下面谈谈我学完后简单的几个应用吧，有觉得不错的，也有执行不够理想的。

　　一、 质量检查表的应用

　　随着软件业的发展，软件开发早已脱离作坊式。虽然本人所在的公司在开发方面管理不够规范，也基本上还是有一定的流程，从功能人员与用户沟通需求形成用户签字的需求确认文档，基于此文档讨论后，系统设计人员形成系统设计文档，测试人员产出测试用例文档，经过讨论确认后，交由开发人员开发，完成后首先经过功能人员、系统设计人员检查，然后提交测试人员测试。整个流程，相信大部分软件开发团队都能接受，但问题在于这中间参与的人员太多，按黑话说干系人，沟通在PMP中很重要，很多大侠都有论述，当然这里面就不讲了。

　　我们面临的问题是，经常大家之前都讨论好了，待最后开发人员开发出来后，总会出现测试人员测出一堆的问题，开发人员总会说这些之前都没有在需求文档那个中提到啊，而测试人员则认为这些应该是潜规则。实际上就是大家在讨论的时候，可能都觉得理解，但是没有明确一个验收标准，开发人员按自己的理解把主功能给实现了，功能人员、系统设计人员在看到主要功能完成后，也就满意。然则测试人员可能会考虑的更细致，与其他系统、其他模块的关联等。最后就是测试人员跟开发人员打架。

　　鉴于这种情况，我们想到是否可以把质量检查表用上呢。在前期开会的时候，我们就把大家的验收标准一条一条写下来，形成一个检查表。开发人员需要按照这个检查表自测，功能人员、系统设计人员按这个检查表检查实现情况，测试人员的测试用例要围绕这个检查表，对于检查表之外测出来的东西，优先级自动降低。经过多方妥协，这一方案基本得到大家认同。

　　这个办法的好处是，可以让我们在前期就列出来我们关心的主要功能，至少我们交付的产品主要功能是通的。当然缺点也是显而易见的，因为我们很难在一开始就把所有值得关注的东西想到。所以这也需要结合组织过程资产，多一些积累，可以慢慢改善。

　　二、 待办事项清单

　　相信每个项目管理者都关注很关注，项目成员是不是清楚自己的目标，什么时候能达成目标。在我所经历过的团队，经常遇到这种情形：在项目初期大家都觉得时间还很遥远有一些轻松，待到临近项目结束，可能又不知道该做什么，开周会不知道要讨论什么。其实我觉得周会的一个重要目标是应该形成一个下一周的阶段目标，让项目成员清楚我们的待办事项，这就是我所说的待办事项清单。这个清单应该在项目启动就形成，根据规划渐进明细的原则，在项目的进展中，不断更新完善，并明确责任人、期限。这个待办事项清单，换句话说也可看做是工作分解结构的一个平面展示，不过个人感觉这更能让项目成员明确自己近阶段的目标。

　　这个工具非常好，可以让项目成员一目了然当前的重要事项，自己要做什么，尤其在项目接近尾声，可避免遗漏重要事项。

　　三、 不让犯错

　　老师在解释质量保证时说过，就是我们按照这个规定的流程去做，理应是要得到正确的结果，忘记原话怎么说了。也有一位管理培训师讲过，放错不是员工的错，而是管理的问题，流程的问题，因为给了员工犯错的机会。如果他想犯错都很难的话，那这个管理就很高了。秉承这个思想，改善我的系统设计思路。在IT界总是有一批技术人员在探讨哪个框架好，哪个框架新。在我看来如果这个框架可以让开发人员少编码、少犯错，那这就是一个好的框架。基于这个思想，我在现在公司设计的一个功能，基本上80%的业务需求只需要简单配置即可实现，虽然还没有达到零编码的境地，基本上也算得上是我目前最满意的一件作品。

　　似乎这一条跟项目管理没有啥关系了，我这里想阐述的是，项目管理思想也可以指导我们干技术活：)