产品技术团队怎样引入 OKR 工作法

文/明道创始人任向晖

经常有团队问我，团队或者部门是否可以应用 OKR 工作法。我一般回答是否定的。像销售、市场、人事、行政这样的职能部门，如果彼此独立设定 OKR，几乎必然是无法和公司的聚焦目标对齐的。而且这些孤立的部门无法形成完整的业务链条，如果不能从公司或者事业单元的角度出发，就无法识别出影响成长的瓶颈问题和可能存在的增长动因，也就无法做有意义的聚焦。有些团队强行实施，最终的结果只是把一般运营流程中的 KPI 换了一个名词表达而已。更糟糕的情况是各个部门和公司同时实施不同层级的 OKR，结果部门的基层员工就很容易在部门 OKR 和公司 OKR 之间发生混淆。有双重的目标指引，自然也就难以分辨优先度。

但是，这个问题在产品技术部门可能是个例外。尤其是产品型公司的产品技术团队。一方面是因为产品型公司的聚焦重点经常会发生在产品本身上；另一方面是因为很多互联网公司在产品技术方面遇到的问题和机会都非常接近，以至于我看到不少科技公司在企业层面的 OKR 设定都非常近似。

先决条件

即便如此，也并非所有的产品技术团队都适合独立引入 OKR 方法。如果要让这个方法在企业中发挥出成效，不产生部门本位主义，那么这个团队要符合以下这些特征：

1）产品技术团队能够对产品的设计、开发和交付整体负责；团队具备主控性，而不是受制于多个部门的配合；

2）非项目服务业务模式，产品技术团队服务的是本企业的产品，而不是客户的产品，否则这个团队的核心管理体制很难超越项目管理本身。而且外包项目的生命周期也不足以来激励 OKR 的实施。

3）公司的业务成效很大程度上取决于产品本身的定位、特性与市场需求的适配度和产品质量；销售和营销职能起的是放大器作用。消费者应用领域的公司大多符合这个条件。如果是面向企业的产品则要视情形来看。

同时，这三个基础条件也决定了产品技术主管一般都是公司的核心管理人员，对公司的资源分配，协调其他部门的工作能够起到关键影响。

如果以上提到的先决条件不存在，那么这样的团队独立实施 OKR 的成效是不乐观的。实际上，如果缺乏自治度和管理关注度的产品技术团队本身也很难有动力来自行发起目标管理。即使做，一般也只是为了响应公司从上至下的管理要求而已。

常见的产品技术部门 OKR 类型

当我辅导了十家科技企业的 OKR 制定沟通会议以后，我发现这类企业的 OKR 选择有非常明显的规律。团队相对容易达成一致的目标意图（Objective）大体会分成这么几类：

1、产品特性交付里程碑

这可能是最常见的目标之一。产品技术团队因为担负交付产品和特性的责任，所以容易有这样习惯性的思维——本季度发布某某特性，交付 2.0 版本产品等。

在这个动因下，产品技术部门设定目标要有更清醒的头脑和更整体的认知。为什么要交付 2.0 版本？2. 0版本主要解决的问题是什么？除了形式上的交付，用什么 KR 能够更好地定义交付成功？一个好的产品交付目标应该揭示背后的商业意图。比如：「通过 2.0 解决客户自助部署问题」，「通过 3.0 解决合作伙伴增加销售选项」就是更加完整的目标描述。

正是因为如此，这类目标所配套的关键结果（Key Results）也要能够反映出意图达成的 KPI（请中性理解这里的 KPI 含义）。发布时间本身不应该成为 KR，发布后能够形成的一个关键数据指标才是。比如上面「通过 2.0 解决客户自助部署问题」的 Objective 可能需要配套一个 KR：自助部署页面的 UV 数量，它反映了这个特性交付带来的客户价值，每有 1000 个 UV，说明可能有 1000 个用户得到了自助部署系统的帮助。在第二个例子中，合作伙伴销售中新产品的占比可能是一个有价值的 KR。

在产品特性交付目标方面，我还经常发现一个常见困难，就是每个季度的 OKR 周期很难保证一个大宗的产品特性交付彻底完成，更加不要说获得使用相关的数据。这时候，我们就需要定义更加细分的里程碑，而不是一个版本的交付，比如「完成单元测试」、「完成数据架构设计」等。

2、提升开发和运维质量

在产品型公司的早期，因为经验和能力的原因，在产品开发和运维过程（DevOps）中存在大量缺陷。有一些质量问题也可能是因为「MVP」理念导致的。这些可能都是创业公司不可避免的阶段。

