笔记 L：估算、排期与进度掌控
[Chief Project Director's Note] (研发总监按)： 请把这句话刻在你的脑子里：项目管理的本质，绝不是为了拿一条鞭子逼迫大家“死守工期”，而是为了 “管理各方预期 (Manage Expectations)” 并 “提前暴露风险 (Expose Risks)”。
模块一：软件估算的科学与艺术 (Software Estimation)
估算是所有项目规划的基石。它不仅是科学，更是一门在信息不足时做出承诺的艺术。我们通常使用分解技术和经验模型来抵御估算的不确定性：
- 基于功能点 (FP-Based) 的估算：不关注代码行数，而是评估信息域的复杂性（如外部输入、输出、查询、内部逻辑文件和外部接口）。这使得我们在需求阶段（不用等代码写完）就能得出系统规模。
- 基于过程 (Process-Based) 的估算：将问题功能与软件工程活动（如沟通、策划、建模、构建等）融合，形成一个矩阵，直接估算每个功能在每个活动上所需的研发人月。
- 经验估算模型 (如 COCOMO II)：使用从现有历史项目数据中推导出的公式，根据代码行数或功能点来预测工作量和周期。它的底层逻辑是：历史数据是预测未来的最有效武器。
模块二：任务分解结构 (Work Breakdown Structure, WBS)
面对复杂系统时，人类的本能是“分而治之 (Divide and Conquer)”。 WBS 就是将宏大的项目目标，自顶向下拆解为独立的、可分配的、可度量的“工作包（任务）”。如果不做 WBS，你就无法为每个任务分配具体的资源，也无法定义任务之间的前置依赖关系 (Intertask dependencies)。
模块三：排期与关键路径 (Scheduling & Critical Path)
当我们把 WBS 中的任务分配到时间线上，就形成了项目进度表。
- 关键路径法 (CPM)：在由数百个相互依赖的小任务构成的任务网络中，关键路径 (Critical Path) 是决定整个项目总工期的那条“最长任务链”。
- 生与死的决定线：非关键路径上的任务即使延期，只要不耗尽浮动时间，项目依然能按时交付；但如果关键路径上的任何一个任务落后于进度，整个项目的完工日期就会直接受到威胁。
- 计划评审技术 (PERT)：通过应用统计模型（如乐观、悲观、最可能的三点估算），为关键任务建立“最可能的”时间估计和边界窗口。
模块四：项目追踪与 90-90 法则 (Tracking & Control)
- 可怕的 90-90 法则：行业里有一句戏谑但极其真实的“90-90 法则”——“系统的前 90% 会消耗掉 90% 的时间和精力；而剩下的最后 10% 会消耗掉另外 90% 的时间和精力”。这通常是因为前期缺乏严密的架构设计，导致后期的联调测试和 Bug 修复陷入了无尽的泥潭。
- 进度跟踪与时间盒 (Time-boxing)：为了对抗失控，有经验的管理者会使用时间盒策略。面对严酷的死线，强行为任务设定一个时间盒（如两周）。当触及时间盒边界时，即便只完成了 90%，也必须停止当前工作，交付可用增量，将剩下的 10% 推迟到下一版本，从而确保项目整体进度不断向前。
研发总监的深度思考维度
[Engineering Mindset] (工程权衡逻辑)
- “精确估算带来的成本” vs. “估算偏差带来的风险”：追求 100% 精确的估算是徒劳的，且极其昂贵（只有在项目做完时估算才是 100% 准确的）。但凭直觉拍脑袋的风险是毁灭性的。权衡之道是：在项目早期提供一个“带有置信区间（如 ±30%）”的估算，并随着项目的推进、认知的深入，持续进行迭代式规划 (Iterative planning)。
- 为什么必须预留缓冲区 (Buffer)？ 因为软件工程具有极高的变异性。开发人员生病、需求变更、第三方 API 宕机都是常态。缓冲区不是给开发者“摸鱼”的时间，而是吸收系统性风险的物理隔震层。
[AI-Era Mapping] (AI 时代的演进与实战)
- 估算模型重构：在 Cursor 这种 AI 编程神器面前，传统的“代码产出率 (LOC/pm)”度量已经失效。AI 可以在一小时内写出以前一周才能写完的代码。现在的估算重心，必须从“代码编写量 (Coding)”彻底转移到“业务逻辑的复杂度 (Logic Complexity)”和“验证与评审工作量 (Validation Effort)”上。审查 AI 生成的一万行面条代码的时间，可能比人手写还要长。
- AI 辅助排期与关键路径的偏移：过去，项目的关键路径通常被“重度编码模块”占据。在 “人机协作” 模式下，编码不再是瓶颈。关键路径发生了重大偏移，转移到了：上游的需求澄清 (Prompt 编写)、下游的自动化测试构建，以及人工代码评审 (Code Review) 环节。 如果你排期时还在给 AI 写代码留出几周时间，而没给测试留足时间，项目必死无疑。
[Memory Trigger] (记忆触发器)
- 精准比喻：WBS 就像是“宜家家具的安装图纸”，而关键路径是“拼装顺序”。 你不能在没有搭建好衣柜框架（关键路径任务）之前，就去安装抽屉把手（非关键路径任务）。哪怕你有十个帮手（AI Agent），如果框架没搭好，所有人只能干瞪眼。
特别模块：架构师的 Cursor 任务拆解指令 (WBS Generator Prompt)
当面对一个模糊的复杂需求时，不要直接让 AI 写代码，先让它为你生成严密的工程 WBS 计划。将以下指令丢给 Cursor 或其他大模型：
# [Role]: 资深研发总监 (Senior R&D Director) & 敏捷项目经理
**Context**: 我们即将启动一个新的系统模块开发（需求如下文所述）。在写任何代码之前，我需要你运用软件工程的 WBS (任务分解) 思维和依赖关系分析，为我制定一个工程排期表。
**Requirement**:
[此处粘贴你的业务需求，如：开发一个支持并发高并发的抢购秒杀系统...]
**Task**: 请按照以下结构输出专业的项目规划：
1. **[WBS Decomposition (任务分解)]**:
将需求拆解为包含 前端、后端、数据库、测试、DevOps 的具体工作包。每个任务不能超过 2 人日的工作量。
2. **[Dependency & Critical Path (依赖与关键路径)]**:
- 明确指出哪些任务是前置任务（如：必须先定义好 API 契约，才能前后端并行开发）。
- 分析并加粗标注出本项目的 **Critical Path (关键路径)**。
3. **[AI-Era Effort Estimation (AI 协作工时估算)]**:
假设开发者将全程使用 Cursor (AI 辅助编程) 进行开发。请给出每个任务的预计耗时。
*(注意：请大幅压缩常规 Boilerplate 代码的编写时间，但必须增加针对 AI 代码的 Review、自动化测试编写以及 Edge Case 边界验证的时间！)*
4. **[Risk Buffer (风险预警)]**:
指出在这个模块开发中，最可能触发“90-90法则”（即最后10%工作耗尽90%时间）的技术难点在哪里？给出规避建议。
**Action**: 请以 Markdown 表格的形式输出 WBS 清单，并附加文字解析。