前一阵我参加了一次户外hiking活动，30多名参与者中竟然将近2/3都是IT从业者和学生，于是好好的一次亲近自然的户外运动活生生地变成了一场行进中的工作研讨会。队伍中有那么一群人是做项目经理的，整场的交流过程中大部分都在声讨各自的团队中的程序员和工程师，我听到最多的话都是类似于“我们公司某某程序员真傻X”，“我手下那个工程师真自大”，“我们团队那几个做技术的全都呆头呆脑的”之类的话。旁边还有几个未入世事的学生像听圣经一样专心学习这些“老项目经理”的“经验”和吐槽。

作为一个技术出身的前项目经理，我也可以如滔滔江水连绵不绝地对程序员和项目经理进行吐槽，不过我最终一句话都没敢插。听着他们侃侃而谈工作中遇到的各种奇葩故事，我仿佛从镜中看到了自己曾经工作的过往。无论在中国、美国还是澳洲，无论跟什么文化背景的人一起工作，项目经理和程序员的纷争仿佛是一个永恒的话题，原本应该协同合作、团结一致的团队总是会闹出各种各样的矛盾，甚至到互相的人身攻击。我自己也实实在在地有过无数被骂和骂别人的惨痛经历，并从中学到了太多宝贵的经验。如今我又做回了技术，跳出了项目经理这个圈子，终于可以不负责任地讲讲“技术“对于一个IT项目经理的重要性。希望能给准备进入这行的澳洲毕业生们一点点提示。

 讲故事，说道理 

关于项目经理应该学习什么课程、考什么样的证书，这都不是重点要讨论的。

像 IPMP, CAPM，Certified Scrum Master, CompTIA Project+, PRINCE2, CPMP, GAQM, MPM, CPM, PPM, PMITS, Certified Project Director这些闪闪发亮的证书，老姚我经过长期地努力学习也是一个都没有拿到。但是，最后也走运考过了PMP和中国信产部项目经理，在理论上算是合格的。可是，我们伟大的矿工、医生、作家鲁迅先生曾经说过：“管理”是你手中的方向盘，“技术”才是带你行走的车轮。

此口水文中，我边讲故事边套理论吧。理论都写在书上了，而故事却各有不同。

 项目经理的定位 

学习项目管理课程时，做得最多的事情就是案例分析，包括“风险管理”、“成本控制”、 “进度掌控”在内的方方面都可以找到无数的正面和反面案例，有些案例堪称精彩。可是很多项目经理在实际工作中确是困难重重，与团队成员难以交流，无法调动资源来解决已有的问题，更无力抵挡来自客户和公司领导给的压力等等，这一系列困境可能都是因为项目经理在最初没有找准自己的定位。就像我开头提到的那几个参加hiking的项目经理，我一听到他们在吐槽工程师，就知道他们的工作很可能走错了方向，从一开始就把自己置于一个居高临下的位置，最后导致项目滞后，然后把罪责归于每一位干活的工程师。

那么什么才是项目经理的定位？

项目经理并不是一个管理者，它并不属于公司管理层的部分，它仅仅是个干活的，而且干的都是脏乱差的苦活。承担的责任巨大，拥有的权利巨小，需要平衡来自公司内部、合作伙伴和客户的多方压力，间于齐楚，关键时刻还要顶“炸药包”。可就是这样赤裸裸的事实却被许多项目经理视而不见，把自己当作一个管理者，工作的80%时间都用来写汇报、分配任务、设置无谓的milestone，悄然地把自己置于团队的对立面。

对于IT项目来说通常涉及的技术复杂，不确定的因素太多，特别是研发类的项目，团队都是摸着石头过河，而且处处是大坑。在一个这样专业技能很强的团队里，项目经理切忌过度使用“管理决策”，而是应该站在一个服务者的角度来帮助技术团队顺利开展工作，这包括抵挡来自客户的不合理要求，化解来自公司管理层的压力，甚至私下帮助团队成员解决家庭矛盾。工程师是工作的执行者，通常都智商超群，有时你认为他们呆头呆脑情商低下，但人家或许只是不愿意搭理你。工程师的核心竞争力是他们脑袋中的知识和技能，这给了他们充分的自信可以将你的命令当作耳边风。所以不要尝试用权利来打压技术团队，这往往得到的都是negative的结果。

 讲一个故事 

