研发任务排期-随风（ym-dev-rd-plan）
把「要做个系统」变成一张不用再想下一步做什么的清单。这个技能只管计划与进度，不产出任何专业内容（技术方案、表结构、代码都不在范围内）。
> 本技能来自「编程专家团-随风」专家团的 研发交付经理 角色（Agent ym-dev-team-lead）——该角色在 Phase 3 用它做任务拆解与排期。全流程编排见配套技能 ym-dev-team-lead。
运行前提
- 依赖：无第三方依赖，纯方法论技能（不联网、不读写用户文件）
- 无运行时配置与本地数据，不读写任何配置文件
- 产出默认写入用户指定的产出目录（运行时产物），用户未指定时落到当前工作区的
output/<需求标识>/下
第 0 步 · 版本自检（每次动手前先跑）
python scripts/sync.py --json
只读比对线上版本：退出码 0 最新 · 10 有新版建议重装 · 20 主版本不同必须重装 · 30 联网失败按旧版继续。
本技能不自动更新自己 —— 换版本只有一条路：用户明确重装（skillhub install ym-dev-rd-plan）。
何时使用
- 需求/PRD/设计文档已经就绪，要落地成开发任务
- 项目做到一半，需要重排期或盘点进度
- 交付收尾，要汇总交付物与遗留风险
- 用户问「这活儿要拆成几步」「大概多久」
不适用：需求本身还没理清（先走需求调研）、技术方案未定（先走技术决策）。
输入要求
开工前必须具备，缺哪项就先补齐或标注为待澄清：
- 范围：这次要做什么、明确不做什么
- 产出物清单：最终要交付什么（代码/文档/脚本/配置）
- 已知约束：期限、技术栈限制、依赖的外部系统
- 验收口径：怎么算做完
工作流
第 1 步：拆到「一个人一天能做完」
拆解粒度以可独立验收为准，不是以「模块」为准。判断标准：
| 太粗（打回重拆） | 合适 |
|---|---|
| 完成后端开发 | 实现设备点检单的查询接口，含分页与条件过滤 |
| 完善前端页面 | 点检单列表页（表格 + 筛选 + 分页） |
| 优化数据库 | 为点检记录表补 (device_id, check_time) 联合索引 |
单条任务预估超过 3 天就继续拆，超过 5 天必然藏着没想清楚的东西。
第 2 步：每条任务写全四要素
[任务 ID] 任务名
- 做什么：一句话说清交付物形态（接口/页面/脚本/文档）
- 谁负责：对应角色
- 依赖：必须先完成的 任务 ID，没有就写「无」
- 预估值：0.5d / 1d / 2d（不用小时，估算精度没到那个级别）
- 完成判据：怎么验证这条算完了
禁止出现「完善系统功能」「优化用户体验」「提升性能」这类无法验收的表述。
第 3 步：排依赖顺序，找出关键路径
- 列出所有「依赖」非空的任务，串成链
- 最长的那条链就是关键路径 —— 它决定最短交付周期
- 关键路径上的任务不能并行，其他任务可以
第 4 步：写人天口径声明（最容易跳过、后果最严重的一步）
同一个需求，口径不同能算出相差数倍的工期。数字交出去之前，先把口径写死：
| 要声明什么 | 为什么必须写 |
|---|---|
| 含什么 | 把计入的工作类型列全：需求 / 设计 / 建模 / 编码 / 联调 / 测试 / 文档 / 部署 |
| 不含什么 | 明确排除项：UAT 支持、上线后维保、真机兼容、历史数据清洗、培训。不写出来就会被当成已包含 |
| 边界条件覆盖程度 | 异常分支、并发、越权、脏数据处理算不算工作量 —— 这是最大的隐藏差距来源 |
| 测试 / 开发 人天比 | 低于 25% 几乎一定是漏算了用例设计、回归与缺陷复验 |
| 文档工作量 | 需求 / 设计 / 任务清单本身也要花人天，不列出来就等于白送 |
| 估算依据 | 计法口径：一「人天」= 熟悉业务的人一天产出，不含沟通等待与返工 |
三条硬校验（不通过就必须写清理由，写不出理由就是没算清）：
- 测试人天 ≥ 开发人天的 25% —— 低于此值要逐项说明哪些测试活动被省略了
- 必须含边界条件 —— 结论里若只有正常流程，等于假设「上线后不出异常」，不接受
- P0 与 P1 分开合计 —— 要给用户一个「只做 P0 需要多少人天」的可选口径
缓冲怎么报：明细表里写原始估算，不掺水；另外单独给两个数——「缺陷修复预留」（按开发人天的 8%~12% 估）与「周期缓冲提示」（实际交付按估算的 1.3 倍看）。三者不要混成一个数字，否则用户无法判断风险来自哪里。
第 5 步：出进度排期表
状态列只有四种取值：待开始 / 进行中 / 已完成 / 阻塞。
阻塞项必须写清两件事：阻塞原因 + 解除条件。写不出解除条件的，说明这个阻塞还没分析到位。
第 6 步：里程碑与风险台账
- 里程碑按可验证的交付节点设，不按时间点设（写「后端接口全部自测通过」而不是「第 2 周结束」）
- 风险台账每行包含：风险描述 / 影响范围 / 触发条件 / 应对预案 / 负责人
第 7 步：交付汇总
收尾时产出交付包目录 + 交付说明 + 遗留风险清单（含「已知但本次不修」的项）。
产出模板
人天口径声明（必须随任务清单一并交付）
| 项 | 内容 |
|---|---|
| 含什么 | |
| 不含什么 | |
| 边界条件覆盖 | |
| 测试 / 开发 人天比 | ___%（红线 ≥ 25%） |
| 文档工作量 | |
| 估算依据 |
合计：P0 ___ 人天 ＋ P1 ___ 人天 ＝ ___ 人天
缺陷修复预留：___ 人天（按开发人天的 8%~12%） 周期提示：交付预期按估算 ×1.3 看待，日历约 ___ 周
任务清单（WBS）
| ID | 任务 | 模块 | 优先级 | 负责 | 依赖 | 预估 | 状态 | 完成判据 |
|---|---|---|---|---|---|---|---|---|
| T01 | P0 | 无 | 1d | 待开始 |
进度排期表
| 里程碑 | 包含任务 | 状态 | 卡点 |
|---|---|---|---|
| M1 需求与设计定稿 | T01-T04 |
风险台账
| 风险 | 影响 | 触发条件 | 应对预案 | 负责人 |
|---|---|---|---|---|
交付包目录
deliverables/
├── 01-需求/ 调研纪要、需求规格说明书、PRD
├── 02-设计/ 系统设计文档、接口定义、设计规范
├── 03-数据/ 数据模型、建表脚本、变更脚本
├── 04-代码/ 前端、后端
├── 05-测试/ 测试用例、测试报告、缺陷清单
└── 06-上线/ 部署方案、上线清单、回滚预案
质量自检清单
- [ ] 附了人天口径声明，且「不含什么」写得出具体条目，不是「无」
- [ ] 测试人天 ≥ 开发人天的 25%（低于则已逐项说明省略了什么）
- [ ] P0 与 P1 分别合计，能给用户「只做 P0」的可选口径
- [ ] 明细估算、缺陷修复预留、周期缓冲三者分开呈现，没混成一个数
- [ ] 每条任务都能单独验收，不存在「做完也不知道算不算完」
- [ ] 单条预估均 ≤ 3 天
- [ ] 所有依赖指向存在的任务 ID，无循环依赖
- [ ] 关键路径已识别，且已知它是周期瓶颈
- [ ] 阻塞项都写了「解除条件」
- [ ] 风险台账里没有「加强沟通」这类无效应对
- [ ] 交付包目录里的每一项都真实存在，没有占位目录
常见坑
- 把「阶段」当「任务」：阶段是聚合，任务是可执行单元。混用会导致进度表永远显示「进行中」。
- 估时不留缓冲：单人项目按最理想情况算必然延期。明细表里写原始估算，另外单独给「缺陷修复预留」和「周期 ×1.3 提示」，不要把三者混成一个数报出去。
- 进度表美化：延期就写延期。把延期项改写成「提前进入下一阶段」是自欺欺人。
- 依赖写成「无」偷懒：绝大多数任务都有前置文档依赖，写「无」前先确认对上游产出真的没要求。
- 口径不清就报数字：只给一个总数（如「约 35 人天」）而不说含什么、不含什么。用户会拿它当承诺工期用 —— 而同一个需求，「只跑通主流程」与「算上异常 / 权限 / 并发 / 回归 / 真机兼容」相差几倍是常态。防法：先出「人天口径声明」，再出数字。
- 测试人天按拍脑袋给：测试不是「开发完再点一遍」。它包含用例设计、数据准备、执行、回归、缺陷复验、环境与真机兼容六块，漏掉任何一块都会让上线后的问题由用户来发现。
交付方式
- 完整产出写入用户指定的产出目录（默认
output/<需求标识>/ym-dev-rd-plan.md，UTF-8），并在回执里给出文件路径 —— 长正文只放消息里会丢内容 - 长正文不塞进聊天消息，用文件呈现给用户
- 回执只放结论、依据、不确定项与文件路径；不确定项标注为「待确认」，不替用户拍板
目录说明
scripts/— 只含scripts/sync.py版本自检器（只读，不改任何文件）
