|
GCS项目从2006年开始，2008年结束，项目最高峰时成员有30多人，是我当时经历的最大的项目之一，其中的经验教训至今还记得清楚，它们指导着我，为我后续项目管理工作起了重要的指导作用。项目管理论坛
GCS是作为客户某部门A的核心系统而开发的，主要功能是对人、物进行实时的调度指挥，保障生产的有序、实时开展。A部门有几千人，管理层级多，业务非常复杂，实时性和安全性要求高。在GCS开始建设之前，用户已经在使用一个类似的系统，姑且叫CCS，一个在上世纪九十年代基于DOS和FOXPRO开发的图形化系统，该系统由A部门一个技术人员牵头开发完成，经过十多年的完善，无论在人性化设计，操作方便性，业务覆盖，性能和稳定性上都算得上是很不错的系统。2004年，意识到该系统存在的技术太旧，扩展性不强，难以做大的改动等问题，该公司决定找家外部公司针对该业务重新开发一个系统，用于替换CCS系统，可不幸地的是该项目在部分模块试运行期间由于准确性、实时性一直达不到要求，用户抱怨很大，被中止。项目经理博客
2006年，借着奥运的东风，客户又重启了该项目。这次项目的重启，是作为客户公司的奥运项目而存在的，各方领导给予了厚望，项目组从上至下都面临很大的压力，当然，另一个好处是，最终各方对项目的支持力度也很大，项目从最初的不到十个人，又抽调了一些骨干，组成了一个近二十人的研发团队，直至到后来的三十余人。项目在2006年下半年，开始按步就班的进行客户需求调研，CCS系统的研究，需求分析，设计....，GCS系统基于JAVA，客户端分两种，基于WEB的和基于WINDOWS客户端，服务器端基于J2EE(现在叫JAVA EE)架构，使用ORACLE数据库，技术风险不大，2007年年中完成第一个版本的发布，随后将整个项目组搬到客户现场，进行系统的试运行和优化，从这开始，很多故事便发生了。项目管理者联盟
前面说了，CCS系统从最初版本到现在已整整经历了十多年的时间，替换CCS系统并不是它在使用上，业务等方面有什么问题，主要还是基于未来发展的考虑，CCS是基于DOS的，因此，CCS客户机很难同现有的其它应用集成，用户面前经常摆着好几台电脑才能正常工作，CCS的开发团队缺少发展和继承，CCS的用户界面虽简洁易用，表数据表现力不足，随着业务量的增长，CCS的服务器面临很大的压力但缺乏很好的扩展方案。从上面的问题很容易看出，所有要用GCS替换CCS的理由几乎都是系统级别的，一线用户是很难理解的，因为大多数用户已对CCS非常熟悉和依赖，并认为CCS能很好的工作，因此，对GCS有很大的抵触心理。training.mypm.net
有了上面的说明，大家也猜到了，试运行一定很不顺利，举一些例子，很多一线用户非要把新的WINDOWS界面风格改成象CCS系统一样的DOS图形化界面风格，包括配色，文字大小等，同时，又要求快捷键一模一样等等，其它遇到的一些问题还包括：www.mypm.net
基层用户很抵触，认为很难习惯GCS的操作，二者并行时，用户总是在CCS上操作。项目管理者联盟
中层领导并不十分支持。担心数据不准确造行生产事故，同时，还有来自属下员工的抱怨。bbs.mypm.net
由于是GCS/CCS并行，因此，二者互通成了大问题，用户总是希望GCS/CCS操作产生等价的效果，但实际是由于二者设计和需求的一些不同，比较难以实现。PgMp.mypm.net
真正接触到一线用户，才发现不管在操作上还是业务上，系统同CCS都有较大的差距，很多应该有的功能原来根本就没考虑开发，而要实现某此功能，可能导致很大的改动，有些功能只做到了表面，对细节理解不好。项目管理者联盟
与GCS连接的外系统太多，任何一个出了问题，用户都认为GCS出了问题，很容易导致信任危机。
由于众多的原因，导致项目的各个利益相关者都在抱怨，导致恶性循环，曾一度陷入天天加班，抱怨却越来越多的情况，劳动成果得不到认可，项目组人员情绪低落、干劲被逐步的消磨。现在想来，如果不是一个自上而下的推动，该项目中途失败的可能性很大。项目管理者联盟
经过近一年的试运行，除了整体架构没有大的变化外，GCS外观、用户体验、业务流程已经与一年前的系统相去甚远，用户最终还是接受了GCS系统(当时不排除有些人是被迫接受)，下面总了其中的一些教训talent.mypm.net
持续不断的用户沟通和用户参与很重要：因为是自上而下的项目，初期对一线用户的声音不重视，导致后面大量一线员工的抵触。另外一方面，在应用的开发期，需求人员也需要定期走访用户，了解最新的业务动态，随时修正设计，因为项目周期较长，一年的时间一定会有很多的改变。项目管理者联盟
前期对业务研究要深入，同类及相关系统的研究也要深入：项目组对CCS系统的了解还不深，流于表面，没有抓住细节，应在需求调研阶段深入的了解CCS，去现场了解用户的使用情况，实现业务的情况等等，因为要替换CCS，如果不了解CCS，从何谈起?club.mypm.net
设计不能想当然，多从一线用户角度看问题：应用在设计期间，无论从业务上还是表现上都要尽可能的灵活，以满足可能的变化。比如，考虑到原有用户使用DOS系统，界面比较单调，就想当然的认为用户一定会喜欢更有表现力的WINDOWS风格。项目管理者联盟
深入了解不同用户习性和痛点，分批次分阶段突破，避免失控：在投产策略上也可以优化，GCS/CCS并行的运行过程中，最好先有针对性的选择一些用户，了解他们的痛点，在习惯，口碑上重点突破，逐步建立口碑。摊子铺得太大，一起开会总结时，你一言我一语，有些用户还带着情绪，很多本想说系统优点的用户也不说了，最后的结果是一线人员都不为你说话，而这又会给中层留下很不好的印象。项目管理者联盟
通过亮点引导用户的正向思维，避免负向思维的强化和缺点放大：尽可能一开始就有某些点能建立用户的兴趣和信心，由于系统一开始只是覆盖了CCS现有的功能，缺少功能亮点，也没有充分发挥新工具的长处，这种状态同CCS比，当然处于劣势。而功能亮点的缺失还是缘于对业务的研究不够。项目管理者联盟
由于客户对安全要求极高，项目结束后，还经过一段时间双系统并行运行，2009年CCS系统已经彻底下线，近5年来，GCS系统发挥着核心作用，用户对系统的评价也逐步好了起来，目前还不断在里面添加新的功能。项目管理者联盟 项目管理者联盟
本文为项目管理者联盟联盟会员原创文章，授权发布，非经同意不得转载！
|
