研发管理圣器：Agile×DevOps×OKR
一、让人头疼的研发管理
| 苦恼的张总
我们有一位朋友张总非常苦恼。
有一天，我们问了张总一个问题：“您公司的所有人都知道公司今年的3个目标是什么吗？”张总答曰：“那当然了。我们天天高层中层执行层开会都会反复强调，大家肯定都很清楚。”张总也是Worktile软件的用户，于是我们提了这么一件事：“张总啊，咱们可不可以做个小调研？Worktile有个投票功能，我们设计10个选项，除了公司的3个目标外，再添加7个干扰项，您公司的员工可以用半天时间投票，选出他们认为公司今年最重要的3件事。”
投票结果如上，好像有点儿一言难尽……公司的3个目标，最好的1个在投票中占22%，另外2个仅占7%和4%。也就是说，这个100多人的公司，大概只有二三十个人和张总在同一个方向上。
张总很苦恼。
可读到这儿的李总、刘总、赵总等等，不妨自己也可以试着做一下这个小调研，相信你们也会有同样的苦恼，张总并不孤单。
这些“跑偏”的同事们来自各个部门，包括研发部门。在一个以产品和技术为驱动互联网公司，“灵魂人物”研发工程师们像勤劳的工蚁一样兢兢业业忙着低头敲代码，抬起头却发现，努力走的每一步，竟是离整个蚁群的行进方向越来越远。
| 研发管理难题
研发管理的难题不止于此。常见问题还包括（慎读预警，以下内容极可能引起研发管理者头疼不适）：
1. 难以KPI化与考核的工作。研发团队如何做绩效管理？又该如何考核？以2/8法则为基底的KPI适用于劳动密集型工作，比如一条流水线上的工人，用关键过程KPI规定好他的作业流程方法，产出就是标准的好结果。而程序猿攻城狮属于知识型工作者，Bug数、功能数、代码行数、营收或996，显然，KPI很难K动他们好好工作，也并不是足够客观有效的绩效评价指标。
2. 离代码很近离用户很远。这个“用户”包括2个层面，一是内部用户，也就是“张总”为代表的公司核心高管，这些用户需要被满足的需求是“公司战略目标”（举个英特尔的小栗子，英特尔一度面临战略转型，业务从存储芯片转到微处理器，在这时，研发团队的工作应服从整体战略需求）；二是外部用户，也就是产品服务的消费者。研发团队通常专注产品，容易忽略考虑以上2大用户需求，公司也往往缺乏相应机制驱动研发团队“走出去”，避免产品研发成为“自嗨”。
3. 跨部门战争。 这个问题倒也不仅限于研发部门，很多公司的职能架构体系下都是只有“小部门”，没有“大团队”，各个部门间资源和工作相互对立难以协调，对彼此的工作不关心不了解不理解，每个部门都有自己独立的目标缺少协调统一，相互看不惯。常见的情形就是销售、产品、运营部门的同事觉得研发团队很傻叉，做的产品根本不考虑客户需求太烂没法儿卖；研发团队觉得这帮人才傻叉呢，天天提些脑残的需求，根本不知道这个产品多牛逼多伟大。
| Worktile的尝试
作为一家互联网公司，Worktile也曾受这些通病所困，做了非常多的尝试，包括组织架构与职级体系调整、成立技术委员会与用户体验委员会，实行Polish Week和研发下乡活动等。在管理方法上，2015年我们接触并尝试OKR，2017年Worktile 6.0版本上线，成为中国首家将OKR以软件形式落地的企业协作平台，由此，还孵化了 W orktile M anagement C onsulting这样一支很“土”的咨询团队，帮助客户认识OKR并在企业内部一步一步落地OKR。 至今，WMC团队已服务180+中国企业，包括龙湖、链家、百度、新浪、中体彩等。 对于OKR如何实施落地、如何用于研发管理、能够在研发管理方面产生怎样的作用等，积累了一些经验。
二、Agile×DevOps×OKR
| 什么是OKR？
首先简单同步下什么是OKR。OKR是“Objectives（目标）”与“Key Results（关键结果）”的缩写，即目标与关键结果管理法，起源于英特尔，盛行于硅谷谷歌、领英、Facebook、Twitter等公司，2014年底左右进入中国，目前，腾讯、华为、新浪、百度、今日头条、龙湖、链家等公司都在OKR。
很多刚接触OKR的朋友在写OKR时总会写成如下图所示的样子。然而，这是工作分解及KPI，并不是OKR。
O是目标，说明我们要达成什么，承接战略而来，是整个团队的方向；KR是O的标准，KR的出现说明O的达成 。举个栗子。
马爸爸给湖畔大学定的目标是“10年以后湖畔学员能成为对中国经济有影响力的企业家”，怎么知道这个目标达成了呢？通过KR来定义，比如10年后的“中国10大企业家”评选中湖畔学员就能占3个，当这个结果出现，可以说明目标达成了。
然而很多人写KR可能会写成下图。
这些不是KR而是过程，这些事做了有可能KR达成也有可能KR没进度。KR没进度的话，说明做的事没有意义，应及时分析调整，使目标能够逐步达成。
目标从哪里来呢？目标最根本从公司的愿景而来，是公司几十年后希望成为的样子。通常公司会按年度制定战略，也就是今年从那个方向着手重点做什么事，再根据当前公司位置与所处环境设定周期性OKR，而不是做没有意义的目标拆解，每个周期OKR类似一个里程碑，每一个小目标达成都让公司离战略目标的实现越来越近。
整体如上图所示。 愿景与O是公司的方向，KR为O的达成标准进行定义，再通过一系列Task（项目与任务）的实施促进O的实现。也就是说，愿景和O解决去哪儿的问题，KR和Task解决如何到那儿的问题。
| 研发管理OKR实例
在简单的认知同步后，我们通过一个实例来看OKR是如何应用于研发管理、促进内部目标对齐与跨部门沟通融合的。
比如，在公司战略之下，今年一个公司级的O是成功发布Worktile8.0版本。什么叫做“成功发布？”KR对此做出定义。
公司级OKR确定后需要确定各个部门级的OKR了。部门级OKR制定时，不是把公司级KR拆解下去，公司级OKR是CEO或在这个栗子中可能是CTO负责，各个部门的负责人看着这个公司级的O，想想他们定什么目标能够对这个目标的达成产生贡献，由此制定部门级的OKR。
比如，研发部门的目标是高质量完成产品研发工作；销售部门通过提高全员对新版本的认知让大家能够更好地了解新版本，从而对父目标产生贡献；客户成功部门的老大可以请客户帮忙测试提供有价值的客户反馈，也能够对父目标产生贡献；然而人力资源部门的老大看着这个目标，想了想好像不能很好地承接，那么他可以不在这个父目标下建立子目标。个人级OKR制定同理。
OKR定好了，再往下就是Task执行过程了。
比如一个公司级的OKR下，为了达成“上线第一周，新增5000 DAU”这个结果，可以通过举办一场高质量的产品发布会这件事去促进结果的达成（但这可能只是Task之一）。我们可以在“项目管理”这个功能模块中“市场部”的项目下建立一个“产品发布会”的子项目，这个项目包括一些列跨部门的、分工明确、权责清晰的任务，比如客户邀请可能是销售部和客户成功部的同事负责，前期宣传可能是内容组的同事负责，产品展示是CEO和CTO负责，PPT美化是UI部门同事负责等等。我们把这个环节叫做“PM（Projectization Management，项目化管理）”而非传统的“PM（Project Management，项目管理）”。
从OKR到PM，整个过程是去中心化非常扁平了，传统的职能部门壁垒被打破，集体目标非常清晰，并将目标执行过程从KR到PM一步一步落地，建立跨部门的分工协作促进共同目标的实现。在这个过程中，目标制定环节促进了上下级与部门间的沟通，帮助大家建立了全局观，使员工对共同的目标及彼此的工作与联系有了更深的理解，大家不再是被动地“领任务”或为了KPI而KPI盲目凑代码数功能数等，而是在子目标的建立过程中充分发挥了主动性，考虑如何做能支持上一级目标实现的真正有价值有意义的事。从目标到执行，整个过程不再是割裂的团队工作“孤岛”，而是真正实现了团队协作。这样的团队协作下，销售与客户成功同事的参与帮助研发团队更好地理解外部客户需求，在公司战略方向的统筹下也更契合内部的客户需求，这一层次的沟通和理解进一步促进更“接地气”从而更有希望成功的产品塑造，原来的部门战争、离用户很远的问题得到解决。
对于OKR的作用，补充两个我司新鲜的小栗子。
一个是昨日我司公告群突变“夸夸群”。销售和研发同事互骂互怼的屡见不鲜，我司就很奇葩了，都是主动互夸的。
事情如上，其实就是一位销售同事提出的产品需求影响到重要客户的回款，我们的研发总监被“催”时并没有傲娇拒绝，而是说会想办法加急处理，还说“只要是客户的问题就没有小问题”。
前两周在爱奇艺和客户说“我们内部从来不发一封邮件”客户觉得很不可思议，这件事在很多研发团队看来也很不可思议。因为有OKR统领，大家不会说“这个跟我没关系”，而是看到自己的这一项工作对其他部门的影响以及与公司财务目标之间的联系，所以积极地协同配合。
另一个栗子同理。昨天刚落地上海，我们的销售负责人打电话给我拉进了一个项目，是一个大客户的商务流程需要填写一份英文调查问卷让我协助。Worktile没有复杂的流程审批与领导协调，而是简单确认后立马和相关同事建立项目组，包括这件事可能还需要其他部门的小伙伴参与，他们肯定也都会和我一样积极响应，没有“这不是我们部门的事”这一说，而是清楚这件事对公司财务目标的意义尽力配合。在Worktile，没有“小部门”，只有“大团队”。
| 研发管理圣器：Agile×DevOps×OKR
在高绩效研发团队的打造过程中，很多研发管理者在团队引入Agile与DevOps。Agile根植精益，核心之一是MVP（Minimum Viable Product，最小化可用产品），即“快“与”Kaizen（持续改善）“，根据用户需求反馈不断调整现有产品快速迭代。DevOps通过开发团队与运维团队的融合，打磨研发全流程管理机制，促进研发全过程的协调与沟通，以灵活全栈角色配置与自动化手段实现高效持续交付，打造结果导向的HOT（High-Output Team，高产出团队）。OKR则从MVS（Mission，使命/Vision，愿景/Strategy，战略）而来，以公司整体目标统领包括研发管理在内的所有工作，使员工看见共同的目标，并以PM打破部门壁垒，促进相互理解与团队协作，使高效能团队的努力用在正确的方向上。西方文化中的“圣”往往三位一体，就像哈利波特中老魔杖、隐形斗篷与魔法师构成的死亡圣器。以Agile为方法，DevOps形机制，OKR作纲领，让团队从日常工作中抬起头，不光忙着走路，更重要的是朝着正确的方向。三者相辅相成，从不同维度驱动，成为打造极具“杀伤力”研发团队的“DMT（Development Management Trinity，研发管理圣器）”。
很多研发管理将“管理”侧重“考核”，将一堆指标压下来。可是，“考核”是为了什么？究其根本，KPI是绩效考核的手段之一，是希望通过胡萝卜加大棒的方式促进员工产生更好的工作表现，是绩效管理的一个环节。整个绩效管理最根本的目的，还是如何让员工产生高绩效。
“KPI 只能让驴使劲走，而 OKR 用于保证驴头朝正确的方向。”在知识型工作中摈弃不够合理的KPI，应用促进理解、自发与协作的OKR，其实是在研发管理中回归本质，即从绩效考核转向绩效驱动。
Agile、DevOps及OKR的引入是管理方法的变革，再往深是企业文化的变革。这是一种全新文化的塑造：足够快与灵活而敏捷响应变化，足够开放鼓励自发与创意，足够包容持续改善迭代，使一个产品/服务驱动型的企业中，研发不再止于研发，产品的打造不仅仅是研发团队的工作，而是各个部门都应该并有了机制充分参与，研发团队也不再只是埋头苦干而是通过Task到个人级OKR、部门级OKR再到公司级OKR的由下向上联结，知道自己每一行代码的意义，在写每一行代码或研究一个功能时都会朝那个大方向看一看校准，这种基于团队协作的研发过程，产品对公司战略的契合与对外客户需求契合程度都更高，真正做到目标与结果导向，不再是研发团队不接地气的自嗨。
从管理体系到企业文化，前者有形后者无形，无招之处胜有招，看不到的力量总是更为强大。
当然，变革与文化的建立并非如此容易，需要很多适配的过程、体系、制度、方法等共同建立。比如建立职级、荣誉、360考核与项目奖惩关联的绩效管理体系，通过技术委员会、用户体验委员会、Polish Week等促进团队融合，其他还包括黑客马拉松、仪式感的打造、团建活动和分享培训等，以点成面，构成研发管理全景。
三、让落地比说更简单
说了这么多，OKR到底如何落地？可以把这部分理解为广告环节，或者接地气的实践帮助环节。
| OKR是什么？不是什么？
| OKR落地常见坑
以上是我们在国内接触200+企业OKR落地时常见的坑，包括把OKR当成目标分解工具或把每日工作事项填进去变成To Do List的，有和绩效挂钩让员工认为就是KPI的，有HR作为主导部门推行产生一系列问题的，还有上来就全员OKR效果不理想的等等。
| 从问题到解决方案
对于OKR和Agile落地，WMC团队在国内服务了180+企业，服务模式包括“咨询+SaaS”，通过咨询服务完成体系搭建，通过SaaS作为应用载体承接体系落地，使OKR/Agile在企业内部以正确方式导入并能切实运转。
广告不多打，感兴趣的朋友可以看图勾搭Worktile吉祥物“十亿”同学咨询详情。
本文为2019.05.10在“携程敏捷沙龙——OKR专场”分享内容的整理（需要完整课件的朋友可点击「我要完整版课件」）
特别感谢两位大神支持：
整体思路、内容与主要案例基于Worktile创始人/CEO—王涛2019.04.14在助通科技小二班CTO俱乐部《当研发遇上OKR》的分享。涛哥有10年互联网开发经验，曾连续3年荣获微软“MVP（最有价值专家）”称号，出版技术畅销书《你必须知道的.NET》，也是微软 TechEd 特约讲师，除了技术过硬，在Worktile近6年的成长过程中，做了非常多有意思的管理尝试，对于研发管理有非常深的洞见，感谢涛哥授权做他智慧的搬运工；
本人非研发背景，在Agile及DevOps与研发管理方面的内容，我司高级系统架构师——孙敬云孙大神给予了非常多的指导和帮助。孙大神曾任百度资深研发工程师及智课教育美小事业部技术总监，具有多年一线技术攻坚和敏捷开发的实战经验，在研发管理及绩效管理领域有丰富的经验。孙大神会在Worktile近期的研发管理系列活动中做很多分享，希望和孙大神交流学习的朋友欢迎关注《Worktile 2019敏捷大会》深圳站参加我们的线下活动。
