关键结果怎么做？PMO协同管理：项目目标从0到1

去年年底，我参加一家工业设备企业的年度目标评审会。会议室白板上贴了23条所谓的关键结果，我逐条读完，发现其中17条的开头动词是"完成""推进""建立""上线""组织"。其中一条写着"完成客户成功体系的搭建"。我问负责人：年底如果客户续约率还是31%，但这套体系上线了，这条KR算不算达成？他愣了大概五秒，说"那应该也算吧"。这五秒就是问题所在。

那场会之后我们花了三周重做KR，最终从23条压缩到9条，删掉的不是工作量，而是那些无论业务好坏都能"完成"的动作。三个月后再看，这9条里有7条能拿出独立的第三方数据来验证，另外2条因为数据源没建起来，主动做了降级处理。

这件事让我确认了一个判断：项目目标从0到1，真正难的不是写出漂亮的OKR表格，而是把一句模糊的方向，翻译成一群人可以各自负责、互相看得懂、月底能对账的关键结果。PMO在这个过程里的角色，也不是催进度，而是当那个负责"翻译"和"编排"的人。

一、先把结论说清楚：KR是证据，不是动作清单

1. KR的判定标准只有一条：能不能被独立验证

我给KR只设一条底线标准：换一个不了解项目的人，拿着约定的数据源，能不能独立算出这条KR是否达成。如果能，它是KR；如果不能，它是任务、是里程碑、是愿望，都不是关键结果。

"完成调研"不能被独立验证，因为调研报告写三页还是三十页、访谈五个人还是五十个人，都可以叫"完成"。"核心场景用户访谈覆盖率达到80%"可以被验证，因为它有分母、有分子、有统计口径。

这条标准听起来简单，但我在实际评审里发现，它筛掉的KR比例高得惊人。多数团队的初稿里，能通过这条测试的往往不到四成。

2. 三个不等式：目标≠KR，KR≠任务，PMO≠催办

第一个不等式，目标不等于KR。目标是方向，回答"我们要去哪里、为什么去"；KR是证据，回答"怎么证明我们真的到了"。目标可以带情绪、带愿景，KR必须带数字或可判定的状态。

第二个不等式，KR不等于任务。任务是"我们打算做什么"，KR是"做完之后世界里发生了什么变化"。任务的数量是开放的，KR的数量必须收敛，一个目标配三到五条就够，超过五条基本说明目标本身没想清楚。

第三个不等式，PMO不等于催办。催办的逻辑是"你答应的事为什么没做"，编排的逻辑是"这件事卡住是因为依赖没暴露、口径没统一、还是资源没到位"。前者解决时间问题，后者解决结构问题。

这三个不等式不是文字游戏。我在复盘会上见过太多次，团队讨论了两小时KR为什么没达成，最后发现大家吵的其实是任务进度，而真正该看的业务结果指标从头到尾没被打开过。

3. PMO在0到1阶段真正该做的四件事

0到1阶段，PMO的职能和成熟期完全不同。成熟期PMO更多在做流程标准化、资源池管理、组合治理；0到1阶段，我认为核心只有四件事。

1. 目标翻译。把管理层嘴里的战略意图，翻译成业务能认领、数据能验证的KR草案。
2. 协同编排。找出跨部门依赖，把"我以为你会做"变成"我们约定了谁在什么时候交付什么"。
3. 节奏运营。设计看板、复盘、变更的节奏，并且保证节奏能跑起来，而不是设计完就挂在墙上。
4. 复盘教练。在复盘时追问假设是否成立，而不是追问谁该负责。

这四件事有个共同点：它们都不产生直接的业务产出，但缺了它们，业务产出会以另一种方式被浪费掉，重复对齐、反复返工、年底发现方向跑偏。

二、真实场景：为什么0到1阶段的目标最容易走形

1. 我在三类组织里看到的差异

过去几年我参与过三类组织从0到1搭目标体系：一类是200人左右的硬件公司，一类是300人以上的SaaS公司，还有一类是集团下属的新业务单元。它们的失控方式完全不同。

200人硬件公司的典型问题是"人少事多"，一个人同时背三条业务线的目标，KR写得再漂亮也执行不过来，最后所有KR都变成"推进中"。这类组织的核心矛盾是资源密度，不是方法论。

