协作工具推广常见的问题，是通知发了、培训做了，却没人说得清谁在什么时候交出什么。把推广拆成可交付的工作项，为每项任务指定唯一负责人，写清输入、动作、输出和完成标志，再按阶段验收，责任和交付要求才能落到实处。下面给出一张责任矩阵、一套任务卡模板、四步执行流程和一份自查清单，可直接用于部门级推广。
要点总览（TL;DR）
- 推广责任用简化 RACI 矩阵定到人：每项任务只设一个唯一负责人（A），其余角色标注执行、咨询、知会，避免多人负责等于无人负责。
- 交付要求用任务卡承载，写清输入、动作、输出、完成标志四要素，并标注截止时间与前置依赖；完成标志须能被第三方直接判断。
- 推广按目标与范围确认、试点或分批推广、全面推广、验收与复盘四步推进，每阶段产出物存放在约定位置。
- 验收时对照启动阶段确定的指标逐条核对，留存签到、工作项记录等证据，复盘产生的改进任务同样进入任务卡管理。
- 推广任务、责任人与交付物可在 ONES Project 中承载为工作项，交付文档通过 ONES Wiki 关联对应任务，便于责任与交付物对应留痕。
推广责任怎么分：一张责任矩阵定到人
推广责任不清，往往源于角色定义模糊：大家都被拉进推广群，却不知道谁拍板、谁执行、谁提供支持。先列出角色，再逐项任务分配责任类型，才能让每个推广动作有唯一负责人。
推广涉及的角色与职责边界
| 角色 | 职责边界 | 不承担的事项 |
|---|---|---|
| 发起人 | 确认推广目标、范围与资源，对最终结果负责 | 不介入日常任务执行细节 |
| 工具管理员 | 账号开通、权限配置、空间与模板搭建、使用问题响应 | 不负责推动各部门成员实际使用 |
| 部门推广负责人 | 在本部门组织培训、跟进使用进度、汇总反馈 | 不承担跨部门资源协调 |
| 团队负责人 | 把工具使用纳入团队日常工作安排，检查成员使用情况 | 不负责工具配置与权限 |
| 成员 | 完成账号激活、参加培训、按约定在工具中更新工作项 | 不承担推广组织工作 |
责任矩阵的填写规则
采用简化 RACI：每项任务只设一个 A（唯一负责人），其余角色标注 R（执行）、C（需咨询）、I（需知会）。填写时按“任务行 × 角色列”逐格判断，空格表示不参与，避免用“大家一起”模糊责任。
| 推广任务 | 发起人 | 工具管理员 | 部门推广负责人 | 团队负责人 | 成员 |
|---|---|---|---|---|---|
| 确认推广目标与范围 | A | C | C | I | I |
| 开通账号与配置权限 | I | A/R | C | I | I |
| 组织部门培训 | I | C | A/R | R | R |
| 首批工作项迁移或新建 | I | C | R | A/R | R |
| 使用情况检查与反馈汇总 | I | C | A/R | R | I |
分配时守住一条原则：一项任务只能有一个 A。若出现两个部门都认为对方在推，说明矩阵中该行缺少唯一负责人，应回到发起人层面重新指定，而不是增加更多协作会议。
交付要求怎么写：任务卡的四要素
责任矩阵回答了“谁负责”，任务卡回答“交什么、什么时候交、怎样算交完”。每项推广任务用一张任务卡承载，四要素缺一不可。
四要素的写法
- 输入：开始这项任务前必须具备的材料或条件，例如账号清单、部门成员名单、培训材料初稿。输入缺失时任务应标记为阻塞，而不是带着缺口推进。
- 动作：负责人要执行的具体操作，用动词开头，例如“为部门 30 名成员开通账号并分配项目角色”。
- 输出：任务完成后产生的交付物，须是可见、可打开的具体对象，例如“账号开通记录表”“培训签到与录屏”。
- 完成标志：第三方可直接判断的验收条件，例如“部门内 80% 成员完成首次登录并创建至少一条工作项”，避免写成“培训效果良好”。
交付物命名与存放约定
统一命名格式为“推广阶段_部门_交付物名称_日期”，例如“试点_市场部_培训签到表_20250610”。所有交付物存放在推广项目约定的同一位置，任务卡中写明存放路径，验收人按路径即可找到，不依赖私聊索要。
截止时间与依赖关系
任务卡需标注截止日期，并写明前置任务。例如“组织部门培训”依赖“账号开通完成”，前置任务未完成时，后续任务不得提前标记完成。依赖关系用“前置：任务名称”一行注明，便于在推广看板中排序和发现阻塞。
从启动到验收：推广执行的四步流程
模板就绪后，按阶段推进能让责任和交付要求随进度落地。每个阶段结束时检查产出物是否齐全，再进入下一阶段。
第一步：目标与范围确认
发起人牵头明确推广覆盖哪些部门、哪些核心场景（如任务管理、文档协作）、期望达到的使用指标。产出为《推广目标与范围说明》，包含推广周期、覆盖人数、验收指标口径。此阶段完成标志是发起人确认签字或书面回复。
第二步：试点或分批推广
选择一到两个部门先行试点，工具管理员完成账号与权限配置，部门推广负责人组织培训，团队负责人推动成员在真实工作中使用。产出为试点部门的账号开通记录、培训记录和首批工作项。试点结束后汇总问题清单，明确哪些问题在全面推广前必须解决。
第三步：全面推广
按部门分批推进，每批指定部门推广负责人，沿用试点阶段验证过的培训材料和任务卡。工具管理员保持问题响应通道畅通，部门推广负责人按周汇总使用进度，向发起人报告偏差。
第四步：验收与复盘
对照启动阶段确定的验收指标逐条检查，收集账号激活率、活跃使用人数、核心场景工作项数量等证据。复盘会输出《推广复盘记录》，写明达成情况、未达成项的原因和后续改进任务，改进任务同样进入任务卡管理。
示例：一个部门推广任务的完整填写
以下为演示情景，非真实客户案例，读者可按本组织规模调整人数与阈值。
任务卡示例
| 字段 | 内容 |
|---|---|
| 任务名称 | 市场部协作工具首批推广 |
| 唯一负责人（A） | 市场部推广负责人 李某 |
| 输入 | 市场部 25 人成员名单、已开通的账号与项目空间、培训材料定稿 |
| 动作 | 组织一次 60 分钟培训；指导成员创建本周实际工作任务；建立部门工作项看板 |
| 输出 | 培训签到表、培训录屏、部门看板链接、成员工作项创建记录 |
| 完成标志 | 25 人中至少 20 人完成登录并各创建 1 条以上工作项；看板中本周任务全部有负责人 |
| 截止时间 | 2025 年 6 月 20 日 |
| 前置依赖 | 账号开通与权限配置完成 |
| 存放位置 | 推广项目“市场部试点”目录下 |
责任矩阵对应行
该任务在矩阵中对应“组织部门培训”与“首批工作项新建”两行：李某为 A/R，团队负责人为 R，工具管理员为 C，发起人为 I。验收时由发起人指定人员核对完成标志，检查签到表人数、工作项创建记录和看板负责人填写情况，三项均满足即判定完成，并在任务卡中记录验收日期与验收人。
推广任务、责任人与交付物可以在 ONES Project 中承载为工作项并分配负责人，任务卡中的输出文档可通过 ONES Wiki 关联到对应任务，使责任与交付物在同一处对应留痕；验收阶段如需按维度查看推广进展，可参考 ONES Performance 的交付效率、完成情况等度量维度设计检查指标，指标口径需结合本组织实际数据源确认。
完成检查：推广责任与交付的自查项
推广机制是否建立到位，可用以下清单逐项核对。任一项为“否”，说明该环节仍需补强。
责任分配完整性
- 每项推广任务在责任矩阵中有且只有一个 A。
- 五个角色均有明确人员对应，无空缺角色。
- 部门推广负责人与团队负责人的职责边界已在推广说明中写明。
- 成员知晓自己在推广中需要完成的具体动作。
交付要求明确性
- 每张任务卡四要素齐全，完成标志可被第三方直接判断。
- 交付物命名符合统一格式，存放位置已写入任务卡。
- 截止时间与前置依赖均已标注，依赖未完成的任务未被提前关闭。
- 验收指标口径在启动阶段已确认，未在验收时临时更改。
验收与证据留存
- 验收按完成标志逐条核对，并有验收人和验收日期记录。
- 培训签到、工作项记录、看板截图等证据存放在约定位置。
- 复盘记录包含未达成项原因与后续改进任务，改进任务已进入任务卡管理。
- 下一批推广可复用本批的任务卡与检查记录。
常见问题
推广任务只有一个人负责，会不会推进太慢？
唯一负责人（A）指的是对结果拍板和担责的人，不等于所有活都由他一个人干。矩阵中同一行可以有多人标注 R（执行），例如培训由部门推广负责人牵头，团队负责人组织成员参加，工具管理员提供配置支持。这样分工后，执行面并不窄，出问题时也能找到明确的责任人协调资源。
真正拖慢推广的通常是责任分散：两个部门都以为对方在推，问题在群里来回流转。设定唯一负责人正是为了缩短这条决策链。
完成标志写成百分比指标，验收时数据从哪里取？
百分比类完成标志需要在启动阶段就确定数据口径和取数方式，例如“80% 成员完成首次登录并创建至少一条工作项”，要说明统计的是哪个成员名单、以哪个时间点为准、由谁导出记录。口径未定就进入验收，容易在数字上产生争议。
如果组织使用协作平台承载推广任务，成员登录与工作项创建记录可在平台内查看，验收人按约定路径核对即可。指标口径仍需结合本组织实际数据源确认，避免验收时临时更改。
试点部门反馈的问题很多，全面推广前要全部解决吗？
不必全部解决，但需要分类处理。建议把试点问题清单分为三类：影响核心场景使用的问题，在全面推广前必须解决；影响体验但可绕行的问题，给出临时方案并排期；个别部门的特殊需求，记录后按优先级安排。
分类结论写入试点总结，并转化为带负责人的任务卡。这样全面推广时各批次知道哪些问题已有结论、哪些仍在处理，避免同一问题在每个部门重复讨论。
部门推广负责人和团队负责人的职责容易重叠，怎么区分？
可以用“组织推广”和“日常使用”来划分。部门推广负责人负责本部门的培训组织、进度跟进和反馈汇总，面向的是推广活动本身；团队负责人负责把工具使用纳入团队日常工作安排，检查成员是否按约定更新工作项，面向的是日常协作行为。
两者在责任矩阵中分别对应不同任务行，边界写进推广说明。若出现同一件事两人都认为该对方做，说明矩阵中该任务缺少唯一负责人，应回到发起人层面重新指定。
推广结束后，这套责任矩阵和任务卡还有用吗？
有用，可以转为常态化管理的基础。推广期形成的任务卡记录了各类交付物的完成标准和存放位置，后续新部门加入或新场景上线时可直接复用；责任矩阵中的角色划分也可延续到日常运营，例如工具管理员继续负责权限与问题响应，团队负责人继续检查使用情况。
复盘记录中的改进任务应继续以任务卡方式跟踪，直到关闭。这样推广不是一次性活动，而是留下了一套可重复使用的分工与交付约定。
