本文主要是介绍OKR文化：OKR实践误区总结，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
虽然大家都对谷歌运用OKR的模式很熟悉了，但是不同的企业类型和企业文化下真正去实践OKR的时候还是会有各种各样的疑问。很多企业都希望彼此之间可以互相交流一下真实的实践经验，看一看自己的问题再别人的企业下是如何去解决和采取行动的。故在此总结OKR的一些误区希望能为在此处有疑问的实施团队提供思考方向。
设定OKR时要确保这个OKR在规定的时间周期内可以完成
制定OKR时最不值得去担心的问题就是这个OKR是否能百分之百完成。OKR本身是具有挑战性的，即一个OKR下的关键成果应当是有50%到70%之间的信心去完成的衡量指标。太高了意味着OKR太简单了会失去其促进企业实现挑战的原目的，太高了从一开始大家就会把它仅仅当做一个口号起不到实质性的作用。一个周期结束，无论OKR是否完成都应该进行复盘总结结束这次OKR，若该OKR仍旧是需要继续努力的对象，那么可以以当前获得的成果为高度制定新的OKR；若当前有其他更重要的事情要做，那么就应该降低其优先级去做最重要的事情。
用一个OKR向上关联多个OKR的模式来实现OKR的级联
员工的OKR向上关联的时候是否应该关联多个OKR，我的理解是不可以的。我们强调一个OKR着重于实现一个最重要的目标，那么一个下级的目标方向又怎么能完全重合于多个不同的上级OKR呢？一个实际的执行动作可能会同时支撑到两个不同的指标上，但是一个OKR是不应该同时去支撑两个上级OKR的，如果这样做了很有可能是你的OKR所要努力的方向范围超过了其中一个OKR，那么上级OKR如何去对下级的OKR进行管控呢？
把OKR逐渐变成O和KR负责人才会关心的事情
一开始启用OKR时所有人都兴致勃勃，因为这是一种全新的管理方法，所有人都期望它能带来改变。逐渐的，有些管理者开始发现真正关心OKR的人只剩下O和KR的负责人了，其他人只是默默地做着KR负责人分配下来的任务，事情好像又回到了用指标去管理大家的模样。为了打破这种状况，建议可以在KR下让所有的参与人去制定属于他们自己的需要自己去挑战的执行计划。每一个人都希望自己努力去做的事情能够被大家看见，至少能够被上级看见，这样才能更有动力的去挑战去展现自我。如果每一个人都能实现自己执行计划所预期的挑战，那么KR的挑战指标也能被更容易的实现。
只关心OKR的进度是否与预期相符合
作为OKR的管理推进者，最大的忌讳就是只关心OKR的进度。很多人会这样想，这个人要在这个时间段做这件事情，我只关心我为此付出的酬劳是否得到了想要的进度，至于他如何实现的不影响对我并没有影响。但是事实并非如此，如果一个人原定每天8个工时完成的工作变成了每天10个工时才能完成，那么多出来的这两个小时带来的很有可能是工作质量的下降。虽然进度没有出现问题，但是最终产出的质量打了折扣就偏离了我们最初想要实现的目标。
OKR推进过程中必然会遇到各种各样的问题，任何无法预估的因素都会改变真正去实践的方式，如果您需要请关注小编，小编会持续为大家总结更多的OKR实践经验。
这篇关于OKR文化：OKR实践误区总结的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
