初任项目经理怎样与技术牛人，如何解化冲突和平相处

（一）初任项目经理如何面对与技术牛人的冲突

4年前，陆朔研究生毕业后，加入一家提供无线通信系统测试解决方案的IT企业。除市场外，从售前技术支持、研发、测试到系统交付，陆朔基本都做过。不久前，陆朔被领导任命为交付二部的项目经理，负责某专网市场客户的项目管理工作。尽管对项目的完整过程熟悉，但带团队还是头一次。
项目组的技术牛人（我称其为牛仔）孙斐，是六年前公司从竞争对手处挖来的。在众人以为孙斐将被任命为新项目经理时，公司出人预料地提拔了陆朔。
陆朔本以为有牛人存在会让自己的项目好做些，可自己被这位大拿搞得郁闷至极。陆朔一直想和孙斐搞好关系，就试着请孙斐吃饭，被不冷不热地找个理由拒绝了。“软的不行，那就公事公办吧！本就是同事关系，我也犯不上巴结你!” 陆朔想。

接下来一段时间，项目在看似风平浪静下运行。
可是，一个技术问题引发了陆朔和孙斐的争执，谁也不能说服谁。陆朔很生气，感觉孙斐倚老卖老。两周后，孙斐提出了辞职，据称是找到了更好的工作。项目到了关键阶段，孙斐果真离职，对项目的影响显而易见。麻烦的是，这么多年来公司也没有培养出孙斐的替代人选。
刚从技术走向技术管理的人，常遇到陆朔、孙斐的局面。这需要从更多角度分析，正确看待，理性面对。

一.高级管理层的安排，更多基于公司整体利益而非单个项目
6年前，公司从竞争对手将孙斐高薪挖过来算是挖墙脚行为。必须说的是，这往往也是公司不重用孙斐重要原因——你对原公司不忠又会对现公司怎样？也基于此，我对职场上的各位严正建议：跳槽须谨慎！
孙斐作为技术专家，高层希望他能带出一个团队，使工作具有可复制性（或说可控性、可替代性）。靠牛人完成工作往往有较大风险，因为人是容易出问题的。但是，孙斐长时间占据技术大拿地位，也客观上影响了其他技术人员的成长。孙斐的牛人行为，当然不是管理层愿意看到的，这也往往是牛人得不到公司重用的原因。
研究生毕业后陆朔就加入了公司，各岗位的历练使其熟悉公司业务与程序，这是成为合格项目经理的良好条件。
可见，站在公司角度，这种人事安排既合理又长远可行。做得好，可以获得以下收获：
1.给有培养前途的新人一个提升和锻炼的机会。
2.暗示牛人，公司需要有更大格局，对公司长远发展有帮助的人。
3.人尽其责，每个人都有自己的合适位置，适合做专家的发挥其技术专长、适合整合的让其做管理。

二.准备转型的技术专家谨防格局狭隘的影响
作为技术专家，孙斐来公司6年有余，一直从事具体的技术工作而未被提拔，倍感怀才不遇，这是技术牛仔们常面对的困境！
基于此，牛仔们常误认为自己的技术是公司的核心竞争力，将工作做成了“秘籍”（离了自己不行）。他们一方面不愿意将核心技术传授给同事，防止鸟尽弓藏、卸磨杀驴，一方面随时准备走人，表现出对公司的不忠诚。更不成熟的表现是，他们常借项目遇到的麻烦，凸显自己的重要性，也顺便发泄对公司的不满情绪。
转型期的技术专家需要从着眼于技术转向着眼于组织的商业价值、整体利益。孙斐没有意识到自己正处于技术转型的关键时期，狭隘的格局已经影响到自己的职业前途。此种心态、思维和格局下，即使已经找好下家也很难获得在新公司的好职位，更谈不上成为组织的核心。 

三.没有技术优势的新任项目经理如何面对与牛人的冲突
作为没有技术优势的新任项目经理，陆朔对公司业务、项目工作较为熟悉，算是具备了转型项目管理工作的条件。众所周知，从技术走向管理，本就存在诸多障碍。技术牛人孙斐的存在，加大了组织、协调、管理的难度。

既如此，陆朔应在技术上充分授权给孙斐，抱着向前辈学习的态度给足面子。不该与孙斐就技术问题争吵。
事已至此，我的建议如下：
1.主动弥补与牛人的裂痕，就自己的冲动道歉。
2. 强调依存关系：“我和项目需要你”。
3.承诺往前看、旧事不提：“从今往后”。
4.试着，从职业前景和公司层面与牛人沟通。
5.寻找后备人选，制定备用方案，做好牛人离职的准备（我不主张如此）。

