大多数产品经理都很注重产品原型的设计的环节，其实也很好理解其中缘由：
今日计划开始着手开始设计HR《绩效管理》模块，基于之前的调研和准备，基本上已经形成对系统整体概念。原型设计过程中，经历了几个关键的思考结点： 1、产品内容组织结构以列表的形式组织，直接罗列每位员工提交的绩效数据项。如果员工数量巨大，又该如何更加高效的组织/管理海量的数据。让人陷入一阵纠结，尝试以绩效模板为主体依旧无法解决表单的超负荷提交；于是再次尝试以组织架构为基础，即被考核员工所属的部门为依据进行绩效表单管理。 管理系统类的产品最关心无外乎业务流程，而业务系统的设计又要求对特定业务有足够的理解。前段时间，已经做了很多的调研，轮到今天商场时依旧心有余悸，存在陌生感。尤其是表单的表头元素的设计，更是让人煎熬。因为我真地不知哪个元素重要，哪个元素不那么重要。 运营业务人员给我提供了一份绩效考核的模板，于是上午一搜也是大同小异。面对一张表格，我该如何将其转化为产品的形态，或者说并不是转换，而是另一种表达方式。 最简单的做法就是稍作变化直接将表Copy到产品上，确实是可以解决问题的。哪有那么多好事呢？想啥呢？ 对表格的内容进行分析，大概包括一下几个内容：
以信息架构（IA）的思想，对产品的个人绩效模块做一个简要的信息架构图（如下）。 总之，这一次产品原型设计的过程让人有些揪心，我也做了一点自我反思：
继续《绩效管理系统》的产品设计，事实上这是一个项目，有别于往日设计的互联网产品。这两天我简直就是“一个脑袋两个大”，主要还是因为缺乏专业的知识以及业务的特殊性。 昨天与集团人事负责薪资的姐姐们开了一次需求“茶话会”，结果就是没有什么实质性的结论产出。 轻轻地我走了，正如我轻轻地来，挥一挥手，不带走一片云彩…… 事实上，还是得到了一句回复：集团各个子公司的绩效考核方式都不一样，闻此之后我的心情是焦灼的。抛给产品经理的问题随机而来，如何平衡一般与特殊的关系？ 甩出一句话：生死看淡，不服就干！ 我想，我该做点什么？
绩效考核信息架构图，如下图： 概述，绩效管理的信息架构（IA）的内容大致分为：
以上三个模块的三个信息模块：员工信息、绩效结果、其他事项，全部为通用信息模块，也就是无论绩效如何评价，都不可能缺少上述的三个基础模块。然而，最艰难的工作是如何将【绩效考核】尽可能标准化，而不是单纯的满足用户的个性化需要？ 以下创建绩效考核模板的基本思想：秉承一般性原则，权衡个性化需求。产品设计也兼顾了用户的个性化需要，满足用户自定义绩效模板的需求。 继续完善《绩效管理》模块的终极产品流程和原型设计，因为本周就是该项目交付的截止时间节点。在该项目的参与过程中，坦白讲我显得有些凌乱、隐约地感觉自己的那一套产品哲学显得有些不那么作用了，以下两点令我印象深刻：
成功的理由都一样，失败的借口千千万！说再多也没用，客观因素就不多说了，事实上只有Loser才在意拿些没有意义的自圆其说，而我并不喜欢那样… 周末两天的休息时间里，我利用闲暇时间尝试梳理了这款《绩效管理》的最初思路和构思路线图，完整还原了一个思考的全过程。耗费了一天的时间完成了【业务流程】到【产品流程】的转化，而这恰恰是业务与产品最有价值的一次“华丽转身”。产品框架结构的布局也是产品过程的核心任务之一，只有做好这一阶段的基础性铺垫准备，才会有接下来的产品细节释放环节。产品经理的工作逐渐由前期偏向构思转向偏向执行的阶段中心，这一环节也体现了执行型（To do）产品经理的核心能力要求。 2016年12月12日 上午实现业务流程 —> 产品流程的演变，其实这一环节是我设计过程中最头疼的：公司的绩效考核方案及流程，与常规的绩效考核方案存在非常大的差异，甚至说有些另类。工作中心实现转换后，将着重侧向对细节的打磨。以下为《绩效考核》的核心页面结构框架： 逐步完善产品原型的设计，依然是心有余悸，主要是业务的陌生感带来的一丝恐惧感，为什么内心如此焦灼？因为爱的深层，一份对产品的挚爱！ 主要包括以下几个核心页面：
构建产品的过程中，影响产品落地的因素真地是猝不及防，主观的、客观的无处不在，让人抓狂不堪。项目本身的复杂性也决定了产品的调性，对产品的思考绝非易事。 产品关联的任何一个协同者都无法忽视，都不能被轻视，都值得被尊重！缔造一款优秀的产品绝非易事，远比想象地要复杂地多！ |
|
|
