2003年5月

                
                    功能紊乱软件项目的七个特征

    经过多年大型软件项目调研和开发风险的鉴定和评估的经验，集成计算机工程公司（ICE）已经开发了一个风险数据库。他们通过分析这个数据库，得出了可以洞悉导致功能紊乱软件项目 的七个主要的特点。这篇文章列举了这些特点以及每一个特点所伴随的现实世界中的风险。
    集成计算机工程（ICE）公司（Integrated Computer Engineering (ICE), Inc.）是美国系统公司（American Systems Corporation）的一个分支机构，它在鉴定和评估大型系统项目的需求和开发风险方面具有丰富经验。十二年来，ICE评估了280多个联邦、州、国防部以及商业软件程序和项目。这些项目包括调研和开发边缘武器、通信、金融、逻辑和公共服务自动数据处理系统。
    ICE收集12年来评估的项目的风险并开始形成了一个包含了丰富有用信息的数据库。该数据库也吸收了国防分析研究所[1]、Capers Jones[2]和Tom DeMarco[3]的风险研究成果，以及ICE在软件风险管理服务中为了支持软件项目管理者网络[4]所确定的风险。现在ICE风险数据库已经成为包含800多种主要和次要的项目管理风险的指示器。
    通过对那些按时、按预算提交具有很大难度而失败的软件系统的需求获取和开发的观察，ICE风险数据库中浮现出七个主要的特点，它们直接或间接关系到那些软件的失败。这七个特点列出如下：
 1． 缺乏必要的软件项目管理实施。很多问题项目的是由于实施项目管理纪律失败所导致的，诸如费用估算、项目进度计划、资源规划、结构管理和动态风险管理。
 2． 盲目的乐观和不现实的管理期望。一些管理者意识到了来自潜在的问题领域对项目的副面冲击，然而他们却选择了乐观的态度，当所有有用证据都显示警告信号的时候还假定问题会自行解决。
 3． 实行有效的软件过程失败。很多项目败于实行有效的软件过程是因为开发团队处理应用的方法没有平衡。一些实施最小过程并依赖专家职员，而另一些则机械地坚持全局的过程。
 4． 提前宣布成功。发布产品的压力经常导致管理者过早的宣称开发完毕。直到彻底严格完成产品所应具有的质量和可靠性才能宣布开发成功。
 5． 缺乏计划管理领导。管理一个软件项目需要“勇气”和经常提拔那些愿意面对今天的挑战来避免明天的麻烦的人。我们发现有两中类型的有问题管理者：一种是具有软件工程经验但是没有管理经验的，另一种是具有管理经验的是没有软件工程经验，两种类型都缺乏理想的技术和管理上的联系纽带。 
 6． 不及时的制定决策。一些管理者即使面对不能拖延的问题的明显的警告，也避免做时间紧迫的决定直到为时已晚。
 7． 缺乏动态的风险管理。很多项目都声称实行风险管理但是很少能够有效。“区分一个好的组织和管理者的依据不仅仅是他们在成功中做得多么好，而是他们在包容自己的失败时的表现[5]”

    现在让我们来仔细看看一些与这七个特点分别相关的现实世界中的风险。

       
缺乏应用必要的项目管理经验

  典型的风险有（风险标识符见19页表1）
 （A） 所采用的过程和制订的决策将会导致某一产品不能满足用户的需求，并与项目失败的严重后果不一致
 （I） 项目计划不能描述技术如何被应用于因产品不一致而持续的返工和修正因返工引起的问题
 （J） 在软件开发期间，因为收集分析错误数据的程序还未编制，软件可靠性问题不会被发现 
 （C） 不可实现或不可执行的项目计划将不会形成一预期的开发环境
 （K） 因承包商不能执行或计划软件设计的检查，软件的缺陷将不会发现
 （L） 因调试问题偶或对关键软件部分进行不足够的调试，导致必要的系统功能不能充分可靠的执行
    通过评估我们重复发现主流软件任务已经被合理的计划和执行，而某些必要的项目管理实践却没有。这些项目管理实践通常包括：成本估算、进度计划、资源规划、结构管理、风险管理、挣值报告、绩效基准、重新估算、质量保证和严格测试。
    许多项目经理认为这些项目管理实践是官僚表面文章，在实际工程中仅会成为绊脚石。同时认为，诸如风险管理、绩效基准和重新估算的方法经常为项目经理提供更多的事实，而不是如何去掌握和运用。
                          
                          表1 七大风险特征