300人以上SaaS公司的问题是"部门墙"。每个部门都能把自己的KR写得很完整，但合在一起看，市场部的KR和产品部的KR之间存在三个月的时序错位，市场要的线索量，产品根本还没做出来。

集团新业务单元的问题是"授权不清"。PMO想推动跨部门协同，但没有考核权、没有预算权，业务部门配合与否全凭人情。这类组织里，PMO最该做的其实是先把升级机制和决策授权写清楚。

把这三类放在一起看，会发现一个共同点：0到1阶段的失败很少是"KR写得不好"，更多是"目标体系没有匹配组织当前的约束条件"。

2. 一个具体的失控过程

我以300人SaaS公司那次为例，复盘整个过程，它走了六个阶段，每个阶段当时看起来都合理。

1. 管理层定了年度目标：把续约率从68%提到80%。方向没问题。
2. 各部门各自拆KR。产品部写"完成三个核心功能升级"，客户成功部写"完成客户健康分体系搭建"，销售部写"新签50家"。三条都是任务型表达。
3. PMO开始每周收进度。收上来的都是"完成度70%""按计划推进"，因为任务型KR本来就只能这么汇报。
4. 第三个月发现产品功能延迟，客户成功部的健康分体系依赖产品数据，但两边从没对齐过接口人和交付时间。
5. 第五个月开始救火，临时拉群、临时加会，PMO变成专职协调员，每天处理跨部门扯皮。
6. 年底续约率71%，比年初涨了3个点。复盘时所有人都很疲惫，但没人能说清是哪条KR真正起了作用。

这个过程里，最大的损失不是没达成80%，而是花了12个月，却没有积累下任何一条"哪个动作导致了哪个结果"的可复用证据。第二年还要从零开始摸。

3. 0到1阶段的四个典型信号

我现在判断一个组织的目标体系是否走形，主要看四个信号，它们出现两个以上，基本可以确认需要重做而不是微调。

• 信号一：KR的动词都是"完成""推进""建立"。说明团队在用任务语言描述结果。
• 信号二：周报里出现大量百分比完成度，但没有一条能对应到业务指标。说明数据源和KR没有绑定。
• 信号三：跨部门问题几乎都在月会上才第一次被提出。说明依赖关系没有被系统化记录。
• 信号四：复盘会上讨论的是"谁没做好"，不是"我们的假设哪里错了"。说明复盘机制已经退化成追责机制。

这四个信号的价值在于，它们都能在目标周期中途被观察到，而不需要等到年底。发现得越早，返工成本越低。

4. 为什么0到1阶段不能直接套用成熟组织的模板

很多团队会直接找一套大厂的OKR模板来用，结果往往水土不服。原因不复杂：成熟组织的模板建立在三个前提上，而0到1阶段这三个前提通常都不成立。

前提一是战略稳定。成熟公司年度战略基本可预期，KR可以在年初定好后微调。0到1阶段，业务方向可能三个月就要调整一次，KR的变更频率天然更高。

前提二是数据可得。成熟公司有埋点、有数据仓库、有相对规范的指标口径。0到1阶段经常连一个可信的活跃用户定义都没有，这时候强行量化只会制造假数据。

前提三是角色清晰。成熟组织里谁负责什么基本稳定。0到1阶段经常一个人身兼多职，KR的负责人这件事本身就很难划定。

我的判断是：0到1阶段的目标体系，应该设计成"低成本可迭代"的版本，而不是"完整规范"的版本。宁可少几条KR，也要保证每条都能被验证、都能找到负责人。

三、拆解五个高频误区

1. 误区一：把KR写成任务清单

这是最普遍也最顽固的问题。中心化的表现是，KR里出现"完成""上线""组织""推进""建立""梳理"这类动词。这些动词描述的是一次动作的结束，而不是一个结果的出现。

为什么团队会反复犯这个错？因为任务是可以被控制的，结果不能。写"上线系统"是可控的，写"系统上线后关键流程处理时长从4小时降到40分钟"就要面对真实效果，心理压力完全不同。

我的处理办法是做一个简单的动词替换练习：把每条KR里的动词圈出来，如果它是完成任务类动词，就追问一句"完成之后，什么数字或状态会发生变化"。这个追问通常能把任务型KR拽回到结果附近。

2. 误区二：把PMO当成催办中心

PMO一旦被定位成催办，就会陷入一个死循环：越催越没人主动汇报，越没人主动汇报就越要催。团队把PMO当成监管者，就会本能地隐藏问题，等到问题藏不住了才抛出来。

