技术型项目管理者需要思维转变，更需要全局观

(一)转型做项目经理，一定要注意全局观

现在有不少搞技术的人转型做项目经理，但要知道的是搞技术和做项目管理间有个最关键区别，就是要关注事情的视角不一样，这是转不转得好要解决的关键问题。

我们来看一个实际案例：

翁金海刚刚入职一家IT公司，虽然之前他已经有了将近3年的项目管理工作经验，不过现在的领导似乎还是对他不太放心，所以在他接手的第一个项目中，被分配的角色是项目经理助理。

这是一个规模不大的常规项目，担任项目经理的是公司系统部资深技术大拿吴锐。名校背景的吴锐一毕业就来到了这家公司，已经快10年了。凭借出色的技术能力和认真的工作态度得到了公司高层领导的信任。安排翁金海做吴锐的助手，也算是对翁金海的信任:让专家带一带，希望他能迅速上手，承担起应有的责任。

原本领导的安排让翁金海很高兴，毕竟不是每个新人都有机会和专家共事的。可是没过多久，烦恼就来了：吴锐虽然在技术上是大拿，可在管理项目这个问题上真是让人没法恭维:在项目的执行过程中，吴锐最喜欢盯住项目的技术细节不放，有时候还亲自上阵，带着几个技术一搞就是一通宵。眼看项目的工期已经延误了，翁金海每次在项目例会上提醒他注意进度，他都一副无所谓的样子，总把“加加班就回来了”挂在嘴边。更让人纠结的是，当客户提出变更要求的时候，吴锐的判断标准基本上只有一个：只要技术上能实现的，都来者不拒! 

眼看着项目的范围越做越大，加班的时间越来越长，翁金海干着急却没办法。既然不能说服吴锐，干脆直接找领导反映吧。没想到正赶上这个项目的客户来访，客户除了答应为新增加的项目产品功能买单，还把吴锐表扬了一通，说他对需求理解透彻，经验丰富。结果不等翁金海把自己对吴锐管理项目的看法说完，就被领导打断了，还让他做好项目经理助理的工作，多向老员工学习，多沟通。

翁金海应该怎么办呢?

这个案例描述的内容有些复杂：技术做项目经理，不管项目只盯技术;虽然对待客户需求的态度不严谨，却并没有造成太大的损失，反而得到了客户的认可;真正有管理经验的项目经理不但没能说服领导，还被要求向技术专家学习!虽然真实的项目实践往往要比教科书上的例子更复杂，但是其中反映出的原理和知识却是相通的。

从案例中我们能够确定，这个项目经理在管理方面确实有问题。最突出的表现就是“专家心态”太强。所谓“专家心态”，是指那些自身在专业技术领域具有较高的水平和能力的人，在遇到具体问题时表现出来的对他人的不信任，同时又过度自信的表现。对于从事技术的人员来说，适当的“大拿心态”往往难以避免，同时也无伤大雅;但是如果这些专家承担的是管理职责，比如案例中的吴锐，过度的“大拿心态”就会使得他们过于关注技术细节，缺乏全局观。忽略了作为项目经理的职责，不利于项目目标的实现。

作为团队的管理者，适当的发挥自己在相关专业领域的技术特长原本是好事，但是如果在具体的技术问题上涉足太多，反而不利于团队成员承担应有的职责，发挥他们必要的积极性和主动性。项目经理不是不能参与项目的细节层面的工作，而是要讲求方式方法。在资源充足的情况下，项目经理应该扮演顾问的角色，更多发挥自己的经验，给团队成员以必要的指导。在资源不足的情况下，项目经理可以合理承担必要的具体工作任务，但是也应该有明确的责任划分，做到团队成员各司其职，而不要过度的越界、插手别人的工作内容。从案例背景的描述中可以看出，这位资深的技术专家虽然名义上是项目经理，实际上做的却是技术工程师的工作，并且还在享受来自解决具体技术难题所带来的成就感和满足感，甚至对项目出现了延期也满不在乎，反而把加班当作解决问题的“灵丹妙药”。从这个角度看，徐阳也许是个合格的，甚至优秀的技术工程师，但真的不是一名合格的项目管理者。在他的头脑中，缺乏对项目的责任感，甚至没有搞清楚自己应该做什么。