* 注释：计算风险发生频率的事件总数为841。

盲目的乐观和不现实的执行管理期望

  典型的风险有：
 （A） 所采用的过程和制订的决策将会导致某一产品不能满足用户的需求，并与项目失败的严重后果不一致
 （B） 项目职员不胜任执行产品和运用所选的技术。过多的交接影响项目的成功
 （C） 不可实现或不可执行的项目计划将不会形成一预期的开发环境
    许多项目有着潜在的信念。事实上，管理软件项目的一个有效途径是对糟糕和突发情况在发生之前进行计划。1995年，仅仅16%的软件项目在预期的时间和预算内完成，大约53%的项目成本超出原先估计的190%[6]。当管理或参加系统采集或开发项目时，绝对不可盲目乐观；当管理一个大而复杂的高科技程序时，历史数据也不会提供过多的自信。那么为什么盲目乐观如此普遍呢？
    盲目乐观的两个基本的原因是：第一原因与第二原因的无知程度相关，或“没有认识到自己不知道的事物”。没有足够的经验项目成员对成功产生不现实的乐观的原因在于：
         l 没有意识到任务的数量或试图解决的问题
         l 过分简化完成所需结果或产品的步骤
         l 在未彻底地评估对程序的效果和影响的情况下，试图运用SILVER-BULLET技术解决问题
    盲目乐观的第二个原因是：存在较大文化隔阂突显出精确估算（和进度计划）。如果早期估算（或进度）预期比客户或经理的期望的成本更高，进度更长，质量更低，需要立即检查估算的有效性。在该种情况下经常要求项目经理直接重新估算，因为估算需在预先设置和任意的边界条件之内。[7]
    这种在执行经理和程序经理之间自我强加的文化隔阂强迫经理们向客户报告不现实的估算、进度和风险，而疏忽组织的要求。
    失控或缺陷系统的成本通常将有责任的执行主管进行解职或降级。
   “我不需要身边的人只会说是。说出你的真实想法即使如此会让你丢掉你的工作。”- Louis B. Mayer,米高梅公司传奇制片人
    面对可能被解职的威胁，多数项目经理存在“不屑一切代价去做”的思想意识。不容忍坏消息，不接受项目所产生的问题和其它所有问题，除了用最严厉的方式进行惩罚。


缺乏执行有效的软件程序


典型的风险有：
（G）所采用的技术程序与项目的需求和员工的能力不一致
（D）设计和编码错误只到开发后期才被发现，此时已为时过晚，以至影响成本、进度和质量。
（H）设计（系统或软件可观测到的基石）也许不能支持应用软件的安全保密需求。
（F）因在设计早期阶段缺乏需求分配，导致软件开发效率低。
    多数软件项目经理们设想去培训软件工程师，而认为项目特定的标准、指导方针和通用工具没有必要。
    有两个起作用的因素影响在特定项目下运用通用程序。第一因素是项目的唯一性。TIM LISTER说：每个项目是唯一的[8]，有它自己特异的客户、唯一的职员和对成功的期望。90%的问题是改变程序，还是改变边缘通用程序？对每个开发问题来说，技术和程序不是“切饼”解决方案，成功的关键在于适应技术和程序，满足特定项目或工程的独特挑战。
   “如果有合适的人员，在程序未完备情况下也可以成功；但是，没有合适的人员，即使有世界上最好的程序，也不会成功”[9]。
    第二因素是项目平衡。技术、工具、程序和人员必须在项目全过程中进行平衡，而不是仅在组织级别。

提前宣布成功

典型的风险有：
（L）由于调试问题或核心软件部分的不充分的调试，必要的系统功能不能充分或可靠地运行。
（N）当交货时，系统不能满足用户的需求和期望。
（O）过早发布不合格的产品导致不可预料的故障、关键用户的疏忽和潜在的数据误用，都会毁坏将来发布的信心。

    我们已经注意到及时付货的压力趋于压制对质量的需求，从而导致管理层过早盲目宣布项目的成功。“…我的许多职员因质量原因，永远修补某一任务；但是在多数情况下市场根本不关注质量。相反，滑稽有趣的是昨天交付的产品被乐意接受，即使处于迅速、恶劣的状态。决定迫使人们交付没有达到质量标准的产品始终是错误的。”
    清楚地理解客户的质量期望是获得客户满意的充分必要条件。交付虽无缺陷但成本明显超支、进度落后以至于技术陈旧的项目产品将不会令客户满意，同样及时交付的产品因不满足特定需求或极差的可靠性也不会令客户满意。

