产出物|手把手学做B端需求:绩效考核模块(上)( 三 )

  • how:我们现在的填写周期是什么呢?
  • 注意:你的询问对象,至少要涵盖流程中的各项角色。例如这个场景中,会有查数据和看数据两种角色,如果角色负责的业务,会影响到角色的行为,那么还需要询问不同业务下同一个角色的工作流程。
    注意:需要特别注意询问数据变更的逻辑。是否会变,变得多与少,为何会变,变了以后会影响什么,这些都会和后期设计产品方案直接相关。
    4. 跨维度搜集内部信息对模块负责,当然要为它未来的价值负责。
    所以你需要跨越当前需求方,去思考谁或者哪个部门可能还有类似的需求。模块的终局,应该是可以支持到所有角色和部门的需求的。所以了解其企业内部其他人的需要,这一步需要主动跨越的步骤,对设计的的可扩展性非常重要,但也是很容易被忽略的。
    在绩效考核的例子中,我们就进一步去搜集了HR部门的绩效考核数据,从而发现了绩效规则的多样性,充实了案例库,也了解了这部分和薪酬管理的关联。
    5. 搜集外部信息以上信息,搜集的都是企业内部的信息,可能会带有强烈的企业个性化风格。
    为了避免陷入定制化的困局,需要再看看外部信息,这时有两种方向是我们可以去尝试的。
    一是提供类似模块的通用产品,他们的流程和业务是如何做的。比如飞书有OKR绩效,泛微有绩效考核,CRM系统有对销售的目标划定。这些产品都可以成为考察的范围,他们的通用化设计思路可以给后续工作带来一些灵感。
    二是其他企业是怎么样做绩效管理的。可以从百度文库找到考核文档,可以从人人查看其他产品的设计方案。在之前的搜索这部分信息的时候,自己很明显的感受到,手头在做的绩效管理和大家的方案并不太一样。大家的绩效管理系统,更多的是体现员工自主定下绩效,进行层层审批的这一过程。所以也才萌生了写一篇文章的想法。
    信息搜集到此结束,后续还有整理信息和设计方案两大步骤,请等待下篇。
    等待的过程中,请收藏,点赞,多多益善~
    本文由 @假装是运营 原创发布于人人都是产品经理。未经许可,禁止转载
    【 产出物|手把手学做B端需求:绩效考核模块(上)】题图来自Pixabay,基于CC0协议