但当公司开启了商业化进程，建立了专门的销售团队，低质量的产品会消耗巨大的营销投入，不仅无法转化满意的客户，而且会让整个团队士气低落。

但站在公司的角度看，刚刚建立了销售团队，管理层的注意力通常被牵制在销售团队的形成和管理上，有时候是难以顾暇，有时候是没有意识到产品质量对于提高销售效率的重要性。与其等到部门之间相互指责和推诿，有全局观的 CTO 应该尽快聚焦在提升质量的目标上。在达成这类目标时，产品技术团队的自治能力至关重要。

技术产品的质量提升目标不难设定用于衡量的关键结果（KR），但指标选择的过程最好依然是从下至上的，因为非专业人员很难有相关的知识背景。如果是和软件缺陷有关的质量改进，这个关键结果最好能够落在测试流程内部（用例的数量和覆盖度，测试的自动化程度等），而不是去衡量客户投诉率这样的滞后性 KR；如果是和运维质量相关的目标，KR 则更容易选择一些，因为有足够多的监控工具来直接提供有意义的指标。我说这类KR容易识别，有个前提，就是 KR 的选择制定能够充分地发挥主管工程师的领域知识，而不是管理者由上至下制定，简单说，就是让专业的人来测量。

3、运营改善相关

产品运营的职能划分在不同公司不一样，但有很多互联网企业很重视产品运营，并且意识到产品设计和研发团队对运营管理的直接驱动力。所以，也有不少产品技术团队会直接提出和运营改善有关的目标，这通常发生在企业的成长阶段。

AARRR（获取，激活，转化，留存和推荐）是建立运营改善目标的最佳模型，它揭示出一个产品的总体成功来自这五个基本运营环节的成功。产品运营绩效目标的达成依靠的是方法、智力的投入，比如通过 User Onboarding Design（用户上手指南设计）提升新用户激活度，而它带来的产出在财务上却非常显要。卓越的产品运营能够大幅降低平均营销成本，提升用户终生价值。从这个角度看，来自产品技术团队的相关目标设定，能够大幅影响公司的最终绩效。

这类目标的描述可以非常直白，面对惨淡的留存，产品团队应该意识到“提升用户留存”是一个显然的目标意图，但是在每个公司的具体业务中，它的描述可以更加明确，比如「通过游戏化设计来加强用户留存」，「通过 Onboarding 模块加强用户留存」等。目标的设定越明确，在 OKR 执行过程中的任务设计就越顺畅，在复盘时头脑也更加清醒，不会被干巴巴的数字所制约。

和开发运维质量提升相关的目标类似，产品运营的 KR 制定也有它的专业性要求，比如有关用户留存的 KR，专业领域内有几十个可以使用的指标，到底哪个指标能够反映当下目标的实现度？次日留存和次月留存可能有完全不同的暗示。这需要专业的产品运营自发来选择指标，而不是等待管理层派发指标。同样，前面提到的目标描述的具体度也会影响我们选择KR时候的精确度。当 OKR 的执行结果和个人的奖惩脱钩的时候，我们就可以自发和客观地选择最科学的指标来衡量目标达成度。

4、提升产品市场适配度

对于产品技术团队来说，这是一个高难度的目标。但对大多数企业来说又是产品化过程中极容易遭遇的问题——产品不对路。产品的功能和特性和客户的实际需求存在断层，这是一个普遍的企业失败原因，不仅在产品早期可能出现，在扩张阶段也可能再次遇到。杰佛瑞·摩尔在经典著作《跨越鸿沟》中阐明了出现这种情况的必然性。尤其是科技产品，早期用户和主流用户在需求和心理上的巨大差异使得一个新产品在进入早期市场和拓展主流市场的不同阶段面临完全不同的市场接受度。

产品市场部门很难独立定义这样的目标。不仅可能缺乏足够的决策信息，也很难有这样的决策权威，因为它很容易挑战到一个公司的品牌和市场定位，细分市场选择。所以，这类目标的设定通常都需要和管理层，销售业务部门建立充分的沟通，对每个企业来说，都是头等大事。

在理想情况下，产品技术团队从第一天起就十分重视客户导向的产品开发流程，产品的每一步定义都小心谨慎地获得客户验证，每一个特性扩展也都保持足够的自律。但在企业实践中，这种理想情况很难达成。即便全员都高度客户导向，也有选择和取舍上的困难。我发现科技型企业在这个问题上的试错成本总是最高的。

