软件项目管理十大知识领域

项目的特点

1. 临时性

   • 本质：项目有明确的起点和终点（如：开发一款APP的周期为6个月）。

   • 例外：项目成果可能持续运营（如：APP上线后的维护转为运营工作）。

2. 独特性

   • 案例：即使开发相似功能的电商系统，因客户需求、技术栈不同，每个项目仍唯一。

   • 管理重点：避免直接套用历史方案，需定制化需求分析。

3. 渐进明细

   • 实施方法：

     • 原型迭代：先交付MVP（最小可行产品），再逐步完善。

     • 滚动式规划：近期任务详细规划，远期任务仅做概要计划。

软件项目管理的四大变量

四大变量（范围、进度、成本、质量）的关联与冲突

经典三角约束：范围扩大→成本增加或进度延长；压缩进度→成本上升或范围缩减。

项目管理的五个要素：技术、方法、团队建设、信息、沟通

判断项目成功的因素包括：项目范围、进度计划、项目成本以及客户满意度

项目管理的五个过程组

启动过程组、规划过程组、执行过程组、监控过程组、收尾过程组

项目总计划包括范围计划、工作范围定义、活动定义、资源需求、资源计划、活动排序、费用估算、进度计划及费用计划；项目辅助计划包括质量计划、沟通计划、人力资源计划、风险计划、采购计划。

十大知识领域

整范进，成资质，沟风采，相全部。

一、项目集成管理

目标：协调所有知识领域的工作，确保项目从启动到收尾的整体成功。

项目章程

• 项目目的：为什么做这个项目？（如“提升客户满意度30%”）。

• 项目经理职权：明确PM的资源调配权限。

• 里程碑计划：高层级时间框架（“Q1完成原型设计，Q3完成测试，Q4正式发布”。）。

• 两大作用：

  • 合法性（Legitimacy）

    • 宣告项目正式存在，获得组织认可，避免资源争夺或优先级冲突。

    • 通常需由发起人（Sponsor）签署生效。

  • 授权性（Authorization）

    • 赋予项目经理正式权力，明确其可调用的资源和决策范围，避免后续推诿。

指定项目管理计划

1. 基准计划（Baselines）

• 定义：经批准的、不可随意变更的项目基准，用于衡量绩效和偏差。

• 核心基准：

  • 范围基准（Scope Baseline）：

    • 包括项目范围说明书（做什么）、WBS（工作分解结构）和WBS词典（详细任务说明）。

    • 示例：电商系统开发项目的WBS分解到“用户登录模块开发”层级。

  • 进度基准（Schedule Baseline）：

    • 经批准的项目进度计划（甘特图或里程碑图），含关键路径。

    • 示例：“用户测试阶段必须在2025年8月15日前完成”。

  • 成本基准（Cost Baseline）：

    • 分阶段的预算分配（如S曲线），包括应急储备。

    • 示例：总预算500万元，其中开发阶段占60%。

2. 辅助计划（Subsidiary Plans）

• 定义：管理特定领域活动的子计划，通常包括：

  子计划	核心内容
  质量管理计划	质量指标（如缺陷率≤1%）、测试流程、验收标准。
  沟通管理计划	干系人沟通频率（如周报）、渠道（邮件/会议）。
  风险管理计划	风险分类、责任人、应对策略（规避/减轻）。
  采购管理计划	供应商选择标准、合同类型（固定总价/工时）。
  资源管理计划	团队角色分工、设备/工具分配。

• 示例：

  • 风险计划中定义“第三方延迟”为高风险，应对措施为“签订备用供应商协议”。

变更管理流程（Change Management Process）

• 关键要素：

  • 变更控制委员会（CCB）：明确成员（如PM、发起人、技术负责人）。

  • 审批阈值：不同级别变更的审批权限（如≤5万元由PM批准，>5万元需CCB）。

  • 流程步骤：申请→评估影响→审批→更新基准。

• 示例：

  • 需求变更“增加多语言支持”需评估对进度和成本的影响，CCB投票通过后调整基准。

变更控制流程（Change Control Process）

黄金规则：

• 所有变更必须书面申请（禁止口头承诺）。

• 基准变更需CCB批准（普通变更PM可决策）。

三、常见问题与解决策略

1. 变更失控

• 现象：频繁未经审批的变更导致范围蔓延。

• 解决：

  • 建立变更控制委员会（CCB）。

  • 使用需求跟踪矩阵确保变更可追溯。

2. 计划与实际脱节

• 原因：项目管理计划未及时更新。

• 预防：

  • 每月重新基线化（Rebaselining）。

  • 利用配置管理系统管理版本。

四、考试与实战要点

1. 高频考点

• 项目章程的批准人：必须是项目发起人（Sponsor），非PM。

• 变更流程顺序：申请→评估→审批→执行→更新。

• 收尾文档：经验教训总结属于组织过程资产。

2. 一句话原则

• 章程是项目宪法，计划是执行蓝图，变更是管控核心。

• 整合管理的本质：平衡范围、进度、成本、质量的冲突。

二、项目范围管理

目标：明确项目边界，确保团队和干系人对“做什么/不做什么”达成一致，防止范围蔓延（Scope Creep）。

二、核心工具与技术详解

1. 需求收集方法

工作分解结构（Work Breakdown Structure, WBS）详解

定义：以可交付成果为导向的层级化项目任务分解方法，将项目拆解为可管理的小单元（工作包）。

WBS的核心作用

• 明确项目范围：防止遗漏或模糊的任务。

• 分配责任：每个工作包对应具体负责人。

• 估算成本与时间：基于工作包细化预算和进度。

• 控制变更：作为范围基准，评估变更影响。

WBS的分解原则

(1) 100%规则

• 父级任务的子任务必须100%覆盖其范围，且不包含额外内容。

  • ✅ 正确示例：

    复制

    “网站开发” → “前端开发” + “后端开发” + “数据库设计”  

  • ❌ 错误示例：

    复制

    “网站开发” → “前端开发” + “后端开发” + “营销策划”  

(2) 可交付成果导向

• 分解依据是成果（如“用户登录模块”），而非活动（如“编写代码”）。

(3) 工作包（Work Package）层级

• 最底层任务需满足：

  • 可估算：能分配时间和成本（如“设计登录页面：5人天”）。

  • 可分配：能指定唯一负责人（如“前端团队”）。

  • 可测量：完成标准明确（如“通过UI验收测试”）。

WBS的分解步骤

1. 确定顶层交付物：

   • 项目最终产出（如“开发一款电商APP”）。

2. 逐层分解：

   • 按功能、阶段或子系统拆分（如“用户模块”“订单模块”）。

3. 细化到工作包：

   • 最底层任务需满足“可管理、可交付”（如“用户注册功能开发”）。

4. 编号与审核：

   • 为每个任务分配唯一ID（如1.1.2），团队确认无遗漏。

4. WBS的两种常见形式

(1) 树形图（层级结构）
    A[电商APP开发] --> B[用户模块]
    A --> C[订单模块]
    A --> D[支付模块]
    B --> B1[注册功能]
    B --> B2[登录功能]
    B1 --> B1a[UI设计]
    B1 --> B1b[后端接口开发]

(2) 表格形式

WBS的实用技巧

• 控制层级：通常3~5层，过大项目可拆分子项目。

• 避免过度分解：工作包建议80小时（2周）内完成。

• 与工具结合：

  • MS Project/Excel：绘制WBS并关联进度和资源。