项目目标关键结果教程：项目成员制度设计，避坑指南

去年第四季度，我陪一家做工业设备维保 SaaS 的公司做年度 OKR 复盘。这家公司 68 人，研发加产品大概 40 人，年初老板亲自带队推 OKR，第一版目标文档写得很有气势。到了年底一对账，12 个部门级 KR 里只有 3 个按期完成，剩下 9 个要么中途换了方向，要么根本没人认领。

复盘会上我只问了一个问题：这 9 个没完成的 KR，年初的时候谁能一句话说清楚"它归谁"？会议室安静了将近半分钟，最后是 CTO 打破沉默："好像……大家默认是项目负责人，但项目负责人手上同时挂着四个项目。"

这不是个例。过去四年我以顾问或内部推动者的身份，参与过十几个团队从 8 人到 200 人不等的 OKR 落地，一个反复出现的规律是：团队把 90% 的精力花在"目标怎么写"，却只花 10% 的精力在"谁在什么规则下对什么结果负责"。而后者才是决定成败的那一半。

这篇文章不讲 OKR 的定义，也不给通用模板。我想把"项目成员制度设计"这件事拆开，用我自己的踩坑记录、样本观察和一套可落地的判断逻辑，回答三个问题：制度到底该管什么、角色和规则怎么定、以及哪些坑几乎所有人都会掉进去。

一、先给结论：OKR 落不下去，八成问题出在制度，不在目标

1. 我复盘过的失败项目，问题都出在同一处

我把 2021 年到现在跟踪过的 14 个团队做了分类，分成"OKR 基本跑通"和"OKR 名存实亡"两组。分组之后我发现，两组在目标撰写质量上的差异并不明显，跑通的团队里也有写得含糊的目标，失败的团队里也有写得漂亮的。

真正的差异集中在三个方面：有没有明确到人的 KR 负责人、有没有写下来的变更规则、有没有固定的复盘输出物。换句话说，失败团队缺的不是"目标能力"，而是"制度能力"。

还有一个更反直觉的发现：制度越晚补，成本越高。团队在第一个季度就建立基本规则，后面只需要微调；如果拖到第二个、第三个季度再补，成员已经形成了默认工作方式，重新建立规则会产生明显的抵触，改造周期往往要翻倍。

2. 制度是操作系统，目标只是跑在上面的应用

我常用一个比喻来解释这件事：目标（Objective）和关键结果（Key Result）是应用，成员制度是操作系统。应用写得再漂亮，操作系统没有进程调度、没有权限管理、没有异常处理，应用一跑就崩。

操作系统要解决的是四件事：谁有权限做什么（角色）、什么时候可以改什么（规则）、出问题时怎么处理（纠偏）、做完之后怎么反馈（激励与复盘）。这四件事缺任何一件，OKR 都会退化成一份季度末才想起来填的文档。

我在多个团队看到过同一个场景：季度初大家热情高涨地写目标，季度中没人更新进度，季度末临时补数据应付复盘。表面上是执行力问题，本质上是制度没有规定"更新进度"这件事该由谁、以什么频率、在什么地方完成。

3. 一个反常识的判断：先定"谁负责"，再定"写什么"

绝大多数教程的顺序是"先写目标 → 再分配任务 → 最后谈责任"。我建议把它倒过来：先把人定清楚，再写目标。

原因很简单。目标写得含糊，最多是执行时方向模糊；但如果责任人不明确，含糊的目标会直接变成"没人管"。而一个明确知道自己要对哪个 KR 负责的人，往往会主动把含糊的目标逼清楚，他会去追问"这个数字到底指什么""截止时间到底是哪一天"。

责任分工本身就是一种目标清晰化的机制。这一点在后面第三章会展开讲怎么落地。

先放一组我整理的样本观察数据，用来支撑上面这个判断。需要说明的是，这是我对 14 个团队做的非正式跟踪（2021，2025），样本量小、行业集中在 To B 软件与硬件研发，只能看趋势，不能当行业统计结论。

二、项目成员制度到底管什么：三个问题、九个动作

1. 三个核心问题：谁参与、谁决策、谁负责

很多人一听到"制度设计"，脑子里浮现的是厚厚的管理手册。其实对项目团队来说，成员制度只需要回答三个问题，每个问题再落到三个具体动作上，一共九个动作。

谁参与：哪些人进入目标设定的讨论？哪些人只在执行期被通知？外部协作方（比如设计、测试、运维）算不算项目成员？

