第23讲 | 产品技术团队OKR使用法则
明道创始人&CEO 任向晖
该思维导图由 AI 生成,仅供参考
经常有团队问我,团队或者部门是否可以应用 OKR 工作法。我的回答一般是否定的。像销售、市场、人事、行政这样的职能部门,如果彼此独立设定 OKR,几乎必然是无法和公司的聚焦目标对齐的。而且这些孤立的部门无法形成完整的业务链条,如果不能从公司或者事业单元的角度出发,就无法识别出影响成长的瓶颈问题和可能存在的增长动因,也就无法做有意义的聚焦。
但是,这个问题在产品技术部门可能是个例外。尤其是产品型公司的产品技术团队。一方面是因为产品型公司的聚焦重点经常会放在产品本身;另一方面是因为很多互联网公司在产品技术方面遇到的问题和机会都非常接近,以至于我看到不少科技公司在企业层面的 OKR 设定都非常近似。
先决条件
即便如此,也并非所有的产品技术团队都适合独立引入 OKR 方法。如果要让这个方法在企业中发挥出成效,不产生部门本位主义,那么这个团队要符合以下这些特征:
1)产品技术团队能够对产品的设计、开发和交付整体负责;团队具备主控性,而不是受制于多个部门的配合;
2)非项目服务业务模式,产品技术团队服务的是本企业的产品,而不是客户的产品,否则这个团队的核心管理体制很难超越项目管理本身。而且外包项目的生命周期也不足以来激励 OKR 的实施。
3)公司的业务成效很大程度上取决于产品本身的定位、特性与市场需求的适配度和产品质量;销售和营销职能起的是放大器作用。消费者应用领域的公司大多符合这个条件。如果是 2B 的产品则要视情形来看。
如果以上先决条件不存在,那么这样的团队独立实施 OKR 的成效是不乐观的。实际上,缺乏自治度和管理关注度的产品技术团队,本身也很难有动力来自行发起目标管理。即使做,一般也只是为了响应公司从上至下的管理要求而已。
常见的产品技术部门 OKR 类型
当我辅导了十家科技企业的 OKR 制定沟通会议以后,我发现这类企业的 OKR 选择有非常明显的规律。团队相对容易达成一致的目标意图(Objective)大体会分成这么几类:
1、产品特性交付里程碑
这可能是最常见的目标之一。产品技术团队因为担负交付产品和特性的责任,所以容易有这样习惯性的思维——本季度发布 xxx 特性,交付 2.0 版本产品等。
在这个动因下,产品技术部门设定目标要有更清醒的头脑和更整体的认知。为什么要交付 2.0 版本?2.0 版本主要解决的问题是什么?除了形式上的交付,用什么 KR 能够更好地定义交付成功?一个好的产品交付目标应该揭示背后的商业意图。比如:“通过 2.0 解决客户自助部署问题”就是更加完整的目标描述。
正是因为如此,这类目标所配套的关键结果(Key Results)也要能够反映出意图达成的 KPI(请中性理解这里的 KPI 含义)。发布时间本身不应该成为 KR,发布后能够形成的一个关键数据指标才是。比如上面“通过 2.0 解决客户自助部署问题”的 Objective 可能需要配套一个 KR:自助部署页面的 UV 数量,它反映了这个特性交付带来的客户价值,每有 1000 个 UV,说明可能有 1000 个用户得到了自助部署系统的帮助。
在产品特性交付目标方面,我还经常发现一个常见困难,就是每个季度的 OKR 周期很难保证一个大宗的产品特性交付彻底完成,更加不要说获得使用相关的数据。这时候,我们就需要定义更加细分的里程碑,而不是一个版本的交付,比如“完成单元测试”、“完成数据架构设计”等。
2、提升开发和运维质量
在产品型公司的早期,因为经验和能力的原因,在产品开发和运维过程(devops)中存在大量缺陷。有一些质量问题也可能是因为“MVP”理念导致的。这些可能都是创业公司不可避免的阶段。
但当公司开启了商业化进程,建立了专门的销售团队,低质量的产品会消耗巨大的营销投入,不仅无法转化满意的客户,而且会让整个团队士气低落。
但站在公司的角度看,刚刚建立了销售团队,管理层的注意力通常被牵制在销售团队的形成和管理上,有时候是无暇顾及,有时候是没有意识到产品质量对于提高销售效率的重要性。与其等到部门之间相互指责和推诿,有全局观的 CTO 应该尽快聚焦在提升质量的目标上。在达成这类目标时,产品技术团队的自治能力至关重要。
技术产品的质量提升目标不难设定用于衡量的关键结果(KR),但指标选择的过程最好依然是从下至上的,因为非专业人员很难有相关的知识背景。如果是和软件缺陷有关的质量改进,这个关键结果最好能够落在测试流程内部(用例的数量和覆盖度,测试的自动化程度等),而不是去衡量客户投诉率这样的滞后性 KR;如果是和运维质量相关的目标,KR 则更容易选择一些,因为有足够多的监控工具来直接提供有意义的指标。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
产品技术团队OKR使用法则的见解 明道CEO任向晖分享了产品技术团队OKR使用法则的见解。他指出,产品技术团队在应用OKR工作法时需要符合一定的先决条件。首先,产品技术团队需要能够对产品的设计、开发和交付整体负责,具备主控性而不是受制于多个部门的配合。其次,产品技术团队服务的是本企业的产品,而不是客户的产品,且公司的业务成效很大程度上取决于产品本身的定位、特性与市场需求的适配度和产品质量。最后,任向晖提到了缺乏自治度和管理关注度的产品技术团队很难有动力来自行发起目标管理。他强调了这些先决条件的重要性,并指出如果这些条件不存在,那么这样的团队独立实施OKR的成效是不乐观的。 文章还探讨了常见的产品技术部门OKR类型,包括产品特性交付里程碑、提升开发和运维质量、运营改善相关、提升产品市场适配度以及技术选型变更和偿还技术债。针对每种类型,文章提供了详细的目标设定和关键结果制定的指导,强调了在OKR执行过程中的任务设计和复盘时的重要性。此外,文章还强调了产品技术团队的自治能力对于达成目标的重要性,以及与管理层达成共识的必要性。 总的来说,本文突出了产品技术团队在应用OKR工作法时需要考虑的关键因素,为读者提供了有益的指导和思考方向。文章内容丰富,涵盖了产品技术团队OKR的具体应用场景和方法,对于希望了解如何有效应用OKR的技术团队来说,具有很高的参考价值。
仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《技术领导力实战笔记》,新⼈⾸单¥98
《技术领导力实战笔记》,新⼈⾸单¥98
立即购买
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(8)
- 最新
- 精选
- 爱笑笑产品研发团队的KR设定问题深有体会,大家习惯于定义版本的发布与否,因为那是显而易见的事实,而忽略了发布的真正意义是给用户带来真正的价值2018-11-076
- Kqiu卓越的产品运营能够大幅降低平均营销成本,提升用户的终生价值。2023-03-31归属地:湖北1
- Kqiu每个季度得oka周期,很难保证一个大宗产品特性的交付,能别谈获取相关的数据,因此需要定义更为细分的里程碑节点。2023-03-31归属地:湖北1
- Kqiu一个好的产品,交付目标背后应该揭示商业意图。2023-03-31归属地:湖北1
- zhengxm_16OKR是不是更适合敏捷团队?2021-08-201
- 远古的咖啡宏观与微观需要和谐统一,战略与战术要相辅相成。2020-04-031
- Kqiu设定这类目标和关键结构,同时公开给其他部门的同事,让大家周知这些事务的重要性,争取支持,既能够激励销售和营销部门,同时也能建立更强的业务拓展信心。2023-04-01归属地:湖北
- Kqiu技术债务包括,技术架构的调整和技术选型的升级等。2023-04-01归属地:湖北
收起评论