理念四：指标也有生命周期，需要演进
软件业界中曾流行过的CMMI和敏捷流畅度模型等，都是依据演化的思路。组织的不同形态对应着不同的阶段，在软件研发的演化过程中因为加入了许多的变量，指标本身也是有着生命周期，需要演进的。
在2020年3月出版的《谷歌软件工程》中，谷歌将整个软件生命周期的度量管理分为了两部分：
- 一是研发阶段的工作（代码上线及上线之前），这部分主要由 Product Team 负责
- 二是运维过程的工作（代码上线之后），这部分主要由 SRE 负责
在研发阶段工作的度量就由项目的PH(Project Health)值来进行度量。它取代了之前谷歌使用了八年的Test Certified(2008～2016)，一个很重要原因是，TC标准是静态的，当团队达到某个级别以后，就没有再进一步的动力提升级别，甚至项目实际情况已经降级了。这和业界中许多组织过了CMMI3评级后就一直停滞不前，甚至倒退的情况有些类似。
说说冒烟移测率
在我参与的度量体系搭建实践中，就曾有冒烟移测率这个指标。指标初始设定的原因，是因为有些团队开发提交测试给测试团队时的质量过差，导致测试团队的资源消耗过多，且缺陷的修复导致项目周期较长，在以提升开发团队质量内建能力的前提下，此指标可作为核心指标。
在持续观测了一段时间以后，提测质量守护的情况在有些团队已经稳定且基本为100%，若再持续观测此指标意义就不大，就可以把此指标放入监控指标中。
在之前，Agilean也提出过一个研发效能提升过程中指标演进路线图（文末推荐阅读有链接），供大家参考：
问题5：我们这里不管用什么指标，下面的人总是要做数据，那要指标来有什么用呢？
理念五：不能因噎废食
钱塘莫美于西湖，金陵莫美于后湖。
南京城里的后湖由于其得天独厚的优势，“周遭四十里，中突数洲，断岸千尺”被明朝设为黄册的存放地，也就是国家绝密档案库，当时的天下郡、县编制赋役都存于此，甚至有了“黄册、里甲制、鱼鳞图册在手，天下透明”的说法。
图 / 南京后湖，来自Pixabay
朱元璋为了让黄册可以得到很好的防护，可以说是殚精竭虑，整个玄武湖被整整封锁了近300年。结果呢，为了修改里面的数据，下面的人想了无数的方法，最狠的一招，是本来使用黄檗汁来做染黄使书籍防虫，被人替换为石黄，招致蠹鱼把黄册直接给吃掉了，神不知鬼不觉的把数据给消失掉。
所以，一旦涉及到利益时，人类的想象力和智慧是无穷的。上头有多少条政策，下面就有多少条对策。汉代搞案户比民，民间就敢舍匿虚田；隋唐有大索貌阅，民间士子就敢冒籍取解；宋代搞衙前差役，老百姓就会析居避役、鬻田减户。
同样的，研发团队要是按照代码行数来统计员工的奖金，那代码的隐形技术债估计也不会少。
从数据运营角度说，我们看到的是趋势，分析的是异常，开放性系统中我们一般会经历以下三个阶段：
阶段一：部门内部的数据共享
单个研发部门内部的数据收集及趋势呈现，有助于CTO改善部门内的管理方式及提升部门研发能力。
阶段二：组织内部的数据共享
组织内部各个部门研发效能数据的共享，可以在一定程度上透明化组织的整个研发部门数字化运营能力，有利于组织从全局层面做资源规划和分配的决策。
阶段三：跨组织的数据共享
研发效能的兴起加上标准的制定，不同组织都开始有意识的收集自身组织的数据，随着有效数据的清洗和治理，之后同行业之间就可以达到数据共享及行业的趋势预测。
德鲁克说，管理的本质，其实就是激发和释放每一个人的善意。
用数据来说话或者数据驱动是为了消除主观偏见，更多的人能在更短的时间内达成共识。
不排除在实际操作中我们因为某些原因在某一个阶段设定了一些不合理的指标，小步试错，指标的设定也是有假设-验证-修改这样不停迭代的过程。
问题6：我是搞度量的，公司的度量体系也搭建了，数据也收集了，接下来明年还能规划个啥呢？
理念六：情景化度量而非控制型度量
下图是一个团队的时效图，从图上你可以看出什么呢？
不同颜色的线条表示不同的前置时间，从图中可以看出，深蓝色最上面的那根时长是在增加的，而由上往下的第三根浅蓝色的线条时长在减少。对应的表示整个团队的研发时效在增加，而需求排期的时间在减少。
如果你不是团队的成员或者你完全不知道团队的情况，你可以知道这样变化的原因么？
大家说，我可以推测呀。
是的，假设-验证-反馈是一个科学化的正向反馈循环。
Keniberg提出过一个数据的验证模型DIBB，即DATA-INSIGHT-BELIEF-BET。从客观数据出发，激发洞见，设定假设，运营验证。从度量的方式来说，我们就是通过数据治理的方式来做组织的研发数据运营，帮助组织实现数据驱动的持续改善。
在日益复杂难测的组织环境中，管理者们可以看到，完全是流程性的从上而下的命令-控制性管理方式已经开始褪去光环，来自于军事领域的Mission Command管理方式更适合现今不确定性较高的组织管理领域。
我们可以从不同的团队数据中，得到不同的团队数据特征，并不要求所有的团队展现出来的都是一样的数据行为模式。当然，要选择控制型度量还是情景度量的判断因素可能有：
- 组织中的员工能力高低
- 组织的目标是防范错误还是创新
- 组织中的决策模式是中央集权还是高度分散
- 团队的价值观是否一致，是否易达成共识
我们观察到组织的研发效能度量可能会经历4个不同阶段的流畅度，流畅度是指某个组织在面临压力时研发效能度量数据可视化呈现的方式。如果有足够的时间待在课堂里，每个人都能做到遵循一系列良好实践，但真正的流畅度是一种有技巧的日常实践，即使当你为其它事分心的时候，这种流畅度也不会离你而去。
对于研发效能度量来说，我们更关注于团队的研发效能度量流畅度，而非个人流畅度。
而团队的流畅度则更多地取决于团队中每个成员的能力，也取决于管理结构、关系、组织的文化等方面。请别误会，这并不是说团队的流畅度低下要归咎于个人，也不是说一个高水平成员的存在就能够保证整个团队的流畅度。
