技术出身的项目经理，别再被技术思维误导

（一）被自己的技术者思维虐过的项目经理们 

　　不论在哪个国家，IT 公司中的项目经理，很大一部分都是技术出身。的确，工程师背景的项目经理，在开发人员选择，开发进度控制，客户需求把握等诸多方面，有得天独厚的优势，从程序员到 leader 再到项目经理也是常见职场发展方向之一。 

　　雷子个人认为，从普遍意义上讲，在日本，只要勤奋努力，向上走是很容易的事。但到了管理岗位，即使勤奋努力，有时候思维没有及时转变，也可能遭遇惨败。我就亲见过智商一流，经验丰富技术人员，初任项目经理时，分外努力却搞得焦头烂额，甚至在项目中途被换下，经过很久很久才熬到第二次被提拔…… 

　　职场上升之路，有时需要些时运，可能各有不同，但失败的原因，有时却很相似。那么，技术者在初任项目经理时，经常会遇到哪些问题，给自己挖哪些坑呢？ 

　　故事一 

　　有时候，谎话连篇的项目经理才是好经理 

　　A 君，认识他时，他是个年轻的 leader，技术很不错，还有开荒牛般的勤勉，性格也非常开朗坦诚，能力人品双佳，当 leader 时成绩斐然，自然的，他很快升到了项目经理，一时间意气风发。 

　　A 做 leader 时很受爱戴，成为了项目经理，依旧沿用了一贯的坦率作风，事无巨细，和大家分享所有和项目有关的事。甚至包括：客户方面的负责人突然换人啊，咱们的契约很危险啊这些情报，也全都毫无保留地告诉给组员们。那么，像A预期地一样，全组拧成一股绳，项目圆满顺利地进行下去了吗？ 

　　实际上，并没有。在充分了解项目的同时，组员们也知道了大量的关于这个项目的不利因素，倍感不安。私底下，咱领导心里也没底啊，项目要扑街啊，这样的议论越来越多，A明明比做技术时更加努力，但项目状况却每况越下，回天乏力。 

　　最后，连部长都觉得“怎么搞成这样，哎，A还是太年轻。”无奈在项目中期换下了A，让经验丰富的B顶上。 

　　B 是个待人和善，初次见面就会让人印象很好的人。上任后，B和整个项目组的人挨个私聊，发现了问题所在——很多人对本来不用他们操心的事感到不安。这种不安，有时甚至影响到了他们的本职工作。 

　　于是，B把大家召集到一起开会，“通过沟通，我了解了大家现在的想法，和对这个项目前景的担心。不过这些担心，很多都是针对潜在的风险的，还有一些问题，是我可以通过斡旋调节解决掉的，balabala……”总之，就是天空飘过几个字儿，那都不是事儿。 

　　这个会，开得效果很好，B自信满满，言之凿凿的一番话，很好的安抚了组员们的情绪，大家专心开发，项目进度竟慢慢地赶上了。 

　　那么B真的像他表现出来的一样有自信吗？ 

　　事情的真相是，他非常了解——这个破项目，问题一大把。和组员说的话，很多都是他信口胡诌的…… 

　　作为项目组的普通成员或者 leader，不管说什么都要有根有据，信口胡诌是绝对不行的。但这不适用于项目经理。有时候就算是睁着眼说瞎话，也得把组员往正确的方向上带。 

　　“不管怎么努力也来不及了”，一旦让组员有了这种想法，那项目就必定要完。互相扯皮，产生信任危机，生产性下降，品质恶化，是一连串的连锁反应。无论如何也要避免这种情况的发生。

  

　　教训一 

　　项目经理必须要让组员相信：“这些情况早就在我的预料和控制之内，大家放心。”只有这样，组员才能心无旁骛的做好自己的事情。给组员们吃定心丸——是项目管理的手段之一。　　 

