软件项目管理与素质拓展-2.2什么是项目

2.2.1项目的特征

　　三国演义中群英荟萃，斗智斗勇，最出彩的章节莫过于赤壁大战了。周瑜全局战略眼光不够，加上心胸狭窄，就老想给诸葛亮下套以除掉他。“草船借箭”就是其中很经典的一出戏。咱们看看两我的的斗智斗法。

 

　　江面上做战主要靠弓箭，周瑜借口东吴军中缺少羽箭，请诸葛亮负责督造羽箭。督造羽箭工做有明确的任务目标：十天造十万支箭，贻误军机，军法处置。没有明确的目标，行动就没有方向，就成了盲动，努力越多，资源耗费越多，距离目标可能越远。执行过程当中，通常容许审时度势，对目标作适当的调整。

　　诸葛亮虽知周瑜故意刁难，但督造羽箭有助于孙刘联合抗曹，加之胸有成竹，就立下军令状：何需十天，三天就足够了。

　　造箭须要工匠、器材，周瑜不给人、不给物，诸葛亮只能求助于鲁肃。对诸葛亮而言，最重要的资源就是鲁肃。鲁肃具备全局战略眼光，认识到孙刘联盟若是破裂，必将被曹操各个击破。鲁肃是东吴的参谋长，具备资源调配的权力：二十条船、六百名军士、青布、稻草、鼓号，听候调用。诸葛亮让人用青布幔子把船蒙起来，扎了一千多个草把子，排在船两边，船上架起鼓号。

　　所谓“兵无常势，水无常形”，每项军事行动都有其独特的地方，没有两项军事行动会彻底同样。为何诸葛亮这么有把握？首先，他事前从江中老渔翁那了解到三天内必有大雾；其次曹操生性多疑，诸葛亮料定曹军大雾天不敢出击；最后有个难能难得的鲁肃，从大局出发，瞒着周瑜，为诸葛亮配齐所需的全部人员、物资。这三方面条件缺一不可，可遇而不可求。设想一下：若是周瑜是提早十天给诸葛亮下的套，若是曹军主帅是许褚，若是鲁肃那段时间正好回南郑见孙权不在军营。只要其中有一个若是成立，诸葛亮就会性命不保。

　　每项军事任务都有一个明确的起点和终点，不是没完没了或重复进行。十万支箭点验完毕，销毁军令状，六百名军士、20条船交还鲁肃，任务即告结束。草船借箭是一锤子的买卖，打死都不会有第二次的。诸葛亮不会第二次冒险，曹操不会上第二次当。

　　“草船借箭”是一个典型的项目（Project），诸葛亮是对项目负全责的项目经理（Project Manager，PM）。项目做为一种特殊的活动，具备如下特征：

　　1．目的性

　　每一个项目都有一个明确的目标。草船借箭的目标是三天造十万支羽箭。一个全省集中的呼叫中心项目的目标是：创建覆盖全省的统一的电话服务平台、短信服务平台、互联网服务平台以及大客户服务平台，实现流程自动流转、服务高效便捷、监管实时到位。

　　2．一次性

　　每一个项目都有一个明确的开始日期和完成项目的结束日期，没完没了或重复进行的工做不叫项目。时间方面的限定性要求是项目各方异常关注方面。由于是一次性的任务，因此又带有临时性的特色，项目团队是临时组建的，项目目标达成之日，就是团队解散之时。

　　3．独特性

　　每一个项目都有其独特的地方，没有两个项目会彻底同样，没有彻底能够照搬的先例。每一个项目的目标、工做内容、资源需求、客户参与、实施团队、实施环境等都不尽相同。项目不能彻底程序化，每一个项目都会面临新的问题、新的挑战。项目经理对各类问题的处理须要因时、因地、因人而异。

　　4．相互依赖性

