信息系统项目管理简谈

项目管理是一个持续并且包括繁多事情的工作，一个项目的成功与项目的管理存在必然的关联，所以项目在执行过程中项目经理要做好各环节的管理工作，避免出现较大问题。项目管理过程包括众多的环节，下面结合个人的一点项目经验简谈一下项目管理的环节中要做的事情及问题，当然列出环节并不是完整项目流程，但这些环节在国内项目中需要经历的，如果想了解完整的项目流程可以参考相关的资料，也可以参加项目经理资格考试。

一、项目启动

1、项目招标

政府的项目招标是需要委托招标公司并将项目建设要求发布到招标网站，以便相关承建企业了解项目信息。我知道的招标公司有五矿国际招标有限责任公司、北京国际招标有限公司。当然很多项目其实在内部就定了项目建设单位，发布项目信息只是为了走相关流程，让项目符合相关规定。貌似现在政府较大的项目都得走项目招标流程，但我在做的项目中也有些较小的项目直接由政府或者事业单位拟定好项目后，由自身指定建设单位进行建设。本篇文章按项目的规范流程进行描述。

招标信息

招标信息是指向外公布的项目招标公告信息，是通过招标网站进行对外公示，招标信息会包含采购人名称、采购人的联系方式、招标的编号、项目的用途及性质、投标人的资格要求、项目价格、开标地点、评标方法和标准等等。

评标专家

评标专家是对投标人的投标内容进行评分的多人团体，是从指定专家库中抽取若干人，在项目开标时对投标人的投标内

容 进行评分，所以投标人是否能中标，这些专家起到相当大的作用。当然在项目后期的需求评审、设计评审、项目验收中也

可能需要这些专家，这得看采购单位的要求。

2、项目投标

项目投标是指投标单位按项目招标要求在规定的时间内向招标代理单位购买招标文件，并在规定的时间内将编写的投标文件提交到招标代理单位，投标文件中的内容通常包括投标函、开标一览表、投标分项报价表、商务条款响应及偏离表、技术规格响应及偏离表、技术详细方案、承诺书等，具体要求还是得看采购单位的招标要求。投标文件提交完后，一般当时招标代理单位就会唱标，唱标是公布各家投标单位的单位名称、项目报价、建设周期等，有的项目会要求现场讲标，由评标专家听取及提问，然后投标单位就回去等中标结果，一般几个工作日就会公布。下面再详细描述一下项目投标几个主要环节：

购买项目招标文件

购买项目招标文件是指投标单位了解到项目招标信息，在规定的时间及地点进行购买项目投标文件，也就是直接去招标代理单位购买标书，购买招标文件不是只买本文件回来，同时也会在代理单位进行记录，你有资格进行投标该项目，反之则没有资格。支付的金额一般会在几百块钱，总得让代理公司搞的零花钱（嘿嘿）。

编写项目投标文件

这里只简单说一下要注意点，如果要详细说可以写出一篇很长的文章出来，第一投标金额不高于项目招标金额，否则直接废标。第二投标分项报价表很重要，一定得按招标文件中的要求进行整理，否则也可能废标（得看招标要求）。第三技术详细方案的大纲要按招标文件的目录结构进行整理，这样最少不会让专家找到明显扣分理由，专家不可能仔细看你的方案内容，他也看不懂。第四如果有承诺书要求，一定得按要求格式进行整理，并盖公章，否则也可能废标。第五，如果有讲标要求，一定得好好整理讲标ppt，专家看的高兴了可能多给你一些分。

投标文件整理

投标文件整理主要是将编写好的投标文件打印好，一般是一个正本和几个副本，也会要电子版，这里需要注意的是将投标文件进行封包，封包一般会有点要求，所以要封包时要仔细看一下招标要求。封包完后就可以直接提交了。

3、合同签定

