OKR已经尝试了3个季度了，感觉从一团迷雾里渐渐看出了点眉目，我很难说现在的一切是对的，但是总结出一些东西，为了今后更加努力的改进。既然OKR是目标，既然OKR是数据驱动的基础，那么就要坚持演进下去。以下想表达的，更多是基于自我OKR回顾的一种总结，并不是OKR完成的组成。只是像以此描述我在定义OKR的过程中所走过的那些坑坑洼洼。

OKR疑问有所斩获：

• Align目标
  这个话题其实以前是知道的，但是体会不深。直到上一次我遇到了一个世纪的问题。当时所有“基础架构”团队的OKR基本上都是1on1来制定的，基本上纯从每个人的想法出发，我这边进行了一些修改和补充。然后，后来做到一半，技术团队OKR出来了，发现之前定义的好多和技术团队OKR关系不大。包括后来又改过几次，才发现慢慢上到。所以OKR以上上下下做做右右信息透明为第一要务，为的就是让大家目标能够algin到一起去。
  具体改进方法：OKR一定要从公司级别开始定义，以此来推导出与公司目标align的技术团队OKR，这个OKR，理论上还应该回过头来和其他业务团队的OKR（针对杏树林而言，可能更多是业务团队）进行align。不过在实际目前的操作中可能并不需要从一开始就这么做，毕竟所有团队也都是为了公司的OKR完成的。因此，出于效率考虑可以继续下去。那么接下来就是小组或者个人级别的工作了。最终，通过一系列的OKR制定工作，可以保证每个季度大家都在一个方向上工作，帮助公司完成商业目标。

• 团队／个人对OKR负责
  说到OKR，就不得不说到很多技术团队的同学们反应，在公司缺乏团队感，不知道向谁汇报，谁该有权利给谁分配任务。其实OKR就是很好的一个衔接点。每一个人为自己的OKR负责，OKR的来源可能是多方面的。在初期一定会有个人帮助他订立OKR，收集需求和反馈。对于业务团队内部来说，往往这件事情比较简单，就是业务团队的技术Lead和业务本身。对于基础架构或者跨团队支持的技术同事，往往这个时候技术同事的级别本身都比较高，那就需要对技术总监团队负责。总体而言，谁帮助订立OKR，就应该谁是负责人。但是OKR一旦被制定下来，每个人应该为OKR负责。

• OKR为了制度改变
  OKR不是绩效目标。因为假设人是优秀和自驱动的，不满足这个条件的人，可以不存在于OKR体系，而实用类似KPI等其他体系。这个话题缘起于对OKR Review的一次讨论，集体内容不说。反思大概是这样。如果OKR的订立前提是，组织内每一个人都是积极的，主动的，乐于思考和勇于承担的，那么OKR的作用是为了帮助大家，对没有做到或没有做好的问题，寻求解决方案。而这种解决方案在实践中，往往就是公司的一些制度和方法的演进。也就是说，任何事情一定要寻找一种新的积极的流程去解决掉。这个前提就是去寻找当时订立OKR之后，发现执行过程中没想到的东西。然后寻找方法，避免掉没想到问题的再次发生。这样可以将OKR订立的更好。

  

时间计划值得坚持：

• 定理时间的经验
  根据Q1的经验，我们在给Q2定力OKR的时候做了一些改动

  • 为了更高效的完成OKR，我们采用组级别进行OKR定义，分为基础架构，公共服务组，PTL团队。
  • 将技术总监团队先完成OKR的制定，然后是基础架构团队，然后是PTL团队。
  • 先进行上季度OKR Review，然后进行新季度OKR制定
  • 继续讲人员限定在基础架构组＋PTL范围内，力图通过Q2完成人员培训工作

• 双周回顾的经验
  技术团队目前还无法形成单周回顾，效率过于频繁可能导致精力分散，而且实践执行中发现难以完成。主要还是大家没有养成这类工作的习惯。所以目前还是我一个人在推广，测算下来，基础架构组＋公共＋PTL的总人数目前有12个人，接下来Q2可能会有15个人，数量庞大，而且没有一个标准，所以尚无法完成扩展。但是下面的表格值得推广，确实效果很好。

  

回顾方法有待改善：

• Q1本季度感觉回顾方法有待改善。学习了一下文亮的OKR Checklist，打算应用到接下来的制定和回顾工作中。接下来会专门做一个表来进行工作。

_OKR检查表_

1. Key Result 是否能够实现Objective，套用句型：通过实现XXX（某一条具体的KR），就能促进XXX（某一条具体的O）的实现。
2. Objective 和 Key Result 描述的是达到什么，而非做了什么
3. 检查是否满足基本明确定义和可度量的要求
4. 检查是否完整反映了个人的主要工作
5. 提醒合作方、同事来给出反馈
6. 检查是否和团队的目标一致
7. 检查是否和个人能力一致 (过易和过难都不好)
8. 检查是否足够专注、优先级是否清楚