（二）遇到这样的项目成员，我该怎么办？

【案例正文】
　　我进公司一年多，期间参加了两个项目的实施，一个月前，被任命为某个项目的项目经理，负责此项目的实施。项目组中有一名项目成员老王，进公司已经2年多，技术比较强，而且我承认确实也比我强，在公司属于资深人员。
　　项目目前进入概要设计阶段，项目组成员频繁的举行会议进行讨论，老王却对此很不配合：
　　(1)会议已经讨论完4个议题的时候，老王才到场，而且这种迟到的情况出现不是一次了;
　　(2)在会议上老王针对方案很少表态，基本上是一言不发：
　　(3)上午的会议中，我将设计方案在会议上做了介绍，并征求项目成员的意见，结果老王提出了自己的方案，与PM完全不一致;
　　这我该咋办?

分析：看法如下：1. 牛逼的技术人员都是有些个性的，这里需要充分尊重他，让他觉得在这个团队中的重要地位，不要害怕你的PM的权威受到了挑战。只要你让他真正融入团队了，你的PM功能才算是发挥了。2. 如果他的技术实力确实很强，那么他的方案应该是具有可取之处。3.需要跟他沟通了解他的真实想法，为什么不配合工作，方式方法你懂得，不要搞得像领导谈话一样，这样就没意思了。

分析：我的看法是这样的：第一，做技术方案或者是WBS的时候，项目经理本来就应该与技术大拿一起完成。在这个案例中，老王技术最好，就应是负责技术方案的不二人选，项目经理主要去做沟通工作。小李撇开老王独自做了技术方案，老王当然不愿意配合啦。第二，加强与老王的沟通。项目经理主要的工作就是沟通，如果连自己团队最重要的技术大拿都沟通不好，那他的工作很难说是出色的，当然就很难成功。这个时候，小李应找到老王的业余爱好，约他去喝茶、吃饭，或者去酒吧等，在放松、和谐的氛围中摆摆龙门阵，这样的沟通往往容易取得效果。第三，挖掘老王的需求。老王也是一个重要的项目干系人，他的需求对项目的完成也很重要。小李应好好分析，老王之所以不配合，是因为职位原因，还是待遇，或者纯粹是赌气？找到病根，然后对症下药，问题就容易解决了。比如，假如老王是因为职位原因不配合，那小李可以很明确地告诉老王，如果项目失败了，老王这个技术大拿也难逃其咎，谁的职位也不可能往上升；如果项目成功了，老王功不可没，他将向老板直接汇报老王的功劳，帮老王实现目标。这样一来，就让老王的需求和项目的需求往一个方向走了，矛盾自然就解决了。第四，小李还需找一个恰当的场合，向老王谈清楚一个问题：项目经理本来就不是各方面都必须强于别人的人，其80的工作是沟通，包括对上沟通、平级沟通、对下沟通；项目经理是一项专业工作，不是凭某一方面技术做的工作，不是技术好就应该做项目经理。如果项目组某位成员在某个方面超过项目经理，这是很正常的事情。当然，项目经理也很需要这些“牛人”的帮助。因此，我的建议是，小李应加强与老王的沟通，挖掘出老王的需求，帮他实现目标，同时实现项目的目标，大家和谐相处，共同干好工作。

分析：1.有技术的人都比较有个性，尊重这样的人，让他为你所用，项目成功的可能性更高；2.多和他沟通，说明利害，项目的成功需要大家的智慧；3.团队的建设需要规矩，没有规矩不成方圆，合作则对各方都有利，如果不合作，只有让他另谋高就，不能因为团队中的某个人，而影响整个团队。

分析：1、资深员工首先要尊重，在会议如何召开，方案怎么定之前多征求他的意见，加强与他沟通，说明他老员工在团队的重要性，多给他戴高帽子，投其所好，让他下不来，自然会全力配合。2、若第1条解决不了，那么就尽量收集一些他不守制度、不配合项目工作的证据，向上反馈。

分析：此种技术牛人，需要先私下判断其对你的真实态度，不服还是不屑亦或者不愿意合作，轻松的氛围下判断其内心的真实想法，然后再做决定，如果私下的场合都不理不视，这种人还是早点撤出项目组，否则其情绪一旦扩散，会对整个团队带来伤害。