谁决策：目标提案由谁发起？对齐冲突时谁拍板？目标需要变更时谁批准？

谁负责：每个 KR 的单一负责人是谁？跨部门 KR 的协同方承担什么义务？没完成时向谁解释？

这三个问题看起来简单，但我在实际项目里见过太多团队从来没有把它们写下来。大家靠"默契"运转，一旦人员变动或者项目数量增加，默契立刻失效。

2. 制度设计必须和 OKR 周期对齐

制度不是静态的，它要跟着 OKR 的三个阶段走：设定期、执行期、复盘期。每个阶段需要的规则完全不同，混在一起谈就会变成一锅粥。

我的经验是：设定期最容易出"目标膨胀"，执行期最容易出"静默失败"，复盘期最容易出"形式主义"。三个阶段的病不一样，药也不能一样。

3. 最容易混淆的边界：制度不等于考核制度

这是我最常纠正的一个误解。团队一说"设计制度"，第一反应往往是"那考核怎么算"。但成员制度的外延远大于考核制度。

考核制度只回答"做得好不好、给多少分"；成员制度还要回答"谁有资格提目标""目标能不能改""改的时候走什么流程""复盘会上谁说最后一句话"。把成员制度等同于考核制度，会导致一个典型后果：所有人都在为分数打工，而不是为目标打工。

我在一家硬件公司见过极端案例：他们的 OKR 制度里，唯一被严格执行的条款是"完成度低于 60% 扣绩效"，其他条款全是摆设。结果是团队成员在季初就倾向于把目标写低，OKR 完全失去了牵引作用。

三、角色设计：把"谁负责"落到人头上

1. 最小可用角色集：四个角色够了

市面上流传的角色体系动辄七八个，我在实际落地中会把它压到四个。角色越多，小团队越容易在两个角色之间互相推诿。

• 目标 Owner：对整个 Objective 的最终结果负责，通常是业务负责人或项目负责人。他的核心动作是对齐和收敛，不是自己动手做。
• KR 负责人：对单个 KR 的达成负责，一个 KR 只能有一个负责人。这是最容易缺失、也最关键的角色。
• 贡献者：承担具体任务，对交付的动作负责，不对 KR 的数字负责。这个区分非常重要，它能避免"人人有责等于人人无责"。
• 复盘主持：负责组织复盘、控制节奏、整理结论。建议不固定由目标 Owner 担任，否则容易变成自我辩护。

如果团队只有五六个人，复盘主持可以轮流，但 KR 负责人不能轮流，那是固定的。

2. 小团队兼岗的三种安全组合

小团队必然要兼岗，问题不在于"能不能兼"，而在于"哪些能兼、哪些不能"。我的判断标准只有一条：如果两个角色之间天然存在监督或制衡关系，就不要由同一人担任。

基于这条标准，我推荐三种安全组合，以及一种明确不建议的组合。

我踩过一次坑：一个 9 人项目里，项目负责人同时兼任目标 Owner 和复盘主持，连续两个季度的复盘结论都是"资源不足、需求变更太频繁"。第三季度换了一位资深工程师主持复盘，当天就暴露出一个关键问题，接口联调环节没有明确的技术负责人，导致每周都在重复返工。

3. 角色设计的三个高频坑

（1）角色过多导致决策链变长。我见过一个 15 人团队设了"目标 Owner、领域 Owner、KR 负责人、执行负责人、质量把关人"五个层级，一个目标变更要走五层确认，平均决策周期从 2 天拉长到 9 天。结果是大家干脆不申请变更，直接闷头做，制度彻底失效。

（2）KR 负责人空缺，用"团队"顶替。只要负责人写的是"研发团队"或者"产品线"，这个 KR 大概率完不成。团队不是责任主体，人才能承担责任。

（3）贡献者被要求为数字负责。贡献者承担的是动作，如果你要求他为最终的 KR 数字负责，他会本能地保守，倾向于选择最稳妥的执行方式，创新性方案直接被扼杀。

四、规则设计：目标设定、变更与冻结

1. 设定阶段的三项权利必须写清楚

设定期最混乱的场景是：所有人都可以提目标，但没人负责收敛。最后目标清单越拉越长，每个都"很重要"，结果一个都做不深。

我建议在制度里明确三项权利。

