B端产品设计与需求评审过程大致是怎样的流程？本篇文章里，作者就进行了一番梳理，从需求编写、需求沟通、需求评审会议等维度进行了拆解，一起来看一下，或许会对你有所帮助。

签完合同，定完项目范围，会有一个项目章程书，产品经理需要编写产品需求文档，包括业务流程图、数据流程图，开发的同事看见项目章程书只会对项目有个大概的了解，并不清楚自己该做些什么开发，需要产品经理带领团队细化需求。

一、需求编写

产品经理写了第一版需求文档初稿后，就可以找相关开发同事沟通了。

我的需求文档内容一般包括业务流程图和原型图含说明文字，因为业务流程图可以帮助自己更好得理解项目全局，流程图体现了每个模块和每个功能之间的关联性，在流程图上一画就可以发现逻辑漏洞，业务流程图顺了，整个项目需求就顺了。

如果画流程图的过程中，发现画不下去的情况，一般就是对项目的需求没有很好的理解，那么就先去翻阅项目书，看看有没有什么遗漏的部分，如果还是不解，那么就找项目经理或者前期参与的相关同事，目的是对整个项目的需求有全局的理解。

产品经理作为整个研发团队的需求输入方，必须对每个需求都了如指掌。一方面，对项目非常了解才可以把需求文档写清楚，不会乱七八糟得到处是错。另一方面，这有助于产品经理领导力的形成，每次与研发团队做需求交流的时候，研发同事都会提出非常多的质疑，如果产品经理经常无法自圆其说，总是被找到很多漏洞，那么产品经理在团队中的领导力会大打折扣。

产品经理虽然不是领导岗，但在团队职责中属于领导属性，需要有与研发battle的能力，所以准备工作一定要充分，才可以以理服人，让研发团队信服你。

下图是业务流程示意，业务流程关键在于简单易懂且不遗漏，千万不能复杂了，别人看不懂的业务流程图不是好流程图。

下图是我在墨刀上做的设计稿（去敏截图），以前我习惯用axure做原型设计，但墨刀在线版确实方便不少，看个人喜欢，以效率导向做工具的选择。

二、需求沟通

在与相关研发同事做私下交流的过程中，产品经理需要对需求做一遍阐述，在阐述的时候，往往自己就会发现不少设计漏洞，配合的同事也会发现阐述漏洞，发现漏洞，优化设计，是这场交流的目的，这也是为了提高后面需求评审会的效率。

当然，这就需要产品经理做一个评估，是单个交流效果高，还是团队一起交流效率高。我的经验来说，不同的需求要区别对待。有些大的框架需要和研发负责人沟通，有些同事这方面的能力比较欠缺，如果拉着一起评审，反而浪费他的时间，降低沟通效率。

我的原则是，评审会议上，不说话的人就不该来参加这次会议，属于互相浪费时间。而有些需求，涉及的功能模块非常多，互相之间都有关联，那么一定要把相关的同事都喊上，否则很容易出现一模一样的事情讲多次都无法拍板的情况，把大家都凑在一起，互相之间的约束关系，都摊开来说，整体规划设计。

所以需求评审会议前期的需求沟通，按需组织，需要产品经理对需求、对需求的实现、对团队成员的分工职责，有一个全局把握后决定。

三、需求评审会议

准备好需求文档后，就可以开正式的需求评审会议了。产品经理需要发正式的邮件，一般情况就发给相关团队成员（研发同事、测试同事、项目经理、销售售前等，根据团队情况而定），并抄送给相关方（如老板，发给老板的目的主要是向上管理，让他知道下进度情况，一般情况老板不必参会）。

产品经理要把准备好的需求文档（业务流程图、原型图、说明文档等）作为附件一并发送，并预定会议室和会议时间，会议时间一般定在邮件发出后的1-3日，因为要保证团队成员在会议前有足够的时间看一遍文档，在看的过程中，对有疑问的地方，标注出来，回复给产品经理，一般被标注的地方就是逻辑矛盾点，也会成为评审会议沟通的重点，这样可以提高会议的效率。

文档内容很多，如果直接在会议上打开，并没有提前浏览，会出现两个问题。

第一个问题是，团队没有足够的时间消化并理解需求，看得模棱两可，容易遗漏问题，没有及时发现，那么等会议结束开始干活的时候，就会发现这也有问题、那也有问题，出现返工情况。

第二个问题是，团队如果在会议上第一次看到文档，会提出很多很多无谓的问题，而这些问题当他们看了全部文档后其实就不是问题了，那么会导致会议效率低下，团队氛围不佳，会认为评审会议又臭又长，浪费时间。

四、需求评审会议纪要

需求评审会议结束的时候，产品经理需要发会议纪要的邮件，把会议讨论内容，下一步的todo项，邮件发出，这封邮件非常重要，因为表示需求已经通过了评审，研发同事可以开始正式干活了，需要紧接着就输出开发设计文档供大家评审。

研发同事在编写开发设计文档过程中，依然会找产品经理不断得沟通需求，以确认开发方案可以满足需求，还有一种情况是，研发同事发现如果需求做适当调整，开发难度将会大大降低，缩短工期，那么也需要和产品经理沟通，做一些权衡的考量。

在开发方案定下来之前，需求依然存在调整的情况，如果需求文档做了变更，那么产品经理需要同步变更给团队，最好就是拉个会议，把几日内沟通的情况，与大家沟通一下，这也属于需求评审，如果有不合理的地方，团队提出，再做调整，需求文档和开发方案是一个渐进明细的过程。

有变更一定要做书面记录，不然会出现信息不一致的情况，会出现返工或扯皮，导致团队氛围不佳。

以上就是针对B端产品设计与需求评审过程的简单分享。