经常有朋友问我：你做过甲方、乙方的项目管理，那么甲方乙方项目管理存在什么差别呢？每次朋友想问，我都会有新的感慨和启发。

乙方的项目管理的困难艰辛相信很多项目管理的人员都深有体会，而甲方的项目管理，很多人的印象中是：9点上班，开开会，喝喝茶，5点下班。从我的角度，我觉得挑战最大的是反而是甲方的项目管理。作为甲方项目管理经理，没有体会到甲方有什么优越感，相反，承担的责任和义务大于乙方的项目经理。

为了便于理解甲方和乙方的项目管理，我们以“劳命伤财”出名的房子装修作为软件开发来为例（甲方：房主，乙方：装修队）：
“软件”需求：把房子装修成什么样子？
项目成本：装修完这套房子需要多少钱？
项目进度：什么时候装修完工？

做甲方有两种做法，一种是事事关心，材料、施工一一过问；第二种是放手不管，到时候来验收就可以了。相信做过装修的，一般不会采用第二种方式，否则，偷工减料、内部质量差等问题就可能出来了。前者房主辛苦一些，但装修质量、进度、成本都可掌控。后者比较省事儿，但意外多一些，遇装修队不淑的话，可能发生偷工减料、装修质量得不到保证。所以管理装修项目时，既可以详细到关心乙方施工的每道工序，也可以粗略到只关注项目的首尾。付出的劳动不一样，得到的结果也往往不同。所以甲方乙方项目管理的差别，完全在于你自己想要什么样的差别。甲乙双方做的是同一个项目，甲方乙方项目管理只是同一个硬币的两个不同面。

无数的教训，为什么要做一个好的甲方？

作者：匿名用户
链接：http://www.zhihu.com/question/19894423/answer/86293962
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

这个世界上有很多的甲方也有很多的乙方，我们在生活和工作中，不是充当甲方角色就是充当乙方角色，往往两个角色交替着来。看起来，甲方给钱，在交易中应该是主导地位，那为啥软件外包领域的甲方经常在项目交付的过程中狼狈不堪？

我平时常常充当第三方，看了形形色色的甲方和乙方，也算是看透了：软件开发项目要成功，更多的取决于甲方，取决于甲方的能力，态度，还有期望。项目换乙方不难，但是换甲方，基本就死了。我们常见，公司换一任领导，之前没完工的项目黄掉的可能性极高。所以，做一个好的甲方很重要，我们来谈谈为什么，以及如何做一个好的甲方。

没有人知道你在想什么

这个世界之所以有那么多矛盾，就是因为我们的思想是不透明的（是不是想起了三体人？），没有人知道你在想什么！你找人帮你做软件开发，你得明确的告诉乙方你想做什么，软件的使用场景是什么，解决什么问题。你在你的领域混了很多年，你觉得有些问题很显然，但是乙方没有。你觉得理所当然的问题，乙方可能完全没有听说过。所以，作为甲方，你应该不厌其烦，尽可能详细的说明白你的需求。很多软件项目做出来效果不理想，追根究底都是甲方一开始没说清楚。你不能觉得你的需求很常见，很简单，所以乙方应该理所当然的做出你想要的东西。如果你要的软件真的这么常见，那你就不用定制开发了，直接买现成的。每个需求都是独特的，所以请不要用这样的语言来描述需求“做一个跟 xxx 软件差不多的就行了”。你说你想要一辆车，乙方好不容易做出来了，结果你说其实你想要的是四驱的，座椅加热的，还得是敞篷的。这样的结局只有一个，就是加钱，延期，否则乙方不干，但是你不爽，埋下了不欢而散的种子。

由于国内的甲方大部分不够成熟，所以很多国内的开发者和外包团队都倾向于接国外的单子，包括香港和台湾的。我参与的海外项目，无一例外，都是非常详细的需求文档，并且对接的人非常耐心的跟乙方解释业务逻辑。更重要的是，甲方非常清楚，他的责任在哪里。在出现问题的时候，他会判断这个问题是谁的原因，不会把所有责任往乙方身上推。这是我们值得学习的地方，也是我经常跟甲方讲的需要改进的地方。

一分价钱，一分货

