不管是你从事了几年，是B端还是C端的产品经理，需求都非常重要。本文作者将从四个方面，围绕需求展开分析，希望对你有帮助。

对于哪个阶段的产品经理来说，需求都非常重要。

规划产品功能时，产品经理需要将原本比较抽象的产品需求变得更加具体。将抽象的产品需求具体化也可以分解为四个环节：确定需求、制作流程图、制作产品原型、编写需求。与大家分享一个需求提出到编写需求文档整个过程我们都需要做什么？

一、需求确定

在需求范围确定阶段，产品经理主要的工作就是与业务方沟通做哪些需求，业务方提需求时，有可能直接说具体实现方案，而没有说痛点，这就需要我们具有识别需求的能力，挖掘背后痛点。当遇到不合理的需求时，如何劝说对方并让他欣然接受呢？

1. 确定需求范围

1）确定需求来源

需求来源分主动需求和被动需求，被动需求由领导、运营、用户等发起的需求，主动需求主要是由产品团队理根据团队目标来规划的版本需求。当遇到被动需求与主动需求叠加的时候，开发资源紧张，如何来确定优先级呢？

2）确认需求目的

因为开发资源有限，确定优先级要根据需求的目的是什么，当前阶段产品重要指标是什么，是数据增长还是优化体验？比如遇到被动需求与主动需求叠加的情况，开发资源只能满足一方的需求时，我们需要根据当前的KPI来确定优先级，如果对当前KPI提升效果不明显，可以将需求调整到后面再考虑。这样确定需求范围的更加客观。

3）需求评估

在评估需求时，若技术方案拿不准，我们需要与技术leader沟通方案的可行性，初步了解需求开发多久，根据开发团队现有的技术能力是否能够满足需求，是否能够在预期时间内完成等。

2. 如何识别需求的真伪？

产品经理最重要的能力就是对需求的判断力，如果需求判断不准备，不但浪费开发资源，对自己也没有成就感，那如何做到呢，我们要考虑如下几点：

1）了解需求的背后痛点

有的需求方提需求的时候直接说方案，但有可能不符合产品的设计原则。

比如运营提的需求是需要在页面中增加一个字段，但是增加一个字段对表结构有改动，影响系统的范围会比较大，需要考虑历史数据如何处理等情况。所以我们需要了解为什么要增加字段，是遇到什么样的问题呢？详细沟通后可能不用增加字段就可以解决问题。所以需要产品经理了解业务方或用户真实的痛点，根据我们的专业能力给出合理的产品方案。

2）是否是普遍需求

前面说到需求的来源分被动需求、主动需求，被动需求有可能是某一家商家或两家提出的，不具有代表性。比如业务方提出一个需求，需要增加一个系统角色，详细沟通以后只有一个商家提出这样的需求。

所以当接到一个需求反馈的时候要了解是不是大多数用户的需求，如果只是少部分有这个需求，需要进一步判断合理性。所以这时候可以让数据作为依据，这样说服业务方也更有信服力。

3）是否符合产品定位

除了要考虑需求是否与目标用户相关，还需要分析该需求是否与产品定位相符合。比如产品是针对销售使用的，就要考虑这个人群的特点，不能学习成本太大，操作太复杂。所以如果业务方提的需求违背了这个原则，我们需要从产品定位的角度去说服对方。

3. 如何说服不合理的需求?

需求判断能力是产品经理能力的体现，难免其他同事提的需求是不合理的，那我们如何来说服对方呢 ？

1）专业度

当对方提一个需求时，需要我们去挖掘背后的原因，其实对方也想寻求你的帮助，如果用你的专业度去和他讲这个需求不合理的原因，或者输出其他解决的方案，对方可能会欣然接受，这样也体现我们的专业度，让对方更加信任我们。

2）善于利用数据

如果对方提一个需求我们也判断不准是否要做，如果能用数据来做依据的，可以利用数据说话，这样更有信服力，对方也会认为比较合理。

3）让对方做输出

若是业务方提的需求，可以让他们输出将需求的流程或需求背景以及期望的收益，当他们在写的时候有可能会查觉需求走不通，有可能自己就说服自己了。

综合以上，明确了需求范围，此时将需求的状态更新为“待排期”，接下来产品经理需要准备需求相关的文档了。

4. 好用的需求管理工具

给大家分享我们常用的需求管理工具wiki，它是一个团队协同的文档管理系统。支持各部门的人将文档传到系统中。

1）界面简单

基础内容通过文本编辑方式就可以完成，支持上传图片，表格等形式。

