TJS_IMIS项目经历

2002年10月，也就是刚开始研究生学习不久，我迎来了一个新的挑战。导师接到一个特种设备监察检验所的信息集成系统，由于实验室只有我和一位博士师兄有相关的项目经验，我的企业应用开发经验似乎更胜一筹，导师把项目管理、系统架构的重任交到我手上。对当时的情景印象非常深刻，导师在开会讨论时简单介绍了项目的情况，然后提名让我做PM，当时有几名博士和硕士师兄师姐以及同级的同学

一共六七个成员在场，大家一致通过。我知道我是凭借着以前的项目经验得到导师的赏识并委以重任，虽然充满信心，但也有些紧张。虽然我有超过两年的企业应用开发经验，但作为项目管理人员，还是头一遭。以前对项目管理的认识都是停留在理论和观察上，现在则是来真的了。当时我刚完成工作流定义工具的开发，还没歇会，研究生课程也比较紧，这真是一个巨大而全新的挑战。我给自己打气：这是一次挑战，也是一个机会。我花了几天时间整理总结了过去的项目经验和对项目管理的认识，然后跟导师确认了项目能安排的资源。

以前作为项目组成员，总是由一个team leader带着，现在自己也要成为team leader了。我相信自己一定行的，成功属于有准备和努力的人。我花了一个星期的时间去特检所做了系统调研（由于特检所跟学校不在同一个城市，一次调研要跑好几趟，真是累啊），基本上了解了特检所的总体要求，他们希望能有一个信息集成系统，包括内部信息管理系统负责管理所内日常工作，信息发布系统负责对外发布信息，电话查询系统提供对外查询接口，移动办公系统辅助技术人员外出工作。花几天时间对调研情况进行了整理，并通过参考和比较选定了几种关键的技术，完成初步的调研报告和技术方案，提交给导师（项目监督，呵呵），然后重重松了口气。来回奔波确实很折磨人，虽然以前也经常出差，但象这次这样奔波倒还是第一次，不过还是很有成就感。在确定技术方案的时候，我参考了大量资料和案例，也咨询了一些经验人士，并根据项目组开发人员和特检所的实际情况（成本、已有资源，工作方式等），给出了几种技术方案和重点推荐方案。由于内部信息管理系统只是在所内部使用，而且客户端数量不多，我选定了C/S作为系统的构架，虽然从长远角度来说应该考虑系统的兼容性而选择先进的B/S架构，但考虑到技术风险、技能风险（开发组成员都是第一次参加正式项目）、成本等因素，C/S仍是首选。而简单的信息发布系统则可以用ASP+IIS搞掂，无须额外的应用服务器，虽然涉及到少量提交页面，但访问量着实太少，性能和安全等问题基本上可以不用考虑。至于移动办公系统，由于客户给出的预算着实不是太充裕，秉着节俭实用的原则，同时考虑客户的员工素质，选定了以PDA作为数据录入、存储、查询设备，通过PDA与工作计算机交换数据的方案。电话查询系统则只需选用价格适中的电话交换机设备就OK了。

调研报告提交后的几天，我开始着手准备项目计划事宜。当时可以参与项目的成员有七个左右（包括我在内），其中只有一个博士师兄有过工作经验，但他不会有太多的时间投入，其他的成员都没有实际项目经验，只是学过程序设计课程，做过课程设计，而且熟悉Delphi的偏多。我根据系统的规模和大致需求，以及开发资源，估计了可能存在的风险，确定了项目时间为六个月，其中考虑到分析设计人员有一定经验，而开发人员存在技能风险，将需求分析/系统设计时间定为60天，编码/单元测试90天（采用迭代开发模式），整合测试/培训/实施30天。虽然之后由于一些估计不足的风险（项目组成员全部是学生，存在不稳定因素）导致项目时间有所调整，但项目进度基本上在控制之中。

