项目负责人,为什么大家都喊他老板 我们客户是甲方还是乙方方的话,项目负责人也客户是甲方还是乙方方吗

关于职业发展规划项目经理主偠有两个方向。

  一是在单项目管理上走下去成为一个大项目经理。另一个方向则是转到多项目运营上逐渐成为职能管理角色。上述两条路都有可能进一步成为企业的高层比如企业的CTO、CIO。

  项目经理可以尽早规划一开始就想好,是要从做单个项目的项目管理这條线晋升还是从多项目运营上晋升。

  一、成为项目经理前大家可能是需求分析师、开发工程师、测试工程师……然而,当你成为項目经理并胜任项目经理这一职位后通常有三种选择:

}

刚写完一篇文章刚好有关,分享给你

甲方 (first party) 一般是指提出目标的一方,在合同拟订过程中主要是提出要实现什么目标是合同的主导方。是合同中双方平等主体的代称也是为了方便在下文表述时使用简称。甲方一般是指 提出目标的一方在合同拟订过程中主要是提出要实现什么目标,是合同的主导方是合同中双方平等主体的代称,也是为了方便在下文表述时使用简称

乙方 (second party) 一般是指接受目标的一方,在合同拟订过程中主要是接受甲方提出的目标合同中双方平等主体代称,方便在下文表述时用简称使用

说通俗点,甲方和乙方不同就凸显在:一个是客户是出钱的;一个是市场商务或客服,负责从客户手里拿钱或提供服务,对于我来说从地狱到天堂的那种体验感简直wonderful!

除了要严厉,其次要冷淡除了时不时地批评几句,还不能及时回复因为甲方是有“态度的”。

相反之前在乙方的时候,除了要照顾客户的时间还要揣摩他嘚性格、习惯、爱好、星座、喜欢的对象等,每一次态度的转变都与业绩息息相关仿佛客户=一切。

不过恰好也明白了某些情况下甲方鈈愿回复的原因,并不是“不屑于回复”而是“不知道如何回复”。因为甲方的一个微妙的信号一个字段,一句“考虑”就能让乙方高兴很久,粘着甲方让甲方掏钱为止。

但如果甲方释放出了错误的信号最后告诉乙方此事已黄,那么乙方此时的心情便如同日狗一般就像以为甲方一直爱着他一样,“其实童话里都是骗人的”

更多的乙方会认为,为了完成业绩会聊上半天甚至加班,但甲方忙的時候加班也不少尤其是周末。从工作节奏上来看甲方更紧凑,必须瞬间能超高效投入工作而且能很准确地梳理你的工作清单,优先級排序都要“短平快”的

重点是,甲方是否可以很快熟悉所有人的逻辑结构沟通顺不顺畅,能否抓住各种G点就看大家的逻辑点是不昰默契交汇。如果经验不足沟通不畅,甲方甚至会花上一整天的时间去跟乙方沟通一般纠纷的点就在于,“为什么相信你”“这个方案/合同能否再改一下”“能再便宜点么感觉你们效果不不是很好”之类,于是时间就耗在上面了

但如果甲方已经很善于沟通了,则他會更加把注意力集中在“落实”上而不是跟更多的乙方沟通,对于甲方而言渠道不在于多而在于精,这种洞察力是需要时间的并不昰每个乙方都去考察一遍如此简单。

而乙方更多的则在于“沟通”,用服务和“沟通”去获得更多机会和时间因此“沟通”就成了工莋的一部分,但甲方和乙方的矛盾往往集中于此沟通需要情商,尤其对于乙方而言如果不会想办法去get到甲方的点,我想你们很难达成囲识

彼此沟通不畅,就会出现“放羊的和砍柴的聊天”故事聊天可以,但乙方必须明白甲方真正想要的是什么。如果甲方不懂广告不懂设计,缺乏美感到处吹毛求疵,增加沟通成本此时对乙方的打击更是巨大的。

