|
自1996年，作者开始正式接触并从事信息系统软件开发与集成方面的工作。本文为2003年参加信息系统集成项目经理培训后，结合自身经历，对信息系统集成项目“成功”整理的一些文字。 当时，作者已陆续参与或直接管理过教育、工商、公安、航天、煤炭等行业软件项目以及在新任职公司参与的一些政府、企业办公软件。在这次反思过程中，最大的触动是下面的一系列问题： 对以前所经历的项目，尤其是一些所谓“成功”的项目是不是真的是成功了？ 进一步努力的方向和余地在哪里？ 怎样才算得上是一个合格的、真正意义上的项目经理？ 怎样才算得上是一个高效的、健康的、真正意义上的项目团队？ 怎样才算得上是对项目进行了有效、可靠的管理与控制，使项目的成功有了真正保障？ 怎样才算得上是真正意义上成功的项目？…… 案例一：“项目”往往只是进行了“开发”工作。 曾负责某校“教学管理系统”软件的开发项目，当时开发周期仅仅3个月。没有需求调研，仅仅根据用户提供的一些表格开始进行数据库设计与程序开发；开发过程中也几乎没有和用户进行交流；项目小组4个人，有2人几乎没有参与到项目中来，基本是作者自己设计、“开发”；值得庆幸的是：最后，用户是“认可”我们工作的，软件的后来使用情况如何不得而知。现在回想起来，存在很多问题： 问题1：项目缺少需求调研阶段，项目范围不确定 最初，根据我们自己的认识，“闭门造车”式的完成了系统的分析。在设计数据库表时发现，这样的“需求”根本无法确定，于是在系统设计过程中对需求开始进行细化。 通过对其输出要求的数据入手进行分析发现：用户主要希望通过该系统实现自动排课、学生档案查询、教师档案查询、学生参加课程情况、教师承担课程情况、学生课程成绩、班级课程成绩排名等信息的打印输出。 于是针对信息的不同类型对数据进行了合理设计分为：学生档案、教师档案、班级信息、教室信息、课程信息四类元数据；通过排课、录入考试成绩等操作建立信息的关联，从而形成课程排课表、课程成绩表等计算数据。根据查询与打印的要求，建立相应的检索表。 利用这种“倒推法”，最终我们赢得了用户的“认可”。 回想起来，从项目范围上有很大的风险性：因为是无的放失，针对不确定的需求开展项目，所谓“成功”靠的是个别项目成员的开发经验与良好的客户关系，对项目范围没有进行有效管理和控制。 问题2：项目组织不力，没有调动起全部的资源，质量与进度也难以控制。 当时的想法很简单：那两个成员是“新手”，与其教会他们，还没有完全靠自己开发出来快，时间“等不及”。现在看来，是缺乏有力的项目组织与管理。如果严格按照软件工程的步骤，做好详细的系统设计，事实上个人的开发技术将不再是瓶颈。而且，设计人员过多的参与开发本身就是资源的巨大浪费。很多可以并行的工作只能逐个实施，使项目进度得不到保障。 当然，最理想的项目组是需求人员能够挖掘到并把握客户的真正需求，设计人员能够完全把握需求人员的系统规划意图，开发人员能够完全实现设计人员的设计要求。但是这样的项目组往往很难找到，即使确实存在也会很容易被公司分散到不同项目。使项目组成员在项目过程中受到良好的锻炼，本身就是项目经理应该考虑的事情。如果缺少达到期望要求的项目组成员，那就更需要逐步培养他们。 与此同时，其他项目成员参与的很少，意味着该项目的质量寄托在个别人的个人才能与经验技巧上。一旦出现疏漏、考虑不周，往往需要返工，缺乏稳定的质量监控机制，系统质量与实施进度都无法保证。从这一角度上讲，该项目在管理上是十分失败的。 问题3：项目浮于客户需求的表面，为了信息化而信息化，并没有做深层次的工作。 就当时的项目实际而言，我们提供的交付物：该软件是针对于特定业务的，至于该业务对学校工作有无深层次的意义和影响，当时根本就没有考虑，充其量不过是一个方便的打印、查询工具而已，难以称其为“系统”，由于最初设计的局限，采集的信息数据再利用也存在麻烦。 总体而言，该项目完成了客户交给的开发工作，至于为什么开发，又开发了一个什么东西却并不是很清楚。同时，对项目没有进行有效的管理与控制，项目经理在项目组中仅仅是带头开发的程序员，既不是什么项目组织者，也更称不上是项目的管理者。 案例二：“项目”往往回避了客户真正的需求。 客户真正的需求往往需要仔细研究才能获得，系统规划初期，难以发现客户真正的需求。到后期，为了项目的“成功”，总是不得不回避掉那些用户的真正需求，使系统的可用性降低，使我们的整个行业解决方案大大折扣。 问题：所忽略的正是用户所需要的 2001年，曾负责一集团型国有企业的办公自动化项目建设。在两周内，我和一位同事“高效”完成了该系统的需求调研、用户评审工作，得到了该系统的软件需求。 最初，我们并未真正领会所谓的“二级单位OA系统”意味着什么。只是想表示将来的系统可以为二级单位所使用。对于二级单位的需求只是看了一个重点单位的情况，并未做全面、深入的了解。 实际开发出来的系统是单层的，根本不存在二级系统的概念。最初，客户并未马上提出二级系统的需求。系统试运行后一个月，用户提出在二级单位的OA系统如何实现的问题，并提出如下具体要求：
由于当时系统已经建成，我们对该需求进行了技术攻关分析，得出三种方案：
然后，从技术难度、开发成本、所需工作量三个关键指标的角度，对上述三个方案作出如下分析：
经过分析，基于当时项目的进展情况，方案C是容易实施和可以让各方接受的，同时也是与用户的真实需求差距比较大的。 事实上，如果从设计之初意识到用户真正的需求，在系统规划、设计阶段方案B是可以实现的，并且对成本、技术难度等指标的影响并不大。方案C是一种后续的、补救的方案，而不是技术实现上的最佳方案，同时开发商投入更多的成本，最终用户却获得了较低的收益。 后来，该项目赢得客户满意度还不错，这更多地源于我们的工作态度和规范的工作方法、习惯。单从技术实现质量上来考核，该项目不能算是一个成功的项目。 曾负责某行业业务系统的开发工作，当时已经有较为明确的客户需求，规范的行业标准，也有足够的人力，同时是专门的小组进行开发。面临的问题是工期紧：一个月。于是，项目组进行了充分分工：数据库设计独立进行；业务模块分块突击开发。一时间，各项工作齐头并进。两周后出现下列问题：
针对上述问题，在项目经理组织下，项目组采取了果断措施：
同时，项目组开始“赶工”：天天晚上加班、周周周末加班，到月末，只有一个模块开发基本符合要求，其他80%模块不是没有完成、就是必须修改！但经过冷静分析，我们得出如下结论：
通过上述分析，项目组决定，调整、更新原有的计划组（进度、成本、资源等）将最终完成日期定为两个月后。后来，该项目的开发按时完成，但项目组成员回忆起来还是后怕不已。当时项目组面临的局面宛如噩梦、令人心悸！因为不仅仅是高强度的工作、无休止的加班，而且还面临一个最郁闷的情况：加班并不能解决问题，达不到预期的效果。 反思起来，主要是忽略了一个重要的项目管理原则：有些阶段是不可逾越的，否则将为之付出惨重的代价。项目经理在原则问题上必须坚持立场，不能完全被动、机械地执行管理层行政命令。要分析，从技术角度进行分析，得出合理的方案，而不是一味迎合上层领导意图，这样才能对项目做到真正的管控。要不然，难免会让大家有劲使不到点儿上。 该项目需求分析、系统设计时间很短，造成开发目标没有很好地明确下来就开始了开发工作。同时，留给项目组成员的印象是“不想再想起这件事”。 十年前，曾参与实施工商行业某项目，项目开展的从表面过程上看很成功，最后用户也对系统进行了验收，但规模庞大的系统，使用率很低，根本没有起到系统预期的作用，究其原因，主要有以下几点：
单纯从技术上考察、从商务上考核，该项目无疑是“成功”的，但是，没有用户、没有应用的项目又有什么成功可言呢？ 无数开发商都在高喊：“要让用户将系统用起来”。殊不知，要达到这一目标，项目经理和项目团队在项目启动之时就必须学会从客户的角度思考问题，从客户的角度来看待每一个项目活动和项目产品。 曾负责某医药行业项目，通过项目组的共同奋战和“良好”的项目管理与控制，项目验收了。但客户的问题从来没有终止过，虽然客户也承认是自己不断的在变换想法。 可是，反思一下：又何尝不是我们项目组在项目建设初期可能忽视了用户的某些隐式需求，没有提供充分的、足够的设计方案。真的追起责任来，恐怕最终用户有20%，项目组（包括建设单位和客户代表）要占80%。 上边所述的案例都是很普通的信息系统建设项目，反思起来，它们在说明着一些看似“成功”的项目，并不是真正成功的项目。 那么，怎样才是一个真正成功的项目呢？对于这个问题，很难做出被普遍认同的答案。但有一点是很明确的：项目经理作为项目成败的直接责任人，不断总结先前项目的经验和教训，在后续项目管理和控制中不断改进和提高，将有助于项目的真正成功。 本文最早发布于2010年1月希赛网，2018年5月重新编辑。
|
|
|