我之前工作的公司有一个部门叫“大项目管理部”，专门负责公司的重大项目管理。有一年我们中标了一个大项目，包括整体的软件开发和系统集成。按照常理，我应该被指定为项目经理，负责项目整体实施，但是公司出于对项目的重视，就从大项目管理部调来了一个职业项目经理负责项目管理工作，而我只负责技术方面的实施工作。项目启动会上，这位有着15年项目管理经验的old lady并没有烧三把火，而是直接把办公室给点了。她制定的项目实施方案从管理层面来说逻辑合理，但是她之前忽略了去提前和团队成员深入探讨研发的困难和不确定性，这就意味着可能项目实施的每一步都不太可能按她的计划进行。我们不明白她为什么会犯这种低级错误，于是会议结束后我们对这位老项目经理的背景做了调查，发现她是最近才被从某知名公司挖来的，之前所从事的行业与IT并没有紧密的关系，也就是说她虽然项目管理经验丰富，但对IT技术知之甚少。而且她之前的公司技术实力雄厚，项目方案都十分成熟，成功率很高。但是这次我们的项目不同，有很多技术障碍是没有先例可循的，这会是一场艰难的战役。

有一句关于军事作战计划的话，叫“枪声一响，作废一半”。项目管理也一样，我们这个项目计划不是作废一半，而是几乎全废。项目开发和实施过程中遇到了各种意想不到的问题，团队成员加班加点全力解决问题，但是项目经理似乎看不到团队取得的成就，只顾着盯着落后的进度，并在项目例会中批评技术团队的工作效率低下，这引起了团队的愤怒。

为了追赶进度，这位项目经理对工作任务进行了调整，具体指定各项任务的责任人，并要求我们给出每项任务的完成期限。工程师A说他的任务最快需要10天完成，并试图解释为什么需要这么多天，但是项目经理立刻打断了他的话，说：“我不需要知道具体细节，我只看结果，10天时间太长，限你6天解决这个问题”。话音一落，我能感受到工程师A都想大嘴巴子上前乎她。这个项目经理因为不懂技术，无法从客观上跟团队有实质的交流，她也不了解团队成员的技术特长和个人性格，导致她做出了这么武断且咄咄逼人的决策。

接下来她将调整好的实施方案通过邮件发给项目的每个成员，并在邮件中对团队之前的工作效率提出了批评。最致命的是她将邮件抄送给了公司全部相关领导，包括公司总经理。抄送邮件给领导是项目经理惯用的手段，从管理角度上讲并没有错，而且有时十分必要，但对我们这个项目来说她的这次抄送十分不合时宜，直接激化了项目经理和技术团队的矛盾。这就像我上小学时，我们班级班长总在老师面前打我们小报告一样，遭人痛恨。

出于对这种管理方式的反感，我们决定予以回击。我在邮件上点击“全部回复”，从工程师角度向领导做了另一种形式的汇报。有过工作经验的人都知道，在向领导汇报时，尤其是向非技术出身的领导汇报工作时，要避免技术细节的阐述，因为领导大多不关心细节，只关心方案和结果。而我在邮件中却主要谈及的是技术问题和可能的技术性解决方案，并给出了大概的完成时间点，同时向公司其他技术团队请求资源支持。整篇邮件我都是以一个工程师的口吻来进行陈述，看不出丝毫项目管理的套路。

就是这封纯技术邮件使项目有了转折，领导回复表示支持我的计划，并要求项目经理协调各方资源保证我们计划顺利进行。大家可能会问为什么领导会支持我而不是那位项目经理。其实道理很简单，因为论管理我肯定不如这位老道的项目经理，但是论专业技能，我胜她一筹。项目关键的时刻，任何领导都会选择有希望解决问题的方案。我在邮件中大段地阐述技术问题，主要目的是给领导留下一种“这小子很专业，估计方案可行”的印象。就像在投资界，山西的煤老板在决定投资一个IT公司时经常会对创始人说：“你说的我不懂，但我觉得你说的有道理”。我们把这种心理战简称为“忽悠”。

接下来，按计划团队中的程序员专注搞软件开发，工程师专注做系统集成调试，而我主要负责和第三方合作厂商谈系统通信接口协议，没有任何多余的管理上的压力。大概两周以后，项目各方面都取得了重大进展，我向公司做了阶段性的汇报，公司表示满意目前进度。然后公司决定让我接任项目经理，而将那位老项目经理调到了其他项目上。其实她被调走之后没多久就离职了，具体原因不详，但我肯定这个项目给她造成了创伤。

看到这，大家可能会说：老姚，你赢了，你成功挤兑走了一位资格比你老的项目经理。如果你这么想那就错了，其实这件事上我和项目经理的命运都是被别人控制的，而控制人恰恰就是团队里那些“呆头呆脑”的工程师。前面提到的那位工程师A，是我们团队中技术最强的，比我大7岁。之前有很多技术问题其实他已经解决了，只不过他不愿意接受那位咄咄逼人的项目经理所给团队施加的高强度压力，就私下和我们商量，统一故意拖延项目进展，给项目经理造成管理困境。我们虽然心存顾虑，但也没什么其他好的选择。于是，当技术团队和项目经理的矛盾公开化后，由我提出新项目方案，然后其他工程师在短时间内交付工作成果，大步伐推进项目进展。在领导层看来，是我的方案比那位项目经理的方案更奏效，而实际上确是工程师们在背后操纵这一切。我感觉这就像电影中的桥段，艺术虽源于生活，但绝对不如生活精彩。另外，不要以为公司发现了工程师的把戏后会轻易地开掉他们，那无异于自掘坟墓。

