上周对团队的进行了OKR复盘，暴露了一些问题：

一、要及时对OKR内容进行跟踪及修订

本季的OKR只在最初设定的时候沟通过一次，然后整个Q都没有再跟进修订过，导致有一部分KR在季末复盘时都失效了，有的是因为还未建立起度量体系，比如【接口测试制品故障率<=10%】，【线上缺陷免疫率>=90%】，在复盘时，发现这些指标完全无从下手去度量，所以没有办法确认这个OKR完成度。如果能以周或者月为维度去定期对OKR进行跟踪和检视，及时对无效的KR进行删减，在季度结束复盘时应该会好很多。

二、要描述”影响”而不是”动作"

比如有一个定的不太好的KR【发布鹦鹉螺2.0版本】，因为真正重要的不是发布这个动作，而是这个动作所带来的影响。为什么说发布鹦鹉螺2.0版本很重要呢？更好的说法应当是“通过发布鹦鹉螺2.0版本，提升20%的产研交付效率”或者干脆简单地说“提高20%的交付效率”。

三、要考虑OKR的类型

复盘OKR的时候，发现在完成度上，业务测试组的OKR基本上全绿，工程效率组的OKR是基本是黄色和红色。

一开始并不明白究竟是哪里出了问题。后来在看OKR相关的书当中讲到，OKR其实有两类：承诺型OKR和愿景型OKR。

承诺型OKR 是指我们必须实现的OKR，是我们甘愿通过调整工作时间和资源配置确保优先实现的目标，承诺型OKR指标预期得分应该是100%。

愿景型OKR 则表现了我们对未来变化的一种预期。我们可能并不清楚如何到达那里，以及实现这一OKR所必须的资源，愿景型OKR指标的预期得分通常是70%。

那么对于业务测试组来说，以O【全面保障测试质量】其中的KR【缺陷探测率>=97%】来举例，就是一条承诺型OKR，因为线上服务质量是质量团队最核心的事情，而且我们有明确的实现手段和路径去保障，所以预期得分就应当是100%。而对于工程效率组来说，O【进一步提升环境可用性】KR【环境资源使用效能提升50%】，就是一条愿景型OKR，因为实现路径和所需资源需要在实现的过程中不断摸索，同时不能为了一味的缩减环境资源使用而影响了业务测试进度。

四、要明确意义，达成共识，并全力以赴

我们业务测试线其中有一个KR是【团队每人都要输出所辖业务分享或文档】，这条KR定的不太好，导致我们有leader为了KR达成，赶在最后一刻，“每个人”草草的补上“一篇分享”来应付交差。这件事情我负主要责任，因为在一开始定KR的时候，就没能和大家在对KR的认识上达成一致。

也希望各位思考一下：我们是否在做一些对我们每个人都很重要的事情？我们是否发自内心地认为我们做的工作是真正有意义的？做这件事情背后到底为我们个人、为团队带来什么？这些如果想不明白，大家去做这些事情永远是为了“数量上的达成”而已。输出可读性差、毫无价值的文档，还不如不写，这种豆腐渣工程，是对团队不负责，更是对自己不负责。