3. 心态对抗解析
为了说明如何这种心态对抗是如何产生的，前面我们对每一种角色在项目开发中所产生的心态进行了适量的描述，下面我们看一下这些心态的分析和对抗解析。

3.1. 高层管理者与项目管理者
要讨论高层管理者与项目管理者之间的关系，首先要了解程序员的心态，只有这样才能让项目管理者理清自己的位置，才能让高层管理者明白项目管理者为什么如此思考问题。关于程序员的心态请参看第一篇中的2.2节和3.1节的内容。
在项目进行中，项目管理者经常遇到的问题如下：
1、 团队内部分或者全部程序员待遇偏低，领导不给涨工资。
2、 对任务的分析与程序员之间有分歧。
3、 程序员不配合自己或者积极性较差。
4、 在其位而无实权，没有基本的奖惩权力。无法对程序员的积极工作进行表彰或者错误进行惩罚。
5、 担心项目中主要技术人员在项目进行中发生变动。
6、 ……
而在项目进行中，高层管理者除了正常的管理工作外，会有如下担心：
1、 项目进展是否顺利，能否按期交货。
2、 按期交货，能否保证运行质量，让用户少提意见，尽快付款。
3、 项目成本不要上升，最好能按照预计的进行，或者更多地节约。
4、 项目经理不要在项目中拉拢帮派，以免公司被架空，发生更大的危险。
5、 ……
总之，项目经理是从项目层面上考虑团队/项目的管理问题，而企业管理者是从企业盈利的角度来考虑项目管理问题。
从上面来看，可以看出两者的想法之间有不少冲突点，这里列举如下：
1、 项目管理者的1和高层管理者的3；
2、 项目管理者的3和高层管理者的1、2、3；
3、 项目管理者的4和高层管理者的3、4；
4、 项目管理者的5和高层管理者的1、2、3；
项目管理者由于职责要求，必须保证项目按期保质保量的完成，而在实际情况下，几乎90%以上的项目都会延期（参看《死亡之旅》），其原因不仅限于上面几种，除了在第一篇中已经分析过的项目管理者与程序员之间的关系，本文重点分析高层管理者与项目经理之间的关系，所以其他外部关系和原因暂不考虑。
3.1.1． 第一个问题分析
对于第一个问题，这是涉及到公司整体管理的一个问题，同时还会影响到项目的成本，所以，直接和高层管理者关注的第三点相冲突。当然，总所周知的是，国内程序员工资收入水平是相对较低的，这个问题的解决往往是项目管理者没有权力做到的。对于一个优秀的项目管理者而言，他往往会根据团队中程序员的表现向高层管理者反映相关情况，并期望获得高层管理者的理解，至少在项目周期内获得一定数量比例的月度奖金分配权利。但是，在提出这个申请的同时又会触发高层管理者担心的第四个关注点的产生，因此，项目经理往往很难得到这样的支持。这就是冲突之一！
其实从正常的心态分析，一个优秀的项目管理者不会脱离公司来做一些事情，对于每个程序员来说，他拿到的额外的工资奖金是公司发给他的，项目管理者虽然起到了一定的促进作用，而如果没有公司高层的理解和体谅，他也明白自己是不可能拿到这些的。
在团队内如果只是部分程序员收入相对偏低，那还可以理解，对于项目管理者来说这方面的压力并不是很大。而如果普遍偏低，那带来的后果，虽然因为人的适应性可以调控，但是，却不会因此让人保持沉默。可以说，在普遍的低收入状况下，人遇到机会，是会选择新的机会的，哪怕新的机会并不一定有什么新的好处和更好的未来，至少对于任何一个人来说，都会憧憬新的机遇能够带来相对较好的未来。
一个不负责任的项目管理者会带着团队在自己承接的项目过程中跳槽离开。而一个优秀的项目管理者永远不会劝说自己团队内的技术人员在项目进行中辞职！但是，他会劝说得到不公平待遇的技术人员在项目结束后辞职！这并不是说他对公司有二心，而是他作为一个人，作为一个优秀的项目管理者应该做到的对上和对下都负责的处世方法。公司的高层管理者必须体会到这一点，并且体谅这个项目管理者的做法。因为只有他的这种做法才能在最大限度内保证公司当前进展的项目得到最高效的完成，最大限度范围内的降低公司的开发成本。
如果真的是公司运营和经费问题，高层管理者应该放心地将这些问题和项目经理进行商谈，你既然敢把一个项目组交给他来运作管理，你就应该敢把公司的危机问题也告诉他，要知道，一个项目的失败可能会比公司财政危机的现状泄露更危险，而如果你不能信任这个项目管理者，那你就更不应该把团队交给他来管理了。
3.1.2． 第二个问题
这个问题和高层管理者无关，只和程序员有关，这个问题的讨论请参看《》，本文不再叙述。这里只需要补充一句，如果这个问题项目管理者都不能合理的解决好，高层管理者似乎应该反省一下自己，是不是选错人了。
3.1.3． 第三个问题
程序员的不配合和工作积极性差将会导致项目任务的延期完成，整个项目进度的拖延，同时带来交付日期的延后，往往因此根据合同，客户方也会延缓相关合同款项的支付。这种延期必然造成项目成本上升，客户的满意度下降和合同履行延期等问题。
这个问题上，高层管理者一般都会支持项目管理者的做法，来促进团队内程序员的工作积极性，但是，相关的原因可能会涉及到很多方面，如果是技术方面的问题，项目管理者必须有能力来解决或者协调解决的，而对于非技术方面的问题会在其它几个方面做出讨论，这里就不再继续了。
这种情况下除了正常的解决途径外，如果是因为长时间开发任务使得技术人员过于疲劳而产生了工作任务延期的问题，可以考虑我下面这种方式：
在开发进度遇到延迟的时候，可以考虑给所有的开发人员更换一个开发环境，因为，当一个人到达一个新的工作环境的时候，往往会因为外界的刺激，让人的神经在两到三个月内保持相当高的兴奋度，这种兴奋度可以在一定程度上与人对周围环境的疲劳度进行抵消，让技术人员持续高效地完成一些开发任务。
这个建议我提供给我那个合作方公司的总经理朋友后，他很高兴，他说他们在威海有足够多的场地，可以将公司总部的技术人员调动到那里去做开发，这是个很好的建议，他回去后立刻就去实施。
3.1.4． 第四个问题
这个问题是中国最常见的项目管理者的困境，这也是很多公司不敢轻易解决的问题。甚至可以说，很多项目最终失败的原因并不是选择的项目管理者有问题，或者技术人员有问题，而是因为这个问题没有解决好带来了负面的效应造成的。
最有效的管理方式莫过于奖罚分明，而奖罚，在公司里面能做到些什么？我们可以考虑一下。
可能的处罚措施基本罗列如下：扣工资/奖金、延长加班时间/减少休息日、训斥、体罚、打骂、辞退……
这里面延长加班时间/减少休息日对于程序员来说简直不是出发，就是日常工作状态，剩下的除了扣工资/奖金、训斥、辞退这三个意外，其他的都是不可行的。而辞退，对于一个仍然对公司有价值的程序员来说，是不能轻易实施的，要知道，开发组本来人手就不足，还敢辞退？是不是不想完成项目了？那剩下的就是扣工资/奖金、训斥这两种手段了。
扣工资/奖金，怎么扣？如何扣？扣多少？这都是一个问题，扣多了，人家辞职了，你就成了变相的辞退，对项目不利。扣少了，人家怠工了，本来收入就不高，还要扣除，结果仍然等同于辞退。于是，项目经理的手段就减少了，只有训斥，那我们来看看训斥的结果。你项目管理者技术很牛，说话让人家信服，那你训也就训了，大多数技术人员都不会反抗，因为你说得有道理，他会反省自己，但是，如果你的技术不够牛，不能让人信服，那后果是什么，几乎所有做过项目管理工作的人应该都能想象到的。
可能的奖励措施基本罗列如下：增发奖金、增加休息日、公开表扬、提职加薪、请他吃饭……
这里一般来说提职加薪是没有什么可能的，因为你只是个项目经理，没有那么大的权力。
请他吃饭，这是可行的方法，但是，如果让你花自己的钱请他吃饭，你是不是觉得有点亏呢？而公司给你的待遇也不够高的情况下，公司又不给你报账的情况下，或者说，公司也在同时压低项目管理者本人的收入，那你还能有心情为了公司的事务自掏腰包请别人吃饭么？
公开表扬，这也是可行的方法之一，但是，光是口头表扬，其实意义不大，所有的技术人员都已经很清楚这种空头支票的价值几许了。
增加休息日，这个方法看似可行，但是，实际想想，你能增加几天？少于两天的话你可以回想一下：这些程序员每天增加的加班时间是多少？他们被占用的休息日有多少？增加休息日的价值大么？很多时候对于程序员来说，休息日本来就不存在，尤其是增加的，连找朋友聊天都没人，就一个人在家里睡大觉么？更没有意思，所以，增加休息日的方法，真得可行么？而你增加超过两天，高层管理者能同意么？
那最后一个办法，就是增发奖金。一提到钱，大家都会感兴趣，至少对于我们这些收入微薄的技术人员来说，不可能不感兴趣，大家也会认为这是最实在的表扬方式了。这里就遇到下一个问题：高层管理者是否同意增发？毕竟这种奖金是额外增加的，对于项目来说，将会造成项目成本的提高，对于公司来说将是一个额外的成本开支。但是，发不发，是一回事，发多少好像又是另一回事。
这里我列举一个我曾经经历的公司的政策制度：
当年那家公司为了激发技术人员参与项目的热情，在月初发布了一个政策，允许项目中对部分人员进行高聘。也就是给这些技术人员一个短期内拿到较高工资的机会。当时大家听到以后都很激动，都觉得公司在为我们考虑了。要知道，当时很多人正在因为半年一次的提升机会数量过少没有机会提升而感到不满。
可是，在下个月初上报项目高聘工资之前三天，公司发布了新的政策，内容说，一个项目组中的高聘人员不能超过项目总人数的5%（具体数字记不大清楚了，但绝对不会超过10%），高聘最多高聘一个级别，然后又在部门整体的高聘人数上进行了一个限制，每个部门的高聘人数比例不能超过3%（比前一个数字低），后来又增加了一条：高聘的理由必须经过专家委员会的审核，通过后才能得到高聘，同时，每个月都要重新申请一次。
于是众人哗然！然后在项目中，有个项目经理直接给自己办理了高聘，理由很充分，如果我的工作都没做好，整个项目自然更不会好。另一个项目组中，项目经理没有给自己做高聘，而是给下面的两个弟兄作了高聘，而其中一个后来因为部门总人数比例超标，被取消了高聘资格。
3.1.5． 第五个问题
如何稳定项目组中的主要技术人员，让他们安心的在项目中努力工作，这个问题相对于前面的问题会比较容易解决，主要的重点在于，项目管理者如何向高层管理者解释清楚，这个人为什么重要！只要能说明这个问题，高层管理者至少都会表示体谅的。
这里应该举一个前面提到的例子：
我那个合作方公司总经理的朋友对我说他一直很担心。于是，他们公司推出了一项新的政策：在公司工作满三年的员工，如果需要买房结婚，公司可以提供10万元无息贷款，在5年内按月从工资中扣除归还公司。后面他还打算推出相类似的政策支持员工买车和其他大件消费品。
他说，通过这种方式，他留下了几个技术人员，终于有一点安心了，但是，还是经常遇到问题，比如这次提出要辞职的那个做硬件开发的技术人员，就再次让他头疼了很久。
于是，我给他提出了我的建议，不仅是软件开发，硬件开发也是一样，都可以参考我的交换编程的概念，来进行人员备份工作。但是，他对此却产生了异议，并说，在他们那里找到一个合适的技术人员很困难，好的基本上都跑到北京、上海、广州、深圳了，所以，让他找个这样的人员来做交换，难度太大了。他前面的技术人员也都是自己培养了三年多才培养起来的。
这里面其实就涉及到一个问题：公司对员工的投入是否能够让员工感到安心并产生报恩的感觉，中国人自古就讲“义”字，其实，除了正常合理的金钱支出外，通过管理方式，尤其是人与人之间的沟通交流，是可以解决大多数问题的。
而我这个朋友一直都是把员工当作员工，并没有当作自己的兄弟来看待，这也是他对这些下面的技术人员严重不放心的原因。他给我说，如果这个人到了一定程度，可以被他认为吸纳作为兄弟的时候，他才可以放心得如何如何。而这句话，我没有当着他的面反驳，因为我觉得他的思路进入了一个误区，这个误区就是：并没有真心地和下面的技术人员交心，表面文章做的比实质得多。因此，我后续的考虑和建议，也就没有更多的对他提出了，因为他的兴趣主要在如何为企业直接盈利，而不是如何长期的保持企业团队的技术稳定和发展状态上。随后，我和他的合作也产生了一些分歧，我就没有再和他续签后续的合同，虽然他每次到北京还是会过来请我吃顿饭，聊聊天，但是，我却感觉，他的公司不是我能够完全认同的公司，不是一个能推动我所认同的整体的管理思想和方式的场所——其根本原因，就是因为企业高层管理者对员工的本质想法。

