系列文章｜OKR与敏捷（三）：赋予团队自主权

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

本文最后一部分分析了OKR的正确使用方法，以及如何赋予团队更多自主权。

回顾第一部分请点这里：系列文章｜OKR与敏捷（一）：瀑布式目标与敏捷的冲突
回顾第二部分请点这里：系列文章｜OKR与敏捷（二）：实现全栈敏捷

使用OKR的正确方式

与其余工具同样，OKR也可能会被滥用并沦为待办事项列表。但若是你想要专一于价值实现，那么你的目标就必需要体现这一点。所以你须要设订价值导向的关键结果：

价值就像讲笑话：你无法告诉对方它到底好很差。

价值导向的OKR不只仅衡量结果。你还须要明白对你的客户和公司来讲，什么样的结果才是有价值的。

下面的例子展现了两种关键结果的差异：

在敏捷中使用行为导向的关键结果会产生摩擦。既然敏捷团队已经有了明确的路线图，为何他们还须要OKR呢？我遇到的全部尝试将OKR与敏捷相结合的团队，都在专一于开发活动自己。

使用价值导向的OKR可以带来变革，它能够成为链接敏捷和精益的桥梁，弥补产品和开发之间的空白。

改变侧重点

尽管敏捷使用的命名法专一于交付。咱们也须要抛开一些概念，好比“完工、燃尽图、速度”。

与之相反的，咱们应该专一于价值。咱们不须要验收标准，须要利用OKR来定义成功的标准。

从意见转变为数据
敏捷并非独立的数据驱动，而是HiPPO（HighestPaid Person’s Opinion）模式，即遵从薪酬最高者的意见。

《谷歌的经营之道》一书生动形象地描述了这个模式：

这种敏捷模式下隐藏着一个巨大缺陷。即公司的利益相关者告诉团队应该去作什么工做，并对工做进行审查。

罗恩·杰弗里斯（Ron Jeffries）描述了一场与利益相关者的虚拟对话：

“每周你能够告诉咱们你最看重什么，而后咱们会告诉你哪些要求是咱们能够实现的。一周以后，你就能够拿到咱们的成果。若是你乐意，你就能够交付出去。”

按照泰勒管理模式，由利益相关者来决定团队应该作什么，以及交付的成果是否能够出售。这种作法默认利益相关者知道什么具备价值，且他们的意见能够做为实际价值的衡量指标。

但数据代表实际上正相反。例如，罗恩·卡哈维发表了一篇论文，对微软的一系列创意和结果进行了分析。结果，仅有 1/3的创意对指望指标在统计层面产生了积极效应。

若是敏捷开发摒弃了数据统计和成果衡量，转而选择HiPPO（遵从薪酬最高者的意见）来决定应该开发什么功能，那么其偏差将超过66%。

不少公司还在使用“客户意见至上”的管理模式。这种模式中，个别人的意见表明了终端客户。在过去这个作法尚且行得通，由于在数据采集上很困难。但到了数字化的现代社会，这已经成为了瀑布模型的又一个遗留问题。

用实验取代HiPPO模式

事实上，开发团队不须要个别人来表明客户的意见。由于团队能够本身采访客户以判断开发行为是否得当。OKR能够取代HiPPO，经过实验让团队学习和复盘。

OKR能够帮助团队采用假设驱动开发模式，巴里•欧莱礼将其描述为：

咱们认为……
可获得……
当……咱们有信心继续进行……

在这个模型中，复盘再也不是为了展现可交付成果。团队在复盘中经过讨论主题和主要假设来不断完善交付成果。

赋予团队自主权

命令与控制依然存在。

命令与控制心理依然贯穿敏捷交付的全过程。利益相关者有权决定开发什么功能。所以，团队的工做模式依然是“由于这是山姆说要作的”，直到“山姆以为不错”以后才算完工。

公司发展须要团队全身心的奉献，因此他们须要理解公司的业务问题并可以就构建内容发表意见。

马蒂·卡根曾写道：“若是你只让你的工程师写代码，那你只获得他们一半的价值。”

为了赋予团队自主权，你要给予他们自主决定如何实现预期成果的自由。所以团队的目标也须要改变：

玛丽·帕彭迪克（Mary Poppendieck）曾写道：

“或许敏捷开发实践最大的缺陷是哪一个来团队决定作什么的方式。在很长时间以来，人们认为团队自己并无责任来回答应该作什么这个问题。”

团队不须要执行由利益相关者提出的瀑布式计划，他们能够利用双轨敏捷和设计冲刺等方法来发现有价值的产品。

原文做者｜Felipe Castro
内容编译｜Worktile
文章来源 | Worktile官方博客文章转载在请注明出处。