project-mngt

project-mngt

使用 MVP/MMP/MMR 方法论制定项目实施计划

目的

本技能旨在教会 AI 助手如何分析任何项目的需求，并使用 MVP/MMP/MMR（最小可行产品 / 最小可销售产品 / 最小可销售版本）方法论制定实施计划。

这是一项讲解如何制定计划的方法论技能，而不是讲解要制定什么计划。

使用场景

1. 初始项目规划：分析需求并制定结构化的实施计划
2. 计划更新：在需求变更时修改现有计划，同时保留已完成的工作
3. 进度跟踪：更新计划中的当前状态，并调整剩余工作
4. 发布策略：定义用于渐进式交付的合理阶段和原子化工作组

适应性

适用于：

• 任意数量的需求文档（5 或 500 份）
• 不同格式：BRD、PRD、用户故事、史诗、功能
• 各类领域：交易系统、Web 应用、API、基础设施、ML/AI
• 不断变化的需求：更新计划而无需重新开始已完成的工作

ID 命名标准

参考：framework/governance/ID_NAMING_STANDARDS.md

常见 ID 格式：

• 规划文档：PLAN-NNN（例如，PLAN-01、PLAN-02）
• 需求：REQ-NN 或 REQ-NN-YY（例如，REQ-01、REQ-01-01）
• 任务：TASK-NNN 或 TASK-NNN-YY（例如，TASK-01、TASK-01-01）

格式规则：

• 主要文档使用 TYPE-NN（三位数字，前置零）
• 子项使用 TYPE-NN-YY（两位数字，前置零）
• ID 在各自的制品类型中唯一
• 序号从 001 开始

---

MVP/MMP/MMR 框架

定义（2024-2025 年最佳实践）

MVP（最小可行产品）

目的：作为学习载体，与早期采用者验证核心假设
重点：测试风险最高的假设、收集反馈、证明可行性
质量：可以存在错误，用户体验不完善，流程可依赖人工
目标：回答“我们能构建这个吗？”和“用户会使用它吗？”
变现：非必需——重在学习，而非盈利
时间线：通常为 4-12 周

MVP 成功标准：

• 核心功能可端到端运行
• 已验证风险最高的技术假设
• 已收集用户反馈
• 已观察到产品与市场契合度的信号

MMP（最小可销售产品）

目的：首个可发布、能够为客户带来实际价值的产品
重点：达到可上市的质量，具备必要功能，可销售或部署
质量：精良的用户体验、稳定、可用于生产环境、错误极少
目标：回答“客户愿意为此付费吗？”和“我们能否大规模提供支持？”
变现：必需——已准备好服务付费客户
时间线：MVP 之后的 8-20 周

MMP 成功标准：

• 所有必要功能均已完成
• 代码和用户体验达到生产级质量
• 已验证安全性、性能和可靠性
• 已建立支持流程
• 营销和销售材料已准备就绪

MMR（最小可销售版本）

目的：MMP 发布后，通过增量功能发布提升市场吸引力
重点：新增功能、优化、集成和扩展能力改进
质量：与 MMP 相同——达到生产级和市场级质量
目标：回答“如何提高采用率？”和“哪些因素能推动留存？”
变现：带动扩张收入、降低客户流失，并吸引新的客户群体
时间线：每次发布 2-8 周（持续进行）

MMR 成功标准：

• 带来可衡量的客户价值
• 保持产品质量标准
• 符合产品路线图愿景
• 根据数据确定优先级

进阶路径

IDEA → MVP (validate) → MMP (launch) → MMR-1 → MMR-2 → MMR-n (grow)
         ↓                ↓              ↓        ↓        ↓
      Learn First     Earn First    Expand Value Stream

质量关卡

阶段	测试	文档	用户体验	性能	安全性
MVP	手动测试即可	最少	基础	达到可接受水平	基础
MMP	自动化	完整	精良	生产级 SLA	全面审计
MMR	自动化	已更新	精良	生产级 SLA	持续进行

---

分析方法

遵循以下 6 个步骤，制定任意实施计划：

步骤 1：需求梳理

目标：汇总所有需求并了解项目范围