指项目中标后，一般会要求在规定的时间内进行合同签定，合同签定就和代理单位没有关系，而是项目采购单位和项目建设单位进行签定，合同内容主要包括商务条款及项目要建设的内容，一般会把投标文件中的技术方案附到合同中，所以在编写投标文件的技术方案时，也不要写的太夸张了。合同签定后就可以开始执行项目了。

二、项目执行

1、需求调研

需求调研是指对项目建设要求进行细化，需求调研主要与采购单位直接使用部门进行需求沟通，毕竟项目交付成果是交给这些用户进行使用，所以这些用户提出的需求才是真实需求。需求调研使用的方式主要有面对面交流、了解用户当前环境因素情况等，最终形成需求规格说明书并进行需求评审。需求评审由采购单位相关部门和建设单位参与，采购单位也有可能邀请专家进行评审，让专家把握需求内容，尽量保证需求科学、实际。

需求调研承建单位通常需要安排项目经理和需求分析师来负责，但最好系统设计人员也参与，以便后续设计工作有利进行。 下面再对需求调研工作要注意的点进行细化描述。

需求交流人群

需求交流人群一定得是项目交付成果的实际操作用户，避免需求与实际操作人员理解有偏差，导致后续麻烦问题。

设计图与原型

在需求交流前，提前整理好相关的设计图及原型，说白了用户也只能知道他们大致想要一个什么东西，但是再往细里说他们也不知道，或者是用户根据就不知道他们要想要一个什么东西，如果能有设计图或者原型，在交流时能起到事半功倍的效果。设计图及原型是目标靶子，交流起来会方便很多，也能避免相互理解的偏差。

需求控制及引导

需求控制及引导是指在需求调研的过程中尽量承建单位有利的方向发展，不但让需求满足用户要求同时也节省建设单位的投入成本。需求控制及引导其实说起来容易要做起来还是不易，因为需求不单是需求调研过程中有，也可能在项目开发过程经常有变化，所以只能出现问题时多考虑、多交流。

2、项目计划

有计划才有目标，所以项目在执行的过程中，项目计划尤其重要，前面所做的需求调研也是作为项目计划的一部份，这小节重点说一下开发计划，开发计划是将需求拆分为功能点来排到开发计划中、并设立项目里程碑、如果项目较大时，一般会设立多个里程碑，按里程碑交付成果，最后就是项目验收，项目验收一般分为预验收及终验，预验收和终验不只是交付成果，其实也是项目付款的时间节点。项目终验完后项目也就结束了，后续就根据合同要求履行维护职责。项目验收有不少工作要做，后面有相关的章节进行描述。

开发计划制定

开发计划制定一定得严谨，因为这可能成为采购单位的约束交付成果的时间，但有点小的偏差一般也不会有问题，但是时间上能多预留尽量多预留，项目经理在制定计划后，需要和项目分工负责人进行交流，保证项目计划更准确。

里程碑

较大的项目一般会划分为多个里程碑，具体还是得看用户的要求来定。本人觉得项目里程碑也不宜过多，因为项目不但得交付里程碑的成果，同时还得继续完成后续的任务，如果在交付里程碑成果时，用户有些延时，会增加项目管理上的工作。所以里程碑能少就尽力少，当然项目经理在制定里程碑时得根据实际情况进行制定。

任务跟踪

任务跟踪是跟踪项目团队完成任务的情况，我一般是通过查看团队成员提交任务的结果进行跟踪，可能是做开发出身，能够直接运行任务的结果。但是在任务跟踪时一定要保证时间及质量，很多时候为了保证任务时间，质量降低了要求，我做了不少项目都是这样，这给项目的后续埋下了很多坑。所以我觉得任务要及时跟踪，避免到任务要交付时才发现质量问题，这时要保证质量已经来不及。后面会有相关章节描述来保证任务质量，这里就不多说。

3、系统设计

系统设计包括的工作有系统架构、功能结构设计、技术选型、将需求转化为功能点等。系统设计作为开发前的工作，是保