我见过一个PMO负责人，她的日程表上每天有六个进度跟踪会，但她自己说"我不知道项目真实的健康度"。这不是她的能力问题，是定位问题。她的时间被消耗在收集状态上，没有余量去分析依赖和风险。

更有效的定位是让状态数据自动流动、把PMO的时间解放出来做结构性问题。这正好是协同平台能发挥作用的地方，后面会展开讲。

3. 误区三：一开始就追求全公司统一模板

0到1阶段最容易被"统一"这个词绑架。PMO花两个月设计了一套覆盖全公司的KR模板，要求所有人按格式填。结果是一线觉得表单太重，填出来的东西只是为了交差，数据质量反而更差。

更务实的路径是先在1到2个有动力、有基础的团队跑通最小闭环，把模板跑薄、跑顺，再向外复制。统一不是起点，是结果。先有愿意用的人，才有值得统一的模板。

4. 误区四：OKR直接当绩效打分表

这个误区会导致一个非常具体的行为变化：团队开始写保守的KR。因为如果KR直接关联奖金和评级，理性选择就是定一个闭眼能达成的数。目标体系本来是为了拉伸，结果变成了保险。

我不主张用一句"OKR不能绑绩效"来一刀切。更准确的说法是：目标的设定质量和达成的过程贡献，可以进入评价；单一的达成率数字，不适合直接当评级依据。尤其0到1阶段，目标本身经常需要调整，用一个会变的标尺去打分是不公平的。

5. 误区五：只对齐上下，不对齐左右

多数团队的对齐动作是垂直的：公司目标拆到部门，部门拆到个人。但项目目标从0到1的过程中，最大的风险往往来自水平方向，两个平级部门对同一件事的理解不一致。

举个我在SaaS公司看到的例子：产品部的KR是"核心功能覆盖率达到85%"，市场部的KR是"功能发布后30天内线索量提升20%"。两条单独看都没问题，但产品部的覆盖率是按功能数量算的，市场部关心的是三个主打功能，两者之间没有任何约定。

结果是产品部为了覆盖率去做了二十个小功能，市场部等的是那三个主打功能，两条KR在时序上完全错位。水平对齐的缺失，会让垂直对齐看起来很完整的目标体系在实际执行中互相打架。

四、专业判断：一个合格KR的判断链路

1. KR四要素公式

我通常在0到1阶段给团队一个足够简单的结构，不追求完备，追求能落地。这个结构包含四个要素：基线、目标值、时间窗口、验证口径。

KR = 从【基线值】到【目标值】
时间窗口：【起始日 ~ 截止日】

验证口径：【数据源 + 计算方式 + 复核责任人】

责任归属：【唯一负责人 + 协同方 + 依赖方】

示例（虚构示例，仅用于说明结构）

KR-01: 核心流程平均处理时长

基线值: 4.2 小时（2024 Q4 实测）

目标值: 1.5 小时

时间窗口: 2025-01-01 ~ 2025-06-30

验证口径: 工单系统 export + 中位数计算 / 数据组复核

责任归属: 负责人=流程Owner / 协同=客服中心 / 依赖=系统权限改造

很多人会跳过基线这一项，直接写目标值。但没有基线的KR，本质上无法判断幅度是否合理。从4.2小时降到1.5小时和从1.8小时降到1.5小时，是完全不同的难度。

2. 从基线到目标值的推导

目标值不能靠拍脑袋。我一般要求写出推导过程，哪怕只是一句话。推导的意义不在于精确，而在于暴露假设。

比如"把客户续约率从68%提到80%"，可以拆成三个假设：产品稳定性提升能减少多少流失、客户成功主动干预能挽回多少、新签客户质量提升能带来多少改善。三个假设分开估算，加起来看是否接近80%。如果加起来只有73%，那就要重新讨论目标是否合理。

这个过程的价值在于，它把一个大目标拆成了几个可以被单独验证的赌注。每个赌注对应一条KR，年底复盘时可以分别检验哪个假设成立、哪个不成立。

3. 领先指标与滞后指标的选择

0到1阶段最容易出现的偏差是只盯滞后指标。滞后指标是结果本身，比如续约率、收入、活跃度。它们的问题是没有前瞻性，等你看到它没动，往往已经来不及干预。

