OKR 小故事–我们在哪里失败了，我们取得了什么成绩，我们还需要改进什么。
我们是一家高速发展的互联网科技公司，我们在没有获得过相当多的资金的情况下取得了这些成绩，虽然这是我们引以为豪的事情，但这也影响了我们的技术工程历程，嗯，我们并不总是那么高兴。为了取得现在的成就，我们经常不得不偷工减料，以比竞争对手更快地交付产品。
2016年前后，我们的发展速度加快，两年内，我们的工程部规模扩大了一倍。很明显，我们不仅需要确保我们的团队遵循行业最佳实践，而且我们还需要开始积极支付我们的技术债务。经过一些比较容易或比较困难的讨论，我们得到了管理层的认同，得到了产品团队的认同，而且……至少在最初，没有什么真正的改变。
事实证明，引入这样一个根本性的变化，比如调整新功能交付和支付技术债务之间的平衡，不能仅仅通过暗示产品所有者和团队领导来实现。事实证明，有一些工程上的具体变化，需要整个组织去适应。如果你不自上而下地解释我们为什么要引入变革，规划和优先级规则如何改变，部门之间就会产生摩擦，要么停止变革，要么让部分组织效率低下。
在我们的案例中，我认为，是来自销售和关键客户管理的压力阻止了我们。总有这个下一个重要的客户，他的新功能似乎比技术改进更重要。你不能责怪这些人，因为他们的工作就是销售，”重构我们的数据处理管道 “听起来永远不会比赢得下一个客户更重要。而且如上所述，我们并没有真正尝试向任何人解释关于技术债务的那件事是什么。我们花了相当长的时间在这个死结中转圈，尝试了不同的管理技术，比如在团队层面上强制执行技术债务专职能力，尝试与专职工作组合作，但最终，一个系统的、可持续的解决方案来自一个意想不到的方向。
我们的第一次 OKR 之旅
2018年，我们决定引入OKR，以提高我们工作的可见性以及管理层和团队之间的一致性。我们为每个开发团队定义了即将到来的一个季度的技术改进目标，但是……我们甚至没有达到回顾成就的地步，更没有提到定义下一个季度的新目标。同样的事情也发生了–我们忙于交付新功能，忙于解决技术问题，以至于没有找到时间开始解决这些问题。从时间的角度来看，我相信我可以很清楚地指出我们当时所犯的错误：
我们没有完全投入到OKRs中去。我们决定用它们只覆盖工程主题，而让产品优先级保持原样。而我认为引入OKRs不仅需要产品和工程之间的协调，而且关键是要让整个组织都能看到这样的变化。
我们没有定义OKRs跟踪和更新的一致和迭代过程。这是事实，我们的团队正忙于交付又一个功能，但我们并没有一个明确的流程告诉我们，例如 “这一天，所有团队都需要开始起草下一季的OKR”。
我们决定对团队和个人都引入OKR，这似乎是太多了，无法一蹴而就。我不认为这是我们变革的杀手锏，但在引入更深层次的组织运作方式变革时，专注于一件事总是更好。
回顾这第一次的尝试，虽然我不会说这是失败的工作。公司技术工程的人知道了什么是OKRs，这个想法被灌输到了我们的脑海里，我们为后来的成功打下了基础。
从失败到成功的经验总结
两年后，在2020年初，我们又在为另外一些问题而苦恼：我们在讨论如何提高我们的中期计划对工程师的可见度。这听起来并不像你从OKRs支持者那里得到的主要承诺，但没错，我们的思路又回到了对我们团队的季度目标制定上。这次我们做得比以前更好一些。我们花了一些时间来描述这个过程，从一开始，我们就和我们的产品团队一起研究这个变化，我们向整个组织清楚地解释了这个变化。
现在我们的OKRs流程已经到了第三次迭代，我们还有很长的路要走，要稳定和改进，但这次的尝试似乎是成功的。与第一次尝试相比，我们改变了什么？我在上面已经非常简短地指出了这一点，但让我们仔细看看：
我们决定全力以赴，用OKRs覆盖产品和技术工作，通过这种方式让我们的开发团队有一套一致的优先级。老实说，现在听起来这是唯一的办法，但我们第一次并没有这样做，所以显然你可以走错。
从一开始，我们就创建了一份文档，描述了我们如何理解OKRs，以及逐季设置和更新OKRs的实际程序。我承认，第一版的文件并不是那么好，我们在这一年里改进了很多，但是是的，有这样一个东西是应该的。
我们投入了更多的时间来阅读OKRs，寻找好的资源，并与我们的工程师分享。同样，我们一开始的学习资料有限，但我们在随后的迭代中进行了改进。
我们决定尽量保持轻量级。我们明白，所有的团队都已经有了自己的流程，所以OKRs需要被组织在这些流程之上的薄薄一层，给团队提供关注点，影响他们的优先级，但不影响他们已有的工作方式。
我们决定不为我们的工程师引入个人OKRs。但我们并没有禁止它们–我们的团队经理可以用他们喜欢的方式为他们的团队成员表述成长目标，但个人OKRs不是我们的重点，我们决定不对此进行规范。
我们决定运用持续的流程改进原则。每个季度我们都会尝试用专门的调查问卷收集所有团队成员对OKRs流程的反馈，我们会分析结果并讨论如何调整流程。通过这种方式，我们让描述实际流程的文件变得更加清晰和简单，现在我们正在尝试跨团队OKRs的协调工作。
引入OKRs后，最突出的效果是我们在启动时都没有想到的改进，这就是我们工程部的指导性提高了。突然发现，我们手中有了一个工具，可以直接将产品和技术策略传递给团队，从团队那里获得策略的反馈，并在OKRs的执行阶段协调跨团队的工作。
当我们变得很好地引导和透明化后，有些事情原来比以前更容易了。直到我们决定用我们的新武器来对付我们的老朋友–技术债务，我们才真正花了很多时间。我们开始要求我们所有的开发团队提供与技术债务相关的OKR，突然间，我们发现自己已经连续三个季度，我们所有的工程团队都将他们的重要部分能力漂亮地奉献给了明确定义的技术挑战。
是的，当然，我们的代码库还没有那么大的变化，但我们还处于相当早期的过程中。我们有时仍然有，而且可能永远会有关于优先级的激烈讨论。但战略是透明的，优先级规则和计划是可见的。在几分钟之内，每个有兴趣的人都可以了解所有团队是如何为战略做出贡献的，我们这里说的是10多个软件开发团队。
另一方面，我们还没有完全完成这个过程，但实际上，我们从来不想这样，所以让我简短地解释一下这些天我们正在研究的事情，并希望在即将到来的迭代中改进：
帮助各团队确定跨团队的OKR。我们原本以为，各团队需要相互交流，以了解他们是否愿意为共同的目标而合作。随着时间的推移，我们了解到，在这方面的一些基本支持会很有帮助。
帮助团队执行跨团队的OKR。我们正在尝试用一种很轻的项目管理结构来处理这类举措，但它应该是作为团队已经遵循的流程之上的一个超薄层，通过跨团队的沟通和协调来完成这些流程，而不是改变它们。
最后但并非最不重要的是，我们需要改进如何定义公司的目标，我们的工程团队会与之保持一致。我们在之前的迭代中已经有了，但我们需要再研究一下，因为我们从季度调查中了解到，方向并不明确，所以我们要么是没有做好沟通，要么是实际的目标没有表达得那么好。
引入 OKR 的注意事项
最后，我非常相信，我们的案例通过两次尝试引入OKRs，使我们的故事变得更加有趣，因为我相信我们非常清楚为什么我们在第一次尝试中失败，为什么我们在第二次尝试中成功。考虑到这些因素，我建议在你的组织中引入OKRs时要注意以下几点：
确保OKRs过程是唯一的机制 为你的团队定义优先级。
教育你自己，教育你的员工了解什么是OKRs。
准备一份文件，解释你的组织如何理解OKRs，并准备一份文件，逐步解释你的OKRs更新过程。
在最初的迭代中要注重重复性。当然，OKRs从一开始就超级重要，但可重复性是你成功的关键。
让它透明化。确保OKRs和实际的成就对你组织中任何对它们感兴趣的人都是可见的。
保持轻松，确保人们知道你希望这样做! 正如前面已经提到的，团队已经有了他们的流程，在上面添加沉重的东西不会为你赢得你的人的想法。
明确地思考你要如何解决跨团队的OKR，检测它们，然后协调它们的工作。
最后但最重要的是，一定要引入某种持续的流程改进机制，比如大团队的季度调查，小团队的回顾性会议。
综上所述，OKRs 似乎是另一个管理流行语，但对我们来说，它是一个游戏规则的改变。我们得到了改进的可引导性，改进的透明度，以及更好的水平和垂直排列。听起来很不错，但也要记住，OKRs 并不是万能的。你的产能不会神奇地增加，你的优先级不会得到神奇的解决，你的工程挑战还是要靠你的工程师来解决。但我敢说，你会得到某种神奇的触动，这就是提高你的员工的积极性，一旦他们得到了我上面指出的所有好东西，他们会更开心。我希望通过这篇文章，我也能帮助你把这小小的魔力带到你的组织中去。享受这段旅程吧!