证系统质量、灵活性、扩展性的关键工作，所以项目在系统设计阶段一定要重视，尽可能安排技术经验及行业经验丰富的工程

师进行系统设计。

设计规范

我们在很多方案或者设计文档中都有相关的章节进行描述建设成果是采用什么标准、什么规范，这些也都是凑文字、过

评审

，在实际设计时未必会做过多的考虑，当然项目各有各的情况，比如有些很紧急的项目，确实也考虑不了太多。本人在实际的项目中也碰到过各种项目情况，所以总结一下，本人觉得设计阶段不可缺少的成果为系统功能原型、数据库设计及文档、系统详细设计文档、关键功能设计图 、接口设计文档 ，这些设计成果如果缺失会对后续开发带来影响。其它的设计成果还包括概要设计文档、设计图、网页设计稿、程序结构设计等。这些文档也都为开发过程起到比较大的作用，为开发人员提供理解及要求作用。

设计细致化

本人在做项目过程中，在项目后续碰到系统质量（代码及功能）没有预期的理想，后面反思觉得导致的原因是项目组人员性格、背景、责任心不同，同时项目组成员也可能有人员调动等，由于这些原因导致项目到后期出现不好挽回的余地。所以本人觉得在做设计时尽量做到细致，让项目组成员更好的理解需求及制定开发更细的规范，保证项目交付成果的质量，减少项目成本。

4、源码

源码一般都是项目交付成果，也是项目成果质量的重要元素，所以源码的管理及设计非常重要，源码会影响项目的成本、用户满意度、甚至项目成败。源码决定着系统的发布版本、多任务同步开发时的源码版本控制，这些都影响着项目的时间、成本、资源。

代码规范

前面说的代码质量，对代码的质量控制需要做好代码规范，这就需要在项目开发过程中制定相关的编码规范，编码规范包括代码编写要求、代码结构要求等，这样就能够尽量保证代码的编写风格统一、系统性能和代码可维护性等较好。减少项目后期出现扩展及维护问题。本人做过的项目就经常碰到每个人编写风格不一致，代码结构也凌乱，本来设计时某些程序应该放到哪个目录下或者如何编写，结果却不是这样，为项目上线及后续带来麻烦。

代码分支/发布版本

代码分支/发布版本指的是在源码管理时建立任务分支和发布版本，这主要为多个任务同步开发及发布版本时用到，通过代码管理工具分支功能能够比较好的解决此问题。本人做某项目时就碰到多个任务同步开发，客户要求多个任务在比较相近的时间点上线，但我们知道上线后又不能保证没有bug，如果同时开发新功能又修改bug，很容易导致更大的问题。所以这种情况下通过代码分支管理代码是比较好的选择。

代码检查（codereview）

前面说到了规范来约束代码质量，但是光有规范真的开发人员会遵守吗？前面也说到了每个人的背景、理解能力、责任心都不相同，所以不能保证所有人都会遵从规范要求。这时代码检查就很重要了，虽然代码检查会花费核心开发人员的时间，但是没有这层把控也将给项目带来更大的问题。

5、人员

创业家都认为人才是企业最重要的资源，项目也一样，所以项目成员的战斗力、合作力、效率等都和项目息息相关。

兵种

在项目执行过程中项目成员包括的兵种主要有项目经理、需求分析师、系统设计师/架构师、UI设计师、网页制作、开发工程师、测试工程师。项目启动前包括商务（销售）、产品经理（售前），项目完成后会有服务工程师（售后）。在实际项目执行过程中，经常出现一个人身兼数职，比如本人就经常身兼产品经理、项目经理、需求分析师、设计师、开发工程师，尤其在较小的单位，大的单位责任会更明确些。如果有兴趣且有机会尝试一下其它角色也是可以提升一下自己。具体的兵种的职责看名称应该能明白，这里就不做过多的描述。

任务安排

任务是分配给项目组人员的具体工作，本人觉得开发任务要尽量明确、详细，减少项目组人员在理解上的偏差。特别

