名称: 技术规划 描述: 采用风险优先开发、里程碑结构化和延迟管理来规划技术项目。在规划软件项目、定义里程碑、结构化开发阶段或将复杂任务分解为可管理的迭代时使用。
技术规划
核心原则
关注“是什么”而非“如何”: 定义可交付成果，而非实现细节。指定约束和成功标准，但保持实现选择灵活。
最后责任时刻: 推迟决策直到有足够信息，但不至于晚到阻碍进度。快速做出可逆决策；延迟不可逆决策直到必要。
风险优先开发: 首先解决最高风险的技术挑战。在完整实现前构建概念验证。早期交付工作但不完美的解决方案以验证核心假设。
延迟管理: 明确记录延迟的内容和何时处理。区分核心价值交付与优化/抛光。
使用TodoWrite进行进度跟踪
使用TodoWrite通过四个阶段跟踪规划进度：
-
开始时: 为每个阶段创建待办事项：
☐ 阶段1: 需求与风险分析 ☐ 阶段2: 里程碑规划 ☐ 阶段3: 实施策略 ☐ 阶段4: 执行框架 -
规划期间: 标记阶段为进行中→完成。为关键交付添加子待办事项：
☐ 提取核心需求（2-3个用户旅程） ☐ 识别技术风险（高风险/集成/性能/架构） ☐ 用成功标准定义里程碑 ☐ 记录延迟项及理由 -
对于复杂项目: 将澄清问题及其解决方案作为待办事项跟踪 – 防止在信息不完整时进行。
决策时机框架
早期决定（需求阶段）:
- 要解决的用户问题
- 成功标准和衡量方法
- 硬约束（安全、合规、性能SLA）
- 关键集成和依赖项
- 影响架构的技术选择
推迟到实施（执行阶段）:
- 具体算法或数据结构
- 内部API设计细节
- 代码组织模式
- 库选择（当多个选项有效时）
- 性能优化（直到证明必要）
- UI/UX细节（直到用户测试）
原因: 早期决策应使工作能进行而不锁定细节。实施决策随着实践经验变得更清晰，并常揭示比前期规划更好的替代方案。
代理指南
在进行前寻求清晰性: 切勿假设不清晰的需求、技术约束或业务优先级。只有在关键方面有80%以上信心时才进行。具体询问：
- 要解决的用户问题（不仅是请求的功能）
- 成功标准和衡量方法
- 技术约束和现有系统依赖
- 团队能力和技术偏好
- 时间约束和优先级权衡
- 性能和可扩展性要求
阶段1: 需求与风险分析
先决条件检查
验证：
- 要解决什么用户问题？
- 主要用户是谁及其工作流？
- 如何衡量成功？
- 技术和业务约束是什么？
提取核心需求
- 识别要解决的基本用户问题
- 映射主要用户旅程（聚焦2-3个关键路径）
- 定义项目成功指标
识别技术风险
- 高风险: 可能使方法无效的技术未知
- 集成风险: 外部系统依赖和兼容性问题
- 性能风险: 可扩展性瓶颈和算法挑战
- 架构风险: 具有广泛影响的基本设计决策
风险优先级矩阵
- 关键 + 未知: 必须在里程碑1中用概念验证解决
- 关键 + 已知: 在早期里程碑中用既定模式解决
- 非关键: 推迟到后期里程碑或消除
阶段2: 里程碑规划
先决条件检查
验证：
- 阶段1识别的技术风险优先级顺序
- 团队容量和可用时间
- 不同组件之间的依赖关系
- 此项目的“工作功能”定义
里程碑结构
- 时间线: 基于项目复杂度的4-8周周期
- 交付: 每个里程碑必须产生可测试的工作功能
- 风险聚焦: 序列化里程碑以首先处理最高风险项
为每个里程碑定义：
目标: 里程碑结果的一句话描述
核心任务: 遵循最后责任时刻原则的4-6个主要实施任务：
- 定义明确结果和约束
- 识别依赖和集成点
- 提供上下文和考虑（非逐步指令）
- 保持实现细节灵活
- 标记在执行期间要解决的问题
成功标准:
- 最低可行成功（必须达到以完成里程碑）
- 完全成功（包括抛光的理想结果）
风险缓解: 在此里程碑中要解决的特定未知
延迟项: 有意排除的内容及目标里程碑
任务分解指南
分解任务时，提供指导而非规定:
✓ 良好任务定义（结果导向）：
- 目标：“使用户能安全认证”
- 约束：“必须与现有会话中间件集成；<100ms响应时间”
- 指导：“考虑会话vs令牌认证；查看src/middleware/中的现有模式”
- 验证：“用户能登录，会话持久，测试通过”
✗ 较差任务定义（过于规定）：
- 步骤1：“用bcrypt导入创建文件auth.js”
- 步骤2：“用bcrypt.hash写hashPassword函数，使用10轮”
- 步骤3：“创建检查req.session.userId的Express中间件”
原因: 良好定义让实施者基于所学选择最佳方法。较差定义在理解上下文前锁定选择，常导致返工。
里程碑定义示例
目标: 验证用户认证和从外部API的基本数据检索
核心任务:
- 实现OAuth流程与提供商
- 创建用户会话管理
- 构建带错误处理的API客户端
- 添加基本用户资料显示
成功标准:
- 最低：用户能登录并查看资料数据
- 完全：包括资料编辑和会话持久性
风险缓解: 确认API速率限制和负载下的响应时间
延迟: 高级资料功能，密码重置流程（里程碑3）
阶段3: 实施策略
开发方法
- 原型优先: 构建一次性版本以测试风险假设
- 核心先于抛光: 在UI细化前实现功能特性
- 早期集成: 在第一里程碑测试外部系统连接
- 持续衡量: 从第一天跟踪性能和用户指标
技术选择标准
- 团队专长: 优先团队熟悉的技术
- 验证可靠性: 为核心系统选择成熟、经测试选项
- 集成能力: 确保与现有工具/系统的兼容性
- 可扩展性路径: 技术应支持预期增长
质量门
- 所有代码必须有基本测试覆盖
- 核心用户旅程必须满足性能基准
- 认证和数据处理需要安全审查
- 用户面向功能必须满足无障碍标准
阶段4: 执行框架
冲刺规划
- 风险评估: 识别即将工作的未知
- 探索时间: 为原型/学习预留20-30%的冲刺时间
- 完成定义: 必须包括工作功能，不仅是完成的代码
- 持续验证: 对核心用户旅程的定期利益相关者反馈
延迟管理
- 定期审查: 每个里程碑评估延迟项的相关性
- 类别: 技术债务、UX抛光、边缘案例、性能优化、高级功能
- 调度: 将延迟项规划到适当的未来里程碑
- 消除: 一些延迟项可能变得不必要
文档要求
- 专注于可交付结果的技术规范
- 带缓解计划的风险寄存器
- 带目标调度的延迟项登记
- 主要选择的架构决策记录
代理决策框架
如果项目有未知技术可行性 → 在里程碑1规划概念验证 如果项目需要外部集成 → 在第一里程碑测试最小集成 如果项目有性能要求 → 早期建立基准和测试核心算法 如果团队缺乏所选技术专长 → 在早期里程碑包括学习/探索时间 如果项目有紧期限 → 聚焦最低可行成功标准并推迟抛光 如果项目是绿地 → 花费额外时间在架构决策和基础设置 如果项目是增强 → 聚焦集成点和向后兼容性
当不清晰时 – 询问这些问题
当需求模糊 → “这解决什么具体用户问题？我们如何衡量成功？” 当技术范围未定义 → “必备vs可有可无的技术能力是什么？” 当时间线不现实 → “不可协商的截止日期是什么？存在什么灵活性？” 当团队能力未知 → “团队有哪些技术经验？技能缺口是什么？” 当集成点不清晰 → “这必须连接哪些现有系统？数据格式和API约束是什么？” 当性能需求未指定 → “预期用户负载和响应时间要求是什么？” 当成功标准缺失 → “我们如何知道此里程碑完成和成功？”
常见陷阱以避免
- 当需求不清晰时做假设而非询问澄清问题
- 以不完整信息进行而非请求必要细节
- 创建过于规定的任务定义，用逐步指令而非结果导向指导
- 过早做出实施决策，当可推迟到执行时
- 花时间在低风险特性上同时推迟关键未知
- 在验证核心假设前过度工程解决方案
- 规划实施细节而非聚焦可交付结果
- 猜测用户需求而非理解具体要解决的问题
- 未记录延迟决策和理由
- 过早优化而非首先证明核心功能
- 在理解完整上下文前锁定技术选择