【本文翻译自infoq.com】

敏捷宣言是错误的。

没错，InfoQ上有一篇文章说敏捷宣言是错误的。但是请先别着急。我喜欢宣言，但12项原则之一是错误的：

可工作的软件是进度的主要衡量指标。
Working software is the primary measure of progress.

敏捷宣言，2001

这是错误的。这种观点现在是错误的，在2001年也是错误的。进度的主要度量指标应该是业务结果，而不仅仅是可工作的软件。

顺便说一句，这条原则与第1条原则相冲突：

我们的首要任务是通过尽早并持续交付有价值的软件来满足客户。
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

因此，我们不应该评估工作的（working）软件，而要有价值的（valuable）软件。这是100％正确的。但是什么是有价值的（valuable）？我们如何定义价值（value）？

价值对于不同的人意味着不同的东西，这取决于他们的观点。在敏捷项目中，有几种处理业务价值的技术，包括价值点（Value Points），业务价值建模（Business Value Modeling）等。

但是其中大多数只是估算，而不是真正的价值度量标准，只有在功能发布之后才能度量。

2015年1月，Ken Schwaber在描述Nexus时介绍了他的规模化敏捷框架：

在我们的案例中，Nexus是3-9个Scrum团队，他们基于唯一的产品待办事项列表工作，以构建满足目标的集成增量。
In our case, a Nexus is 3-9 Scrum Teams that are working on a single Product Backlog to build an integrated increment that meets a goal.

但是对于什么是目标以及如何定义目标却只字未提。

我们需要一种设定清晰的目标的方法，供不同的利益相关者和团队共享。

目标设定有什么问题（What is wrong with Goal Setting）

静态规划（Static Planning）。这就是我所说的传统的年度计划流程。大家都知道这是怎么回事：公司高管在一个度假村里进行“战略思考（strategic thinking）”，并确定了该年度的公司目标。然后在接下来的几周内，这些目标在整个组织中“串联”起来，为公司制定一个详细而固定的年度计划。

静态模型（static model）的假设是：

1. 可以预先详细定义计划的所有步骤；
2. 绝大多数计划是正确的；
3. 市场情况将基本保持不变；
4. 计划中的变更很小，可能在年中进行一次审查，届时将创建一个新的详细的静态计划。

级联的比喻本身从字面上指的是一种单向自上而下的现象——瀑布。

相反，动态计划（dynamic planning）包含变化，并在增量的、迭代的模型中以较小的计划周期工作。动态计划假设市场条件和计划本身都将发生变化。

《黑天鹅》的作者纳西姆·塔勒布（Nassim Taleb）喜欢将静态模型与克里姆林宫的中央计划者进行比较，后者制定了自上而下的5年计划，认为他们可以预测未来。

如果您的团队正在进行一到四周的迭代（或冲刺），离开办公室与客户交谈，通过经过验证的学习测试假设，那么您如何才能使用由克林姆林宫设计的年度瀑布流程中定义的一组静态目标呢?

答案是，你不能。

一定有别的办法。

Keith R. McFarland在他的MITSloan管理评论文章“ 您应该像构建软件一样构建战略吗？（Should You Build Strategy Like You Build Software?） ”中写道：

由于战略（strategy）只能在给定的时间点上捕获公司的最佳思想，因此，随着人们获得并分配新的经验和知识，需要对战略（如同软件程序一样）进行完善和改进。
考虑到这一现实，完善的战略制定流程应使公司能够快速、迭代地创建和调整战略……并在不断变化的环境中分配资源。

因此，尽管我们一直在战术（tactically）上使用敏捷/精益的思维方式和流程，但我们仍在使用瀑布式的思维方式和流程来设定目标。这种情况需要改变。

但我们如何才能实施一种新的方法呢？McFarland提到了“战略Scrums（strategy scrums）”的使用，但是仍然缺少一个更正式的框架。让我们进入OKR吧。

OKR：敏捷目标设定框架（OKR: an Agile Goal Setting Framework）

OKR（目标和关键结果）是由英特尔创建并被多家硅谷公司采用的目标设定框架。Google是最著名的案例，它在创办第一年就采用了OKR。Twitter，LinkedIn，Dropbox和Oracle等公司也采用了这种技术。

将Google引入OKR的全明星风险投资家John Doerr提供了设定目标的绝妙方法：

我将完成可供____________衡量的________。
I will ________ as measured by ____________.

因此，OKR可以认为是一项承诺：

我将完成可供（这组关键结果）衡量的（目标）。
I will (Objective) as measured by (this set of Key Results).

因此，一个OKR包含两个组成部分：目标（我们要实现的目标）和一组关键结果（我们如何知道我们是否达到了目标）：

