技术领导力实战笔记_29_第23讲_|_产品技术团队OKR使用法则
经常有团队问我，团队或者部门是否可以应用OKR工作法，我的回答一般是否定的，像销售市场、人事行政这样的职能部门，如果彼此独立设定OKR的话呢，几乎必然是无法和公司的聚焦目标对齐的，而且这些孤立的部门无法形成完整的业务链条。
如果不能从公司或者事业单元的角度出发，就无法识别出影响成长的瓶颈问题和可能存在的增长动因，也就无法做有意义的聚焦。
但是这个问题在产品技术部门可能是个例外，尤其是产品型公司的产品技术团队。
一方面是因为产品型公司的聚焦重点经常会放在产品本身。
另一方面是因为很多互联网公司在产品技术方面遇到的问题和机会都非常接近。
以至于我看到不少科技公司在企业层面的OKR设定都非常近似。
即便如此，也并非所有的产品、技术团队都适合独立引入OKR方法。
如果要让这个方法在企业中发挥出成效，不产生部门本位主义，那么这个团队要符合以下这些特征。
一、产品技术团队能够对产品的设计、开发和交付整体负责，团队具备主控性，而不是受制于多个部门的配合。
二、非项目服务业务模式产品技术团队服务的是本企业的产品，而不是客户的产品。
否则，这个团队的核心管理体制很难超越项目管理本身，而且外包项目的生命周期也不足以来激励OKR的实施。
三、公司的业务成效很大程度上取决于产品本身的定位特性，与市场需求的适配度和产品质量销售和营销职能起的是放大器作用。
消费者应用领域的公司呢，大多符合这个条件。
如果是to b的产品，则要视情形来看，如果以上先决条件不存在，那么这样的团队独立实施OKR的成效是不乐观的。
实际上，缺乏自制度和管理关注度的产品，技术团队本身也很难有动力来自行发起目标管理，即使做一般也只是为了响应公司。
从上至下的管理要求而已。
当我辅导了十家科技企业的OKR制定沟通会议以后，我发现这类企业的OKR选择呢有非常明显的规律，团队相对容易达成一致的目标，意图大体会分成这么几类。
一、产品特性交付里程碑，这可能是最常见的目标之一。
产品技术团队因为负担交付产品和特性的责任，所以容易有这样习惯性的思维。
本季度发布某某某特性交付二点零版本产品等。
在这个动因下，产品技术部门设定目标要有更清醒的头脑和更整体的认知。
为什么要交付二点零版本？二点零版本主要解决的问题是什么？除了形式上的交付用什么k二能够更好的定义交付成功呢？一个好的产品交付目标应该揭示背后的商业意图，比如通过二点零解决客户自助部署问题，就是更加完整的目标描述。
正是因为如此，这类目标所配套的关键结果，也要能够反映出意图达成的。
Kpi发布时间本身不应该成为k二发布后能够形成的一个关键数据指标才是。
比如，上面通过二点零解决客户自助部署问题的objective,可能需要配套一个KR自助部署页面的UV数量，它反映了这个特性交付带来的客户价值没有一千个UV,说明可能有一千个用户得到了自助部署系统的帮助。
在产品特性、交付目标方面，我还经常发现一个常见困难，就是每个季度的OKR周期，很难保证一个大宗的产品特性交付彻底完成，更加不要说获得使用相关的数据。
这时候呢我们就需要定义更加细分的里程碑，而不是一个版本的交付，比如完成单元测试，完成数据架构设计等。
二、提升开发和运维质量。
在产品型公司的早期因为经验和能力的原因，在产品开发和运维过程中存在大量缺陷。
有一些质量问题，也可能是因为MVP理念导致的。
这些呢可能都是创业公司不可避免的阶段。
但当公司开启了商业化进程，建立了专门的销售团队，低质量的产品会消耗巨大的营销投入，不仅无法转化满意的客户，而且会让整个团队士气低落。
但站在公司的角度看，刚刚建立的销售团队，管理层的注意力通常被牵制，在销售团队的形成和管理上。
有时候是无暇顾及，有时候是没有意识到产品质量对于提高销售效率的重要性，与其等到部门之间互相指责和推诿，有全局观的CTO呢，应该尽快聚焦在提升质量的目标上。
在达成这类目标时，产品、技术团队的自制能力至关重要，技术产品的质量提升，目标不难设定于衡量的关键结果，但指标选择的过程最好依然是从下至上的，因为非专业人员很难有相关的知识背景。
如果是和软件缺陷有关的质量改进，这个关键结果，最好能够落在测试流程内部，而不是去衡量客户投诉率这样的滞后性。
K二，如果是和运维质量相关的目标，k二则更容易选择一些因为有足够多的监控工具来直接提供有意义的指标。
三、运营改善相关产品运营的职能划分在不同公司不一样，但有很多互联网企业很重视产品运营，并且意识到产品设计和研发团队对运营管理的直接驱动力。
所以也有不少产品技术团队会直接提出和运营改善有关的目标。
这通常发生在企业的成长阶段。
Aa二二二是建立运营改善目标的最佳模型。
它揭示出一个产品的总体成功，来自这五个基本运营环节的成功。
产品运营绩效目标的达成，依靠的是方法，智力的投入。
比如通过用户上手指南设计，提升新用户激活度，而它带来的产出在财务上却非常险要。
卓越的产品运营能够大幅降低平均营销成本，提升用户终身价值。
从这个角度看，来自产品技术团队的相关目标设定，能够大幅影响公司的最终绩效。
这类目标的描述呢可以非常直白，面对惨淡的留存产品，团队应该意识到提升用户留存是一个显然的目标意图。
但是在每个公司的具体业务中，它的描述可以更加明确，比如通过游戏化设计来加强用户留存，通过one boarding模块加强用户留存等，这标的设定越明确。
在OK二执行过程中的任务设计就越顺畅，在复盘时，头脑也更加清醒，不会被干巴巴的数字所制约和开发运维质量提升相关的目标。
类似产品运营的k二制定也有它的专业性要求，比如有关用户留存的k二，专业领域内有几十个可以使用的指标。
到底哪个指标能够反映当下目标的实现度呢？次日，留存和次月留存可能有完全不同的暗示，这需要专业的产品运营自发来选择指标，而不是等待管理层派发指标。
同样，前面提到的目标描述的具体度也会影响我们选择k二时的精准度。
四、提升产品市场适配度。
产品的功能和特性与客户的实际需求存在断层，这是一个普遍的企业失败原因，不仅在产品早期可能出现在扩张阶段，也可能再次遇到杰弗瑞摩尔在经典著作跨越鸿沟中阐明了出现这种情况的必然性，尤其是科技产品早期用户和主流用户在需求和心理上的巨大差异，使得一个新产品在进入早期市场和拓展主流市场的不同阶段，面临完全不同的市场接受度。
因为市场部门很难独立定义这样的目标，不仅可能缺乏足够的决策信息，也很难有这样的决策权威。
因为它很容易挑战到一个公司的品牌和市场定位，细分市场选择。
因以这类目标的设定呢，通常都需要和管理层销售业务部门充分的沟通设定。
好，这一类的目标的前提是企业对理想客户对象有更加明确的定义。
假设这个步骤能够达成共识，那么产品技术团队就需要和销售业务团队仔细沟通，产品应该怎样改进，才能更好的满足这类目标客户的需求。
在以季度为周期的OKR执行中，聚焦解决那些能够有助于提高产品市场适配度的关键特性。
这时候选择对应市场的销售转化率，作为k二可能是更明智的做法。
因为在客户买单之前，我们很难找到可靠的前导性指标。
对于to c产品的验证要更加容易一些，一般留存率和活跃度指标都能够很好的反映需求匹配度。
五、技术选型变更和偿还技术债。
在业务成长到一个阶段时，有一些技术团队会意识到紧迫的架构调整、技术选型升级等偿还技术债问题，这更加是一个需要由下至上设定目标的领域。
因为很少有公司的管理层和其他业务部门关注这一点。
如果业务发展顺利，用户不断增长，那么该发生的事情一定会发生。
警惕性高的CTO们会未雨绸缪，设定这类目标时要重视的是和管理层达成共识，因为这类技术工作必然会影响功能特性，开发锁死，一些常规事务的进展也可能涉及一些可控风险。
如果没有事先的沟通，很可能会发生不必要的冲突。
当然，这些目标是否应该成为产品技术部门某季度必须面对的关键目标不能是CTO的主观臆断。
它应该是建立在数据的客观分析和预测上。
衡量这类指标的k二呢也不难识别，甚至纯技术层面的压力测试，就能够很好的回答这个问题。
我们有没有让基础架构更加健壮呢？我们能否承受每小时一百万次以上的访问呢？设定了这类目标和关键结构，就公开给其他部门的同事。
这样既能够让团队周知这些事物的重要性，争取支持，也能够激励营销和销售部门建立更强的业务拓展信心。
上面我列举了产品技术部门可能独立制定的五类目标类型，他们中的一部分依然有赖于和其他部门的深度协作，KR的设计也考验团队的策略分析和批判性思维能力。
这这些都还只是开始OKR目标的有效达成，并不是依赖选择出科学的k二，而是需要设计出切实有效尽责执行的任务项，而且连续跟踪这些任务的完成状况，遇到的问题、改进方题，我为什么要强调任务设计而不是任务分配呢？因为OKR目标所应对的问题，通常不是一个常规运营问题，更加不是一个逐步改良性的目标，而是一个阻碍企业成长的关键问题，必须集中精力去跃升。
如果依靠一般的任务分配所能够达成的成效，是很难有惊喜的当OK二、脱离了传统的绩效考核范畴，参与者就可以解放思想，采用创造性的手段来达成目标。
这就是为什么要叫任务设计。
在产品技术相关的目标达成中，我发现卓越完成的情况往往依赖两个重要的驱动力，一是成员的敬业度，二是成员的学习能力。
对于一个产品技术问题的解决很少存在可不可行的问题，更多的是团队暂时没有取得相关的能力，不知道行业的最佳实践是怎样的，敬业度又和学习能力相辅相成，彼此关联。
所以，想要OK二目标的达成度提高，CTO和产品，VP们应该长期关注的是人才的选拔标准和团队共同学习进步的具体安排。
我在管理明道的几年中，最大的感悟就是这一点。
科技公司的兴起来自于关键技术能力的提前掌握。
同样，科技公司的衰败，也是因为没有能够跟上产品技术进步的洪流，它和团队成员有没有及时完成一个短期绩效目标，没有太多联系。
所以，OKR工作法看似是一个围绕短期高速迭代的执行落地方法。
但它的有效性有赖于使用者对长期绩效和价值创造的绝对关注。
作者简介，任向辉企业社会化协作平台明道创始人及CEO梅花网创始人。