是开发任务要配合系统原型与设计图，以便开发人员更能理解开发任务，如果复杂的任务，还需要召集项目组人员开会进行讲解

，保证任务按期望的目标进行完成。

前面说的是任务安排要注意的事项，这里再说一下要对任务定期检查，定期检查的好处首先是检查任务是否偏离项目开

计划，其次是检查任务是否偏离预期结果，如果出现问题项目负责人可采取措施及时处理，避免问题更严重的风险。

人员士气

这里人员士气主要指的是项目组成员的工作效率、工作积极性方面，要提升项目组成员的士气，必须要保证每个项目成员

的工作任务明确、体现每个成员都有自己的价值，在项目频繁加班的阶段要尽量保证成员的休息时间，同时在对外 时 要维护项

目组成员的利益，避免人员带着情绪或者抱怨工作。项目经理要尽量向上级争取项目奖金，为项目组成员争取最大的 利益。

软件行业公司众多，外面有无比多的机会，如果人员没有及时关注到，可能就出现人员离职情况，给项目带来比较大 的风险，

所以项目经理要及时关注和了解，以便提前做好准备。

团队合作

团队合作指的是项目组成员在执行任务时，要和其他人员配合才能完成任务目标，所以项目组人员间的配合、沟通就很重要，不要出现相互推卸责任，更要减少冲突。如果项目中出现此类问题，项目经理要及时进行处理及协调，认真分析问题的根源，如果协调能解决此问题当然最好，如果无法协调，问题一直出现 ，项目经理则要分析问题出现在哪方，应及时采取替换人员，减少项目的风险。本人就在项目中遇到过此事情，当时问题的环节出现在美工UI和前端页面制作人员间，经常出现美工UI提供UI图，前端制作人员总反馈有问题，给页面制作进度带来延误，但是美工UI又觉得没问题，所以经常发生矛盾，本人经过认真分析，觉得美工UI人员工作态度确认有问题，不愿意修改反馈的问题，就找理由推卸。所以我在项目任务相对松的阶段果断将美工UI人员进行替换，解决了项目后续这个节点的问题。

团队合作还体现在工作职责及任务的互补上，如某个任务因人员要请假或者任务延时，这时项目经理要及时考虑是否有其它人员相对空闲或者其它任务相对没有那么紧迫，须将其他人员及时补充进去。当然在做这种安排时，要和相关人员做好沟通，避免出现误解，影响人员的士气。

6、质量

代码质量

代码质量决定功能质量、系统维护性及扩展性，代码质量的好坏取决于开发人员，但是在项目的管理上可以增加相应的约束，如制定代码规范、代码检查、提高开发人员的代码水平。前面2.4节已经描述了代码的质量控制，这里就不在重述。所以项目经理一定得重视代码的质量，避免给后期的项目带来麻烦。

系统功能

信息系统项目中正常都需要项目测试人员，即质量保证员，测试人员的工作主要是测试系统流程及功能，保证系统功能的稳定可用，如果并发性要求高的系统还需要做性能测试，这对测试人员水平要求更高。下面分别说一下系统功能测试及性能测试。

系统功能测试主要是对系统流程及功能测试，这里想说明一些注意事项，首先要让测试人员理解整体业务功能需求，以便测试人员能够全面测试及有针对性测试。其次需要测试人员前期整理相关的测试用例，这样也才具有目标，项目经理、需求分析师、设计人员，也能了解到测试哪些功能点，确认是否有遗漏。再次一定要强调开发人员要做好相应的单元测试，避免交给测试人员的系统版本出现无法测试的情况。

性能测试主要是对系统功能的并发性测试，并发性测试时测试人员需要根据功能要求拟定压力测试的功能点，同时性能测试的结果与众多环境相关，所以测试人员要和开发人员或者设计人员配合好，也可提出相关的要求，比如服务资源的配置、网络要求、如何提升用户比率等。性能测试是一个反复调优的过程，并不是一次测试就能得到比较理想的结果。

