项目开发系列 -- 需求评审

      今天进行了传说中的需求评审。开始以为是一群大BOSS坐在那里挑我们的毛病，没想到是一个极度轻松和OPEN的过程。总结下一哈：

     首先，需求评审的参与者是PD，PM，需求方和项目小组全体成员。目的是对需求方提出的需求进行确认和补充。大致的流程是：需求方给出一个大概的轮廓，开发团队提出自己的想法，然后咨询需求方这样是否满足了需求。在这个过程中，可以顺带解决两个问题：一是统一了项目组内部的想法，二是使需求尽量详细，避免以后因为需求问题导致的变更。

     在对PRD文档进行提问的时候，作为一个有经验的开发人员，要问一些有“技术含量”的问题：

1.未雨绸缪，考虑产品上线之后会产生的问题。如产品对并发的要求，以后是否会有扩展，是否需要升级服务，需要长期维护？

2.高瞻远瞩，考虑全面。如划定系统的涉众，具体实施过程，必须要遵守的规则（高压线），最后的期望产出物。

3.向直接使用者提问。在他们那里可以改善一些很“蹩脚”的需求提案。而且可以询问一些以前类似系统的使用情况，对即将做的产品有更直观的了解。

4.做任何决定都要有书面记录。比如需求评审开会时一定要指定两个书记员，记录需求的更改细节。需求评审结束之后要对本次评审进行总结，并整理一份完整的需求文档出来，给今天与会的人员每人一份。而且此需求一旦制定，以后最好不要再去修改。

5.充分考虑到项目风险。在评审会议上，要收集和公布所有的风险和应对措施。这样以后出现风险时不会太慌张。