05 · 项目管理（Software Project Management）

📅 预计 45 分钟　|　⭐ = 核心概念　|　📌 中英术语见文末
✍️ 配套练习：课程中心「软件工程」模块在线测验

5.1 项目管理：把"一锅粥"管成"流水席"

项目经理不是"催进度的人"

想象筹备一场婚礼：要租场地、订餐、写请柬、安排座次、管预算，任何一个环节掉链子，婚礼当天就会乱成一锅粥。软件项目管理就是软件开发的"婚礼策划"——用计划、组织、指挥、控制，让人（团队）、事（任务）、时（进度）、钱（成本）、物（工具）协调一致，按时按质交付。

软件项目为什么特别难管？因为软件开发是脑力密集工作，需求会变、人会被挖、bug 会隐身。管理学上有著名的软件危机根源之一就是"管理不善"——不是写不出代码，而是管不住项目。

项目管理的核心要素（俗称"4P"或更常见的几个 P）⭐：

要素	关心什么
人员（People）	团队怎么组织、角色怎么分工
产品（Product）	交付物是什么、范围有多大
过程（Process）	用什么开发模型和方法
项目（Project）	计划、进度、成本、风险怎么控制

💡 记忆口诀：项目管理四件套 = 人、物（产品）、法（过程）、控（项目）。

⚠️ 常见错误

以为项目管理 = 记考勤催进度：核心是计划与控制，包括范围、进度、成本、质量、风险五大维度。
小项目就不做管理：哪怕 3 人小项目，也至少要定任务清单、里程碑和分工，否则同样失控。

5.2 项目计划：先分解，再估算

工作计划 = WBS + 估算 + 排程

项目计划（project plan）是项目启动时最重要的文档，它回答：做什么、谁来做、做多久、花多少钱。制定计划的第一步是分解。

WBS（工作分解结构，Work Breakdown Structure）：把整个项目从大到小逐级分解成可执行、可核算的最小任务单元（工作包）。比如"开发图书管理系统"可分解为：

图书管理系统
├── 1. 需求分析（调研→SRS→评审）
├── 2. 设计（概要设计→详细设计）
├── 3. 编码（借还模块→查询模块→后台管理→测试）
├── 4. 测试（单元→集成→系统→验收）
└── 5. 交付部署

估算（estimation）：对每个工作包估工作量（人·日）和工期。常用方法：

类比估算：参照以往类似项目的经验。
分解估算：把大任务拆小后逐个估算再累加。
专家判断 / 三点估算：乐观值、悲观值、最可能值加权平均。

估算出来后，结合资源（几个人、几台机）就能排出进度表。

一个估算小例子：需求分析工作包拆成"调研访谈 2 人·日 + 编写 SRS 2 人·日 + 评审修改 1 人·日"，共 5 人·日；团队有 1 名需求分析师，则工期约 5 天；若他同时被别的任务占用，就要相应顺延。估算的粒度越细，排程越准——这正是先做 WBS 的原因。

⚠️ 常见错误

WBS 分解粒度不当：太粗没法控制，太细管理成本高。到"一个人几天能干完"的工作包最合适。
估算只给一个数：工程上常用区间（如 3~5 人·日），单一乐观值几乎必然低估。

5.3 进度安排与甘特图 ⭐

甘特图：一眼看清"谁、什么时候、做什么"

进度安排（scheduling）是把任务按时间排开，明确先后关系（哪些必须在前，哪些可以并行）和里程碑（milestone，阶段性的重要节点，如"SRS 评审通过"）。

甘特图（Gantt chart）是表示进度的最直观工具：横轴是时间，纵轴是任务，每项任务画一条横向条形，条的长度表示工期，条的位置表示起止时间，通过条形前后关系能看出任务的依赖与并行。

任务                第1周  第2周  第3周  第4周  第5周
需求分析            ██████
概要设计                    ██████
编码                            ██████ ██████
测试                                        ██████

甘特图读图要点：

条形起点 = 最早开始时间，终点 = 最早结束时间。
重叠的条形 = 可并行的任务；首尾相接 = 有先后依赖。
里程碑用菱形/标志标出，用于检查项目是否按节点推进。

关键路径法（CPM）是更精细的工具：在依赖网络里找出一条最长的、决定整个项目工期的路径——这条路径上的任务一旦延期，整个项目就延期，叫关键路径（critical path）。非关键路径上的任务有"浮动时间"，可以适度延迟而不影响总工期。

💡 记忆口诀：甘特图 = 时间轴上的任务条；关键路径 = 决定总工期的"命脉链"，一延全延。

⚠️ 常见错误

把甘特图当成静态死图：进度一变就要更新，它是控制工具不是装饰品。
只盯进度不看依赖：所有任务并行排、忽略先后依赖，甘特图就失真了。
搞混"里程碑"与"任务"：里程碑是时间点/检查节点（没有工期），任务是时间段（有工期）。