大家都知道买东西是一分钱一分货，凭啥到了软件开发就不是了呢？凭啥要求乙方给你免费干活呢？有些甲方意识不到软件的价值，因为看不见摸不着。所以才有一些厂商把软件装到服务器内再卖高价的情况，因为服务器是实实在在存在的，掏钱就很乐意。显然，这是不对的。定制开发软件的价值就是人工，虽然很多时候计费是按项目收，但实际上也是按人工时间算的，跟装修一样。刷墙看起来是按平米收费的，但实际上也是折算成刷这么多面积的人工来算的。所以你装修的时候刷墙刷完了发现颜色不满意，重刷，不得再给钱么？任何功能的开发，调整都是有成本的，你想在有限的预算内做很多的功能，那你必须接受的事实就是做的比较粗糙，或者你得接受周期拉长，等乙方安排空闲时间帮你慢慢做。

我记得有一个理论是餐馆理论“好吃，便宜，服务好”这三点不可兼得。很有道理，几乎所有的餐馆都不可能兼顾这三点，假如有，那一定会很多人去吃，排队排死，自然服务也就不好了。这条理论放到其他行业也一样，你怎么可能要求软件开发做到“质量好，便宜，交付快”呢？

我是甲方，我是爷？

现实中的交易有时候会存在一种情况，给钱之前甲方是爷，给钱以后乙方是爷，所以才有了所谓的第三方。软件开发由于不是实体产品，很多时候的定义无法完全明确，这样的情况尤其明显。但是，一个成功的软件项目，往往甲乙双方都不是爷，就是纯粹的甲方和乙方，各有各的责任，各有各的义务。乙方作为收钱的一方，对甲方态度好点，耐心一点是应该的，但是特别要强调的是：甲方并不凌驾于乙方之上。先来说点不正规的，还拿装修说事儿。21世纪都进入第二个十年了，然而我们在装修的时候不还是得给装修师傅送香烟么？这是为什么呢？明明给你装修费用了，为啥还得买烟？这是一种态度，师傅你工作辛苦了。结果是，师傅高兴了，活儿干的也快了，质量也好了，横平竖直，保证不偷工减料。有的地方看的见，有的地方看不见。软件开发也是一样，你对乙方尊重，乙方自然会有体会，别的不说，同样的功能，我可以把代码写写好，注释多写点以便后期维护。

再来说点正规的。软件开发项目如果完全按照合同来，估计甲方也有很多小尾巴，大家谁都不让谁事情就很难办。所以把关系处好是有必要的。还有，软件项目总有小修小改，如果严格按照产品定义来，乙方完全可以不做这些修改，或者要求加钱。但是如果大家相处的好，这些小改动就顺手做了。这些都是很现实的状况。毕竟，软件开发还算是门手艺活儿。

这篇文章是写给甲方看的，所以乙方的问题就不详细讨论了。说一个结论：如果你觉得乙方不靠谱，或者你给了钱就的听他的，请尽快更换乙方，后面的钱不要再支付了。虽然前期的投入会让更换乙方的成本很高，但毕竟比项目烂尾要好。而且多次实践经验表明，如果乙方前期不靠谱，后期变的靠谱的可能性为零。除非你愿意忍辱负重，凑活把项目做了，否则尽快终止交易，换人。

纠结还是交付？

所有程序员都知道，程序不可能没有 Bug，而且 Bug 往往越修越多，然而这在很多甲方那里是不能理解的。我经常跟甲方讲的是要看主要功能，主要流程是否能走通。除非一些特殊领域的软件，例如金融，工业控制等等，其他的软件，特别是互联网领域的，都应该是先上线，然后再完善。我看到的几乎所有互联网产品都是这个路子。所以，在绝大多数情况下，我们应该选择尽快交付上线，而不是纠结于一些小问题。一般的软件项目都有质保期的，所以这些小问题可以在质保期慢慢修。这有几个好处，首先是不用赶时间，做的质量会好一些。其次，上线以后有了实际的用户和运营数据，可以更加准确的定位一些问题。

另外就是从心理上来讲，大家做一个软件一般都好几个月，如果一直拖着不上线势必会影响士气。虽然，理论上乙方只是帮你开发而已，是否上线跟他关系不大，但成就感多少还是有一点的。上线以后，大家修 Bug 的情绪都会不一样，而且大家都知道已经上线了，有问题得及时修。总而言之，我建议甲方在交付阶段不要纠结，先交付，然后利用质保期完善。

在软件开发这件事情上，你可能是甲方，但在你工作的领域你可能是乙方，换位思考一下会让你成为一个更好的甲方。

最后，如何判断你是不是一个好的甲方呢？很简单：乙方是否下次愿意降价 10% 跟你继续合作。

甲方在项目开发过程中的作用

软件项目的开发是一个综合性的工程，需要项目相关各方努力配合。随着信息化程度的深入，软件项目的复杂度和精细化程度越来越高，对项目相关方的配合也提出了更高的要求。项目开发不仅仅是软件开发公司的工作，作为项目的客户即甲方在其中也起着至关重要的作用，本文结合软件开发过程的阶段划分，论述了甲方在软件开发不同阶段的作用。