　　任务有前后，资源要保证。每一个项目都是由一系列相互关联的任务组成的，许多不重复的任务以必定的顺序完成，才能达到项目目标。每一个任务的完成须要运用各类不一样的资源，如：资金、设备、物资、人员、关系、信息等。领导、同事、客户、下属、伙伴是项目资源库的重要组成部分。

　　5．不肯定性

　　项目的特殊性使得人们在项目开始之初通常很难确切划定项目的工做范围，准确估算完成任务所需的时间、成本，彻底预见全部可能的项目风险，由此致使初期工做计划制定的困难。随着项目的推动，一些原先不肯定的因素慢慢浮现并肯定，各方对项目的认识理解逐步清晰并统一，项目风险逐渐降低，项目经理须要与时俱进地对计划进行适时调整。 

2.2.2项目三角形 

　　 基于上节对项目特征的总结，咱们能够对项目作以下定义：项目是在既定资源和要求的约束下，为实现某种目的，而相互联系的一次性工做任务。

　　首先，这个定义强调项目的目的性。项目目标包括4个方面：

　　（1）范围目标：要什么？项目要完成的内容是什么？

　　（2）时间目标：要多快？项目必须在多长时间内完成？

　　（3）质量目标：要多好？项目交付物须要达到什么样的指标？

　　（4）成本目标：要多省？项目人、财、物的投入必须控制在什么范围内？

　　思考：这几个目标中哪些是效果目标，哪些是效率目标？

图 2‑ 5 项目三角形

　　作得对、作得好是效果目标，作得快、投入少是效率目标。如前所述，效果重于效率，范围、质量优先于时间、成本。问题真的是这么简单吗？软件项目中客户会更关注哪一个因素呢？

　　其次，这个定义强调任务和资源的相互依赖。项目的目标要素间存在某种关联关系，一个要素的变化会引发其余的要素变化，没法寻求全部目标要素同时最优的结果，这就是著名的项目三角形，见 图2‑5 。项目三角形的三条边分别是时间（Time）、成本（Cost）、质量（Quality），三条边围成的面积表明工做范围（Scope）。其中质量这条边表明的是：因为质量低劣所付出的代价。质量越好这条边越短，质量越差这条边越长。三条边与面积之间存在着颇有意思的现象。

　　假设你是一个软件项目的负责人，原先合同约定完成100个功能，年末上线。项目是年初启动的，五个月后因为某种强力缘由，客户要求提早到国庆上线，并且是做为一项必须完成的政治任务，你该怎么办？

　　加班加点，加大投入，是首先想到的办法，见  图2‑6 。

图 2‑ 6 加大投入以压缩工期

　　问题是：这样作可否确保提早交付符合质量要求的100个功能，也就是在范围（S）、质量（Q）保持不变的状况下，增大成本（C）这条边，以压缩时间（T）这条边呢？咱们知道三角形的面积等于底边乘以高。若是过与质量相对的顶点，画条平行线，当三角形顶点在平行线上滑动时，面积保持不变。

　　当顶点向左端滑动时，成本边逐渐增大，时间边逐渐减少。增长人员，加班加点，进度能够被压缩，任务能够提早。

　　但时间边的压缩是有限度的，当时间边与三角形的高重合时，进度的压缩达到最小值。进一步地增长人手，加大投入，非但不能加快进度，反而会因为人浮于事，相互观望、效率低下等缘由而延后项目。

图 2- 7 范围—工期—质量—成本的妥协

　　若是因为背负政治性任务等因素，强行要求进一步压缩工期怎么办？如 图2‑7 有两个选择：

　　选择一：保持面积（范围）不动，该完成的100个功能一个不落；加大投入的同时，加长低劣质量的代价这条边，牺牲必定的项目质量，以确保国庆系统上线。

　　选择二：保持质量不变，加大投入的同时，减少面积（范围），国庆前先完成影响客户运营的核心功能，其余功能在年末前完成。

　　对于这两种选择，不能简单地断定对错。