缺少计划管理领导

典型的风险有：
（C）项目计划不现实或不可执行，且不能产生预期的开发环境。
（E）项目计划没有及时更新，已经过时且不能反映当前的协定与约束。
（M）客户关联形成一个无组织的环境，排除在成本、进度范围之内成功完成项目产品。
（B）项目成员不能胜任完成项目产品，不能运用所选择的技术。过多的交接可能影响项目的成功。
    “蹩脚的项目管理会好的工程蒙受挫折，构成项目失败的最主要原因。”[10] 过多没有开发软件经验的人参与软件如何开发的决策。一个优良的项目经理的品质是：具有广泛的软件开发技术经验，具有管理人员和激励团队的能力，具有提前预防、管理项目风险和及时决策的意识。Tom DeMarco说：“项目经理…让疯狂的人离开”[11]。
    在最近评估处于严重困境中的软件项目时，项目经理不知道产品的状态，职员被复员，项目严重超支，进度落后。我们所发现的将会使你吃惊：管理层已经设置好目标，在某一期限前，成为软件工程协会、成熟模型处理能力（CMM）三级。难以置信的是，他们将40%的富有经验的工程人员转向CMM的研究。管理层经理说：“我们认为其余的人能够填补空缺。”这不是火箭科学。如果你想去管理一个你不得不坚持的软件项目，按照下述方法去做：没有捷径，不要胡闹，没有SILVER BULLET；只有一条通向终点的激光束。

不及时的决策

典型的风险有：
（D）设计和编码错误只到开发后期才被发现，此时已为时过晚，以至影响成本、进度和质量。
（E）项目计划没有及时更新，已经过时且不能反映当前的协定与约束。
（F）因在设计早期阶段缺乏需求分配，导致软件开发效率低
    “管理是一门计划艺术，因此它能在时间、成本和其它资源的约束且相互竞争的情况下完成项目。”当项目队伍在等待明确的方向或关键的资源时，因迟缓决策造成的延误使得这些约束发生进一步变化。除非计划依然通用，当未预料到的问题发生时，项目可能失去保护，项目经理离职，没有足够控制、纪律和有效明达的决策支持系统。
    简单地说，不及时决策导致的第二个问题是：你可以修改一个错误的决定，但是在等待项目经理如何去做时项目没有任何进展。在我们评估的多数项目中，工程师已经知道他们采取何种行动，作好行动准备，但只有等到管理层决定了仔细的过程才能开始行动。
    斯坦福大学的Kathleen Eisenhardt和维吉尼亚大学的Jay Bourgeois研究表明：快速决策通常比迟缓决策好得多。快速决策建立一套系统，在他们自身行业和市场不断地收集广泛的信息，然后利用可用数据制定决策。迟缓决策者首先分析问题，然后对所需解决的问题进行排序。仅在那以后，他们才外出寻找信息。[13]

缺少预先风险管理

典型的风险有：
（P）没有跟踪其它风险，使得项目成功不太可能
（Q）风险管理没有被正式有效或识别关键风险事件
（R）缺乏有效风险管理过程导致未计划的问题对项目产生冲击。
    “项目管理的问题如同大多数的管理一样，在时间、成本和绩效之间寻找可接受的平衡点。”[14] 当项目远离平衡时会产生风险。因为客户的压力，进度绩效通常成为最重要的问题，导致减少对成本绩效、产品绩效的关注，从而增加项目风险。“一个有效的风险管理计划在项目开发的全过程中是动态的、同步进行的，并且需要所有相关人员的参与。”[15]
    在评估项目时，大量的时间用在决定风险管理在整个管理中效率和执行程度。根据我们的经验，该对潜在的整体项目风险的评估应睁大眼睛去分析。没有进行有效风险管理的项目不断地对问题进行应对，而那些较好管理风险的经理能很好地预料而不是疲于应付。“一旦从疲于应付变更转变为提前预防、预料变更，你的组织将会更好。”[16] 为了增加可能的成功，风险管理应该在项目管理中起一个可视的、关键的角色。
    “风险管理胜过现代管理理论，如整体质量管理（TQM）和商业程序再设计，因为风险管理是制定决策的基础。风险管理基于在有问题的条件下提供不同决策策略的理论。”[17]

