导读：小白进入产品经理行业，总会有些迷茫，想要寻求前辈的经验。对本文将从产品的整个策划流程进行写作，包括需求调研分析、范围层和结构层梳理、交互原型设计几个工作节点，根据时间比例个人总结为532工作法。

一、目的

不知不觉已经整整毕业5个月，成为产品界菜鸟新人5个月了，通过这篇文章总结一下5个月来自己从0-1的成长，也总结积累一下个人的工作方法，为之后进阶为产品小白菜打下基础。

说实话，刚接触产品策划这个岗位时我是比较慌、恐的。慌是因为陌生，我之前是做产品运营的，主要的业务是如何让产品更好的为公司创造价值，是使用产品这个介质，不是创造介质，对我而言产品策划是个陌生的领域；恐是因为未知，我不知道我能在产品这条路上走多远，也不知道这条路到底适不适合我，只能带着未知坚定而又慌恐的向前走。

从进入公司通过MNI项目从0到1进行产品策划，转正后又通过已有的项目进行从1-N的迭代优化，这5个月对我而言真的是翻天覆地的变化，产品领域博大精深，涉及的知识领域数不胜数，这5个月看的书籍堪比我大学四年的数量。我也在实践中初步总结出了属于自己的工作方法，其中包括需求调研分析、范围层和结构层梳理、交互原型设计几个工作节点，按照时间比例我个人总结为532工作法。

二、工作方法

做过产品的人都知道B端和C端有本质上的区别，C端重视体验，且是一类用户多种属性，而B端重视效率，是多种角色、多种业务，重视对业务逻辑和流程的把握。如果想B端产品设计好，那么需求的分析和调研是最重要的部分。

1. 需求调研分析

需求调研分析是很考验产品专业的一项技能，可以说需求调研分析做好了，产品策划工作就做好了一半。我一般会用策划周期一半的时间去做需求调研分析，这就是“532工作法”中的“5”。

需求调研有多种方法，如问卷、访谈、岗位实践、数据分析等，不过对于B端个人推荐访谈和实践的方法。

1）需求分析

当你接到一个需求的时候，不能直接就去想要做成什么功能，一定要先通过调研的方式把握需求的产生原因、涉及的业务逻辑和流程、以及想要得到的效果（涉及管理层面的规范和标准，一定要不能光看业务，业务只是管理的执行表现，管理层面的规范逻辑才是核心）。

以本质思维为思考方式，以追问法进行自问自答自分析，举个例子，现在有1需求是想做一个采购管理的功能，用来解决采购流程不规范、采购数据追溯困难的问题。

那首先设置几个问题，

1. 这个需求是要解决什么问题？
2. 要解决的问题涉及到了哪些业务？
3. 现有的业务流程是怎样的？所涉及的相关人员都有哪些？
4. 想要的效果是怎样的？

那么我们自己回答一下这些问题，

1. 这个需求要解决采购流程不规范、数据追溯困难的问题
2. 涉及到了物品采购业务
3. 现有的业务流程是先向采购员提出物品采购需求，通过后采购员进行线下的比价议价，采购负责人负责线下审批比价单，通过后采购员进行下单、向财务请款，最后收货给到申请人；所涉及的相关人员有申请人、采购员、采购负责人、财务
4. 想要的效果是将此业务流程规范化、将线下进行仅有部分人可见的业务数据放到线上，可供业务流程上的相关人员进行协作，可快速追溯数据，让监察能随时监管

那么分析过需求，对需求的产生原因、涉及的业务流程和要得到的效果有一定了解后，就可以进行调研进行验证了

2）需求调研

需求调研的目的是为了进一步理解需求，验证、补充完善预先分析的结果，调研的方法我基本上会选用访谈的方式。

访谈一般对于初级的产品来说是比较困难的，一是级别不够，很难能将所有的相关人都一起访谈，二是经验不足，可能无法通过一次/几次访谈就能调研透彻。所以个人建议是初级的产品可以通过自己部门领导去组织访谈会议，同时预先做好分析，多维度总结一些要提问问题。

