工具切换推广的核心，是把“已经上线”变成“真正被使用”。做法是先按角色和高频流程圈定首批必须迁移的场景，再明确各角色的动作与交付物，用可见的流程状态和评审记录替代口头督促，最后用采用率、活跃流程数、遗留工具使用情况做阶段检查。本文按启动、执行、分工、示例、治理、验收六个环节展开，适用于替换完成后进入推广期的团队；选型、实施和迁移窗口不在讨论范围。推广中的工作项状态、评审记录和采用数据，可以由ONES这类研发管理平台承载。
要点总览（TL;DR）
- 推广启动先圈定首批范围：按角色和高频流程两个维度筛选，优先纳入“高频且流程清晰”的场景，低频或流程未稳定的场景放到后续批次。
- 执行按五步推进：启动宣贯、模板与流程预置、试点团队跑通完整流程、分批扩围与答疑、每周复盘调整，每步都要有输入、动作、输出和完成标志。
- 推广涉及推广负责人、团队负责人、一线成员、平台管理员四类角色，团队负责人承担本团队采用结果，一线成员的交付物是平台内的真实记录。
- 旧工具并行使用要写成规则：明确并行期长度和退出条件，关键节点以平台记录为准，例外申请有审批和到期复查。
- 推广是否完成用检查表核对：采用类、流程类、遗留工具三类指标逐项检查，未达标项按培训、配置、执行意愿分类处理并约定复查日期。
推广先做什么：圈定首批采用范围与目标
推广启动阶段最容易犯的错误是全面铺开：所有团队同时切换、所有流程一起迁移，结果问题分散、支持力量不足、哪个环节都没跑通。更稳妥的做法是先圈定一个可控的首批范围，把目标写清楚，再按阶段扩围。
圈范围时按两个维度筛选。第一个维度是角色：哪些角色在新平台上有高频、刚性的动作，例如需求提出人、开发负责人、测试负责人、项目经理。第二个维度是流程：哪些流程每天都在发生、且状态变化清晰可追踪，例如需求提交与评审、任务分派与完成、缺陷提交与关闭。两个维度交叉后，优先纳入“高频且流程清晰”的场景，低频或流程尚未稳定的场景放到后续批次。
范围确定后，为每个场景设定可观察的采用目标。目标要能直接从平台数据里读出来，避免“大家用起来”这类无法核对的表述。常见口径包括：需求在平台内提交并完成评审的比例、任务状态按约定更新的比例、缺陷从提交到关闭全程在平台内流转的比例。目标值结合团队现状设定，例如首月要求关键流程覆盖率达到约定比例，次月再提高。
同时明确推广周期与阶段划分。一个可操作的节奏是：第一周完成宣贯、配置和试点跑通，第二周扩围到首批全部团队并做首次数据复盘，之后按两周一个周期检查采用情况，直到达到验收标准。阶段划分要写进推广计划，让每个团队知道当前处于哪一步、下一步要交什么。
本阶段的交付物是一份首批推广范围清单和阶段目标表，至少包含：纳入的团队与角色、纳入的流程、每个流程的采用目标与统计口径、各阶段的时间点和负责人。
推广执行步骤：从宣贯到日常使用的完整流程
推广执行可以拆成五个步骤，每一步都应有明确的输入、动作、输出和完成标志，避免推广停留在发通知和开会的层面。
第一步：启动宣贯
输入是切换决策、时间点和首批范围清单。动作是面向首批团队说明三件事：为什么切换、什么时间点开始按新流程执行、对每个人的日常工作有什么具体影响。宣贯要落到个人动作上，例如“需求提出人从某日起在平台内提交需求”“开发人员每天更新任务状态”。输出是宣贯记录和常见问题清单。完成标志是首批团队的关键角色都已知晓自己的动作和时间点。
第二步：模板与流程预置
输入是各流程的工作项类型、状态流转和字段需求。动作是把常用工作项类型、状态、必填字段、权限配置到位，让成员进入平台后能直接按流程操作，减少“先建一个再说”的随意性。输出是配置完成的工作项模板和流程说明。完成标志是试点团队可以不改配置直接跑通一条完整流程。
第三步：试点团队跑通一条完整流程
输入是预置好的模板和试点团队名单。动作是选一个配合度高、流程相对规范的团队，从需求提交、评审、任务拆解、开发、测试到关闭完整走一遍，过程中记录卡点和配置缺口。输出是一份可复用的流程示例和问题清单。完成标志是这条流程在平台内留下完整的状态记录和评审记录，且试点团队认可操作可行。
第四步：分批扩围与答疑机制
输入是试点沉淀的示例和问题清单。动作是按批次把流程推广到其余团队，每批扩围前用试点示例做一次简短演示；同时建立固定答疑渠道，明确响应人和响应时限，把重复出现的问题整理成问答文档。输出是扩围记录和答疑台账。完成标志是首批范围内所有团队都已按新流程提交并流转工作项。
第五步：每周复盘与调整
输入是平台内的采用数据和答疑台账。动作是每周对照阶段目标检查采用情况，区分三类问题：不会用（补培训）、不好用（补模板或调配置）、不愿用（补规则或由团队负责人跟进）。输出是周复盘记录和调整事项。完成标志是每周都有明确的调整动作并落实到人。
角色与交付物：谁负责推动、谁负责使用
推广责任悬空，通常是因为只指定了一个“推广负责人”，却没有定义其他角色要交什么。推广涉及四类角色，各自的职责和交付物如下表。
| 角色 | 主要职责 | 交付物 | 检查时点 |
|---|---|---|---|
| 推广负责人 / 项目管理员 | 确定首批范围、阶段节奏和治理规则，组织宣贯与复盘 | 推广范围清单、阶段目标表、周复盘记录 | 每周复盘会 |
| 团队负责人 | 推动本团队按新流程执行，收集并反馈使用问题 | 本团队采用情况说明、问题清单 | 每周、阶段结束时 |
| 一线成员 | 按新流程提交工作项、更新状态、参与评审 | 平台内的工作项记录、状态更新、评审意见 | 日常 |
| 平台管理员 | 维护配置、权限和数据，处理配置类问题 | 配置变更记录、权限清单、问题处理记录 | 按需、阶段结束时 |
分工中有两点需要特别说明。团队负责人承担的是本团队的采用结果，而不只是传达通知；一线成员的交付物是平台内的真实记录，推广检查看的正是这些记录是否完整、及时。推广负责人和平台管理员可以是同一人，但在团队规模较大时分开更利于配置维护和节奏推进各自到位。
推广过程中，工作项状态和评审记录本身就是分工是否落实的证据。以ONES为例，需求、任务、缺陷的状态流转和评审意见都留存在工作项上，推广负责人查看这些记录即可判断各团队的执行情况，团队负责人也能据此定位本团队的卡点，减少逐层口头汇报。
示例：一个团队两周推广过程怎么走
以下为一个演示情景，用于说明步骤如何衔接，实际执行时按团队情况调整。
背景：一个约二十人的产品研发团队完成工具切换，首批纳入需求管理和缺陷管理两条流程，涉及产品、开发、测试三个角色。阶段目标定为：两周内需求在平台内提交并完成评审的比例达到约定水平，缺陷全程在平台内流转。
第一周前半段做宣贯和配置。推广负责人向三个角色说明切换时间点和各自动作，平台管理员按需求、缺陷两类工作项配置状态和必填字段。第一周后半段由产品组作为试点，从一条真实需求开始，走完提交、评审、拆解任务、开发完成、测试验证的完整流程，过程中发现两个配置缺口并当场修正，形成一份流程示例。
第二周扩围到开发和测试全员。扩围前用试点示例做了一次演示，明确需求评审的参与人和缺陷状态的更新要求。答疑渠道每天汇总问题，重复问题整理进问答文档。周末做首次数据复盘：对照阶段目标查看需求评审完成比例和缺陷流转情况，把未达标的环节归类为培训、配置或规则问题，分别安排跟进人和完成时间。
这个示例的关键在于：第一周产出的是可复用的流程示例和修正后的配置，第二周产出的是首次采用数据和分类后的改进事项。两周结束时，团队手里有范围清单、示例、答疑台账和复盘记录，推广从一次活动变成了可重复的周期。
推广中的常见阻力与治理规则
推广遇到阻力是常态，靠反复强调解决不了，需要把处理方式写成规则，让团队知道边界在哪里。
旧工具并行使用是最常见的阻力。处理规则应明确并行期的长度和退出条件，例如规定并行期不超过一个推广周期，并行期内新发起的工作项必须在新平台创建，旧工具中的存量事项按约定时间完成归档或关闭。并行期结束后，旧工具转为只读或停用，由平台管理员执行。
关键节点以平台记录为准，是让新流程产生实际约束力的核心约定。需求评审结论、任务完成状态、缺陷关闭意见等关键节点，以平台内的记录作为依据；会议和口头沟通可以作为补充，但不替代平台记录。这条规则要提前说清楚，避免在考核或复盘时产生争议。
例外申请要有明确通道。确实存在流程不适配的场景，由团队负责人提交例外申请，说明原因、影响范围和预计持续时间，经推广负责人审批后记录在案。例外不是豁免，到期要复查：要么调整配置让流程适配，要么结束例外回归标准流程。
规则本身也要随阶段调整。推广初期规则宜少而明确，重点保证关键流程跑通；进入稳定期后，再补充数据完整性、评审时效等要求。每次调整在复盘会上说明原因和生效时间，避免规则频繁变动让团队无所适从。
完成检查：判断推广是否达标的核对项
推广阶段是否可以结束，用一张检查表逐项核对，比凭感觉判断更可靠。检查表分为采用、流程、遗留工具三类指标，外加未达标项的处理安排。
| 类别 | 核对项 | 判断口径 |
|---|---|---|
| 采用类 | 活跃用户 | 首批范围内各角色在检查周期内均有平台操作记录 |
| 采用类 | 关键流程覆盖率 | 纳入首批的流程均有团队按新方式执行，覆盖率达到阶段目标 |
| 流程类 | 工作项状态更新及时性 | 抽查工作项，状态与实际进展一致，更新间隔符合约定 |
| 流程类 | 评审记录完整性 | 关键节点的评审意见、结论和参与人记录齐全 |
| 遗留工具 | 旧工具使用情况 | 并行期内新工作项均在新平台创建；并行期结束后旧工具已按规则处理 |
核对时以平台数据为准，抽样检查与整体统计结合。未达标项不直接判定推广失败，而是按原因分类处理：属于培训不足的补培训并安排复查，属于配置不适配的调整模板后复查，属于执行意愿问题的由团队负责人跟进并约定复查时间。每项未达标事项都要有跟进人、处理动作和复查日期，复查通过后才算完成。
全部核对项达标、且未达标项均已复查通过，推广阶段即可结束，转入日常运营。此后采用情况纳入常规管理节奏，按季度或半年复查一次，防止使用率回落。
常见问题
推广期旧工具还要不要保留？并行多久合适？
并行期可以保留，但要有明确的长度和退出条件。常见做法是并行期不超过一个推广周期，并行期内新发起的工作项必须在新平台创建，旧工具中的存量事项按约定时间归档或关闭。并行期结束后，旧工具转为只读或停用，由平台管理员执行。并行期越长，团队越容易退回旧习惯，所以退出条件要提前写进推广计划，并在复盘会上确认执行情况。
试点团队跑通了，扩围到其他团队还是推不动，问题一般出在哪？
扩围受阻通常有三类原因，处理方式不同。第一类是不会用，扩围前只用试点示例做一次简短演示不够，需要针对新团队的角色补一次操作说明。第二类是不好用，试点团队的流程和字段配置未必适配其他团队，扩围前应收集一轮配置需求，必要时调整模板。第三类是不愿用，需要团队负责人明确本团队的采用要求和检查时点。扩围时按批次推进，每批扩围后留出答疑和调整时间，比一次性全员切换更容易发现问题。
关键节点以平台记录为准，会不会和线下评审会议冲突？
两者可以并存，但要分清主次。约定是：需求评审结论、任务完成状态、缺陷关闭意见等关键节点，以平台内的记录作为依据；会议和口头沟通作为补充，不替代平台记录。执行时可以在会议结束后由主持人在平台内补录结论和参与人，让记录和会议同步产生。这条规则要提前说清楚，避免在考核或复盘时对“到底算不算完成”产生争议。
推广负责人和平台管理员由一个人兼任可以吗？
可以，团队规模较小时由一人兼任更利于节奏统一。但两项职责的性质不同：推广负责人管范围、节奏和治理规则，平台管理员管配置、权限和数据维护。兼任时容易把配置类问题当成推广问题处理，或者反过来。团队规模较大、配置变更频繁时，建议分开设置，让配置维护和推广推进各自到位。无论是否兼任，配置变更记录和问题处理记录都要留存，便于复盘时追溯。
推广达标结束后，怎么防止使用率回落？
推广阶段结束后转入日常运营，采用情况纳入常规管理节奏，按季度或半年复查一次。复查沿用推广期的检查口径，重点看关键流程覆盖率和评审记录完整性是否保持。如果出现回落，先定位原因：新成员加入后没有补培训、流程调整后配置没跟上、或者团队负责人不再跟进。针对原因补动作，比重新发起一轮全面推广更有效。