流程：

1. 阅读所有需求文档（BRD、PRD、用户故事）
2. 提取每项需求的以下信息：
   • ID、描述、复杂度（1-5）、优先级提示、依赖关系、功能领域
3. 创建需求清单表

输出：完整的需求清单

步骤 2：依赖关系映射

目标：识别关系和顺序约束

依赖类型：

• 技术：需要基础设施/库/组件
• 业务：工作流所需的前置功能
• 数据：需要架构/迁移/数据源
• 集成：依赖外部系统/API

流程：

1. 为每项需求识别依赖关系
2. 将依赖关系分类为阻塞或非阻塞
3. 创建依赖关系图
4. 识别关键路径

输出：显示阻塞关系的依赖关系图

步骤 3：原子分组原则

目标：创建可独立部署、可测试的分组

原子组特征：

• 内聚：将相关功能组合在一起
• 独立：可单独开发/测试/部署
• 可测试：验收标准明确
• 有价值：交付可观察的成果
• 大小适当：工作量为 1-4 周

分组方法：

1. 功能内聚：按功能领域分组
2. 技术层：按架构组件分组
3. 用户旅程：按端到端工作流分组
4. 依赖集群：将紧密耦合的需求分组

命名规范："[组件] [操作]"（例如，“经纪商集成”、“风险验证框架”）

输出：边界清晰的原子组列表

步骤 4：阶段分配（MVP/MMP/MMR）

决策框架：

MVP 分配标准（至少满足 2 项）：

• 验证核心技术可行性
• 端到端工作流所必需
• 测试风险最高的假设
• 获取关键用户反馈
• 不存在可行的替代方案

MMP 分配标准：

• 首位客户/用户必需
• 生产部署所需
• 法规/合规要求
• 对安全性/可靠性/数据完整性至关重要
• 竞争中的基本功能

MMR 分配标准：

• 增强现有功能
• 拓展市场覆盖范围或使用场景
• 优化或提升性能
• 与可选系统集成
• 有助于推动采用率/留存率的锦上添花功能

输出：将每个原子组分配至 MVP、MMP、MMR-1、MMR-2 等阶段

步骤 5：优先级编号

优先级编号系统：

• 顺序优先级（1、2、3……）：必须按顺序完成
• 并行优先级（相同编号）：可同时执行

优先级规则：

1. 依赖驱动：优先级越高，依赖越少
2. 风险优先：尽早处理高风险/高不确定性事项
3. 权衡价值：平衡技术依赖关系与业务价值
4. 考虑资源：考虑团队规模和技能分布

并行化检查：

• 没有技术依赖关系？
• 涉及不同的代码区域？
• 有可用的独立团队成员？
• 没有共享基础设施瓶颈？
• 集成点定义明确？

如果以上均为是 → 分配相同的优先级编号

输出：按优先级编号的原子组

步骤 6：时间线估算

基于复杂度的估算：

• 复杂度 1：0.5-1 周
• 复杂度 2：1-2 周
• 复杂度 3：2-3 周
• 复杂度 4：3-4 周
• 复杂度 5：4-6 周

缓冲管理：

• 阶段级：增加 15% 缓冲
• 项目级：增加 25% 缓冲

时间线公式：

Total Time = Σ(Group Duration) / Parallel Tracks + Stage Buffers

输出：包含开始/结束日期和里程碑的甘特图

---

进度跟踪与状态管理

实施状态类别

状态	符号	含义	可变更性
COMPLETED	✅	已完整实施、测试并部署	IMMUTABLE
IN_PROGRESS	🚧	正在进行	评估影响
BLOCKED	⏸️	因依赖项或问题而无法继续	需要解决
PLANNED	📅	尚未开始，计划未来开展	可自由修改
MODIFIED	🔄	相较于原计划有所变更	记录变更
CANCELLED	❌	已从范围中移除	说明移除理由

状态跟踪要求

1. 每个原子组都必须有状态
2. 已完成的工作不可变更——不得在计划更新中修改
3. 对进行中的工作，必须谨慎评估影响
4. 只有计划中的工作可以自由调整
5. 所有状态变更都必须记录在变更日志中

