现在问题来了，虽然他花费了心思去设计的流程。并对于需求部门和相关部门组织了培训。可是在进行试点的时候，他发现，当他去评审需求分析组的工作时，别人很反感。而且对于有些需求的变革也推诿到销售人员、客户等因素。同时，流程中只要有一点不太合理的地方，就抱怨的很厉害。最后试点结束，他自己很累，试点的结果也不好，改善的目标没有实现。整个过程的改进处于一种微妙的处境。最后，试点的流程并没有推广。其他的KPA过程改进也不再进行了，随着时间的推移，过程改进在企业中也不在有人提起。知道这位开发组的主管错在哪里吗? 他选错了KPA，他选了一个不属于自己管辖范围的KPA作为起点。他跑到一个不属于他的地方开始指手画脚，他是个不受欢迎的人。注定了，在一开始他就面对着对立和抱怨。这样的团队是无法经受一点点挫折和失败的。若他一开始选择配置管理，这个至于他管理范围的KPA，他可以利用手中的权利、资源和威信，组织试点。可能情况就好的多。 又或者企业的高层给这个开发主管一个虚职，比如过程改进项目组组长，并任命其他组的组长为过程改进项目组成员。情况也会完全不同。
对于过程的改进要有度量。不必一开始就是数字化的，也可以是感性的体会。但要把这些也要收集起来。 一个有力的对比可以堵住反对者的嘴。不要因为度量管理是CMM4级的内容就在实施低级别的CMM时放弃度量。一套流程需要一系列度量的数据来说明它改进了多少。而度量的数据将会为它赢得预算和支持。当然度量作为CMM4级的内容，也是有一定的道理的。收集一套完备、准确的度量是需要大量人力的。但是在一开始，也许我们可以借助一些好的工具达到同样的效果，而不必花费大量的时间和精力。在我就自己做过一个简易的BUG管理工具，并和数据库相连。在项目结束时我可以轻易的了解项目中有多少BUG、BUG分布如何，BUG的原因统计等度量数据。我只是用了几个SQL语句就掌握了我需要的度量。
文章来源于领测软件测试网 https://www.ltesting.net/