分析：首先判断该成员是否是项目必须人员,如果不是申请更换合适的人员.其次，如果该成员是不可或缺的，那就必须对该成员加深了解，根据他的个性寻找合适的激励措施，动之以情，从情感上打动他，从而使其主动配合。最后，如果该成员如果持才傲物，劝说无效的状态下，向上级申请权限，对其负责部分下达责任制，严格考核，并将考核结果上报，以权力来制约他 。

分析：我觉得对这种人明显是对你的管理能力和技术能力不信任，而且总觉得他比你要厉害的多。对这种人首先要提升自己的业务能力，让他看到你有比他厉害的方面，另一方面你要认真观察他的工作方式，对他的方案要仔细分析，任何方案都有他的合理性，你可以取其所长避其所短，并虚心和他沟通，总有一天会认可你

分析：原因很简单，新来的没干多长时间就上去了，各方面能力都没有我强，你凭什么就当上项目经理了。所以在工作上处处为难你。解决办法很简单，与他沟通，再沟通，一定要深入，一定要指出他的问题，一定要对他以后的工作有所帮助，这样的沟通才会有效果，如果这样都不成，只能将其换到其它实施组，如果不成就干掉。

（三）老司机十年肺腑之言，说说技术总监的三板斧

作为一个老技术人，今天不聊技术，就聊点技术人员职业发展的事情：对技术管理岗位的认知，比如技术总监。
先贴一张技术人员职业发展路线图，按照管理路线和技术路线区分。在国外管理路线和技术路线的职位会按照 IT Manager 和 TechLead 去区分。
但在国内其实是没有纯粹的管理路线，管理岗位中一定有具体技术工作的要求。今天我说说对“技术总监”岗位职能要求的理解。

我理解技术总监的权责范畴应该包括：
►技术性工作
►管理性工作，分为人员管理（即团队管理）和项目管理
在技术型工作中，我认为更多考验的是一个技术管理者的技术深度和广度，而管理性工作中，更多考验的是一个技术管理者对于复杂人和事的协调能力。

一、技术性工作
对于一位优秀的技术人员而言，应该具备如下几种技术能力：
关键性技术能力
架构设计能力
工程管理能力
而一位技术管理者首先应该是一名优秀的技术人员，必须能在这三种技术能力之间游刃有余。
关键性技术能力
你也可以把它理解为技术难点的攻克。我曾看到过朋友圈包括饿了么 CTO 张雪峰、钉钉 CTO 一粟等，在团队面前现场 Coding 演示某些难啃骨头的解决场景。
不要求技术管理者写代码，但是在某些风险性大的技术场景里，技术管理者必须能亲自上阵，以免团队成员解决不了“甩锅”的时候可以接得起来。
而且了解团队的代码情况，融入团队的代码编写，也方便对系统架构的掌控。另外，作为示范代码，能够让管理者在团队中更好的立威。 

架构设计能力
我们在说到架构设计的时候，一般会提到“技术架构”和“业务架构”，脱离业务架构的技术架构一定不会成功。这就要求技术管理者对业务有良好的理解能力。
而且架构的设计不仅仅是指能画架构图，能写架构文档，能把热门技术堆砌到图纸上；一个没在工地上跑过的建筑设计师一定不会造出好的大楼。
反之，一个不做架构设计就想写出好系统的技术人员不是天才就是傻子。架构的设计要更好的考虑运行效率、业务的可拓展性 /伸缩性，特殊场景的分模块管理等。
如果做不到这些，系统将随业务的进展越来越冗余，最终将为如何“解耦”操碎心，“重构”往往就在这样的场景下被提出来，这是对系统和业务的具有伤害性的选择。
所以作为技术总监，必须要有大的视野去组织模块和架构，避免早期的设计缺陷造成痛苦不堪的晚期“重构”。

工程管理能力
很多人对“工程管理能力”感到陌生，如果我把这块分开说为“性能”、“运维”和“效率”大家就好理解了。我们更多的认为工程管理能力关系到稳定性和效率上。
小团队当中，工程管理能力往往价值体现不大，但当遇到一个大团队的时候，大团队的运转稳定性和效率就会成为突出问题。
这里面主要包括持续性优化的能力和工具化使用的能力，并且需要较多的靠近流程管理和业务理解，有比较多的细小和琐碎事情。
我见过很多技术管理者开发出身，但是晋升到管理者的岗位后，不得不去了解运维之类的事情。这些都属于工程管理能力的范畴。

