关于需求评审的想法

熊点心

以前项目组没有评审的环节。为了新项目，最近已经试点了2次。有些感触、想法，不知道实际会怎么样。
1、评审前，对需求文档的阅读很重要。提高工程师分析能力应该在平时开始。
   现实中，工程师的能力一定有高低之分，除了从阅读时间上入手，还可以提供其他辅助。
   比如，需求文档阅读的检查表，提醒工程师要注意的内容。
   eg：数据格式是否描述清晰、限制条件是否描述清晰、业务流程图前后切换是否描述清晰、界面默认值是否描述清楚。。。。

2、提前培养评审主持人的控制力。
   因为团队中对质量有所认识的人太少，所以必须先保证有质量和管控力的人手是足够的。
   对此，试点时，我们已经安排其他有管理职能的人员参与试点，开始灌输评审的核心目的和要注意事项。

3、经过试点，对以下问题进行了强调
1）我们采取方式：负责开发需求的工程师逐行逐图描述自己理解的需求。评审员发问。
2）负责开发需求的工程师自己记录不明确的疑问。
3）讲述人和提问人要清晰说明页数、行号、图编号等信息，同时指出位置。提示评审员
4）主持人要有管控力。必须阻止扩散性讨论，紧密围绕需求确定明确or 不明确。
5）时间控制在1-1.5小时