【关键词】甲方   项目管理   阶段作用

1.前  言

软件项目是甲乙双方共同合作的一个工程，从不同的角度理解，往往对项目的认知程度不同。软件的用户在软件项目中作为甲方采购软件产品和软件服务。软件应用项目和软件服务项目通常是一个软件项目在甲方和乙方两个方面反映，站在甲方立场看，是一个软件应用项目；而站在乙方立场，则是一个服务项目。同时从甲方和乙方两方面看，项目的范围和目标是不同的，尽管项目都由启动、计划、执行、控制和收尾几个过程组成，却不会是一一对应关系。甲方在软件应用项目中的采购管理过程，将甲方软件应用项目与乙方软件服务项目联系在一起，其中的合同管理对应甲方项目的执行和控制过程，对应乙方的计划、执行、控制和收尾过程。明白了这个道理，作为甲方，不应该只把压力给乙方，而应该和乙方配合，达到双赢的目的，尤其在大型复杂的软件项目管理中更应该如此。在实际情况中，作为甲方常常给用户提出各种需求，让乙方开展项目，但是项目的结果往往不尽如人意。

从甲方的角度分析，一个项目的过程可以分为六个阶段，即项目立项阶段、初始阶段、精化阶段、实现阶段、实施阶段和维护阶段。对于以上存在的问题，下面就结合笔者的工作经验，分析作为甲方在复杂软件项目的各个阶段应该把握的事项。而项目的立项阶段和初始阶段的工作开展的如何，将直接影响到后期的工作，所以本文中就这两个阶段的工作做了大量的描述，后几个阶段的工作乙方的工作量相对较大，描述则较少。

甲方在项目过程中的作用示意图

2.立项阶段

(1) 项目意向提出

该部分内容属于项目意向的提出过程。业务部门发现需要由信息化手段来实现的业务需求，并提出建设信息化系统的期望。由于信息化项目的意向伴随着业务发展的全过程，因此，对于意向的统筹管理与规划对企业的信息化部门来说这始终是一个难题。

对于有集中业务规划期间的企业，意向的产生经常集中在业务规划期间，比如：在财务年末，业务对自身的模式进行盘点期间，往往产生业务模式的改进或改革的需求，从而对信息化工具产生需求。在这一时间产生的想法或需求，往往不是很成熟，不确定性很大，后期变化的风险也很高。但这一时期，也是意向最集中，最易于统筹规划的时期。信息化部门通常在这一时期，对所有的意向进行收集，分类整理，初步形成项目建设清单。并考虑公司战略重点与资源投入的约束，对项目进行排序，以确定建设重点。

对于不在集中规划时期提出的项目意向，往往会影响到原有的整体规划与计划，各方面的论证更应谨慎，比如，项目的必要性、投入的合理性、资源到位的可能性，对已建和在建系统的影响等等。信息化管理部门可以通过建立一些制度与流程，对业务需求的意向进行引导，尽量使意向在集中规划时期提出。

意向提出作为项目启动的一个阶段来管理，其意义就在于：对意向进行统筹规划，保证系统建设的整体合理性。

(2) 了解承包商

作为承包商应该多多关注甲方客户的愿景分析，能够让甲方感觉到你能够帮他完成他的愿景，这样才可能赢得甲方的信任，进而赢得项目。但是作为甲方同样应该清楚自己的愿景，并考察潜在的承包商。

甲方要了解潜在承包商的实力，切实考察潜在承包商是否开发过类似的项目，在考察过程中最好是让潜在承包商提供成功和失败两种案例，然后在没有潜在承包商陪同的情况下，自己组织人员去案例单位考察，这样会很好的了解潜在承包商的实力和诚信。

项目管理是项目开发过程中一个很重要的方面，是否有一套项目管理的规范应该是考察承包商的一个很重要的方面。项目管理的规范包含两个方面，第一是否有一套既定的模板，第二 是否在以往的项目管理过程中使用过这套模板，有没有现成的文档可以作为参考。甲方应该要求承包商提供全部的项目管理文档，并建立双向沟通的渠道。潜在承包商在争取这个项目的过程中，应该向甲方提供解决方案一类的文档，这个文档的模式实际上是文档是否规范的一个代表。

(3) 项目招标

在承包商的选择阶段，对潜在承包商进行初步的筛选以后，根据需求与方案要求，制定招标文档，接收潜在承包商的项目解决方案，并根据评估标准，组织相关人员对供应商进行评估，选出2个以上的潜在承包商进入商务谈判。并在立项报告审批通过以后，与承包商签署合同。

