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