本文为我设计《绩效考核管理系统》的全过程还原，写这篇文章的初衷是因为我对面向B端的业务系统不熟悉，想借此机会对自己有些提升。文章以时间为主线串联一段时间的工作流。

　　2016年12月6日

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

　　原型直观明了，至少说是产品早期的雏形；产品成果交付，原型是产品的第一次直观产出；

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

　　1、产品内容组织结构

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

　　2、产品内容元素

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

　　3、内容形式转换

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

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

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

　　员工基本信息：姓名、部门、岗位；绩效指标内容：评估时间、考核指标、指标说明、评估依据、指标权重、完成情况、指标得分；考核结果信息：评分等级、绩效得分、绩效薪资系数；

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

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

　　对业务熟悉程度有限，存在眼高收低的心理；设计过程有些急躁，还是太年轻了。

　　2016年12月8日

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

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

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

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

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

　　我想，我该做点什么？

　　问题：不同公司之间的绩效考核方案及流程存在差异，同一公司的不同部门/员工的绩效考核方式存在差异。矛盾：产品不可能针对全部个性化需求做定制化服务，产品追求的统一标准化，个性化兼而有之。分析：绩效考核方案/流程的差异化最直观的表现就是各个员工之间绩效考核指标和评价流程的不一样，解构《绩效考核表单》，如下图。

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

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

　　员工信息：姓名、部门、岗位，通用信息；绩效考核绩效结果其他事项