承包商的评估应该包括以下几个方面：

1．承包商基本面评估：如评估潜在承包商的规模、业绩、合同语言和仲裁地、合作策略等方面。

2．性能评估：它主要是对满足甲方信息化需求的产品本身进行评估，对所提供的软件产品的功能、性能、体系架构、用户友好性、费用等方面进行考察。

3．运行环境评估：对系统运行所需要的服务器、客户机的软硬件配置进行评估。这是很容易被忽略的一部分，又是有可能对后续实施投入影响最大的一部分，尤其是在客户端数量大，环境复杂的情况下。

4．项目实施评估：在信息系统的建设中，项目实施方法与能力已经成为项目成败的重要环节，因此对潜在承包商实施能力的评估显得尤为重要。评估内容主要包括：实施方法、实施费用、实施周期、实施顾问经验以及对相似实施案例的考察。

5．培训与售后服务评估：包括考察培训方式、及其费用、售后服务方式、及其费用、响应时间等。

6．效益风险评估：即项目的投入与产出的评估。这是最难评估的一项，当前在信息化项目中尚没有形成较完备的投入产出的量化评估指标，多是采用一些定性的分析与比较。

以上的评估通过以后，就可以同承包商签订合同，开始进入项目的实质化阶段。

3.初始阶段

项目的初始阶段，又称为项目的启动阶段，是项目成功与否的一个决定性阶段，这个阶段直接决定着项目后续各阶段的开展状况。做好项目启动管理是甲方在信息化项目中进行合理的投入产出分析，有效控制项目风险，确保项目成功的关键。

(1) 确定项目干系人

项目干系人主要指项目当事人和其利益受该项目影响（受益或受损）的个人和组织；也可以把他们称作项目的利害关系者。大型复杂的项目往往有多方面的人参与，就甲方来讲一般有公司的领导、业务部门的人员、计算机部门的人员等，有监理单位的还有监理工程师、咨询顾问等。他们一般通过不同的形式，共同参与项目。实际上项目的各方当事人需要有自己的项目管理人员，表示了项目当事人之间的联系。

项目不同的干系人对项目有不同的期望和需求，他们关注的目标和重点常常相去甚远。例如，领导层可能十分在意时间进度，系统使用人员更注重系统的易用性和对业务的调整内容，计算机相关人员往往更注重技术。弄清楚哪些是项目干系人，他们各自的需求和期望是什么，这一点对项目管理者来说非常重要。只有这样，才能对干系人的需求和期望进行管理并施加影响，调动其积极因素，化解其消极影响，以确保项目获得成功。

项目干系人中，领导层是一个非常重要的层面，所以要积极争取“一把手”的支持。很多大型软件项目的实施，是一个耗时长、高投入、高强度、高振荡、高风险的工作，如果没有一把手在资金支持、人员配备、流程调整等方面的强有力的持续支持，很难获得成功。

(2) 成立项目组

成立项目组不仅仅是乙方的工作，甲方也应该成立相对应的项目组，配备相应职位的人员，明确各自的责任，这对项目的开展是一个非常重要的工作内容。

甲方项目管理人员必须对本项目所涉及的业务比较熟悉，项目的成功和甲方的项目经理的个人素质（技术素质）以及在企业的个人魅力有很大关系，因此甲方的项目经理一般由负责业务的领导或者是计算机部门的领导担当。

甲方项目组的成员还应该有业务需求人员、系统实施人员等。业务需求人员一般由相关业务方向的对业务精通的人员担当，根据具体的业务方向可能有更详细的划分。业务需求人员一般承担的责任是组织业务的调研、对业务需求调研的确认、组织编写业务管理规定、系统使用培训等。系统实施人员一般是计算机相关的人员，一般负责系统架构的确认、硬件产品的选择确认、采购、硬件及软件系统安装调试的协调等工作。

(3) 确定项目计划

甲方应对自己所需开发项目应该达到的目标有比较明确的认知，或者是对项目实施后的愿景有比较明确的描绘。针对这个项目的目标和甲乙双方确认的结果，制定一个完整的项目计划，是项目启动阶段的一个重要内容。

项目计划是要提供一份合理的进程表，让所有开发人员任务明确、步调一致，最终共同准时地完成项目。项目计划是要付诸实施的，不像喊口号，可以很夸张。软件的项目计划重在“准确”而非“快速”。

一份完整的项目计划应该包括工作划分、责任人、里程碑等。明确各项工作及各个阶段、各个人员的职责，才能保证项目进展的顺利。

