|
1、前言项目管理者联盟
出于安全保密的考虑，此文中将以A项目代替项目实名，A机构代替实际客户机构。领导A代替实际客户机构的项目主管部门领导。项目管理者联盟
我是于项目后期参与建设的。当时项目通过了第一期验收，进入第二期建设。虽然通过第一期验收，但大部分潜在风险都是在第二期集中爆发，导致项目一拖再拖，陷入无底深渊中......项目管理者联盟
2、项目综述项目管理者联盟
A项目已经持续建设两年多，至今还未最终验收。而按照合同，建设期为一年。项目管理者联盟
A机构的业务离不开信息化系统。在A项目启动之前，A机构已经有好几个系统在运行。但随着业务量的增大，业务流程的更改，旧系统的劣势日益显现。主要体现在：性能下降明显、无法适应业务变更的需要、业务系统与OA系统难以无缝连接、存在多个不同的技术体系，维护工作难度大，成本高等等。基于此，A机构提出了A项目，旨在升级改造所有信息化系统，以解决旧系统所带来的问题。项目管理者联盟
按一般的项目建设考虑，A项目应该不存在什么问题。首先，确定目标为升级改造项目;其次，对现有的软硬件条件、业务流程、用户新需求进行调研分析;然后，根据分析结果进行技术选型，创建团队开始实施。项目管理者联盟
对于项目，一般都会采用较为成熟的技术体系。比如A项目，可采用.net平台或者java平台，采用一些成熟的开发框架和产品，完全可以满足要求。然而，事与愿违，在特定的时期出现了特定的状况，导致了不一般的建设思路。而这个特定的状况就是：A机构的-A项目的-主管部门的-领导A出于政绩的考虑，也是其理想主义的支撑，给A项目注入了众多不可确定的因素，而这些因素严重影响了结果。项目管理者联盟
领导A提出完全采用开源技术，从开发语言、操作系统到数据库，都必须是开源。按理说，java技术可以满足条件。可是，领导A要求是采用新的开源技术(出于安全保密，姑且称之为A技术)。而这个技术也是近几年才兴起，完全还没有大规模使用。技术人才短缺、技术资料匮乏、第三方库和工具寥寥无几，这就给技术选型和技术实现埋下了隐患。其次，他又提出了全业务流程的概念，而这个概念，更是拖累了整个项目进度，差一点导致项目的崩盘。项目管理者联盟
当然，公司能够接下此项目，也正是利用了这些因素。但是，公司决策层和项目管理者没有意识到，投标阶段是为了拿下项目，更多从商务角度考虑问题，夸大或无条件应承都是有可能的;而实施阶段则是实打实的，不存在任何幻想和夸张。接下来的项目实施是痛苦的，项目团队一直处于不稳定状态，项目经理更换了四五拨，项目成员一直在更替。原本一年完成的项目延期了近一年。到目前为止，新系统已经上线试运行半年左右，基本处于稳定状态，现已进入终验阶段。项目管理者联盟
在我看来，A项目是失败的。站在客户角度，项目结果偏离、项目延期、未达到领导A的预期;站在公司角度，项目团队支离破碎、成本严重超支、技术体系未建立、行业进入推迟。项目管理者联盟
3、项目总结bbs.mypm.net
3.1、项目定位-项目目标的不明确，导致项目从一开始就无所适从项目管理者联盟
项目定位很重要，决定了项目的走向。项目A目标不明确，如果一开始只定位为升级改造项目，采取成熟的技术架构，那么这个项目将不存在什么困难。但是，确定采用新的开源技术，技术风险明显增加，在近一年的时间里，项目团队就沉浸在解决技术难题上了：Workflow、Cluster、SOA、Report、Dynamic Form等等。很明显，项目性质变成了技术研究，而研究本身就有很多不确定因素。其次，全业务流程的思想，使得业务需求调研抛开了现实情况，从BPR角度去重构业务规则，重新规划各业务部门的功能职责。而这些并不是一个信息部门的领导所能推动的，其难度可想而知。而在之后的一次会议上，A机构一把手就提出：想法是好的，但不切实际!结果项目进展了近一年，看不到任何实际成果。项目经理博客
因此，我们从一开始一定要确立好项目的目标，这个目标是契合实际、可测量的!如果从领导A的角度来考虑，那么这个项目就应该定位为“一把手”工程，分阶段分步骤实现。首先，由于要做全业务，那么可定义业务规划子项目，采用咨询方式进行;其次，要采取新技术，则可定义技术研发子项目，采用研究方式进行;接下来，定义一个试点子项目，以某个业务部门进行试点，成功后，则可以开始全面展开。而这个过程，不是一年就能做下来的。pmp.mypm.net
3.2、沟通管理-沟通方式、干系人期望严重阻碍了项目进展项目管理者联盟
沟通，无时无刻不存在!缺乏沟通，事事困难。沟通，要建立在互赢的基础上，任何具有单方面倾向性的沟通都会是失败的。在这点上，项目经理要起到至关重要的作用，当然也需要客户方的理解和配合。监理方则是站在中立的角度上，按照监理要求去协调供求双方，力求项目顺利进行。但是，A项目中，领导A太强势，事事必亲躬，事事要做决定，甚至干涉项目的开发，对技术实现指手画脚;监理方完全看甲方行事，并未从项目实际情况考虑问题;而历任项目经理都过于软弱，盲目应承客户要求，不断推高干系人期望，不考虑进度、成本和现有技术实力，结果答应的实现不了或者延期实现，使得甲乙方关系日趋紧张。唯一一次的客户妥协，因为某业务要赶紧上线，就降低了技术要求，采取了快速开发实现的方式，保证了按时上线。这也顺利通过了第一期验收。training.mypm.net
因此，在项目启动之前，甲乙双方，加上监理方，要确立好沟通方式、职责范围。项目经理一定要管理好干系人及其期望，针对不同干系人采取不同的沟通方式。项目经理不能一味软弱，要从项目根本出发，力求双赢。如果不属于其职责和能力所能企及的，则要及时寻求更高领导的帮助。项目管理者联盟
3.3、技术选型-项目定位不明确，导致技术选型产生偏差，进而改变了项目前景项目管理者联盟文章
3.1中提到了项目定位不明确，正是定位偏差，导致了技术选型的失败!之前也提到了，项目定位只是升级改造的话，采用java技术完全不存在技术风险，在成熟的轻量级的Web开发框架SSH、JBPM、Lunece的基础上，公司已自成一套体系，完全可以满足升级改造的需要。而事实采用了风险巨大的新技术，这种技术在业界里尚未有类似业务平台系统的先例，具有太多的不确定性。也就是说，A项目是全国乃至世界第一个完全采用该新技术的大型业务平台系统。其技术风险可想而知。项目管理者联盟
因此，项目定位决定了技术选型。项目定位最重要，技术选型也不能忽视。一般的，做应用软件项目，最好采用业界公认的、已得到广泛使用和验证的、属于公司已成熟的技术，而不确定的新技术，在应用项目中使用之前，最好以研发项目的形式进行学习、研究和试验，得出研究成果，以确定其适用性和可推广性。项目管理者联盟
3.4、开发模式-美好的敏捷式开发，导致团队失去了控制项目管理者联盟
市面上有很多的开发模式，最传统的瀑布式、IBM的RUP、微软的MFS、敏捷开发等。而A项目采取了敏捷式开发。敏捷开发是一种应对快速变化的需求的一种软件开发能力。相对于传统模式，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通(认为比书面的文档更有效)、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重做为软件开发中人的作用。但是我认为敏捷开发适用于中小型项目，且团队成员之间的水平相当。有效沟通是建立在相对平等且互信互利的基础上的，一个相对不稳固的团队，而且水平参差不齐，何以有效沟通。这种团队，命令是最有效的方法!更值得玩味的是，甲方也有开发人员，领导A提出1+1模式，即乙方一个开发人员带甲方一个开发人员，共同完成开发。这样，既完成了项目，也带出了甲方自己的队伍。殊不知这种架构让项目经理如何去管理!这种看似“创新”的模式，实际上已经让团队成为散兵游勇，无法控制了!想想看，甲方人员怎么可能去听乙方人员的差遣!这种模式完全让团队崩溃!另外，在项目实施中采用了敏捷开发，但在项目监理中却采用了GB标准以项目文档作为阶段里程碑。一个不强调文档，另一个却是以文档为主，冲突避免不了了。项目管理者联盟
因此，开发模式要根据项目目标、客户现状、团队情况、技术选型来确定。如果只是升级改造，需求相对稳定，团队也并不成熟，那就采取最传统的方式进行迭代开发即可。如果非要说培养甲方队伍，那应与乙方独立运行，乙方提供相应的技术支持，由甲方自行控制。甲方所做的功能模块，应是非核心部分，相对独立不影响其他功能模块的运行。再不济，就是乙方只做人力外包，甲方全权负责，这样，项目就只是人力外包项目了。talent.mypm.net
3.5、团队建设-没有一个强有力的项目经理就没有一个坚实的团队项目管理者联盟
|
