写在前面
为什么管理很难做到让所有人都满意?因为管理的方法论一直在不断地变化,你去书店看看,最多的那一类书一定是管理类的,这是因为企业的外部环境一直在变化,90 年代流行学日本,2010 年后改成学华为,永远都没有谁对谁错,而在于时代需要怎么样的管理方式。
KK 在《失控》这本书中向我们描述了这样一个实验:一群从未驾驶过飞机的人第一次驾驶飞机(用虚拟驾驶仪器),没有人教他们如何驾驶,实验的内容是直接让他们以团队形式做一次飞行实验。实验需要他们驾驶飞机穿越海洋,穿越过程中会遇到(虚拟仿真)夏季风暴。在实验过程中,团队成员都被冻得瑟瑟发抖,不知道应该怎么做,没有人给他们指示,而又因为是在茫茫大海上航行,对大家来说有太多选择了,以至于无从选择。正在大家迷茫时,有人在房间后面轻声说了一句"你们为什么不向右转向"?发出提示的人并不是团队负责人,也只是提了一个极小的建议,但是它向人群提出了方向和建议。如果我们在这个实验里要求大家制定 KPI,由于没有人拥有足够的技能,也没有类似的经验,也就没有办法制定出详细和准确的 KPI 指标,如果换位到企业,尤其是创业公司,你的员工和公司方向一样会存在这样的问题,如果你让他们指定 KPI,他们只有通过指定较低的 KPI 指标,才能做到自保。因此,只有通过在工作过程中指定目标,然后针对目标进行不断地方法调整,你才能够确保公司向着正确的方向发展,因为只有这样你才能够防止自下而上的"失控"。今天我们需要讨论的是正是针对初创公司如何用好 OKR。
什么是 OKR?
OKR 的全称是 Objectives and Key Results,中文可以直译为"目标和主要成果",这套系统最初由英特尔公司制定,但是付诸实践的最大公司并不是英特尔自己,而是谷歌。大家还记得谷歌的成立时间吗?1998 年 9 月 4 日。英特尔在 1999 年(成立一年后)就全面引入了 OKR 管理方式,同时也是目前为止该方法论的最强力支持方。我认为,也正是用好了 OKR 管理方式,谷歌才能成长为现在为大家所知的谷歌。
正如李运华先生在《技术漫谈:为何KPI 毁了索尼,而OKR 却成就了谷歌?》一文中所描述的OKR 和 KPI 的关系,如下图所示:
在他的文章中,他提出OKR 首先需要确定O,然后从O 分解出KR,然后用KPI 或者 Milestone 的形式来表示KR。他指出了一个细节,OKR 的KR 可以是 KPI,也可以是Milestone,这是为什么呢?关键在于OKR 要求KR 是 measurable,中文译为"可衡量的",而 KPI 的指标要求是"可量化的",也就是说衡量的方法更加广泛一些,可以是"量化"衡量,也可以是"里程碑"式的衡量。
OKR 与 KPI 的区别
以程序员为例,如果我们关注目标,我们会思考接下来我应该做什么事情,是要解决产品的性能问题,还是可以引入数据挖掘技术来做精准推荐。如果关注性能指标,由于我们的工作内容是针对产品进行编程,那么我们就会琢磨哪些指标可以被用来衡量编程工作,自然而然我们想到的是代码行数、bug 数、单元测试覆盖率等等。
程序员的 Bug 数量怎么量化?这个命题其实是一个伪命题,因为是否是 Bug、Bug 等级的明确,这些很多时候成为了程序员和测试人员之间的冲突点,最后一定是互相进行妥协,或者出现双方水火不容的情况。
OKR 相对于 KPI 而言,不是一个考核工具,而是一个更具有指导性的工具,说白了,是一个计划 - 执行 - 检查的循环。OKR 存在的主要目标不是考核某个团队或者员工的工作量,而是时刻提醒每一个人当前的任务是什么。在谷歌公司,每个人都有自己的 OKR,每个团队有团队的 OKR,无论级别高低、团队大小,所有人都需要制订并且服从 OKR。这个 OKR 在每个季度结束之后要做一个评分,评分高低并不直接决定一个员工的晋升和待遇,而更多的是提醒员工,这个季度工作完成的怎么样,未完成的工作为什么没有完成,下一阶段的工作重心是什么。
OKR 的关键词是 Objectives,KPI 的关键词是 Indicators,正是由于程序员的很多工作无法量化,比如你对一个程序员说,你编写的代码不能出现缺陷,这本身是一个伪命题,因为软件本身是模拟人行为的映射产物,人是会犯错误的,所以软件一定也会存在缺陷。所以只能通过设定目标方式驱动程序员前进,否则,他们中灵活的人会为了完成指标而作弊,而老实的人则会陷入苦恼、迷茫。
OKR 的好处
OKR 的最大好处是促使人积极地离开安逸区,无论是主动,还是被动。
对于硅谷的大多数初创科技公司来说,员工个个充满激情和野心,否则他们干嘛来初创公司,去大公司会更加安逸,而这一点在 OKR 的考核系统中可以实现。OKR 要求雇员在与组织目标保持一定的前提下,需要站得更高、看得更远。与 KPI 不同的是,OKR 要求员工走出"舒适区",最好超出自身的能力范围。一个 100% 被完成的 KPI 可能对于公司或者产品的发展没有任何推动作用,而一个 70% 完成度的 OKR 却近乎完美,你只有知道极限在哪里,你才会有更大的上升空间。OKR 相信并且依靠员工的自主性和创造性去完成任务,目标是实现自由和方向的平衡。
OKR 最大的好处就是它极度简单,从分类开始就足够简单,就三个单词: “Objective"和"Key Results”。一些管理绩效和战略执行的方法术语连篇,员工一头雾水,被诸如使命、愿景、核心价值观和 KPI 这类术语弄得晕头转向,不知所措!这些都是初创公司需要避免的,你每时每刻都在担心失败,繁琐意味着人力成本的消耗。
对一个公司而言,员工注意力是非常稀缺的一种资源。在这 7×24 小时不间断的世界里,有很多事情都在抢占这一资源,比如公司目标、业务单元目标、个人目标、各种会议、行业趋势、职业生涯考虑、家庭琐事、社交媒体,等等。上周我去了趟新加坡,见了前同事,我把每一次见面都当做最后一次,因为大家的时间都是碎片化的,也许此生都没时间再聚。
使用 OKR 的本质是希望能够让员工明确自己的目标,不要为了满足指标而去动歪脑筋,也不要因为满足指标了而进入了舒适区,OKR 就是要把人拉出舒适区。中小型或者初创公司如果不能做到尽可能地发挥员工的主观能动性,你就很难和大公司竞争,如果不能最大地发挥所有人的优势,将大家捏在一起,最后结果就是老板累死、公司解散。
初创公司的烦恼
初创公司,相较于大型企业来说有很大的不同,我总结了以下几点:
1. 如果你在创业公司工作,那么你在工作上会有较大的自主权,同时也可以做一些自己认为会成功的事情,但这也意味着只要公司需要,你就什么都得做。
首先我们需要意识到在创业公司工作也可能会涉及到很多无聊乏味的苦差事,做这些事的技术含量和成就感可能要远低于你在一家大公司做的事情。比如为产品做无休止的缺陷修复和改进、接听和拨打各种电话、收发快递以及其他一些或许你会觉得无法全部体现自身价值的工作。针对这一类型工作,我们需要明确它所产生的效果,修复缺陷、改进系统、拨打客户电话、收发快递,这些工作很有可能都能实现"改进产品,提升客户满意度"这样的 OKR 目标,既然是有利的,我们就需要去明确目标,然后思考如何实现目标,并有针对性地分配任务,创业公司如果能够做到目标实现方式明确及步骤细分,那么一定能够最大化地使用所有人,所以 OKR 对于创业公司非常重要。
我对于 OKR 的设定有自己的一套检查机制,每周我会安排半天时间,让所有人逐一说说上一周完成的工作,越详细越好,因为只有详细,你才有机会提出具体问题。我们真正需要去关注的是事情的结果以及所影响的范围,而不是仅仅完成了这一项任务。
2. 谁都希望自己的公司最后会成为下一个 Google、腾讯。但你要明白这其中的风险很大,以及最终成功的创业公司其实数量很少。
最近哈佛大学的研究发现美国大约 75% 的创业公司最终都失败了。你觉得你们公司将会属于剩下的 25% 呢,还是这 75% 呢?就算一家创业公司里的每个员工都竭尽所能的工作,就算这家公司所打造的产品真的能改变世界上每一个人的生活,但事实是有时候这些东西与成功没多大的关系,很多创业公司都坚持不到一年。既然我们不知道未来,我们就应该采取更为积极有效的管理方式,采用 OKR,而不是 KPI,让大家努力拼一把,而不是为了满足 KPI 指标想尽办法。
3. 虽然许多创业公司会公平对待每一个员工,但对薪水和福利别期望太高。
创业公司往往存在着资金紧张的问题。这意味着许多创业公司提供的薪资与福利和那些已经比较成熟的公司是不能比的。举个例子,在美国一个市场高管求职时的待遇要求一般是 15000 美元左右每月,对于大公司来说这完全是一个合理的要求,但如果是在创业公司,每月能拿到 11000 美元就已经非常不错了。既然工资上没有太大的吸引力,那么我们可以通过创造更宽松的考核方式,更加广阔的发展空间,来吸引员工。通过 OKR,让每位员工可以看到其他人的目标和完成情况,包括 CEO 的,这会让他很有参与感,而不是像在大公司,每天做的事情他可能都没有意识到究竟是为了什么,究竟自己的贡献有多大。
4. 来自主管的指导。
创业公司的工作氛围可能会让一些人难以忍受,在一个小团队里工作,要求你必须主动性十足,感觉仿佛回到了大学时代。如果你的主管很忙,那么很有可能他就不会给你太多指导,特别是那种你在别的地方会得到的正式指导。而且别忘了在某些特定的领域,你主管的经验可能还不如你丰富。举个例子来说,如果你是你们团队中唯一一个被聘来负责市场的人,相比于在那些有着多年市场经验及众多市场人才的公司,比如宝洁,你获得的指导会少很多很多,你只能自己领悟闯荡市场的技巧。这种问题的存在,可以通过为主管设定特定的 OKR 来实现,比如"加强员工的技术归属感",这一条目标的实现就需要主管加强与员工就业务和技术上的交流,帮助员工制定成长计划、审核计划的实现成绩,一定要做好这一条,初创公司。
5. 最后一条或许是最重要的一条。虽然创业公司有很多的乐趣,但压力可能也会比其他公司大很多。
达成结果、完成指标、保持进步、提高知名度。。。在创业公司工作类似于这样的压力将会纷至沓来。我们已经看到了很多人退出了创业公司因为他们发现无法承受这些精神上的压力。你的工作能够决定这家公司的命运,这种感觉确实不错,但套用《蜘蛛侠》里的经典台词:“能力越大,责任越大。”
OKR 并非一个自上而下的运动,不是要一成不变地把目标向下分发给低层级业务单元和部门,让他们毫无保留地去执行。正好相反,OKR 更加包容,个体在 OKR 的选择上更具话语权,目标设定是自下而上和自上而下的融合。要通过使用 OKR 让员工增强归属感,他的每一次付出,都在帮助公司成长,他们对于公司很重要,这样才能不断激励他们。
OKR 的落地
OKR 如果想要真正落地,最关键的是 peer review,其实这是对于管理理念的巨大挑战,因为这种做法意味着集合了扁平化管理和去中心化管理理念。扁平化并没有去掉员工的层级管理理念,只是简化了层级,不会出现美国某大公司的 9 层管理层级,每一层只管理 1 位员工的情况,但是还是有管理层存在的,员工之间互相不存在交互(典型的 Master-Slave 分布式架构)。而去中心化,则意味着各个员工之间可以互相查看对方的目标,也就是分布式系统设计时各个节点需要通信,虽然依然存在弱中心化的设计,但是总体来说没有了 Master 概念。
即便是在采用 OKR 方式的众多公司内部,对于 OKR 的具体方案还是存在一些差异的,大体上可以分为较为宽松的和较为严谨的两大类。无论哪种方式,我觉得如果初创公司想要做到 OKR 的平稳落地,我认为需要满足以下几点:
- 首先指定较为模糊的目标,统一大家努力的方向,而不是完全计划好,再周全的计划也总是赶不上变化。所以 OKR 不是计划,只是一个模糊的目标,具体如何实现还需要探索。但有了目标至少有了努力的方向。这样个人的目标、团队的目标和公司的目标才有可能达成一致,从而为产生更大的影响提供可能。看看谷歌的 OKR 目标:“增强 Blogger 的威望”,而不仅仅是每天发一篇博客的 KPI 指标;
- 量化 OKR 必须是一个可度量的目标;
- 目标可以由员工或者技术经理提出,而不是总监。OKR 需要统一的是个人的目标和团队的目标。技术经理负责的是团队的目标,而员工在意的是个人的职业生涯和个人为公司做出的影响,两个目标通过共同制定 OKR 来统一;
- (基本) 不作为考核标准。既然 OKR 是用来统一目标而非衡量成果的,一般不作为考核标准,虽然考核的过程中也会参考,但建议不要太在意分数之间的差距;
- 个人的 OKR 是对公司内其他员工开放的,包括 CEO。
我的应用
对于 OKR 的使用,我认为应该坚持以下几点,这些也是我在团队管理时使用的方式:
- 采用"长期规划制定,短期定时验收"的策略,即我们需要坚持使用 OKR 管理方式,这是长期政策,可以通过季度或者月度计划进行约束。 基本格式可以如下所示: 目标:这里必须提出明确的目标,例如完成一个 c/s 程序设计,实现客户端和服务端的通信。如果你发现不能明确提出目标,那么一定是你还没有想清楚自己接下来 1 个计划周期内需要完成什么,或者不是那么得明确,只是知道一个大概目标,这都是不合适的,每一个员工都必须明确目标。
执行过程:需要能够尽可能地细化我们的执行方式,尽自己所能实现目标切分和执行步骤切分,这种方式可以避免出现指定的目标空洞或者错误的情况发生,我们要做的是避免失控。 - 坚持采用每周一次或几次的目标执行情况检查工作。对于技术团队管理者来说,一切不可把控基本都是因为自己没有做好检查工作,我们管理一个团队,不仅仅是布置工作,而是要对工作过程中的每一个细节了解清楚,对于每一个难题给出自己的解决方案或者建议,引导团队前进。我比较推荐的检查方式如下所示: 上周工作回顾:这里需要逐一列出自己上周的目标及完成这些目标所做的具体工作。
本周计划工作:这里需要逐一列出自己本周的目标以及完成这些目标所需要做的具体工作。
我们对于技术团队的管理,不仅仅是带来 OKR 方式,而是带给他们如何最好地通过执行这些管理方式为团队研发成绩做出贡献,所以需要我们完整地掌握知识方法论,并主动不断纠正自己的使用方式。
总结
我个人认为,再好的制度,没有详细的实施方案、严谨的监督方案,也是不会取得成功的。初创公司有它自己的特性,它不像大公司那样船大人多,它相对来说比较轻巧,可以针对实际情况进行适度的快速调整。
在中小型公司,特别是初创公司,最好的方式是每周至少开一次晨会,晨会中 Review 大家的目标完成情况、讨论遇到的问题、并给出解决方案、指定下一次晨会之前的目标。所有人的目标,都应该能够被其他人看到,这样才不会出现务虚的人,对于初创公司来说,务虚、待在安逸区,两者都是对公司而言非常不利的,必须遏制。
作者介绍
周明耀,2004 年毕业于浙江大学,工学硕士。13 年软件研发经验,近 10 年技术团队管理经验,4 年分布式计算、大数据技术经验。著有《大话 Java 性能优化》、《深入理解 JVM&G1 GC》、《技术领导力 - 码农如何才能带团队》。个人微信号 michael_tec,个人公众号"麦克叔叔每晚 10 点说"。
感谢郭蕾对本文的审校。
评论