　　客户能够忍受按时交付的一个有80%功能的符合质量要求的系统，却没法接受一个包含100%功能而质量却不好的系统。客户能够忍受按时交付的核心功能没有大碍但有很多缺陷的系统，却没法忍受大幅延期的项目。交付延迟，意味着客户的业务目标没法按时达成，甚至严重影响客户的业务运营、经济效益、管理效益，这些损失每每要大大超出软件项目自己的投资。软件开发公司也将所以付出额外的开发成本与声誉损失的成本。

　　美国一个未公开的评估报告显示，17个主要的军方软件合同，没有一个项目按时完成，平均28个月的进度计划推迟了20个月才完成，一个4年应该完成的任务，7年还未提交。因此有负责人说：“我宁愿软件有错也不肯被延迟，咱们能够在之后纠正错误。”[SEI01]

　　这又使得不少项目经理陷入“前期重进度，后期重质量”或者“前期过于细致，后期草草收尾”的误区。这种先后不一致的状况主要是因为对项目工做量及难度估计不许，对自身研发能力与实施能力认识不足，项目资源规划不科学。前期质量缺陷遗留到后期解决，时间越拖后，代价越大。若是出现大范围返工，将得不偿失。

　　项目推动的过程，就是项目三角形的四个要素动态调整、动态平衡的过程。软件项目中，时间这一效率目标通常是比较刚性的目标，范围、质量这两个效果目标是与时间相关的弹性目标，成本这一效率目标主要取决于软件开发公司的经营决策。在客户能够忍受的范围与质量前提下，在公司能够承受的代价下，确保按时交付基本可用的系统。系统交付以后，再逐渐补齐应该作的内容，提升软件的质量。

　　没有固定的标准，没有固定的程式，只有指导性的原则。各方的博弈，火候的拿捏，都是每一个项目经理成长路上的必修课。

　　项目三角形还有其余一些值得探讨的话题，你们能够本身作些思考。如：零缺陷软件的代价有多大？项目的最佳投入是多少？时间越充裕质量必定越好吗？

2.2.3项目与运营活动

　　 人类有组织的活动可分为两种类型：一类是接二连三、周而复始的活动，称为“运营”(Operation)，如公交车的运营、平常教学管理活动；一类就是前面讲述的“项目”，如阿波罗登月计划、三峡工程、奥运售票系统等。两者的主要区别见表2‑2。

表 2‑ 2 项目与运营活动的区别

	项目	运营
负责人	项目经理	职能主管
组织体系	临时项目团队	职能式固定组织
时限性	一次性	周而复始
工做性质	独特性	不断重复
运做目标	关注效果	关注效率
运做环境	相对开放和不肯定	相对封闭和肯定
管理模式	按项目的过程和活动进行管理	按部门职能和直线指挥系统进行管理

特定客户＋特定目标＋必定期限＋必定资源，这才构成项目。

　　思考：如下活动，上课、迎新晚会、集体婚礼、申办奥运、系统运行维护、教室卫生保洁、神州飞船计划及我的健身锻炼，哪些是项目，哪些是运营？

项目活动的一次性、独特性，决定了必须首先关注实现效果，在达成能够接受的效果目标的前提下，再考虑效率，绝对不能由于追求效率而影响了效果。

运营活动是重复性活动，其运营环境相对封闭肯定，经过以往屡次的重复已经验证其效果达标，所以大多更关注效率，更关注在不断重复时下降实现的代价。

2.2.4软件项目

  1 ．软件及软件的特色

　　IEEE这样定义软件：软件是计算机程序、规程以及运行计算机系统可能须要的相关文档和数据。软件能够形象化表示为：软件＝程序＋数据＋规程＋文档。其中的“规程”是所求解问题的领域知识和经验，反映了软件要实现的功能，要支持的业务流程。

　　软件区别于硬件及传统工业产品具备明显不一样的特性：

