系列文章｜OKR与敏捷（一）：瀑布式目标与敏捷的冲突

OKR与敏捷开发的原理有着相似之处，但已经使用敏捷的团队再用OKR感觉会显得多余。这种误解的根源就在于对这两种模式不够了解，运用得当的情况下，OKR和敏捷可以形成强强联合的效果，他们可以创造出以价值为驱动的团队，改变团队的工作方式。

本文第一部分介绍了瀑布式目标与敏捷之间的冲突。

敏捷的诞生是为了确保软件的交付，可以替代瀑布式开发来管理软件项目。敏捷模式注重的是可交付成果（开发需求或软件功能）而非项目价值（业务成果）的管理。

事实上，敏捷中并没有单独跟踪结果的规范。

《敏捷宣言》本身具有一定的误导性，因为它告诉人们要衡量可交付成果，它的第七条原则规定：“可工作的软件是进度的首要度量标准”。

该原则默认所有可使用的软件都有价值，这显然是错误的。因为有些项目能够产生价值，有些不能；用户可能会采用软件的某些功能但却会摒弃其他的功能。

大多数公司陷入了“功能工厂”模式，其团队压根不关注交付产品的价值。正如约翰·卡特勒（John Cutler）所描述的那样，开发人员就像流水线的工人那样“坐在工厂里，批量制造各种功能，然后传送出去”。

马蒂·卡根（Marty Cagan）强调过这种模式可能导致的可怕后果：

“开发团队忙着具化细节、写代码和测试。他们对更大背景知之甚少，甚至不太相信自己的产品真的能成为解决方案。他们不在乎这些功能是否真正解决了潜在的业务问题。因为他们衡量进度的标准是输出而非成果。”

距《敏捷宣言》发表已经过去15年了，大多数公司使用敏捷只是为了交付，而在缩放框架上几乎没有什么帮助。因为他们选择这条阻力最小的路并且专注于改善软件开发过程。也正因此，几乎很少有公司能够真正实现公司业务的敏捷性。

我喜欢把公司看成是一个包含了五个层级的架构，即文化、战略、策略、运营和目标。

公司目标反映公司的工作和运营方式，因此它也会渗透到其他四个层级。

传统公司的组织架构图示如下：

在传统的公司架构中，各个层级的特点分别是：

通常，公司采用的敏捷，是指敏捷交付功能。仅仅只是用来替换公司最底层的架构：

敏捷交付仅在运营层面实践精益和敏捷性。当团队进行分散的实验时，敏捷取代了瀑布式开发，这也就导致团队无法形成实验文化。尽管各处都开展了一些A/B测试，但许多高风险假设未能得到验证。

鉴于敏捷交付不涉及其他层级的架构，因此其优势变得越来越小， 瀑布模型的缺陷与公司敏捷性的实现之间存在直接冲突。

在设定目标时，瀑布模型的思维模式仍然十分常见。公司通常会以年度为单位，自上而下地规定一系列静态的目标，而这与公司保持敏捷性之间存在直接冲突。

瀑布式目标遵循了静态的规划模式。通常由一群高层管理人员集体制定公司的年度目标，然后逐级向下传达，并最终形成公司该年度的固定计划。

没什么能比瀑布更形象地描述这种自上而下逐级传递目标的设定模式了！

这种静态的模式包括下列几种假设：

更糟糕的是，瀑布式目标不关注价值，因为它们反复围绕着管理层批准的一系列项目而设定。

弗雷德里克•泰勒（FrederickTaylor）曾写道： “每个员工的工作都应该至少提前一天由管理层详细规定出来。” 如果他得知当今的公司依然遵循着他的教导，想必会异常欣慰。

在泰勒的敏捷管理理论中，团队存在的意义就是为了完成项目的交付。管理人员将严格按照流水线工厂的模式来规划工作。这种管理模式将导致公司反应迟缓、难以适应变化，同时还会增加风险和浪费。

在敏捷交付中，大多数的缩放框架都是能够取得一定成效的，因为他们着重通过敏捷的思维方法来推动瀑布式计划的实现。

信奉静态计划模型的人就像是苏联时期的中央领导人，他们制定5年计划方案，认定自己可以预测未来。

相较之下，动态计划则拥抱变化。他们在一个较小的计划周期内运转。动态计划假设市场条件和计划本身都会发生变化。更重要的是，我们对问题的理解将伴随着了解的深入而变化，而计划也会做出相应调整。

正如肯特·贝克（KentBeck）所写的： “一成不变地按照既定计划行事的唯一方法就是拒绝学习、固步自封。”

你希望团队可以在更短的周期内更新迭代并检验假设，那你怎么能效仿苏联通过瀑布式流程来设定一系列的静态目标呢？

这样肯定行不通，尽管我们在交付层面实现了敏捷，但在其他方面依然使用瀑布模型。

我们需要改变。

原文作者｜Felipe Castro
内容编译｜Worktile
翻译｜彭相珍