当项目正式立案签约后，就要开始需求分析了。在我带一个成员进行需求分析的一个月里，我才知道调研那段时间所受的痛苦是那么的轻微，与客户沟通+文档整理+来回奔波+学业+技术培训，真正让我体验了工作的艰辛。在需求分析的同时，我整理了以前积累的技术文档资料以及系统框架对项目组成员进行了培训，并让一个基础较好的成员作为助手，指导开发人员熟悉相关制度、文档和代码规范、系统框架、版本管理知识等等。需求分析期间，我体会到了沟通的重要，也提高了自己的沟通表达能力，虽然这是第一次接触的业务，但通过反复沟通，我基本上了解了整个业务流程，同伴主要负责部分部门业务细节的沟通，也较好地完成了任务。幸运的是，客户的高层领导非常重视这个项目，创造了良好的环境配合我们的工作。在与用户沟通的时候，也遇到了一些问题。尽管他们一直都在用系统（用foxpro开发）辅助工作，但他们对计算机的了解程度还是比较低，在沟通时，时刻要注意不能使用计算机专业术语，而应该用他们领域的语言描述需求，编写需求分析说明书时只能使用用户的语言。部分用户对他们本身的需求比较模糊，这时候需要结合他们的实际工作和信息系统的功能进行分析解释，让需求逐渐清晰。同伴非常认真负责，学习能力也很快，我们通过努力按时完成了需求分析。需求分析说明书提交给客户后，我并没有松口气。根据以前的经验，客户是非常相信软件开发方的，要求他们在需求分析说明书sign in时，他们会立刻签名的。他们相信开发方已经很好地理解了他们的需求，但事实上可能并非如此。我与导师一起跟他们说明了具体情况和风险，要求他们认真审核我们的需求分析说明书。客户也表现出了较高水准，他们花一个星期的时间对需求进行了确认，并最终签字通过。虽然后来需求也发生了一些小变化，但总体来说，当时的需求分析是非常成功的，基本上没有影响项目

进度。后来项目庆功会的时候，老板（导师的昵称，呵呵）特别强调了需求分析的成功和所起到的作用，我被一再点名，弄得怪不好意思，J。回想起来，在整个需求分析过程中，过去项目经验起了重要的作用，但我其间经常向一些有经验的前辈学习并且抽空学习相关的文档资料和软件工程书籍，保持思考，更是起关键性作用。整一个过程是我对以前经历总结的过程，也是不断学习、思考的过程。能在工作中不断学习、进步，这是最让我兴奋的。

当需求分析完成的时候，出来的成果不单是需求分析报告，还有一帮摩拳擦掌的兄弟姐妹。经过培训和他们自身的努力学习，他们已经不再是雏鸟（他们的用词是“菜鸟”，呵呵）了。我看过他们的代码，与他们就开发过程的看法进行了交流，发现他们真的是学习和理解能力非常强的人，“手下”高手如云，我对这项目越来越有信心了。

下一步是系统结构设计了。划分功能模块是首先要考虑的问题。 “高内聚，低耦合”是模块划分的原则。我根据这个原则按照他们提出来的四个业务需求，将信息集成系统划分为四个子系统：内部信息管理系统，信息发布系统，电话查询系统，移动办公系统，他们都存在轻度的数据耦合。其中内部信息管理系统是最复杂的子系统，根据他们内部部门的划分和工作之间的联系，划分为八个大的模块：系统维护、人事管理、公文流转、质量管理、检验管理、财务管理、仪器与资料管理、报表管理。这八个模块耦合程度低，而且高内聚。四个子系统共用一个中心数据库，选用MS SQL SERVER，达到数据共享，不会出现信息孤岛，很好地解决了旧系统存在的问题。鉴于他们的统计报表、证书的格式经常可能发生变化，我设想专门独立一个报表管理模块，为系统管理员提供一个修改报表格式的工具，随时可以修改报表的显示格式；并且提供一个查询管理工具，系统管理员可以无须编程就可以定义查询条件和显示的内容，这样就提供了这样一种可能：系统管理员可以控制不同的用户使用同一个查询功能得到不同的结果显示（调用不同的查询条件和显示结果要求）。在编写设计文档过程中，我经常召集项目组的成员开小组会议，提出我的想法与他们进行讨论，大家各抒己见，逐渐完善系统总体设计说明书。我在参考一些流行产品的系统结构和界面的同时，也根据自己的经验提出自己的新思路，得到导师、师兄和客户的肯定和支持。后来事实证明，这个系统的结构保证了整个系统稳定运行，而且速度、性能、工作效率都完全满足客户的要求，得到客户较高的评价。确定了系统的总体结构后，我设计了系统的用户界面，并提交原型给客户。客户在项目开发工作尚未正式开始之前，就了解了未来系统的全貌及以后的工作方式，他们对此给予了肯定。