　　这时有的同学可能会说，很多项目从一开始就明摆着是坑，瞎子都能看出来。但即使是这样，把真实情况全部如实传达给组员，也是一点好处都没有。就算项目真的无论如何也挽救不了，那也是项目经理一个人的责任。把真实情况隐瞒下来，让组员们安心工作，多少还有一点希望。就算扑街，也不会姿势太惨烈。反过来，把真实情况和盘托出，导致军心涣散，那就真的一点儿机会也没有了。 

　　故事二 

　　有时候，不会较真的项目经理才是好经理 

　　C 君做工程师的时候，非常优秀。思维敏捷，逻辑清晰，精通各种开发语言。最重要的是，发生问题时，他一定要刨根问底的追查，不仅要找到解决方法还要找到问题的根本原因，从流程上改进，防止再发。这样的思考方式和做法，很多工程师都有。 




　　当时的上司和同事们对C君都是绝对地信赖，即使有时他在刨根问底上花费了太多时间，导致进度延迟，上司也都是积极地同客户调整进度或者加人，从不给他脸色看。 

　　当得知C申请做项目管理，而不是走技术路线的时候，大家都挺吃惊的。不过他作为项目经理，负责的前两个小型案件都完成得满好。这时他的上司有些放心了，觉得聪明又努力的人，做什么都会做得不错吧。 

　　之后，他被指定去负责一个具有一定规模的项目。这个项目所开发的系统，有十几个子模块，每个模块有3～4 个成员负责。 

　　一天，C收到了客户发来的邮件“项目进度全体看起来很顺利，但是几个子模块开发进度为什么有些延迟？什么地方出了问题吗？” 

　　C 作为整个案件的项目经理，通常是掌握项目的大体情况，对于每个子模块开发的具体细节并没有过问。第一次被客户质问开发进度延迟的理由，C有点坐不住了，而且他也产生了同样的疑问。 

　　于是，C君询问了这个模块的每个开发人员，得到的回答是：该模块所使用的部分第三方产品，有兼容性问题，加上调用方法不对，不断试错导致了这部分的开发延迟。可是C还是有疑问：“产品兼容性和调用方法不对，真的会导致生产性这么大的降低吗？” 



　　于是C又开始了他对于问题刨根问底式的追查。把每个项目组成员负责的工作细细地捋了一遍，得出的结论是——恩，和他们说的一样。于是，他向客户如实地汇报了原因，客户也接受了他的解释。 

　　但是他这么一折腾，本就有点儿延迟的项目，又浪费掉了更多的工数，给组员和他自己又加重了负担。 

　　本来对客户作出最初的解释就完全够了，可是C并没有那么做。像做工程师时一样，在这个问题上刨根问底，但整个过程却只是他的自我满足。本来项目经理和成员之间是互相信任的，由于这件事，信赖关系也出现了裂痕。 

　　在分析问题原因这件事上，项目经理追求的目标应该是客户的满足感。如果弄错了这个目标，花费了大量的精力，那就得不偿失了。 

　　比如说客户问，为什么这个系统能够运行？这个时候只要从产品框架的程度上给客户作出解释就完全够了。如果真要从编程语言和计算机原理的开始讲给客户听，只会让客户一头雾水吧。 

　　确实，如果花费大量的时间精力，去把一个问题彻底弄清，非黑即白，对今后的工作是有帮助的。但这是工程师该做的事情，而不是项目经理。 

　　教训二 

　　项目经理应该把更多的精力放在客户和成员的组织协调方面。有时候，不得不对问题的正确性和精准性做出妥协。从工程师出身的经理，往往在这一点上很难转变。 

　　故事三 

　　有时候，不会和部下同甘共苦的项目经理才是好经理 

　　第三个故事，是我的故事。 

　　大多数工程师都是很单纯很热心的人。如果组里的其他成员遇到了什么问题卡住了，很多工程师会留下来加班帮他一起把问题解决掉。但这种做法并不适用于项目经理。 