5.4 风险管理：先想到最坏的情况 ⭐

风险 = 坏事发生的"概率 × 影响"

项目里总有些"可能发生但不确定"的坏事：核心成员离职、需求大改、技术选型踩坑、服务器宕机。风险管理就是提前识别它们、评估它们、给它们安排对策。

风险管理四步 ⭐：

识别风险：列出潜在风险（人、技术、需求、进度、成本类）。
评估风险：打分 = 可能性 × 影响程度，给风险排优先级。
制定对策：针对高风险项提前行动。
监控与应对：持续跟踪，风险变成现实时执行预案。

常见的风险应对策略：

策略	做法	例子
规避	改变计划让风险不发生	不选没人会的冷门框架
减轻	降低概率或影响	关键模块双人结对，降低离职影响
转移	把风险外包给他人	用云服务商承担机房运维风险
接受	明知有风险但成本划算，留预算兜底	预留 20% 缓冲工期应对需求变更

💡 记忆口诀：风险值 = 概率 × 影响；对策四选一：避、减、转、接。

⚠️ 常见错误

把风险当"坏消息"藏着：风险管理要提前、透明，识别得越晚，对策空间越小。
评估只凭感觉：要量化（概率、影响分级打分），否则无法排优先级。
只识别不行动：列了风险清单却不对策，等于没做。

5.5 团队协作：人是项目的发动机

分工、沟通、工具，一个都不能少

再好的计划也要人执行。团队协作是项目管理的落地点，核心三件事：

① 角色分工。一个典型软件团队包含：项目经理（管进度与资源）、产品/需求分析（对接用户定需求）、架构师（定技术方案）、开发（写代码）、测试（保质量）、运维（管部署上线）。敏捷团队中常强调自组织与跨职能。

② 沟通机制。沟通不畅是项目最大的隐性杀手。常用机制：每日站会（同步进展与障碍）、定期评审（向干系人汇报）、文档沉淀（设计文档、接口文档、会议纪要）。关键原则是"重要的沟通落到文字"，避免口头约定造成信息失真。

③ 协作工具。现代软件团队几乎离不开：

版本控制：Git 是事实标准，多人并行开发靠分支合并，代码有历史、可回溯。
任务看板：Trello/Jira 等，用看板（Kanban）可视化任务状态：待办→进行中→已完成。
代码评审：合并代码前由他人审查，提前发现缺陷并分享经验。
CI/CD 流水线：代码提交后自动构建、测试、部署（见第 1 讲 DevOps）。

团队协作的本质：目标对齐 + 透明沟通 + 工具提效。技术债和人治窟窿，都是协作的隐性成本。

干系人与沟通计划

项目里所有"影响项目或受项目影响"的人都是干系人（stakeholder）：用户、客户、上级、团队成员、运维。不同干系人关心的东西不同——用户关心功能，客户关心预算与工期，团队成员关心任务与资源。管理干系人的第一步是识别，第二步是按需沟通。

沟通计划回答四个问题：谁需要知道什么、多久知道一次、通过什么渠道、谁负责传达。例如：每日站会同步团队成员，每周周报汇报上级，每轮迭代末评审会汇报客户。没有沟通计划，要么信息轰炸、要么没人知情，项目便容易失控。

⚠️ 常见错误

沟通只靠口头、不留记录：需求变更、接口约定必须落到文档/工单，否则事后扯皮。
多人直接改同一份代码文件：没有版本控制或不会用分支，改动互相覆盖，这是协作第一大事故源。
把评审当走流程：代码评审和需求评审若流于形式，等于把缺陷留到更贵的时候修。

📌 双语术语表（本讲）

中文	English	记忆点
项目计划	project plan	做什么/谁/多久
工作分解结构	WBS	任务逐级分解
估算	estimation	估工作量与工期
里程碑	milestone	时间节点检查点
甘特图	Gantt chart	横时间纵任务
关键路径	critical path	决定总工期的链
风险	risk	概率 × 影响
风险管理	risk management	识别→评估→对策→监控
规避 / 减轻 / 转移 / 接受	avoid / mitigate / transfer / accept	风险四策略
版本控制	version control	Git 等
代码评审	code review	合并前审查
每日站会	daily stand-up	15 分钟同步

⭐ 本讲考点清单

项目管理要素：人员、产品、过程、项目（4P）。
WBS：项目逐级分解为可执行工作包。
甘特图：横轴时间、纵轴任务、条形表工期；里程碑是节点不是任务。
关键路径：最长的任务链，决定总工期，一延全延。
风险 = 概率 × 影响；四策略：规避、减轻、转移、接受。
团队协作三件套：角色分工、沟通机制（落到文字）、协作工具（Git/看板/评审/CI）。