技术部门引入OKR
Last updated
Last updated
Objective and Key Result(OKR) 的意思是目标与关键成果，这是一套组织管理机制,原创于Intel，并在1999年由 John Doerr 介绍到了成立时间不到一年的Google。后者采用之后，一直在贯彻行。
Eric Schmidt 和 Jonathan Rosenberg 在 《How Google Works》（中文书为《重新定义公司：谷歌是如何运营的》） 中第六章对OKR有一段简单的介绍，标题是“制定（近乎）遥不可及的目标”。文中介绍了跟常见的“低承诺，高实现”的管理不同的OKR具有如下的特征。
完备的OKR不仅制定了大的目标，也确立了易于衡量实现的“关键成果”
合理的OKR应该有一定的难度，达到其中所有的要求应是不可及的。最佳的OKR不但有挑战性，还要切合实际。
OKR系统应该人人可用。
OKR需要打分，但这分数不做他用，其唯一的用途，就是让员工诚实地评判自己的表现。
OKR并不非包罗一切，只有那些需要特别关注的领域以及不做出额外努力难以达成的目标，才用得上这个系统。日常工作不需要记入OKR
对于OKR是什么的详细介绍，有兴趣的朋友可以看一下以下的介绍，这里不详细的展开。
这是Google内部使用的打分系统，你也应该试一下
如何使OKR在你的创业公司中真正的有效 -
Google OKR 系统 -
OKR基本知识 国内的一些文章，基本上是一些翻译和整理，也可以做参考：
OKR比KPI好的不只是Bigger
在我负责的公司技术部门，团队构成和配置是比较复杂的。这不仅体现在分布式的团队，也体现在不同地点的团队成员的文化上。在东欧的两个团队不是在同一个国家，对北京的团队来说，他们都是远程接入办公的。而且，在同一个团队中，也并不是所有的成员都在同一个办公室。北京本地的团队，负责的项目也是多样化，有web开发，有app开发，有测试，还有devops开发。这种地域的分布式(时区的差异)、文化上的差异性、语言的差异给团队的沟通管理带来了很大的挑战。虽然借助于现代化的工具（比如slack，trello)，沟通的问题能得到一定程度的缓解，但是，要真正的把各个团队打造成一个团队，致力于同一个目标，以便有效的提高执行力，减少沟通成本，始终是我们的痛点之一。
为了解决这个问题，在过去的半年中，我一直在尝试把OKR这套系统引入到我们的技术部门中。写这篇文章的目的主要是为了总结，同时也为那些想在公司、部门推行OKR的朋友做个参考。 一个题外话是，前一段时间看讨伐KPI的微信文章，看到读者留言，声明OKR跟KPI一样的不受人待见。也希望这篇文章能为他们提供一个新的视角。
我们知道这样一个管理系统的推动，离不开公司高层的支持。在技术部门推行之前，跟公司的管理层介绍了OKR是什么，为什么我们要采用OKR，我们具体推行的计划。公司的CTO对技术部门推行OKR全力支持，为后期的执行奠定了基础。
在正式推行之前，我们在不同的场合，给大家介绍OKR的概念，比如在公司季度分享会上，在每周回顾会议室上，甚至在Daily Scrum上。 由于有地区和时区的差异，对于OKR的培训至少进行了英语和中文两次正式的培训。后来发现，培训再多，也没有真正试用给人的印象深刻，促进真正的理解。于是，我们在去年第三季度组织了一个OKR的试运行。
在试运行时，我们只设置了团队的目标。我们团队的目标跟我们项目管理中的软件开发指标紧密相关，由于我们采用的是敏捷迭代式开发，每个迭代是一周，这样，每周都会有一个OKR打分。在整个季度中，所有迭代打分的平均值就是该季度的OKR打分。这种方式，避免了团队成员只追求短期的效果，而需要考虑整个季度所有迭代都要保持比较好的表现，反应在有比较好的软件开发指标上。
拿工作流效率来讲，规定基准线0.7表示效率能达到80%，然后，OKR打分每变化0.1，对应着效率的5%的改变，比如，0.8就对应着85%的工作流效率。同样的，我们对于质量（Quality），生产周期（Cycle Time）也都有相应的OKR评分标准。更重要的是，这些评分，都基于所使用的项目管理工具，经过了二次开发，做到自动采集数据，自动打分。自动化能有效的减少管理方面的开销，并能给团队即时的数据反馈。
这样，在周迭代回顾会上，除了分析当前迭代的软件开发指标，团队成员也要看一下OKR到目前的打分，从短期和长期两个方面来给开发团队相关的洞见。
在试运行之后的第一个季度，在OKR中引入了个人方面的目标和关键成果。这些部分由员工个人根据自己的职业发展来设定，经过与Team Lead或者经理讨论之后来最终确定。讨论的过程确保了员工个人的发展目标与公司和团队的目标是一致的。比如，有的员工同事英语水平需要提高，在该季度就制定了提高英语水平的目标，并确立了要认识记住多少个单词的关键成果。OKR设定的过程大概要持续2周到3周的时间，在这期间，员工给与时间，真正思考在当前季度，需要关注在哪些方面。
我们十分注意，不把OKR跟绩效直接建立联系，一次一次的抵制了HR部门相关的想法。原因非常明显，只要跟经济利益挂钩，每个人就都不会大胆的设定目标，而变得保守。OKR的设定和打分就会变得十分敏感，整个流程会拖沓冗长，OKR的已经脱离了其精神，变得跟KPI一样"可恶"。这可能是有些人认为OKR只是KPI换了一个名字，没有什么本质区别的原因吧。
我们利用OKR这种机制来构建持续性学习的组织。每个季度，对于每个职位角色，管理层都会帮忙列出需要学习的书籍。这样，在知识学习和分享这个目标中，每计划读一本书都有一个单独的关键成果，打分的方式很简单，就是按照书完成的百分比来计算。
每个同事的OKR都是公开透明的。这样带来的好处是，你可以借鉴别人的计划，为自己指定目标做参考，另外，自己的目标被别人了解之后，无形中会有一个同事之间的压力，促使自己关键成果的达成。一个团队的Scrum Master虽然有推行轮班制的计划，但是之前基本上由Team Lead来兼任。在一个季度的OKR设定时，一个同事在自己的OKR中设定了一个目标，要更多的参与到团队敏捷站会的组织中来。在每日站会的时候，别的同事字在了解到他这个目标时，就推荐他来做Scrum Master，整个过程的沟通非常清晰。
另外一个例子是我们的一个同事给自己设定了一个更加充分了解和掌握所有团队新产品特性开发的目标，为了帮她更加容易的实现这个目标，我跟产品经理沟通，要求产品经理在发起新产品特性开发评估会的时候，确保邀请她参会；跟Team Lead沟通，当评估会没有邀请她的时候，确保及时纠正，并把她的工作安排进行了适当的调整，以便她有时间来参与到这些评估会中。这些活动快速的发生，都是因为OKR对目标的明确化，减少了沟通成本。
在经过2016年第一季度的试运行OKR，我们收到了非常多的反馈，比如，对KR的跟踪比较困难，KR设立的不太恰当，KR执行忘记了，有些KR中的绝对数字不太合适。看起来这些反馈反应了团队成员对于试行的OKR有了建设性的反馈，但是，我们也看到了这些反馈背后，是团队成员对于OKR这个制度本身还没有完全接受，这是最重要的问题。
OKR协调员制度可以在1） 和3）这两个方面起非常重要的作用。这些协调员拥护目标设定的管理方式，他们是第一批OKR理念的跟随者，并能积极的参与到OKR的各项活动中。他们愿意学习和了解目标管理的意义，并能协调所在团队，更好的遵循相应的OKR流程： 目标设定，审阅，执行和打分的过程。Team Lead有时候只关注技术和项目方面的事项，忽视了OKR的协调组织，这样造成的后果是，尽管组织了多次OKR的Team Lead会议，但是有些理念和做法并未能顺利的让团队成员充分理解。当我们引入OKR协调员这一角色之后，这个问题得到了有效的解决。OKR协调员有固定的会议（半个月一次）。这个会最主要的功能是讨论技术部门对于OKR流程的计划，以及收集团队成员的各项反馈。在每日站会上，OKR协调员会带领大家讨论OKR执行的相关的事项，提醒成员有效执行设定的目标。经常的提醒，慢慢的就把OKR融入了日常工作中，变成文化的一部分。
要想取得成功，需要选择合适的工具。我们在这个方面，一直在探索。第一次试用，我们使用trello来管理。主要原因是trello可以帮助很好的记录每个人OKR的状态（目标设定，审阅，执行和打分).但是，trello缺乏对于关键结果的跟踪特性。接下来的季度，我们在trello基础上，增加了Goolgle docs，通过Spreadsheet来记录每个团队，每个个人的目标和关键成果。通过使用API importrange，我们做到了集中管理团队目标，并使团队目标和个人目标在同一个文档中展现。但是，这两套工具结合的使用，总体的感觉是使用不够方便。接下来的计划是评估和选择专业的OKR管理工具。
我们的OKR系统已经推行了半年多，现在很难说成功，但是，像敏捷开发一样，我们都是本着反馈，迭代的方式来发展的。随着更方便的工具的引入，工程师二次开发的OKR自动计算功能，以及OKR协调员制度的推行，我们认为OKR系统正朝着一个正确的方向发展。
根据，我们了解到能成功推行OKR，有几个关键因素， 1） 公司或者团队坚定不移的相信目标管理的重要性。 2） 一个公司需要一个OKR的牧羊人，此人会教育团队，跟踪OKR的进程，推动解决OKR系统中任务的问题。这样的角色，可能是COO，也可能是人事总监。或者技术部门总监 3） 公司必须把OKR作为文化的一部分，OKR出现在公司的日常管理活动中。