场景： 与某公司做完差距分析后——
当说到公司最大的改进点是“度量与分析” 时，主管们都同意公司要量化管理。
我举例说，可以先从现有数据入手，用缺陷排除率来看整个生命周期的缺陷。识别缺陷都出自哪个阶段？是否可控？
问：验收阶段的缺陷情况如何？
答：极小，大部分的缺陷是在单元测试。
如果确实如此，那是相当不错了——缺陷最好在发生阶段就被消除，比如大部分已经在代码开发后的单元测试就发现和解决。
然而在和主管讨论到开发团队主要的痛点时，他们提到维护软件是一个头疼的问题：在维护时，为了找出、排除缺陷花了很多力气——因为对软件不熟悉，必须依赖有经验的开发工程师投入大量精力，导致这些有经验的工程师没有空去开发新的产品，这也非他们所愿。
所以说验收测试阶段缺陷很小并不能说明什么，当时没有用心去找的后果是缺陷在维护期仍然需要解决。其实他们还是不少缺陷未被发现，而遗漏到后面。
原因何在？
基于以数据说话的原则，我接着问：整个过程中，是否有数据支撑？
大主管回答：这个不需要什么数据，原因我都很清楚——很多需求比较复杂的，都是来自少部分客户的定制 / 特殊要求。
从刚才的谈话，你也发现很多决策其实都是大主管说了算。
我们一直强调数据是用来帮助我们做决定的，如果有相关的数据，比如：在特殊需求方面的维护成本是多少？以前是否有出现过这类需求？特殊需求是否可以避免？
有了数据的支撑，开发人员 在设计或电脑编码阶段才有动力 提早发现并解决缺陷，也可以让相关的团队成员真正了解问题所在，也能参与这方面的讨论，反过来如果没有数据来支持，最后就是大主管一个人说了算，负面影响了工程人员的积极性。
后记 大家抱怨遇到的困难很多： 没有数据支撑导致决策没有方向，是很多规模扩大中的公司的痛点。 所以我们现在为客户做咨询，都不是直接扔一堆标准模板和过程，而是要求客户召集团队所有相关岗位人员，依据现有的东西和客观数据，一起讨论、预定如何改善。这样才能够有持续改善、提升的生命力。 联系我们
- 配置管理不好而导致代码错误；
- 代码开发交付的质量问题；
- 项目管理不规范.......等等。
我问有没有一些相关的统计数据？
他们没有，因为没时间收集。
我便问，既然你没有数据，如何可以把这些的问题正式汇报到管理层？
这位抱怨的经理，其实已经经历过两次CMMI的评估，跨越了8年时间。当其中一位专管公司资质认证的90后员工，提到ISO9000很难学。而这位经理说，ISO9000太容易了。其实很多认证的标准都是基于戴明环的持续改进概念。
这位经理在进入软件行业之前，在制作业做过流程，也在软件公司担任过项目管理，用过很多CMMI的最佳实践来编写项目计划书、设定里程碑、监控等。她从自己的经历中融会贯通，理解了CMMI而不是只懂一些理论。
正是这样的经历，促使她希望在公司里其他经理中推动这件事，以便能解决大家工作中遇到的各种困难。
而目前最大的挑战是，其他管理者或者做开发的人，要有这个意识。
任何改变都是困难的——人都喜欢遵循自己熟悉的做法。即使是一个小小的报销流程信息化，都会有很多反对的声音。
必须领导决心推动，才有会结果和效果。
首页
课程
文章
电话咨询