　　（1）软件是抽象的逻辑产品，由0、1集合表示的交互界面、处理逻辑及数据集合。软件在最终投运以前，谁都没有彻底的把握下结论——“鞋子合不合客户的脚”。软件产品的无形性，使得知识及知识产权的管理比较困难，在某种程度上制约了软件业的发展。

　　（2）复杂性是软件的本质特性，软件在规模上可能比任何其余人工制品都要复杂。它的复杂性源于应用领域实际问题的复杂性和应用软件技术的复杂性。

　　（3）软件开发最关键的因素是人，生产过程以创造性思惟为主，研发成本远远大于生产成本。软件产品基本上是“定制”的，软件开发至今没有摆脱手工模式。人手不够、人员流失、能力欠缺、没有动力、不负责任、单打独斗都是项目失败的一些常见缘由。

　　（4）软件没有统一的质量标准，软件缺陷检测比较困难。所谓充分完备的测试也只是相对意义上的，没法作到全面完全。即便通过严格的测试试用，也没法保证软件没有潜在的缺陷，几乎全部的软件系统都是“带病上线”。

　　（5）计划、监督、控制、管理比较困难。软件涉及的技术更新迅速、需求变化快、时间紧迫，研发工做每每多任务并发、依赖关系复杂、流程繁多且环环相扣，加之个体生产率差别巨大，以至软件项目的进度、成本、质量每每难以准确估计与控制。

　　（6）软件维护比硬件复杂许多，管理调整、技术进步、应用水平提升都会对软件提出更高的要求。软件维护包括修复缺陷的纠错性维护，加强软件功能、性能的完善性维护，以及因应软硬件环境变化的适应性维护。维护的过程当中又可能产生新的缺陷。

　　（7）受制于不少社会因素，如组织的政治、文化、决策体系、管理方式。

2．软件行业的现状

　　上个世纪末曾经有这样一个传闻，比尔•盖茨和通用汽车CEO韦尔奇间有个争论。

盖茨在一次计算机博览会上说：“若是通用汽车像计算机行业那样跟得上技术发展，咱们都将驾驶每加仑行驶1000英里的25美圆的汽车。”

韦尔奇作出回应：若是通用开发了像微软那样的技术，咱们今天将驾驶有如下特征的汽车：

• 不管怎样，你的汽车都会毫无理由的一天碰撞两次。
• 每次重划公路交通线时，你都不得不买辆新车。
• 偶尔地，你的车会毫无理由地“Down”在高速上，你不得不“再发动”，而后继续驾驶。
• 偶尔地，实施一个控制命令如向左转，会致使你的汽车莫名其妙地熄火，并拒绝再发动，在这种状况下你不得不重装汽车发动机。
• 每次只能有一我的使用这辆汽车，除非买辆“汽车95”或“汽车NT”，但那样你将不得不买更多座位。
• 油、水温和交流发电机的报警灯将被单一的“通常汽车故障”报警灯代替。
• 新座位将迫使每一个人有一样大小的臀部。
• 汽囊系统在中止运行前将不断询问“你肯定要关闭吗？”
• 偶尔地，你会被汽车拒之门外，除非你在转动钥匙时，同时打开门把手。
• 要求全部买主同时购买一套道路交通图，即便他们不须要也不想要，尝试删除这个选择将当即致使汽车的功能减小50%或更多。通用也将变成司法部的调查对象。
• 每购买一款新车，用户将都要从头学驾驶，由于“汽车2000”控制方式与“汽车98”截然不同。
• 你将按开始键，而后关掉发动机。

　　美国著名的咨询机构Standish Group自1995年发布第一份CHAOS报告以来，近二十年的时间里，对超过9万个IT项目进行了深刻的追踪调查，如 图2‑8 。他们发现，虽然在过去的20年里，IT项目的成功率整体上有所提高，但2012年的报告显示状况依旧不容乐观。能在预算内按时交付规定功能的项目仅占39%，43%的项目存在延期、超预算或功能缩水等问题，完工前取消或交付后没有投入使用的项目仍然高达18%。

 

 图 2‑8 Standish Group的CHAOS报告