领先指标是那些能预示结果变化的先行信号，比如核心流程的使用频次、关键岗位的周活跃、客户健康分的分布变化。它们的价值是可以周度观察，让团队有机会在结果发生前调整。

我的建议是每个O下面至少有一条领先指标型KR，一到两条滞后指标型KR。全部用滞后指标，团队会在季度末才发现问题；全部用领先指标，又容易偏离最终业务结果。

4. KR评审的七个问题

我在KR工作坊里会让团队互相提问，七个问题问完，不合格的KR基本会自动浮现。

1. 这条KR描述的是结果，还是我们打算做的动作？
2. 它的基线是什么？没有基线的话，为什么可以省掉？
3. 数据从哪里来？现在拿得到，还是需要先建数据源？
4. 谁对这条KR的最终达成负责？是唯一负责人吗？
5. 达成或未达成，能否用一个外部人也认可的方式判定？
6. 它对上游有什么依赖？依赖方知道这件事吗？
7. 多长时间复盘一次？复盘时会看哪个数据？

这七个问题看起来朴素，但我在三家企业的工作坊里统计过，初稿KR能一次性通过全部七问的比例不到三成。大部分问题集中出现在第2、3、6问上。

5. 质性KR的边界条件

有些目标确实难以量化，比如"建立跨部门协作机制""完成组织能力升级"。我不主张强行给这类目标编数字，但也不能让它们变成无法验证的空话。

处理方式是给质性KR配一个"可判定的证据清单"。比如"建立跨部门协作机制"可以配三个证据：机制文档已发布并被三个以上部门确认、月度协同会连续三个月按期召开、争议解决平均耗时从X天降到Y天。前两条是事实判定，第三条是量化补充。

质性KR不是免检通道，它只是把验证方式从数字换成了可核查的事实。只要能被核查，它就有存在价值。

五、案例与数据观察：协同机制怎么落到平台上

1. 为什么协同机制需要载体

前面说的依赖识别、节奏运营、变更留痕，如果全靠会议和文档，会随着项目数量增加迅速失效。原因是会议的容量是线性的，而依赖关系是网状增长的。

项目从1个变成5个，跨部门依赖可能从8条变成40条以上。这时候靠周会口头同步，必然出现"我以为你知道"的信息断层。我见过一个团队用共享表格管理依赖，用到第三个月表格已经有七个版本，没人说得清哪个是最新的。

所以协同机制必须要有一个承载平台。平台的价值不是替代管理，而是让依赖关系、变更历史、指标数据有一个唯一可信的来源。

2. PingCode在目标到执行链路上的承载方式

在服务中大型企业、尤其是100人以上组织时，我看到比较典型的一类做法是，把目标层的KR、执行层的需求与任务、以及依赖关系放在同一个平台里贯穿起来。PingCode在这类场景里被不少团队用来做这件事，它的定位是覆盖研发管理与项目协同的一体化平台，主要服务中大型企业及100人以上的组织。

具体到0到1阶段的项目目标管理，我观察到几个比较关键的承载点。

（1）目标与工作项的关联。KR不是一个孤立的卡片，它可以关联到具体的需求、任务、缺陷。这样在复盘时，可以从KR直接下钻到"为了实现它，我们实际做了哪些工作"，而不是靠回忆。

（2）依赖关系的显性化。跨部门依赖可以在平台上被记录为明确的关联关系，包括依赖方、被依赖方、约定交付时间。这比在文档里写一段文字要刚性得多，因为它会在计划层面直接体现。

（3）变更留痕。KR目标值调整、交付时间变更都会留下记录。这一点在0到1阶段特别重要，因为目标调整是常态，而留痕才能让复盘时看清"我们是在修正方向，还是在给延期找理由"。

（4）私有化部署与迁移能力。对于数据敏感的中大型企业，私有化部署往往是硬性要求。同时，很多团队原来在用Jira，如果迁移成本过高，平台切换本身就会变成一个额外的项目。PingCode支持Jira平滑迁移，这对已经有一定历史数据的团队来说，是降低切换阻力的实际因素。从国产替代的角度看，这也是它被不少团队纳入考虑的原因。

3. 从Jira迁移到PingCode的一次观察

我参与过一次规模在400人左右的研发组织做工具迁移的观察，他们的诉求很明确：原来的工具在研发侧够用，但目标管理和跨部门协同一直靠外部表格补充，两边数据对不上。

