1.依靠简单、灵活的方法，以支持不同的开发类型

 

　　在系统交付方面，我们发现一个有趣的矛盾现象：交付环境虽然日益复杂，却要求实施交付的方法变得更为简化。今天，这种新的“回到本源”的方法论对于能否取得业务的成功至关重要。对我们来说，就意味着以下的几点：

 

　　确保这种方法既要象以往一样具备“企业级实力”，但同时又要简单：应当易于理解和记忆，同时信息划分层级越少越好。

 

　　使用易于接受的术语，让沟通更顺畅。比如在我们的公司里，统一的建模语言是我们许多交付项目的基础。同时支持定制化开发和打包开发两种方式。

 

　　根据项目经理、设计师、开发人员以及决策层的工作性质不同，向他们阐述关于这个方法论的不同“视角”。

 

　　运用市场上最先进的方法，同时勇于尝试其他来源的业内领先方法。

 

　　2.采用阶段发布计划

 

　　是什么能让庞大而复杂的系统运转呢?我们的研究发现，做一个阶段性的发布计划是其中的关键。

 

　　要想有效进行程序管理，必须将需求分解，分阶段发布。还必须要做到在每个阶段性发布中都能严格控制项目范围和计划时间。如有必要，各个部门应该协同行动，从各自的职能上保证按时完成计划。这样做规划有如下几点好处：快捷实现商业价值。及早检验认证基本系统组件。有效控制程序变更频率，减少对用户的影响，并能让用户更多参与。及时更正在项目中的错误。提高IT效率。

 

　　3.管理并跟踪项目使之保持在可控制的“规模”之内

 

　　这是项目管理的“黄金”法则：工作分组不能太小也不能太大，而是要正好能在正确的时间实现应有的价值水平。我们发现，如果将管理工作控制在三到六个月的发布期内，将是成功发布项目的最佳保证。

 

　　这就意味着，可持续的项目管理的一部分涉及到工作如何合理分组，遇到不合理的情况如何使之变得合理、满足需要。当项目团队从计划到分析，再到设计，再到组建、测试以及最终的部署，所采用的交付方法需要能反映出不同的可管理工作组。

 

　　4 .通过转换点或“阶段门槛”来控制工作流程和质量

 

　　阶段门槛是指当一个可交付的项目从一个团队转到另一个团队过程中对应的点。在这些转换点上，典型地说是在已定义好的工作阶段(例如，从分析到设计，再从设计到组建，组建到测试)之间，项目管理者必须提供进出标准(这也是何时工作完成的标准)的清单。多亏有这些精心设计的点、完好划定的标准可交付项目，上一个阶段的“交付者”准确地知道他们需要制作的内容。下一阶段的“接收者”则也会准确地了解他们将会拿到什么样的内容。拥有更清晰的预期目标是成功的保障之一。

 

　　举例来说，在一家高科技制造企业中，项目团队规定了在项目每个阶段的起点时应交付出的产品描述。但是，描述的细致程度以及在早期的设计阶段对可交付出产品的出口标准却不甚统一。造成的结果是，项目后期需要做大量额外的工作，才能找出那些没有明确指出的需求，重新返工，而这些工作应该是在项目早期就已经完成的。与这个例子相反的是，一家旅游和运输公司在一个项目初期，就专门设立了项目办公室。这个团队采用了非常简单而有效的技术，来通过对细节的把握，控制交付产品的质量，方便了管理者了解项目进展，并保持信息的同步。此项目取得了应有的价值，也实现了在预算范围内按时完成任务。

 

　　5.管理跨地区工作

 

　　对于如今的跨国公司而言，系统开发比以往更可能在多个不同时区的地区展开。因此，在我们前面所说的转换点上，不仅仅需要从一个团队向另一个团队的产品交付……更可能是从一个地区向另一个地区的交付方式。

 

　　如今，在全球化开发项目中，企业所需要的，正是如何对于在多个地点发生的项目管理结构和方法进行优化指导。在不同的环境中，解决问题的办法会千差万别。项目所采用的方法必须把握如何做好发布管理、沟通/合作、时间计划/预算管理、资源管理、进程报告以及问题管理。根据商业的远景规划，项目必须能使中高层管理者的成本最小、质量最优同时又能按时完成。

 

　　6.依靠结构，有效控制项目范围

 

　　我们发现，有的设计师出于良好的意愿，与客户沟通时，有时短短几句话，就会使庞大而复杂的项目的范围进一步失控。客户说，“ 要是这个系统能做到XXX就好了。”设计师立即点头附和，“哦是的，它能做到。”其结果：客户现在期待系统能有XXX功能，而其实这已经超出了项目的范围。如果一个项目能有变更需求的严格流程，控制好项目范畴，则项目的成功几率会大大增大。只要让项目团队养成依靠结构的好习惯，这一点就不难做到。所以，针对客户的要求，正确的回答是：“我们要检查您的需求和原有计划是否有出入，如果可行，您需要作一个需求变更请求。”结构不是人为设置的障碍，而是为了项目整体的成功。

 