管理学从来不是非黑即白那么简单，在这个案例中，不合格的项目经理吴锐在工作中也有值得肯定的地方。比如他能赢得客户的信任，在客户看来，他对需求理解透彻，经验丰富。在项目活动中，能得到客户的理解和认可对团队来说是最大的利好，这对于工作的开展和推进都将起到非常积极的作用。

在一些特定的行业中，由于激烈的市场竞争，一方面甲方变得越来越强势，在项目中说一不二;另一方面乙方为了争取到市场和订单，对客户言听计从，甚至不惜做出过度承诺。这两种情况往往互相影响，形成恶性循环。其实，这种不顾客观条件和技术制约，一味迎合客户的行为表面看是对客户的尊重，实际上最终双方都要受到伤害。在这种情况下，一些客户往往更愿意与技术人员沟通，因为相比市场人员，他们的想法会更“单纯”，更“靠谱”。无数实践表明，从科学的角度出发，基于严谨、客观的态度，用事实说话，比无原则的迎合更能得到客户的理解。案例中的徐阳，就是以技术专家的身份，在与客户交流的过程中赢得了认可与信任。虽然项目范围被扩大了，但是在技术层面都能够得到实现，并没有引入更多的风险。更重要的是客户也乐于为增加的内容买单，这在一定程度上是把项目的“蛋糕”做大了，相信在通常比较敏感的进度问题上，也能和客户达成新的一致。

接下来再看看这位新入职的翁金海。翁金海在这个案例中虽然被分派的是项目经理助理的角色，却真正用了项目经理的心!首先他有3年的项目管理经验，相比吴锐，在面对项目工作时，更有项目整体的大局观，比如能意识到项目经理过于关注技术这种行为的不妥，能及时发现项目工期出现了延误，包括及时向高层领导汇报项目工作中遇到的、已经超出自己控制范围的问题，希望通过领导的力量将项目偏移纠正回计划的方向。这些细节都表现出晓明确实具有项目经理应该具备的良好素质和工作思路，这对于领导和管理一个项目，并确保项目目标的达成是非常有益的。

和吴锐类似，翁金海在工作中的表现既有可圈可点的优势，也存在一些需要弥补的不足。比如在沟通的问题上，他虽然已经意识到了项目经理存在的缺陷，却没能成功让对方接受自己的观点;在向领导反馈项目问题的时候，也没能让领导了解项目经理存在的真正问题。案例中虽然没有给出更多关于翁金海是如何与吴锐及领导沟通的细节，但是我们相信在这个沟通过程中，翁金海还是应该有一些可以改进的地方。比如在提醒项目经理要关注进度的时候，是在“项目例会”上。项目例会是个公开的环境，除了自己和项目经理，一定还有其他团队成员，如此开放的环境中对别人提出当面的质疑，一定程度上会影响自己意见被采纳，甚至被理会的效果。如果采取私下，面对面的非公开方式，更详细的说出自己的想法，并给出适当的建议，也许会有不同的结果。在向领导反馈问题时，除了口头表达，如果能辅以必要的文件、数据，再加上自己的观点，通常也能够提高领导理解和重视的程度。

项目经理不是个简单的角色，除了自身要具备技术方面的硬技能，也离不开沟通、协调的软技巧，只有两手都抓，两手都硬，才能让项目工作得到有效的管理。

（二）项目经理怎么应对技术型领导

【案例正文】
　　本人刚换了新工作，到一个小公司的项目管理部，部门成立没多久，公司比较小，不是很正规，管理流程不健全，工具也没有。部门经理原来是做技术的，现在转成管理，感觉不是特别懂管理，好多思想还停留在技术上，部门同事也不懂，感觉现在公司的项目管理非常混乱，项目经理经常抱怨。我刚到公司好多想法没办法提，就算提了感觉执行的可能性也很小，不知道大家遇到过这种情况没有?
　　<-我的疑问->
　　1、公司的管理流程不健全，作为一个刚入职的员工应该提意见吗?
　　2、如果领导是技术型的，应该怎么应对?

