工具切换完成后，团队真正要面对的问题从“系统能不能用”变成“大家是否每天在用”。推广阶段的目标，是把已经上线的平台变成交付、评审和文档沉淀的默认场所。本文按推广前界定、分阶段执行、角色分工、数据观察、排期示例和收尾检查展开，适用于刚完成切换、准备推动日常采用的研发管理者与推广负责人。
要点总览（TL;DR）
- 推广的起点是界定：按角色圈定必用与可选对象，明确先迁移的项目类型和工作流，并为每个阶段设定可核对的完成标志。
- 推广按试点跑通、约定固化、分批扩面、常态运行四个阶段推进，每阶段写清输入、动作、输出和完成标志，问题在影响面最小时暴露。
- 推动与采用分开落责：推广负责人管节奏和约定文档，团队负责人管本团队工作项流转，一线成员负责录入与沉淀，平台管理员负责配置与问题响应。
- 用活跃角色覆盖率、工作项流转完整度、文档与评审沉淀三类指标做周度复盘，异常时按流程不顺、权限缺失、习惯未改分类处理。
- 推广期以4–8周为观察窗口，收尾时逐项核对必用角色流转、约定引用、旧入口关闭时间点和遗留问题闭环。
推广前先定清楚：推广对象、范围与完成标志
推广的起点是界定，而不是发一封全员通知。启动前需要把三件事写清楚：谁必须用、哪些工作先迁、什么状态算完成。这三项确定后，后续的培训、答疑和复盘才有明确对象，推广也不会退化成泛泛的动员。
第一，按角色和团队圈定首批推广对象。必用角色通常是承担交付责任的人，例如项目负责人、需求负责人、开发与测试的执行成员，他们的工作项必须在新平台创建和流转。可选角色包括阶段性参与评审、偶尔查阅进度的岗位，可以先提供访问权限和简短指引，不设强制录入要求。区分这两类角色，能避免推广初期把精力平均摊到所有人身上。
第二，明确推广范围。列出先迁到新平台的项目类型和工作流，例如“本季度新立项的研发项目，从需求提出到上线评审全流程在新平台运行”。范围写得越具体，团队越容易判断自己手上的工作是否需要切换。范围之外的项目可以保留原有方式，但要标注后续迁移的时间预期，避免长期双轨。
第三，为每个阶段设定可观察的完成标志。完成标志应能通过平台数据或文档状态直接核对，例如“试点项目的需求、任务、缺陷全部在新平台创建并走完状态流转”“团队约定文档已发布且被至少一次评审引用”。完成标志不追求精确的百分比，但必须能回答“这一阶段结束了没有”。
启动前可以形成一份推广范围与阶段完成标志清单，包含以下字段：
| 字段 | 填写内容 | 示例 |
|---|---|---|
| 推广对象 | 必用角色、可选角色及所属团队 | 研发一组、二组的项目负责人与执行成员为必用；产品经理为可选 |
| 推广范围 | 项目类型、工作流、时间边界 | 本季度新立项项目，需求到上线评审全流程 |
| 阶段划分 | 试点、固化、扩面、常态 | 四个阶段，每阶段一至两周 |
| 完成标志 | 可核对的状态或数据 | 试点项目全部工作项在新平台流转完毕 |
核心推广步骤：从试点跑通到全员采用
推广按四个阶段推进：试点跑通、约定固化、分批扩面、常态运行。每个阶段都明确输入、动作和输出，阶段之间以完成标志作为推进条件。这样安排的好处是，问题在影响面最小的时候暴露，约定在扩面之前成型。
试点阶段：用真实项目跑完整流程
输入是推广范围清单和1–2个真实项目。动作是让试点项目从需求提出、任务拆解、开发提交、测试验证到评审关闭，全程在新平台完成，推广负责人跟随记录每个卡点：哪个字段填不出来、哪个状态找不到、哪次评审不知道该在哪里留记录。输出是一份卡点清单，按流程不顺、权限缺失、习惯未改分类。完成标志是试点项目的主要工作项全部在新平台走完一轮完整流转。
固化阶段：把用法写成团队约定
输入是试点卡点清单。动作是把新平台中的字段含义、状态流转规则、评审节点和文档存放位置写成一份团队约定，明确哪些字段必填、状态由谁推进、评审记录留在哪里、文档按什么目录组织。约定发布前应经过团队负责人确认，发布后作为培训和答疑的统一依据。输出是已发布的团队约定文档。完成标志是约定文档可被检索到，并在至少一次项目评审中被引用。
扩面阶段：按团队分批切换
输入是团队约定和分批名单。动作是按团队或项目组逐批切换，每批配套一次定向培训和一至两周的陪跑，陪跑期内推广负责人或平台管理员集中响应问题，把高频问题补充进约定文档或答疑记录。输出是各批次的切换记录和问题台账。完成标志是当批必用角色的工作项已在新平台创建并持续更新。
常态阶段：让新平台成为默认入口
输入是扩面完成情况。动作是把新平台设为交付与评审的默认入口：项目例会用新平台的进度视图、评审在新平台留记录、交付物在新平台归档，旧入口按计划转为只读或关闭。输出是默认入口的切换说明和旧入口处理时间点。完成标志是团队日常例会与评审不再依赖旧系统取数。
| 阶段 | 输入 | 关键动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 试点 | 推广范围清单、1–2个真实项目 | 全程在新平台跑完整流程，记录卡点 | 卡点清单（按原因分类） | 试点项目工作项完成一轮完整流转 |
| 固化 | 卡点清单 | 编写并发布字段、状态、评审与文档约定 | 团队约定文档 | 约定已发布且被评审引用 |
| 扩面 | 团队约定、分批名单 | 分批切换，配套培训与陪跑 | 切换记录、问题台账 | 当批必用角色工作项持续更新 |
| 常态 | 扩面完成情况 | 例会、评审、交付归档切换到新平台 | 默认入口切换说明 | 日常取数与评审不再依赖旧系统 |
在工作项流转、评审记录和文档沉淀集中到同一平台后，推广负责人可以直接从平台侧核对阶段完成标志。以ONES为例，需求、任务、缺陷等工作项的状态流转、评审记录与项目文档可以在同一项目空间内关联，团队约定中的字段和状态也能作为项目模板复用，减少每批切换时重复配置的工作。推广期需要观察的活跃角色和工作项流转情况，也可以从项目与工作项的记录中提取，作为周度复盘的依据。
角色与交付物：谁负责推动、谁负责采用
推广期的责任需要落到具体角色和具体交付物上。推动与采用是两类不同的责任：推广负责人对节奏和机制负责，团队负责人和一线成员对实际使用负责，平台管理员对配置和问题响应负责。四类角色的职责与交付物如下。
| 角色 | 主要职责 | 交付物 | 完成判断 |
|---|---|---|---|
| 推广负责人 | 统筹阶段节奏，组织周度复盘，维护团队约定文档 | 推广范围清单、阶段排期、周度复盘记录、约定文档 | 各阶段完成标志按期核对 |
| 团队负责人 | 确保本团队工作项在新平台创建和流转，参加复盘 | 本团队切换确认、遗留问题清单 | 本团队必用角色工作项持续更新 |
| 一线成员 | 按要求录入和更新工作项，在平台内沉淀文档与评审记录 | 工作项状态更新、评审记录、项目文档 | 交付过程可在平台内追溯 |
| 平台管理员 | 维护字段、权限与项目模板，响应使用问题 | 配置变更记录、问题处理台账 | 高频问题有处理结论并回写约定 |
分工确定后，建议在推广启动会上逐条确认，并写入团队约定文档的开头部分。推广负责人不替代团队负责人推动具体成员使用，团队负责人也不承担平台配置工作，边界清晰可以减少问题在角色之间来回转移。
用数据判断采用程度：推广期看哪些指标
推广是否有效，要看使用行为是否稳定发生，而不是看通知是否发出。推广期建议按周采集三类指标，并在周度复盘会上对照阶段完成标志解读。
第一类是活跃角色覆盖率。统计必用角色中当周在新平台有实际操作的人数比例，并单独查看关键角色，例如项目负责人是否持续更新工作项。覆盖率停滞时，先确认是哪些角色没有动作，再判断原因。
第二类是工作项流转完整度。观察新平台中的工作项是否走完约定的状态与评审节点，而不是只停留在创建阶段。可以按项目抽查：需求是否推进到关闭、缺陷是否经过验证、评审是否留下结论。流转完整度低，通常说明流程设计与实际工作方式存在偏差。
第三类是文档与评审记录沉淀情况。检查项目文档、评审结论、交付物是否存放在新平台，而不是继续散落在聊天工具或个人目录中。沉淀情况直接决定新平台能否成为交付证据的载体。
指标异常时，按三类原因排查：流程不顺，例如状态过多或必填字段与实际工作不匹配；权限缺失，例如成员看不到所属项目或无法推进状态；习惯未改，例如团队仍按旧方式在群里同步进度。前两类由平台管理员和推广负责人处理，第三类需要团队负责人做定向辅导，并把正确做法在例会上演示一次。
| 指标 | 观察口径 | 异常时的优先排查方向 |
|---|---|---|
| 活跃角色覆盖率 | 必用角色当周有实际操作的比例，关键角色单独看 | 权限是否到位、培训是否覆盖该角色 |
| 工作项流转完整度 | 工作项是否走完约定状态与评审节点 | 状态设计是否贴合实际流程、必填字段是否过多 |
| 文档与评审沉淀 | 项目文档与评审结论是否存放在新平台 | 目录与模板是否清晰、旧习惯是否延续 |
周度复盘模板可以固定为四栏：本周指标、与阶段完成标志的差距、原因归类、下周动作与负责人。复盘结论要回写到团队约定或问题台账，避免同一问题反复讨论。
示例：一个研发团队四周推广安排
以下为一个约二十人研发团队的推广排期示例，用于说明节奏如何排布，实际执行时可按团队规模和项目节奏调整。推广期通常以4–8周为一个观察窗口，四周安排适合范围较集中、项目类型单一的团队。
第一周，选定一个正在进行中的真实项目作为试点，由项目负责人带队在新平台跑完需求、任务、测试和评审流程。推广负责人每天记录卡点，周末整理成卡点清单，按流程不顺、权限缺失、习惯未改分类。本周完成标志是试点项目主要工作项完成一轮完整流转。
第二周，根据卡点清单修订字段与状态设置，发布团队约定文档，并组织一次定向培训。培训内容围绕约定文档展开：字段怎么填、状态由谁推进、评审记录留在哪里、文档放在哪个目录。本周完成标志是约定文档发布，且试点项目的下一次评审按约定留下记录。
第三、四周，按两个批次扩面，每批一个项目组，配套答疑与陪跑。每周五做一次复盘，对照活跃角色覆盖率、工作项流转完整度和文档沉淀情况，确定下周的定向辅导对象。第四周结束时，全部必用角色的工作项应已在新平台持续更新，旧入口的关闭或只读时间点同步公布。
四周结束时仍需处理遗留问题，例如个别成员权限未开通、某类评审记录格式尚未统一。这些问题应逐条登记负责人和关闭时间，纳入下一阶段跟踪，而不是等到推广总结时再集中处理。
完成检查：推广是否真正落地
推广阶段能否结束，用一份检查清单逐项核对，比凭感觉判断更可靠。以下条目全部满足，可以认为推广进入常态运行；存在未满足项时，明确责任人和补齐时间。
- 必用角色的工作项已在新平台完整流转，抽查近期项目可看到从创建到关闭的记录。
- 团队约定文档已发布，并在项目评审、培训或答疑中被实际引用。
- 项目文档、评审结论和交付物已在新平台沉淀，日常取数不再依赖旧系统。
- 旧入口已明确关闭或转为只读的时间点，并已通知到全部必用角色。
- 遗留问题逐条有负责人和关闭时间，且已进入周度复盘的跟踪范围。
- 周度复盘已形成固定节奏，指标口径和复盘模板稳定使用。
旧入口的处理需要与团队约定同步公布。关闭或转只读的时间点一旦确定，应留出查档过渡期，并说明历史数据的查阅方式；涉及数据留存与审计要求的部分，按企业自身制度确认后再执行。完成检查通过后，推广工作转入常态治理：约定文档随流程变化更新，复盘频率可以降低，但指标核对和问题闭环的机制保留。
常见问题
推广期设多长比较合适，四周和八周怎么选？
观察窗口通常取4–8周。团队规模较小、项目类型单一、试点项目能在一两周内跑完完整流程时，四周排期足够覆盖试点、固化、扩面和一次收尾检查。团队多、项目类型差异大，或需要跨部门参与评审时，扩面批次会增加，八周更稳妥。判断依据是扩面批次数量和每批陪跑所需时间，而不是固定套用某个周数。
必用角色和可选角色怎么划分，划分错了会有什么影响？
划分依据是交付责任：工作项需要由本人创建、推进或关闭的岗位列为必用，阶段性参与评审或偶尔查阅进度的岗位列为可选。划分过宽，推广精力被摊薄，培训和陪跑难以覆盖真正需要改变习惯的人；划分过窄，关键角色游离在外，工作项流转会出现断点。推广中期可以根据实际流转情况调整一次名单，调整时同步更新团队约定文档。
旧系统入口什么时候关，关了之后历史记录怎么查？
旧入口的关闭或转只读时间点应与团队约定同步公布，并留出查档过渡期。一般安排在扩面完成、必用角色工作项已在新平台持续更新之后，避免在切换中途切断历史记录查阅。关闭前需说明历史数据的查阅方式，涉及数据留存与审计要求的部分，按企业自身制度确认后再执行。旧入口处理时间点建议写入收尾检查清单，与遗留问题一并跟踪。
周度复盘发现指标上不去，先查流程还是先做培训？
先区分原因再决定动作。成员看不到所属项目或无法推进状态，属于权限问题，由平台管理员处理；状态过多、必填字段与实际工作不匹配，属于流程问题，需要修订约定文档；成员仍按旧方式在群里同步进度，属于习惯问题，由团队负责人做定向辅导，并在例会上演示一次正确做法。三类原因混在一起时，培训和流程修改都会失效，复盘记录中应把原因归类写清楚。
推广结束后，团队约定文档还需要维护吗？
需要。推广转入常态运行后，约定文档随流程变化更新，字段含义、状态规则和评审节点的调整都应回写到文档，避免文档与实际用法脱节。复盘频率可以降低，但指标核对和问题闭环的机制保留，新成员入职培训也以约定文档为统一依据。
