产品技术团队OKR应用指南与常见类型.pdfVIP

第23讲|产品技术团队OKR使用法则

2018-5-23明道创始人CEO任向晖

经常有团队问我，团队或者部门是否可以应用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解决客户自助部署问

题”就是更加完整的目标描述。

正是因为如此，这类目标所配套的关键结果（KeyResults）也要能够反映出意图达成的

KPI（请中性理解这里的KPI含义）。发布时间本身不应该成为KR，发布后能够形成的一个关

键数据指标才是。比如上面“通过2.0解决客户自助部署问题”的Objective可能需要配套一个

KR：自助部署页面的UV数量，它反映了这个特性交付带来的客户价值，每有1000个UV，说明

可能有1000个用户得到了自助部署系统的帮助。

在产品特性交付目标方面，我还经常发现一个常见困难，就是每个季度的OKR周期很难保证一

个大宗的产品特性交付彻底完成，更加不要说获得使用相关的数据。这时候，我们就需要定

义更加细分的里程碑，而不是一个版本的交付，比如“完成单元测试”、“完成数据架构设

计”等。

2、提升开发和运维质量

在产品型公司的早期，因为经验和能力的原因，在产品开发和运维过程（devops）中存在大

量缺陷。有一些质量问题也可能是因为“MVP”理念导致的。这些可能都是创业公司不可避

免的阶段。

但当公司开启了商业化进程，建立了专门的销售团队，低质量的产品会消耗巨大的营销投

入，不仅无法转化满意的客户，而且会让整个团队士气低落。

但站在公司的角度看，刚刚建立了销售团队，管理层的注意力通常被牵制在销售团队的形成

和管理上，有时候是无暇顾及，有时候是没有意识到产品质量对于提高销售效率的重要性。

与其等到部门之间相互指责和推诿，有全局观的CTO应该尽快聚焦在提升质量的目标上。在达

成这类目标时，产品技术团队的自治能力至关重要。

技术产品的质量提升目标不难设定用于衡量的关键结果（KR），但指标选择的过程最好依然

是从下至上的，因为非专业人员很难有相关的知识背景。如果是和软件缺陷有关的质量改

进，这个关键结果最好能够落在测试流程内部（用例的数量和覆盖度，测试的自动化程度

等），而不是去衡量客户投诉率这样的滞后性KR；如果是和运维质量相关的目标，KR则更容

易选择一些，因为有足够多的监控工