就我个人而言，访谈步骤基本上是

1. 预先估算一个会议时间，把会议室先预先定出来
2. 然后联系部门领导和其他相关人，根据重要的人的时间调整会议安排
3. 访谈过程：询问需求背景—涉及的业务有哪些—现有的业务流程是怎样的—涉及哪些角色—各个角色在其中起到哪些作用—各个角色所涉及的业务细节—想要达到一个什么样的效果/规范—提出自己的解决思路和完善流程的想法—总结会议的共识和后续跟进的相关事项和人员

调研不是通过一次访谈能彻底解决的，访谈会议基本上能解决大部分的问题，但不能解决全部问题，需要后续有更多的交流，个人建议是涉及相关人较多/需要确定的共识性问题组织相关人员进行访谈会议，相关人较少/仅涉及部分业务的问题尽量通过聊天产品进行文字交流。

3）需求梳理

需求梳理是需求调研分析的收尾部分，也是最重要的部分。这是一个承上启下的部分，需求梳理不好前面的需求分析、需求调研就会没有任何用处。

就我个人而言，一般情况我会根据相关业务流程去做需求梳理，以要解决的问题为中心，以业务流程为框架，以角色涉及的需求为填充。通过梳理需求，分析出解决方案，并根据业务核心程度简单判定优先级，同时判断难易程度。

个人使用的需求调研分析的表格字段：序号、提书方、提出人、业务场景、业务需求、解决方案、难易程度、优先级、备注

2. 范围层和结构层梳理

范围层指的是解决需求所需要拥有的能力，结构层是能力外在体现的功能。需求梳理阶段的分析出的解决方案是初步的解决方案梳理，具体的范围层和结构层的梳理需要更加精细化。这一步是需要根据需求调研梳理出将要做的系统能力和功能，还需梳理出需要关联的外部系统，关联方法、功能权限、数据权限、字段权限、审批流程、审批权限等等。这一步我一般会用策划周期10分之3的时间去做，这是“532”工作法中的“3”。

具体步骤如下：

1. 首先梳理出业务需求所需的能力导图，这一步一定要细致，能力基础决定上层建筑
2. 然后根据能力去分解功能、设计功能，一定不能通过需求直接设计功能，那一定会有疏漏，一气呵成永远比缝缝补补要好得多
3. 梳理字段，将功能所涉及的字段一个不漏的梳理出来，不要偷懒、不要偷懒、不要偷懒
4. 梳理系统权限和流程，权限梳理一定要考虑数据的敏感性和角色的权限，有必要的话要将功能、字段、数据区分开，流程设置的话要考虑后续是否会有相似的路程，可以单独设计出一个配置项，后续可复用

范围层和结构层梳理最好是输出思维导图，比较清晰，在设计原型的时候超级方便。

3. 交互原型设计

交互原型设计包括三部分：原型、交互、规则。原型是结构层的外部体现，交互是与用户做交流的系统表达，规则是在这个系统上的玩法以及与其他系统要怎样玩。前面的工作如果都可以尽善尽美的做完，那么交互原型设计就会特别快，我一般会用策划周期的10分之2的时间去做，这是“532”工作法中的“2”。

原型设计这里无法总结太多，我个人画原型一般是画低保真，规则要写尽可能的完善，可参考一些阿里、腾讯的交互设计，B端对于交互原型没有那么高的要求，只要高效、便捷就是好的，个人推荐采用简洁的设计。（可以读一读《简约至上》这本书。）

三、结论

我个人目前处在产品的初级阶段，大多数情况只能考虑到业务和管理层面，我很清晰的能感知到。产品经理一般有两种模型要掌握，一是初级产品经理要掌握的用户模型（对于B端，此“用户”多数指的是业务需求），二是高级产品经理要掌握的交易模型。以后的日子还长，诸君共勉。

本文由 @神明大人呐 原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议。