每次增加新的需求或是功能做变更时
一般的开发流程是：
提出需求（一般是用户或者策划工程师）
讲解需求（提出需求者或者需求工程师对开发者讲解）
开发者理解需求
开发者开发
测试
完成验收。
我经历过的开发基本就是这样的步骤，但是做了这么久开发，我总能经历到这样一个现象：
一般新增需求更明显一些，那就是当讲解完需求后，一般来说很少再开全体会议再次讲解需求了。但是当开发者第一次听一个新的需求时，可能并不能完全理解这个需求，或者需求工程师也不完全就将所有情况考虑到位了；开发者也不可能在听完一次需求会议后就完全理解了需求的含义。
所以导致，开发者在听完需求后，开始着手设计程序，编写代码中，有了需求不明白的地方只好单独找提出需求者求证，而对于那些几个人联合开发的功能就会导致沟通不畅，浪费不少时间进行不断修改。不利加快项目进度。根据我的经验，一般耗费时间较多的就是对需求的不明确和理解偏差导致做了很多事情，结果发现出现了错误，又返回去修正。
因此我觉得，在第一次需求会议后，开发者消化了需求后，提出需求方再进行一次需求讲解。为了避免浪费提出需求者的时间，在第二次需求会议时可以对需求重点讲解，或者专门解决开发者的疑惑。这样比开发者单独求证需求效果要好，因为大家都在一块，对于联合开发的功能在会上就能沟通了。这样开发者对需求理解的好了，就能一次性设计和完成编码，避免了错误，节省项目的时间。一般来说只要再多占用提需求方的一次会议时间，就能提高项目开发进度，我觉得还是比较划算的。
对于需求的理解是关系项目进度的关键，所以一定要在初期将需求讲解明白，理解透彻。
