产品案例|从0到1构建《绩效管理系统》

本文概述了我设计《绩效考核管理系统》的全过程，还原了产品设计过程中的思路和心理变化细节。写这篇文章的初衷——对面向B端的业务系统不熟悉，想借此机会对构思过程做加法。全文以时间为主线串联起一个完整的工作流。

产品案例|从0到1构建《绩效管理系统》

---

2016年12月6日

大多数产品经理都很注重产品原型的设计的环节，其实也很好理解其中缘由：

原型直观明了，至少说是产品早期的雏形；

产品成果交付，原型是产品的第一次直观产出；

今日计划开始着手开始设计HR《绩效管理》模块，基于之前的调研和准备，基本上已经形成对系统整体概念。原型设计过程中，经历了几个关键的思考结点：

1、产品内容组织结构

以列表的形式组织，直接罗列每位员工提交的绩效数据项。如果员工数量巨大，又该如何更加高效的组织/管理海量的数据。让人陷入一阵纠结，尝试以绩效模板为主体依旧无法解决表单的超负荷提交；于是再次尝试以组织架构为基础，即被考核员工所属的部门为依据进行绩效表单管理。

绩效列表-原型设计

2、产品内容元素

管理系统类的产品最关心无外乎业务流程，而业务系统的设计又要求对特定业务有足够的理解。前段时间，已经做了很多的调研，轮到今天商场时依旧心有余悸，存在陌生感。尤其是表单的表头元素的设计，更是让人煎熬。因为我真地不知哪个元素重要，哪个元素不那么重要。

员工列表-原型设计

3、内容形式转换

运营业务人员给我提供了一份绩效考核的模板，于是上午一搜也是大同小异。面对一张表格，我该如何将其转化为产品的形态，或者说并不是转换，而是另一种表达方式。

绩效考核表

最简单的做法就是稍作变化直接将表Copy到产品上，确实是可以解决问题的。哪有那么多好事呢？想啥呢？

对表格的内容进行分析，大概包括一下几个内容：

员工基本信息：姓名、部门、岗位；

绩效指标内容：评估时间、考核指标、指标说明、评估依据、指标权重、完成情况、指标得分；

考核结果信息：评分等级、绩效得分、绩效薪资系数；

以信息架构（IA）的思想，对产品的个人绩效模块做一个简要的信息架构图（如下）。

员工绩效详情页

总之，这一次产品原型设计的过程让人有些揪心，我也做了一点自我反思：

对业务熟悉程度有限，存在眼高收低的心理；

设计过程有些急躁，还是太年轻了。

---

2016年12月8日

继续《绩效管理系统》的产品设计，事实上这是一个项目，有别于往日设计的互联网产品。这两天我简直就是“一个脑袋两个大”，主要还是因为缺乏专业的知识以及业务的特殊性。

昨天与集团人事负责薪资的姐姐们开了一次需求“茶话会”，结果就是没有什么实质性的结论产出。

轻轻地我走了，正如我轻轻地来，挥一挥手，不带走一片云彩……

事实上，还是得到了一句回复：集团各个子公司的绩效考核方式都不一样，闻此之后我的心情是焦灼的。抛给产品经理的问题随机而来，如何平衡一般与特殊的关系？

甩出一句话：生死看淡，不服就干！

我想，我该做点什么？

问题：不同公司之间的绩效考核方案及流程存在差异，同一公司的不同部门/员工的绩效考核方式存在差异。

矛盾：产品不可能针对全部个性化需求做定制化服务，产品追求的统一标准化，个性化兼而有之。

分析：绩效考核方案/流程的差异化最直观的表现就是各个员工之间绩效考核指标和评价流程的不一样，解构《绩效考核表单》，如下图。

绩效考核表单

绩效考核信息架构图，如下图：

绩效考核-信息架构

概述，绩效管理的信息架构（IA）的内容大致分为：

员工信息：姓名、部门、岗位，通用信息；

绩效考核

绩效结果

其他事项

以上三个模块的三个信息模块：员工信息、绩效结果、其他事项，全部为通用信息模块，也就是无论绩效如何评价，都不可能缺少上述的三个基础模块。然而，最艰难的工作是如何将【绩效考核】尽可能标准化，而不是单纯的满足用户的个性化需要？

以下创建绩效考核模板的基本思想：秉承一般性原则，权衡个性化需求。产品设计也兼顾了用户的个性化需要，满足用户自定义绩效模板的需求。

创建绩效考核模板-原型设计

---

2016年12月12日

继续完善《绩效管理》模块的终极产品流程和原型设计，因为本周就是该项目交付的截止时间节点。在该项目的参与过程中，坦白讲我显得有些凌乱、隐约地感觉自己的那一套产品哲学显得有些不那么作用了，以下两点令我印象深刻：

业务知识专业、深奥、难懂，尤其是HR绩效方面的知识更是让人不可思议，因为大部分公司都没有遵循HR知识体系的相关要点，都开辟了全新的个性化考核方式，甚至有些另类；

产品思路并稳定，显得有些迷离。此次负责的产品工作，严格意义讲应该是——软件项目，一种有别于互联网产品的软件形式，与我之前负责主导的产品管理的流程明显是存在差异的。

成功的理由都一样，失败的借口千千万！说再多也没用，客观因素就不多说了，事实上只有Loser才在意拿些没有意义的自圆其说，而我并不喜欢那样...

周末两天的休息时间里，我利用闲暇时间尝试梳理了这款《绩效管理》的最初思路和构思路线图，完整还原了一个思考的全过程。耗费了一天的时间完成了【业务流程】到【产品流程】的转化，而这恰恰是业务与产品最有价值的一次“华丽转身”。产品框架结构的布局也是产品过程的核心任务之一，只有做好这一阶段的基础性铺垫准备，才会有接下来的产品细节释放环节。产品经理的工作逐渐由前期偏向构思转向偏向执行的阶段中心，这一环节也体现了执行型（To do）产品经理的核心能力要求。

2016年12月12日 上午

实现业务流程 —> 产品流程的演变，其实这一环节是我设计过程中最头疼的：公司的绩效考核方案及流程，与常规的绩效考核方案存在非常大的差异，甚至说有些另类。工作中心实现转换后，将着重侧向对细节的打磨。以下为《绩效考核》的核心页面结构框架：

2016年12月12日 下午

逐步完善产品原型的设计，依然是心有余悸，主要是业务的陌生感带来的一丝恐惧感，为什么内心如此焦灼？因为爱的深层，一份对产品的挚爱！

主要包括以下几个核心页面：

组织绩效管理

绩效评估分析——部门绩效、员工绩效

绩效授权管理——管理员设置

页面框架结构

构建产品的过程中，影响产品落地的因素真地是猝不及防，主观的、客观的无处不在，让人抓狂不堪。项目本身的复杂性也决定了产品的调性，对产品的思考绝非易事。

产品关联的任何一个协同者都无法忽视，都不能被轻视，都值得被尊重！缔造一款优秀的产品绝非易事，远比想象地要复杂地多！

Note：写于2015年12月初，整理于2016年12月末，此文章为之前的四篇文章的综合。

---

原创声明：本文章的最终解释权归互联网产品小王所有，如需转载，请注明文章出处！谢谢...