梳理一下B端产品设计与需求评审过程

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

一、需求编写

产品经理写了初版需求文档初稿后，就可以找干系开拓同事沟通了。

我的需求文档内容一样平常包括业务流程图和原型图含解释笔墨，由于业务流程图可以帮助自己更好得理解项目全局，流程图表示了每个模块和每个功能之间的关联性，在流程图上一画就可以创造逻辑漏洞，业务流程图顺了，全体项目需求就顺了。

如果画流程图的过程中，创造画不下去的情形，一样平常便是对项目的需求没有很好的理解，那么就先去翻阅项目书，看看有没有什么遗漏的部分，如果还是不解，那么就找项目经理或者前期参与的干系同事，目的是对全体项目的需求有全局的理解。

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

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

下图是业务流程示意，业务流程关键在于大略易懂且不遗漏，千万不能繁芜了，别人看不懂的业务流程图不是好流程图。

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

二、需求沟通

在与干系研发同事做私下互换的过程中，产品经理须要对需求做一遍阐述，在阐述的时候，每每自己就会创造不少设计漏洞，合营的同事也会创造阐述漏洞，创造漏洞，优化设计，是这场互换的目的，这也是为了提高后面需求评审会的效率。

当然，这就须要产品经理做一个评估，是单个互换效果高，还是团队一起互换效率高。
我的履历来说，不同的需求要差异对待。
有些大的框架须要和研发卖力人沟通，有些同事这方面的能力比较欠缺，如果拉着一起评审，反而摧残浪费蹂躏他的韶光，降落沟通效率。

我的原则是，评审会议上，不说话的人就不该来参加这次会议，属于相互摧残浪费蹂躏韶光。
而有些需求，涉及的功能模块非常多，相互之间都有关联，那么一定要把干系的同事都喊上，否则很随意马虎涌现千篇一律的事情讲多次都无法拍板的情形，把大家都凑在一起，相互之间的约束关系，都放开来说，整体方案设计。

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

三、需求评审会议

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

产品经理要把准备好的需求文档（业务流程图、原型图、解释文档等）作为附件一并发送，并预定会议室和会议韶光，会议韶光一样平常定在邮件发出后的1-3日，由于要担保团队成员在会议前有足够的韶光看一遍文档，在看的过程中，对有疑问的地方，标注出来，回答给产品经理，一样平常被标注的地方便是逻辑抵牾点，也会成为评审会议沟通的重点，这样可以提高会议的效率。

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

第一个问题是，团队没有足够的韶光消化并理解需求，看得模棱两可，随意马虎遗漏问题，没有及时创造，那么等会议结束开始干活的时候，就会创造这也有问题、那也有问题，涌现返工情形。

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

四、需求评审会议纪要

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

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

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

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

以上便是针对B端产品设计与需求评审过程的大略分享。

本文由 @洗七七 原创发布于大家都是产品经理，未经容许，禁止转载

题图来自 Unsplash，基于 CC0 协议

该文不雅观点仅代表作者本人，大家都是产品经理平台仅供应信息存储空间做事。