迁移过程中的三个实际观察值得记录。

第一，历史数据的处理比预想的复杂。不是技术问题，而是口径问题，原来的字段定义和历史项目的分类方式需要先统一，否则迁过去只是把混乱换个地方。

第二，团队的抗拒主要来自习惯，不来自功能。工程师习惯了旧的快捷键和视图，切换初期效率会下降一到两周，这需要提前管理预期。

第三，真正的收益在迁移后第二个月才显现。当他们把KR和研发任务真正关联起来之后，月度复盘第一次做到了"每个KR都能下钻到具体工作项"，这在此前是没有的。

4. 一组模拟的落地数据对比

需要提前说明，下面这组数据是我基于几个项目观察整理的示意性对比，不是严格的对照实验结果。它的用途是说明平台承载前后，协同类指标的典型变化方向，而不是给出精确基准。

承载前，跨部门依赖主要靠周会同步和文档记录，依赖识别往往是"问题爆发了才发现"。承载后，依赖被前置记录在计划里，识别时间点明显提前。同时，周报的人工整理时间下降，因为状态数据可以从平台上直接获取。

更重要的变化是变更留痕。在0到1阶段，目标调整本身不是问题，问题是没有记录，导致复盘时无法判断调整是否合理。这一点在平台承载后有比较明显的改善。

5. 工具解决不了的三件事

写到这里必须说清楚边界。平台能承载依赖、留痕、数据，但有三件事它解决不了，而这三件事恰好是0到1阶段最关键的。

第一，目标本身的合理性。平台不会告诉你"续约率从68%提到80%"是否过于激进。这需要业务判断。

第二，负责人是否真的认领。平台上指派了一个负责人，和这个人真的愿意为结果负责，是两回事。这需要沟通和管理动作。

第三，复盘时的诚实。数据在平台上，但复盘时是讨论假设还是互相甩锅，取决于团队文化，取决于主持人怎么提问。

工具能让机制变得可执行，但不能替团队做决策、建信任、改文化。把工具当解药，最后会得到一套漂亮的系统和一个依旧低效的组织。

六、不同情况下，PMO具体该怎么做

1. 组织成熟度低：先做三件事

如果团队此前没有目标管理体系，或者上次尝试失败了，我不建议一上来就搞全套。先做三件事，做完再判断要不要继续。

1. 统一语言。用一次两小时的会，把目标、KR、任务、里程碑、交付物这五个词的定义讲清楚，并且当场用团队自己的例子改写一遍。这一步不产出任何文档，但省掉后面大量沟通成本。
2. 选一个可控的项目跑闭环。不要选最难的项目，选一个有明确负责人、周期在8到12周、数据相对好获取的项目。
3. 建立一条数据链路。哪怕只有一条KR，也要把它的数据源、计算方式、更新频率定下来，让团队体验到"数据可以自己说话"。

这三件事做完，一般需要4到6周。如果团队在这之后仍然没有动力，说明问题不在方法，而在授权或激励，需要往上找原因。

2. 组织成熟度中等：从单项目闭环切入

如果团队已经用过OKR但没有沉淀下来，问题通常出在复盘和变更管理上。这时候建议从单项目的闭环切入，重点补两块。

一是补齐基线和验证口径。把现有KR逐条过一遍，凡是说不出数据来源的，要么补建数据源，要么降级为任务。

二是建立变更规则。明确什么情况下可以调整KR、谁有权批准、调整需要留什么记录。这个规则越简单越好，我一般建议只有一条：任何KR的目标值调整，必须同时写下调整原因和影响判断。

3. 多项目并行：目标地图与依赖管理

当PMO同时协调5个以上项目时，单点沟通会迅速失效，必须换工具和方法。

我推荐的做法是先画一张目标地图，把所有项目的O和KR放在同一张图上，用连线标出项目之间的依赖。这张图不需要精美，它的价值在于让冲突可见。

然后是依赖管理。每条跨项目依赖都要有四个要素：交付方、接收方、约定时间、验收标准。四个要素缺一个，这条依赖就是模糊的。用平台承载时，这些要素应该成为结构化字段，而不是文档里的一段描述。

4. 已有体系但流于形式：做减法

这是最常见也最棘手的情况。团队有完整的流程、模板、会议，但所有人都知道它没在真正起作用。这时候加方法、加工具都没用，必须做减法。

