EEPW论坛

领导一个新的项目是一种激动人心的经历，也是公司管理层对我的专业水平的肯定。当然，这也是一种让人感到有些紧张的经历。突然要处理一些自己可能并不很了解的事情，这的确会让人感到不知所措。 6月份，烟台港客运售票信息系统的项目正式开始。这是一个实时性非常强的项目，而且功能模块较多（500个左右），但从获取需求信息到正式运行却只有4个月的时间。其中包括基于因特网的远程售票系统，这一部分要涉及到分布式多层应用技术，而这对我们来说还很陌生。此外，还包括公司的网站和Web在线售、订票系统，涉及到在线支付。不得不说这是一个不小的挑战，能不能在限定的时间内按质量要求完成开发任务，我没有确切的把握。 一、需求调研&总体设计 这是我第一次接触这种规模比较大的软件项目，以至于一开始就出现了一些失误。比如，整个项目是在悄无声息中进行的，没有要求管理层召开正式的项目启动会议，开发小组的人员也没有全部到位，甚至于连一份简单的项目计划都没有！ 部门从别的项目组临时抽调了一位项目总监参加我们的需求分析与总体设计，他对业务比较熟悉，参与多个类似项目的研发工作，精通数据模型设计，算是我们中间的内行。初期主要就是依靠他一个人的工作，我们调研小组的其他成员（我和另外一名项目经理）只是协助做一些事情，主要是整理一下材料，与客户做一些简单的沟通。 需求调研工作一共进行了三天！现在想起来都觉得不可思议，这个阶段工作结束的时候形成了一份非常简单的《用户需求说明书》，其实只是一份功能清单，连功能描述都没有。当时项目总监出差，我们负责项目的另一个项目经理也被调去参加其他项目的实施工作，实在没有人力来完成规范的需求文档。 很快我们进入总体设计阶段，项目总监开出了一份数据模型设计文档，包含了基本表和另外十几个核心业务相关的表和视图，罗列了几个关键的存储过程和触发器。此时，我也根据与用户的沟通做出了关键模块的用户界面，对功能也做了第一次大的调整。然后我们召开了一次正式的用户沟通会议，在功能设计上与用户取得了一致意见，此时项目已经进行了一个多月的时间（40天），人员基本到位，项目逐步进入正规。 二、详细设计与编码 根据公司的ISO9001文件，我们必须做出比较详细的《详细设计说明书》，这样的一份文档起码要有几百页。但是，由于我们是第一次接触客运售票这种业务，我个人认为不可能做出非常好的详细设计，因为我们对业务的认识程度不够，设计上可能会存在很大的不确定性。因此我不支持在详细设计的文档上花费太多的时间，我们把更多的精力放在核心功能模块的分析设计上。我们不断的围绕航班、售票的数据流进行讨论，同时对售票的并发、实时控制进行详细设计，对装车的算法反复论证，做优化设计。设计结束的时候，我们得到了一份核心模块的功能设计文档，开发人员对他负责的功能模块相关的业务也基本熟悉了。这就是敏捷设计，在兼顾规范的同时，更注重实用性，更注重核心功能的把握。 一切顺利，在大家的艰苦努力下，我们顺利完成了本地网售票系统基本框架的编码工作。太令人高兴了，我告诉团队的成员，我们可以休息一下了。但是，麻烦就在这时候出现了。 三、迭代开发阶段与项目的延期 9月份，终于完成了售票系统的“毛坯”，我们抢了整整两个周的进度，这是前个阶段辛苦的结果。 按照计划，我约请客户代表来看程序，提意见。我们每天接待一批客户派过来的测试人员，他们都是客户方各个部门的业务骨干，每天看一个子系统。毕竟是一个毛坯，客户的意见不小，而且对于业务规则，各个部门之间又产生了争议。 恰恰是这个时候，我负责编码实现的远程售票管理系统遇到了技术难题，致使进度明显滞后，而这个子系统是必须和本地系统同时启用的，如果不能完成，整套系统也就不能按计划切换，这成为影响进度的瓶颈。我当时接触Delphi只有两个月的时间，然后就直接切入COM/DCOM/COM+方向的编程，经验非常匮乏，公司内部也没有人能够给与指导。我当时特别紧张，一连几天严重失眠，整晚上睡不着觉，头脑也麻木了。 项目组的开发人员都非常努力的工作，但项目的进展缓慢。那段时间，我一直在为远程售票系统的开发查资料，想办法，只是希望我们的开发人员能够认真地对待客户的意见，及时解决。这真是一个艰苦的阶段，原本平静的局面又变得杂乱无章。虽然临近结束，却怎么也结束不了。程序在反复的调整，我们反复经历了多个“几乎完成”的状态，但是仍然有很多人在抱怨他们要求的功能没有实现，或者与他们的期望有出路。 用户的意见终于反映到管理者耳中，“问题出大了”，我们几乎要被客户投诉。公司上层管理者也找我谈话，给我不小的压力。问题必须立即解决！首先要冷静下来，仔细的分析一下，问题都是出在什么地方。我们认真的整理了客户的每一条意见，分类归纳，最后得出结论，项目的主流程是正确的，问题绝大多数都在操作习惯上，比如，有一些快捷键与原有系统有些区别，另外，因为有些业务的调整，致使一些操作过程发生了变化，有些操作人员对业务的调整并不了解。由此看来，主要的问题还是在于跟客户的沟通不够。我们立即着手解决这些用户界面层次的问题，不久召开了一次用户座谈会议，澄清问题，同时把一些业务上尚未确定的问题解决了。 领导决定项目延期一个月，同时为我们开出了一个里程碑，一定要在10月25日解决所有问题，进入试运行状态。我们加班加点的工作，我的远程售票系统也取得了较大的进展。终于，20号左右的时间，我们基本完成任务，除了个别存在问题的模块尚未完善，绝大多数都已经做到流程正确、数据无误，已经可以投入运行了。 又经过一个月的测试，我们成功的解决了剩下的所有问题，用户培训业已完成，大家都在等待着正式运行的那一天了。 四、终于正式运行了！ 11月25日晚上12点，这真是一个令人难忘的夜晚，我们历经5个月辛勤劳动的成果终于登上了舞台。随着一个个运行良好的消息传来，我们终于胜利了！ 这是一个不规范的项目管理案例，但项目结果却是皆大欢喜。总结得失，展望未来，我感觉这个项目之所以能够成功的完成，主要得益于以下几点： 一、负责项目总体设计的项目总监对业务比较熟悉，建立的数据模型比较合理。 二、人力资源配置比较合理，能够做到“人尽其才，优势互补”，发挥了每个开发人员的特长，把核心的功能模块化分给主程序员完成。并在总体上形成以“航班---售票---财务”三个中心，分别由三个程序员来完成。 三、融合“XP”（敏捷设计）的项目管理思想。在开发中不断迭代，消除需求不清造成的设计失误。减少形式上的文档，注重核心模块的讨论，设计。对核心功能深入分析，多次讨论，做到一个功能模块由谁负责开发，谁就要对周边业务十分了解，编程思路的方法非常清楚。 四、技术难度较大的模块选择有特长的人单独完成。在这个项目中，我负责了分布式多层方面，也即远程售票系统的开发工作。这样安排既有有利的一面，也有不利的一面。一般而言，负责项目管理的人员不应该在安排做较多的编码工作，尤其是技术难度比较大、功能复杂的模块。但是，由于我在软件体系结构上的能力使我很快拿下了这个技术难点，成功的完成了该套系统的开发工作，当然为此我们也付出了许多管理上的代价，客户因此抱怨彼此沟通时间较少。 在项目结束后，整体考虑，也发现了一些问题，这主要是： 一、项目启动以后，没有召开正式的项目启动会议，以至于项目进行一个多月以后，都不能明确谁是项目的主要负责人。这不仅束缚了项目管理人员能力的发挥，缺乏管理层赋予的威信，而且，造成权责不明确，用户找不到合适的联络人。因此，我认为不但要召开正式的项目启动会议，明确责任，公布项目计划等信息，另外，还需要公开张贴出项目已经正式启动，以及项目领导组织结构等信息。 二、开发人员没有参加需求调研活动，仅靠文档和转述无法对业务形成深入的理解，往往造成开发中的失误。进入总体设计阶段，开发人员还没有全部到位，也给开发进度造成了一定影响。 三、项目进行中缺乏有效的激励措施。尤其是在开发阶段，为了保证10月份的正式运行，以超常规的方式加班加点工作，晚上加班，周末不休，每周的任务量是平时的两倍多。特别是整体框架完成以后，让用户介入系统的测试，用户提出不少不足的地方，反复多次迭代开发，开发人员非常辛苦。但是作为项目管理人员只能从精神上来鼓励，缺少其他可以依循的激励保障措施。久而久之，大家也就没有热情了。因此，我认为应该促请公司高层管理者制定一系列的“激励政策”，在适当的时机给开发人员“加油”！另外，作为项目经理也应该掌握更多的激励技巧，特别是在士气低落的时候，能够重振士气，带领大家把工作做好。 四、在实施中如果业务规则不清应该立即解决。作为项目管理人员要及时控制项目中不确定的因素，让问题暴露出来，然后分类整理，并与客户交流取得一致意见。如果设计到多个部门的问题，还需要召开各部门参加的联席会议，在会上集体讨论形成决议。一定不要久拖未决，以免影响项目的整体进度。 附：烟台港客运售票信息系统开发 人员配置： 项目总监一名：借调，完成项目分析 项目经理一名：负责项目管理、远程售票系统研制开发 开发人员三名：负责航班、售票、财务三大系统的开发 测试人员数名：主要由客户组成的项目领导小组负责 开发进度： 需求调研：6 月1 日 — 6月4日 总体设计：6 月4 日 — 7月10日 详细设计：7 月10 日 — 7月20日 编码实现：7 月20 日 — 8月30日（完成框架） 迭待开发：9 月1 日 — 10月25日（相当于实施阶段） 试运行： 10月25日 — 11月20日 正式运行：11月25日 —