• 提案权：谁可以发起 Objective 提案。我的做法是开放给所有项目成员，但提案必须附带一页纸的说明，为什么这件事对业务重要、预期影响是什么、需要哪些人配合。
• 对齐权：谁负责把跨部门的目标捏合到一起。通常是目标 Owner，他要主动去找依赖方确认，而不是等对方来找他。
• 拍板权：出现分歧时谁说了算。这一条必须写死到具体角色，不能写"由团队讨论决定"。

我见过最有效的一种做法是设定"收敛截止时间"：季初第 5 个工作日必须锁定目标，锁定后提案窗口关闭。这条规则的价值不在于时间本身，而在于它强制团队在有限时间内做取舍。

2. 执行阶段的变更机制：触发条件比审批流程更重要

大多数团队的变更规则只有一个"审批链"，却没有"触发条件"。结果是成员不知道该不该申请变更，要么什么都不改，要么随意改。

我一般会建议明确四类允许变更的触发条件：外部依赖失效、关键人员变动、业务优先级发生官方调整、以及前期假设被数据推翻。只有这四类情况可以走变更流程，其他一律在复盘期统一讨论。

下面是我在某团队实际使用过的一份制度配置片段，脱敏后贴出来，可以直观看到"规则要怎么写成可执行的形式"。

okr_governance:
cycle: quarterly

roles:

objective_owner: 1 # 每个Objective唯一

kr_owner: 1_per_kr # 每个KR唯一，不允许写"团队"

contributor: n

review_facilitator: rotating # 不可是object_owner

setting_phase:

proposal_window: day_1_to_day_3

alignment_owner: objective_owner

decision_maker: business_lead # 分歧时拍板人

lock_deadline: day_5 # 之后关闭提案窗口

execution_phase:

progress_update: weekly # 每周五17:00前更新

change_triggers: # 仅以下四类可申请变更

external_dependency_failed

key_member_changed

official_priority_shifted

assumption_invalidated_by_data

change_approver: objective_owner

change_limit_per_quarter: 2 # 超过2次需业务负责人复核

review_phase:

facilitator: not_objective_owner

required_outputs:

what_worked

what_blocked

next_cycle_adjustments

3. 冻结与解锁：什么时候允许改，什么时候不允许

变更机制的另一面是冻结。很多团队只讲"要灵活"，结果目标每两周变一次，成员根本不知道该往哪使劲。

我的建议是设置一个"半程冻结点"：季度过半之后，除非出现上面四类触发条件之一，否则不再接受目标调整，所有想改的东西记入"下季度候选池"。这条规则同时解决两个问题，既防止目标漂移，又让好想法不会丢失。

我的经验数据是：一个季度内目标变更 0 到 2 次是健康的，3 到 4 次达成率开始明显下滑，超过 5 次基本可以宣告这个季度的 OKR 失效。

五、激励与复盘：让制度真正形成闭环

1. OKR 与绩效的关联强度，是这个制度里最敏感的旋钮

这个问题几乎每个团队都会问，而且大多数团队会给出两个极端答案：要么完全不挂钩，要么直接按完成度打分发奖金。我的观察是，这两种做法都有明显副作用。

完全不挂钩，OKR 很快会被"更紧急的日常任务"挤掉，因为不做的代价为零。直接强挂钩，成员会系统性地降低目标难度，或者把容易量化的部分拆分出来当作 KR，以换取更高的完成度。

我比较推荐的是一种"弱关联"设计：OKR 结果影响绩效评级的一个维度，但不直接换算成奖金系数；同时，把"目标设定的挑战性"和"过程中的纠偏质量"也纳入评估。这样做的目的是让成员敢于设定有难度的目标，因为他们知道"没完成但有清晰复盘"比"轻松完成一个保守目标"更被认可。

具体比例可以根据团队成熟度调整。我见过效果比较好的配置是：OKR 相关表现占绩效评估权重的 20% 到 30%，其余由岗位职责履行情况、协作评价等构成。

2. 复盘必须产出三样东西，否则就是聊天

我判断一次复盘是否合格，只看它有没有产出三样东西：什么有效、什么被卡住、下个周期要调整什么。没有这三样，复盘就只是情绪交流。

这里有一个容易被忽视的细节："什么被卡住"必须落到具体环节，而不是落到人。"某某配合不及时"是无效结论，"接口联调环节缺少明确的技术负责人"才是有效结论。前者无法执行，后者可以直接变成一条制度补丁。

