关于两者之间的关系，我是这样理解的。质量是我们的根本要求，离开了质量其它就不用谈了。效率则是提高质量的关键。项目开发总是受到进度、人力等各方面资 源的限制，只有效率提高了，才可以取得最好的质量。离开质量这个根本空谈效率是没有意义的，没有好的效果，效率只会是一种浪费。

　　那么什么是高质量，它的标准是怎么样?以下几点应该可以作为一种标准

　　缺陷率低

　　代码的结构良好，可重用性、扩展性好

　　代码的可读性强，易于维护

　　丰富的维护手段，可维护强

　　目前项目组中存在那些不足呢?大概有以下几个方面

　　一些模块的封装性不好，与其它模块耦合度比较大，这导致代码的可移植性不好。

　　软件的维护手段不够，出了问题很难定位。

　　资产管理做的不好，以前积累的技术输出没有专门的管理，时间久了就流失了。需要的时候也很难找到。

　　小特性开发后，没有相应的功能和设计说明文档，不便于其它人员了解特性。

　　其它产品发现和解决的问题，没有及时同步过来。

　　分析设计过程中，方案讨论、检视的投入不够。导致特性开发的设计不够好。

　　一些工作改进的思考

　　为什么要强调特性设计文档?没有设计文档，开发人员的设计思想就无法传承。后继的开发人员通过代码很难完全理解前人的设计。那么开始设计好的结构就很可能被破坏。其人开发人员不容易维护。

　　还需要调试和维护指导书。特性开发人员自己在调试和问题定位的过程中，会形成一些调试方法和定位问题的思路。这对于特性的维护是很重要的。目前这部分的知识还没有能够记录下来。可以通过调试和维护指导书的形式将这部分的知识记录下来。

　　在目前的特性开发流程中，具体开发人员由于受能力和知识的限制，在设计中常常无法考虑的很周全，只注意到了功能的设计，忽视模块化、兼 容性、扩展性方面的考虑。项目组有经验开发人员的经验的能力不能为这些特性开发做出足够的贡献。一方面是由于受时间的限制，无法投入足够的精力。另一方 面，所提出的建议无法对特性开发人员产生约束。为解决这个问题，可以考虑在开发流程中增加一个环节，来专门检查设计的模块化、兼容性、扩展性。可以做一个 checklist，只有全部通过了，这个设计才可以通过。

　　为什么我们的根因分析总是流于形式?大部分问题的根因还是会归根于项目组日常管理工作的不到位。如检视投入不足，受技能水平的限制等。解决这样问题的关键还在于改善项目组的日常管理工作，否则，同样的问题还是会发生。

　　资产的管理也是一项比较重要的工作。一方面要输出各种文档，另一方面要加强对文档的管理。现在存在的问题是，随着时间迁移、组织结构的变化证这些文档资产渐渐的遗失了，相关的开发人员不知道这些文档的存在，更不用说去找了。

　　提高质量和效率或许都可以看作是一个目标，一个结果。重要的还是要关注项目运行的过程，既包括开发的过程，也包括日常工作的过程。对项目经理来说， 一个特定问题的解决常常并不困难。而项目经理面对的往往是一堆的问题，这些问题放在一起，就会变得纷繁复杂。项目经理的资源又总是有限的。如何找到关键问 题，并将改善工作有效的落实下去，才是需要一些智慧的。