2.2.1项目的特征

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

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

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

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

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

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

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

　　1．目的性

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

　　2．一次性

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

　　3．独特性

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

　　4．相互依赖性

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

　　5．不确定性

2.2.2项目三角形 

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

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

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

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

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

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

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

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

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

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

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

　　当顶点向左端滑动时，成本边逐渐增大，时间边逐渐减小。增加人员，加班加点，进度可以被压缩，任务可以提前。

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

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

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

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

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

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

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

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

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

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

　　项目三角形还有其他一些值得探讨的话题，大家可以自己做些思考。如：零缺陷软件的代价有多大？项目的最佳投入是多少？时间越充裕质量一定越好吗？

2.2.3项目与运营活动

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

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

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

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

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

2.2.4软件项目

　　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月
-- 转载：请标明出处