对应项目计划的是各种项目管理的制度，这是非常关键而且容易忽略的一项工作。主要包括：

l 项目考核管理制度；

l 项目费用管理制度；

l 项目例会管理制度；

l 项目通报制度；

l 项目计划管理制度：明确各级项目计划的制定、检查流程，如整体计划、阶段计划、周计划；

l 项目文件管理流程：明确各种文件名称的管理和文件的标准模版，如汇报模板、例会模板、日志、问题列表等。

(4) 确定沟通流程

项目组成立之后，要明确相应人员的职责，明确甲方人员同乙方人员的沟通流程。这主要是指项目业务内容的沟通过程，即项目的需求调研对象和培训对象的沟通。

企业的一项业务工作，往往是由多个人去做的，业务部门包括多个工作人员，甚至是由多个分公司或子公司去开展这项业务。让乙方的需求调研人员直接面对众多的业务人员是不明智的选择。一方面是各个人员对一项业务往往有不同的理解，让乙方人员去明确业务的方向是很难的；另一方面是业务在系统上的实现方式确定以后，要有一个执行的过程，这个执行过程也要甲方的人员去明确和执行。这也是前述强调的“一把手”工程的内容，业务明确以后要执行。

解决的办法是针对一项业务，甲方明确一个负责人，这个负责人一般由业务部门的业务精通人员或计算机相关人员担任。由这个负责人组织协调需求的明确和系统的执行。业务负责人将业务确定之后，反馈给乙方的需求调研人员。

(5) 召开启动会议

项目启动的准备工作完成后，就可以召开项目启动会议了。启动会议是项目开工的正式宣告，参加人应该包括项目组织机构中的关键角色，如管理层领导、项目经理、供应商代表、客户代表、项目监理、技术人员代表等。

项目启动会的任务包括：

l 阐述项目背景、价值、目标；

l 项目交付物介绍；

l 项目组织机构及主要成员职责介绍；

l 项目初步计划与风险分析；

l 项目管理制度；

l 项目将要使用的工作方式。

从这些我们可以看出，项目启动会已经涉及到了项目计划阶段的初期内容，这也映证了在PMBOK体系中启动阶段与计划阶段的重迭。

4.精化阶段

(1) 需求调研

在经过了项目的概念阶段以后，就进入对项目需求的调研阶段。这一阶段需要有甲方信息化人员与业务人员组成的小组，对业务需求进行详细的调研与分析。采用的方法主要包括各业务层次人员访谈、会议、调研问卷等。这个阶段可能还要针对需求调研，进行需求调研人员的培训，明确业务的调研的参与人员、调研的方式等。

甲方应该对项目承包商涉及人员做比较具体而详细的项目准备，做好项目所涉及业务的调研工作，具体包括业务流程，流程所涉及的岗位、单据、报表，以及各种单据和报表之间的计算关系等等。这些工作是对前面提到的愿景确定的具体描述。

在这一阶段，往往出现信息化人员可能认为业务的需求不清晰，而业务人员认为自己的需求已经十分清晰。解决这个矛盾的关键在于，要有详细的管理控制方法，引导业务人员进行需求的细化。如，制定需求分析报告的框架，针对关键点形成文档。一般来说，需求分析包括以下内容：当前业务流程分析、未来业务流程分析、当前业务与未来业务的差异分析、信息化功能点需求、对将来系统的非功能需求，如：性能需求，环境需求，安全需求等。

(2) 需求调研确认

需求调研完成之后，乙方的业务调研人员编制需求调研报告。需求调研报告形成以后，还需要组织对需求的评审，以达成项目关系人对需求的一致认可。这一过程主要包括：

l 制定评审计划：制定评审的工作计划，确定评审小组成员，准备评审资料；

l 需求预审查：评审小组成员对需求文档进行预审；

l 召开评审会议：召开评审会议。对需求调研报告进行评审；

l 调整需求文档：根据评审发现的问题，对需求进行重新分析和调整；

l 重审需求文档：针对评审会议提出的问题，对调整后的需求文档进行重新审查。

(3) 需求规格确认

需求调研报告完成之后，乙方人员会同甲方人员进行需求的分析，之后编制需求规格说明书，即我们常讲的概要设计。同样，对需求规格说明书也要有一个评审确认的过程，确认的过程同调研报告的确认过程大致相同。

(4) 采购计划确认

经过需求的分析确认，系统的架构应该在这个阶段确定下来。这个需求不单单指功能性的需求，也包括业务内容的确认。还有一个非功能性的确认，即系统使用的硬件配置、软件环境等方面的内容。硬件配置和一些软件的数据库及中间件需要进行采购，这里也要制定采购计划。

