我们喜欢度量，只是因为我们害怕不确定性罢了。

拟定的目标，但未成为现实之前，是摸不着的空中楼阁。我们如何确保自己以及众人，做出了正确的努力。度量，是在到达那一天之前，本能之下会想到的办法。遥望远方，时不时回头看下身后的脚印，再一步一步踱往前去。

只是到了一些特定的局面之中，因为我们内在的人性惯性，企业文化的重力，以及微妙的的官僚和政治，原本有着良好意愿的度量初心，就会很容易被极度简单物化成了只需遵从并实现的指标，并挤压在复杂性下做全局优先思考的空间。

于是，度量势必走向变形的另外一面。我们看到了多少以KPI和OKR之名，行下达摊派之实。极度简化的单词缩写，也简化了人们的头脑。结果只能是懒惰的思考，以及唯一放在产出的关注点。目标平庸还好，无伤大雅。而华丽的愿景之下错误的方向，则会引领人们南辕北辙，日暮途穷。在这错误的旅途上，唯指标和上峰至上，各自为阵，彼此倾轧，只见树木不见森林。

而这又会进一步扭曲我们对于当下存在状态的思考角度。认为这就是现实，无力扭转。

我一度也以为，敏捷更关乎开放的心态，无止境的快速反馈和学习，提起度量的态度是暧昧的。即便见证过敏捷起来的收益，但对于心存狐疑的人终究没有说服力。

《加速》里面提到了四个关键指标：

• 前置时间
• 部署频率
• 平均恢复时间
• 变更失败率

与误入歧途的KPI不一样，这里的关注点则被放在了亟待建设的能力上。

在我看来，它们是尽了最大的可能，给出让人信服但又难以企及的答案。对于我们的理想境地，用它们去描述，虽然平白，但激动人心。但它们终究是经过大量的案例和数据统计得来的，一个完美主义者的美丽新世界。深刻去理解它们，并能理解在它们之下，究竟隐藏着多少持续改进的意愿和努力，才是最难能可贵的。

重要的是，它们确实为我们提供了可以观察的立足点，看到我们进步，以及我们驶往的方向。

（谢谢王妮的建议）

重要的是持续优化的过程，最终交付只是作为副产品之一产生，顺水推舟而已。

记得在某个场合，跟仝键有这样大致的对话。

面前一段旅程，从起点出发，往着目标进发。这是每个人都会有的功课。对于组织而言，要有自己的目标，商业盈利还是社会公益，也都无可厚非。但我们多少已经习惯，目标的实现，即等同于定义的成功。全神贯注于目标，并致力于实现它，成为普世意义上唯一衡量是否努力的标准。

但在软件行业，是否存在另外一个可以思考的空间。

软件构建相比较其他行业而言，最大的一个区别莫过于，它是知识消费和创造的过程。从业务诉求和价值定义，所有与此相关的信息在人们的头脑和言语间传递和转换。令人失望的是，除去那些自欺欺人的所谓满意以外，我们并没有足够的经验和能力，能表明我们在这些信息承转之间，获得到了足够的心安理得。需求模棱两可，在过程中反复无常，曾经自以为的目标交付物也可以沦落到谬以千里，触目惊心。

瀑布方法已经被证明一板一眼无法再有面对不确定性的从容。敏捷以适应性和响应性，挺身而出。敏捷之中诸多的原则和实践，是显而易见的改进手段，唾手可得，耍将起来也煞有介事。短时间取得显而易见的效果，本就是理所当然。它们一度填充了人们在恐惧面对不确定性洪流时的安全皮筏。但人们也就此误以为，这就是可以赖以顺流直下的救命稻草。

然后就此认为改进完成，已然敏捷。

如果仅仅是就此原地踏步，也算万事大吉。但无奈怎样都会是事与愿违。敏捷实践的整体性诉求，以及企业组织和文化的惯性，总是很容易让团队的微弱努力顷刻烟消云散。不安全感再度笼罩。

迎难而上的改进，是向不确定性讨要回掌控感的本能。但一如字面意义，持续改进，难的不是改进，而是在持续。

持续二字，既是对改进这件事一如既往的执着态度，也是对不确定性和不安全感出自内心的认可。适时后退一步，并不意味着低头，在后退间反而得到片刻静默，以及观察的机遇。

历经辛苦，找到改进的良药，实属不易。解决了一个技术难题，或者澄清了纠结已久的需求，都是件值得庆贺的事情。当下的事情，都可以某种更明快的节奏往前推进。怎么都被看做一件值得庆贺的事情。但起点（需求）和终点（目标）对于确定性的双重挤压，仍然会将我们置回于似曾相识的失落境地。不再奏效的不只是曾经成功的经验，还有尚未消失殆尽的成就感。

这时候，我们可曾有过妄议，哪怕迈出大胆的一小步，质疑我们开头来的路，以及我们要去的方向。