2）多职能协同

运营以及业务方可以将需求录入，产品经理看到需求后做整理。在axure中编写完成后上传到wiki，技术，测试都可以访问wiki查看需求。

3）归档

目录清晰，方便归档，方便查找之前写过的方案，也方便新人了解业务。

4）可追踪历史

记录页面的修订历史，页面的各个版本都可以查看，也可看到文档的编辑者。

每个公司需求管理工具可能不同，有的用wiki，有的使用teambition,无论使用什么工具，只要清晰管理需求，并且能做好归档就可以。

二、制作流程图

1. 流程图的作用

• 提高沟通效率：和运营，技术讲需求时给大家演示流程图就一目了然。
• 防止功能点遗漏：方便梳理各功能逻辑，防止对功能点有遗漏。
• 锻炼逻辑思维：将流程的正向逻辑与逆向逻辑都进行梳理，从而判断需求的范围。

2. 流程图的分类

流程图分业务流程图，功能流程图、活动流程图，页面流程等，制作流程图前确认目的是什么，业务流程图帮助我们梳理业务架构，主要给领导，业务同事看。任务流程图帮助我们梳理用户操作行为，主要给开发，测试同事看，页面跳转流程帮助梳理各个页面之间的跳转关系，主要在需求中体现。

根据不同的需求来梳理不同的流程。比如要规划618购物节的活动，从如何创建活动、用户购买、以及配送等环节通过流程图先梳理出来，与相关人员沟通确认后，若流程没有问题，再开始画原型。

画流程图时，可以先画正向逻辑，再画逆向逻辑，画完以后再根据需求来检查一遍。

3. 用什么工具画流程图

只要用得顺手就可以。有的小伙伴使用visio，但viso不支持苹果电脑使用，平时我使用axure画，这样原型图、流程图都在一个工具上方便使用。

三、制作原型图

流程图是需要我们将功能的逻辑关系表达出来，原型图是要将需求转化为可视化图形。

一份完整的产品原型要包含具体的功能，页面如何布局，具体交易细节。如何看出产品经理画的原型是否专业呢？

1. 功能点全面

产品原型首先要保证产品功能和内容是完整的，而不是只画主要流程。比如，注册登录页面，在没有输入的情况下，是有文字提示，还是默认灰色，这些都是需要考虑。

2. 页面统一

页面的尺寸，按钮，弹窗、表单等元素也需要统一，而不要每个页面尺寸不一样，按钮大小也不同~

3. 页面简洁

制作原型的目的是为了更加形象地表达产品需求，以方便与技术进行需求的评估。不用做视觉图，只需要线框图就可以。专业的人做专业的事，视觉图交给设计就可以啦~

4. 交互内容完整

产品原型是用于表达产品功能和内容的示意图，因此，产品原型首先要保证产品功能和内容是完整的，要考虑周全，不要有所遗漏。比如，注册登录界面，在没有输入的情况下，是有文字提示，还是默认灰色，这些都是需要考虑的。

5. 工具使用

画原型图的工具除了Axure、还有墨刀、Origami等，个人一直使用axure，根据自己的使用习惯就可以，同时也要考虑团队其他人在用什么，尽量用一种工具，这样相互共享文件时方便打开编辑。

四、需求编写

前面介绍如何确定需求范围，如何制作流程图、画原型。最后如何输出一份高质量的需求文档呢？给大家总结有以下几点：

• 信息全面：需求文档中包含需求背景、版本说明、流程图、原型图、字段说明等描述。除了正常的流程，如无网络，初始化数据，历史数据处理等也都要说明清楚、开发过程中不要因需求信息不全面来回确认而耽误项目进度。
• 格式清晰：写需求也要站在用户的角度去考虑，开发、测试看纯文字会浪费时间，文档形式采用原型+文字描述形式，如果需要表格描述尽量用表格。
• 及时更新文档：在开发过程中难免会有需求更改的情况，及时修改，以免测试时产生歧义。

五、总结

C端产品经理写需求注重是交互逻辑，B端产品在写需求时更注重业务逻辑，所以流程图是必备的。因为大多数需求与字段有关，最好运用表格说明。

B端产品经理也需要了解一些技术基础，比如接口、数据库相关的常识。所以还没有从事产品经理领域或要转行的，可以根据自己的特点选择B端产品经理还是C端产品经理。

作者：柿子姐，8年互联网产品经理；公众号&视频号：柿子姐说产品

本文由 @柿子姐 原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议