硬件系统一般讲的是服务器的配置、网络环境的搭建等。需要购置什么样的服务器，搭建怎样的网络环境，是自己搭建网络，还是进行服务器的托管，这都要明确下来。

数据库方面，究竟是使用SQL Server还是ORACLE或者是其他的数据库，都要明确下来，列入采购计划。中间件一般指的是B/S条件下WEB服务器，例如WebLogic或WebSphere，都需要明确和采购。

5.实现阶段

(1) 跟踪项目风险

目前的阶段，主要的工作在乙方，甲方需要对项目的实现进行风险的跟踪。

加强对项目关键点的审核和项目关键环节的控制。在项目的每个关键点，设立里程碑，对前一阶段的工作进行严格的审核和评审。保证这一阶段出现的问题不会被传递到下一阶段，甚至被放大。同时，通过对关键环节进行有效的控制以保证项目的质量和项目的进度。

在项目的初始阶段，应该已经建立了项目的风险管理机制，在这个阶段主要是对项目的风险进行跟踪。例如，乙方的项目经理的工作是否到位，乙方的开发进度是否与计划一致等。在项目计划阶段，如果项目负责人能够对项目中可能存在的风险进行仔细分析，制定比较周密的风险防范机制，会大大降低项目实施过程中出现的风险。

(2) 业务操作规范制定

系统开发完成之后，乙方的开发人员编制操作说明书。甲方应该着手制定系统的使用规范。系统的开发是在理顺业务的基础上进行的，可能对业务有一定的调整，或者是新增加的业务内容，甲方需要在操作说明书的基础上编制业务操作规范。

(3) 相关设备采购

前述的设备采购已经确定，这个阶段需要着手进行设备采购。包括联系设备、系统供应商，制定价格，签订合同，预定到货日期和交货方式。

(4) 系统测试

乙方系统开发完成之后，经过了内部的测试，应该进入甲方测试阶段。这个工作应该搭建正式的服务器环境，运行真实的数据，进行测试。测试的人员应该是前述的业务需求负责人，可以包含其他的业务人员。

对于二次开发的系统，甲方一般由原来的计算机系统，对于原来的数据，应该在前期的实现阶段有一个导数据的工作。这个测试过程，也可以包含对导数据工作的测试。可以将原来的数据导入到测试环境中，让测试人员进行真实数据的测试。

6.实施阶段

(1) 召开培训会议

操作说明书和操作规范编制完成之后，应该召开培训会议对系统的使用进行培训。培训的环境应该是前述的系统测试环境。培训的形式应该是比较正式会议的形式，可以使用投影仪等工具，由乙方的开发人员进行主要的讲解，或者是甲方的业务负责人进行讲解。培训时应该有操作说明和业务操作规范的书面文本，培训后操作人员对照这两个文本进行系统使用的练习，否则培训的效果可能不尽如人意。

(2) 系统安装

系统的设备、软件系统已经采购到位，此时应该着手进行系统的安装。

服务器和网络环境的搭建是一项重要的工作。服务器主要包括数据库服务器和WEB服务器，组织的形式还可能是集群的环境。这个系统的搭建则更为重要，服务器配置的是否良好直接决定着系统运行性能的优劣。网络环境的搭建包括与服务器配套的网络和操作人员使用的网络环境以及操作人员的客户端机器的配置。

软件系统的安装则包括采购的数据库及中间件的安装及开发的应用系统的安装，及各种软件之间的互相连接。应用系统的安装还包含原有数据的导入或录入。可以采用的方法有两种：一是批量的导入，使用在实现阶段开发的系统将数据导入到新的系统中；二是手工的录入，这样可能需要组织人员进行数据的录入工作，例如组织专门的数据录入人员。

(3) 系统试用

系统的培训和安装完成之后，则开始正式试用新开发的系统。试运行阶段包括两种方式：对于原来已有计算机系统的情况，可以采用两个系统并行试用，一个业务作两遍，以此来检验新的系统的计算方法是否正确。对于原来没有系统或原来有系统但是计算方法变更的情况，则只能进行单独的试运行，通过人为的测试来检查试运行的效果。这个阶段一般持续的时间为一个月左右。

(4) 系统验收

系统试运行结束，系统开始正式的运行。此时，乙方会出具验收报告，甲方配合乙方对系统的开发情况进行验收和总结。

7.维护阶段

(1) 确定修改内容

系统正式运行之后，系统在运行的过程中，可能会检验出原来制定的需求有不足的地方，或会有业务的更改，此时需要对系统进行部分的调整。