　　我以前当工程师的时候，一次遇到客户要求调查一个问题，要的很急。我和项目经理两个人一直调查到很晚，都没有做完。眼看要赶不上终电了，项目经理一脸抱歉地对我说：“不好意思啊雷子君，今天就辛苦一下，加个通宵的班吧。” 

　　客户要求的，也没有办法，所以我就很爽快地答应了。本来以为项目经理也会留下来和我一起加班，没想到这个大哥说了一句“后面的就拜托了！”然后拎包就回家了，只剩下我坐在那里独自凌乱。 

　　虽然明知项目经理留下陪我加班没有意义，但当时不免心里是颇有微词的。直到后来我自己也当上了项目经理，才体会到他的做法完全正确。 

　　我作为一个个体的工程师，只要对项目经理一个人负责就可以了。但是项目经理需要对整个项目负责，对客户负责。如果他留下来陪我一起加班，第二天早晨一起回家的话，那么第二天的项目推进谁来管？如果客户对于调查结果有追加的疑问，让谁来对应？就算他第二天不回家，一直留下来完成自身的工作，那恐怕也是精疲力尽，效率会大打折扣吧。 

　　上面这张图是网上流传很久的，leader 和项目经理的区别。作为 leader，和成员们同甘共苦，是很有必要的，但项目经理绝对不可以。反过来，leader 和成员们只要低头努力工作就够了，但项目经理坐的位置，决定了只有他才能看到前方有没有深渊，后面有没有猛兽。这一点谁都代替不了。 

　　教训三 

　　技术者升级为项目经理，切不可再像做工程师的时候那样事事亲力亲为。懂得自己该做什么，懂得找擅长的人去做他擅长的事情，才是经营之道。 

　　故事四 

　　有时候，想着「等前提条件都确定了再开工」的项目经理不是好经理 

　　这个故事是个段子。 

某日，老师在课堂问一个学生： “树上有十只鸟，开枪打死一只，还剩几只？” 

学生反问“是无声手枪或别的无声的枪吗？” 

“不是。” 

“枪声有多大？” 

“80-100 分贝。” 

“那就是说会震的耳朵疼？” 

“是。” 

“在这个城市里打鸟犯不犯法？” 

“不犯。” 

“您确定那只鸟真的被打死啦？” 

“确定。”老师已经不耐烦了“拜托，你告诉我还剩几只就行了，OK？” 

“OK，树上的鸟里有没有聋子？” 

“没有。” 

“有没有关在笼子里的？” 

“没有。” 

“边上还有没有其他的树，树上还有没有其他鸟？” 

“没有。” 

“有没有残疾的或饿的飞不动的鸟？” 

“没有。” 

“算不算怀孕肚子里的小鸟？” 

“不算。” 

“打鸟的人眼有没有花？保证是十只？” 

“没有花，就十只。” 老师已经满脑门是汗，且下课铃响，但学生继续问, 

“有没有傻的不怕死的？” 

“都怕死。” 

“会不会一枪打死两只？” 

“不会。” 

“所有的鸟都可以自由活动吗？” 

“完全可以。” 

“如果没有其他前提条件，”学生满怀信心的说，“打死的鸟要是挂在树上没掉下来，那么就剩一只，如果掉下来，就一只不剩。” 

老师擦了擦汗说：“你一定是个程序员......” 

　　编程做久了，往往思维方式会发生固化。工程师都对事物的逻辑性和因果关系有着执拗的追求，“把前提条件全都告诉我”，是工程师的常用语。当然，从工程师的角度来看，前提条件不明确就开工，最后能做出什么样的东西来，只有上帝才知道。 

　　但是，这个世界上从来就没有过从最开始就明确了所有前提和需求的项目。这个时候，就需要对案件的情况做出各种假设，分析可能性，然后在保证最大正确性的前提下开工。如果在项目途中，前提条件或者需求发生了改变，那就再根据具体情况进行调整——这考验的是项目经理的能力。不这么做的话，项目永远也开始不了。 