目标（Objective）

• 我们想要实现的目标。
• 定性的（Qualitative）。

强烈建议使用能鼓舞人心的目标。没有人会为了“提高10%的转化率”而兴奋的起床。

关键结果Key Results（每个目标各一套a small set per Objective）

• 我们如何知道我们是否实现了目标。
• 定量的（Quantitative）。
• 显示我们是否在进步的成功标准。
• 度量指标或里程碑。

例如，假设有一家技术公司希望提高客户参与度和满意度，那么他可以制定如下OKR：

目标：使我们的客户高兴。

关键结果：

• 重复访问：每周每位活跃用户平均访问3次。
• 净发起人得分达到90％。
• 80％的非付费（有机）流量。
• 参与度：75％的用户完成了完整的个人资料。

OKR有什么独特之处？（What's unique about OKR?）

• 简洁：为了实现频繁的设定目标（英特尔每月设定一次OKR ），该过程非常简单。OKR本身应该是简单易懂的。
• 节奏更短： OKR不使用年度静态计划流程，而是使用更短的目标设定周期（通常是每个季度），从而实现动态计划并更快地适应变化。
• 开源： OKR是一个开源框架，公司可以根据不同的文化和环境对其进行调整，从而创建不同的版本。这是一个很大的好处，因为OKR很容易适应。但这一点可能会误导那些寻找循序渐进配方的人。
• 延伸目标：将团队带出舒适区域并让他们重新思考工作方式，以达到最高绩效的目标（了解更多信息）。
• 与薪酬和评估相分离：将目标与薪资和晋升脱钩是关键，这样团队才可能追求艰巨的、有抱负的目标（阅读更多内容）。

OKR的实践（The Practice of OKR）

OKR的主要目标是在组织中建立一致性。为此，透明度是关键。OKR对公司所有级别的人都是公开的——每个人都可以访问其他人的OKR。所有的OKR，包括CEO的，通常都可以在内联网上找到。

OKR的存在是为了设定明确的优先级并使组织专注。为此，您应该没有几个OKR。每个个人或团队最多只有5个目标，每个目标最多只有5个关键结果——少即是多。

增量，自适应的目标设定（Incremental, Adaptive Goal Setting）

OKR通常具有双重节奏：

• 公司的高层目标是每年设定的。
• 团队和个人的详细增量目标设定为较短的目标周期（迭代），通常持续一个季度，但也可以只持续30或45天。

在年初，公司会定义一组高层级OKR（最好是在团队的帮助下），而无需设置整个年度的详细计划。

在目标周期（goal cycle）的开始阶段，每个团队都要回顾上一个迭代（previous iteration）的结果，然后为下一个目标周期设置详细的目标。在并行过程中，个人和团队定义与组织目标（organization objectives）相关联的目标（goals），并由管理者在自底向上和自顶向下的系统中进行验证。

团队可以从公司的OKRs获得明确的指导，并了解他们如何为实现这些目标做出贡献。约60％的OKRs应该由团队定义。

重新评估上一个循环中未实现的目标，以便将其包含在下一个循环中，或者如有必要，将其丢弃。

水平对齐（Horizontal Alignment）

为了确定OKRs，个人和团队互相讨论以解决相互依赖关系并建立水平一致性。如果团队需要其他领域的东西，他们可以讨论并设定共同的优先级，甚至可以将计划推迟到下一个目标周期。

由于OKR是透明的，因此如果业务的某个领域与其他领域不一致，则其他团队可以迅速注意到并修复该问题。

加强一致性：共享的OKRs（Reinforcing Alignment: Shared OKRs）

为了加强一致性，可以在不同团队之间创建共享的OKRs，从而在他们之间创建共享的成功标准。因此，与其在团队之间分配一个单独的计划、设置单独的目标——这可能导致团队忽略实际目标——不如在团队之间创建一个共享的OKR。

例如，假设一个产品团队想要发布一个新产品，他有可能需要平台团队开发新功能，同时需要业务开发团队与合作伙伴签署内容协议。

目标：成功推出Acme产品

关键结果：

• 免费版本的每日活跃用户500.000。
• 从免费客户到付费客户的转化率为8％。
• 净发起人得分为75％。
• 少于5个严重或阻碍型bug被用户报告。
• 与5个目标内容合作伙伴取得至少40％的收入份额。

在团队之间共享这个单一的OKR，而不是在没有期望业务成果的情况下单独实现3个不同的目标。每个团队都有不同的任务，但具有相同的OKR——相同的成功定义。

在本OKR期间，将把三个不同领域的团队组建为一个虚拟团队，他们将定期开会跟踪进度。

OKR如何补充精益和敏捷（How OKR complements Lean and Agile）

