产品技术团队如何引入okr工作法

技术团队：如何引入OKR工作法本文作者将结合自身经验与大家：团队如何引进OKR？enjoy~经常有团队问我，团队或者部门是否可以应用OKR工作法。我回答是的。像销售、市场、人事、行政这样的，如果彼此设定OKR，几乎必然是无法和公司的聚焦目标对。而且这些孤立的部门无法形成完整的业务链条，如果不能从公司或者事业单元的角度出发，就无法识别出影响成长的瓶颈问 题 快递公司问题件快递公司问题件货款处理关于圆的周长面积重点题型关于解方程组的题及答案关于南海问题 和可能的增长动因，也就无法做有意义的聚焦。有些团队强行实施，最终的结果只是把运营流程中的KPI换了一个名词表达而已。更糟糕的情况是各个部门和公司同时实施不同层级的OKR，结果部门的基层员工就很容易在部门OKR和公司OKR之间发生。有双重的目标指引，自然也就难以分辨优先度。但是，这个问题在技术部门可能是个例外。尤其是型公司的技术团队。一方面是因为型公司的聚焦重点经常会发生在产品本身上；另一方面是因为很多互联网公司在技术方面遇到的问题和机会都非常接近，以至于我看到不少科技公司在企业层面的OKR设定都非常近似。一.先决条件即便如此，也并非所有的技术团队都适合引入OKR。如果要让这个在企业中发挥出成效，不产生部门本位主义，那么这个团队要符合以下这些特征：1.技术团队能够对的设计、开发和交付整体负责；团队具备主控性，而不是受制于多个部门的配合；2.非项目服务业务模式，技术团队服务的是本企业的产品，而不是客户的，否则这个团队的管理体制很难超越项目管理本身。而且外包项目的生命周期也不足以来激励OKR的实施。3.公司的业务成效很大程度上取决于本身的定位、特性与市场需求的适配度和质量；销售和职能起的是放大器作用。消费者应用领域的公司大多符合这个条件。如果是2B的则要视情形来看。同时，这三个基础条件也决定了技术主管都是公司的管理，对公司的资源分配，协调其他部门的工作能够起到关键影响。如果以上提到的先决条件不，那么这样的团队实施OKR的成效是不乐观的。实际上，如果缺乏自治度和管理关注度的技术团队本身也很难有动力来自行发起目标管理。即使做，也只是为了响应公司从上至下的管理要求而已。二.常见的技术部门OKR类型当我辅导了十家科技企业的OKR制定会议以后，我发现这类企业的OKR选择有非常明显的规律。团队相对容易达成一致的目标意图（Objective）大体会分成这么几类：1.特付里程碑这可能是最常见的目标之一。技术团队因为担负交付和特性的责任，所以容易有这样习惯性的思维——本季度发布特付2.0版本等。在这个动因下，技术部门设定目标要有更清醒的头脑和更整体的认知。为什么要交付2.0版本？2.0版本主要解决的问题是什么？除了形式上的交付，用什么KR能够更好地定义交付？一个交付目标应该揭示背后的商业意图。比如：“通过2.0解决客户自助部署问题”，“通过3.0解决合作伙伴增加销售选项”就是更加完整的目标描述。正是因为如此，这类目标所配套的关键结果（KeyResults）也要能够反映出意图达成的KPI（请中性理解这里的KPI含义）。本身不应该成为KR，发布后能够形成的一个关键数据指标才是。比如上面“通过2.0解决客户自助部署问题”的Objective可能需要配套一个KR：自助部署页面的UV数量，它反映了这个特付带来的客户价值，每有1000个UV，说明可能有1000个用户得到了自助部署系统的帮助。在第二个例子中，合作伙伴销售中新的可能是一个有价值的KR。在特付目标方面，我还经常发现一个常见，就是每个季度的OKR周期很难保证一个大宗的特付彻底完成，更加不要说获得使用相关的数据。这时候，我们就需要定义更加细分的里程碑，而不是一个版本的交付，比如“完成单元测试”、“完成数据架构设计”等。2.提升开发和运维质量在型公司的早期，因为经验和能力的，在开发和运维过程（devops）中大量缺陷。有一些质量问题也可能是因为“MVP”理念导致的。这些可能都是创业公司不可避免的阶段。但当公司开启了商业化进程，建立了专门的销售团队，低质量的会消耗巨大的投入，不仅无法转化满意的客户，而且会让整个团队士气低落。但站在公司的角度看，刚刚建立了销售团队，管理层的注意力通常被牵制在销售团队的形成和管理上，有时候是难以顾暇，有时候是没有质量对于提高销售效率的重要性。与其等到部门之间相互指责和推诿，有全局观的CTO应该尽快聚焦在提升质量的目标上。在达成这类目标时，技术团队的自治能力至关重要。技术的质量提升目标不难设定用于衡量的关键结果（KR），但指标选择的过程最好依然是从下至上的，因为非专业很难有相关的知识背景。如果是和缺陷有关的质量改进，这个关键结果最好能够落在测试流程内部（用例的数量和覆盖度，测试的自动化程度等），而不是去衡量率这样的滞后性KR；如果是和运维质量相标，KR则更容易选择一些，因为有足够多的工具来直接提供有意义的指标。我说这类KR容易识别，有个前提，就是KR的选择制定能够充分地发挥主管工程师的领域知识，而不是管理者由上至下制定，简单说，就是让专业的人来测量。3.运营相关运营的职能划分在不同公司不一样，但有很多互联网企业很重视运营，并且设计和研发团队对运营管理的直接驱动力。所以，也有不少技术团队会直接提出和运营有标，这通常发生在企业的成长阶段。AARRR（获取，激活，转化，留存和推荐）是建立运营目标的最佳模型，它揭示出一个的总体来自这五个基本运营环节的成功。运营绩效目标的达成依靠的是、智力的投入，比如通过UserOnboardingDesign（用户上手指南设计）提升新用户激活度，而它带来的产出在财务上却非常显要。卓越的运营能够大幅降低平均成本，提升用户终生价值。从这个角度看，来自技术团队的相关目标设定，能够大幅影响公司的最终绩效。这类目标的描述可以非常直白，面对惨淡的留存，团队应该意识到“提升用户留存”是一个显然的目标意图，但是在每个公司的具体业务中，它的描述可以更加明确，比如“通过游戏化设计来加强用户留存“，“通过Onboarding模块加强用户留存”等。目标的设定越明确，在OKR执行过程中的任务设计就越顺畅，在复盘时头脑也更加清醒，巴巴的数字所制约。和开发运维质量提升相标类似，运营的KR制定也有它的专业性要求，比关用户留存的KR，专业领域内有几十个可以使用的指标，到底哪个指标能够反映当下目标的实现度？次日留存和次月留存可能有完全不同的暗示。这需要专业的运营自发来选择指标，而不是等待管理层派发指标。同样，前面提到的目标描述的具体度也会影响我们选择KR时候的精确度。当OKR的执行结果和个人的奖惩脱钩的时候，我们就可以自发和客观地选择最科学的指标来衡量目标达成度。4.提升市场适配度对于技术团队来说，这是一个高难度的目标。但对大多数企业来说又是化过程中极容易遭遇的问题——不对路。的功能和特性和客户的实际需求断层，这是一个普遍的企业失败，不仅在早期可能出现，在扩张阶段也可能再次遇到。杰佛瑞·在经典著作《鸿沟》中阐明了出现这种情况的必然性。尤其是科技，早期用户和主流用户在需求和心理上的巨大差异使得一个新在进入早期市场和拓展主流市场的不同阶段完全不同的市场接受度。市场部门很难定义这样的目标。不仅可能缺乏足够的决策，也很难有这样的决策权威，因为它很容易到一个公司的品牌和市场定位，细分市场选择。所以，这类目标的设定通常都需要和管理层，销售业务部门建立充分的，对每个企业来说，都是头等大事。在理想情况下，技术团队从第一天起就十分重视客户导向的开发流程，的每一步定义都谨慎地获得客户验证，每一个特性扩展也都保持足够的自律。但在企业实践中，这种理想情况很难达成。即便全员都高度客户导向，也有选择和取舍上的。我发现科技型企业在这个问题上的试错成本总是最高的。设定好这一类的目标的前提是企业对“理想客户对象”有更加明确的定义，如果不能定义清楚目标客户，那么所谓的适配度提升就缺失了参照对象。假设这个步骤能够达成共识，那么技术团队就需要和销售业务团队仔细应该怎样改进才能更好地满足这类目标客户的需求。在以季度为周期的OKR执行中，聚焦解决那些能够有助于提高市场适配度的关键特性。这时候，选择对应市场的销售转化率作为KR可能是更明智的做法。因为所谓的需求匹配，最终是依靠客户的来 证明 住所证明下载场所使用证明下载诊断证明下载住所证明下载爱问住所证明下载爱问 的，在客户之前，我们很难找到可靠的前导性指标。对于2C，验证要更加容易一些，留存率和活跃度指标都能够很好地反映需求匹配度。这个类型的OKR叙述起来比较抽象，我举一个比较典型的例子。比如一个SaaS在运营两年后，功能和模块越来越繁复，导致在面对任何一个具体客户的时候无法用简明的陈述和演示来说明清楚价值。如果通过OKR工作法来解决此类问题，就可能涉及到这类短期目标。比如“强化服务型企业的CRM特性”。与此相关的KR可以是服务型企业的成交转化率或者留存率。虽然这个KR不得不滞后衡量，但它的确是反应这个意图目标的实现程度。5.技术选型变更和偿还技术债在业务成长到一个阶段时，有一些技术团队会紧迫的架构调整、技术选型升级等偿还技术债问题。这更加是一个需要由下至上设定目标的领域，因为很少有公司的管理层和其他业务部门关注这一点。如果业务发展顺利，用户不断增长，那么该发生的事情一定会发生。警惕性高的CTO们会未雨绸缪，在频繁宕机之前，把问题提前解决。设定这类目标时，要重视的是和管理层达成共识，因为这些技术工作必然会影响功能特性开发，锁死一些常规事务的进展，也可能涉及一些可控风险。如果没有事先的，很可能会发生不必要的。当然，这些目标是否应该成为技术部门某季度必须面对的标，这不能是CTO的臆断。它应该建立在数据的客观分析和上。衡量这类目标的KR也不难识别，甚至纯技术层面的测试就能够很好地回答这个问题。我们有没有让基础构架更加健壮？我们能否承受每小时100万次以上的？设定了这类目标和关键结构，就公开给其他部门的同事，这样既能够让团队这些事务的重要性，争取支持，也能够激励和销售部门，建立更强的业务拓展信心。三.执行和评估我列举了技术部门可能制定的五类目标类型，它们中的一部分依然有赖于和其他部门的深度协作，KR的设计也考验团队的策略分析和性思维能力。但这些都还只是开始，OKR目标的有效达成，并不是依赖选择出科学的KR，而是需要设计出切实有效，尽责执行的任务项，并且连续跟踪这些任务的完成状况，遇到的问题，改进方案。我为什么要强调“任务设计”，而不是“任务分配”？因为OKR目标所对应的问题通常不是一个常规运营问题，更加不是一个逐步改良性的目标，而是一个阻碍企业成长的关键问题，必须集中精力去跃升。如果依靠的任务分配所能够达到的成效是很难有惊喜的。当OKR脱离了传统的绩效考核范畴，参与者就可以思想，采用创造性的来达成目标，这就是为什么要叫“任务设计”。在技术相标达成中，我发现卓越完成的情况往往依赖两个重要的驱动力，一是成员的敬业度，二是成员的学习能力。对于一个技术问题的解决，很少可不可行的问题，的是团队暂时没有取得相关的能力，不知道行业的最佳实践是怎样的。敬业度又和学习能力相辅相成，彼此关联。所以，想要OKR目标的达成度提高，CTO和VP们应该长期关注的是的选拔标准和团队共同学习进步的具体安排。我在管理明道的几年中，最大的感悟就是这一点。科技公司的兴起来自于能力的提前掌握，同样，科技公司的衰败也是因为没有能够跟上技术进步的洪流，它和团队成员有没有及时完成一个短期绩效目标没有太多。所以，OKR工作法看似是一个短期，高速迭代的执行落地，但它的有效性有赖于使用者对长期绩效和价值创造的绝对关注。以上就是明道对团队如何引进OKR的理解，欢迎在下方留言交流~作者：，明道创始人本文由@发布于人人都是经理。，转载。题图由作者提供