　　国内软件项目情况的数字只会比这更糟糕。很多软件的开发，仅仅是为了验收会上那一个小时的系统演示。验收会后，服务器直接关机，软件系统没有真正投入运行一天。由于在项目立项之初，可能就仅仅是为了把有限的科技项目资金找个名目开支掉，固然谈不上关注软件的可用性、实用性了。

　　2014年，GAO（美国政府问责署）审计指出，美国国防部信息技术项目频频出现预算超支、表现不佳和延期的问题。15个美国军方主要的自动化信息系统中（MAIS），7个项目的总成本增加范围从4%到2233%不等，12个项目的时间进度延期从数月到6年不等，有8个项目的性能数据未能达到预期目标。其缘由主要有两点：

• 软件规模与复杂性不断增长；
• 软件管理方法欠缺，手段简陋。

　　大量实践证实，软件项目的成败，一般是由于管理问题（协同工做的能力），而不是技术上的问题。管理是影响软件项目成功开发的全局性因素，而技术只影响局部。

　　抛开动机不纯的软件项目以外，提升软件项目成功率的根本解决之道就是《软件工程》课上介绍的合理的开发方法，以及本课程讲解的项目管理方法。

　　3．软件项目开发的通常过程

　　 图2‑9 是软件开发的通常过程，客户与软件公司在软件项目开发过程当中须要紧密配合，各司其职。客户深度参与项目，对确保项目的成功具备很是重要的做用。

　　（1）立项可研：客户组织相关方进行立项论证、可研分析，提出项目整体目标及初步需求，同时着手安排资金预算，启动业务转变准备。

　　（2）项目招标：客户经过公开招投标或竞争性谈判的方式，肯定由哪家公司承接项目。随后双方展开商务谈判，协商工做范围、产品要求、交付要求、付款条件等合同条款。

　　（3）项目启动：客户及软件公司确认项目目标，任命项目经理，下达项目任务书，组建项目团队，明确责任分工界面，创建工做流程，正式启动项目。

　　（4）需求调研：软件公司进驻现场，在客户通力配合下，经过访谈调研、问卷调查、文档收集、研讨观摩、制做原型等多种手段收集客户各方需求，整理记录用户需求。

　　（5）需求分析：软件公司统一各方意见，排定需求优先顺序，展开细致的需求分析工做，造成面向开发人员、严格表述的需求规格说明。

　　（6）需求确认：双方共同确认后造成需求基线，做为系统分析、设计、开发、测试、验收的主要依据。需求基线一经造成，后续的需求变动，必须通过严格的变动控制程序。

　　（7）系统设计：软件公司依据需求，展开系统整体设计，肯定系统架构、模块划分、关键技术方案，进而展开算法设计、界面设计、数据库设计等工做，编制系统设计说明书。

　　（8）开发测试：设计评审经过后，软件公司全面铺开编码、测试、培训、部署等工做。复杂项目多采用增量开发，屡次迭代的开发过程，静态审查与动态测试相结合以确保质量。

　　（9）业务转变：与此同时，客户要为系统上线作好业务转变准备，调整组织机构，优化工做流程，并在开发公司的配合下，清理历史档案数据，补充新系统必要的基本数据。

　　（10）系统上线：割接及试运行，须要双方事前精心组织，明确关键节点、分工界面、应急预案、问题处理机制及版本控制方法等。关键业务系统上线前甚至须要屡次演练。

　　（11）运行维护：系统正式投运后，由常设的联合运维小组负责平常运维工做，包括问题解答、操做指导、报表处理、流程处理、数据处理、缺陷修复以及功能完善与扩展。

图 2‑ 9 软件开发通常过程

 

-- 摘自 《软件项目管理与素质拓展》 张大平 殷人昆 陈超 清华大学出版社 2015年11月-- 转载：请标明出处