如何用OKR做团队规划
2021-03-30 11:58:51 4 举报AI智能生成
登录查看完整内容
全面从实战角度介绍如果基于OKR做团队规划
作者其他创作
大纲/内容
如何用OKR做团队规划
团队规划方法
团队规划是TL工作中最头疼的事情之一
这件事情很难有确定的标准，感觉怎么做都有一定的道理，但又不太确定什么样的规划才能拿到好结果
团队成员也需要掌握团队规划方法
作为团队成员，你需要理解 TL 的规划，并且根据他的规划分解出自己的规划
当你自己学会了团队规划，就更容易发现潜在的机会，然后跟 TL 争取这些机会
KPI规划法
OKR规划法
KPI
关键绩效指标
Key Performance Indicator
把公司的目标自上而下地分解，并且通过相关的关键绩效指标来衡量实际的执行效果
KPI的问题
KPI 规划法曾经的确是比较先进的管理方法，但是到了今天，它的缺点也暴露得很明显
实际问题
1、只适合标准化的、目标稳定的工作
eg
在一家生产洗衣液的工厂，生产线是标准化的流水线，KPI 可以设定为产量、停机时间和良品率等，产品销售是目标稳定的活动，KPI 可以设定为销售量和市场占有率等
但是，工厂的技术创新就不适合用 KPI 来衡量了，因为创新有很大的不确定性，既不可能标准化，也不可能稳定产出
2、给团队带来不好的风气
案例
索尼公司前常务董事
《绩效主义毁了索尼》
超链接
痛批 KPI 规划法带来的问题
如果我们先抛开文章结论对不对、观点是不是太偏激、索尼对 KPI 的理解是不是准确这些争议不谈，只看其中描述的现象，就会发现很多公司都存在同样的问题
共性问题
故意定低指标
几乎所有人都把指标定得比较低，因为这样容易实现
只顾短期效益
简单的活，简单的方法，简单的思维
追求眼前利益的风气蔓延，短期内难见效益的工作都受到轻视，比如
产品质量
性能优化
闭环故障
基础平台
创新思维
提效变革
一切只看指标
上司不把部下当有感情的人来对待，一切都用指标来衡量
工作和考核本末倒置
绩效考核需要把各种工作量化，但是很多工作无法简单地量化，所以公司在绩效考核上花费了大量的精力和时间，而在真正的工作上却敷衍了事，本末倒置
技术团队如何使用KPI
KPI的困惑
KPI 规划法的这些缺点，在互联网公司的技术团队往往会进一步放大，很多 TL 在使用这种方法的时候都遇到过问题
这些指标都不可行
某公司
考核程序员的关键指标
bug的数量
bug的等级
考核测员试的关键指标
发现的bug数量
bug等级
结果
程序员和测试员为了一个问题是 bug 还是需求遗漏、bug 的等级是严重还是一般，能够吵上 2 个小时
2 个小时吵不出结果，就拉上双方主管再吵 2 小时
还吵不出结果，就拉上经理继续吵 2 个小时
于是最后就看谁会吵，谁官大，搞得程序员和测试员身心俱疲，关系很紧张
程序员的工作要怎么量化？
代码行数？
需求数？
bug数？
版本数？
技术团队怎么体现工作贡献？
既然以上指标不可行，那么如何体现技术团队对业务的贡献呢？
比如用“技术团队背 30% 的业务指标”这样的方式来定技术团队的 KPI
比如公司业务的整体目标是“新增用户 100 万”，技术团队直接按照 30% 的比例定自己的 KPI 为“新增用户 30 万”
这种KPI没有意义
因为技术团队的工作并不能直观的转换为业务数据
最后只能是看运气，业务目标达到了技术团队就跟着吃肉，业务目标没达到技术团队就跟着挨罚
有风险的工作谁愿意做？
很多前瞻性和拓展性的工作也伴随着风险
比如闭环转MySQL上云
比如引入 ElasticSearch
理论上是可以提升搜索性能的，但在引入的这一年可能会带来很多问题，之后能带来多少收益还不确定
总结
在 KPI 的机制下，这种有风险的工作很可能没有人愿意去做，因为大家都不想犯错
技术团队规划的常见角度
考虑到KPI带来的问题，在使用KPI规划法的时候，技术团队的TL一般会从以下三个角度来做团队规划
解决问题
比如解决版本延迟、线上 Bug 和团队成员士气不高等问题
这是最容易找的角度，因为没有完美的团队，只要去找，一定能找到问题
而且这个角度看上去就很有价值，因为出问题肯定是不好的，解决掉总归是有好处的
优化性能
团队优化
比如提升开发效率和质量，提升团队成员战斗力
技术优化
比如将 App 的崩溃率从 0.5% 优化到 0.3%，将后台接口响应时间从 50ms 优化到 30ms
引入新技术
比如引入 Flutter 来实现双端统一开发，引入机器学习来实现系统的某个功能
业界各种新技术不断涌现，新技术有可能让生产效率或者生产质量大幅提升，所以引入新技术看起来既可以提升团队技术水平，又可以提升产品竞争力
看起来是一个完美的KPI
因为它也非常简单明确，不需要太多的思考
毕竟没有哪个产品和系统是完美的，每年都可以找到各种优化点
并且这些优化点还可以用指标衡量出来
缺点
从这些角度来做 KPI 规划，往往拿不到很好的绩效结果
主要原因为
这些都是团队和技术的角度，没有结合业务目标，所以就算你做得很好，价值也不一定能体现出来
某个技术团队的 TL 兴致高昂地介绍了自己的团队规划
技术领导问了一句：“为什么要现在做这个事情，这个事情给业务带来什么价值？”
结果这位 TL 就答不上来了，因为在整个规划的过程中，他都没有这样思考过。最后，他的规划汇报没通过，被领导要求重新规划
你可能会认为：
这些事情本身都是有价值的呀，为什么不可以作为规划内容呢？
比如 App 崩溃率从 0.5% 优化到 0.3%，用户体验肯定是提升了的呀！
不可否认这个事情本身的价值
但是团队规划需要考虑的是如何做才能创造最大的价值
因为团队的资源和时间是有限的，需要让投入产出比最大化
假如以App 崩溃率为例
如果你的 App 是在东南亚市场推出，受当地市场的手机档次比较低端的限制，崩溃率 0.5% 跟国内市场比感觉很高了，但其实在当地已经算很好的了
你花了很大力气，将崩溃率从 0.5% 提升到 0.3%，确实有利于用户体验，但是这部分提升带来的价值对用户来说感知不明显
相比之下，如果你花同样的资源按照当地用户的操作习惯将 UI 改版，可能效果会非常明显
没有结合业务目标，体现不出价值
OKR
目标与关键成果
都在使用OKR 规划法
Objectives and Key Results
历史背景
为了解决 KPI 规划法的问题，英特尔公司创始人安迪·格鲁夫（Andy Grove）提出了另一种团队规划法，后来由约翰·杜尔（John Doerr）引入谷歌发扬光大
知名公司
比如微软（Microsoft）
领英（LinkedIn）
推特（Twitter）
亚马逊（Amazon）
脸书（Facebook）
雅虎（Yahoo）
实施步骤
首先，设定业务目标（Objectives）
比如提升市场占有率
然后，为每个目标设定关键结果（Key Results）
也就是为了实现目标具体要做的事情，以及具体的标准
比如为了实现“提升市场占有率”这个目标，准备“请 XX 明星做代言人”“投入 100 亿做用户补贴”等
OKR和KPI的区别
KPI关注数据指标，OKR关注业务目标
KPI 的关键词是 Indicators，而 OKR 的关键词是 Objectives
1、假如你是程序员
如果关注指标，你想到的是代码行数、bug 数和单元测试覆盖率
而如果关注目标，你想到的是解决产品的卡顿问题和实现精准推荐
2、假如你是足球运动员
如果关注指标，你想到的是进球数、助攻数、跑动距离和比赛场次
而如果关注目标，你想到的是夺冠、四强和保级
3、假如你是曹操专车的业务负责人
如果关注指标，你想到的是司机数量、订单数和乘客数
而如果关注目标，你想到的可能是让曹操专车成为网约车行业第二
“具有讽刺意味的是，因单枪三束彩色显像管电视机获得成功而沾沾自喜的索尼，却在液晶和等离子薄型电视机的开发方面落后了。”
按照 KPI 的思维
彩色显像管电视机是已经在做的产品，自然要把销量数据做得越高越好
按照 OKR 的思维
整个行业都在转向液晶和等离子电视，必须尽快切换产品方向
《管理的实践》
“并不是有了工作才有目标，而是相反，有了目标才能确定每个人的工作。所以企业的使命和任务，必须转化为目标。”
这句话非常好地诠释了 KPI 和 OKR 的区别
KPI 让我们正确地做事，OKR 让我们做正确的事
不要小看指标和目标这两个词的力量，它们代表的是两种思维方式
当你使用 KPI 规划法
更关注数据指标的时候
第一反应是“我要履行什么职责”
思维就会受到限制
只会关注当前已有的工作，不太可能去思考接下来应该做的事情是什么
当你使用 OKR 规划法
更关注业务目标的时候
第一反应是“我要做成什么事情”
思维就会更加开阔
而不会局限于当前正在做的事情，可以根据实际情况判断和选择接下来应该要做的事情
方向对了，就不怕路途遥远；方向不对，数据再漂亮也没有意义
在快速发展的行业
比如互联网行业，我们需要拥抱变化、不断调整，显然 OKR 规划法更加适用
KPI要求结果可以量化，OKR要求结果可以衡量
KPI让我们正确的做事，OKR让我们做正确的事
分支主题
OKR是一种牛逼的KPI制定方法，KPI是OKR中KR的两种表现形式之一
大部分的人的 KPI 是怎么制定的
一般先看有哪几个指标，然后每个指标做一些提升，就当成 KPI 提交
某手游交易网站的产品经理列出了 5 个指标
用户量
成交额
用户安全
发货速度
收入
团队内部讨论的时候，我提了一个问题：“为什么要制定这些 KPI？”
产品经理的回答是：“这些指标每个都很重要啊，你说哪个不重要呢？”
事实上，这些指标在不同的时期重要程度是不一样的，有的指标甚至是互相冲突的
如果业务目标是做到市场份额行业第一
那么用户量作为核心指标必须增长，你需要到百度买流量、补贴新用户和免交易手续费等，但这样做肯定会增加支出、减少收入
如果集团要求创新业务必须实现盈亏平衡
那么收入作为核心目标必须增长，你就不能免除交易手续费，而是要实现交易阶梯收费，但这样又会影响用户量和成交额，因为会有一部分用户会因为手续费的原因而转移到其他交易平台
给每个指标设定一个增长量
当你用 OKR 规划法的话
需要先根据环境变化和业务发展进行判断和取舍，明确业务目标，然后才能基于目标分解出合理的 KPI
OKR 其实就是一种牛逼的 KPI 制定方法
两种不同的思维方式
OKR和KPI的联系
虽然 OKR 和 KPI 有着本质区别，但这并不意味着它们截然相反、水火不容
OKR 的 KR 和 KPI 的表现形式基本一致
某 App 业务负责人的 OKR
这里的KR，也可以叫KPI
O：App 注册用户数达到 5000 万
KR1：2021 全年新增用户 1500 万
KR2：月活用户达到 2500 万
KR3：新用户月留存率达到 40%
OKR 和 KPI 其实有着内在的联系
OKR 的 KR 有两种表现形式，一种是 KPI，一种是里程碑
KPI 的要求是
可以量化
OKR 的要求是
可以衡量
你可以用量化的数据来衡量，也可以用里程碑式的关键节点来衡量
量化的KR
比如前面提到的“2021 全年新增用户 1500 万”
里程碑式的 KR
指的是关键事项的落地
难以量化但可以衡量
以索尼公司为例
彩色显像管电视的开发项目立项时的 KR 应该是“19XX 年开发出彩色显像管电视”
这就是一个无法量化但可以衡量的结果
“某某业务上线”
“完成推荐系统从 0 到 1 开发”
“落地敏捷开发流程”
OKR规划法应用实践
核心理念
聚焦
在众多可以选择的方向中，挑出最重要的
对齐
对照上一级的OKR，看看自己的团队能贡献什么价值
业务规划
聚焦业务目标
业务负责人确定最重要的目标，不超过3个
分解关键结果
业务负责人分解出关于目标的关键结果，3～5个
团队规划
对齐业务OKR
TL对照业务规划的OKR，提出业务上的OKR
补充专业OKR
TL结合业务目标和团队情况，提出专业上的OKR
注意事项
1、对于研发团队
一线工程师的OKR目标设定
不建议用OKR来制定个人规划
除非工程师能够独立负责一个领域或者方向
如果团队成员没有在制定OKR的时候就明确负责某个KR，那么考核只能是事后评价
如常规任务
没有在OKR中体现
如果团队OKR的KR一开始就能够分配给某个或者某几个成员，是可以按照KR来考核的
考核方式
事后总结评价
做了什么事
贡献如何
质量和效率如何
是否有犯错
360度评价
2、OKR不适合1个月这种短周期，OKR至少是一个季度的
3、选择远远大于努力
选择错了当然没法取得成果
但方向选择对了，后面的落地执行同样重要
4、关于程序员的工作量如何量化？
无法量化，一线的程序员不推荐用OKR来规划和考核，更不用说KPI了，更不合适
一线程序员的考核基本就是事后总结
单纯某一点做好不等同于就能够拿到最后的结果
KPI 的缺点有两方面
一是只适合标准化的、目标稳定的工作
二是会给团队带来不好的风气
技术团队的 TL 做团队规划有 3 个常见做法
OKR 规划法关注业务目标
可以根据实际情况及时调整，更适合快速发展的行业
OKR 是一种牛逼的 KPI 制定方法，KPI 是 KR 的一种形式
当你先明确业务目标，再根据环境变化和业务发展进行取舍，才能制定出合理的 KPI
但是因为没有结合业务目标，价值很难体现
0 条评论
回复 删除
下一页