另外，我建议复盘结论里必须包含至少一条"制度层面的修改"，哪怕很小。比如"下个季度进度更新从每周改为每两周，但增加一次中途风险对齐"。这条规则能让制度保持迭代，而不是写完就冻住。

3. 两个极端：批斗会和走过场

复盘变成批斗会，通常是因为复盘主持由目标 Owner 担任，且绩效强关联。每个人都清楚"说得多错得多"，于是集体沉默。

复盘变成走过场，通常是因为没有输出物要求，也没有下一季度的衔接动作。会议开完，大家各自回到日常工作，什么都不会改变。

这两种极端的修正方式其实是一致的：换一个不在直接利益链上的主持人，同时强制要求产出三条书面结论并进入下一季度的制度或目标。机制比态度可靠得多。

六、一个真实案例：68 人研发团队的制度改造过程

1. 改造前的状态

回到开头那家工业设备维保 SaaS 公司。改造前他们的状态很有代表性：目标由老板和 CTO 在年初闭门写好，然后通过全员会宣布；部门级 KR 分配到各条产品线，但没有指定到人；进度更新靠每月一次例会；绩效与 OKR 完成度直接挂钩，系数 0.8 到 1.2。

结果是三个连锁反应。第一，没有人主动更新进度，因为更新意味着暴露风险。第二，跨部门 KR 全部悬空，谁都觉得对方应该牵头。第三，季末大家都在解释为什么没完成，而不是讨论下季度怎么改。

2. 我们动了哪四处

改造只做了四件事，没有推翻原有体系，也没有引入新概念。

1. 把 12 个部门级 KR 压缩到 7 个，每个 KR 指定唯一负责人，写进文档第一行，不允许出现"团队"字样。
2. 设定半程冻结点，季中第 6 周之后不再接受目标调整，想改的记入候选池。
3. 把绩效与 OKR 完成度的直接换算取消，改为占评级权重 25%，同时加入"目标挑战性"和"纠偏质量"两个评估项。
4. 复盘主持改为轮值，且明确规定不能是当季的目标 Owner；复盘必须产出三条书面结论，其中至少一条是制度修改。

这四条里，最难推行的是第三条。取消直接换算时，业务负责人一度担心"没有考核压力，大家会松懈"。我们做了一个折中：保留季度末的完成度公示，但公示的是"目标 + 完成情况 + 原因说明"三栏，而不只是完成率数字。这样压力来自透明度，而不是来自扣分。

3. 工具层：制度必须有承载物，否则规则会退化成口头约定

这是我想强调的一个容易被忽略的判断：制度设计的最后一步是"落到一个所有人每天都会打开的地方"。如果规则只写在文档里，两周之后就会被遗忘。

这家公司最初的进度跟踪是 Excel 加微信群。Excel 的问题是没有人知道最新版本在哪，微信群的问题是信息被大量日常对话淹没。我们统计过，改造前每周用于"确认当前进度到底是哪个版本"的时间，平均每人 47 分钟。

他们的团队后来从 68 人扩张到 140 多人，跨部门协作的项目从 3 个增加到 9 个，Excel 方案彻底撑不住了，于是开始评估专业平台。在这个阶段他们选的是 PingCode。选择理由主要有三条：一是支持私有化部署，他们的客户里有一部分对数据存放位置有明确要求；二是支持从 Jira 平滑迁移，他们早期部分项目历史数据在 Jira 上，迁移成本是硬约束；三是在国产替代方案里，它的目标与项目联动做得比较完整，不需要再额外拼一个 OKR 工具。

这里有一个诚实的边界说明：PingCode 主要服务中大型企业及 100 人以上组织，如果团队还在 20 人以下，用它其实是过度配置。这家公司真正的迁移节点是在突破百人之后，而不是在 68 人的时候。10 人以下的团队用一张共享表格加上清晰的更新规则，效果往往不比专业平台差。

另外我想强调，工具解决的是"信息在哪"和"状态是否最新"，解决不了"谁负责"。我们是在角色和规则定清楚之后才引入平台的。如果顺序反过来，先上工具再补制度，最后得到的只会是一堆没人维护的空任务。

4. 六个月后的数据

改造从 2024 年第二季度开始，到第四季度末，我们做了前后对比。需要说明的是，这是一家公司内部的对比，样本量为 1，受业务波动影响大，我把它当作案例参考而不是结论。

值得注意的是，达成率从 25% 提到 64%，并不是因为团队变强了，而是因为目标被压缩到 7 个、责任落到人、变更被约束。换句话说，提升来自"制度消除了无效消耗"，而不是"成员更努力了"。