OKR为有效的学习带来了原则（OKR brings discipline to validated learning）

Steve Blank在他的文章中写道：

使用商业模式画布（Business Model Canvas）来构架假设，让客户开发人员走出办公室来测试假设，并使用敏捷工程来迭代和增量地构建产品。

但是，您如何知道自己是否成功？我们认为什么是“经过验证的假设（validated hypothesis）”？我们需要明确的、共享的成功标准来进行有效的学习。所以我要补充：

… 和OKR用来跟踪您的方向是否正确。
…and OKR to track if you are going in the right direction.

OKR定义了超越功能的成功标准（OKR defines Success Criteria beyond features）

敏捷项目通常通过其交付功能（带有“质量”）的速率来评估。但是，提供功能但未能实现预期业务成果的团队永远不会被视为成功。

OKR教练Christina Wodtke关于“成功”的推文很棒：

成功不是打勾。Success is not checking a box.
成功就是有影响力。Success is having an impact.
如果你完成了所有的任务，却没有任何进展，那就不是成功。If you complete all tasks and nothing ever gets better, that's not success.

实际上，提供不会对所选指标产生积极影响的功能（OKR话语中的“关键结果（Key Results）”）可能会产生负收益：新代码可能存在错误，必须加以维护，并且产品本身将变得更加复杂。

Marty Cagan对此主题（以及其他几个主题）都有一些不可不读的文章。如果您尚未阅读他的书和博客，可以先看看摘要：

这就是为什么我很高兴看到OKR的兴起。如果使用得当，它们可以将这种情况从输出（路线图上的功能）[output (features on roadmaps) ]转变为结果（业务结果）[outcome (business results)]。

OKR有助于避免“淋浴温度”问题（OKR helps avoid the “shower temperature” problem）

如果你不停地转动淋浴龙头，水永远不会达到你想要的温度。创新也是一样，如果你一直在调转方向，你永远都不会到达你想去的地方。

使用较短的目标周期（goal cycles）可以帮助避免该问题。当然还是可能会出错，但是正如Zynga前高级产品副总裁Jon Tien在关于OKR的精彩视频中所说：

臭狗屎也会有粉丝，但这并不意味着您不应该使用相同的原则。

OKR支持自组织团队（OKR enables self-organizing teams）

最好的体系结构，需求和设计来自自组织团队。

敏捷宣言

但是，如何真正实现自组织团队呢?

为了拥有一个由自我管理的团队组成的扁平的、高度一致的、高度自治的组织，您必须为组织设置一个“正确的方向（True North）”。你必须给团队明确的方向（clear direction）。

给团队赋予一组OKR可以做到这一点。

OKR将团队与企业及其客户联系起来（OKR connects the team with the business and it's customers）

对于团队来说，他们很容易迷失在编写代码和设计的技术细节中。但是，当您开始在自底向上的流程中讨论业务成果（business results）时，您会让团队成员开始询问他们为什么要这样做。

如果您一直在谈论交付功能（delivering features），您希望团队如何考虑用户？或者业务？

OKR如何补充Scrum（How OKR complements Scrum）

OKR赋予团队自治权（OKR gives autonomy to the team）

在一些公司中，产品负责人（Product Owner）被称为“代理负责人（Proxy Owner）”，因为她/他只是将高层管理人员优先考虑的功能列表来回传达。您如何赋予他/他管理产品的授权？您如何确保团队具有自治权？

如果团队的角色是“交付客户/管理人员想要的功能”，那将永远不会发生。心态必须是“团队的角色是实现关键结果中描述的成功标准，并与客户/管理层达成一致。让我们给他们这样做的自主权。”

OKR帮助确定产品待办列表的优先级（OKR helps prioritize the product backlog）

即使您必须专注于交付业务结果而不是功能，您仍然必须优先考虑产品待办列表。

但是产品负责人/产品经理应该怎么做呢？她/他应该使用“感知价值”作为标准，但这仍然是主观的。OKR可以作为缺失的部分，一个简单，清晰的框架来决定要开发的功能。

正如Cagan关于产品记分卡（product scorecards）（现在已由OKR取代）写的那样：

关于产品记分卡，我最喜欢的好处之一是，它们通常可以帮助您消除待办事项列表/路线图的很大一部分。如果某个功能构想没有直接与产品记分卡（product scorecards）[OKRs]上最重要的KPI[关键结果（Key Results）]联系起来，那么它通常不会出现在列表中。

结论（Conclusion）

我希望这篇文章能够说明OKR是一个很好的框架，可以在多个方面补充精益和敏捷，从而在团队之间建立一致并改善沟通。这是一个轻松、简单和直接的技巧，只需进行一些结构化的对话即可设定目标。