担任修改确定工作的还应该是前述的需求责任人。业务人员将变更的需求提交上来之后，首先由业务需求人员确定是否应该进行修改，或进行业务变更的总结。系统修改最好是批量的修改，变更需求积累到一定的程度再进行提交，繁琐的修改对甲乙双方都不是一件好事情，更容易导致今天的修改和昨天的修改发生冲突的等。

修改提交上来之后，业务需求负责人需要同乙方及甲方的相关人员讨论修改的必要性和可能性。有的修改点没有必要，则不进行修改。有的修改点可能对系统是一个颠覆性的改动，需要的工作量比较大，则要考虑具体的情况。确定之后将修改的工作交给乙方的人员。

对于工作量比较大的修改，或者是对系统整体架构的改动，此时则可以进行系统的升级工作，比如新起用一个版本。

(2) 修改测试

乙方的修改完成之后，甲方进行系统的修改点的测试。更改相应的操作说明书和操作规范。

(3) 修改应用

系统修改测试完成之后，进行系统的发布，开始正式运行新的系统。

8.结论

项目开发是甲乙双方的工作，决不仅仅是乙方的工作，甲方的工作直接决定项目的成败，国内众多的ERP系统的实施情况早就证明了这一点。甲方在项目的开发过程中，遵照上述的工作内容展开，无疑对项目的成功起着巨大的作用。

作者单位：大连海心计算机有限公司

--------------------------

一个甲方项目经理的自白

基于个人工作经验谈一点，自认做的还行，但是也说不上优秀，信息化领域高人辈出、藏龙卧虎，所谓长江后浪推前浪，江湖代有新人出，这里只不过说说自己的看法，描述一下个人对信息化的认识。

　　做过乙方的项目管理，也做过甲方的项目管理，所以结合“围城”内外以不同的角度对甲方项目经理这一角色进行了一些思考，个人认为，做为一名合格的甲方项目经理，应该有以下几个物质，这里说的，只是合格的，优秀的项目经理则是不同的标准，一直觉的优秀的销售、优秀的项目经理、优秀的咨询顾问基本是天成+勤奋，缺一不可。

　　1、良好的沟通能力

　　在项目实施的过程中，甲方项目经理沟通对象主要有三类：乙方、业务部门用户、不同级别领导。

　　那么在与这三类沟通对象进行沟通时，就会出现一些问题。

　　与乙方沟通时，乙方的水平参差不齐，遇到高水平的乙方就省心，遇到乙方水平一般的，就比较麻烦，因为对业务的不熟，他们会误解关键用户的需求，因为对技术的“执着”，他们会埋头于所谓“技术难题”的研究，而忘记项目的主要开发内容，所以，与乙方的沟通很重要，第一，在他们出现偏差时，要告诉他们应该校正，第二，在沟通时，还得让乙方认可你，所以沟通中，建立互信和权威，非常重要，而这完全取决于沟通技巧、丰富的项目经验和还说的过去的技术水平。

　　与业务部门用户沟通的时，会出现的情况不同，业务用户对业务很了解，但是在项目实施过程中，他们会出现两种状态，第一，认为信息化无关紧要，手头的事多的是，很忙，不在意信息化的工作，配合上有问题，第二，在描述需求时，对需求没有明确的概念，只能描述个大概，技术人员听不懂，这时，就需要发挥沟通的能力，让业务部门用户理解信息化的重要性，同时能够将业务部门的业务语言让技术人员听懂，同时也需要引导业务部门人员理清思路，其实，这块工作，如果乙方的实施顾问水平够的话，是应该交给他们的。

　　与不同级别领导的沟通，这一块比较复杂，基本要看EQ了，第一，部门间难免有利益冲突，信息系统正好是个中介，第二、领导都很忙，怎么能让领导忙中有时间把需要决策的事帮忙做好，所以与领导的沟通至关重要，技巧的要求也很高。怎么能让各部门的领导支持项目，也不觉的烦是个技术活。那种让老总压各部门领导的做法，个人一直认为可以适当的用，但不能做为主要用途，如果作为主要手段，无异于“饮鸩止渴”，只能解决短期问题，却带来后患无穷。

　　2、资深的技术能力