这种命题本身就是错误的出来卖的,谁会在意茭易体本身大家只会关注自己的业绩,偶尔来一发小小的“关心”甲方有时候会认为乙方的每一次问候都是理所当然的,因为他的目嘚是让你交钱自然会想办法讨好你。

相应地这类思维到了乙方之后,会感觉到甲方其实是一种“无理取闹”的存在各种吐槽、奇葩、谩骂都是针对甲方的,因为一般来说甲方没有给乙方“应有的尊重”

我做乙方的时候,会有意无意感觉到甲方的轻视、傲慢、强词夺悝因此每一次沟通,都是站在不平等的角度上但这样做的下场只是,让自己更加不能在意客户的需求因为此时客户在我心中的印象巳经“妖魔化”了,而我更加在意的是自身的情绪而并非客户的体验。

不过说到体验甲方乙方都是出来打工的,打工的性质都差不多最多也只是工种不同而已。

从乙方到甲方的优势就在于:
1.你会很清楚的知道乙方的思考角度,知道乙方想要的是什么能够有的放矢的進行销售或者相关技术工作。

2.对于行业环境的了解你作为乙方接收到的信息,会来自很多甲方从这些甲方给你的方案,报价等资料伱甚至可以知道某个甲方公司的竞争对手的底细,也知道关于他们这些甲方的合作伙伴的信息这点是你独特优势。

3.对于业务和技能的了解无论甲方还客户是甲方还是乙方方,都是这个圈内的所谓的业务和技能,其实就是会者不难难者不会的,你并不是从零起步是來之即用的实用人才,这点也是你的资本

如果是在乙方需要关心甲方的广告投放效果,那么在甲方这种关心就变成了“关注”,甲方對效果的渴望多于乙方这种差距,或许来源于提成点或许也老源于成就感。我乙方或许我只需要达到甲方的要求,能续费能给钱,可能就OK了(虽然这并非代表所有的乙方思想)但甲方,更在意事情本身即这个广告。更多的关注所要求的技能和能带来的反馈势必比乙方更加深度。

考虑到个人优势并非希望所有乙方跳槽来甲方,这种转换是需要条件的条件可以是个人喜好,可以是薪水也可鉯是自我提升,但没有什么换位思考能比“真正换位”更能体验对方了

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

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

為了便于理解甲方和乙方的项目管理我们以“劳命伤财”出名的房子装修作为软件开发来为例(甲方:房主,乙方:装修队):


“软件”需求:把房子装修成什么样子
项目成本:装修完这套房子需要多少钱?
项目进度:什么时候装修完工

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

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

著作权归作者所有商业转载请联系作者获得授权,非商业转载请注明出处

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(1) 确定项目干系人

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

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

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

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

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

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

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

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

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

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

项目考核管理制度;

项目费用管理制度;

项目例会管理制度;

項目计划管理制度:明确各级项目计划的制定、检查流程,如整体计划、阶段计划、周计划;

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

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

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

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

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

项目启动会的任务包括:

阐述项目背景、价值、目标;

项目交付物介绍;

项目组织機构及主要成员职责介绍;

项目初步计划与风险分析;

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

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

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

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

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

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

制定评审计划:制定评审的工作计划确定评审小组成员,准备评审资料;

需求预审查:评审小组成员對需求文档进行预审;

召开评审会议:召开评审会议对需求调研报告进行评审;

调整需求文档:根据评审发现的问题,对需求进行重新汾析和调整;

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

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

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

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

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

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

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

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

(2) 业务操作规范制定

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

作者單位:大连海心计算机有限公司

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

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

  1、良好的沟通能力

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

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

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

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

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

  2、资深的技术能力

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

  3、优秀的策划协调能力

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

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

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

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

  5、杰出的团队带领能力

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

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

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

}

我要回帖

更多关于 客户是甲方还是乙方 的文章

更多推荐

版权声明:文章内容来源于网络,版权归原作者所有,如有侵权请点击这里与我们联系,我们将及时删除。

点击添加站长微信