第4章：整合管理

class ProjectCharter {
    // 核心属性
    String projectPurpose;      // 项目目的
    String businessCase;        // 商业论证
    Authority pmAuthority;      // PM 权限
    Stakeholder[] stakeholders; // 关键相关方
    Constraints constraints;    // 约束条件
    Assumptions assumptions;    // 假设条件
    Budget initialBudget;       // 初始预算
    Milestone[] milestones;     // 高层级里程碑
}

项目启动 ──→ 项目执行 ──→ 项目收尾 ──→ 运营阶段
   │           │           │           │
   └─ 早期效益 └─ 过渡效益 └─ 交付效益 └─ 持续效益

焦点小组              vs            一对一访谈
├─ 群体动力学                      ├─ 深度挖掘
├─ 想法碰撞                        ├─ 隐私保护
├─ 共识形成                        ├─ 详细信息
└─ 效率较高                        └─ 无群体压力

高 │ 强迫          协作
关 │ (竞争)        (问题解决)
注 │
自 │     妥协
身 │   (中间路线)
利 │
益 │ 回避          迁就
低 │ (撤退)        (包容)
   └────────────────────
     低    关注他人利益    高

项目章程结构
│
├── 项目信息
│   ├── 项目名称
│   ├── 项目编号
│   └── 批准日期
│
├── 项目描述
│   ├── 目的与理由
│   ├── 高层级需求
│   └── 项目边界
│
├── 可交付成果
│   ├── 主要交付物
│   └── 验收标准
│
├── 项目组织
│   ├── 项目经理任命
│   ├── 权限级别
│   └── 关键相关方
│
└── 约束与假设
    ├── 预算约束
    ├── 时间约束
    ├── 资源约束
    └── 关键假设

def integrate_plans(subsidiary_plans):
    """整合各子计划的逻辑"""
    integrated_plan = ProjectManagementPlan()

    # 检查依赖关系
    for plan in subsidiary_plans:
        check_dependencies(plan, other_plans)

    # 解决冲突
    conflicts = identify_conflicts(subsidiary_plans)
    for conflict in conflicts:
        resolution = resolve_conflict(conflict)
        apply_resolution(resolution)

    # 优化资源分配
    optimize_resource_allocation(subsidiary_plans)

    # 同步时间线
    synchronize_timelines(subsidiary_plans)

    return integrated_plan

范围基准 ←→ WBS
    ↓         ↓
活动清单 ← 活动定义
    ↓         ↓
资源需求 → 资源计划
    ↓         ↓
成本估算 → 成本基准
    ↓         ↓
进度计划 → 进度基准

绩效测量基准（PMB）= 范围基准 + 进度基准 + 成本基准

PMB 用途：

- 挣值管理（EVM）的基础
- 绩效报告的参照标准  
- 变更影响评估的基准
- 项目健康度的衡量标准

初始阶段：高层级计划
    ↓
规划深化：详细子计划
    ↓
执行过程：持续更新
    ↓
变更管理：受控调整

时间轴 →
|←  当前  →|←  近期  →|←  中期  →|←  远期  →|
|  1-2 周  |  3-8 周  | 2-6 个月 |  6+ 个月 |
|  100%    |   80%    |   50%    |   20%    |
|  详细度  |  详细度  |  详细度  |  详细度  |

Gate 0    Gate 1    Gate 2    Gate 3    Gate 4
  ↓         ↓         ↓         ↓         ↓
构想 → 可行性 → 开发 → 测试 → 发布
  ↑         ↑         ↑         ↑         ↑
粗略     概念性    详细      执行      收尾
计划      计划     计划      调整      总结

[项目代码]-[类型]-[模块]-[版本]-[日期]
PMP2024-DOC-REQ-V1.2-20240315

其中：

- 项目代码：唯一项目标识
- 类型：DOC/CODE/TEST/CONFIG等
- 模块：功能模块或子系统
- 版本：主版本.次版本.修订号
- 日期：YYYYMMDD格式

{
  "ci_id": "PMP2024-DOC-REQ-001",
  "name": "需求规格说明书",
  "version": "2.1.0",
  "status": "已批准",
  "owner": "张三",
  "created": "2024-01-15",
  "modified": "2024-03-15",
  "dependencies": ["设计文档", "测试计划"],
  "baseline": "BL-2024Q1",
  "storage_location": "/docs/requirements/"
}

草稿 → 评审中 → 已批准 → 基线化 → 变更中 → 已废弃
 ↓       ↓        ↓        ↓        ↓        ↓
可编辑  只读    受控变更  只读    限制编辑   归档

master    ────●────────●───────────●───→
              ↑        ↑           ↑
release   ───┼────●───┼───────●───┤
              ↑    ↓   ↑       ↓   ↑
develop   ●──┼────┼───┼───●───┼───┼───→
          ↓  ↑    ↓   ↑   ↓   ↑   ↑
feature   ●──●    ●───●   ●───●   ↑
                                  ↑
hotfix                            ●───●

□ 所有配置项都有唯一标识
□ 版本历史完整可追溯
□ 变更都经过授权批准
□ 基线内容未被非授权修改
□ 文档与代码版本匹配
□ 测试覆盖所有配置项
□ 配置数据库信息准确
□ 备份和恢复程序有效

Git 工作流           →  项目变更流程
git add             →  提交变更请求
git commit          →  记录变更内容
pull request        →  变更评审
code review         →  变更影响分析
merge               →  批准并实施变更

     [变更请求提交]
           ↓
     [记录变更请求]
           ↓
     [初步影响评估]
           ↓
    ┌─────────────┐
    │ CCB 评审会议 │
    └─────────────┘
           ↓
    ┌─────────────┐
    │   批准？    │
    └─────────────┘
         ／  ＼
       是      否
       ↓        ↓
  [实施变更]  [记录拒绝原因]
       ↓        ↓
  [更新文档]  [通知申请人]
       ↓
  [验证变更]
       ↓
  [关闭变更]

