37 | 如何做好需求评审（上）：需求评审不只是一次会议

感谢二爷的良苦用心。 之前遇到这些困惑，的确是自己对于产品工作或是需求评审这件事的重视程度不够，在自己尚未准备充分或是考虑清楚的情况下寄希望别人来共同参与，这是不负责任的表现。作为产品经理，首先要认真做好自己的本职工作，从二爷提到的很多细节上，我还有很长的路要走。 能够清晰、完整地将自己的业务流程和逻辑具象化表达，并且让大家统一思想，提前沟通，这本身就是对产品经理的综合考验。 我真心认同二爷说的「需求评审应当是凯旋的钟声，而不是冲锋的号角」。两者的差异可见一斑。 年前经历的那次需求评审并不完美，时间紧迫，只好提前用正式机会和大家沟通，这就造成很多不确定性，这是我体会最深的。希望年后回来能够认真做好每一件小事。 感谢二爷的辛苦付出，提前祝大家新年快乐，万事如意~

二爷，一个to B的小硬件公司(30人以下，也有软件和云服务)，只有需求方和开发团队，需求方是商务总监和销售，开发团队很少第一线与潜在和已有客户沟通（唯一直接接受客户反馈和投诉的工程师快自己蜕变和被定位成支持工程师了)。最近请了一个做过硬件行业品质和项目的资深经理担当项目经理的角色，他对软件开发了解得比较少。这种情况下除了空降外，什么样的人，或现有的团队和角色里，谁比较适合当或发掘成产品经理，原因是什么。如果外部空降是更好的解决办法，看重候选人的哪些特质，技能，过往经验，现有公司从哪些方面支持他更有助于他融入和为团队贡献价值。 这个话题有些大，二爷能回答一两点我也很感激😀

很想交流一下。 我不是产品经理。最早是测试工程师，现在是项目经理。 深深认同二爷的这两个观点：评审的四个目标和手段是为目标服务。评审会能不能开好，就看是否达成这四个目标。 然而，现实情况是需求评审会很不容易开好，一旦有某一方掉链子，会议效率低下还是轻的，重则研发过程中天坑滚滚。 在遇到各种问题之后，我们制定了评审会的几个重要原则：1.重在评审，不能开成培训会；2.产品经理必须在会前和需求方充分沟通，确保可以实现业务目标；3.大需求必须在产品框架方案构思阶段和技术负责人沟通，确认可行，并且实现成本尽可能小；4.大需求必须和业务负责人就方案达成共识。 此外，我们还围绕会议效率和质量定了一些细则要求。 最近几个月，我们遇到了一些糟糕的情况，因为需求方调整了策略或者当初没规划清楚功能的使用，花费大量资源开发出来的一些功能基本不使用，甚至搁置未用。 这对团队造成了极大的伤害。我们因此做了一些调整，在需求评估阶段，产品经理要合理评估需求的价值，需求方要阐述清楚未来使用该功能的规划。如果产品经理或者产品团队不具备可以评估需求价值的能力，依然有可能会存在这种问题。

今天的分享中关注到两个关键词： “冰山一角”，不能局限在一个流程切片的角度去理解需求评审。这让我想到足球比赛中的“临门一脚”。这一脚固然精彩，但更重要的是之前的传接配合。首先要在会议之外下功夫，会议才有达到预期的可能。记起在之前的分享中学到的，非正式沟通是会议之外很好的补充。 “意外”，生活中意外有可能是惊喜，而项目中的意外往往相反。面向两个角色，做四件事情，目标就是统一期望值，让产品在需求方和开发团队的脑海中的形态统一。第一步尤其重要，可以通过之前关于需求变更的分享中提到的“五问法”，挖掘背后真实的需求。 我作为前端程序员，其实也可以从自己的角度出发去促成与产品经理的沟通。比如，可以主动一对一跟进，了解需求背后的缘由，以及需求文档上自己需要重点关注的地方。 谢谢二爷分享，春节快到了，提前祝二爷和一起讨论的极友们新年快乐。

会而不议 可能是需求评审的最高境界了吧，所有问题都在事先沟通解决了，会上只是大家一起确认一遍，而不是讨论需求，更不是读需求

学到的最重要的一点是，完成需求搜集和分析后，产品经理要事先与相关人员沟通。再有，要提前发出需求评审的材料，让大家提前熟悉评审内容。但不能只是笼统发出去，要指出不同人需要关注的地方。

文档发出之后一对一进行指导和跟进，这是一个站在对方角度去高效处理问题的好方法，学习了。其实需求评审应该是个很高效的达成共识的会议，总结过往展望未来，很有必要。

需求评审，让大家知其然并知其所以然，建立相关方对产品的生产的参与感，这样大家做起来要有意义和成就感一点。

讲的很细，虽然我只是一个程序员，但是听过之后对产品经理工作更加理解了