通过这个故事总结一下：IT项目，技术是核心，看的是结果，再牛X的管理策略也产生不了创造力。项目经理必须要服务好团队，为团队扫除外围障碍并提供一切可能的资源，不要把自己置于团队的对立面。我感觉项目经理就好比是电影剧组的制片人，而不是导演。

 专业技能是核心领导力 

我在墨尔本参加过很多次项目管理相关的meetup，并不出我意外，去参加meetup的项目经理来自各行各业，有通信、电子、IT、医疗等等，几乎都是技术出身。我去的目的一是为了混吃混喝，二是听听各路大牛谈谈各自行业的技术发展趋势，三就是交流一下项目管理经验。

在领导一个技术团队时，项目经理经常会遇到一种困境，就是团队中的技术大牛十分难于管理，他们总有一套自己的行事风格，使项目经理难以树立威信，无法发挥核心领导力。在一次meetup上，我们重点讨论了这个问题，每个人都讲了自己的经验，仿佛都十分有效。不过一个来自荷兰的项目经理的故事给我留下了深刻的印象，我早已忘了他的名字（本来就没记住），就暂时叫他David吧。

David做项目经理之前做了几年C++程序员，写了不少程序，他们公司当时用的是集中化的源代码管理程序perforce，那时候还没有github。雁过拔毛，人过留声，David在公司服务器上留下了许多署有他名字的源代码，他也是他们公司为数不多的具有软件开发背景的项目经理之一。David在他负责的一个项目上出现了困境，当时他团队里有一个程序员一边参与着David领导的项目，一边又同时参与其他多个项目。其实一个程序员参与多个项目或者一个项目经理同时负责多个项目的情况十分普遍，在这种情况下，每个项目经理都希望团队成员可以全心全意为自己的项目工作，而少去参与其他项目。David遇到的情况是，那位程序员把David的项目优先级评估得很低，总是把David这边的工作无限地拖延，这使David十分苦恼。那位程序员在其他项目上的工作进展也并不顺利，他在用C++编写一个设备控制驱动时遇到了困难。有一天，他在公司的源代码服务器上发现了David曾经编写过类似的程序，并跑来向David请教。David本来内心就一直怀有对这位程序员的不满，而且他的项目忙得不可开交，根本没有时间来帮助这位程序员去解决其他项目上的问题。但是David不但没拒绝，反而自己主动加班到深夜，和那位程序员连续几日的奋战把问题解决掉了。从此以后，这位程序员对David的项目不再有怠慢，也变得易于被领导了，总是很听David的话。

项目结束很久以后， David自己总结出了原因：那位程序员并不是单纯出于感谢David而顺从David的领导，而是因为David在帮助他解决问题的时候充分地体现出了专业性，在程序员心中树立了技术权威。在这种权威被树立之前，项目经理提出的建议、意见和命令很容易被团队中的技术专家所忽略，而一旦这种权威被树立，就容易得到团队成员的支持。这并不是什么新鲜的理论，这正是项目管理学中的“发挥专家技术权威性”。但请记住这种权威性的发挥一定要讲技巧，让他人从内心佩服，而不是强迫于别人顺从。

打铁还需自身硬，把专业技能作为核心领导力不但可以使团队管理变得轻松，有时也会帮你在客户那边树立威信，从而获得多方面支持，使项目可以顺利进行。

项目延期是常见的事情，事实上很少有项目是按照计划完成的。客户（甲方）很少有不讲道理不允许延期的，在向客户做汇报时有时必须要做到专业。比如，我们公司的客户大多是中国的国企，不要以为国企的领导都是肥头大耳的技术盲，恰恰相反，这些领导各个都是精英，大多曾经都是技术大牛，从一线摸爬滚打一步步走上来的，蒙是蒙不住的。所以我在向客户领导请求项目延期时，都会首先从技术上讲解为什么项目出现了滞后，以及我们会以什么样的方案来解决。大多数时候都会得到客户的谅解，既为自己争取了更多的时间，又和客户维护了良好的关系。如果一个项目经理一点技术不懂，就算陪领导喝多少五粮液都白扯。

 总结 

讲了两个故事，又讲了一大堆道理，今天的重点就是讲专业技术对于一个项目经理的重要性，如果你现在是个项目经理或者以后想成为一个项目经理，除了学习项目管理知识外，一定要广泛深入地学习你所在行业的技术细节和发展趋势。管理既是服务，服务既是管理。

项目管理的套路实在太多，今天只讲了一个侧面，如果你觉得有用，下期节目我再从另一个侧面讲讲故事。如果你觉得没用，我建议你可以直接竞选下届美国总统。