今天进行了传说中的需求评审。开始以为是一群大BOSS坐在那里挑我们的毛病,没想到是一个极度轻松和OPEN的过程。总结下一哈:
首先,需求评审的参与者是PD,PM,需求方和项目小组全体成员。目的是对需求方提出的需求进行确认和补充。大致的流程是:需求方给出一个大概的轮廓,开发团队提出自己的想法,然后咨询需求方这样是否满足了需求。在这个过程中,可以顺带解决两个问题:一是统一了项目组内部的想法,二是使需求尽量详细,避免以后因为需求问题导致的变更。
在对PRD文档进行提问的时候,作为一个有经验的开发人员,要问一些有“技术含量”的问题:
1.未雨绸缪,考虑产品上线之后会产生的问题。如产品对并发的要求,以后是否会有扩展,是否需要升级服务,需要长期维护?
2.高瞻远瞩,考虑全面。如划定系统的涉众,具体实施过程,必须要遵守的规则(高压线),最后的期望产出物。
3.向直接使用者提问。在他们那里可以改善一些很“蹩脚”的需求提案。而且可以询问一些以前类似系统的使用情况,对即将做的产品有更直观的了解。
4.做任何决定都要有书面记录。比如需求评审开会时一定要指定两个书记员,记录需求的更改细节。需求评审结束之后要对本次评审进行总结,并整理一份完整的需求文档出来,给今天与会的人员每人一份。而且此需求一旦制定,以后最好不要再去修改。
5.充分考虑到项目风险。在评审会议上,要收集和公布所有的风险和应对措施。这样以后出现风险时不会太慌张。