二、管理性工作
团队管理，即人员管理
很多技术人员都很厌恶管理工作，让一个常年跟没有脾气和情绪的机器打交道的技术人员，去应付心思千万的人员管理，听上去确实很有挑战。
但你要知道，管理的目标是实现组织目标，最重要的是制定管理标准、贯彻执行和校验结果。
而这些也并非非要管理者亲力亲为，我们在组织的构建中强调的搭班子，就可以安排一些在这方面擅长的人以“副总监”甚至是“项目经理”“助理”的职位存在。
我觉得一个技术总监要分出 30% - 40% 的精力在团队的管理工作上，主要包括这些方面：

绩效考核
关于技术人员的 KPI 一直是一个千古难题，并且热度不减。难就难在技术人员工作的质量难以量化，并且受不可控因素的影响太多。
我认为给技术人员的绩效指标达到两个目的即可，一个是量化可量化的东西，一个是鼓励他的积极性。
所谓量化可量化的东西，通常我们会认为是指在时间进度上量化或者 Bug 数量、项目数量等。
但也可以将能保证“质量”的因素模块化，分模块量化，当然这个要求比较高。
因为所谓保证质量的模块，是需要技术总监确定至少是建议性，而不是丢给技术人员自行设置，比如设置必须要完成的单元测试指标、质量监控指标等。
很多人会问需不需要在技术人员的考核指标中设置业务指标，我认为在业务相对稳定的情况下是有一定有可行性的。
业务指标可以帮助技术人员更好的理解大团队的目标，知道在业务环节中技术价值的体现，更好的发挥主动能动性。

组织结构设计和人员招募
我认为组织结构设计更好的关乎团队的效率和能力发挥，包括岗位的增删减，扁平化结构还是梯度化结构，什么样的人安插在什么样的岗位上，这也是管理者应该懂得一门大课程。
而招聘上，我只想说，对于技术总监而言抓重点岗位，普通岗位的招聘可以由经理去进行，但不要小觑招聘，寻找团队平均能力以上的人是一个团队走的远的基础。

阶梯人员的培养
我比较在乎这点，就像我并不认为一个人的成长是顺其自然，我认为每个人的成长中都是受到重要的人和事的影响的。
环境对于一个人的成长非常重要，要尽可能的去创造可持续成长的环境，包括如下三点：
Code Review ，我认为有必要性。
技术团队内部技术方案的评审，最好的学习往往源于把手里的工作做好。
外部的学习和讲座，最怕坐井观天，最后被时代抛弃，不要抱着工作不放，要想象一下未来的世界和你的位置。

跨部门的沟通协调
对于技术总监而言，除了处理部门内的事情，部门外的事情也需要一定的协调沟通。
但是我并不建议多花时间在外部的会议和沟通上，更多的沟通是跟随项目走，由项目负责人去跟进和反馈即可。
你只需要协调那些别人要不来的资源，当然你能要的来，大部分原因是因为你在公司的威信，你曾给过别人的帮助。

项目管理，即对事的管理
很多公司会设立有项目经理的角色，这块就不怎么需要技术总监来操心；但反过来讲，每一位技术人员也都身兼项目经理的角色，而技术总监一定是最大的项目负责人。
有关项目的事情会比较琐碎，但完全可以按照项目负责人分配下去，技术总监需要的是指定负责人、过问项目计划和进度，另外就是在项目推进遇到阻力的时候，去解决问题。

主要包括这两方面：
项目进度：项目评审，确定项目计划；检查进度，进度延迟预警；项目验收和总结。
资源协调：人员协调，包括项目组人员以及编外人员的支持；IT 设施协调，包括硬件、软件系统等，公司内资源还有公司外资源。

写在最后
有一种说法，领导就是要拿别人拿不到的资源，做别人做不了的决定，承担别人承担不了的责任。
但是，我想说技术管理者难度更胜一层，技术管理者要先有专业性，再来领导力，需要像医者一样的仁心仁术，而不是简单粗暴的工厂管理。
我也不认同很多人认为的随着时间的增长，技术人终将成为技术管理者，否则何来的“中年危机”，不是时间的累积就能得到质的变化。
我身边也有很多技术管理者经常感叹：“感觉自己做到技术总监就到头了，未来乏力。”
只想说，从技术能力的成长，到复杂事物管理能力的成长，再到视野和决策能力的成长，这才是一个技术人员，从程序员到中层管理者（技术总监）再到高层管理者（ CTO ）的能力成长过程。
如果你觉得乏力，或许应该多出来看看，毕竟有些东西是靠钻研出来的，有些东西是靠多行路、多交流得出来的，比如情商和视野，见闻的东西多了就知道该如何处理了。