作为项目经理来谈谈需求评审

原谅链接：http://blog.chinapm.com.cn/u/ucwxy/1748.html

1、不同类型的需求是否由不同的职能角色同学来负责编写更合理？

   * 一般情况下更建议技术优化需求由研发同学负责编写。展现的形式可以是需求文档，也可以是技术方案，技术方案一般会涵盖了需求、技术框架、接口协议等描述（有些时候，没必要把需求和设计分那么开）

   * 虽然有些技术优化需求不是产品同学来写，但是每个版本要做哪些需求，都应该由产品经理来统筹和拍板

2、如何有效的召开需求评审会？

   * 首先你要了解如何组织高效的会议

   * 其次才是软件产品的需求评审

   * 是产品同学去讲解需求，还是研发同学来讲解需求，产品同学来纠正和补充（反正这些在我们过去都有尝试过）

3、下版本的需求评审工作应该放到什么时候最合适？

   * 2、3个研发人员规模的小项目，是否串行迭代更合适，就是说上个迭代发布后再开始下个迭代的需求评审，但是需求文档可以提前尽早发出，以方便研发同学在提测版本后的空隙时间去预审，测试同学在某轮次测试完成等待研发修改bug再次提测的空隙时间去预审

   * 越复杂的项目团队，是否要比当前版本发布时间提前1-2周完成是最好的安排？

   * 外部关联需求越早评审越好

4、需求评审是否要分成需求框架和需求细节等不同层次的评审？

   * 以前在乐园，分需求初评和需求细评，你对应的团队是否也需要这么弄呢

   * 框架评审和细节评审的会议参与人员如何考虑和安排

5、需求文档写到什么程度才是合适的？

   * 对于进度要求更严格、版本质量要求更高的产品，需求文档偏向于更详细具体一些

   * 对于关联需求，关联业务流程和协议偏向于描述更细节一些

   * 需求文档是为后面设计、编码、测试工作服务的，同样也是今后新同学了解业务的途径之一。那么文档如果能满足这2个条件，就合适了  

6、项目经理是否需要参与一个版本中所有需求的需求评审？

   * 核心需求、关联需求、复杂需求一定要参与评审 

   * 根据团队的成熟度灵活判断，越不成熟的团队，项目经理需要投入的时间和精力需要越多  

7、是否所有需求在评审前，都需要有预审？预审中发现问题后要怎么处理？

   * 什么情况下的项目，不用预审，直接组织团队召开需求评审会会更合理（一些简单的后台业务，我觉得可以不需要提前预审，但是复杂需求一定要提前预审）

   * 如果大家都没来得及需求预审，需求评审会议是否要考虑推迟

   * 如果安排需求预审，那么一般要在需求评审会议前提前多久发起需求预审

   * 预审阶段发现的问题和疑问，是等到评审会议上再去沟通还是评审会议前沟通清楚更合适（一般要会前沟通清楚更合适，以便需求作者评审会议效率更高）

上面的每一个问题都可以展开去耗费大量时间来讨论，而工作中你会遇到不同 业务类型的项目、不同 复杂度的项目、不同的 团队氛围、不同 性格的人、不同 能力的人、不同 重要性的项目、不同 成熟度阶段的团队等等，还有好多其他很多项目相关的因素，比方有些业务是创新业务，而有些是收尾业务等

你常常会听到做项目管理需要有灵活性。可能你当时不能理解什么是灵活性。单纯从需求评审这个事情来看，能灵活的、高效的开展是需要对应的知识结构的，否则你是很难做好移动互联网业务下的项目管理工作。所以，灵活性是在不同情况下你都能用最合适的方式去推动项目工作的进展。『 灵活性确实是一种综合能力的体现』