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

how：我们现在的填写周期是什么呢？

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