经常被研发、运营怼？一篇文章教你告别过去！

1. 你接到一个需求的，立刻去想怎么解决这个问题，想的差不多就开始画原型，很快就画好原型拿给领导看，领导劈头盖脸的指出一系列的问题。

2. 经过几轮的修改，终于进入需求评审阶段，在需求评审会议上，方案被研发、运营挑战，直接在评审会议上开撕，一个需求评审会议，要进行 1-2 个小时，最终还要进行二次评审。

3. 上线之后，业务方反馈说，其实这个和他们想要的，还是有一些差距的。你感觉心好累，不被理解。

• 这个需要要解决什么问题
• 解决之后，能给你们带来什么价值
• 如果不处理，那会有什么影响？

做这件事的目的是整理这个需求有哪些功能模块，以及模块之间的关联，产出物可以是纸上涂鸦。这时候要做的事情:

1. 是拿上手绘图，去找研发负责人，讨论一下方案的可行性，避免踩不懂技术的坑。
   
   
2. 同时也让研发同学参与进来，知道接下来产品要做什么事情，解决什么问题。

• 新「用户登录」，支持微信账号登录即注册。
• 「新老用户关联」，解决「老用户」用微信账号登录后，与原来账号绑定或解绑问题；
• 涉及到「修改密码」模块优化：要关注只有微信登录的用户，是无法修改密码的；
• 原来账号系统中，支持手机验证码登录模式有安全漏洞，增加「手机号码注册限流」。

 流程图 

目的要定义角色，在核心功能模块的逻辑规则、分支条件和最终结果。也防止我们遗漏场景。这时候可以做两件事：

1. 拿着流程图，找你 leader 讲一下，看下流程有没有问题；如果业务比较复杂，可以和需求方沟通下，看有没有需求遗漏；

2. 和研发同学提前沟通下，让研发同学也了解整个模块的流程是什么。

   
   

举个例子：

 结构图细化 

 原型交互设计 

以上 5 步完成之后，那产品 80%的思考已经完成。可以根据团队习惯，确定交互的细致程度，如要求高保真原型，那就把交互做的更完善一些，有交互的地方做好标记，有逻辑的地方标明规则。这里不讨论如何画交互原型，如果有需要，可以留言沟通。

需求文档

1. 首先是按模块写文档，要明确每个模块的背景和定义，

2. 当需求较多（超过 3 个）时，要标注优先级（P0、P1、P2），确保核心功能优先处理。

3. 注意不要造名词，同一个内容前后保持一致。

需求评审

1. 需求文档提前 1 天发给团队中的小伙伴，让大家提前了解下需求情况。
2. 正式的需求评审会议上，先讲和大家同步，这次需求，我们为什么要做这个需求，解决了什么问题；更高阶一点的可以讲此次需求，能给业务或团队带来了什么价值。
3. 要先讲结构图和流程图，这两个讲解完毕，团队小伙伴们基本上了解此次需求的重点是什么了，然后着重讲一下逻辑判断。
4. 最后，要有一个时间计划表，然后团队小伙伴填写，确保团队合作的节奏，如果有 deadline，团队小伙伴会更合理安排时间。