软件工程心理学之3---甲方项目负责人 PK 乙方

(注意：本写列文章，未经本人同意，谢绝转载，版权所有，如需转载，请与本人联系，谢谢）
    
    系列之二主要是闲聊了关于甲方项目负责人如何和甲方的领导相处配合，以及其中要注意的地方。在本文里，将探讨下在整个项目过程中，作为甲方的项目负责人，应该如何于乙方进行配合，如何揣摩好乙方的心理，如何能和乙方和谐相处。

         首先，我们继续来复习上次提到的图。
  


     这次我们着重谈的是箭头中的“3”。首先我们来看看，作为甲方信息项目负责人，在面对乙方的情况下，会遇到一些什么样的问题（普遍而言）。我列举了大概下面一些常见的：

1、来自领导各方面的压力比较大，领导期望大，自己也有很高的期望，但时间紧迫，又第一次做甲方，觉得没把握；有的人原来做技术的，现在角色转换了，觉得做甲方无聊枯燥。

2、项目大，自己觉得在实施方面经验不足，自己的知识体系结构与乙方有很大的差距，面对乙方提出的要求，新技术，新的实施方法，自己
了解的不多，老有感觉被“乙方牵着鼻子走”的感觉。


3 、感觉对乙方的监督不到位，老是感觉乙方进展慢，不合当初提出的要求，于是老是催乙方，但又提不出很好的对乙方的具体要求。

4、和乙方的工作中，经常意见不一，双方理解分歧大，老觉得乙方偷工减料，经常和乙方发生争执
       在上面的这些原因中，有的是由于甲方负责人本身的问题做成的。比如第1点，我就见过有甲方负责人出现过这样的情况，当然，出现这样的情况的一般是甲方负责人的经验问题，或者是做信息项目的新手，又或者是以前是专搞技术的，这次转换角色有点不适应。
 
      在这样的情况下，建议先做下心理上的调适。假如你是由于经验问题或者是角色刚转到甲方来的话，建议你可以这样想：我毕竟以前是搞技术的，虽然现在转了角色，虽然要做的东西不同了，但起码不用做编码CODING了 ，可以站在更高的角度去把握问题了，可以学到更多的软件工程的知识以及管理规划的知识，可谓海阔天空了，可以做“监工”了，有做“小老板”的感觉了。呵呵，上次我有位朋友，在单位原来是搞技术的，属于技术狂，后来由于有项目要外包给其他公司做了，他自然成了甲方负责人，开始他觉得不爽，觉得做甲方负责人无聊枯燥，整天要上听领导指示，下要面对乙方。后来我让他按上面的讲法重新思考，重新调整自己的心理状态，重新去感觉做甲方的乐趣所在，最后，由于他技术功底好，加上肯学习，很快就转换了角色了，在整个项目中对各类问题，以及和各方的关系处理的很好。

      而对于第2点的情况，应该是普遍存在的。原因可能是：可能是由于经验的不足，工程庞大，自己在这方面的业务知识还是不足够，对一些新技术之类的和乙方提出的方法不大熟，但时间又紧。在这样的情况下，建议有几点：

     1、你自己的心理上要坚信：你是甲方的负责人，你不是全能的，你的职责是把需求较好地告诉乙方，配合，监督乙方完成工作，而不是去做乙方的参谋。因此对于知识方面的缺陷，你要有个清楚的认识，如果不是涉及太核心的业务流程知识，而只是涉及到一些花俏的知识和技术，则无必要过分强调自己去全盘照收，毕竟你的精力是有限的。要搞清楚，乙方提出的新东西，是否真正适合本项目使用。这就涉及到一个评估的问题。这时建议你先把乙方的有关方案仔细研读记录，并要求乙方提出明确的根据和理由，千万不要轻信乙方表面上的东西。打个比方，乙方说要上。NET系统，吹到如何如何好，但做为甲方的你，你可以结合项目目前的具体情况，再让乙方提出根据理由进行判断，就是：
           仔细研究项目的业务流程和具体情况+要求乙方真正举出理由根据+咨询第三方意见+查询同类案例的经验

          这样的做法的好处是“反客为主”，因为要知道，有时设置甲方的负责人有可能根本不是搞技术出身！还可以咨询第三方的意见，最简单的是可以和手下开会（手下的一般都是搞技术的），和他们探讨乙方的方案。注意做为甲方负责人的你，不要那么直接让你的下级清楚你知识上的缺陷（否则太明显的话，有可能让下级对你产生不信任和认同），要通过和他们讨论，间接布置任务给他们，由他们来进行解答，从中听取相关意见。最后，还可以多查询同类案例的成功或者失败经验，搜集好这些资料，以便在开会时和乙方讨论时有根据可以提出来。

        在做好这些工作后，对于乙方提出的新玩意，你最好还是自己了解其基本原理和应用就可以了，太深的东西你根本没必要去了解，或者你让你的手下去做和整理。

    2、心理上要认为自己是掌握主动权的，因为毕竟你是甲方，你是客户，是上帝。在同乙方打交道的时候，要让乙方觉得你做为甲方的负责人，是对项目整体的把握是到位的，是有大局观的，是有很好的掌控能力的，是有领导风范的，是有经验的。因为这点是很重要的，特别是假如甲方负责人刚接手，或者是经验不足的，或者是根本不是技术出身的话，更加要在乙方面前表现得镇静自若。建议如果你手下有搞技术的人员的话，每次开会都带上他们；如果碰到乙方吹新技术，新方案的话，自己要保持冷静，如果不熟的话，可以在会上适当拖延下，让下次再讨论答复，或者让技术人员解答，有时也要在乙方面前，多表现自己的权威（甚至做下戏有时也要的，呵呵）。

     而对于第3，4点，主要是由于缺乏对乙方的量化监督。很多情况下，如果没有第三方监理的话，甲方很容易陷入盲目的监督中，比如表现在形式上的监督，要乙方定期汇报进度，缺乏在细的方面上的监督。因此有如下建议：
1、在项目一开始，就要拟订好对乙方的监督计划。比如定义的会议制度，会议需要乙方参加人员，乙方的长期联络人。监督计划最好按照里程碑来实现，不能过于太粗糙，比如等乙方完成需求调研才进行审核，可以改为：要求乙方完成需求调研中的某个部分的调研，就要提交给甲方审核一次，就象XP里一样，小规模审核。而且最好也留一定的余地给乙方，比如要求乙方在某个时间段内提交，有的时候不能对乙方太过苛刻，否则会引起乙方的不满意，影响接下来的工作。

2、  每次和乙方开会讨论问题时，要做好记录，最好能录音。开会前，按出现问题的严重程度，由高到低列出来，会上向乙方提出来，最好能搞成一个表格的形式，比如能记录乙方当时的响应，会后的响应，实际的效果等，这样以后一目了然，知道乙方到底做了些什么工作了。对于原则性问题，要明确地向乙方指出，不怕得罪乙方，而对于乙方提出的意见和方案，自己也要记录，不急于做结论，因为主动权在你手。

3 比如一份典型的监督计划的模版有可能是这样的（仅供参考）
    
   

 监督计划

 

1、  需求分析阶段中乙方对需求调研效果的监督

 

原计划内容描述
乙方计划开始日期
乙方计划结束日期
实际开始日期
实际结束日期
完成情况
滞后情况乙方描述
乙方提出的解决方案
乙方提出的问题
甲方对本阶段的意见问题
双方对下阶段的意见	甲方：   乙方：
下一任何的起始时间：
本阶段备注	这里可列出本阶段双方可参考的已有制品或文档情况
双方领导签名：	甲方 乙方

  当然，如果有第三方监理方的话，则上面加上监理的意见和看法及签名等。这样在实际操作中，就量化了，有规范了，大家都要遵守。
先写到这里，下次继续写，欢迎各位继续批评和补充，发表看法

评论

1 楼 zjh0588 2008-09-12