开发工作正式拉开了序幕。在正式开发之前，我与开发人员统一了思想，每个成员负责一到两个模块的开发，强调重视单元设计文档、单元测试文档的编写，我特别强调了单元测试的重要性（即使如此，还是有些开发人员在前期忽视了单元测试，结果测试人员进行模块整合测试时发生许多错误，不过后来经过多次沟通，基本上开发质量得到了保证）。开发过程中，每周我组织两次项目组会议，周一成员汇报计划，周五总结一个星期的工作；还建议通过不定期的小组讨论进行交流，解决遇到的难题。开发人员都感到通过交流可以学习到很多新的东西，也加快了开发速度，减少不必要的错误，避免了走弯路。Teamsource的使用保证了版本管理。我在承担一定开发工作的同时，将主要精力放在以下方面：协调、监督组员的工作；监控项目的进度；与客户、导师沟通；组织定期的项目组会议。其间我们也遇到了一些困难，但通过大家的共同努力，还是克服了种种困难，保证了开发进度基本上按计划进行。开发前期，我向导师多要了两个没有任何开发经验和编程基础的同学（之前因为没有编程基础所以没有加入项目组），让他们熟悉系统的需求，配合开发人员的单元测试工作。在后面的整合测试中，他们也起到了中坚作用。其间我向导师建议与客户方商量派一个用户定期过来测试已经成型的模块，这个措施也保证了系统一直沿着正确的方向并且按照时间进度计划前进。经过两个半月的开发工作，具备大部分功能的系统已经出来了，我提出花几天时间对系统进行整合，形成第一个完整的测试版本，在我们测试过后提交给用户进行测试。这个提议得到导师的赞同，这样接下来的时间里，我们继续完善系统的功能，而客户则可以抽空对我们的系统进行测试，并及时向开发人员反馈他们的意见。也许是当初需求分析做得细致的缘故，客户在测试过后只提出了少量更改意见，这对我们项目组的成员是莫大的鼓舞，而我更是兴奋不已。但我没有放松，我知道现在还没有真正成功，在后面还有很多重要的任务没有完成。在最后的一个月时间里，我们没有松懈，根据用户的反馈和要求继续完善系统功能。直到最后交付给客户正式使用后，我们还是或多或少对系统功能进行了变更和完善，毕竟需求不是一成不变的。整一个开发过程体现了我们的团队合作精神和认真负责的作风。每一个项目组成员在后来的项目总结中都表示学到了很多书本上学不到的东西，为以后的工作积累了宝贵的项目经验。他们全部都对我表示了感谢，我有一种苦尽甘来的感觉。

开发过程比较顺利，但最后的系统交付却出现了一些问题。系统培训时，客户方的用户由于工作任务比较繁重，对培训产生了抵触情绪。开始通过行政干预（让客户方的高层领导出面），但上有政策下有对策，他们终于全部出席参加培训了，但身在曹营心在汉。我知道如果用户得不到培训的话，使用系统时会出现很多不必要的麻烦，特别是我们与客户不在同一个城市，不能做到及时的“售后服务”。我决定和那些用户进行交流，交换一些观点。我首先征求他们的意见，发现他们没心机参加培训的原因之一是他们认为一直在用计算机系统，新系统也相差不了多少。我针对他们的这种看法，大概介绍了新系统的思想和工作方式，引起了他们的兴趣。我趁机指出新系统与旧系统在工作方式和流程上的区别，强调熟悉系统对提高工作效率的作用。本来我是抱着试试的态度，没想到却收到意外的效果，可能是他们对我比较信任的缘故（他们认为“研究生，很厉害的”，呵呵，而且在需求分析期间，我也跟他们混得比较熟），而他们对领导却有些抵触情绪。我发现通过这个项目，组织、协调、沟通、表达能力都得到很大的提高，而且好象还有些“个人魅力”（通过表扬、鼓舞，大大提高了开发人员的工作效率和热情），呵呵。

随着培训的结束、系统的上线，这个项目也该画上个圆满的句号了，尽管还有一年的维护期（虽然我一直强调“服务”的概念，但对于这个系统来说，那些维护工作都是轻量的了，而且我已经培养出一大批人才可以胜任这个工作了，心里美滋滋的，呵呵）。这是我第一次作为team leader，就获得了成功，我知道这不是靠运气的，而是自己不断学习，不断总结，并充分调动开发人员的积极性和发挥他们的优势的结果，这是团队合作的成功，其间所经历的艰辛让我至今难忘，而所学到的东西、所取得的进步却是一笔巨大的财富。后来到特检所时，听他们领导介绍，我们开发的系统在省内同级单位中处于领先地位，某些工作方式甚至是国内首创。