记录OKR在小公司实施的一次经历

00 前言    

    前段时间看了本书叫《OKR工作法》,顺便了解了一下OKR的相关知识,感觉这个起源于英特尔公司的东西,正是为那种小而美的团队准备的好东东。如果你还不知道什么是OKR,那我给你个传送门,可以去那里扫扫盲。恰逢我当时所带领的技术团队是小团队,而公司的业务和技术都处在需要变革的前夕,这简直就是老天爷给予的实施OKR的良机啊。那么我是如何导入OKR,并且将OKR实施落地的呢?下面且听我慢慢分解。

 

01 黎明前的黑暗

    在开始给大家讲述我的OKR经历之前,先给大家交代一下背景情况。我当时所在的公司是一家做通讯产品业务的小公司,说白了就是帮移动、联通这些电信公司销售手机号卡,流量套餐以及做一些自己的新零售业务的渠道商。我当时空降过去的时候,这公司的日子过得可以说是相当难受,因为:

1. 公司的系统经常崩溃停机,严重影响业务

2. 公司的系统开一单要10分钟到半小时,而且开单成功率不到50%

3. 公司的系统存在一号多开,丢单等的问题

4. 最最让人不爽的是,公司的几个竞争对手,他们的系统开单成功率都在90%以上,开单还快。所以他们天天向公司老总秀肌肉。

    以上的这些情况,充分说明了,这是一个彻头彻尾的烂摊子。也正是因此,才让公司的这个业务平台到了不得不改变的地步。因为不改肯定会死,改可能还有活的机会。

    就是在这样非常糟糕的情况下,我接手了这个烂摊子。恰好这个项目面临变革,技术团队人又少,所以,这绝对是一个实践OKR的绝佳机会。

 

02 确定目标,备好粮草

    要实施OKR,首先第一步肯定是要确定O,也就是目标。公司虽然使用KPI的方式考核绩效,但是OKR不是绩效考核工具,所以跟公司的考核机制不冲突,可以做目标对齐。既然这样,那如果我是公司老板,我会怎么定目标呢?很简单,就四个字,开源节流。但是目前来看,节流不如开源(不是开源软件的那个开源哈)。既然竞争对手们开发的系统,开单成功率在90%以上,开单速度在1分钟以内,那我就把部门的季度O定为技术支撑业务能力高于竞争对手

    OK,我现在有O了,那下一步,肯定是key result,然后推导出key action。前面提到过,竞争对手的开单成功率是90%,开单速度在一分钟以内,好,那我的第一个KR就定为开单成功率95%以上,第二个KR就定为开单时间半分钟以内。此外,由于系统经常崩溃,所以我又加了一个KR,即线上故障2小时内修复。现在我的OKR模型是这样的:

  • O:技术支撑业务能力高于竞争对手
  • KR1:平均开单成功率95%以上
  • KR2:平均开单时间半分钟以内
  • KR3:线上故障平均2小时内修复

为了能达成这几个KR,我认为需要公司的一些支持。这些支持包括:

人员支持:现有的技术人员能力参差不齐,需要调整。但是,凡是涉及到人事的变动,就需要和相关的人提前沟通好,比如公司老板,行政HR等,因为有些技术人员有点沾亲带故的关系。

资金支持:既然要改变,肯定是要花钱的。系统都已经烂到家了,快活不下去了,还有啥理由不投钱?除非老板不想做这生意了。

然后我就开始了和老板的漫长的交涉沟通(其实也没多长,两三天吧),终于争取了下来。现在人和钱这两方面都有保障了,可以放心大胆地干了。

 

03 落地三部曲,想好了就干

    OKR实施的第一步,先解决人的问题。首先我让小伙伴们根据部门的OKR来制定自己的OKR,并一起开会评审,做出承诺。然后每周复盘,并对那些没有达标的小伙伴,逐一谈话,能干的愿意干的可以再给一次机会,不愿意干的就可以另谋出路了。对于愿意留下来继续干的小伙伴,我会在平时去验收他们的工作成果,例如review他们的代码,查看他们编写的文档等,不断提升他们的战斗力,并逐步建立起工程师文化,改变技术部以往死气沉沉的氛围。

    在解决了人的问题后,第二步就是解决工具的问题。以前小伙伴们使用的办公电脑,普遍配置一般,甚至偏低(赛扬处理器,内存4个G,甚至2个G),键盘鼠标全都是二手货,手感贼差。于是我向公司申请,将办公电脑的配置全部升级(i7处理器,8G内存,带固态硬盘),键盘鼠标全部换新的。这样一来,小伙伴们编程时的体验好了不止多少倍。除此以外,我还将技术部使用的宽带升级,并更换了带宽更大的路由器,提升设备之间的数据传输效率。另外,还有为搭建测试环境采购的服务器,平时沟通用的玻璃白板等等。有了这些家伙什,大家的工作效率就有了保障。

    最后的一步,就是解决系统的问题。公司使用的业务系统,是找外包团队花了两个星期的时间做出来的,是一个跑在tomcat容器中的web单点应用,外加一套不怎么好用的app。我通过一两天的观察发现,开单慢,是因为数据库设计不合理,也没有做数据库优化导致的(mysql中查询100万条数据有多慢,相信经历过的人都懂)。开单成功率低,是因为前端app未做参数校验,后端应用也没有过滤无效数据,程序出错导致开单失败。至于系统经常崩溃,是因为内存溢出导致tomcat容器停止运行。好吧,这都是很低级的问题。既然系统要重构,那就索性把这个巨石架构的应用换成微服务架构。正好当时流行springcloud框架,于是我决定将系统中的业务模块都做成独立的微服务。同时,让做app开发的小伙伴们重新开发app。在重构系统的过程中,顺带解决以前系统中的一号多开,丢单等影响业务的问题。

    小伙伴们听说要使用很潮的技术开发微服务,兴趣都非常的高。做app开发的小伙伴一听说让他们从头开发app,也都非常高兴(因为不用再给外包的app擦屁股了)。大家在热火朝天的干劲中奋斗了两个多月。最终我们重构的新系统上线了,并且上线一周后,数据显示平均开单成功率在93%,平均开单时间在半分钟以内。而后我们针对开单失败的情况又制定了一套补偿机制,最终将平均开单成功率稳定在了98%。嗯,真香……

 

04 复盘总结,展望未来

    总体来说,这一次实施OKR的经历,收获真的是非常的多,而且充分验证了OKR真的很适合在小团队或者创业团队中去实施。通过两个多月的OKR经历,大家都有了不同程度的成长和提高。而这,才是OKR真正给我们大家带来的好处。当然了,取得了这么好的成绩,庆功会是肯定不能没有的。所以,有条件又有时机的小伙伴们,强烈建议你们去尝试实施一下,真的很香。

posted @ 2019-08-19 18:16  湖畔清茶杨柳飘  阅读(796)  评论(0编辑  收藏  举报