从需求分析到需求评价，笔者总结了需求实现前的八个步骤和要点，希望对产品经理有所帮助，避免频繁的研发和运营。


产品经理经常抱怨我的需求，但我得不到团队和需求方的认可。


在与需求方的认可。


在与研发沟通时，几乎是跪着说，在线需求方也开玩笑说，预计仍有一些差距。


先描绘一个场景，看看里面有没有你的影子: 当你收到一个需求时，立即考虑如何解决这个问题。


当你想到它时，你几乎开始画原型，并很快为领导画原型。


领导指出了一系列问题。


经过几轮修改，终于进入了需求评估阶段。


在需求评估会议上，该计划受到研发和运营的挑战，并直接在评估会议上撕裂。


需求评估会议应进行 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，小伙伴们会更合理地安排时间。


最后:需求评审只是一个宣传，重点是线下。


希望以上能给你带来一些帮助。


特别说明：本网站的主要目的是收集与互联网运营相关的干货知识，为运营伙伴提供便利。


本网站收集的公共内容来自互联网或用户的贡献，这并不意味着本网站同意其观点，也不对网站内容的真实性负责。


如有侵权行为，请联系网站管理员删除，。