---

变更管理协议

场景 A：新项目（创建初始计划）

适用情形：启动新项目，且此前没有计划

输入：

• 完整的需求文档集
• 项目背景（领域、团队规模、约束条件）
• 时间线约束（如有）

流程：

1. 执行步骤 1-6（从需求发现到时间线估算）
2. 将所有原子组标记为 PLANNED
3. 时间线从项目启动（第 1 周）开始

输出：PLAN-XXX_[project_name].md 版本 1.0

---

场景 B：已有计划时 BRD 发生变更（最关键）

适用情形：需求发生变化，且项目已在进行中

输入：

• 修改后的／新增的需求文档
• 现有实施计划
• 当前进度状态（哪些组已完成／正在进行）
• 当前日期（时间线重新起算点）

流程（关键——严格遵循）：

阶段 1：保留已完成的工作（不可变更）

1. 找出所有状态为 COMPLETED 的组
2. 标记为 LOCKED——不得修改
3. 规则：绝不删除、重命名或更改已完成工作的范围

阶段 2：评估进行中的工作

1. 找出所有状态为 IN_PROGRESS 的组
2. 评估：BRD 变更是否影响范围？是否应继续开展工作？
3. 记录评估结果
4. 决策：按原计划继续／调整范围／取消

阶段 3：分析 BRD 变更

1. 找出新增／修改／移除的需求
2. 将变更映射到原子组
3. 确定受影响的组以及需要新增的组

阶段 4：仅重新规划 PLANNED 工作

1. 仅修改状态为 PLANNED 的组
2. 可选操作：重新分组、调整优先级、新增、取消、修改范围
3. 重新进行依赖关系分析
4. 重新分配阶段

阶段 5：更新时间线

1. 从当前日期开始，而非项目开始日期
2. 计算剩余工作量
3. 重新估算剩余组
4. 更新预计结束日期
5. 计算时间线偏差

阶段 6：记录变更

1. 创建详细的变更日志
2. 记录 BRD 变更及其理由
3. 列出所有受影响的组
4. 说明对时间线的影响
5. 更新进度摘要

输出：更新后的 PLAN-XXX_[project_name].md（版本号递增）

关键规则：

• ✅ 保留所有已完成的工作
• ✅ 评估对进行中工作的影响
• ✅ 仅修改计划中的工作
• ✅ 从今天开始计算时间线
• ✅ 记录所有变更
• ❌ 绝不修改已完成的组
• ❌ 绝不从第 1 周重新开始计算时间线

---

场景 C：进度更新（BRD 未变更）

适用情形：更新计划进度，需求未发生变化

输入：

• 现有计划
• 进度更新（状态变更）
• 当前日期

流程：

1. 更新各组状态
2. 为已完成的组标注日期
3. 更新进度指标
4. 若进度与计划不同，则调整时间线
5. 找出受阻事项

输出：更新后的 PLAN-XXX_[project_name].md

---

执行模板

模板：实施计划文档结构

# Implementation Plan: [Project Name]

## Document Control

| Item | Details |
|------|---------|
| **Project Name** | [Name] |
| **Plan ID** | PLAN-01 |
| **Version** | X.0 |
| **Date** | YYYY-MM-DD |
| **Status** | [Active / Completed / On Hold] |
| **Owner** | [Name] |
| **Preparer** | [Name] |

### Document Revision History

| Version | Date | Author | Changes Made | Approver |
|---------|------|--------|--------------|----------|
| 1.0 | YYYY-MM-DD | [Name] | Initial plan creation | |
| | | | | |

---

## Executive Summary

**Project Goal**: [One-sentence description]
**Implementation Approach**: MVP → MMP → MMR staged releases
**Current Status**: [X% complete, Y of Z groups done]
**Timeline**: Start: YYYY-MM-DD, Projected End: YYYY-MM-DD, Duration: X weeks

**Key Milestones**:
- MVP: [Date] - [Status]
- MMP: [Date] - [Status]
- MMR-1: [Date] - [Status]

---

## Implementation Progress Summary
*(Include in updated plans)*

