最近几年“软件研发效力”成了业界的热词，频繁呈现在各个行业大会，被各大厂、传统行业数字化部门、谋求高效能的团队一直的提及并迭代，比方阿里的效力改良 211 愿景，腾讯的智研平台，百度工程能力白皮书。
那么为什么软件研发效力会成为热词，有哪些适合的软件研发效力指标呢? 本文想尝试答复这两个问题，并尝试构建一个依据团队上下文的软件研发效力举荐指标图表，同时介绍一些理论度量指标的案例。
一、为什么软件研发效力会成为热词？
咱们先看看现有的问题，与传统制造业相比，软件研发行业还很年老，并没有达到传统行业的大规模流水线的生产方式，这解释了为什么没有一种对立的，被宽泛认可的办法来掂量开发人员或研发小组的效力。研发效力的度量很大水平上取决于公司的类型，规模，文化，与之单干的我的项目类型以及其它诸多因素。甚至某些小而精，依附聪明才智和资深教训的守业团队，不必度量研发效力，团队仍然十分高效。
很显然，10 年前应用代码行数 (Lines of code) 来度量研发效力的形式曾经不实用古代麻利过程对软件研发的了解了。以前关注代码产出，而不是业务成绩，以前关注集体绩效，而不是团队效力。例如: 随着公司和开发人员向着价值驱动和基于团队开发方向的转变，代码行数不再具备任何意义。100 行代码是否比 20 行好？行数是否通知你获得了良好的停顿，还是只是一个没有上下文的形象指标？软件企业都在寻求其它无效的指标来度量研发效力。
同时，现在的软件行业曾经不再是“以大吃小”的时代了，而是转变成了“以快吃慢”的时代。对于很多大型软件企业、传统行业的数字化部门。本来“大”是劣势，当初却陷入了“大船难掉头”的难堪。如何破局？研发效力具体来讲就是从需要转化成软件或者服务的能力。改善研发效力从某种方面也在试图解决“大船难掉头”的难堪。
研发效力试图在解决度量和让研发变快的问题，那为什么会成为热词? 为什么最近几年各大厂、传统行业数字化部门、谋求高效能的团队，都纷纷开始在研发效力畛域发力，我认为这背地的起因有以下四点：
- 从内部技术视角来看：研发效力的土壤和环境曾经就绪，相似高速移动网络的遍及为智能手机和 App 培养了土壤和环境。4G 挪动网络的遍及，让人们能够不便、疾速的接入互联网，为智能手机和 App 铺好了路。古代软件研发的各个环节曾经全面数字化，为研发效力的数据收集和度量做好了筹备。比方: 电子看板治理工作状态，可数字化团队合作状况。Git 等工具治理代码提交，可数字化开发过程。继续部署流水线治理公布过程，可数字化公布状况。DevOps 云上编排、监控，可数字化产品运行状态。
- 从组织外部视角来看：很多公司都有“谷仓”(The Silo Effect)，随同着市场竞争的日趋激烈，“谷仓”效应越发突出，局部优化然而无奈全局优化，破局“大船难掉头”的难堪势在必行。开发到测试的连接实现了优化，然而当用户需要被设计好当前须要很长时间能力传递到开发，当产品上线后，线上问题须要很久能力从运维传递给开发并修复，影响了全局效率。基于合作流程的优化，突破流程中的“谷仓”，去除不必要的期待，让价值流动快起来，也是研发效力试图解决的问题。
- 从公司业务视角来看：组织倒退规模化，技术驱动商业差异化，然而 IT 交付工厂化，难以应答市场的疾速变动。传统企业对于 IT 投资，谋求 ROI 最大化以及交付过程的透明化，从而缓解市场带来的压力，晋升差异化竞争力。研发效力度量的外围是提供数据撑持这个指标的达成，基于数据继续改良。
- 从内部资源视角来看：以前业务的疾速倒退靠烧钱、人海战术换取更快的市场占有率，从而达到赢家通吃。那时候关怀的是软件产品性能产出，研发效率能够用人、用钱填上。然而随着工夫的推移，还有这么多从业人员可填吗？即使有了这么多人还能砸这么多钱吗？每年从事软件研发的毕业生无限，然而行业对人才的需要从没削减过，当抽干一线城市的人才，各个大厂曾经开始热衷去二、三线城市的大学招人了。同时，随着产品利润的降落，须要更多的获客，回馈客户，须要开始节流了，节流就是研发效力的晋升，同样的资源，同样的工夫来取得更多的成绩。
二、有哪些适合的软件研发效力度量指标呢?
下面根本答复了研发效力为什么会成为热词，那什么才是软件研发效力中适合的指标呢? 要度量哪些指标和数据呢？依据不同的场景和指标人群须要给出相应的度量指标。正如《要害对话》中倡议的，须要依据信息接收者的趣味点来构建沟通策略和沟通内容。从研发效力 DevOps 角度《Accelerate》这本书给出了 4 个指标和评估规范。研发效力是一个比拟大的话题，如何依据不同的关注点，给出不同的指标呢？Roy Osherove 的“Lies, Damned Lies, and Metrics”也给出了很好的归类。依据咱们在我的项目中的理论应用和经验总结，这里把以后罕用的度量指标归类如下：
2.1 布局进度：评估进度，获取背景信息和上下文，晓得工作何时实现，预测问题（将来），对问题复盘与回顾（过来）。
- 燃尽图 (每个迭代 / 每个公布)（Burn down chart sprint/release)
- 速率图 (Velocity chart)
- 标准差 (Standard deviation)
- 吞吐量（Throughput)
- 累积流程图 (Cumulative flow diagram)
- 管制图 (Control chart)
- 看板 在制品限度图 (Kanban WIP board)
2.2 疾速反馈：继续集成，继续部署。
- 构建与部署速度 (Build & Deploy speed)
- 测试速度 (Test speed)
- 代码签审时长 (PR approval Time)
- 单元测试通过速率 (Unit tests passed)
- 集成测试通过速率 (Integration tests passed)
2.3 团队转型：应用特定指标来掂量不同工作形式的办法，能够影响行为，帮忙扭转人们的行为形式。也能够向管理层阐明某些事件不合理，须要扭转，或者阐明须要更多的工夫和估算。
- 结对编程的时长 (Pairing Time)
- 手工测试的时长 (Time spent manual testing)
- 代码签审时长 (PR approval Time)
- 修复失败构建的耗时 (Fix red build time)
- 修复 Bug 的耗时 (Cost of fixing bug in Dev/Prod)
- 测试覆盖率 (Coverage test count)
- 效用调配比率 (Effort allocation, New work / Unplanned work or rework / Other work)
2.4 辅助决策：可进行试验并一直寻找新的度量指标，帮忙做决策。
- 前置时长 (Lead time)
- 公布进来的 Bug 数 (Escaped bugs 线上逃逸 Bug 数)
- 效用调配比率 (Effort allocation, New work / Unplanned work or rework / Other work)
- 交付的价值 (Valued delivered)
2.5 工程能力：4 key metrics 度量并找出团队工程实际的弱点。
- 变更前置时长 (Lead Time for Changes)
- 部署频率 (Deployment Frequency)
- 变更失败率 (Change Fail Rate)
- 服务复原耗时(Time to restore service)
当您在为团队寻找研发效力指标时，其实并没有一个恒定不变的模板，须要剖析多个因素，抉择最适宜您的指标，并与团队一起一直的应用它们，一直的依据价值交付为导向来批改和迭代。您本人团队的度量指标很可能与其余公司或团队的指标齐全不同，这是齐全失常的事件。因为正如后面提到的，研发效力的度量很大水平上取决于公司的类型，规模，文化，与之单干的我的项目类型以及其它因素。
三、我在一线开发过程中对效力的三个察看和观点
观点一：莫让度量变指标。
经济学家查尔斯·古德哈特在 1975 提出了古德哈特定律 : When a measure becomes a target, it ceases to be a good measure.“当一个度量自身成为指标时，它就不再是一个好的度量”。依据咱们在我的项目中的察看和教训，古德哈特定律不光实用于经济学畛域，一样实用于软件研发畛域。
此定律在事实中的故事: 在法国殖民期间的越南，鼠患成灾，所以当地政府想出方法: 激励民众一起入手灭鼠并处分灭鼠的民众，民众只须要上交死老鼠的尾巴就能够取得处分。不久之后，越南的街头就呈现了没有尾巴的老鼠，人们为了继续盈利，并没有杀死老鼠，而只是切下它的尾巴，期待它去生新老鼠给本人赚钱。
在失常状况下，「被切下的老鼠尾巴的数量」与「死去老鼠的数量」正相干，是一个好的指标。可是，一旦政府把「被切下的老鼠尾巴的数量」变成大家的优化指标，就会产生未曾预料到的后果。简略来说，这种度量变成了指标，驱动并产生了“上有政策，下有对策。”
在软件研发畛域里，当你度量团队产出的代码行数并设置指标时，比方: 800 行 / 人天，聪慧的程序员，就会被驱动去优化「代码行数」并让它达到目标。比方: 多加点两头变量，多加点正文，多抽点办法和测试，指标不就达成了吗?(曾见过办法实现只有两行代码，正文 20 多行，而且在工程里常常看到相似的正文和办法。) 这种指标度量会给业务带来价值吗?
再比方你度量并设置团队每个迭代须要实现 Story 的点数或者个数的时候，比方: 20 点 / 迭代，团队就会被驱动优化「Story 点数」并让它达到目标。比方: BA 和 Dev 在开迭代打算会议的时候多估算一点，多拆一些卡，指标不就达成了吗？(曾听到有团队的卡墙上有一张三个点的 Team Building 卡。Create DB 这种操作原来估 1 个点，当初估 3 个点。为了不影响 Cycle time 的统计, 因为第三方依赖阻塞的卡，阻塞不好推动，也不想继续辨认并推动了，移回 Backlog。) 这种指标度量会给业务带来价值吗？它是否能够落实到具体的治理或技术实际中？
让度量指标和数据收集尽量实在，须要关注的是趋势和阻塞。在下面的案例里，统计每个迭代实现的卡，须要察看其趋势，个别状况下，每个迭代实现的卡，会在一个正当的区间内稳定。(好比：用听诊器测量每分钟的心跳，非静止状态在 60~100bpm 次 / 分钟都属于失常。) 察看趋势并辨认阻塞和阻塞的起因，加以针对性的治理，从而加速卡的流动，是度量的意义。而不是简略的和其余团队比拟，粗狂的设定一个指标，驱使团队产生未曾意料的后果。
（某团队 24 个迭代所实现故事点统计图）
上图是一个我的项目 24 个迭代，每个迭代实现故事卡点数的统计图。因为团队所工作的业务畛域没有变动，团队在此业务畛域越来越纯熟，所以总体交付趋势逐步是回升的，交付速率逐渐在一个正当区间内稳定。察看并剖析交付点数稳定较大的迭代，剖析并采取行动：
- 迭代 7 到迭代 8，单个故事卡过大，拆卡品质不高，沟通复杂性减少，单卡开发时长减少，速率降落。口头：开发人员与业务分析师严密沟通，在工作开始时将其拆解成更独立，更小的故事卡。
- 迭代 14 到迭代 15，因为开发过程中所依赖的第三方 API 呈现问题，无奈按时对接，有累计超过 10 个点的卡提早交付，不能奉献给本迭代，但会在下个迭代第三方 API 完工后实现，并体现在下个迭代。口头：及时的沟通和追踪依赖零碎的状况并进行开发工作的调整，避免阻塞与期待的产生。
察看和观点二：无奈拆解的度量指标，可能不是一个好的度量指标。
可拆解的指标和后果才是一个好的指标。变更前置时长 (Lead time for change) 或者需要交付时长，是一个很好的指标，能帮忙并促成价值流的交付。然而你只是捕捉需要提出的工夫点和需要上线的工夫点，并计算这两个点之间的耗时以此进行度量和阻塞辨认，这是十分艰难的，因为跨度太大，包含的因素太多，你很难看分明到底产生了什么，到底在哪个阶段什么因素导致了阻塞。
杜邦分析法就是问题拆解的经典利用，拆解某个不容易看清楚的大问题到若干个子问题，通过剖析若干子问题从而解决原来的大问题。比方剖析并优化股本回报率这个一下看不清楚的大问题，拆解: 股本回报率（ROE）= 利润率 × 资产周转率 × 权利乘数 = (净收入 / 营业支出) × (营业支出 / 资产) × (资产 / 股东权益)从而将无奈间接剖析和优化的股本回报率，变得更容易剖析和优化，同时再次钻取这些子问题，直到找出一个个更加不言而喻的指标。
（杜邦分析模型）
（杜邦剖析图）
那么为什么能够借鉴杜邦分析法来拆解研发效力？因为研发效力也是一个不容易看清楚的大问题，须要拆解到若干个子问题，通过剖析若干子问题从而解决原来的大问题，同时它是一个可分阶段度量拆解的指标，并且每阶段都能够再次细分、拆解。
如上图，一个需要交付时长的拆解，通过一直的拆解找到更细化、具体的指标，找到优化点。
- 需要从提出到上线总破费时长为：21.5 天 (工作日)= 需要剖析时长(2.5 天)+ 需要设计时长(3.2 天)+Backlog 期待(0 天)+ 需要交付时长(15.8 天)；
- 需要交付时长(15.8 天)= 团队研发时长(7.7 天)/ 研发并行效率(48.5%)，如果只有一个团队，并行效率为 100%；
- 团队研发时长(7.7 天)= 需要开发时长(3.6 天)+ 需要测试时长(1.3 天)+ 公布前测试时长(1.2 天)+ 金丝雀公布时长(1.1 天)+ 全量公布时长(0.5 天)。
在上个迭代找相似大小的需要，同样拆解各个工序指标的时长、占比，从趋势角度观察各个指标是回升了还是降落了。如果回升了，比方需要设计时长 (3.2 天) 比上迭代相似大小需要的占比回升了 2.18%，起因是什么，是否须要留神并改良什么? 因为这次的一个需要点没有剖析透彻，导致了设计屡次反馈批改，耗时加长。
口头：对于需要剖析的产出减少更明确的查看列表，保障需要在送入设计之前曾经被剖析透彻了。所以当一个度量指标是一个可拆解的指标，它才可能是一个可落地到治理实际、技术实际的好指标。
察看和观点三：可继续扩大的度量，才可能驱动价值流的增效。
研发效力的度量常常从一个比拟全局的指标开始，因为比拟全局的指标，能更直观的体现交付价值，比方：上文的需要交付时长，然而不容易直观的看到问题，须要一直拆解，以此找到明确的问题点，把改良口头落地到治理实际、技术实际。与此同时指标也能够从部分开始，通过一直的扩大，驱动价值流增效。例如：起始的度量指标是《Accelerate》中的 Lead time, 度量从代码提交到部署到生产环境的时长。
原文第二章 Measuring Performance:
“The elevation of lead time as a metric is a key element of Lean theory. Lead time is the time it takes to go from a customer making a request to the request being satisfied. However, in the context of product development, where we aim to satisfy multiple customers in ways they may not anticipate, there are two parts to lead time: the time it takes to design and validate a product or feature, and the time to deliver the feature to customers. In the design part of the lead time, it’s often unclear when to start the clock, and often there is high variability. For this reason, Reinertsen calls this part of the lead time the“fuzzy front end”(Reinertsen 2009). However, the delivery part of the lead time—the time it takes for work to be implemented, tested, and delivered—is easier to measure and has a lower variability.”
原文阐明了残缺的 lead time 是从客户提出需要到性能上线、需要被满足的工夫，然而因为需要剖析、设计的起始工夫不确定性大，难以统计，所以从确定性大的交付阶段开始统计，同时《Accelerate》这本书也是主打 DevOps 工程实际，更关注此方面的度量和指标。能够从这个指标开始，然而不应就此停留在这一阶段，这一阶段的耗时少了，阐明团队的工程实际强，有欠缺的 CI/CD，但不肯定疾速的响应了客户的需要。所以须要继续扩大度量，驱动价值流增效。
理论案例：团队度量了 lead time for change: 10 分钟左右就从代码提交部署到生产环境了，然而察看发现一个性能的好几个代码提交等了几天才被部署，起初发现这些代码提交后进入了 pull request review，须要被客户团队 review，然而客户团队并没有及时的 review 且合并 master 主分支，没有触发 pipeline，所以等了几天。团队能够自行 review 和 merge 的 pull request 都被很快的 review 合并了。此时团队扩大 lead time for change 的度量，起始工夫从合并到主分支这个工夫点，左移到 pull request 里的第一个提交，通过度量找到了和客户团队单干 pull request review 过程中能够优化的点，减速 pull request 的过程。
起初 lead time for change 的起始工夫又被进一步左移，挪动到了 Story 卡被移进 开发 列的工夫，当 Story 被移进 开发 列就代表此性能的 lead time for change 开始计时了，从而理解开发过程中是否有和 BA、QA 沟通中的阻塞，有可优化的点。如果开发的性能被 feature toggle 所爱护，在代码提交并部署上线后，feature toggle 没有被关上，也能够将 lead time 的完结工夫右移，计算为 feature toggle 关上的工夫点，能够剖析是否业务决策的工夫过长影响了性能上线。
以上的三个察看和观点：
- 莫让度量变指标。让度量指标和数据收集尽量实在，须要关注的是趋势和阻塞。
- 无奈拆解的度量指标，可能不是一个好的度量指标。
- 可继续扩大的度量，才可能驱动价值流的增效。
心愿能在您应用研发效力的指标与度量过程中带来帮忙，通过设定的指标和对应的
度量，找到软件研发过程中的阻塞，从而制订对应的口头，无效的落地到治理实际和技术实际。
四、三种我的项目类型及其举荐指标
软件研发效力的度量指标和工具链越来越丰盛，主打数字化转型的企业在外部也开始建设本人的效力中台了，作为一线研发人员，面对这些目迷五色的指标、工具和平台，不经要问：我须要把这些货色都实际了吗？什么是我最须要做的，什么是我现阶段的优先级? 在前文中咱们提到，研发效力的度量很大水平上取决于公司的类型、规模、文化、与之单干的我的项目类型等因素。一个团队的度量指标很可能与其余公司或团队的齐全不同，这是齐全失常的事件。那么有没有一个略微简略的形式能帮咱们疾速辨认一些更适宜现阶段的度量指标呢?
4.1 三种我的项目类型
在软件研发过程中，个别会通过三个阶段或者说接手三种类型的我的项目：绿地我的项目、棕地 (黄地) 我的项目、红地我的项目，（下文应用: 绿地、黄地、红地与之对应并简化代表），如同一个软件系统的生命周期。通过辨认我的项目类型来找到此类型适合的度量指标，这可能是一个疾速高效的计划。
- 绿地：“In software development, a greenfield project could be one of developing a system for a totally new environment, without concern for integrating with other systems, especially not legacy systems. Such projects are deemed higher risk, as they are often for new infrastructure, new customers, and even new owners.”一个全新的我的项目可能是为一个全新的环境开发一个零碎，而不必关怀与其余零碎的集成，尤其是与遗留零碎的集成。
- 黄地：“Brownfield development is a term commonly used in the information technology industry to describe problem spaces needing the development and deployment of new software systems in the immediate presence of existing(legacy) software applications/systems. This implies that any new software architecture must take into account and coexist with live software already in situ. In contemporary civil engineering, Brownfield land means places where new buildings may need to be designed and erected considering the other structures and services already in place.”在现有（遗留）软件程序 / 零碎之下开发和部署新的软件系统。这意味着任何新的软件架构都必须思考并与已运行的软件系统共存。
- 红地：软件系统进入保护期，并且不再开发新性能，只修复终端用户所发现的 Bug，保护一段时间后，可能从此进入沦亡期，不久后会被新零碎所取代。
绿地与黄地的疾速辨认因素：是否思考遗留零碎的集成、共存。黄地与红地的疾速辨认因素：所保护的零碎是否只修复 Bug，不思考减少新性能，或曾经有打算会被取代。当疾速辨别我的项目的类型后，那么就能够依据我的项目的类型来设置度量指标：
4.2 三种我的项目类型的举荐指标
- 绿地举荐指标
相比其它类型，绿地我的项目研发团队是最可能靠近我的项目终端用户，最可能发展端到端度量的，同时此类型的我的项目没有“历史包袱”，能够失常的进行架构设计，技术栈抉择，在失常开销下实现部署流水线、线上监控告警、回滚、灾备等必要的线上保障措施。可抉择 辅助决策、工程能力 这两类指标为首要指标，关注端到端的价值流，同时保障我的项目初期就将良好的工程实际落地。可抉择 布局进度、疾速反馈 为主要指标，辅助端到端价值流度量的达成。
首要指标和主要指标之间个别会相互影响，互相印证，主要指标的改善会带来首要指标的改善（比方：疾速反馈 - 代码签审时长的改善，会带来辅助决策 - 前置时长的改善。）如果晋升首要指标不好下手，可从主要指标开始。此时的 fuzzy front end 可定义为：终端用户向团队提出了某个需要的那一刻，可将用户需要被明确记录的那一刻认定为 lead time 的开始。
- 黄地举荐指标
我的项目已上线一段时间，有不少终端用户，并且要在原有零碎上进行设计和开发，团队须要背负肯定的“历史包袱”，架构和工程实际可能曾经开始腐化。可抉择布局进度、工程能力这两类指标为首要指标，关注交付工作的进度、架构和工程能力的改善，当工程能力晋升后，会带来交付的减速。可抉择辅助决策为主要指标，拓展性能交付所产生价值的度量，促成端到端的价值流度量。中篇提到的：可继续扩大的度量，才可能驱动价值流的增效，是一个无效技法。此时的 fuzzy front end 可定义为：在业务交给开发的那一刻，故事卡失去了明确定义。
依据以往教训，接手此类我的项目个别会有很多协调和沟通工作，“谷仓”(The Silo Effect) 重大，一开始就想从需要源头度量比拟艰难，从交付延展至价值度量是一个更适合的形式。同时此类型的我的项目还随同着自上而下的改革诉求（尤其产生在滞销的、长生命周期的产品我的项目上），此时可退出 团队转型、疾速反馈 这两类指标为首要指标，帮助实现改革诉求。
- 红地举荐指标
软件系统上线多年，稳固服务于终端用户，不再开发新性能，只修复 Bug，可能不久后会被新零碎所取代。产品团队很可能不想再投入更多的资源改善零碎，只有能把重要的 Bug 修复，每个季度公布一次就行。可抉择 布局进度 为首要指标，保障有良好的 Bug 修复吞吐量。如果产品团队心愿减少部署频率，放慢响应终端用户的 Bug 诉求，可抉择 疾速反馈 为主要指标，帮忙减速公布周期从而疾速响应终端用户的 Bug 诉求。此时的 fuzzy front end 可定义为：终端用户将 Bug 清晰地报告给客服人员的那一刻。
指标的抉择和团队的上下文强相干，需依据团队具体的上下文来抉择举荐的指标集，并裁剪指标集中的具体指标。
（基于我的项目类型的效力指标举荐图）
五、度量债与治理
随同度量的发展和深刻，我的项目同时也经验了一段时间的倒退(由绿转黄，或由黄转红)，你可能会失去一个贵重的顿悟时刻 度量债，绿地不开始度量，我的项目倒退到了黄地或者红地的时候想度量了，就须要实现原来的度量（债权），迁延的工夫越久相比一开始就度量所付出的代价就越高（利息）。
这两个特点十分相似事实中的债权，和经常提到的技术债也很类似。比方：零碎想剖析和统计一个申请在各个阶段所破费的时长从而进行优化，在最后的设计和实现时，不想花老本，就义将来的度量需要，满足当下的疾速上线，没有为申请做一个 TraceID，或者 Tag、Bag，这样的属性，让其能够追随申请通过各个系统，做好序列化和反序列化，那么当你想度量申请耗时的时候，很可能只能在申请端记录一个收回工夫和返回工夫，两头各个系统的解决时长根本无奈获取和剖析。
当你想加这个信息的时候，会发现株连的零碎太多了(网关, 反向代理, 服务 A、B、C、…, 音讯队列, 数据库，等)，工作量太大，甚至有些零碎你可能还不晓得。度量也相似：当我的项目还是绿地阶段，干系人较少，需要评审和设计流程短，此时就义度量需要，只管性能上线，没有统计终端用户的需要创立工夫、需要评审和设计工夫，只统计了故事卡被交给开发的那一刻，随着我的项目倒退 (尤其是盈利我的项目，策略我的项目，需要和规模疾速扩充的我的项目)，干系人增多，需要评审和设计流程加长，此时再想统计终端用户的需要创立工夫、需要评审和设计工夫，可能你已无奈晓得故事卡在传给开发之前都经验了那些流程和阶段，所以此时再想度量，就会比绿地时所破费的代价大得多。
如何治理度量债？因为和技术债的相似性，能够借鉴技术债的治理办法，尽量只留下：审慎成心的、审慎无心的度量债。借鉴 Martin Fowler 的 Tech debt quadrant。
当你向团队提议说:“咱们来度量一下研发效力吧，看看有没有什么能够改善的?”可能会失去上面的答复：
- “咱们没工夫进行度量，就这样吧！”，此时团队是莽撞并且成心的，团队晓得这样做是会欠债，然而并不分明欠了债的具体结果，这种状况能够减少流程、负责人来作为揭示。
- “咱们晓得要度量，然而等这次公布之后就开始吧。”，此时团队是审慎并且成心的，团队晓得这样做是会欠债，而且也晓得欠了债的具体结果，这种状况根本无奈防止。
- “什么是度量？怎么度量？”，此时团队是莽撞并且无心的，团队不分明什么是度量，不分明如何进行度量，这种状况须要补充能力。
- “当初咱们终于晓得该怎么度量了！”此时团队是审慎并且无心的，团队晓得度量这件事，但过后没有人晓得如何度量，直到现在才明确如何度量。这种状况无奈防止。
起源：Thoughtworks 洞见
作者：张思楚
申明：文章取得作者受权在 IDCF 社区公众号（devopshub）转发。优质内容共享给思否平台的技术伙伴，如原作者有其余思考请分割小编删除，致谢。
1 月 27 日（周四）晚 8 点，【冬哥有话说】“拆书会”，译者天团领读《运维窘境与 DevOps 破解之道》，公众号回复“冬哥”可取得直播地址