系统升级

系统升级是指用户已经上线了一个版本，将升级到更新的版本，并不是系统首次上线。所以系统升级一定得要保证系统的可用性及稳定性，避免因为上线而导致系统无法使用。系统升级时得注意的事项，首先一定得做好系统程序、数据的备份，保证有版本可退回。其次系统升级完后一定得做全面的流程测试及功能测试，保证新版本功能的可用。最后系统升级过程一定得重视，升级过程中一定得安排相关的人员待命，最少要包括核心开发人员及测试人员。

本人就在实际的项目中出现过系统升级后核心功能无法使用，导致被用户发现，到最后进行投诉，投诉后还得去查明问题的原因，当查到原因后，用户还不相信问题就这么简单，总怀疑系统的稳定性。所以我反思还是觉得之前不是很重视系统升级的过程，才导致出现问题后带来一序列的麻烦。

7、项目预验收

大项目实施过程中，一般都会有项目预验收的里程碑节点，即项目初验，项目预验收指的是项目交付成果已完成了相关的版本或者交付成果已部份上线的过程，预验收通常需要业主方邀请相关的专家进行评审，项目组要组织初验报告给业主方及专家进行汇报，主要描述当前已完成的情况，后续还需要做哪些工作等。项目验收也是合同的一个时间节点，从商务上来说项目预验收通过后，业主方需要按合同要求给承建方付相应的款，通常为30%左右，所以说项目的预验收是一个较大的里程碑节点。

三、项目收尾

1、项目终验

项目终验是项目最后一个里程碑节点，即项目已完成。项目终验通常要做的两类工作，第一类为处理项目验收事情，包括项目终验汇报、项目中要求提供的文档，如：项目验收报告、使用手册、性能报告、安装手册，如果前面没有提供需求文档、设计文档等，在项目终验时要求全部补全。第二类为合同履行终验，这类工作需要看相关的合同文件，是否在终验时有相关的约束条件，最重要的是业主方需要付终验款给承建方，也是承建方也比较关心。如果项目有分包或者采购，终验时也要履行验收要求及合同要求。

2、项目维护

项目维护是指项目终验后承建方对项目交付物的维护过程，一般合同中也会有相关的要求，项目免费维护期一般在2-3年左右，一般也会要求7x8或者7X24的电话支持，多长时间内解决问题，重大问题需要几天内现场等。所以项目维护期也需要一些成本投入。

四、总结

1、商务关系

国内的项目主要拼的还是商务关系，尤其是政府及事业单位的项目，好的商务关系在项目的执行过程中会较顺利，项目费用也不会少。这一般要看承建方的品牌及商务人员的关系。本人就碰到过商务关系很差的项目，当然在项目中我们也只是分包商，但在项目实际的执行过程要直接与用户去打交道，所以明显感觉到商务关系不好，能在项目中分到的利益相对少及用户态度明显不好。

2、总结概述

前面所描述的是一个比较简单的项目管理过程，本人所描述的是结合自身经历觉得在项目管理过程中可能出现问题地方。实际的

项目管理过程所要做的工作远比这多，有兴趣的同学可以学习或者参加“信息系统项目管理师”的内容或者考试，能扩充不

少项目管理知识。但本人觉得 “信息系统项目管理师”中的项目管理过程，在真实的项目管理中不会全部用到，主要得看项目的

要求及业主和承建企业的项目管理制度，甚至得看承建企业管理的职能类型。比如：像风险的管理、配置管理、绩效管理很少应

用到，当然本人可能没有参与过超大项目或者没有在项目型管理公司就职过，可能不了解。但话说回来管理知识还是要灵活

运用，并不是死搬硬套，而且需要我们去反思和总结，这样我们才能够避免犯同样的错误及预防一些潜在问题，使项目尽量顺利

进行。同时我们也需要将总结的问题分享出去，和有相同经历的人交流或者给学习者一些提示，这样我们才能够共同进步。