3.1.6． 汇总
上面这几个问题其实更深层次的问题就在于，公司是否足够信任项目经理的管理操作，对于高层管理者来说，他也很担心项目管理者在公司里面拉帮结派，形成自己的独立实体而与公司对立，但是，他又希望项目管理者能够留下这些技术人员和他们搞好关系。其实，对于高层管理者来说，他本人也喜欢使用自己熟悉的人，中国历来都有一朝天子一朝臣的说法，不拉帮结派，怎么搞好关系？怎么才能团结人？
这里顾虑的深层次原因有两点：一是高层管理者对程序员的心态不够了解，二是过于顾忌项目管理者的人际关系好可能给公司带来的不利因素，却没有考虑到另一个方面。
程序员的心态相对来说是传统的中国文人/技术人员的心态居多，更多的是
只有项目管理者的人际关系足够好，才能让技术人员和他交心，才能在足够的程度上稳定公司的项目团队。其实，高层管理者更应该反过来思考一下，既然项目管理者有能力将团队内的人员稳定住，这对你难道不是一件简单的事情么？本来你需要应对整个项目团队的单一的个人的去留问题，每个单一的个人都是你必须考虑的问题，而现在，你只需要考虑一个人，就是项目管理者自身就可以了，解决好他的问题，他就可以帮你留住整个团队，保证你的项目实施。相反，如果他留不住项目组中的技术人员，无法团结他们，这时候才应该是你高层管理者真正担心的事情。对于管理问题，将矛盾集中于一点进行解决，比矛盾散播于多点的解决方案要简单得多，往往不需要全部解决，只要部分解决也一样能极大的缓解矛盾冲突。这和写代码不一样，写代码更倾向于将接口简单化，而不是将所有的接口集中于一点。反过来想一下，如果你这个高层管理人员都不能留住自己的下属（项目管理者），你怎么才能让他留住自己团队的技术人员呢？
对于一个软件公司来说，技术人员就是广大的劳动人民，如果没有了技术人员的存在，你这个公司再好，也就是个倒买倒卖的，不可能做大，善待你的技术人员，这样才能保证你的舟不会轻易颠覆。
给你的项目经理以一定的权力，让他可以对项目组的成员进行奖励和处罚，要知道，平时的加班已经是一种违反规定的处罚方式了，因此，为了团队的工作积极性和稳定性，付出一些小的资金来奖励一些技术人员也是应该的。
3.2. 高层管理者与程序员
这方面的内容在第一篇中进行了相关讨论，这里就不作补充了

3.3. 高层管理者与周边角色
高层管理者与周边角色的关系主要是在于市场推动活动以及相关的资源信息管理上，或者说带有很强市场性质的工作活动，不属于本文的重点讨论内容，限于篇幅也就不在本文继续讨论了。