　　甲方的项目经理在技术能力上通常都有缺陷，这样就容易被乙方牵着鼻子走。举个例子，人家说这个服务器不能用PC SERVER，必须用小型机，然后提出一大堆理由，还加一些风险分析—其实就是“威胁”，这时，如果对技术不了解，也许就答应乙方的方案了，因为不懂细节的技术，又怕担责任。而事实上，用PC SERVER完全满足需求，小型机比PC SERVER贵出的百万就白白的花掉了，大马拉小车。还比如，有时很正常的需求，需要增加业务功能，不增加就满足不了企业需求，乙方说太难了，如果做要几十天上百个天，甚至说做不了，更有甚者，会说实现了这个需求会对企业管理有问题、会对其它已经完成的模块造成很大的影响，而事实并不是，这时，如果技术底蕴浅，就被忽悠了。做出的系统不能很好的满足用户的需求，对项目的质量就有影响了。所以，一个甲方的项目经理必须有深厚的技术能力，才能从技术上把控项目，维护企业的利益，同时把项目做的尽量好。

　　3、优秀的策划协调能力

　　一个大型的信息化项目，从选型、启动、实施、验收、运维，期间有大量的工作，每个阶段又会分成N多会议、N多测试、N多协调的工作。那么如何对这个项目进行统筹策划?如果协调团队成员、争取公司资源、争取领导支持，做好这件事呢?策划和协调能力就非常重要。

　　其实，信息化项目都是这样，启动后，就没人管你了，乙方一心想着少干活、多拿钱，这不是他的错，这是一个独立核算公司应该做的，而甲方企业的领导已经宣布支持项目了，下面的活，基本上就是甲方项目经理的事了，如何把整个项目计划好、并按计划推行，如何在项目的不同阶段梳理计划、修正计划、推动项目，就是非常重要的。很多甲方经理，尤其是大型信息化项目的甲方经理，就死在这一步了，从这一刻开始，如果不能掌控项目，被项目带着走，基本就会死的很难看了。这是策划能力的需求。

　　协调能力，主要是指，能够在不同的阶段，协调不同的人、不同的资源真正投入到项目，做到各自的贡献。注意，协调其实有两个含义，第一，把人、资源安排好，第二，要让人、资源发挥作用，达到目的。经常在项目中会看到，人是来了，心没来，糊弄糊弄回去了，有的项目经理就抱怨业务部门的人不积极，其实根源在自己。

　　4、细心

　　细心也隐含着主动的意思，尤其对于项目中隐含的问题要细心的及时发现。对于，一个信息化项目，其实唯一的责任人就是项目经理，唯一出了问题找不到借口的就是项目经理。而乙方为了快速结束项目，会把一些隐患回避，业务部门的同事因为只是参与，没有责任，所以不会很积极的去发现问题。所以，甲方项目经理就必须去细心的分析项目，找到隐含的问题，如果在系统上线了，乙方撤离现场了，才发现问题就晚了。仔细想想，经常做项目的同事应该都有过，项目验收了，实施人员撤离了，却发现问题不少，或者问题挺严重，这时想再找人维护，比登天还难，要不就是人不来，要不就是加钱，请选择。当然，如果遇到职业素质良好的乙方，另当别论。

　　5、杰出的团队带领能力

　　作为甲方项目经理，需要带领导团队进行长达半年到N年的项目建设过程，这么长的时间里，如果能做到计划有人执行、分出的工作按时完成有一定难度，这时主要决定于项目经理的个人能力、为人，只有建立起信任，让大家都信服你，工作才能推进下去。其实，这也是选择项目经理至关重要、不可或缺的一点。这里也千万不要指望高层领导的力挺，靠高层权力获得的暂时领导权在大家心中不会长久。

　　6、学习能力

　　信息化项目涉及范围广，从技术的角度，开发工具种类多、开发架构多，从业务的角度，可能今天做的是财务模块，明天做的设备管理模块，也许以前对某些知识比较了解，可是总有不了解的。所以项目经理必须要有较强的学习能力，只有自己了解了，才能有效的管控项目。观察身边优秀的项目经理，不管是乙方的不是甲方的，哪个不是学习能力强、博学的呢?常有人说项目经理不需要懂技术，懂管理就行，不敢恶疾苟同，举个很简单的例子，有一个新的需求提出来，如果不懂技术，你怎么知道能做还是不能做，做的话需要多大的投入呢?如果让技术顾问或者技术经理还评估，那要项目经理还干什么呢，技术经理也可以管理，也可以协调人啊，让技术经理兼顾项目经理不就得了。

　　7、决策能力

　　尤其在甲方，有的项目经理喜欢事无具细，一律报领导定夺，主要是怕担责任，这样的项目基本上不会成功了。做为项目经理不决策，还叫什么项目经理，重大事情找领导就行了。只要做好项目才是最终目的。以前遇到有的项目，启动时大家谈到ERP必须是一把手工程，结果小伙逢会就请老总，请经理，搞到后来，什么会领导也不来了，狼来了的故事地球人都听过。