试点项目落地手册
目的
这份文档把专家评审建议落到一个真实项目上。不要一开始全公司推广，也不要继续补很多组织级原则。先选一个项目跑通：
选项目
-> 填项目入口
-> 新人试跑
-> 小任务试交付
-> 发布或模拟发布
-> 复盘并修文档
试点目标不是证明流程完美，而是找出当前团队在项目理解、协作、开发、验收、发布和排障上的真实断点。
适合选什么项目
优先选择满足这些条件的项目：
| 条件 | 为什么 |
|---|---|
| 正在维护或近期会改 | 能用真实任务验证，不是纸面演练 |
| 风险中等 | 足够暴露问题，但不会因为试点影响核心生产 |
| 有产品或业务验收人 | 能验证“做完是否有价值” |
| 有本地开发环境 | 能检验新人是否跑得起来 |
| 有发布或 preview 流程 | 能检验发布、smoke、回滚和观察 |
不建议第一批选择：
- 已经无人维护的历史项目。
- 生产事故高发、正在救火的项目。
- 完全没有 owner 的项目。
- 一次变更要跨很多仓库的大平台项目。
- 只有老板口头需求、没有任何任务入口的项目。
试点参与人
| 角色 | 必须做什么 |
|---|---|
| Sponsor | 允许团队花 1-2 周做试点，接受短期效率下降 |
| Product Owner | 选一个真实小需求或 bug，写清用户问题和验收标准 |
| Tech Owner | 说明架构边界、风险路径、review 规则 |
| Ops Owner | 说明本地依赖、发布入口、回滚、监控和日志 |
| Doc Driver | 推动 docs/PROJECT.md、试点记录和文档修复 |
| 新人 / 非核心成员 | 按文档跑项目，记录哪里跑不通 |
| Reviewer | Review 试点 PR，检查证据、风险和文档更新 |
小团队可以一人多职，但角色必须写在试点记录里。不要写“研发组负责”，要写具体人。
第 0 天：试点启动
启动前先用 72-试点讨论清单-stakeholder-discussion-guide.md 确认参与人、讨论点和工具入口。
输出一个试点任务，至少包含：
项目：
试点周期：
Sponsor：
Product Owner：
Tech Owner：
Ops Owner：
Doc Driver：
新人 / 试跑人：
试点任务：
完成标准：
建议使用模板：templates/试点验收-pilot-acceptance.md。
第 1-2 天：补项目入口
Doc Driver 用 templates/项目入口-project-index.md 创建项目内的：
docs/PROJECT.md
先不要追求完整，只要能让新人回答这些问题：
- 项目解决什么问题？
- 主要用户或调用方是谁？
- Product Owner、Tech Owner、Ops Owner、Doc Driver 分别是谁？
- 本地要装什么？
- 本地怎么启动依赖服务？
- 环境变量从哪里来？
- 怎么启动 Web / API / worker？
- 改完要跑什么检查，每个命令验证什么？
- PR 找谁 review？
- 发布、回滚、监控、日志入口在哪里？
如果当前项目没有 ARCHITECTURE.md、TECH_STACK.md、DEPENDENCIES.md，先在 PROJECT.md 里写 L0 摘要，不要卡住。
第 3 天：新人试跑
找一个不熟悉该项目的人，严格按 docs/PROJECT.md 执行，不允许靠老员工口头带路。
试跑记录必须写清：
| 项 | 记录 |
|---|---|
| 机器和系统 | macOS / Linux / Windows，芯片架构 |
| 分支 / commit | 确认使用同一个版本 |
| 安装依赖 | 成功 / 失败，耗时 |
| 启动依赖服务 | 成功 / 失败，缺什么 |
| 准备环境变量 | 成功 / 失败，哪些变量不清楚 |
| Migration / seed | 成功 / 失败，错误是什么 |
| 启动应用 | 成功 / 失败，本地地址 |
| 本地快速检查 | 命令、结果、失败原因 |
| 核心路径 smoke | 怎么验证，结果是什么 |
遇到问题时，先修文档或脚本，不要只在群里解释一次。
第 4-7 天：小任务试交付
选择一个真实小任务，按正常流程走完：
任务卡
-> scope 和验收标准
-> 本地开发
-> 检查命令
-> PR
-> review
-> 产品验收
-> 关闭任务
试点任务不适合太大。推荐：
| 类型 | 适合原因 |
|---|---|
| 文案或表单校验 | 容易验证，有用户可见结果 |
| 小 bug 修复 | 能检验任务、PR、测试、验收 |
| 小 API 行为修正 | 能检验请求响应、测试和日志 |
| 文档和脚本修复 | 能快速改善新人体验 |
不适合：
- 跨仓库重构。
- 数据库破坏性 migration。
- 权限、支付、客户数据大改。
- 没有明确验收人的需求。
第 8-10 天：发布或模拟发布
如果变更能发布，走真实发布流程。如果暂时不能发布，至少做一次模拟发布。
必须验证：
| 项 | 需要证明 |
|---|---|
| Release scope | 本次包含哪些任务和 PR |
| 发布负责人 | 谁操作，谁观察，谁拍板 |
| CI 结果 | 哪些检查通过，失败如何处理 |
| Smoke | 主路径怎么验证 |
| 回滚 | 代码、配置、数据、feature flag 怎么回退 |
| 监控 | 看哪个 dashboard、哪些日志、哪些告警 |
| 产品验收 | 谁验收，结论是什么 |
使用模板：templates/发布检查表-release-checklist.md。
第 11-14 天：复盘和推广判断
复盘只问事实，不做空泛总结。
| 问题 | 结论 |
|---|---|
| 新人是否半天内跑起项目？ | 是 / 否，卡在哪里 |
| 任务是否从进入到关闭全链路可追踪？ | 是 / 否，断点在哪里 |
| PR 是否带验证证据、风险和回滚？ | 是 / 否，缺什么 |
| 产品是否完成验收？ | 是 / 否，为什么 |
| 发布或模拟发布是否可复制？ | 是 / 否，缺哪个入口 |
| 文档和代码不一致是否被修正？ | 是 / 否，是否形成任务 |
| 哪些流程有价值，应该保留？ | |
| 哪些流程太重，应该删减？ |
复盘输出三类 action：
| 类型 | 例子 | Owner |
|---|---|---|
| 立即修 | PROJECT.md 命令错误、链接失效、环境变量缺说明 |
Doc Driver / Ops Owner |
| 后续补 | 架构图、依赖图、runbook、测试说明 | Tech Owner |
| 暂不做 | L3 模块契约、复杂自动化、Agent 接入 | Sponsor / Tech Owner |
试点通过标准
满足下面条件，才建议推广到第二个项目：
- 新人或非核心成员能按文档跑起项目。
- 至少一个小任务完成了任务、PR、验证、review、验收、关闭。
- PR 里有检查命令结果和用户可见证据。
- 发布或模拟发布能说清 rollback 和观察入口。
- 试点期间发现的文档问题至少修掉一部分。
- 三角色都认为流程没有明显拖慢交付。
如果不满足，不要推广。继续在同一个项目修 L0。
推广节奏
试点通过后，再按下面顺序推广：
第 1 个项目：完整试点，发现问题
第 2-3 个项目：复制 PROJECT.md 和发布检查表
第 4-5 个项目：统一 PR 模板、检查命令说明、owner 字段
更多项目：只强制 L0，不强制全量文档
每个新增项目只要求先做到：
- 有
docs/PROJECT.md。 - 有具体 owner。
- 有本地启动命令。
- 有检查命令和含义。
- 有 PR / CI / 发布 / 监控入口。
- 有一个核心 smoke。
常见失败模式
| 失败模式 | 处理 |
|---|---|
| 试点变成写文档运动 | 回到一个真实小任务，用任务闭环验证文档 |
| 负责人只挂名不参与 | 暂停试点，重新确认 Product Owner、Tech Owner、Ops Owner |
| 新人靠私聊跑起来 | 把私聊答案补回 PROJECT.md，否则不算通过 |
| 命令跑不通但没人修 | 创建文档或脚本修复任务，指定 Driver |
| 产品验收缺席 | 选择更小的用户可见变更，要求 Business Approver |
| 发布流程靠个人收藏夹 | 把发布入口、dashboard、日志补到 PROJECT.md |
| 一上来要求所有项目执行 | 先完成一个项目的 L0，再复制 |
和 90 天计划的关系
试点项目是 60-90天落地计划-rollout-90-day-plan.md 的执行抓手。
0-30 天先用试点验证工作入口和任务闭环；31-60 天验证 PR、CI、发布和回滚；61-90 天再扩大到核心项目，并评估是否具备后续 Agent 就绪条件。
下一步阅读
读完或填完这份文档后，通常继续看：
- 73-试点确定方案-pilot-decision.md：如果需要最终拍板，先看确定版方案。
- 72-试点讨论清单-stakeholder-discussion-guide.md：如果参与人、讨论点或工具入口不清楚，先回到讨论清单。
- 试点验收-pilot-acceptance.md：试点执行时，用验收模板记录证据和结论。