还没有完成的话题：

• OKR如何打分，如何数据结果导向

这个周发生了几件小事情。

• 首先和杨宇、张诚有过一次讨论，觉得事情推进困难，一个随访的小红点问题似乎N久也得不到解决。关于operation和admin等后台不知道谁管也不知道该怎么办。
• 在本周由于同事离职反馈了两点信息，公司创业气氛不够，总觉得推动不足，以及责任心的一场讨论。而团队的同事另一方面觉得，自己没人管，没有人安排工作和关心。
• 第三个事情是周末一早出现的一个产品事故，业务负责人很难受；另一方面其实我能感觉到，事情相关的技术同事也都是公司数一数二有责任心的人，怎么会出现这个结果呢？

以上的事实，可能很多人都会归结成一句挺伤人心的话，叫做“责任感意识不强”。于是，这个似乎就理所应当成为了一个“人”的问题，更进一步说成了“别人”的问题。但说实话，在我心里，我挺认同文亮常说的那句话，“一个事情成功了找客观原因，失败了一定要找自己的问题”。这和我的为人风格也很像，说白了，任何事情，无论成败，都应该称为自己前进的阶梯，只有这样我们才能从中成长，不断颠覆打败那个曾经的自己。

于是周末和同事的一场讨论，一场回顾会，让我好像悟出来点什么。话题开始与《格鲁夫给经理人的第一课》。这是一本像“德鲁克”系列的经典管理书。（虽然会不屑于一些陈旧的言论，但是经典总归是经典里面的宝藏，在不断的实践中会一点点露出来）

书中有提到的一个观点。作者收集了自己工作中的时间和工作内容，概括起来大概分为四类，在这些事件中，时间的分配变少是最合理的。

在我们的讨论中，我发现，其实各个公司做得越好，越必须遵循这个原则。如果以这个原则我得到了一些新的想法：

• 从我们几个所谓技术管理的四个人的思想里，我们坚持认为，管理的目的是为了更好的帮助大家工作成长和提高，而不是为了“分配任务”，这一点我坚持认为是正确的，而且会一直坚持下去。所以，团队的人觉得没人管这个事情是错误的，而是让团队理解，他们不是要被管理，而是自我管理，做和公司方向一致的，并且自己认为争取的事情。有问题向周边人询问，这才是“杏树林”的文化。
• 既然是这样，我们是一批支持格鲁夫模型的人，那么问题出在哪儿了？在我看来，我们希望尽量少的做决策，多一点给大家建议，和引导大家的事情，而管理团队目前最缺乏的，反而是上面两个，那就是“传递”和“收集”
• 关于“收集”目前还没到这个高度，所以尚待完善，但是关于“传递”这个事情我们却真实应该做许多。其实我们总希望大家主动来问我们问题，但是如果我们没有传递足够强的信号给他们，如果我们传递信息不够多，大家在做事情的时候，就很难实现问问题这件事情，因为有太多他们所不了解的东西。所以你就可以理解，为什么ThoughtWorks，这么在乎每个月的monthly update，在乎buddy／sponser的1on1吃饭，在乎早上的站会，在乎物理墙，包括在乎老大不能有自己的座位，需要到处做，在乎小组一张大桌子进行随时随地的交流。这些都是信息充分传递的表现，只有信息传递了，大家才能拥有互动。（同理，关于OKR，我们也得出了类似的结论，那就是，每一次OKR指定的过程，恰恰是公司自定向下传递信息的过程）因此，信息的快速、健康、准确的传递，是企业管理者面临的重要责任。
• 于是乎我想到了关于7-10人管理边界的问题，《How Google Works》里面提到，Google认为管理边界应该不低于7个人，而不是像传统企业不超过7-10个人的上限。我以前的理解是，这是为了扁平组织的需要。但随着理解的深入，这原来是一个非常高的管理要求，说白了，传递效率是人类社会最大的障碍（推荐看三体，或者星际争霸，来了解哲学意交流的方法）。也正是因为此，人类单人传播能力大体在7-10个人之间。如果要实现更佳广泛的传播，就要借助各种“OKR”，“看板”，“monthly update”等等现代管理方法，从而最终实现管理扁平化。

综上总结，管理扁平化，不是一个简单的规定或者想法。身为团队的Lead们，大家肩负着“收集”和“传递”信息的使命。在这方面，我们不应该把责任简单的归结到人不行，不能充分的提问，甚至没有责任心。自己的工作没有做好，才是这些事情的核心。

因此，我自己打算给自己设定一个目标，要在未来的半年里，第一，变成一个大喇叭，不断传播公司各个级别的信息，学习更多的方法，让信息传播更有效率。第二，让周边的管理者们，尤其是技术总监们，管理团队们，更佳立即信息传递的重要性，让公司文化真正得到落实。我理解这也是所谓工程师文化必不可少的组成部分。