PMO如何解决业务价值和数据指标不匹配的情况，并且让数据指标更好地服务业务价值？这篇文章里，作者给出了回答，即将OKR工具、精益价值交付和敏捷框架结合起来，形成一系列的活动。一起来看看本文的拆解和总结。
现代管理学之父彼得·德鲁克大师说“没有度量，就没有管理”，在实际工作中如果不能对工作目标进行量化，就不能确认投入的资源和成本，无法衡量投入和产出，不能确认和追溯某个事情是不是应该做值得做。没有量化凭感觉做事就无法设定执行过程的里程碑，过程偏差无法被监控和纠正，走弯路是理所当然的事儿，不走弯路才是奇迹。
如何正确地围绕业务价值设置可量化的目标（数据指标），并合理设置可量化的里程碑目标呢？这里存在两大难题：
上图是三国演义隆中对的场景，诸葛亮在这里提出了刘备集团的战略思想 ——“若跨有荆、益，…，则霸业可成，汉室可兴矣”。
数据指标是“占据荆益二州”，业务价值是“成就霸业中兴汉室”。后来的剧情大家都耳熟能详，刘备集团确实拿下了荆州和益州，并派最得力的大将关羽镇守荆州，雄主刘备和军师诸葛亮先后担任益州州牧。但是最终只能偏安一隅建立蜀汉，随后被晋所灭，并没有把正宗的汉室江山匡扶起来。
可见即使数据指标达成，业务价值（战略目标）并不一定能达成。
如下图所示，在结构上把大图分为OKR的活跃区和敏捷活动的活跃区。在OKR的活跃区的核心是建立公司和全员的OKR，通过设定OKR以及OKR的持续审视和刷新，形成业务活动过程中的Key Action，并成为敏捷活动的需求输入。
OKR的设定遵从如下的顺序：先根据公司的使命愿景，确认好公司的年度战略目标（或3年的战略目标），也就是OKR的大O，再基于O找到业务存在的5大价值，进而确定年度的O和对应的KR。这个版本的OKR是战略层面的，指引我们到哪儿，是行动的总战略纲领。
接下来再制定战术层面的OKR，通常1个季度搞一次，在战术OKR层面会确定季度目标、策略，从而形成业务和项目，会带来组织架构的调整，和项目的关停并转以及新增。
每个月，还会基于OKR来审视业务执行情况，复盘执行过程的问题，判断策略是否需要调整，项目是否需要调整，组织是否需要调整。每周召开业务经营会，通过OKR来check每一周的执行进展情况，或许会产出组织、业务和项目的调整，但是更多的层面还是在策略和Key Action上的优化和新增。Key Action每天都会有变化，会变成日常的运营活动、日常的产研需求等等。
这里看到有周、月、季度、和年度活动，是不是意味着会有很多呢？确实多，但是执行上是这么来的：每个月的第一周周会改为月度审视，时间为半天。每个季度的第一周周会改为季度复盘和规划会，时长为1天或者2天。年度的战略会一般是在这一年结束前根据情况发起的，时间2-3天不等。
再说回敏捷活跃区，KA会生产源源不断的需求进入到需求列表，在建立需求列表时，每一个需求都必须和KR建立明确的链接，在需求宣讲会前，需求要有明确的KR价值和预期贡献度，通过需求宣讲统一目标认知、明确优先级，形成迭代需求列表。
接下来进入到持续的价值研发和价值交付，每个产品和业务可以有自己的迭代周期。在发布前，需要reveiw需求给用户带来的价值以及运营计划，发布后产生研发效能数据。发布后，根据业务的特点形成自己周期规律的回顾会，回顾会要有价值回溯和过程改进。
在日常迭代的产品上，价值回溯通常和需求宣讲放在一起做，运营活动按着运营节奏来自行定义。这时，还可以形成人效数据。
把OKR贯穿于敏捷活动，建立了价值交付的闭环。在研发环节通过日会建立进日反馈的闭环，通过持续迭代建立迭代闭环，通过回顾会建立价值交付闭环，以上活动又反作用于OKR，通过OKR的周刷新、月审视及时调整KA，进而让价值交付变得更加有效。
OKR是怎么从公司使命愿景往下落的呢？有3个层面，分别通过组织协同和项目管理来落地。
首先是通过业务价值来做使命愿景和年度战略OKR的串联，结合年度复盘和战略路径产生年度的、全局性的、有聚焦目标的年度战略OKR。通过组织协同，自上而下地形成了业务组织、具体的项目（包括战役项目）。
通过组织协同，跨部门、自上而下、自下而上多维度的不断对焦，形成统一的团队目标、项目目标，也会自下而上的产生一些项目。不管是团队目标还是项目目标，都要符合OKR的要求，要有阶段性的结果，可衡量的指标要有一定的挑战性，还要有可执行的路径。
之后，就要通过项目管理，把各个环节的规划执行下去。通过价值回溯、经营管理分析、效能分析，以数据驱动做好过程改进和OKR的优化。
公司的OKR经过分解和策略形成了项目OKR、业务OKR，项目和业务OKR通过上下目标对齐和业务协同，形成了团队和个人的OKR。最终形成了一张网状的OKR表，每个层级的OKR都有不同的特点。
作为PMO团队，在这其中要像管理项目一样，把OKR的实施也当作一个项目来对待。在一个阶段内，OKR的实施也是和项目管理5大过程组的管理是一致的。
在启动和规划阶段，要负责做OKR的拆解、通过自上而下和自下而上的头脑风暴和讨论，通过组织协同制定OKR达成的策略，并形成业务组织和项目组织，形成OKR和项目的一张大图。在执行和监控阶段，通过建立机制，过程管理，来确保风险可控和项目目标的达成，并且要有阶段性的回顾，做到过程改进和持续改善，在收尾阶段组织复盘，让组织活动和项目活动有好改进，有向好的变化。
这是一个年度战略OKR制定过程的case。围绕组织愿景和使命，从长期战略出发，形成了下年度的价值主张。
比如，我们从3年的战略出发，明确了集团价值、商业价值、员工价值、消费者价值和商家价值，进而确定下一年的价值主张。再结合当下的业务实际，包括复盘的结论，来确定下一年的战略路径，最终形成公司级的年度OKR。为确保高层级的OKR达成，管理团队会深入地研讨，提出一些策略和打法，根据价值贡献讨论出优先级，从而明确出OKR要达成的策略，也产生出了一批项目。
通过自上而下和自下而上的对焦，最终产生了一张图。
其主要结构一般为：公司年度OKR有3个O，每个O下面根据不同的KR会形成不同的项目集，每个项目集有自己的OKR，于是会有不同维度的子项目。
项目集要求有执行路径，子项目围绕执行路径形成阶段性的聚焦，帮助项目集达成总体的目标。对于子项目，要把目标和计划分解到月。月度分解在最右侧，由于截图放不下了，所以这个图上看不到。
月度分解也是有策略的，离现在越近，要求越具体、越详尽。通过一张图，把公司、团队、项目、个人的OKR串接起来，每个人都能在项目中找到自己的落位。
当大图建立完毕后，接下来要进入落地阶段，也就是敏捷活跃区。把项目分为长期的业务项目和短期的战役项目。业务项目按着特性，对团队进行拆分，从业务运营开始，到PD、UED、研发和测试。
对于战役项目，会根据目标聚焦的原则拆分为不同的子项目。这样通过特性团队和子项目的形式，能够让团队的目标和工作更聚焦，从而让团队交付的价值更聚焦，团队也会变得更加的专业。这两个拆分叫做功能拆分和团队拆分。
还有一个拆分是做价值交付的拆分，所有的价值交付都会以增量的方式来做持续交付。通过迭代，不断地交付用户可见的价值，这个是第三个拆分。这个过程，可以通过价值交付看板来协助完成的。
这是某个APP产品的迭代示意图，把每个迭代分为4个阶段，包括需求准备阶段、预研阶段，研发阶段和发布阶段。
需求准备阶段是属于运营和PD等需求方的YY阶段，这一阶段要求所有的需求都要有KR项匹配。通过内审后，PMO发起需求宣讲会，评估需求价值和贡献度产生需求的优先级排序从而形成迭代列表。接下来需求经过3周的需求完善、评审、开发集成到对应的版本发布分支，在预演后会发布并有迭代回顾会。
实际上这是一个月度迭代，但根据需求准备和需求研发的阶段性投入特点，巧妙地形成了用户可见的双周价值交付。
在敏捷活动中，有一个非常关键的节点叫做需求宣讲。需求宣讲往往会有4个步骤，首先每个PD阐述需求的价值，现场被关联的开发TL会做一个工时的初步估算，总PD现场和大家根据价值情况快速确认一个基础优先级，如果有争议的，放在会后在集中沟通。于是，会后会形成了具有明确优先级的迭代列表。这一步有一些操作细节，都是围绕OKR来进行的。
发布预演的核心目标是做确认，一个功能和产品的上线，背后一定有思考和业务价值，更需要持续的运营。因此，在这个会上需要管理层基于功能交付做业务判断，并对其后的人力、财务资源做确认。
预演通常有QA来投屏操作，有总PD讲诉迭代目标，对应的产品和运营讲诉功能点的设计和思考，讲诉和竞品的差异以及用户价值，讲诉运营策略和计划。得到确认后，功能会被发布到线上。
迭代发布（可以是灰度发布）上线后会有回顾会，回顾会包括价值回溯和过程改进两个部分。
在敏捷活动中必须安排价值回溯环节，避免搞错用户，搞错用户价值。如果用户和用户价值都正确，还要观察下用户价值在落地过程中有没有脱靶，如有意外情况及时修正、止损或者降级。一定要用用户（孩子）的视角来看真的价值，不要出现如上图所示的情况。
价值回溯要围绕OKR进行，这个过程会有BI提供数据支持，以及第三方视角的业务分析。不管指标的好坏，现场都会有一些决策，下线也好，加码也好，放在哪儿不管也好，总之得有个结论。
季度复盘、月度审视和周会刷新等复盘机制，不同的业务和组织可以有不同的形式，但建议以经营数据分析打头，以Action的确认为收尾。
总而言之，基于OKR的复盘是围绕目标和价值的匹配、关键结果和经营管理数据的匹配，过程中使用不同的复盘方法来进行的。在这个审视的过程中，所有参会人员都会围绕目标数、经营结果、得与失进行分析，结合行业的变化，从中抽丝剥茧得出一些新的策略和战术打法，并调整OKR、项目、组织等等。
在复盘的方法论层面，经常用到的工具包括头脑风暴、专家判断、鱼骨图等等。作者本人比较喜欢GROW模型，能够短平快的解决日常活动中碰到的问题。时间关系，依然不做展开。总而言之，不管黑猫白猫逮住老鼠的就是好猫。
最后来审视一下敏捷活动，敏捷活动划分为4个阶段，第0阶段是准备解决，主要是围绕利用OKR工具建立OKR和项目大图，以此建立对应的业务组织架构和项目组织架构，形成子项目和特性团队，并建立迭代机制。
在预研阶段，依据OKR和业务价值，围绕需求进行需求内审和宣讲，并做价值回溯来明确我们的迭代目标，需求优先级。
在研发阶段，通过看板和站会，结合班车机制做到敏捷的价值交付。
在发布阶段，通过预演、灰度的形式来明确运营策略，最后迭代结束后还有迭代的回顾。
看到这儿，大家一定会觉得这么一套实践活动跑下来挺难的。其实，也确实挺难的。过程中一定会有这样和那样的弯路、变形，比如下文所列执行过程中常见的3个坑。
第一个坑是用户需求背后价值挖掘的坑。假如用户到画室要买一个冲击钻，作为普通卖家会怎么样？“滚粗，我是又不是五金店！”。青铜卖家会怎么做呢，会再多问一句你买冲击钻要干什么？哦，得到的反馈是用户想买画。王者卖家还会再多问一句，你买画干什么？是不是想要一个女朋友？
这说明用户在表达诉求的时候，未必是准确的。在向用户收集需求的过程中，千万不能满足于用户本身的描述，要把用户最本地的需求给深挖出来，这是一种洞察能力。一个好的运营和产品经理，一定要具备这种能力，避免做些不满足用于预期的价值。否则在价值回溯阶段，别人说我的OKR完成了多少多少的时候，你只能说我做了多少需求。
因此，要求通过3W1H、影响地图等方法找到最短价值路径，挖掘用户的最深层次的需求，避免无意义的Key Action。要为价值工作，拒绝瞎忙碌的伪工作。
第二个坑是，是要目标聚焦，找准自己的第一客户是谁，以及要解决第一客户最基本的需求。当一个人被生活所迫只能吃泡面的时候，专家还在说“你要注意健康，泡面不健康啊”。这种建议是没有意义的，因为专家的第一客户选错了群体，服务的目标人群太发散了。
因此在制定OKR的KR时，不但要描述核心指标，还必须附带健康指标。
前面讲过，数据指标是业务价值的一种现象表现，但不能完全取代价值。比如，APP产品设定了一个业务价值，当价值达成后，日活会突破百万。但反过来不是，日活百万不能代表APP的业务价值实现了，因为这百万日活可能是买来的。所以还需要加健康指标，比如次日留存、停留时长。
另外，这里还有一个误区，有的人核心指标没达成，但是健康指标达成，就会沾沾自喜，这是最要不得的，比如百万日活的目标只完成了10%，高高的留存和停留时长数据又有何用？
第三个坑是度量的坑，千万不要把OKR当做KPI来用，OKR只是一个带有优秀方法论的工具。如果当做KPI，OKR就会失去活力。有些度量指标可以写入到KPI，有些度量指标只能当做过程参考的依据，来看趋势的。比如研发效能、经营人效等。请思考下面这个案例：业务价值达成是否数据指标一定达成呢，KPI该如何设定呢？
唐僧师徒取得真经后，如来佛祖和观音菩萨有一段对话。佛祖问，这个取经的项目团队取经路上遇到了多少磨难啊？观音菩萨掐指算了算回答说80难。佛主说，那不行，我们要九九归真，再给唐僧送1个大礼包。真是应了一句话，没有困难制造困难也要上。可见业务价值达成了，数据指标可能并未能达成。
可见，数据指标并不能完全描述业务价值，数据指标所描述的业务价值，未必是真正的业务价值。
好比说大象，一提到大象大家脑海里会立刻显现大象的样子来，但如果要用3个关键指标来定义大象，相信很难通过几个纬度和数字来表达出什么是大象。老子说道可道非常道，佛祖说不可说不可说，也就是这个道理。
业务价值是业务要实现的目标，是基于使命、愿景和价值观所要到达的一个地方，是一种状态和结果，也是相对静态的，是制定KPI的源头。
数据指标则是对这个状态和结果片面的、局部的数字化描述和定义。
PMO如何解决业务价值和数据指标不匹配的情况呢？如何让数据指标更好地服务于业务价值呢？答案是：把OKR工具、精益价值交付、敏捷框架结合起来，形成一系列的活动。
首先是从价值出发设定OKR，这个是使命愿景到年度战略OKR、季度战术OKR制定的一个过程，最终形成了项目大图。
其次是对价值进行深度挖掘，寻找用户最底层的需求，以及最短的用户路径，来规划和指导行为路径，形成了敏捷活动做所用到的需求，并丰富敏捷活动。
再次是敏捷活动，在敏捷的各个活动中，围绕OKR来做活动的改变和优化，聚焦于用户价值，通过高效的过程协同，做到持续的用户价值交付。
最后，通过数据驱动，做周、月、季度、半年度和年度的复盘回顾，来不断调整和修改我们的OKR，以及关联的key action和需求，让我们在创新业务中不断地试错，小步快跑，实现业务价值并赢得市场。
做到了以上还不够，只是完成了“术”的层面，需要用如下的“三个持续”来武装自己和团队，活学活用穿插在日常工作的每一个环节。
第一是持续交付。OKR是敏捷活动的长期价值指引，敏捷活动要做修改和优化，以便于更好地把OKR融入其中。还要建立基于OKR的项目团队和业务团队，以及子项目和特性团队，让敏捷活动中的目标更聚焦，团队活动更专注和高效。在敏捷活动中，把迭代也是使用OKR轻量级的管理起来，制定每次迭代的目标O，让需求聚焦而且和OKR的目标树关联起来。
第二是持续审视。数据指标不能真实地反映出业务价值，数据指标只是业务价值达成后的结果呈现。当佛祖面对业务价值都感慨不可说不可说，所以还要设定健康指标来辅助度量，避免唯核心指标论，要让业务价值能够真正的达成。
第三是持续优化。所有的OKR活动和敏捷活动都要不断的迭代，不断的优化，所有的活动本身和活动目标都应该为价值工作，拒绝无价值和低价值的瞎忙碌。如果在建立机制的过程中有迷茫，不妨重新打开在制定年度战略ORK时候所设定的5个价值，从心出发，回归初心。
作者：彭鑫（花名公亮），前阿里巴巴高级项目管理专家和技术专家
本文由 @公亮 原创发布于人人都是产品经理，未经许可，禁止转载
题图来自 Unsplash，基于 CC0 协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。