软件项目管理

项目管理概述

软件项目管理的提出源于20世纪70年代中期的美国：美国国防部研究发现，70%的软件开发项目问题（如延期、超支、质量不达标）源于管理不善而非技术，因此软件开发领域开始重视管理环节。但到20世纪90年代中期，项目管理不善的问题仍普遍存在。

其特殊性体现在两点：

• 软件是纯知识产品，开发进度、质量、生产效率难以估计和保证；
• 软件系统复杂性高，开发过程中风险难以预见和控制。

软件项目管理的对象是软件工程项目，覆盖整个软件工程过程。核心是在技术工作开始前就对项目的工作范围、风险、资源（人、软硬件）、任务、里程碑、成本、进度等进行预先计划，并在整个软件生命周期中持续执行，直至项目结束。

管理目标是确保项目按预定成本、进度、质量完成，核心是对人员（People）、产品（Product）、过程（Process）、项目（Project）四大要素的分析与管理。后续将围绕进度、配置、质量和风险管理展开介绍。

软件进度管理

进度管理是为确保项目按期完成的管理过程，核心是对活动的计划与控制，包括6个环节：活动定义、活动排序、活动资源估计、活动历时估计、制定进度计划、进度控制。

1. 工作分解结构（WBS）
   软件项目因复杂庞大，需层层分解为可管理的小任务，即“项目→任务→工作→日常活动”。WBS是按可交付成果导向对项目要素的分组，每下降一层代表更详细的工作定义，是制定进度计划、资源需求、成本预算等的基础。
   

   • 工作包：WBS树形结构最底层，是最低层次的可交付成果，由唯一主体负责。
   • 分解方式：按产品物理结构、功能、实施过程、实施单位、目标等分解。
   • 基本要求：
     • 工作包需可控、可管理，不过于复杂；
     • 分解层次不超过6层；
     • 每个工作包有明确交付成果；
     • 每个任务有明确定义的完成标准；
     • 有利于责任分配。

2. 任务活动图
   工作分解后需明确活动的前驱（开始前必须发生的事件）、持续时间、必须完成日期、里程碑等，以确定活动间的先后顺序，形成任务活动图。它是进度管理、成本管理的基础，常用甘特图展示和管理。
   

3. 活动历时估算
   
   
   
   

软件配置管理（SCM）

SCM是标识、组织和控制软件修改的技术，应用于整个软件工程过程。其目标是管理变更（标识、控制、确保正确实现、报告变更），以减少错误、提高生产效率。核心内容包括：

1. 版本控制
   对软件开发中程序代码、配置文件、文档等的变更进行管理，核心功能是：

   • 追踪变更：记录“何时、何人、修改了什么”，每次变更后版本号递增；
   • 支持并行开发：解决多人协同的版本同步、通信问题，通过分支与合并处理不同版本的Bug修正。

2. 变更控制
   目的不是阻止变更，而是确保变更有序进行。引发变更的因素包括：

   • 外部变更（如客户修改需求）：最难处理，因IT项目需求变更概率高，后期变更工作量大；
   • 内部变更（如为修复测试错误修改源码或设计）。

3. 配置项
   
   
   

软件质量管理

软件质量指软件与明确/隐含需求的一致程度，具体表现为符合功能性能需求、开发标准及隐含特征的程度。影响因素可分为三组：产品运行、产品修改、产品转移。

1. 软件质量保证(Software Quality Assurance,SQA)
   建立有计划、系统的方法，确保项目遵循标准、步骤和实践，核心是“过程可见”，通过评审和审计验证合规性。

   • 目标：
     • 事前预防缺陷（而非事后检查）；
     • 尽早捕获缺陷，避免扩散；
     • 作用于过程而非最终产品；
     • 贯穿所有活动。
   • 主要任务：
     • 审计与评审：审计工作产品、工具、设备是否符合标准；评审活动是否与预定过程一致；
     • 报告：记录结果并发布，需保证SQA与高层直接沟通、向工程组发布、向关心质量者发布；
     • 处理不符合问题：及时向相关人员及高层反映问题。

2. 软件质量认证
   检验企业整体质量水平，评估其设计、开发、生产符合质量要求软件的能力，主要标准包括：

   • ISO 9000：国际标准化组织制定的系列标准，其中ISO 9001:1994用于证实组织满足顾客及法规要求的能力，覆盖设计、开发等20项质量要求；
   • CMM（能力成熟度模型）：卡内基梅隆大学软件工程研究所研制，是软件生产过程及企业成熟度等级认证标准，我国企业多采用。

