方法论:互联网式庖丁解牛

作为互联网公司的产品经理来说,如何根据需求来制定具体的功能点是一个非常基础的能力。但是很多时候对于新手来说,往往很多设计和功能是拍脑袋决定的,设计出来的功能往往是不具备所谓的“产品闭环”。一经版本上线就会发现成吨的问题,所以不管从价值论层面还是从方法论层面来说,产品经理需要具备能够根据需求、业务流程来做拆解,并有所取舍来完成一个功能的“闭环”。

举例子来说,本周和sam讨论的需求机器人,boss提的要求能够随时能够记录需求。那么先从分析背景和目的来说,boss提这条需求的背景,是因为往往在工作中所提的需求并没有被解决,希望通过需求机器人的形式随时随地能够记录并且提醒相关负责人解决并且解决通知。从需求本身来看,是因为需求对于boss和相关负责人来说“不见了”,才会导致上述结果。那么我们将整个流程进行拆解分析可以得到:

需求不见了:

1.看到了,但是并未被执行

2.没看到,可能群里对话太多,被淹没了

3.不知道,做完了,但是提需求的人并不知道结果

4.未被执行(可以归为1类)

对于1中来说,看到了未被执行,可能的结果是看到了,但是忘记了,或者有可能需求太难,需要的资源多,或者技术难度大等等无法时下处理,那么这种情况下,需要处理人能够事实看见,知晓,或者提需求的人能够知晓。那么我们需要在收集的页面有状态显示,告知处理中或者无法处理。对于2来说,没看到,那么则需要能够有实时提醒处理人的功能。对于第3点来说,同样也需要告知提需求人结果,并反馈给他。那么这么一分析下来,大概的功能应该有状态、通知两个大类的功能。再进一步的完整流程:


根据流程完成下来后,我们明确了流程中各个阶段需要做的事情,在每个阶段中规划处相应的功能后组合,进一步形成了我们产品的整个闭环。

所以,当在产品经理在遇到某些具体的需求的时候,应该开始慢慢拆解一下需求的背景和原因和目的,明确后思考我们解决问题的各个流程以及步骤,确定产品/功能的边界和闭环后针对每一个步骤进行功能设计。这样我们能在我们既定的框架和逻辑下得到最优解。

你可能感兴趣的:(方法论:互联网式庖丁解牛)