重视需求评审
需求评审重要性
需求评审是项目流程重要环节。从团队角度来看，这是团队成员（特别是产品经理和技术）第一次正式就业务需求进行全方位地专业讨论。经验上来说，这次会议质量直接决定后续需求变更频度。原因一般是产品经理没考虑完整或者部分细节需求技术可行性存在一定问题。
从另外产品经理角色来看，评审会是体现个人能力的绝佳场地，当然也是暴露自己缺点的高光舞台。需求评审会是产品经理的炼金石。在我个人职业生涯初期，每次需求评审之前都像如临大敌，私下会花费大量时间进行排查和演练，以确保顺利通过，甚至还会定下目标，力求需求评审一次通过。
需求评审内容
需求评审具体内容可以划分 3 部分，分别为需求项目背景以及项目目标/价值、项目功能、具体每个功能模版的任务评审。下面具体展开进行说明。
在需求评审上说清楚项目背景以及项目目标的好处在于：让项目组成员了解项目为什么来，将去向哪里。既为后续需求开发优先级提供判断依据，还可以提高各个角色参与感。另外，在会上与上级老板在目标上再次确认，确认对整体方案框架的认可情况，也有利于后续项目推动。
具体评审项目功能是需求评审的重头戏。这部分内容是要讲解清楚具体功能模块前后端流程、逻辑以及确认需求优先级，评估出技术难度、投入产出情况等。这部分评审需要各个部门负责人（类似技术主管、测试主管等）参与，给出具体评估情况。
另外具体每个功能模版任务评审，需要对应到具体各个开发人员。这部分是对具体细节任务开发评估，通过评估这部分内容得到详细项目时间周期。
需求评审流程
在整个评审流程中，各个环节常规流程就不展开讨论，主要阐述一些注意事项。
需求评审之前，可以单独找核心技术人员以一种非正式沟通的方式核对一遍需求，避免技术可行性或者产品方向问题（特别是不懂技术的产品经理或者刚加入团队的新人产品经理）。
评审会议中，产品经理一定要主导，引导各个角色往下走。保证不要偏题，不要拘泥于细节前端样式。并且控制好会议时间，建议不要超过 1 小时。大功能可以拆分为小模块，通过分阶段评审来保证参会人员精神状态。在其他角色质疑产品经理需求价值时，产品经理需要拿出理论、案例、数据任何一项论证方式进行支撑说明，凡是含糊其辞或者顾左右而言他都是令人失望的表现。一定要直面问题。
会议结束需要整理好会议输出。输出内容可以按照需求是否确认划分为两部分：已确认需求的开发周期、排期时间等、对应负责角色人员；未确认需求的确认时间、确认形式等。这部分做起来并不难，但还是提一下，力求做到事事有回应。
整个需求评审会议，可以尝试在团队内部建立标准流程，包含：评审资料、项目干系人、评审角色职责分配、会议步骤、评审通过条件等等。这样更有效率。这里额外说下「评审通过条件」，建议项目干系人可以提前列好各自评审标准，避免遗漏。评审标准可以针对 4 个方面重点评估，分别是：正确性、完整性、可行性、质量 。例如：
- 考核需求正确性
- 是否有需求与其他需求相互冲突或者重复？
- 是否清晰、简洁、无二义地表达了每个需求？
- 考核需求完整性
- 是否包含了每个需求实现优先级？
- 是否定义了功能说明内在算法?
- 考核需求质量
- 各个任务/子任务交互是否合理？
- 各个页面文案是否合理/统一？
- 考核可行性
- 各个字段是否可以获取？
综合来看，一个好的产品经理可以保证需求评审会议不会太差，但需求评审会议质量更高取决于一个优秀的团队。