分析：1.员工完成本职工作。2.领导技术型决定不在与你能改变的。3.身为技术型领导，一般对自己技术都比较傲气。不必要冲突，有技术问题让他出方案即可。4.无需应对，发生问题是团队整体问题，身为领导第一个首当其冲负责，所以你没必要纠结。

分析：应对技术性的领导，首先要尊重他的技术偏好，以便获得他的好感，进而深入其他管理领域的脚交流和沟通，慢慢的融合他就好了，任何人都不会是铁板一块。至于新来员工开会是否发言的问题，如果是刚参加工作的员工，最好是先听，可以以学习的目的提出提问，如果是经验丰富的老员工入职，可以提一些针对性的问题，千万不要带刺，委婉一点。

分析：1. 没必要先指出这些问题，等遇到事情后，一点点暴露，一点点指出，循序渐进2.技术方面，让他找到满足感，多和他聊管理方面的东西.

分析：技术型领导重视细节。所以，可以将细节性的东西多给他审查一下。技术型领导往往反对客户技术变更。所以，可以将变更的问题比较有技巧地提出来，如以内部设计优化的方式和团队讨论，这样往往效果好些。

分析：在比较混乱的流程下工作自由度比较大，也会造成很多麻烦。但是建立体系和流程不可能是一朝一夕能完成的，尤其是你的领导自己也不懂。我想还是先配合领导的想法，在技术工作方面不出现错误前提下，一点点向领导展示你的想法。领导一定会有认同你的时候。

（三）技术型项目经理的常见问题分析

大部分公司，都是领导觉得你技术做得不错，那带个项目试试吧，于是开始了备受折磨的PM生涯，以下是本人做项目经理时遇到的各种问题，愿与各位PM交流探讨，欢迎批评指正。

1.项目经理累得吐血，可其他人员闲的发慌

初当项目经理时，心中想的是三国-曹彰：“为将者，被坚执锐，临难不顾，为士卒先；赏必行，罚必信。”觉得自己是项目组里技术最强的，技术困难自己上，其他人员处理简单问题。可在项目过程中发现，自己会被各路神仙频繁骚扰，基本上是白天回邮件晚上写代码，一不留神就导致项目延期。而项目组其他成员，都有大把的时间处理简单问题，能不闲吗？长此以往，项目经历累得吐血，项目成员还埋怨项目无法让自己得到成长，得不到认可，不敢承担关键业务，从而造成恶性循环。

作为项目经理，首先应当信任项目组成员，其次应当在项目组内挖掘具有技术骨干潜质的技术人员，并重点培养，为自己分担技术工作。随着项目的开展，成员能力逐步提升，获取更多的认可，可以承担更有挑战性的工作，从而形成良性循环。当然依靠新人完成关键业务存在风险，但我想项目经理通过监控手段，从旁协助，可以降低此类风险的发生概率。做最坏的打算，如果培养出来了2-3名信得过的得力助手，哪怕项目出现延期我认为也是值得的。 

  

2.布置的任务，总是无法按期完成，在我看来是件很容易的事

许多任务，项目经历认为应该很简单，但布置下去后，总是无法按期完成，集腋成裘，造成项目失控。这种情况下，作为项目经历应该反思，并问自己这几个问题：