七、避坑清单：项目成员制度设计中最容易犯的七个错误

下面这七条，是我在十几个团队里反复见到的。每一条我都按"错误表现 → 后果 → 修正建议"来写，方便直接对照自查。

1. 目标数量超过团队的消化能力

错误表现：一个 15 人团队设了 6 个 Objective、21 个 KR，每个都标注"高优先级"。

后果：注意力被平均分配，每个目标都推进缓慢，季末全部处于"进行到 60%"的状态，没有一个拿得出手的成果。

修正建议：按团队人数设定上限，我用的经验值是每 5 到 8 人对应 1 个 Objective，KR 总数不超过人数的 1.5 倍。超过就要做强制排序，排不进去的进候选池。

2. KR 负责人空缺或用团队顶替

错误表现：KR 负责人一栏写着"研发团队""产品线"或者干脆空着。

后果：跨部门 KR 全面悬空，出问题时第一反应是找别人，季末复盘时所有人都能证明"不是我的问题"。

修正建议：把"负责人必须是具体的人"写成硬性规则，文档里出现团队名称一律打回重写。这条规则的执行难度比想象中低，效果比想象中大。

3. 制度与激励脱节，或者绑得过死

错误表现：一种是 OKR 完成与否和任何评价都无关；另一种是完成度直接乘进奖金系数。

后果：前者 OKR 被日常任务挤掉，后者成员集体降低目标难度，数据真实性下降。

修正建议：采用弱关联，权重控制在 20% 到 30%，同时把目标挑战性和纠偏质量纳入评估，让"敢定难目标并诚实复盘"获得正反馈。

4. 缺乏变更机制，导致目标僵化或目标漂移

错误表现：要么一条都不许改，要么随时可以改、不需要任何人批准。

后果：前者在外部环境变化时错失调整窗口；后者成员失去方向感，无法做长期投入。

修正建议：明确四类变更触发条件，设置季度变更次数上限，并建立半程冻结点。

5. 复盘形式化，没有可执行输出

错误表现：复盘会上大家轮流说"这个季度比较忙""下季度会注意"，会议结束后没有任何文档产出。

后果：同样的问题连续三个季度重复出现，成员逐渐认为复盘没有价值，参与度继续下降。

修正建议：强制三条输出物，其中至少一条是制度层面的修改，并将结论与下一季度的目标设定直接关联。

6. 照搬大厂制度，忽视团队规模差异

错误表现：20 人团队照抄一套五层角色、季度性全员对齐会、严格评分卡的大型组织制度。

后果：制度执行成本超过收益，成员把大量时间花在流程上，项目推进反而变慢，最后制度被普遍绕过。

修正建议：只保留最小角色集，流程能省则省，先解决"谁负责"和"能不能改"两个问题，其他规则等规模上来再补。

7. 只看结果，不看纠偏过程

错误表现：季度末只公示完成率，不公示过程中的风险暴露和调整动作。

后果：成员倾向于隐藏风险直到无法挽回，早期可修复的问题拖成季末的大窟窿。

修正建议：公示三栏内容，目标、完成情况、原因说明；同时在评估中加入"风险暴露及时性"这一项，鼓励早期暴露。

八、不同规模团队的行动建议

1. 10 人以下：只做两件事

这个规模不适合复杂制度。我的建议是只做两件事：每个 KR 指定唯一负责人；每周固定 20 分钟同步进度，只讲"卡在哪"。

其他规则一律先不写。10 人以下的信息传递靠面对面效率最高，写太多规则反而是负担。这个阶段用一张共享表格完全够用，不需要引入专业平台。

2. 10 至 50 人：补上变更机制和复盘输出

这个规模开始出现"信息不同步"的问题，但还没到需要复杂角色体系的程度。核心是补两件事：明确四类变更触发条件；复盘必须产出三条书面结论。

角色上，保留目标 Owner 和 KR 负责人两个角色，复盘主持可以轮值。跨部门协作超过三个项目时，建议开始用一个集中化的项目管理平台，避免信息散落在多个渠道。

3. 50 至 200 人：制度要成文，工具要统一

这个阶段是我观察到的"制度断层区"。团队规模上来了，但很多人还在用 20 人时的方法管理，结果是目标层层传递失真、进度靠人工汇总、复盘流于形式。

