|
关于需求评审要传递的信息，其实包含了非常简单的一套逻辑：价值，功能，实现。 高效评审，是向协作团队传达出了统一的项目价值，能够让他们理解彼此的角色，任务及需要落地的行动，以及彼此角色之间的关联是什么。 价值：为什么要做这个需求，上线之后的价值是什么。 功能：为了支撑这个价值，需求包含了哪些功能呢。 实现：针对每一个功能，该怎么实现。 产品经理在需求评审会上最重要的任务，是帮助大家建立这种信任感，传递这几个信号：
2、这个事儿能做。 3、这个事情做成了会对客户(我们)有好处。 能不能在需求评审会上把需求说明白，直接决定了后续开发工作是否顺利，因为各种原因，在需求评审中，协作团队会经常跳出来怀疑产品经理—— l 这是不是老板或业务方随意的需求，而你只是一个传递者的角色； l 这是一个确定的用户需求，还是你拍脑门想出来的； l 最关键的，要准备好对这件事情，你作为产品经理有没有想清楚或者为此做过一些准备。 这里说起来有点绕，因为这里才是我们遇见的很大的问题，可以先回忆一下我们评审过程中遇到的一些问题：
为啥会这样，因为呀，你觉得“我比你懂市场，我比你懂交互，我比你懂人性”，其实呢，在很多情况，为啥叫产品狗，就是真的只能汪汪、掌握流程的技术、掌握资源的运营小伙伴对各种水面下的情况真的比你懂。 所以，不管是新手上路，还是老司机开车，最大的问题就是你不是专家说不清楚或没有准备而才被Check的千疮百孔。为了让效率更高，目标明确，我们可以在评审前、评审中和评审后做相应的准备： 1、评审前——做好产品基本功如果是一个商业产品需求，请和你的业务方认真推演产品要解决的问题。注意要提炼出业务方要解决的问题，而不是问业务方“你要不要这个功能？” 作为产品经理，你要相信自己的产品设计能力，业务方提供的产品方案可以作为参考，不能作为指南。 如果一个是工具类的产品或者体验层面的优化，请认真分析各个方案背后的用户心理变化，同时准备好相关数据佐证你的假设。仔细推敲产品方案，是否有考虑过还有其他的方式可以解决问题，不同的方案优缺点各是什么。 提前找到此项目对应的负责人，认真的和他们沟通你的方案和想法，协同的小伙伴们不是被动的执行者，让他们参与到你的前期设计中来。 准备好一份逻辑清晰的需求文档，形式不局限，核心是要表达清楚你的意图。如果之前评审经常出现表达混乱，说的意思别人不容易懂。你可以再辛苦点，准备好一份评审大纲仔细review你的需求文档，是否各个细节都考虑到了，尤其是异常的情况，和其他系统有依赖影响的情况。不然挑刺的的同学会把你问的哑口无言。 2、评审中——注意表达，注意情绪，控制好节奏1）参与评审的技术，他们的关注点可能各不相同。有的擅长剖析你的需求动机业务目标（大部分的技术leader会关心）、有的擅长追求细节（比如设计师、测试同学）、有的喜欢带偏话题（在你评审的时候，可能他们会提一个其他的话题）、也有的喜欢用“教导你”的口吻“教你”做怎么产品。 2）需求开始，可以先讲清楚你的业务背景，确保大家理解的前提下再带入你的方案。然后记得要阐述为什么要用这套方案，而不是其他方案。这两件事情需要在开始就说的很清楚，讲完后可以停顿让大家提业务背景和方案的问题。 这里要掐断那些喜欢问交互细节，逻辑细节的问题。 这一步骤的重点是要说清楚发生了什么问题，为什么这么干而不是那么干—这样不至于在后续的环节里，又有人绕回来质疑你的需求背景。 3）复杂的问题，考虑用一些流程图，再结合“总分总”的方式。可以先说明白整理步骤，先做什么，再做什么，最后做什么。然后再按步骤细评各个环节的细节，都评完后再阐述一下总的流程那样会在逻辑上很清楚。 4）注意话题不要被带偏。在过程中，出现某个同学说“唉，之前有个XX也是类似的问题，还没解决”的忆苦思甜的时候。这个时候作为产品经理，要注意，陪着大家喷3分钟可以，但绝对要及时掐住话题源头，可以说这个问题待会私下讨论。不然你懂得，失控后每次这种会议就是喷公司、喷市场、喷没有资源，喷一切但绝对解决不了问题。 5）你也会遇到喜欢爆粗口的技术。“我操，这有个屁用啊！”“你是不是脑残啊！” 我们要控制好自己的情绪，因为这个粗口的背后，他们想表达的意是：“这样设计是不是不对”？只是加了一个感叹词嘛。听他们把背后的原因说出来，不建议用“为什么没用啊？”“这样挺好的啊”“我靠，你才脑残”来正面回应他们的感叹词，这会让气氛更尴尬，后面的评审更难进行。可以问“是有什么问题吗？”“方案哪里不合理？”来拉上正轨。 7）“这个不好做”、“实现不了的”。遇到技术们这样的回应时，绝大情况下是背后有一个巨大的开发量。不建议直接驳斥“这个还这么麻烦啊？”“很简单的啊，这样搞搞就行了啊”。我们需先权衡是否值得这样的投入？如果的确是一个很重要的业务卡口，可以表达清楚这件事的严重性，就算开发复杂，需要较多的时间也可以接受。 8）做好会议纪要和分发！以便会后跟进讨论和修改！ 3、评审后——保持持续跟进，反复review评审结束不代表就等着上线了，接下来要做的是持续的关注。需要不断的review，确保该表达的细节都有表达：
最后的最后，不同岗位的人都有自己关心的问题，项目成功了，给团队请功加鸡腿，如果项目无功而返，注意调整目标和期望值。加不了鸡腿就加棒棒糖。不要让本次参与者失望。职场上虽然大家都很功利，但还是那几句话： 一.明确需求评审的目标 二.说明为需求设计方案之前的准备工作三.逻辑+模块的表达方式四：追踪和跟进。 一个小小的需求评审会，不是什么难题，还有各种工作的挑战等着你呢！
|
|
|
需求评审会是每个产品想要实现功能落地都要开的会议，在这个会议上产品经理要详细向项目组成员阐述需求背景、需求目标和需求的详细设计。目的是让项目的参与者B端有业务方流程制定者在最小成本下的原型法的尽量确认需求，而大多数情况下(这里主要指研发测试）能够快速理解产品的意图，认可采用大家认可的方案开始准备落地。
