(注意:本写列文章,未经本人同意,谢绝转载,版权所有,如需转载,请与本人联系,谢谢)
上周的系列之二(主要是闲聊了关于甲方项目负责人如何和甲方的领导相处配合,以及其中要注意的地方。在本文里,将探讨下在整个项目过程中,作为甲方的项目负责人,应该如何于乙方进行配合,如何揣摩好乙方的心理,如何能和乙方和谐相处。
首先,我们继续来复习上次提到的图。
这次我们着重谈的是箭头中的“3”。首先我们来看看,作为甲方信息项目负责人,在面对乙方的情况下,会遇到一些什么样的问题(普遍而言)。我列举了大概下面一些常见的:
1、来自领导各方面的压力比较大,领导期望大,自己也有很高的期望,但时间紧迫,又第一次做甲方,觉得没把握;有的人原来做技术的,现在角色转换了,觉得做甲方无聊枯燥。
2、项目大,自己觉得在实施方面经验不足,自己的知识体系结构与乙方有很大的差距,面对乙方提出的要求,新技术,新的实施方法,自己
了解的不多,老有感觉被“乙方牵着鼻子走”的感觉。
3 、感觉对乙方的监督不到位,老是感觉乙方进展慢,不合当初提出的要求,于是老是催乙方,但又提不出很好的对乙方的具体要求。
4、和乙方的工作中,经常意见不一,双方理解分歧大,老觉得乙方偷工减料,经常和乙方发生争执
在上面的这些原因中,有的是由于甲方负责人本身的问题做成的。比如第1点,我就见过有甲方负责人出现过这样的情况,当然,出现
这样的情况的一般是甲方负责人的经验问题,或者是做信息项目的新手,又或者是以前是专搞技术的,这次转换角色有点不适应。
在这样的情况下,建议先做下心理上的调适。假如你是由于经验问题或者是角色刚转到甲方来的话,建议你可以这样想:我毕竟以前是搞技术的,虽然现在转了角色,虽然要做的东西不同了,但起码不用做编码CODING了 ,可以站在更高的角度去把握问题了,可以学到更多的
软件工程的知识以及管理规划的知识,可谓海阔天空了,可以做“监工”了,有做“小老板”的感觉了。呵呵,上次我有位朋友,在单位原来是搞技术的,属于技术狂,后来由于有项目要外包给其他公司做了,他自然成了甲方负责人,开始他觉得不爽,觉得做甲方负责人无聊枯燥,整天要上听领导指示,下要面对乙方。后来我让他按上面的讲法重新思考,重新调整自己的心理状态,重新去感觉做甲方的乐趣所在,最后,由于他技术功底好,加上肯学习,很快就转换了角色了,在整个项目中对各类问题,以及和各方的关系处理的很好。
而对于第2点的情况,应该是普遍存在的。原因可能是:可能是由于经验的不足,工程庞大,自己在这方面的业务知识还是不足够,对一些新技术之类的和乙方提出的方法不大熟,但时间又紧。在这样的情况下,建议有几点:
1、你自己的心理上要坚信:你是甲方的负责人,你不是全能的,你的职责是把需求较好地告诉乙方,配合,监督乙方完成工作,而不是去做乙方的参谋。因此对于知识方面的缺陷,你要有个清楚的认识,如果不是涉及太核心的业务流程知识,而只是涉及到一些花俏的知识和技术,则无必要过分强调自己去全盘照收,毕竟你的精力是有限的。要搞清楚,乙方提出的新东西,是否真正适合本项目使用。这就涉及到一个评估的问题。这时建议你先把乙方的有关方案仔细研读记录,并要求乙方提出明确的根据和理由,千万不要轻信乙方表面
上的东西。打个比方,乙方说要上。NET系统,吹到如何如何好,但做为甲方的你,你可以结合项目目前的具体情况,再让乙方提出根据理由进行判断,就是:
仔细研究项目的业务流程和具体情况+要求乙方真正举出理由根据+咨询第三方意见+查询同类案例的经验
这样的做法的好处是“反客为主”,因为要知道,有时设置甲方的负责人有可能根本不是搞技术出身!还可以咨询第三方的意见,最简单的是可以和手下开会(手下的一般都是搞技术的),和他们探讨乙方的方案。注意做为甲方负责人的你,不要那么直接让你的下级清楚你知识上的缺陷(否则太明显的话,有可能让下级对你产生不信任和认同),要通过和他们讨论,间接布置任务给他们,由他们来进行解答,从中听取相关意见。最后,还可以多查询同类案例的成功或者失败经验,搜集好这些资料,以便在开会时和乙方讨论时有根据可以提出来。
在做好这些工作后,对于乙方提出的新玩意,你最好还是自己了解其基本原理和应用就可以了,太深的东西你根本没必要去了解,或者你让你的手下去做和整理。
2、心理上要认为自己是掌握主动权的,因为毕竟你是甲方,你是客户,是上帝。在同乙方打交道的时候,要让乙方觉得你做为甲方的负责人,是对项目整体的把握是到位的,是有大局观的,是有很好的掌控能力的,是有领导风范的,是有经验的。因为这点是很重要的,特别是假如甲方负责人刚接手,或者是经验不足的,或者是根本不是技术出身的话,更加要在乙方面前表现得镇静自若。建议如果你手下有搞技术的人员的话,每次开会都带上他们;如果碰到乙方吹新技术,新方案的话,自己要保持冷静,如果不熟的话,可以在会上适当拖延下,让下次再讨论答复,或者让技术人员解答,有时也要在乙方面前,多表现自己的权威(甚至做下戏有时也要的,呵呵)。
而对于第3,4点,主要是由于缺乏对乙方的量化监督。很多情况下,如果没有第三方监理的话,甲方很容易陷入盲目的监督中,比如表现在形式上的监督,要乙方定期汇报进度,缺乏在细的方面上的监督。因此有如下建议:
1、在项目一开始,就要拟订好对乙方的监督计划。比如定义的会议制度,会议需要乙方参加人员,乙方的长期联络人。监督计划最好按照里程碑来实现,不能过于太粗糙,比如等乙方完成需求调研才进行审核,可以改为:要求乙方完成需求调研中的某个部分的调研,就要提交给甲方审核一次,就象XP里一样,小规模审核。而且最好也留一定的余地给乙方,比如要求乙方在某个时间段内提交,有的时候
不能对乙方太过苛刻,否则会引起乙方的不满意,影响接下来的工作。
2、 每次和乙方开会讨论问题时,要做好记录,最好能录音。开会前,按出现问题的严重程度,由高到低列出来,会上向乙方提出来,最好能搞成一个表格的形式,比如能记录乙方当时的响应,会后的响应,实际的效果等,这样以后一目了然,知道乙方到底做了些什么
工作了。对于原则性问题,要明确地向乙方指出,不怕得罪乙方,而对于乙方提出的意见和方案,自己也要记录,不急于做结论,因为主动权在你手。
3 比如一份典型的监督计划的模版有可能是这样的(仅供参考)
监督计划
1、 需求分析阶段中乙方对需求调研效果的监督
原计划内容描述 |
|
乙方计划开始日期 | |
乙方计划结束日期 | |
实际开始日期 | |
实际结束日期 | |
完成情况 | |
滞后情况乙方描述 | |
乙方提出的解决方案 | |
乙方提出的问题 | |
甲方对本阶段的意见问题 | |
双方对下阶段的意见 | 甲方:
乙方: |
下一任何的起始时间: | |
本阶段备注 | 这里可列出本阶段双方可参考的已有制品或文档情况
|
双方领导签名: | 甲方 |
当然,如果有第三方监理方的话,则上面加上监理的意见和看法及签名等。这样在实际操作中,就量化了,有规范了,大家都要遵守。
先写到这里,下次继续写,欢迎各位继续批评和补充,发表看法