任务划分粒度足够小吗？任务划分粒度越大，对任务执行人的要求越高。举个例子，高级工程师可以独立承担模块的设计与开发，中级工程师能够独立完成类的设计与开发，而初级工程师也许只能独立完成一个函数的设计与开发。任务的划分粒度，如果对执行者来说太大，那么注定了任务会异常。
任务划分合理吗？很多项目都会出现模块职责不清晰，任务划分不明确的情况，本来应该并行的任务却只能串行，从而导致任务间的等待、异常。
对他足够了解吗？这一点与任务划分粒度息息相关，对一名开发人员是否了解，决定了你安排的任务是否合理。不要让项目出现“马谡失街亭”的故事。
你想要的和他做的一致吗？对于技术出身的项目经理来说，多少都会有些自以为是，认为自己想的应该就是他人想的，可惜现实往往并非如此。也许是因为沟通时的信息丢失，也许是因为理解能力的差异，你想要的和他认为你想要的，总是存在偏差，新组建的项目团队由于默契度不高这种现象非常普遍。所以对于重点任务，在开工之前一定要确认执行者的理解与你一致，并在执行过程中适时监控、及时纠偏，以保证任务结果是你想要的。
估算和预期可行性大吗？项目计划是领导拍脑袋，项目经历拍胸脯拍出来的吗？项目的预期是否过高了，这样的预期对项目组来说到底是正激励还是负激励呢？拍胸脯时的英雄气概，换来的可是项目组无休止的加班和大家对你的不信任。

3.越到产品发布时间，问题出现得越多

有一种说法是“Deadline才是第一生产力”。程序员的工作总是会掐在最后的时间完成，在下班前一秒，编译通过，然后欢呼雀跃的提交代码，并告诉项目经理任务完成了。测试时往往漏洞百出，Bug不断，直到项目发布前才拼着老命把问题解决完，发布上线。项目经理总是越到后期发现问题越多、事情越多。

这种情况下，作为项目经历应该反思，并问自己这几个问题：

WBS分解有遗漏吗？不要漏掉WBS分解造成的隐形工作量，如模块集成、接口测试等等，否则你会发现Deadline来临时，你拥有的只是一堆自我表现完美的积木，而不是完美拼接出来的伦敦塔桥。
里程碑评审有严格执行吗？项目经理很容易只盯着发布时间而忽略了过程中的里程碑评审，殊不知产品发布原也只是这诸多里程碑中普通的一员。前期的里程碑评审不严格，误差不断积累，最终演变成项目失控，只能在项目后期加班恶补。正确的节奏应该是，重视过程中的每一个里程碑，保证每一个里程碑的完成质量，一不小心就顺便完成了项目发布这一里程碑。
有没有可以在前期完成的工作？有一次送我弟弟坐火车，一路狂奔总算按点到了火车站，还预留了十分钟，可这小子车票还没拿，得先去售票厅拿车票，结果因为排队人多而延误了火车。后来我想，从项目管理的角度看，那火车票这件事为什么一定要放到最后来做？这不是把风险留到最后处理了吗？所以，请好好想想你的项目中，是否也有可以提前拿的火车票呢？

4.天天加班，昼夜颠倒，项目组怨声载道，怒气冲冲

关于这一点，如果加班是公司绩效考核重要指标的话，你可以请领导品味下这句话：“当一个管理者的智慧无法衡量一支团队的产出的时候，他就会把“工时”当做最后的救命稻草，死死抱住——这是他唯一听得懂的东西了。”

我发现很多人加班是基于这两个原因：1）加班是因为工作时间不够投入导致的心虚表现；2）加班是因为其他人都在，所以自己也需要在的面子表现。作为项目经理，请在项目能够按时完成的前提下想尽一切办法让项目组不加班。应对突发事件、冲刺型项目，有时确实需要通过加班才能完成，但这不应该是常态。长时间的加班极容易导致项目组人员疲惫，产品质量差，市场表现不如意，员工愤而离职的恶性循环。

5.项目这么忙，领导和QA老是来烦我怎么办？

在项目如火如荼进行的时候，领导和QA总是会不厌其烦地询问项目进展，这意味着你没有让他们放心。项目周报有按时抄送给大家吗？项目周报有描述项目进展、遇到的问题以及解决方案吗？项目周报能够充分地表达项目在你控制范围内吗？项目周报能给他们信心吗？

永远不要跟领导和QA解释技术细节，如果谈了，请接受他们茫然而又不耐烦的眼神。永远不要给领导和QA惊喜。无论惊喜是否有利，都将降低你在他们心中的信任度。你应该做的是让他们知道项目在你的控制之下按计划进行，给他们信心，让他们放心。