【探索与启程】：《Google OKR实践手册》发布方
误区一：混淆指令性与挑战性OKR
指令性OKR和挑战性OKR混为一谈，会增加OKR达成的风险。指令性OKR需团队百分百投入以确保完成，而挑战性OKR则是对团队潜能的挑战。混淆两者会导致资源分配混乱，影响团队士气。
误区二：例行公事的OKR
若所制定的OKR都是轻松完成的工作，而非真正追求的目标，这样的OKR失去其意义。团队应追求真正想要实现的事情，而非简单的任务完成。
误区三：挑战性的OKR缺乏挑战
制定挑战性OKR时，不应基于假设和乐观估计，而应基于解除限制后的理想状态。真正的挑战在于描绘出最终状态，并朝着这个方向努力。若挑战过于简单明了，那么挑战的意义何在？尝试询问客户真正想要的是什么，看看你们的挑战性OKR是否达到或超越了他们的期望。
误区四：不敢挑战的OKR
一个团队的资源精力有限，但不应止步于指令性OKR。挑战性的OKR应当超出当前资源范围，否则无法实现真正的挑战和成长。若团队能轻易完成所有OKR，这可能意味着资源的浪费或管理层的不当分配。这时需要上层管理团队重新分配资源给更具潜力的团队。
误区五：“没人在意”型的OKR（LowValued Objective, LVO）
OKR必须体现清晰的商业价值。那些完成后的成绩无人关注的目标不值得投入资源。制定目标时需清晰描绘其商业价值，如通过描述经济收益、用户体验改善等来吸引关注和资源投入。确保OKR的达成能够带来实际的价值和收益。
误区六：KR不足以支撑O的达成
OKR包含两部分：O描述期望结果，KR描述达成结果的过程。若所有KR的完成不能保证O的达成，这是常见的陷阱。团队应避免躺在舒适区，增加必要的承诺和资源投入。确保所有KR都能支撑O的实现，并及时暴露风险以便及时调整策略和资源分配。若所有KR完成仍未能达成O，应重新评估和调整KR以确保目标的顺利实现。在制定OKR时，务必确保它们具有明确的商业价值和实际可行性，以便更好地推动团队的进步和发展。
OKR查阅、解读与实施
对于指令性OKR：
团队需高度重视并及时调整其他事项的优先级以确保指令性OKR的百分百交付得分必须为满分一确保目标的实现并体现团队的承诺与执行力。如果团队无法在指令性OKR上达成预期的1.0分目标，那么团队必须及时向上级报告这一风险。这一点至关重要。无论是因分歧于OKR的设定，对优先级的安排有异议，还是因时间、人员或资源的分配不足而无法实现承诺的OKR目标，都应毫不犹豫地选择升级管理层次进行上报。这将有助于管理层提前制定应对策略，有效应对潜在问题。
由此可推断，每一个OKR的实施都可能涉及某种程度的升级，因为可能需要基于已有的优先级或承诺进行调整。那些无需任何修改的OKR，虽然可能被视为例行公事，但它们不应被视作新的OKR而轻视其重要性。一旦未能按时达成目标分数，我们应进行事后回溯分析，这并非为了惩罚团队，而是为了找出问题的真正所在——是计划制定不合理还是OKR执行存在问题。对于未来的指令性OKR完成度，这种分析能极大提升团队能力。
关于指令性OKR的一些示例包括：确保服务满足SLA（服务水平协议）、预先发布特定功能或在指定日期提升基础设施系统的性能以及以一定成本制造并交付一定数量的服务器等。
而对于挑战性OKR，它们被设计为需要团队在特定季度付出额外努力才能达到的目标。这些OKR的优先级明确了团队成员在完成指令性OKR后，还需要在哪里投入额外的时间和精力。当团队面临多个挑战性OKR时，应优先完成优先级较高的OKR，然后依次完成其他挑战，以确保资源和精力的集中。这些挑战性OKR及其优先级应一直列在团队的OKR清单上，直到完成。如果必要，这些OKR可能需要跨越多个季度来持续推动其进展。
如果一个团队拥有充足的专家资源和时间投入，那么将挑战性OKR转交给这样的团队可能更为合适。团队管理者需要定期评估挑战性OKR的资源需求，并确保业务需求的满足。管理者不应接受所有的资源请求，而应优先在团队所有指令性OKR完成后进行资源分配和调整。
本文首发于Bob Jiang的博客，转载请注明出处并联系作者Bob Jiang授权。 |
