协作工具推广常见的卡点是：方案已经定了，但谁在什么时候交出什么、由谁验收说不清楚，进度只能靠追问。本文给出一套可执行的方法：把推广拆成准备、试点、全员上线、稳定运营四个阶段，用一张推广责任表写清动作、负责人、交付物、完成标志和验收人，再配套可检查的使用规则与固定复盘节奏。文中的责任表、规则清单和试点示例可直接改写使用，ONES 在责任分工与交付物跟踪环节可作为承载工具。
要点总览（TL;DR）
- 把推广拆成准备、试点、全员上线、稳定运营四个阶段，每阶段先定义可验收的交付物和完成标志，责任才有落点。
- 责任表固定八个字段：阶段、动作、负责人、协作方、交付物、完成标志、验收人、截止时间；坚持单一负责人和验收人分离。
- 使用规则按“场景—动作—时限—责任人—检查方式”五段写，首轮控制在10条以内，并明确谁抽查、抽查多少、结果记在哪。
- 推广后按周抽查、月度汇总、季度复盘固定节奏运行，检查结果进入责任表更新版本，避免责任表停留在文档层面。
- 启动前用完成检查清单逐项自查，优先补正负责人缺失和完成标志缺失两类问题。
先定推广阶段和每阶段的交付物
责任划分的前提是先把推广拆成有明确终点的阶段。阶段不清，责任就只能写成“负责推广”这类无法验收的表述。建议按准备、试点、全员上线、稳定运营四段推进，每段设定一个可判断是否结束的目标，并规定必须产出的交付物。
准备阶段的目标是让方案具备启动条件，交付物包括推广方案（含范围、时间表、成功标准）、角色与责任表、工具基础配置清单、使用规则初稿、培训材料。试点阶段的目标是在小范围验证规则与流程是否可行，交付物包括试点名单、试点培训记录、试点问题清单、试点结论报告。全员上线阶段的目标是让目标人群完成迁移并开始按规则工作，交付物包括上线通知与培训记录、账号与权限开通清单、上线检查表、首批规则执行情况记录。稳定运营阶段的目标是让使用习惯固化，交付物包括月度使用情况报告、复盘会议纪要、规则与责任表的更新版本。
完成标志要写成可观察的状态，避免“已完成”“基本到位”这类模糊表述。写法上包含三个要素：产出物存在且可查阅、关键内容通过验收人确认、满足一项可核对的量化或事实条件。例如“使用规则初稿”的完成标志可写为：规则覆盖任务登记、文档归档、状态更新、评审记录、通知习惯五类对象，每条含场景、动作、时限、责任人、检查方式，经部门负责人确认后发布在团队知识库。“上线检查表”的完成标志可写为：目标人员账号开通率100%，完成培训签到，抽查10名成员能独立完成一次任务登记与状态更新。
| 阶段 | 阶段目标 | 主要交付物 | 完成标志示例 |
|---|---|---|---|
| 准备 | 方案具备启动条件 | 推广方案、责任表、配置清单、使用规则初稿、培训材料 | 方案含范围、时间表、成功标准；规则初稿经负责人确认并发布 |
| 试点 | 验证规则与流程可行 | 试点名单、培训记录、问题清单、试点结论报告 | 试点成员按规则运行满一个周期；问题清单逐条有处理结论 |
| 全员上线 | 目标人群完成迁移并按规则工作 | 上线通知与培训记录、账号权限清单、上线检查表、规则执行记录 | 账号开通率达标；抽查成员能独立完成核心操作 |
| 稳定运营 | 使用习惯固化 | 月度使用报告、复盘纪要、规则与责任表更新版 | 检查按节奏执行；复盘输出改进项并落实到责任人 |
责任表怎么填：角色、负责人与验收人
责任表的作用是让每一项交付物都能追到一个人。字段建议固定为：阶段、动作、负责人、协作方、交付物、完成标志、验收人、截止时间。字段固定后，填写过程本身就是一次责任对齐，空缺项会直接暴露分工盲区。
填写时坚持两条原则。一是单一负责人：每项交付物只写一个负责人姓名，协作方可以多人，但进度和结果由负责人承担，避免“共同负责”变成无人负责。二是验收人与负责人分离：验收人负责判断完成标志是否达成，通常由发起人或部门负责人担任；负责人自己验收自己的产出，等于没有验收。
角色边界可以按四类划分。发起人通常是推广的决策者，负责批准推广方案、确定范围与时间表、裁决跨部门争议、在关键节点听取汇报。工具管理员负责账号与权限开通、基础配置、培训组织与答疑、使用数据导出，对配置类交付物负责。部门负责人负责本部门人员名单确认、规则在本部门的落地、指派本部门规则执行检查，并对本部门上线检查结果负责。一线使用者按规则完成日常任务登记、文档归档、状态更新，是使用规则的执行主体，其遵守情况由部门负责人检查。
跨部门争议常见于两类情形：一是同一交付物被两个部门同时认领或同时推诿，二是规则要求与某部门现有流程冲突。升级路径写进责任表附注：负责人之间协商不成，由发起人在约定时限内裁决；涉及流程调整的，提交推广例会讨论并记录结论。升级路径要写明触发条件和时限，否则争议会停在“已反馈”状态。
| 字段 | 填写要求 | 常见错误 |
|---|---|---|
| 阶段 | 对应四个阶段之一 | 阶段混用，同一行跨两个阶段 |
| 动作 | 动词开头，指向一个可完成的事 | 写成“推进推广”这类无法判断完成 |
| 负责人 | 唯一姓名 | 写部门名或“相关同事” |
| 协作方 | 列出需要配合的角色 | 把协作方写成第二负责人 |
| 交付物 | 可查阅的具体产出 | 只写“完成培训”不写记录在哪 |
| 完成标志 | 可核对的事实或量化条件 | 写“质量达标”无判断依据 |
| 验收人 | 与负责人不同的人 | 负责人自验 |
| 截止时间 | 具体日期 | 写“上线前”等相对时间 |
责任表本身需要被持续查看，放在个人电脑里就失去作用。若团队使用 ONES，可把每项交付物建成工作项，负责人、验收人、截止时间作为属性记录，交付文档通过 ONES Wiki 与任务关联，验收结论和状态更新留在同一处，检查时按阶段筛选即可看到哪些交付物未完成。ONES Project 支持将需求和相关任务分配负责人，并提供看板查看进度，适合承载这类按阶段推进的推广任务。
把交付要求写成可检查的使用规则
交付要求如果只停留在“希望大家规范使用”，就无法检查。使用规则要把推广目标翻译成具体场景下的动作和时限，让检查人有据可依。规则覆盖的对象建议包括五类：任务登记（什么工作必须建任务、必填哪些字段）、文档归档（文档放在哪个空间、命名与目录规则）、状态更新（状态变更的时机与责任人）、评审记录（评审结论记录在哪里、谁确认）、通知习惯（哪些变更需要通知、通过什么渠道、响应时限）。
每条规则按“场景—动作—时限—责任人—检查方式”五段写。例如：场景为需求变更，动作为在任务中更新需求描述并标注变更原因，时限为变更确认后当日内，责任人为需求负责人，检查方式为每周抽查变更记录是否含原因说明。再如：场景为会议形成决议，动作为将决议转为任务并指派负责人，时限为会后一个工作日内，责任人为会议组织者，检查方式为例会检查上周决议任务是否已建。
规则数量需要控制。首轮推广建议不超过10条，按影响面排序：优先保留直接影响交付可见性的规则（任务登记、状态更新），其次是影响知识沉淀的规则（文档归档、评审记录），通知习惯类规则可放在后一批。规则过多会让执行者难以记住，检查成本也会上升。每条规则标注生效时间和适用范围，试点期规则可先在小范围试行，验证后再推广。
规则要与考核和例会衔接才有约束力。可行做法是：把规则遵守情况纳入部门例会的固定议题，由部门负责人通报上周检查结果；把关键规则（如任务登记完整性）纳入个人或团队的月度评价参考，权重不宜过高，重点是形成可见的反馈。检查动作要指定人：谁抽查、抽查多少条、结果记在哪里，都要在规则清单中写明。
| 规则对象 | 规则示例（场景—动作—时限） | 检查方式 |
|---|---|---|
| 任务登记 | 承接新工作时建任务并填写负责人与截止时间，接单当日完成 | 每周抽查新增任务字段完整率 |
| 文档归档 | 方案类文档存入指定空间并按“项目-文档类型-日期”命名，定稿当日归档 | 月度抽查文档目录与命名 |
| 状态更新 | 任务状态变化当日内更新，阻塞时标注原因 | 例会查看超期未更新任务 |
| 评审记录 | 评审结论记入对应文档并注明确认人，评审后一个工作日内完成 | 抽查评审文档是否含结论与确认人 |
| 通知习惯 | 影响他人的变更在协作工具内通知相关人，一个工作日内响应 | 抽查变更通知记录与响应情况 |
示例：一次试点推广的责任与交付安排
以下为演示情景，用于说明责任表与规则如何填写，团队应按自身规模调整。某团队计划在研发部门的一个小组试点协作工具，试点期四周，参与人员为小组全体成员、小组负责人、工具管理员和推广发起人。
试点范围选择标准：业务链路完整、成员配合度高、有可对比的基线数据（如当前任务平均响应时间）。人员选择上，小组负责人担任试点负责人，工具管理员负责配置与培训，发起人担任验收人。
| 时间 | 动作 | 负责人 | 交付物 | 完成标志 | 验收人 |
|---|---|---|---|---|---|
| 第1周 | 确认试点名单与基线数据 | 小组负责人 | 试点名单、基线数据表 | 名单经发起人确认，基线含至少两项可对比指标 | 发起人 |
| 第1周 | 完成账号开通与基础配置 | 工具管理员 | 账号权限清单、配置记录 | 试点成员账号全部可用，配置项逐条记录 | 小组负责人 |
| 第2周 | 组织试点培训并发布规则 | 工具管理员 | 培训记录、规则清单 | 成员完成签到，规则清单经小组负责人确认 | 小组负责人 |
| 第2—4周 | 按规则运行并记录问题 | 小组负责人 | 问题清单、规则执行记录 | 问题逐条有提出人和处理状态 | 发起人 |
| 第4周 | 输出试点结论 | 小组负责人 | 试点结论报告 | 报告含规则可行性判断、问题处理结论、推广建议 | 发起人 |
试点验收检查项建议包括：规则清单中的每条规则是否被实际执行过至少一次；问题清单中的问题是否都有处理结论；基线指标是否取得试点期数据；成员是否能独立完成核心操作。判定标准可设为“全部检查项通过”或“关键项通过且遗留问题有明确处理计划”，具体口径在试点启动前确定。
试点结论要反馈到全员推广方案，至少回答三个问题：哪些规则需要修改措辞或调整时限，哪些角色负担过重需要增配协作方，推广时间表是否需要调整。结论报告中的改进项要逐条落到责任人和截止时间，进入下一阶段的责任表。
用检查与复盘让责任持续生效
责任表在推广启动时容易执行，几周后往往被搁置。让责任持续生效的关键是把检查排进固定日程，并让检查结果有去处。检查节奏建议分层：每周由部门负责人做一次规则执行抽查，每月由推广负责人汇总一次交付物完成情况，每季度做一次整体复盘。
检查内容围绕三类：使用情况（活跃人数、任务登记量、文档归档量等可导出的数据）、规则遵守情况（抽查结果与问题记录）、交付物完成情况（责任表中各项的完成标志是否达成）。检查结果记录在同一张表里，标注检查人、检查时间和发现的问题，避免口头通报后无据可查。
复盘会议的输入包括：本期检查结果、未完成交付物清单、问题清单及处理状态、使用数据变化。议题聚焦三件事：哪些责任没有落实及原因、哪些规则需要调整、下一期需要新增或取消哪些交付物。输出应包含改进项、责任人、截止时间和责任表更新版本。会议时长控制在合理范围，避免变成情况汇报会。
责任表需要版本管理。每次复盘后更新版本号，记录变更内容与变更原因，旧版本归档保留。规则清单同样如此，避免成员执行的是过期规则。若团队使用 ONES，交付物完成情况可通过工作项状态和看板查看，ONES Performance 支持对研发过程数据做多维度分析，可用于汇总阶段进展；具体统计口径需按团队实际配置确定。
责任落实不到位的处理方式按情形区分：因规则不合理导致的，调整规则而非追责；因负责人时间冲突导致的，增配协作方或调整截止时间；因明确未执行导致的，由部门负责人在例会通报并纳入评价参考。处理结论要记录在案，作为下一轮复盘的输入。
完成检查：推广责任与交付是否到位
推广启动前或阶段结束时，用以下清单逐项自查。每项都应有明确的是或否判断，判断为否的项要写明补正动作和责任人。
- 责任表是否覆盖准备、试点、全员上线、稳定运营全部四个阶段，没有阶段空缺。
- 每项交付物是否只有一个负责人，负责人为具体姓名而非部门名称。
- 每项交付物是否都有可核对的完成标志，标志包含产出物、确认动作或量化条件。
- 每项交付物是否指定了验收人，且验收人与负责人不是同一人。
- 每项交付物是否都有具体截止日期，没有使用“上线前”等相对时间。
- 使用规则是否覆盖任务登记、文档归档、状态更新、评审记录、通知习惯中的关键对象。
- 每条规则是否写明场景、动作、时限、责任人和检查方式。
- 每条规则是否都有对应的检查动作，检查人、抽查范围和记录位置明确。
- 跨部门争议的升级路径是否写明触发条件、裁决人和时限。
- 周检查、月度汇总、季度复盘是否已排入日程并有固定参与人。
- 责任表和规则清单是否有版本号与变更记录，旧版本是否归档。
- 试点结论中的改进项是否已逐条落实到责任人和截止时间。
清单全部通过，说明推广责任与交付机制具备可执行条件；存在未通过项时，优先补正负责人缺失和完成标志缺失两类问题，这两类问题会直接导致后续检查无法开展。
常见问题
推广责任表由谁维护，多久更新一次？
责任表建议由推广负责人维护，发起人负责批准。更新节奏与复盘节奏对齐：每次复盘后更新版本号，记录变更内容和原因，旧版本归档保留。阶段切换时也要更新，例如试点结论中的改进项要逐条落到责任人和截止时间，进入全员上线阶段的责任表。日常发现负责人变动或截止时间调整，可随时修订，但要在变更记录中注明。
团队规模较小，是否还需要区分发起人、工具管理员和部门负责人？
角色可以合并，但职责不能空缺。小团队中发起人可兼任工具管理员，部门负责人可由团队负责人承担，关键是把决策、配置执行、规则检查三类动作分别落到具体人，并保证验收人与负责人分离。若一人同时担任负责人和验收人，该项交付物应改由上一级或发起人验收，否则完成标志失去约束力。
使用规则与现有部门流程冲突时怎么处理？
先把冲突写清楚：是哪条规则、与哪个流程的哪一步冲突、影响哪些角色。由规则涉及部门的负责人协商，协商不成提交推广例会讨论，由发起人在约定时限内裁决，结论记录在案。处理结果有两种走向：调整规则措辞或时限，或者在责任表附注中写明该部门的例外条件和适用范围。例外要有时限和复查安排，避免长期悬空。
试点通过后，全员上线阶段最容易遗漏哪些交付物？
常见遗漏有三类：账号与权限开通清单没有逐人核对，导致上线后部分成员无法使用；培训记录只统计签到，没有验证成员能否独立完成核心操作；首批规则执行情况没有留记录，复盘时缺少基线。建议在上线检查表中把这三项写成可核对的条件，例如抽查若干名成员现场完成一次任务登记与状态更新，结果记入检查表。
检查发现规则遵守率低，应该先改规则还是先追责？
先判断原因。若规则本身与工作场景不匹配、时限过紧或检查方式不可行，应调整规则，这类问题追责没有意义。若规则合理但负责人时间冲突，可增配协作方或调整截止时间。只有在规则合理、资源到位的情况下明确未执行，才由部门负责人在例会通报并纳入评价参考。处理结论要记录，作为下一轮复盘的输入。
