项目过程要求有设计文档的评审的阶段，但由于成员对彼此的模块不是很熟悉，再加上通过文档来理解别人的设计需要一些精力的，所以最后评审的结果大多是错别字、字体不符合规范之类的缺陷，没有起到真正的对设计评审的效果。
另外，一些研发人员不是很爱写设计文档，总觉得设计文档没啥用，甚至觉得是项目负担。所以常常出现先写代码后补文档的现象。产生这种现象的原因主要是：开发人员没有将两者有机的结合起来，而是把文档编写和编码当成两件独立的事情对待，所以未能体会到优秀的设计文档带给编码的好处。
为了让文档真正的发挥应有的作用，让其能够切实的帮助程序员提高工作效率，采取了如下措施：
1) 思想上
让大家理解“一个设计，如果你都无法用中文把他描述清楚，那你怎么可能用编程语言把它描述清楚呢？”的道理。向大家传递文档的作用不仅仅是为了完成质量管理目标，更是为了帮助我们自己写出更加优秀的代码，减少测试环节反复修改代码的工作量。
2) 评审方式
将文档评审方式由传阅改为会议评审，由模块负责人向大家讲解其设计，大家设计进行提问和评价，对需要改进的地方给出参考意见。
这种评审方式的带来了如下好处：
u 由于每个人都必须对自己的设计进行讲解，所以他会认真的去思考自己的设计，避免出现应付了事的现象；
u 讲解过程也是对设计的再次验证，同时还可以搜集到大家的意见和建议；
u 锻炼研发人员的表达和沟通能力。
通过这样的评审，项目成员基本都能逐步认识到编码前设计的重要性，特别是在评审过程中发现重要缺陷的人员。因为大家能够意识到如果这些缺陷被推迟到测试阶段才发现的话，那么自己的模块将会出现很多bug，而自己将会面临很多修改代码的工作，同时过多的bug数量还会影响自己的考核。