工具切换支持手册用于替换上线后的推广与治理阶段，把“谁在什么时点做什么、看什么状态、找谁求助”写成可执行的操作文档。下面给出一份20人研发团队切换完成后四周推广期的已填写示例，并逐项解释写法、可替换变量与适用边界。示例中的团队、数据与效果均为演示情景，不代表真实客户案例；手册中的工作项流转、求助记录与复盘动作，可由ONES这类研发协作平台承载。
要点总览（TL;DR）
- 工具切换支持手册服务于替换上线后的推广期，核心是把角色、求助渠道、推广节奏、问答口径和观察指标写成可执行文档。
- 示例给出20人团队四周推广期的完整填写稿：第1周会用、第2周用对、第3周看结果、第4周固化，并配套角色表与观察项。
- 观察采用度应看工作项创建与流转量、字段完整率、求助量与关闭情况，登录数只能说明打开过平台。
- 换团队时保留五段骨架，替换团队规模、小组划分、角色名称、周期长度和指标口径；推广期结束后转入例行检查与责任人机制。
- 示例中的团队、数据与效果均为演示情景，不构成采用率或效率提升承诺，选型与迁移切换阶段应走各自流程。
这份支持手册要解决什么问题
支持手册的目标是推动新平台从“能用”走到“常用、按约定用”。它服务的阶段是替换上线完成之后到团队形成稳定使用习惯之前，通常覆盖上线后的前四到八周。手册要改变的行为很具体：研发和测试在新平台创建工作项、按流程走评审、及时更新状态、按约定字段填写必要信息。这些动作是否发生、是否规范，决定了替换是否真正落地。
手册的读者包括五类角色：研发与测试人员是主要使用者，需要知道怎么建单、怎么填字段、遇到问题找谁；项目经理负责检查工作项流转和评审是否按约定执行；部门负责人关注采用进度和遗留问题；平台管理员负责权限、字段配置和问题闭环。每类角色在手册中应有对应的动作和求助路径，避免手册只写给一线使用者，管理者却不知道自己要做什么。
手册与选型实施、迁移切换窗口有明确分工。选型阶段解决“选哪个平台”，实施阶段解决“怎么配置和上线”，迁移切换窗口解决“数据怎么迁、怎么校验、怎么回退”。支持手册从替换完成、团队开始在新平台日常工作的那一刻接手，不重复迁移方案，也不承担选型论证。写手册时把这条边界放在开头，能避免读者把推广问题和迁移问题混在一起。
以下示例为虚构团队与虚构数据，仅作填写示范。读者可以参照结构和口径，替换成自己团队的真实角色、周期和指标。
完整示例：一个20人研发团队切换后的四周支持手册
示例背景
某20人研发团队，分为两个业务小组，每组约10人，各设1名种子用户。团队已完成工具替换，旧平台进入只读状态，新平台开始承接日常工作。团队指定1名平台管理员，两个小组各1名负责人。推广期定为四周，目标是第四周末团队能按约定流程独立使用新平台，求助量回落到日常水平。以下数据均为演示设定。
角色与支持渠道
| 角色 | 职责 | 求助入口 | 响应时限（示例） |
|---|---|---|---|
| 平台管理员 | 权限开通、字段与流程配置、问题汇总与升级 | 专用支持群，@管理员 | 工作时间内2小时响应 |
| 小组种子用户 | 本组一线答疑、示范建单与字段填写、收集高频问题 | 组内群或当面 | 当日内答复 |
| 部门负责人 | 检查本组采用进度、协调资源、参加周复盘 | 周例会与复盘会 | 按周例会节奏 |
| 项目经理 | 检查工作项流转与评审执行、反馈流程问题 | 支持群或复盘会 | 当日内反馈 |
| 一线研发与测试 | 按约定建单、填字段、更新状态 | 先找本组种子用户，解决不了转支持群 | — |
四周推广节奏
| 周次 | 主题 | 主要动作 | 完成标志（示例） |
|---|---|---|---|
| 第1周 | 会用 | 集中答疑；组织一次建单演练，每人新建一个工作项并走完基本流转 | 全员至少完成一次建单与状态更新 |
| 第2周 | 用对 | 检查字段填写与流程执行，针对高频错误做一次短说明 | 字段完整率明显上升，重复问题减少 |
| 第3周 | 看结果 | 试用评审流程与报表，项目经理核对工作项流转是否反映真实进度 | 至少完成一轮基于新平台的评审与进度查看 |
| 第4周 | 固化 | 复盘四周问题与数据，确定遗留事项责任人和例行检查节奏 | 形成复盘记录与后续治理安排 |
常见问题与统一答复口径
- 旧数据在哪看：旧平台进入只读，历史数据按迁移方案保留查询入口；新工作一律在新平台创建，具体查询方式以管理员通知为准。
- 字段怎么填：必填字段以工作项类型模板为准，不确定时参照种子用户提供的填写示例，仍不清楚则在支持群提问。
- 权限怎么申请：在支持群提交申请人、所需角色和用途，由平台管理员按权限规则开通，工作时间内2小时内响应。
- 流程走错了怎么办：先在工作项中说明情况并联系项目经理，由项目经理判断是回退状态还是补充记录，避免私下改状态。
采用度观察项
| 观察项 | 观察方式（示例） | 用途 |
|---|---|---|
| 活跃人数 | 按周统计在新平台有操作的人数 | 判断覆盖面，识别未进入使用的成员 |
| 工作项创建与流转量 | 按周统计新建数和状态变更数 | 判断工作是否真正迁到新平台 |
| 字段完整率 | 抽查必填字段的填写情况 | 判断使用是否规范 |
| 求助量与问题关闭情况 | 记录支持群提问数、关闭数和遗留数 | 判断问题是否在收敛 |
示例逐项解释：每个板块为什么这样写
把角色与支持渠道放在手册前部，是为了降低求助成本。切换初期问题集中出现，如果使用者不知道找谁、多久有回应，问题容易积压，种子用户也会被重复提问拖住。示例中设置“先找本组种子用户、解决不了转支持群”的两级路径，并给出响应时限，让求助有明确预期。响应时限的具体数字属于演示假设，团队应按自身工作时间和支持人力调整。
四周节奏按“会用、用对、看结果、固化”分段，对应采用过程的不同阶段。第1周先让每个人完成一次建单和状态更新，解决“不敢用、不会用”；第2周转向字段和流程规范，解决“用了但不规范”；第3周引入评审和报表，让管理动作也落到新平台；第4周复盘并确定后续治理安排，避免推广期结束就失去跟进。这个分段逻辑可以保留，周数可按团队规模和问题收敛速度压缩或延长。
统一答复口径的作用是避免同一问题出现多种说法。切换初期，旧数据位置、字段填法、权限申请这类问题会被反复问到，如果种子用户、管理员、负责人各说一套，使用者会无所适从。示例把高频问题写成固定答复，并注明以管理员通知为准，既保证一致性，也保留了口径更新的入口。
观察项选择行为数据而非单纯登录数，是因为登录只能说明有人打开过平台，不能说明工作是否迁过来。工作项创建与流转量反映实际使用，字段完整率反映使用规范程度，求助量与关闭情况反映问题是否收敛。示例中的统计频率和判断标准是演示设定，实际口径应与团队的工作项类型和管理要求对齐。
可迁移规律：换团队、换工具时怎么改这份手册
这份手册的固定骨架包括五部分：目标与边界、角色与渠道、推广节奏、问答口径、观察项与治理节奏。换团队或换工具时，骨架可以保留，需要替换的是具体变量。下表列出常见变量及替换建议。
| 变量 | 示例取值 | 替换时考虑 |
|---|---|---|
| 团队规模 | 20人，两个小组 | 规模变大时增加种子用户数量，明确分组答疑责任 |
| 小组划分 | 按业务分为两组 | 按实际组织结构或项目线划分，保证每组有对接人 |
| 角色名称 | 平台管理员、种子用户、部门负责人 | 沿用团队既有称谓，避免手册角色与实际岗位脱节 |
| 周期长度 | 四周 | 问题收敛慢可延长，简单切换可压缩，但保留分段逻辑 |
| 观察指标口径 | 活跃人数、流转量、字段完整率、求助量 | 与团队的工作项类型、必填字段和管理关注点对齐 |
推广期结束后，治理节奏需要延续。示例在第4周复盘时确定遗留事项责任人和例行检查安排，实际做法可以是每月检查一次字段完整率和工作项流转情况，由平台管理员汇总、部门负责人在例会上跟进。治理节奏的频率和检查项应按团队管理要求设定，重点是把责任人和检查时点写清楚，避免推广期一结束就无人跟进。
手册本身也需要维护。建议在文档中标注版本、负责人和更新触发条件，例如流程或字段调整、组织变动、高频问题口径变化时更新。手册中的工作项流转、求助记录和复盘结论如果集中在一个协作平台中管理，更新和查阅会更方便；ONES可用于承载工作项管理、状态流转和文档协作，具体配置按团队实际流程设定。
适用边界与常见误用
这份示例适用于替换已完成、团队进入推广期、并且已经明确平台管理员和小组负责人的情况。此时手册能帮助团队把推广动作、求助路径和观察指标固定下来。如果团队尚在选型阶段，或仍处于迁移切换窗口、数据校验和回退方案尚未确定，应走对应的选型与迁移流程，支持手册不能替代这些工作。
照搬示例容易出现的误用有几类。只发文档不安排答疑，使用者遇到问题无处求助，问题会迅速积压；观察项只看登录数，无法判断工作是否真正迁到新平台；问答口径各说各话，同一问题出现多种答案，增加混乱；推广期结束即停止治理，字段完整率和流程执行会逐渐回落。这些误用的共同点是把手册当成一次性通知，而它需要配套的答疑、检查和复盘动作。
示例中的团队规模、周期、指标数值和完成标志均为演示情景，用于说明手册的写法和组织方式，不构成对采用率或效率提升的承诺。实际使用时，团队应结合自身规模、流程要求和支持人力调整周期与指标，并以真实运行数据判断推广效果。
常见问题
推广期定四周是硬性要求吗？团队规模不同该怎么调整？
四周是示例设定，不是统一标准。调整时保留“会用、用对、看结果、固化”的分段逻辑，按问题收敛速度压缩或延长：小团队、流程简单可压到两到三周；跨多个小组、字段和评审规则较多时可延长到六到八周。判断依据是求助量是否回落、字段完整率是否稳定，而不是日历上是否走完四周。
种子用户由谁担任，需要额外授权吗？
示例中每组设1名种子用户，通常由组内熟悉流程、愿意答疑的研发或测试骨干担任。手册里要写清两件事：种子用户负责本组一线答疑和示范填写，超出权限的问题转给平台管理员；种子用户收集的高频问题定期汇总给管理员，用于更新问答口径。种子用户本身不需要系统管理权限，但需要知道字段模板和常见问题的标准答复。
推广期结束后，治理动作怎么延续才不至于流于形式？
关键是把检查项、频率和责任人固定下来。示例在第4周复盘时确定遗留事项责任人，实际可安排每月检查一次字段完整率和工作项流转情况，由平台管理员汇总，部门负责人在例会上跟进异常。检查项宜少而具体，与团队当前的管理关注点对齐；口径或流程调整时同步更新手册版本和问答口径。
手册里的问答口径和实际流程冲突时以哪个为准？
以平台管理员确认的最新口径为准。示例在答复中注明“具体以管理员通知为准”，就是为口径更新留出入口。出现冲突时，由管理员判断是流程配置需要调整，还是手册表述需要修订，并在支持群统一发布更正，避免种子用户和负责人各自解释。手册更新时记录版本和变更点，便于后续查阅。
团队还在迁移切换窗口，能先用这份手册吗？
不建议。迁移切换窗口的重点是数据迁移、校验和回退方案，支持手册从替换完成、团队开始在新平台日常工作后接手。两者时间上可以衔接：迁移方案确定后，提前准备手册中的角色表和求助渠道，等切换完成即进入推广节奏。若数据校验尚未完成就发推广手册，使用者容易把迁移遗留问题当成使用问题，增加答疑负担。