**Overall Status**: X% Complete (Y of Z groups completed)

**Completed Stages**:
- MVP (Completed: YYYY-MM-DD, Duration: X weeks)

**Current Stage**: MMP Phase 2 (Week 3 of 4)

**Completed Groups**: [List with dates]
**In Progress**: [List with status]
**Planned**: [List with start dates]
**Blocked**: [List with issues]
**Modified**: [List with reasons]
**Cancelled**: [List with justification]

**Timeline Adjustment**:
- Original End: YYYY-MM-DD
- Current Projected: YYYY-MM-DD
- Variance: +/- X weeks
- Reason: [Explain]

---

## Stage 1: MVP (Minimum Viable Product)

**Goal**: [What this stage validates]
**Status**: [NOT_STARTED / IN_PROGRESS / COMPLETED]
**Duration**: [Original X weeks] | Actual: [If complete]

**Success Criteria**:
- [ ] [Criterion 1]
- [ ] [Criterion 2]

**Exit Criteria**:
- [ ] Core functionality works end-to-end
- [ ] Riskiest assumptions validated

### Atomic Groups

#### Priority 1: [Group Name]
**Status**: [COMPLETED / IN_PROGRESS / BLOCKED / PLANNED / MODIFIED / CANCELLED]

**Requirements**:
- REQ-01: [Description]
- REQ-02: [Description]

**Dependencies**:
- [Dependency 1] (Status: Satisfied / Pending)

**Deliverable**: [Clear, testable output]

**Success Criteria**:
- [ ] [Criterion]

**Duration**: X weeks
**Completion Date**: [If COMPLETED]
**Notes**: [If MODIFIED/BLOCKED/CANCELLED]

---

## Timeline Visualization