核心动作有三个：把制度写成文档并全员可见；引入统一的项目管理平台承载进度和变更记录；建立季度性的目标对齐机制，让跨部门依赖被显式确认而不是靠默契。

这个规模区间也是专业平台价值开始凸显的节点。如果团队有数据存放位置要求，或者历史数据在 Jira 上、迁移成本是硬约束，私有化部署加平滑迁移这两项能力就变得关键。

4. 200 人以上：制度分层，但保持单一数据源

这个规模需要分层的目标体系，但我要强调一点：目标可以分层，进度数据源不能分层。一旦出现两套并行的进度系统，对齐就变成了人工对账，成本会急剧上升。

另外，200 人以上要特别注意"制度执行的最后一公里"。我见过不少大团队制度写得很完整，但一线成员根本不知道有这些规则。解决办法不是再培训一次，而是把规则嵌入到日常工具的流程里，让人在执行时自然遵守。

九、不同情况下的取舍：没有最优解，只有适配

1. 强考核还是弱考核

选强考核的情形：团队执行力差是主要矛盾，且成员普遍偏保守、不愿意主动承担目标。这种情况下适度提高关联强度能快速建立紧迫感。

选弱考核的情形：团队需要探索性目标，或者当前阶段更需要跨部门协作。此时强考核会诱导成员守住自己的数字、拒绝协同。

我的取舍标准：如果这个季度公司的主要矛盾是"确定的事情没做扎实"，可以偏强；如果矛盾是"不知道该做什么"，必须偏弱。这个判断每个季度都可能变。

2. 高频复盘还是低频

选高频（每两周一次，20 分钟）的情形：项目外部依赖多、变化快，风险暴露越早价值越大。

选低频（每月一次，60 分钟）的情形：工作性质偏长周期研发，两周内很难产生有意义的进展，高频复盘容易变成互相汇报"还在做"。

我的取舍标准：看"最小可观察的进展周期"。如果一件事两周内没有任何可观察变化，高频复盘就是浪费；如果能，就该高频。

3. 自建工具还是采购平台

选自建的情形：团队规模小、流程特殊性强，且已有工程能力可以低成本维护。

选采购的情形：团队规模超过 50 人、跨部门协作多、需要审计痕迹和权限体系，或者对数据存放位置有合规要求。

我的取舍标准：自建的真实成本不是开发，而是后续维护和人员流动后的接手成本。如果团队一年内可能翻倍，自建方案基本会在半年后变成技术债。这也是那家案例公司在规模扩张后转向 PingCode 这类平台的原因，不是为了功能更多，而是为了少维护一套自己造的轮子。

4. 全面推行还是试点先行

选试点的情形：组织对 OKR 陌生、历史上推过失败过、或者存在明显的抵触情绪。

选全面推行的情形：公司处于快速变化期，需要全员方向对齐，且管理层能投入足够时间参与对齐。

我的取舍标准：试点的价值在于验证制度细节，不在于验证"OKR 有没有用"。所以试点团队要选业务节奏正常、人员相对稳定的团队，不要选最难的团队去试。我最常见到的错误是拿最乱的一个部门做试点，结果失败之后被归因为"OKR 不适合我们"，其实是样本选错了。

结语：制度的价值不是约束人，而是让目标可被承接

回到最开始那个问题：为什么 OKR 教程看了很多，落地还是乱。我的答案始终没变，目标本身不产生执行力，制度和角色才产生执行力。

如果你只从这篇文章带走一个观点，我希望是这句：先把"谁对哪个 KR 负责"写清楚，再去讨论目标怎么写。这个顺序反过来，后面所有的努力都会打折。

如果你只带走一个动作，我建议做这件事：打开你当前季度的目标文档，逐条检查每个 KR 的负责人栏，凡是写着团队名称、写着两个人、或者空着的，今天就全部改成具体的一个名字。这个动作大概需要 15 分钟，但它能暴露出你当前制度里最大的那个洞。

至于更深层的制度设计，变更规则、复盘输出、激励关联强度，可以按这篇文章的章节顺序，一个季度补一块。制度不是一次写完的，它和你跟踪的项目一样，需要版本迭代。

最后提醒一句判断边界：本文涉及的样本观察来自我跟踪的十余个团队，集中在 To B 软件与硬件研发领域，规模从 8 人到 200 余人。如果你所在的是销售驱动型团队或者强流程型的制造现场团队，角色和规则的权重分配需要重新调整，不要直接照搬。