★ FEATURED ARTICLE 软件项目管理项目管理概述软件项目管理的提出源于20世纪70年代中期的美国美国国防部研究发现70%的软件开发项目问题如延期、超支、质量不达标源于管理不善而非技术因此软件开发领域开始重视管理环节。但到20世纪90年代中期项目管理不善的问题仍普遍存在。其特殊性体现在两点软件是纯知识产品开发进度、质量、生产效率难以估计和保证软件系统复杂性高开发过程中风险难以预见和控制。软件项目管理的对象是软件工程项目覆盖整个软件工程过程。核心是在技术工作开始前就对项目的工作范围、风险、资源人、软硬件、任务、里程碑、成本、进度等进行预先计划并在整个软件生命周期中持续执行直至项目结束。管理目标是确保项目按预定成本、进度、质量完成核心是对人员People、产品Product、过程Process、项目Project四大要素的分析与管理。后续将围绕进度、配置、质量和风险管理展开介绍。软件进度管理进度管理是为确保项目按期完成的管理过程核心是对活动的计划与控制包括6个环节活动定义、活动排序、活动资源估计、活动历时估计、制定进度计划、进度控制。工作分解结构WBS软件项目因复杂庞大需层层分解为可管理的小任务即“项目→任务→工作→日常活动”。WBS是按可交付成果导向对项目要素的分组每下降一层代表更详细的工作定义是制定进度计划、资源需求、成本预算等的基础。工作包WBS树形结构最底层是最低层次的可交付成果由唯一主体负责。分解方式按产品物理结构、功能、实施过程、实施单位、目标等分解。基本要求工作包需可控、可管理不过于复杂分解层次不超过6层每个工作包有明确交付成果每个任务有明确定义的完成标准有利于责任分配。任务活动图工作分解后需明确活动的前驱开始前必须发生的事件、持续时间、必须完成日期、里程碑等以确定活动间的先后顺序形成任务活动图。它是进度管理、成本管理的基础常用甘特图展示和管理。活动历时估算软件配置管理SCMSCM是标识、组织和控制软件修改的技术应用于整个软件工程过程。其目标是管理变更标识、控制、确保正确实现、报告变更以减少错误、提高生产效率。核心内容包括版本控制对软件开发中程序代码、配置文件、文档等的变更进行管理核心功能是追踪变更记录“何时、何人、修改了什么”每次变更后版本号递增支持并行开发解决多人协同的版本同步、通信问题通过分支与合并处理不同版本的Bug修正。变更控制目的不是阻止变更而是确保变更有序进行。引发变更的因素包括外部变更如客户修改需求最难处理因IT项目需求变更概率高后期变更工作量大内部变更如为修复测试错误修改源码或设计。配置项软件质量管理软件质量指软件与明确/隐含需求的一致程度具体表现为符合功能性能需求、开发标准及隐含特征的程度。影响因素可分为三组产品运行、产品修改、产品转移。软件质量保证(Software Quality Assurance,SQA)建立有计划、系统的方法确保项目遵循标准、步骤和实践核心是“过程可见”通过评审和审计验证合规性。目标事前预防缺陷而非事后检查尽早捕获缺陷避免扩散作用于过程而非最终产品贯穿所有活动。主要任务审计与评审审计工作产品、工具、设备是否符合标准评审活动是否与预定过程一致报告记录结果并发布需保证SQA与高层直接沟通、向工程组发布、向关心质量者发布处理不符合问题及时向相关人员及高层反映问题。软件质量认证检验企业整体质量水平评估其设计、开发、生产符合质量要求软件的能力主要标准包括ISO 9000国际标准化组织制定的系列标准其中ISO 9001:1994用于证实组织满足顾客及法规要求的能力覆盖设计、开发等20项质量要求CMM能力成熟度模型卡内基梅隆大学软件工程研究所研制是软件生产过程及企业成熟度等级认证标准我国企业多采用。软件风险管理风险管理是软件项目管理的重要内容目标是预防风险风险指可能影响预算、进度的问题若发生可能导致延期、超支甚至项目失败。核心流程是辨识风险→评估概率与影响→制定管理规划。主要风险管理体系包括Boehm体系分为风险估计辨识、分析、排序和风险控制计划、处理、监督偏重理论Charette体系分为风险分析辨识、估计、评价和风险管理计划、控制、监督与Boehm体系接近偏重理论CMU-SEI体系基于实践的全面管理体系包括SRE、CRM持续风险管理、TRM团队风险管理与CMM配合将需求方纳入风险管理要素。易混淆点解读第4项管理风险和第5项预算风险之所以被归类为商业风险而非项目风险核心在于它们的根源和影响层面不同。简单来说项目风险威胁的是“项目”的成功能否按时、按预算、按范围完成。商业风险威胁的是“产品”的成功和业务的生存能力项目完成后它能否带来商业价值能否存活下去。下面我们来详细拆解第4和第5项第4项管理风险 - 由于重点转移或人员变动而失去上级管理部门的支持为什么是商业风险根源在于商业战略和优先级的变化失去支持通常不是因为项目经理管理不善而是因为公司整体的商业环境、战略方向或高层领导团队发生了变化。例如公司被收购/合并新东家可能有不同的战略原项目可能不再重要。市场出现新机遇或威胁公司必须将资源和注意力转移到更紧迫的事情上。关键高管如CEO、赞助人离职新上任的领导可能有自己的一套规划不再认可前任支持的项目。影响的是产品的“生存”而不仅仅是“交付”即使项目团队排除万难成功交付了系统但失去了管理层的支持意味着产品无法获得持续的运营和维护资金。在推广阶段得不到必要的组织资源和政治支持。最终的成果无人认可也无法被有效采用。这直接导致系统“死亡”——虽然被开发出来了但成了一个没人用、没人维护的“僵尸系统”无法实现其商业价值。这正是对系统生存能力的致命威胁。作为对比的项目风险例子“项目团队内部沟通不畅”或“技术骨干离职”是项目风险因为它们直接影响项目本身的交付但不一定意味着产品本身没有商业价值。第5项预算风险 - 开发过程没有得到预算或人员的保证为什么是商业风险根源在于商业价值的再评估和投资决策预算被削减或撤销根本原因通常是商业层面认为该项目的投资回报率ROI不再吸引人或者有更优先的投资选项。这不是项目超支那是项目风险而是商业投资意愿的撤销。例如经重新评估发现项目预期收益无法实现。公司整体财务紧缩需要砍掉“非核心”项目。竞争对手抢先发布了类似产品使得本项目即使完成也失去了市场先机。影响的是项目存在的“根本理由”预算是项目存在的“氧气”。撤销预算不是一个可管理的执行问题而是商业上对项目死刑的宣判。它直接导致项目彻底终止、夭折。系统根本无法被开发出来更谈不上后续的运营和生存。作为对比的项目风险例子“项目成本超支”是典型的项目风险。它意味着管理不善或估算错误但项目仍然可能通过申请额外预算如果商业案例仍然成立来完成。而预算风险是商业案例本身已经被否决投资方不再愿意投钱。总结与类比风险类型关注点问题根源核心问题例子商业风险产品的生存能力商业环境、战略、投资决策“我们做的东西对吗还值得做吗”管理层换人后不再支持公司决定停止拨款。项目风险项目的交付能力执行过程、技术、团队、管理“我们能把它做出来吗”程序员离职技术难题无法攻克进度延误。您可以这样理解项目风险是“执行风险”——船能不能造好商业风险是“航线风险”——等船造好了我们要去的目的地还存在吗这艘船还有用吗船长管理层还支持这次航行吗因此管理风险和预算风险本质上是商业战略和投资承诺的动摇它们直接决定了即使项目成功交付其产出的系统也无法在商业环境中“生存”下去所以它们被划为最顶层的商业风险。
阅读完成 · 觉得有帮助？
