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

Posted 2022-08-04 johntsu

    前段时间看了本书叫《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真正给我们大家带来的好处。当然了，取得了这么好的成绩，庆功会是肯定不能没有的。所以，有条件又有时机的小伙伴们，强烈建议你们去尝试实施一下，真的很香。