　　在设计第一台月球车的时候，如果 NASA 宇航局的工程师说：“请把月球表面的详细情报告诉我，否则我没法设计”，这样的话人类可能永远只能在地球上晃悠。当时，月球表面的状态只能从望远镜里观测到的景象进行推测。虽然前提条件很不充分，但也只有基于最大可能性开始设计，别无他法。 

　　做项目也是一样。设计系统的时候，要假设各种各样的前提：系统使用年限，最大并发访问数，相关的法律会不会更改（特别是政府项目或者和金融相关的系统）...... 

　　教训四 

　　先从最确定，可能性最大的部分开始做起，当需求和前提渐渐明确，再逐步调整进度和人员安排。对于项目全局的把握和大局观，往往是工程师初任项目经理时，最为欠缺的部分。 

　　今天，和大家分享了几个小故事，愿大家在职场上升道路上避免这些有可能走的弯路，少付出一些成长的代价。 

（二）IT项目经理必备的八种能力

优秀的IT项目管理者决定着业务举措的最终成败，但真正的顶尖人才还需要具备独特的综合性技能储备——既包括硬技术水平、又拥有软技能素养。在今天的文章中，我们将一同了解招募项目管理专家时需要关注的八项核心技能。 

优秀的IT项目管理者决定着业务举措的最终成败，但真正的顶尖人才还需要具备独特的综合性技能储备——既包括硬技术水平、又拥有软技能素养。在今天的文章中，我们将一同了解招募项目管理专家时需要关注的八项核心技能。 

随着全球经济逐步走出衰退泥潭，企业对于项目管理专家的需求也呈现出一路飙升之势。为与关键性业务相关的IT项目找到理想的项目管理人才往往难度极高，因为正确的人选不仅需要具备过硬的技术水平、同时也需拥有良好的软技能储备。 
除了我们所熟知的各项要求——例如关注细节、把握流程、时间管理以及同时处理多项任务的能力——还有一部分不太明显但却同样重要的关键性技能，正是这些素养决定了一位管理者到底止步于优秀、还是真正堪称杰出。在这里，我们将一同探讨在招募IT项目经理时需要关注哪些重点。 

管理资源冲突的能力 
“无论企业规模有多大，也无论所在企业拥有怎样可观的整体储备，大家总会面临源自特定资源的分配冲突。我们始终受到成本、技术能力、时间周期以及可用人员数量的严重制约。项目经理需要有能力做出决定，从而以最科学的方式分配有限的资源，这对于最大程度积极推动业务项目而言意义非凡，”Innotas公司市场营销副总裁Tushar Patel指出，这是一家云项目组合管理解决方案供应商。 
熟悉各种不同类型的技术平台/方法 

对于IT项目经理来说，熟知与软件及应用程序开发、设计、构建以及交付相关的标准化方式是其必备技能之一，Patel表示。时至今日，大部分IT部门已经开始运用敏捷开发方法，因此对于这一重要框架的理解同样不可或缺。 
“在过去，敏捷机制往往只作用于软件开发团队内部，但目前我所接触到的企业中已经有超过一半开始将敏捷方法引入到数量越来越庞大的技术项目当中。因此，像迭代、冲刺、并行以及根据客户反馈将变更要求翻译成终端用户功能的能力已经成为IT项目经理的必要技能储备，”Patel解释称。当然，每一家企业实现敏捷性流程的方式有所区别，因此项目经理还必须了解该如何将这一理念灵活地应用在其所在组织当中。 

关注业务战略与敏捷性 
相较于单纯完成独立性任务的领导班子，能够专注于如何利用项目推动业务增长、创新以及规模化商业战略的项目管理团队往往会成为企业自身的一大竞争优势，Patel指出。“在IT部门之外广泛使用敏捷性概念能够创建出业务敏捷机制，这一点在项目管理工作当中至关重要，”他总结称。 
“大家当然希望自己的项目经理能够在了解客户及市场反馈的前提下，进一步掌握市场的实时变动或者内部战略的具体调整; 只有做到这一点，大家的企业才能在面临接受收购、收购其它厂商或者任用新的CEO等一系列重大变动的同时，继续保持理想的项目推进节奏。项目经理必须有能力证明自己在转变灵活性方面的出色表现。面对不断出现的具体变化，负责人必须能够适当处理业务优先级问题，”Patel表示。 