分析

    表1显示7个风险的特征和他们各自的标识符（大写字母从A到R）。ICE公司数据库中的每个风险事件均指定了标识符，统计结果在表1的从左数第3列，每一风险标识事件对应的风险特征统计在第4列，最后一列显示相应风险发生的频率；注意到最后一列统计的频率总数不到100%，因为每个风险特征对应的标识符不唯一。
    根据风险特征的发生频率进行排序；因此表中数据表明功能可能紊乱的原因，但不是对项目或程序的相应冲击。

结论

    当回顾功能紊乱软件项目时，需考虑一个合理的方法，是否运用此处已识别和确定7个风险的特征进行风险描述。
    如果问题如此显然，为什么项目没有解决这些问题呢？第一原因是否认问题。当你每天进行软件项目开发时，很容易假定可能发生致命错误的先兆，和该项目不会影响其它12个项目的方式。否认问题是项目经理制定被动决策的借口。
    第二原因是文化隔阂。同样地，所有7个因素集中于文化差异，而不是技术问题。“自1979年以来，我们一直联系那些发现项目走入歧途后离开的项目人员。根据对压倒性的多数破产项目的研究，不是仅用技术问题能来解释项目失败的原因。”[18] 上述的7个因素确实产生效果，且应该成为任何项目的必要部分。

参考书目

1. Technical Risk Indicators for Embedded Software Development. Institute for Defense Analysis, Paper P-3027, Oct. 1994. 
2. Jones, Capers T. Assessment and Control of Software Risks. New Jersey: Yourdon Press, Feb. 1994. 
3. DeMarco, Tom. Why Does Software Cost So Much? New York: Dorset House Publishing, 1995. 
4. Software Program Managers Network. 16 Critical Software Practices For Implementing Performance-Based Management. Ver. 3.0, Arlington, Va.: Integrated Computer Engineering, Inc., 2 Aug. 2000. 
5. DeMarco, Tom. Why Does Software Cost So Much? New York: Dorset House Publishing, 1995. 62. 
6. Standish Group International. “Chaos.” Open Computing Copyright, Mar. 1995 SPC. 
7. Jones, Capers T. Assessment and Control of Software Risks. New Jersey: Prentice Hall, Feb. 1994. 158. 
8. Lister, Tim. “Software Management for Adults.” Software Technology Conference, 1996. 
9. Davis, Alan. “Software Lemmingineering.” IEEE Software Sept. 1993. 
10. Humphrey, Watts. “Three Dimensions of Process Improvement: Part I: Process Improvement.” CrossTalk Feb. 1998. 
11. DeMarco, Tom. Why Does Software Cost So Much? New York: Dorset House Publishing, 1995. 66. 
12. Putnam, Lawrence H., and Ware Meyers. Industrial Strength Software, Effective Management Using Measurement. Los Alamitos, Calif.: IEEE Computer Society Press, 1996. 1. 
13. Putnam, Lawrence H., and Ware Meyers. Industrial Strength Software, Effective Management Using Measurement. Los Alamitos, Calif.: IEEE Computer Society Press, 1996. 13. 
14. P.V. Norden. Useful Tools For Project Management, Operations Research in Research and Development. Edited by B. V. Dean. New York: John Wiley & Sons, 1963. 
15. Molt, George. “Risk Management Fundamentals in Software Development.” CrossTalk Aug. 2000. 
16. Boehm, Barry, Raymond Madachy, and Chris Abts. “Future Trends: Implications in Cost Estimation Models.” CrossTalk Apr. 2000. 
17. Hall, Elaine. Managing Risk. Reading Mass.: Addison-Wesley 1997. 5. 
18. DeMarco, Tom, and Tim Lister. People-ware, Productive Projects and Teams 2nd ed. New York: Dorset House Publishing, 1999. 4. 


   

项目管理者联盟授权翻译，请勿转载