class ChangeImpactAnalysis:
    def analyze(self, change_request):
        impacts = {
            'scope': self.analyze_scope_impact(change_request),
            'schedule': self.analyze_schedule_impact(change_request),
            'cost': self.analyze_cost_impact(change_request),
            'quality': self.analyze_quality_impact(change_request),
            'risk': self.analyze_risk_impact(change_request),
            'resources': self.analyze_resource_impact(change_request)
        }

        # 计算综合影响分数
        total_impact = self.calculate_total_impact(impacts)

        # 生成建议
        recommendation = self.generate_recommendation(total_impact)

        return ChangeImpactReport(impacts, recommendation)

变更前关键路径： A → B → C → D (总工期 100天)
变更后关键路径： A → B' → E → C → D (总工期 115天)

影响分析：

- 关键路径变化：新增活动 E
- 工期影响：延长 15天
- 浮动时间变化：非关键路径浮动减少
- 资源冲突：需重新平衡资源

直接成本影响
├─ 人工成本增加
├─ 材料成本增加
├─ 设备成本增加
└─ 外包成本增加

间接成本影响
├─ 管理成本增加
├─ 机会成本损失
├─ 延期罚款
└─ 品牌价值损失

预防成本 < 评估成本 < 内部失败成本 < 外部失败成本

1:10:100 规则：

- 设计阶段修复：$1
- 开发阶段修复：$10
- 生产阶段修复：$100

           影响
      低    中    高
概 高  中    高   极高
率 中  低    中    高
  低  极低   低    中

{
  "change_id": "CHG-2024-001",
  "submission_date": "2024-01-15",
  "requester": "张三",
  "description": "增加实时数据同步功能",
  "category": "功能增强",
  "priority": "高",
  "impact_analysis": {
    "scope": "新增3个用户故事",
    "schedule": "延期2周",
    "cost": "增加15000元",
    "risk": "可能影响系统稳定性"
  },
  "status": "已批准",
  "approval_date": "2024-01-20",
  "implementation_date": "2024-02-01",
  "verification_date": "2024-02-05"
}

□ 可交付成果验收
  □ 功能测试完成
  □ 性能测试通过
  □ 用户验收测试（UAT）
  □ 签署验收文件

□ 文档移交
  □ 用户手册
  □ 技术文档
  □ 运维手册
  □ 源代码和配置

□ 知识转移
  □ 培训完成
  □ 支持流程建立
  □ 联系人清单更新

□ 财务收尾
  □ 最终付款处理
  □ 预算对账
  □ 成本报告

□ 资源释放
  □ 团队成员释放
  □ 设备归还
  □ 许可证转移
  □ 访问权限回收

□ 经验教训
  □ 经验教训会议
  □ 文档记录
  □ 知识库更新
  □ 最佳实践提炼

SPI = EV / PV
SV = EV - PV

里程碑达成率 = 实际完成里程碑 / 计划里程碑 × 100%
平均延迟天数 = Σ(实际完成日 - 计划完成日) / 活动数

风险类型    | 识别数 | 发生数 | 应对成功率 | 影响程度
技术风险    |   15   |   3    |   100%     |   低
进度风险    |   12   |   5    |    80%     |   中
成本风险    |    8   |   2    |   100%     |   低
资源风险    |   10   |   4    |    75%     |   高
外部风险    |    5   |   1    |   100%     |   低

类别        | 问题描述          | 根本原因      | 改进建议
沟通        | 需求理解偏差      | 缺乏确认机制  | 建立需求评审会
计划        | 估算偏差较大      | 经验不足      | 使用三点估算
执行        | 进度延迟          | 资源冲突      | 优化资源分配
监控        | 问题发现滞后      | 监控频率低    | 增加检查点

指标类别    | KPI            | 目标值 | 实际值 | 状态
范围        | 需求完成率    | 100%   | 98%    | 🟢
进度        | SPI            | ≥1.0  | 0.95   | 🟡
成本        | CPI            | ≥1.0  | 1.02   | 🟢
质量        | 缺陷密度      | <5/KLOC| 3.2    | 🟢
满意度      | CSAT           | >4.0   | 4.3    | 🟢
团队        | 人员流失率    | <10%   | 8%     | 🟢

我是一个PMP考生，正在学习变更管理。请扮演项目经理，分析以下变更请求：

项目背景：

- 项目：电商平台升级
- 当前阶段：开发阶段60%完成
- 团队规模：15人
- 预算：100万元
- 计划工期：6个月（已进行3.5个月）

变更请求：
客户要求增加"社交分享"功能模块

请分析：

1. 对范围的影响
2. 对进度的影响
3. 对成本的影响
4. 对质量的影响
5. 新增风险
6. 你的建议

# AI 提示词示例
prompt = """
创建一个变更请求决策树，包含以下决策点：

1. 变更是否符合项目目标？
2. 变更的成本效益比是否合理？
3. 是否有足够资源实施变更？
4. 变更对关键路径的影响？
5. 相关方是否支持？

为每个路径提供建议的行动方案。
"""

角色设定：

- 项目发起人：关注商业价值
- 项目经理：关注三重约束平衡
- 技术负责人：关注技术可行性
- QA经理：关注质量影响
- 财务经理：关注预算影响

让 AI 分别从每个角色出发，对变更请求发表意见。