　　7.与客户保持良好关系

 

这一点是与第6点相辅相成的。对于系统开发团队来说，仅仅是和客户一起，在项目之初就计划并划定项目范围范畴，然后按计划完成部署，然后向客户报告成功，这是不够的。商业客户并不仅以此看待项目的成功。他们对成功的衡量标准是，这个项目是否创造了应有的价值，而不是仅仅简单地按时完成任务。有效保持与客户的关系要做到两方面：

 

　　(1)从客户的立场发，理解项目的目标和期望值;

 

　　(2)与客户公司的高级管理层建立并维持良好关系。我们都知道，组织的高管需要有战略性的思维、决策力以及个性正直等方面的素质。但我们也了解，把这些抽象的概念付诸实践的过程，通常不可捉摸。

 

　　8.用量化的方法衡量进程

 

　　观察项目经理面对管理周期内评估任务时的表现，会发现，没有什么比这更能揭示人性的特点了。对于不得不审查的项目进展，项目经理们最经常采取的逃避手段是把责任分摊出去。其结果是：经理所听到的，是每个人都报告说一切进展顺利。虽然这能在短期内缓解压力，但绝对不是长远之计，而且这样做往往会带来成本的上升。正确的作法应该是用定性分析的方法更直接地过问评估工作，同时采取定量法严格地跟踪衡量项目进程。把软件开发项目的行为和目标都写入文档是很重要的，但这样做还不够，同时还要跟踪实际的结果和绩效，把它们与项目计划进行对照。在实际结果与原始计划产生明显偏差时，要能够采取校正措施，保证项目回到正确的轨道上。跟踪项目进展不仅仅是标出已投入的天数和还剩余的天数，项目经理要通过正确地衡量和跟踪项目，找出把握项目成功的行动方案。这里请关注三个方面的问题：

 

　　“必须在这里老调重弹：很多项目往往会在还没有开始编写一行代码之前，就失败了。”

 

　　“我们发现现今在系统交付方面一个有趣的矛盾现象：交付环境虽然日益复杂，实施交付的手法却必须变得更为简化。”

 

　　采取衡量框架，用于开发IT跨维度的标准。通常，我们推荐使用平衡记分卡，可以令人对关键的跨IT标准一目了然。

 

　　成功的评估项目需要有恰当的设计，并收集那些关键绩效指标(KPI)。

 

　　开发出适合不同的角色的相应标准。比如说，项目经理或是团队领导者需要更详细地理解关键标准指标。

 

　　9.主动着手风险管理

 

　　很多项目失败的原因之一是，项目管理者把风险管理与问题管理混为一谈。有效的风险管理意味着对可能发生的问题提前作出预测，风险管理就好比是一家保险公司对投保对象可能发生的火灾、损害或盗窃事件进行预测的过程。如果你只是能够有效地应对问题，那么你根本没有在做风险管理。风险管理结构应该能迫使团队成员引起某种程度的关注——强迫他们不断自觉地预测未来可能发生的事情。

 

　　10.与项目中的其它公司主动保持职能沟通关系

 

　　也许在在过去20年中系统交付领域最大的变化之一，就是庞大而复杂的项目往往牵涉到多家公司。能否合作并管理好这样的关系是十分关键的。成功的几条诀窍如下：

 

　　明确每个人在自己职责中对于跨公司合作环境所持有的现实期望值。

 

　　在项目开始时就定义并划清各自角色和职责，并能就有效的团队合作展开谈判。

 

　　与所有供应商都要创建运营协议。

 

　　在项目实施中，对于项目管理结构要保持一致意见。

 

　　尽力了解项目上其他重要合作方的业务职责。

 

　　识别并管理需要通过跨供应商的合作来交付的产品和相应的依赖性要素。

 

　　书面记录与其他供应商的谈话，主动保留所指派的任务的风险日志和问题日志。

 

　　保持与其他供应商的高管的定期

 

　　结论：计划、控制、结构

 

　　当然任何一个项目结构都不会取代训练有素、精明胜任的项目执行者。实际上，我们发现，项目必须依赖有着项目管理经验的领导者。这方面的能力是独特的、系统的，并且是长期训练的结果。找到有交付复杂大型项目经验的合适的人员是在项目计划之初就必须做的一件事，否则项目根本无法开始。

 

　　而除了有经验的项目管理者之外，本文讨论的十原则会带来有效的组织结构、流程和管理过程，开发人员也就更能发挥才干，更可能在规定的时间和预算之内，成功交付项目。