IT项目成功的八条经验

IT项目成功的八条经验

      虽然以前的博文更多地在探讨导致IT项目失败的原因，但是了解一下成功的企业软件实现也是有必要的。

　　Mike Kavis是一个企业应用架构师，整整一年来他都在自己的博客中发表对于他们有关BPM和SOA实施的

情况。最近，他们开展的第一个SOA应用，一个面向顾客的B2B门户网站完成。Mike Kavis在博客中撰文：“这

个应用系统将用于我们整个销售和订单处理全过程。虽然这只是整个项目过程中的第一步，数月后，完整系统

提供的功能将极大地提高我们的投资回报率（ROI）。对于我们，这是一个重大的里程碑。所以，我希望借此

机会与大家分享我们的经验。”

　　Mike Kavis与我们分享了他们开发第一个SOA项目时得到的经验。我则对Mike认为的“我们作对的事情”进

行了评注。

　　1. 侧重业务而非技术

　　“我们做了一个为期90天的业务流程评估，总结现状，并充分考虑未来可能出现的局面，制定了一系列不

同投资回报比率的项目。”
　　
　　评注：认识到项目与业务发展紧密联系的同时，Mike团队实际上已经走上了成功之路。 软件与技术的进步

应该成为促进相关业务发展的重要因素。绝不能依赖无法准确评估的隐性效益。

　　2. 充分的准备

　　“我们参加各种讨论会，学习博客上的知识，研究相关网站，与有经验的设计师合作，努力获取任何SOA

相关的信息。”
　　
　　评注：这个道理是显而易见的。 不幸的是，太多的IT客户过分依赖他们的供应商，而没有充分地学习相关

知识。 这将导致不健康的依赖关系，影响机构内利益相关者做出明智的决定。

　　3. 全面的POC模型

　　“我们花了大量时间做客户对BPM与SOA工具需求的评估。”

　　评注：耐心做客户评估，进行POC验证，充分了解你的合作伙伴。俗话说，强扭的瓜不甜，仓促地进行大

项目开发绝对不是个好主意。

　　4. 挖掘人才

　　“我们在IT与业务方面都安排了最优秀的员工。 同时，我们还派遣设计师到有合作关系的SOA公司学习。”

　　5. 有力的决策支持

　　“我们的决策人是业务部门的人，也是为我们的项目筹集到最多资金的人。与我们IT部门的几个人一样，她

将这个项目视为自己的事业，为争取四年内实现可观的投资回报率而努力。”
　　
　　评注：虽然这是他们的第一个SOA项目，Mike团队对软件实现却有深刻的认识。出于某些原因，业务管理

人经常不太情愿为技术实现交出自己的资源。而强力的决策支持可以让业务方面的人员更自愿地参与帮助技术

实现。

　　Mike的决策人将她的事业与项目紧密联系在一起，这也是承诺与信心的表现。如果你的决策人没有购买自

己公司的股票，那你最好赶紧换一个。

　　6. 即时处理阻力因素

　　“无论何时遇到阻力或消极因素，我们都会马上处理。”

　　评注：到处都有唱反调的人。虽然建设性的批评总是有用的，消极的却必须及时处理。 Mike在这方面做的

很对，当然实际解决问题的时候肯定会遇到一些困难。

　　7. 通过迭代交付取得短期成效

　　“我们首先分析已确定的项目，然后结合需求与SOA路线图决定各个项目的优先级与应用范围。”

　　8. 健全的体系结构

　　“我们在为一个松散耦合的服务体系结构打基础……”
　　
　　评注：不要拿项目计划表或技术体系开玩笑。无论在业务还是技术层次，准确、专业的规划都是至关重要

的。

　　虽然Mike团队是第一次进行SOA开发，但他们在很多事情上做的很对。 吸取这些经验，你的企业软件项

目必然会更加成功。

 

备注：

BPM是Business Process Management的缩写，意思是业务流程管理，是指根据业务环境的变化，推进人与人

之间、人与系统之间以及系统与系统之间的整合及调整的经营方法与解决方案的IT工具。业务流程管理应该包

括"建模-实施-监控-管理"等过程，要具备其所需的所有服务与工具才能叫作BPM。

面向服务架构（ SOA ）是让 IT 更加关注于业务流程而非底层 IT 基础结构，从而获得竞争优势的更高级别的应

用程序开发架构。

 

POC，是Proof of Concept的缩写，意思是为观点提供证据，它是一套建议的电子模型，它可用于论证团队和客户的设计，允许评估和确认概念设计方案，POC的评价可能引起规格和设计的调整。
1、POC的概念 POC，是Proof of Concept的缩写，意思是为观点提供证据，它是一套建议的电子模型，它可用于论证团队和客户的设计，允许评估和确认概念设计方案，POC的评价可能引起规格和设计的调整。POC流程所产生的关于设计的承诺、大家都认可的意见都将记录在设计的调整文档中，以备查。这样下去，POC不断发展。 如果在完成这些任务时需要帮助，可以在Queensland大学找到协助资源。

2、POC的开发 POC的开发步骤及方法如下： 第一步，开发包含所有基本导航特征(按纽，图标、菜单等)的界面模型，但不是最终的完美形式。 第二步，给界面添加少量内容，尤其是在至关重要的媒体中添加一到两个样本。例如，如果套装软件包非常依赖3D模型，就应该添加一个包含驱动所必须的3D模型样本。如果软件包需要显示数据符号和表格，那么有关数据符号和表格的样本也应添加上。 请注意，这个过程应该用于支持论证和验证设计，而并不是软件包开发的实际开端。你应该尽力去论证和销售设计，但也不要太过分，因为设计过程中有时需要作重大的修改，这样将导致浪费大量的资源。

3、POC的评价和验证 评价和验证过程就是寻求风险承担者通过POC和备案设计文档的反馈。通过POC评价，风险承担者可能提出调整规格和设计的要求。 有时，由于设计存在的缺陷或不适当的地方，设计团队就可能只好回到绘图板。客户可能决定停止设计或寻找其他团队，这是因为设计没有足够地关注客户和使用者的需求，或者是因为客户需求的不稳定性。有时这种改变是由客户组织或者项目决策者所引起的。 通常，在评价和验证过程结束时，有关设计的承诺、大家都认可的意见都将记录在备案的设计文档中，这往往是产品开发的生命周期中一个重要的里程碑。在结束评价和验证之后，POC就可继续发展。 4、最小化的需求 尽管POC是产品开发过程中重要的评估技术，但是你也应该限制在POC开发方面所花费的时间，考虑到早先的设计阶段包含的所有因素，构建POC中关键元素。 应该把充足的精力用于论证和认同设计方面，但也不要过多，这样即使设计中需要作重大的修改，也不会导致浪费大量的资源。 在全面设计开始执行之前，让客户对设计认可是必要的。

5、客户的角色定位 规格和设计阶段，要求产品开发有详细的设计文档，而且POC常伴随着产品开发。客户签署设计文档中，并反馈POC是重要的项目里程碑。如果在下一阶段仍需修改产品设计，就要按照受控的变更控制流程得到认可和批准。在整个项目过程中处理不同的检查和停顿时，客户的一个重要职责是为按期交付而保证已确认的进度表，并同意为防止计划被耽搁而需再投资的情况出现。