《可持续的项目管理架构十项原则》由会员分享，可在线阅读，更多相关《可持续的项目管理架构十项原则（4页珍藏版）》请在装配图网上搜索。
1、可持续的工程管理架构十项原那么6. 依靠构造，有效控制工程范围如今，系统交付环境变得复杂化， 组织在开发系统方面只好竭尽全力做到更迅速、 更可重复地迭代应用。 也正因为如此，对系统交付的构造、方案和有效管理的重要性前所未有地显现出来。我们必须在这里老调重弹：很多工程往往会在还没有开场编写一行代码之前，就失败了。在此，埃森哲总结出十项原那么，能够帮助您实施有效的程序管理和工程管理架 构。1. 依靠简单、灵活的方法，以支持不同的开发类型 在系统交付方面，我们发现一个有趣的矛盾现象：交付环境虽然日益复杂，却要求实施交付的方法变得更为简化。今天，这种新的 “回到根源的方法论对于能否取得业务的成功至关重
2、要。对我们来说，就意味着以下的几点： 确保这种方法既要象以往一样具备 “企业级实力，但同时又要简单：应当易于理解和记忆，同时信息划分层级越少越好。 使用易于承受的术语，让沟通更顺畅。比方在我们的公司里，统一的建模语言是我们许多交付工程的根底。同时支持定制化开发和打包开发两种方式。 根据工程经理、设计师、开发人员以及决策层的工作性质不同，向他们阐述关于这个方法论的不同 “视角。 运用市场上最先进的方法，同时勇于尝试其他来源的业内领先方法。2. 采用阶段发布方案 是什么能让庞大而复杂的系统运转呢？我们的研究发现，做一个阶段性的发布方案是其中的关键。 要想有效进展程序管理，必须将需求分解，分阶段发布
3、。还必须要做到在每个阶段性发布中都能严格控 制工程范围和方案时间。如有必要，各个部门应该协同行动，从各自的职能上保证按时完成方案。这 样做规划有如下几点好处：快捷实现商业价值。及早检验认证根本系统组件。有效控制程序变更频率，减少对用户的影响，并能让用户更多参与。 及时更正在工程中的错误。提高 IT 效率。3. 管理并跟踪工程使之保持在可控制的 “规模之内这是工程管理的“黄金法那么：工作分组不能太小也不能太大，而是要正好能在正确的时间实现应有的价值水平。 我们发现，如果将管理工作控制在三到六个月的发布期内，将是成功发布工程的最正确保证。这就意味着，可持续的工程管理的一局部涉及到工作如何合理分组，
4、遇到不合理的情况如何使之变得合理、满足需 要。当工程团队从方案到分析，再到设计，再到组建、测试以及最终的部署，所采用的交付方法需要能反映出不同的可 管理工作组。4 .通过转换点或“阶段门槛来控制工作流程和质量阶段门槛是指当一个可交付的工程从一个团队转到另一个团队过程中对应的点。在这些转换点上，典型地说是在已 定义好的工作阶段例如，从分析到设计，再从设计到组建，组建到测试之间，工程管理者必须提供进出标准这也 是何时工作完成的标准的清单。多亏有这些精心设计的点、完好划定的标准可交付工程，上一个阶段的 “交付者准 确地知道他们需要制作的内容。下一阶段的 “接收者那么也会准确地了解他们将会拿到什么样的
5、内容。拥有更清晰的 预期目标是成功的保障之一。举例来说，在一家高科技制造企业中，工程团队规定了在工程每个阶段的起点时应交付出的产品描述。但是，描述 的细致程度以及在早期的设计阶段对可交付出产品的出口标准却不甚统一。造成的结果是，工程后期需要做大量额外的 工作，才能找出那些没有明确指出的需求，重新返工，而这些工作应该是在工程早期就已经完成的。与这个例子相反的 是，一家旅游和运输公司在一个工程初期，就专门设立了工程办公室。这个团队采用了非常简单而有效的技术，来通过 对细节的把握，控制交付产品的质量，方便了管理者了解工程进展，并保持信息的同步。此工程取得了应有的价值，也 实现了在预算范围内按时完成任
6、务。5.管理跨地区工作 对于如今的跨国公司而言，系统开发比以往更可能在多个不同时区的地区展开。 因此，在我们前面所说的转换点上， 不仅仅需要从一个团队向另一个团队的产品交付 更可能是从一个地区向另一个地区的交付方式。如今，在全球化开发工程中，企业所需要的，正是如何对于在多个地点发生的工程管理构造和方法进展优化指导。 在不同的环境中，解决问题的方法会千差万别。工程所采用的方法必须把握如何做好发布管理、沟通 /合作、时间方案 / 预算管理、资源管理、进程报告以及问题管理。根据商业的远景规划，工程必须能使中高层管理者的本钱最小、质量最 优同时又能按时完成。 我们发现，有的设计师出于良好的意愿，与客户
7、沟通时，有时短短几句话，就会使庞大而复杂的工程的范围进一步失控。 客户说，“ 要是这个系统能做到 XXX 就好了。设计师立即点头附和， “哦是的，它能做到。其结果：客户现在期待 系统能有 XXX 功能，而其实这已经超出了工程的范围。如果一个工程能有变更需求的严格流程，控制好工程范畴，那 么工程的成功几率会大大增大。只要让工程团队养成依靠构造的好习惯，这一点就不难做到。所以，针对客户的要求， 正确的答复是： “我们要检查您的需求和原有方案是否有出入，如果可行，您需要作一个需求变更请求。 构造不是人 为设置的障碍，而是为了工程整体的成功。7. 与客户保持良好关系这一点是与第 6点相辅相成的。对于系
8、统开发团队来说，仅仅是和客户一起，在工程之初就方案并划定工程范围范 畴，然后按方案完成部署，然后向客户报告成功，这是不够的。商业客户并不仅以此对待工程的成功。他们对成功的衡 量标准是，这个工程是否创造了应有的价值，而不是仅仅简单地按时完成任务。有效保持与客户的关系要做到两方面：1从客户的立场发，理解工程的目标和期望值；2与客户公司的高级管理层建立并维持良好关系。我们都知道，组织的高管需要有战略性的思维、决策力以及 个性正直等方面的素质。但我们也了解，把这些抽象的概念付诸实践的过程，通常不可捉摸。8. 用量化的方法衡量进程观察工程经理面对管理周期内评估任务时的表现，会发现，没有什么比这更能提醒人
9、性的特点了。对于不得不审查 的工程进展，工程经理们最经常采取的逃避手段是把责任分摊出去。其结果是：经理所听到的，是每个人都报告说一切 进展顺利。虽然这能在短期内缓解压力，但绝对不是长远之计，而且这样做往往会带来本钱的上升。正确的作法应该是 用定性分析的方法更直接地过问评估工作，同时采取定量法严格地跟踪衡量工程进程。把软件开发工程的行为和目标都 写入文档是很重要的，但这样做还不够，同时还要跟踪实际的结果和绩效，把它们与工程方案进展对照。在实际结果与 原始方案产生明显偏差时，要能够采取校正措施，保证工程回到正确的轨道上。跟踪工程进展不仅仅是标出已投入的天 数和还剩余的天数，工程经理要通过正确地衡量
10、和跟踪工程，找出把握工程成功的行动方案。这里请关注三个方面的问 题：“必须在这里老调重弹：很多工程往往会在还没有开场编写一行代码之前，就失败了。“我们发现现今在系统交付方面一个有趣的矛盾现象：交付环境虽然日益复杂，实施交付的手法却必须变得更为简 化。采取衡量框架，用于开发 IT 跨维度的标准。通常，我们推荐使用平衡记分卡，可以令人对关键的跨 IT 标准一目了 然。成功的评估工程需要有恰当的设计，并收集那些关键绩效指标KPI。开发出适合不同的角色的相应标准。比方说，工程经理或是团队领导者需要更详细地理解关键标准指标。9. 主动着手风险管理很多工程失败的原因之一是，工程管理者把风险管理与问题管理混
11、为一谈。有效的风险管理意味着对可能发生的问 题提前作出预测，风险管理就好比是一家保险公司对投保对象可能发生的火灾、损害或盗窃事件进展预测的过程。如果 你只是能够有效地应对问题，那么你根本没有在做风险管理。风险管理构造应该能迫使团队成员引起某种程度的关注 强迫他们不断自觉地预测未来可能发生的事情。10. 与工程中的其它公司主动保持职能沟通关系也许在在过去 20 年中系统交付领域最大的变化之一，就是庞大而复杂的工程往往牵涉到多家公司。能否合作并管 理好这样的关系是十分关键的。成功的几条诀窍如下：明确每个人在自己职责中对于跨公司合作环境所持有的现实期望值。在工程开场时就定义并划清各自角色和职责，并能
12、就有效的团队合作展开谈判与所有供给商都要创立运营协议在工程实施中，对于工程管理构造要保持一致意见。尽力了解工程上其他重要合作方的业务职责。识别并管理需要通过跨供给商的合作来交付的产品和相应的依赖性要素。书面记录与其他供给商的谈话，主动保存所指派的任务的风险日志和问题日志。保持与其他供给商的高管的定期结论：方案、控制、构造当然任何一个工程构造都不会取代训练有素、精明胜任的工程执行者。实际上，我们发现，工程必须依赖有着工程 管理经历的领导者。这方面的能力是独特的、系统的，并且是长期训练的结果。找到有交付复杂大型工程经历的适宜的 人员是在工程方案之初就必须做的一件事，否那么工程根本无法开场。而除了有经历的工程管理者之外，本文讨论的十原那么会带来有效的组织构造、流程和管理过程，开发人员也就更 能发挥才干，更可能在规定的时间和预算之内，成功交付工程
可持续的项目管理架构十项原则