我的建议是砍掉三类东西：砍掉没人看的报表、砍掉只做状态同步的会议、砍掉无法验证的KR。砍完之后，剩下的东西数量会少很多，但每一样都能真正被用起来。

七、不同情况下的取舍：没有全都要

1. 覆盖度与完成度的取舍

0到1阶段最容易犯的错是追求全覆盖。所有部门都要有KR，所有KR都要有数据，结果是每条都做到及格，没有一条做到优秀。

我的建议是把覆盖度降到能管得住的水平。一个0到1项目，真正需要被严格跟踪的KR可能只有5到8条，其余可以作为观察项存在，不进入正式复盘。

这个取舍的代价是部分工作没有进入目标体系，可能被忽视。收益是核心KR能得到足够的注意力。在资源有限的阶段，我倾向于选收益。

2. 统一模板与局部自治的取舍

统一模板的收益是数据可汇总、口径可比对；代价是灵活性下降，部分团队被迫填写与自身业务不匹配的字段。

我一般建议做"半统一"：统一的是必填字段（KR描述、基线、目标值、负责人、验证口径），不统一的是呈现形式和辅助字段。这样既保证了横向可比，又给团队留了空间。

3. 量化与质性的取舍

全量化看起来很专业，但在0到1阶段会产生大量假数据。因为数据源还没建起来的时候，强行量化只能靠估算，估算的数据用来做决策比没有数据更危险。

我的处理原则是：能量化的量化，不能量化的用可核查事实替代，不能核查的就不写进KR。三条路径的优先级是明确的，不允许出现"先写个数字以后再说"的情况。

4. 机制先行与工具先行的取舍

这个问题我在不同团队看到过完全相反的答案，但我的判断是清楚的：机制先行，工具跟进，中间间隔不超过一个季度。

只做机制不做工具，机制会在项目数量增加后失效。只上工具不做机制，会把混乱自动化，产出更多没人看的数据。两者的顺序不能颠倒，间隔也不能太长，否则机制会因为缺乏承载而自然衰减。

5. 升级机制的代价

升级机制指的是当跨部门冲突无法在PMO层面解决时，如何上升到更高决策层。这个机制必须有，但它的使用是有代价的。

代价是关系成本。频繁升级会让中层觉得被绕过，长期可能导致更严重的协作壁垒。所以升级机制要配一个明确的使用门槛：什么类型的冲突可以升级、升级前需要准备什么材料、升级后由谁在多久内给结论。

升级机制的价值不在于经常用，而在于它存在，让所有人知道僵局不会无限期持续。

八、总结：把目标变成共同承诺

1. 三条可以带走的判断

第一，KR是证据，不是动作清单。判断标准只有一条：换一个不了解项目的人，能不能用约定的数据源独立验证。做不到这一条，就不是KR。

第二，PMO在0到1阶段的角色是翻译者和编排者，不是催办员。把时间从收集状态转向设计机制、暴露依赖、主持复盘，才是真正产生杠杆的地方。

第三，0到1阶段要的是低成本可迭代的目标体系，不是完整规范的模板。先在一个项目上跑通最小闭环，让机制被验证，再向外复制。

2. 下一步的七个动作

如果你正准备在团队里推动这件事，我建议按这个顺序走，每一步都能独立产出结果。

1. 用一页纸把当前项目的O和KR写出来，不要超过一页，写不下说明目标没收敛。
2. 逐条检查动词，把所有"完成""推进""建立"换成结果描述。
3. 为每条KR补上基线、数据源和验证口径，补不上的标记出来，暂时降级。
4. 找出跨部门依赖，列出交付方、接收方、时间、验收标准四个要素。
5. 确定复盘节奏，0到1阶段我建议双周一次，季度做一次大的方向检验。
6. 选择一个合适的平台把目标、任务、依赖、变更承载起来，优先考虑能否私有化部署、能否从现有工具平滑迁移，避免切换本身变成新负担。
7. 跑完一个完整周期后做一次复盘，重点问"哪个假设成立、哪个不成立"，而不是"谁没做好"。

这七步做完，大概需要8到12周。如果只能记住一句话，我建议记住这条：项目目标从0到1，真正的产物不是一张OKR表，而是一群人愿意共同为其负责的、可以被验证的承诺。表格会过期，承诺会留下来。