设定好这一类的目标的前提是企业对「理想客户对象」有更加明确的定义，如果不能定义清楚目标客户，那么所谓的适配度提升就缺失了参照对象。假设这个步骤能够达成共识，那么产品技术团队就需要和销售业务团队仔细沟通产品应该怎样改进才能更好地满足这类目标客户的需求。在以季度为周期的 OKR 执行中，聚焦解决那些能够有助于提高产品市场适配度的关键特性。这时候，选择对应市场的销售转化率作为 KR 可能是更明智的做法。因为所谓的需求匹配，最终是依靠客户的买单来证明的，在客户买单之前，我们很难找到可靠的前导性指标。对于面向个人用户的产品，验证要更加容易一些，一般留存率和活跃度指标都能够很好地反映需求匹配度。

这个类型的 OKR 叙述起来比较抽象，我举一个比较典型的例子。比如一个 SaaS产品在运营两年后，产品功能和模块越来越繁复，导致产品在面对任何一个具体客户的时候无法用简明的陈述和演示来说明清楚产品价值。如果通过 OKR 工作法来解决此类问题，就可能涉及到这类短期目标。比如「强化产品针对服务型企业的 CRM 特性」。与此相关的 KR 可以是服务型企业的成交转化率或者留存率。虽然这个 KR 不得不滞后衡量，但它的确是反应这个意图目标的实现程度。

5、技术选型变更和偿还技术债

在业务成长到一个阶段时，有一些技术团队会意识到紧迫的架构调整、技术选型升级等偿还技术债问题。这更加是一个需要由下至上设定目标的领域，因为很少有公司的管理层和其他业务部门关注这一点。如果业务发展顺利，用户不断增长，那么该发生的事情一定会发生。警惕性高的 CTO 们会未雨绸缪，在频繁宕机之前，把问题提前解决。

设定这类目标时，要重视的是和管理层达成共识，因为这些技术工作必然会影响功能特性开发，锁死一些常规事务的进展，也可能涉及一些可控风险。如果没有事先的沟通，很可能会发生不必要的冲突。

当然，这些目标是否应该成为产品技术部门某季度必须面对的关键目标，这不能是 CTO 的主观臆断。它应该建立在数据的客观分析和预测上。

衡量这类目标的 KR 也不难识别，甚至纯技术层面的压力测试就能够很好地回答这个问题。我们有没有让基础构架更加健壮？我们能否承受每小时 100 万次以上的访问？设定了这类目标和关键结构，就公开给其他部门的同事，这样既能够让团队周知这些事务的重要性，争取支持，也能够激励营销和销售部门，建立更强的业务拓展信心。

执行和评估

我列举了产品技术部门可能独立制定的五类目标类型，它们中的一部分依然有赖于和其他部门的深度协作，KR 的设计也考验团队的策略分析和批判性思维能力。但这些都还只是开始，OKR目标的有效达成，并不是依赖选择出科学的KR，而是需要设计出切实有效，尽责执行的任务项，并且连续跟踪这些任务的完成状况，遇到的问题，改进方案。

我为什么要强调「任务设计」，而不是「任务分配」？因为 OKR 目标所对应的问题通常不是一个常规运营问题，更加不是一个逐步改良性的目标，而是一个阻碍企业成长的关键问题，必须集中精力去跃升。如果依靠一般的任务分配所能够达到的成效是很难有惊喜的。当 OKR 脱离了传统的绩效考核范畴，参与者就可以解放思想，采用创造性的手段来达成目标，这就是为什么要叫「任务设计」。

在产品技术相关的目标达成中，我发现卓越完成的情况往往依赖两个重要的驱动力，一是成员的敬业度，二是成员的学习能力。对于一个产品技术问题的解决，很少存在可不可行的问题，更多的是团队暂时没有取得相关的能力，不知道行业的最佳实践是怎样的。敬业度又和学习能力相辅相成，彼此关联。所以，想要 OKR 目标的达成度提高，CTO 和产品 VP 们应该长期关注的是人才的选拔标准和团队共同学习进步的具体安排。我在管理明道的几年中，最大的感悟就是这一点。科技公司的兴起来自于关键技术能力的提前掌握，同样，科技公司的衰败也是因为没有能够跟上产品技术进步的洪流，它和团队成员有没有及时完成一个短期绩效目标没有太多联系。所以，OKR 工作法看似是一个围绕短期，高速迭代的执行落地方法，但它的有效性有赖于使用者对长期绩效和价值创造的绝对关注。

---

题图： Marine with Sailboats  -   Léon Spilliaert, 1925.