project-mngt（项目管理）

Expected Outputs

Every invocation MUST produce:

1. Implementation Plan Document

- Filename: PLAN-XXX_[project_name].md - Location: User-specified or docs/IMPL/ - Format: Markdown following template - Versioning: v1.0, v2.0, v3.0...

1. 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

1. 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:

Group A + Group B can be parallel if:

*    No code dependencies
*    Different files/modules
*    No shared database schema changes
*    No shared infrastructure
*    Separate team members available
*    No specialized skill bottleneck
*    Integration points clearly defined
*    Low rework risk

If 8-10 checks = ✅ PARALLEL (same priority) If 5-7 checks = ⚠️ PARALLEL with caution If <5 checks = ❌ SEQUENTIAL

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

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_root}/.claude/skills/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.