曾几何时，一位项目管理者只要能够在市场发生变化时及时做出反应就已经完全合格，但时至今日项目经理必须以积极主动的姿态预测任何可能出现的变化，并解读这一切可能给其项目甚至企业的整体业务带来哪些影响，他指出。“我们提出的主张主要在于以灵活方式实现预测与自适应预测; 规划编制、成本、时间限制并以六个月左右为周期考量哪些项目将成为未来成功的关键所在，”他解释道。“这项任务绝不轻松，毫无疑问，但优秀的项目经理必须有能力实现这一目标。” 

良好的沟通技能 
沟通能力是项目管理人才必须a具备的重要素质之一，Mondo公司中西部地区区域招聘经理Hallie Yarger指出，这是一家数字营销与高科技人才招募及咨询企业。项目经理必须能够接触拥有各类不同教育、从业背景以及个性的对象，并有能力以快速而简明的方式同员工、高管、客户以及全部其他利益相关者就项目当前状态进行交流。“沟通技能对于项目经理来说必不可少，但重要的是，这些技能会以多维方式综合呈现、并直接面向企业内部及外部的各类利益相关人员，”Yarger表示。 

管理技能 
除了良好沟通a的能力，管理技能也是项目负责人的必修课之一。项目经理必须有能力突破困苦的现状，并在不涉及立场的前提下根据业务实际需求作出艰难的决定。这些管理者需要在顺境中理解并同情抱有不同观点、个性、沟通方式或者需求的利益相关者——而在危急时刻，这样的能力将成为项目经理最为重要的能力体现。 
“大家几乎必须在一定程度上运用心理学技巧来有效地激励、推动并引导相关人员，确保项目能够在最低时限与最小冲突之下充分发挥每个人的具体优势，”Yarger指出。 

准确评估风险的能力 
“在每一个项目当中，风险都是切实存在且不可避免的，”Yarger表示。具体包括将资源分配给某一项目而非其它项目的风险、项目无法满足特定客户及利益相关者预期及审议标准的风险、项目无法在规定时间内完成的风险以及项目无法按时交付的风险等等。不过，一位出色的项目经理应该有能力通过对每荐资产进行价值优先级排序的方式评估并应对这些风险，同时确保采用正确的团队成员并监督其获得合适的工具、知识以及信息，借此将项目失败的可能性控制在最低限度。 

利用正确的语言进行交流 
在IT行业当中，信任是一位项目经理建立起良好客户关系的关键性因素。特别是对那些非常挑剔的软件开发者群体而言，Yarger指出，因此企业的一大重要任务在于找到正确的项目管理专家、保证他们能够以高信任度方式管理并激励开发人员。 
“大家必须寻找那些能够激发起软件开发人员工作热情、乐于与之配合并对其表现出尊重的项目管理者; 这类理想人选应该掌握软件开发人员的交流语言及所使用的平台、了解关于软件开发生命周期(简称SDLC)的方方面面并熟知每位开发者所面临的挑战及优势——当然，一定要确保人选能够说到做到，”Yarger解释称。 

具备全球管理经验或者垂直管理经验 
如今全球化与数字化生态系统的兴起意味着某些项目很可能需要由来自不同地理位置的团队负责。Yarger指出，具备离岸团队管理或者协作经验、或者曾经在其它国家打理过项目工作的项目经理已经成为人才市场上的紧俏资源。 

“我们的客户目前最需要的是拥有全球管理经验的项目经理。而在医疗保健与金融服务领域，对于项目经理在垂直领域中的管理经验——特别是EHR/EMR领域的经验——也相当看重，其主要表现在合规性保障方面，”Yarger如是说。