```mermaid
gantt
    title Implementation Timeline
    dateFormat YYYY-MM-DD
    section MVP
    Group 1 (✅)  :done, mvp1, 2024-01-01, 2w
    Group 2 (🚧)  :active, mvp2, 2024-01-15, 2w
    Group 3 (📅)  :mvp3, 2024-01-29, 1w

---

变更日志

（更新后的计划中必须包含）

版本 2.0 - YYYY-MM-DD

更新原因：[BRD 变更 / 进度更新]

BRD 变更：

• BRD-004：新增 5 项需求（REQ-041 至 REQ-045）

影响分析：

• 已完成的工作：保持不变
• 正在进行的工作：[评估]
• 计划中的工作：[修改内容]

具体变更：

1. 组 X：已修改 - 新增 REQ-041、REQ-042
2. 组 Y：新增 - 为 REQ-043、REQ-044、REQ-045 创建
3. 组 Z：已取消 - 移除需求

时间线影响：由于新增组 Y，延长 2 周

---

可追溯性矩阵

原子组	需求	ADR	BDD 场景	状态
MVP 组 1	REQ-01, REQ-02	ADR-006	broker.feature	✅
MMP 组 5	REQ-041, REQ-042	ADR-008	risk.feature	🚧

---

## AI Assistant Usage Instructions

### How to Invoke This Skill

#### Scenario 1: Create Initial Implementation Plan

**Command Pattern**:

"使用 project-mgnt 技能为 [project name] 制定实施计划。

输入：

• 需求文档：[文件路径列表]
• 项目背景：[领域、团队规模、约束条件]
• 时间线约束：[如有]

按照 MVP/MMP/MMR 方法论创建 PLAN-XXX_[project_name].md。"

**Example**:

"使用 project-mgnt 技能为 inventory system 制定实施计划。

输入：

• 需求：{project_root}/docs/BRD/BRD-*.md（11 个文件）
• 背景：电子商务领域，5 名全职员工团队，先部署到 staging 环境
• 约束：MVP 在 <3 个月内完成

在 docs/08_IPLAN/ 中创建 PLAN-01_inventory_system.md。"

---

#### Scenario 2: Update Existing Plan (Requirements Changed)

**Command Pattern**:

"使用 project-mgnt 技能更新 [path] 中的实施计划。

输入：

• 已修改的 BRD：[变更文件列表]
• 现有计划：[path]
• 当前进度：[已完成/正在进行的组]
• 当前日期：[today]

重要：保留已完成的工作，仅修改计划中的工作。"

**Example**:

"使用 project-mgnt 技能更新 PLAN-01_inventory_system.md。

输入：

• 已修改内容：BRD-004 新增 5 项安全需求
• 计划：docs/08_IPLAN/PLAN-01_inventory_system.md v1.0
• 进度：MVP 已完成（组 1-4），组 5 正在进行（第 2/4 周）
• 日期：2024-02-01

创建 v2.0，并附上变更日志。"

---

### Expected Outputs

Every invocation MUST produce:

1. **Implementation Plan Document**
   - Filename: `PLAN-XXX_[project_name].md`
   - Location: User-specified or docs/08_IPLAN/
   - Format: Markdown following template
   - Versioning: v1.0, v2.0, v3.0...

2. **Required Sections**
   - Document Control section with project metadata and revision history
   - Executive Summary
   - Progress Summary (if update)
   - Stage breakdown (MVP, MMP, MMR)
   - Atomic groups with priorities, status, dependencies
   - Timeline visualization (Gantt chart)
   - Success metrics and exit criteria
   - Change log (if update)
   - Traceability matrix

3. **Change Log** (updates only)
   - BRD changes documented
   - Impact analysis
   - Specific group changes
   - Timeline impact

---

## Decision Frameworks

### Framework 1: MVP Scope Decisions

**Question**: Should this feature be in MVP?

**Key Questions**:
1. Does it test the core hypothesis?
2. Can we validate without it?
3. Is there a simpler alternative for MVP?
4. Does it validate high-risk assumption?
5. Is there a viable workaround?

**MVP Inclusion Criteria** (meet at least 2):
- [ ] Validates core technical feasibility
- [ ] Required for end-to-end workflow
- [ ] Tests riskiest assumption
- [ ] Generates critical user feedback
- [ ] No viable workaround exists

---

### Framework 2: Parallel vs Sequential

**Decision Checklist**:

如果满足以下条件，组 A 和组 B 可以并行：

• 没有代码依赖
• 涉及不同的文件/模块
• 没有共享数据库架构变更
• 没有共享基础设施
• 有可分配的独立团队成员
• 没有专业技能瓶颈
• 集成点定义清晰
• 返工风险低

如果有 8-10 项符合 = ✅ 并行（优先级相同） 如果有 5-7 项符合 = ⚠️ 谨慎并行 如果少于 5 项符合 = ❌ 按顺序执行

---

### Framework 3: Stage Gate Criteria

**MVP → MMP Gate**:

Exit Criteria (must meet ALL):
- [ ] Core functionality works end-to-end
- [ ] Riskiest assumptions validated
- [ ] User feedback collected
- [ ] Critical bugs logged
- [ ] Team consensus: hypothesis validated
- [ ] Product Owner sign-off

Proceed if:
- ✅ Hypothesis confirmed
- ✅ Technical feasibility proven
- ✅ Team confident

STOP if:
- ❌ Hypothesis rejected
- ❌ Technical infeasibility
- ❌ Cost exceeds value

---

### Framework 4: Update Impact Assessment

**Process**:

**Step 1: Categorize Change**
- Type: New / Modified / Removed / External dependency
- Size: Small (<5 req) / Medium (5-15) / Large (>15)
- Timing: Early (planned) / Mid (in-progress) / Late (completed)

**Step 2: Map to Groups**
- Completed groups: [Impact: None / Re-validation needed]
- In-progress groups: [Impact: Continue / Adjust / Stop]
- Planned groups: [Impact: Modify / Cancel / Reprioritize]

**Step 3: Impact Level**
- NONE: No action
- LOW: <1 week, adjust in place
- MEDIUM: 1-2 weeks, consider new group
- HIGH: >2 weeks, create new group
- CRITICAL: Invalidates group, cancel/redistribute

**Step 4: Decision Matrix**
- COMPLETED: No change (immutable) unless re-validation needed
- IN_PROGRESS: Continue / Adjust / Stop and replan
- PLANNED: Adjust / Modify / Cancel / Create new


---

## Adaptation Guidelines

### For Different Project Types

#### Infrastructure Projects
- **MVP**: Single environment (dev) with core infrastructure, automation scripts
- **MMP**: Production with full DR/HA, all IaC automated
- **Grouping**: By layer (network, compute, storage, security)
- **Critical Path**: IAM/Security → Network → Compute

#### API Development
- **MVP**: Core endpoints, happy-path only, simplified auth
- **MMP**: All endpoints, full error handling, OAuth, rate limiting
- **Grouping**: By resource/domain (Users API, Orders API)
- **Parallel**: Independent resources can develop simultaneously

#### ML/AI Systems
- **MVP**: Single model, manual training, sample data
- **MMP**: Automated pipeline, versioning, A/B testing, production serving
- **Grouping**: By ML pipeline stage (data prep, training, serving)
- **Critical Path**: Data quality → Model training → Serving

#### Web Applications
- **MVP**: Single-page prototype, core flow, desktop-only
- **MMP**: Responsive, cross-browser, all flows, production hosting
- **Grouping**: By user journey (registration, onboarding, core workflow)
- **Parallel**: Frontend + Backend (clear API contract)

---

### For Changing Requirements

#### New Features Added Mid-Project
1. Is it MVP validation? → Add to MVP (rare)
2. Essential for launch? → Add to MMP
3. Incremental value? → Add to MMR
4. Can wait? → Backlog

**Process**: Create requirement IDs, assess dependencies, fit in existing or create new group, assign stage/priority, update timeline, document in change log.

#### Features Removed/Descoped
1. In COMPLETED group? → Note descoping (already built)
2. In IN_PROGRESS? → Assess if should continue or stop
3. In PLANNED? → Cancel group or reduce scope

**Process**: Identify affected groups, remove requirements, cancel empty groups or adjust deliverables, update timeline, document rationale.

#### Priority Changes (Urgent Feature)
1. Verify dependencies allow earlier execution
2. Reprioritize to earlier priority number
3. Shift other groups later
4. Assess resource impact
5. Update timeline
6. Communicate trade-offs in change log

---

### For Different Team Sizes

#### Small Team (2-3 FTE)
- Limited parallelization (max 2 tracks)
- Focus on sequence over parallel
- Longer MVP/MMP stages
- Add 30-50% buffer for context switching

#### Medium Team (4-8 FTE)
- Good balance (2-3 parallel tracks)
- Specialization possible
- Maximize stage parallelization
- Clear ownership

#### Large Team (9+ FTE)
- High parallelization (4+ tracks)
- Specialized roles
- Risk: Communication overhead, integration complexity
- Strategy: Strict API contracts, daily syncs, strong PM


---

## Best Practices Compendium

### Common Pitfalls and Solutions

**Pitfall 1: MVP Scope Creep**
- Problem: MVP grows with "nice-to-have" features
- Solution: Ruthlessly apply MVP criteria, time-box MVP, create "MMP Backlog"

**Pitfall 2: Ignoring Dependencies**
- Problem: Parallelizing groups with hidden dependencies causes rework
- Solution: Thorough dependency mapping, define APIs before parallel work, daily syncs

**Pitfall 3: Modifying Completed Work**
- Problem: Updates change completed groups, causing confusion
- Solution: Mark completed as IMMUTABLE, create NEW groups for modifications

**Pitfall 4: Underestimating MMP Polish**
- Problem: Thinking MMP is "MVP + features" vs "production quality"
- Solution: Budget 50-100% more time for MMP, use strict "Definition of Done"

**Pitfall 5: No Clear Stage Gates**
- Problem: Moving MVP → MMP without validating success
- Solution: Explicit gate meetings, written exit criteria, PO sign-off required

---

### When to Deviate

**Acceptable Deviations**:
- Regulatory deadline: Compress stages, parallelize aggressively
- Market window: Skip some MMR features, focus on differentiators
- Technical debt crisis: Insert "Stabilization Sprint" between stages

**Never Deviate**:
- ❌ Skip MVP validation
- ❌ Launch MMP with known high-severity bugs
- ❌ Ignore completed work in updates
- ❌ Parallelize hard dependencies

---

### Lessons Learned

1. **MVP Always Takes Longer**: Add 25% buffer (50% for first-time team)
2. **MMP Needs More Testing**: Budget 30% of MMP for testing/QA
3. **Documentation Never "Done"**: Start in MVP, update continuously
4. **Velocity Improves**: First groups slower (learning), later groups faster (momentum)

---

## Validation Checklist

### For New Plans

**Completeness**:
- [ ] All requirements accounted for
- [ ] Dependencies identified and documented
- [ ] No circular dependencies

**Atomic Groups**:
- [ ] Groups independently testable
- [ ] Groups cohesive (related functionality)
- [ ] Size reasonable (1-4 weeks each)
- [ ] Descriptive names

**Stage Assignment**:
- [ ] MVP scope minimal (validation only)
- [ ] MMP includes launch essentials
- [ ] MMR is incremental (not launch-critical)

**Timeline**:
- [ ] Estimates based on complexity
- [ ] Buffers included at stage level
- [ ] Timeline realistic for team size

---

### For Updated Plans (CRITICAL)

**Immutability**:
- [ ] **All completed work preserved unchanged**
- [ ] Completion dates/deliverables unchanged
- [ ] No deletions/scope changes to completed groups

**Impact Assessment**:
- [ ] In-progress work assessed
- [ ] Only planned work modified
- [ ] New requirements mapped to groups

**Change Log**:
- [ ] BRD changes documented
- [ ] Impact analysis complete
- [ ] Specific changes listed with reasons
- [ ] Timeline impact calculated

**Timeline Continuity**:
- [ ] Timeline starts from current date
- [ ] Remaining work calculated accurately
- [ ] Variance explained

**Progress Tracking**:
- [ ] Progress summary accurate
- [ ] Status categories correct
- [ ] Completion percentage calculated

---

## Appendix

### Complexity Rating Scale

| Rating | Definition | Duration |
|--------|------------|----------|
| 1 | Trivial: Config change, minimal code | 0.5-1 week |
| 2 | Simple: Single component, clear requirements | 1-2 weeks |
| 3 | Moderate: Multiple components, some integration | 2-3 weeks |
| 4 | Complex: Cross-system integration, unknowns | 3-4 weeks |
| 5 | Very Complex: Architectural change, high uncertainty | 4-6 weeks |

### Glossary

**MVP**: Learning-focused first version to validate hypothesis. Functional but imperfect.

**MMP**: Market-ready first release with essential features and production quality. Can be sold.

**MMR**: Incremental feature releases after MMP. Production-quality, adds value.

**Atomic Group**: Independently deployable set of related requirements. 1-4 weeks, cohesive, testable.

**Critical Path**: Longest dependency chain determining minimum timeline.

**Dependency**: Prerequisite relationship between requirements or groups.

**Stage Gate**: Decision point between stages to validate completion.

**Priority Number**: Sequencing indicator. Same number = parallel execution.

**Status**: Current state (COMPLETED, IN_PROGRESS, BLOCKED, PLANNED, MODIFIED, CANCELLED).

**Change Log**: Document section tracking all modifications from previous version.

**Immutable**: Cannot be changed. Completed work is immutable in updates.

---

## Worked Example Reference

See examples directory for complete worked examples:

**Trading System v1.0**: Initial plan from 11 BRDs
- 13 atomic groups across MVP/MMP/MMR
- All groups PLANNED
- Timeline: 27 weeks from start

**Trading System v2.0**: Updated after BRD-004 changes
- MVP completed (Groups 1-4)
- Group 5 in progress
- New requirements added
- Timeline adjusted, change log included

*(Full examples in `../project-mngt/examples/`)*

---

## Skill Version History

**Version 1.0** (2025-01-03):
- Initial release
- Complete MVP/MMP/MMR framework
- Change management protocols
- Templates and decision frameworks
- Validation checklists
- Adaptation guidelines

---

## Support and Feedback

For issues or enhancements:
1. Document issue or suggestion
2. Provide scenario where skill didn't work
3. Suggest improvement with rationale

This skill evolves based on real-world usage and feedback.