经常有产品经理和我吐槽，辛辛苦苦做的需求，得到的却得不到团队和需求方的认同。在和研发沟通的时候，差不多就是跪着讲的，上线之后需求方还来吐槽，说也预期还是有一些差距的。
先描绘一个场景，看看里面有没有你的影子：
- 你接到一个需求的，立刻去想怎么解决这个问题，想的差不多就开始画原型，很快就画好原型拿给领导看，领导劈头盖脸的指出一系列的问题。
- 经过几轮的修改，终于进入需求评审阶段，在需求评审会议上，方案被研发、运营挑战，直接在评审会议上开撕，一个需求评审会议，要进行 1-2 个小时，最终还要进行二次评审。
- 上线之后，业务方反馈说，其实这个和他们想要的，还是有一些差距的。你感觉心好累，不被理解。
如果你身上也有类似的事情发生，按照下面的步骤进行，会极大减少这种场面的发生。
01 需求分析
当我们接到需求，不要马上去想怎么来实现，先问需求方几个问题：
- 这个需要要解决什么问题
- 解决之后，能给你们带来什么价值
- 如果不处理，那会有什么影响?
问了这几个问题之后，你大致就清楚这个需求的来龙去脉，以及需求的优先级，如果需求方连这几个问题都回答不了，那需求可以拒绝了。
举个例子：运营同学说我们的登录系统不满足现在需求，希望系统能支持微信登录。按照上面 3 个问题，我们来和需求方沟通，需求方说：
“下个季度我们的重点是做微信粉丝购买转化，但现在账号系统只支持“邮箱登录”和“手机号码”登录，几轮运营测试下来，发现未注册的粉丝购买转化很低，很大程度上卡在注册环节，不愿意填写手机号码，怕收到骚扰短信。支持微信登录后，会极大增加粉丝的付费转化效果。”
了解到需求方的使用场景“微信体系场景下粉丝快速登录”，不做会影响转化，是必须要做的事情了。接下来要进入第二个环节「手绘线框图」
02 手绘线框图
做这件事的目的是整理这个需求有哪些功能模块，以及模块之间的关联，产出物可以是纸上涂鸦。这时候要做的事情:
- 是拿上手绘图，去找研发负责人，讨论一下方案的可行性，避免踩不懂技术的坑。
- 同时也让研发同学参与进来，知道接下来产品要做什么事情，解决什么问题。
举个例子：拿上你画好的登录流程手绘图，和研发同学讲清楚要解决什么问题，研发同学看了之后，说需求问题不大，但你要考虑一下，已经注册过的用户，用微信登录后账号如何关联在一起。
和研发同学沟通完毕之后，你再增加了一个“新老用户关联”线框图。
接下来进入「产品结构」整理阶段。
03 结构图整理
整理好手绘图，那我们来进一步梳理产品结构。这阶段的产出物，是模块的定义，或者说这个模块解决了什么问题。
举个例子：上面支持微信登录的例子，涉及到的功能模块有：
- 新「用户登录」，支持微信账号登录即注册。
- 「新老用户关联」，解决「老用户」用微信账号登录后，与原来账号绑定或解绑问题;
- 涉及到「修改密码」模块优化：要关注只有微信登录的用户，是无法修改密码的;
- 原来账号系统中，支持手机验证码登录模式有安全漏洞，增加「手机号码注册限流」。
完成了结构图，就要开始模块之间的流程整理。
04 流程图
目的要定义角色，在核心功能模块的逻辑规则、分支条件和最终结果。也防止我们遗漏场景。这时候可以做两件事：
- 拿着流程图，找你 leader 讲一下，看下流程有没有问题;如果业务比较复杂，可以和需求方沟通下，看有没有需求遗漏;
- 和研发同学提前沟通下，让研发同学也了解整个模块的流程是什么。
举个例子：
05 结构图细化
每个功能模块，要细化到字段，避免信息遗漏，前后台数据要保持一致。
举个例子：还是上面讲的微信登录场景，用户第一次用微信方式登录，要获取到用户的 userid、手机号码，如果手机号码不存在，那还要生成用户名(username)。把所有关键字段罗列出来，对产品思路重新进行梳理。
06 原型交互设计
以上 5 步完成之后，那产品 80%的思考已经完成。可以根据团队习惯，确定交互的细致程度，如要求高保真原型，那就把交互做的更完善一些，有交互的地方做好标记，有逻辑的地方标明规则。这里不讨论如何画交互原型，如果有需要，可以留言沟通。
完成原型交互设计，拿给你的 leader 看下，组织一次小规模的需求方评审，看看是不是解决了需求方的问题。
工具推荐：Axure、墨刀。
07 需求文档
和需求方沟通之后，就开始写需求文档。关于需求文档，有的团队要求写成doc 文档，有的只要求在原型处标记就好。
我比较倾向于写成 doc 文档，因为需求文档是产品产出的再一次检查和梳理。需求文档的第一读者是产品经理，然后才是研发、测试等小伙伴们。
文档中几个关键点要注意:
- 首先是按模块写文档，要明确每个模块的背景和定义，
- 当需求较多(超过 3 个)时，要标注优先级(P0、P1、P2)，确保核心功能优先处理。
- 注意不要造名词，同一个内容前后保持一致。
完成以上，就可以进入需求评审阶段了。
08 需求评审
现在我们要重新认识下「需求评审会」，它不是一个PK 工作量的会议，而是与研发、测试等团队小伙伴信息同步，宣告这个项目的开始，更多的工作是要前置到评审会议之前。
需求评审也是有流程的：
- 需求文档提前 1 天发给团队中的小伙伴，让大家提前了解下需求情况。
- 正式的需求评审会议上，先讲和大家同步，这次需求，我们为什么要做这个需求，解决了什么问题;更高阶一点的可以讲此次需求，能给业务或团队带来了什么价值。
- 要先讲结构图和流程图，这两个讲解完毕，团队小伙伴们基本上了解此次需求的重点是什么了，然后着重讲一下逻辑判断。
- 最后，要有一个时间计划表，然后团队小伙伴填写，确保团队合作的节奏，如果有 deadline，团队小伙伴会更合理安排时间。
最后：需求评审只是一个宣讲，重点都在线下。希望以上能给你带来一些帮助。