软件风险管理

风险管理是软件项目管理的重要内容，目标是预防风险（风险指可能影响预算、进度的问题，若发生可能导致延期、超支甚至项目失败）。核心流程是：辨识风险→评估概率与影响→制定管理规划。

主要风险管理体系包括：

• Boehm体系：分为风险估计（辨识、分析、排序）和风险控制（计划、处理、监督），偏重理论；
• Charette体系：分为风险分析（辨识、估计、评价）和风险管理（计划、控制、监督），与Boehm体系接近，偏重理论；
• CMU-SEI体系：基于实践的全面管理体系，包括SRE、CRM（持续风险管理）、TRM（团队风险管理），与CMM配合，将需求方纳入风险管理要素。

易混淆点解读

第4项（管理风险）和第5项（预算风险）之所以被归类为商业风险而非项目风险，核心在于它们的根源和影响层面不同。

简单来说：

• 项目风险威胁的是“项目”的成功（能否按时、按预算、按范围完成）。
• 商业风险威胁的是“产品”的成功和业务的生存能力（项目完成后，它能否带来商业价值，能否存活下去）。

下面我们来详细拆解第4和第5项：

第4项：管理风险 - 由于重点转移或人员变动而失去上级管理部门的支持

为什么是商业风险？

1. 根源在于商业战略和优先级的变化：失去支持通常不是因为项目经理管理不善，而是因为公司整体的商业环境、战略方向或高层领导团队发生了变化。例如：

   • 公司被收购/合并：新东家可能有不同的战略，原项目可能不再重要。
   • 市场出现新机遇或威胁：公司必须将资源和注意力转移到更紧迫的事情上。
   • 关键高管（如CEO、赞助人）离职：新上任的领导可能有自己的一套规划，不再认可前任支持的项目。

2. 影响的是产品的“生存”而不仅仅是“交付”：即使项目团队排除万难，成功交付了系统，但失去了管理层的支持意味着：

   • 产品无法获得持续的运营和维护资金。
   • 在推广阶段得不到必要的组织资源和政治支持。
   • 最终的成果无人认可，也无法被有效采用。
   • 这直接导致系统“死亡”——虽然被开发出来了，但成了一个没人用、没人维护的“僵尸系统”，无法实现其商业价值。这正是对系统生存能力的致命威胁。

作为对比的项目风险例子：“项目团队内部沟通不畅”或“技术骨干离职”是项目风险，因为它们直接影响项目本身的交付，但不一定意味着产品本身没有商业价值。

第5项：预算风险 - 开发过程没有得到预算或人员的保证

为什么是商业风险？

1. 根源在于商业价值的再评估和投资决策：预算被削减或撤销，根本原因通常是商业层面认为该项目的投资回报率（ROI）不再吸引人，或者有更优先的投资选项。这不是项目超支（那是项目风险），而是商业投资意愿的撤销。例如：

   • 经重新评估，发现项目预期收益无法实现。
   • 公司整体财务紧缩，需要砍掉“非核心”项目。
   • 竞争对手抢先发布了类似产品，使得本项目即使完成也失去了市场先机。

2. 影响的是项目存在的“根本理由”：预算是项目存在的“氧气”。撤销预算不是一个可管理的执行问题，而是商业上对项目死刑的宣判。它直接导致：

   • 项目彻底终止、夭折。
   • 系统根本无法被开发出来，更谈不上后续的运营和生存。

作为对比的项目风险例子：“项目成本超支”是典型的项目风险。它意味着管理不善或估算错误，但项目仍然可能通过申请额外预算（如果商业案例仍然成立）来完成。而预算风险是，商业案例本身已经被否决，投资方不再愿意投钱。

总结与类比

您可以这样理解：

• 项目风险是“执行风险”——船能不能造好？
• 商业风险是“航线风险”——等船造好了，我们要去的目的地还存在吗？这艘船还有用吗？船长（管理层）还支持这次航行吗？

因此，管理风险和预算风险本质上是商业战略和投资承诺的动摇，它们直接决定了即使项目成功交付，其产出的系统也无法在商业环境中“生存”下去，所以它们被划为最顶层的商业风险。