如果我对一个老程序员说：“有必要转项目经理啦”，很多人第一反应是“为什么一定要当项目经理？！”，反问很给力，基至会让人哑口无言。但反问成功的结果可能只是使自己麻醉，暂时忘却现实中面临的烦恼和压力，这无异于把头埋进沙子中的鸵鸟。只有理智的分析，才能作为自己行动的指南。
首先申明，不是每个程序员都需要当项目经理，也不是每个程序员都想当项目经理，更不是每个程序员都能当项目经理。因此，当不当项目经理，可以说是一个“需不需要、想不想、能不能”的问题。
想不想，是一个意愿的问题。这是前提，毕竟强扭的瓜不甜嘛。显然，富二代一般是不想当项目经理的，因为他们想直接当总裁。还有些人，只想钻研技术，不想钻研人，他们也是不会想当项目经理的。如果你没有意愿当项目经理，也就没有讨论的必要了。什么，你不知道想不想？呃，那就继续往下读吧，也许读着读着，你就想当了。
能不能，是能力的问题。这是不关键，因为只要有意愿，能力是可以培养的。程序员连复杂得让人琢磨不透的软件都能搞定，还有什么搞不定的？
2.鸭梨山大
当我从网上看到码农这个词时，觉得网民很有自嘲精神，后来我看到了码畜和码奴这个两个词，不禁从心底涌起了深深的悲哀，为这个行业，也为这个社会。
看看智慧的网民对IT人士级别的划分：
码畜：年入低于3万（刚毕业的，租房，傻乐）
我在上一篇博文中提到30岁现象，有些人认为车到山前必有路，这是杞人忧天。不错，程序员确实可以干到30多岁，甚至四五十岁，但他们面临的压力却可能是“不足与外人道也”。
我经常与30岁以上的程序员交流，他们流露出来的对现状的不满、无奈、无力、对安全感的缺乏，让我感同身受。
虽然谈压力并不是一件愉快的事情，但我仍然必须要说出来，因为我宁可清醒的痛着，也不要在麻醉中睡去。那就让我们拿着手术刀，对自己进行痛苦的解剖吧。
下面是一个简单的“危机评估表”，总共有30项。在“是否认同”后面打出分数，每一项如果认同为1分，不认同为0分。
（说明：此表并不精确，仅供参考）
如果你的总分大于20分，说明你承受的压力过大，可能面临职业方面的危机，应当寻求改变了。
如果总分在10-20分，说明你生活比较稳定，收入方面可能是中上等水平，但职业发展方面仍有风险。
3.另一片天地
所谓“穷则变、变则通”，如果你还是普通的老程序员，并且还在为自己的职业彷徨和苦闷，那就应该寻求变化之道了。
如果你愿意，转向项目管理乃是上上之策。
当然转项目管理只是程序员很多选择中的一个。显然不是每个程序员都需要当项目经理。一般每个公司都最少提供了技术和管理两条职业发展通道，如果你技术超牛，你完全可以从程序员做到系统分析师，一直做到技术总监。如果技术方面你信心不足，转项目管理就是一件自然而然的事情了。
技术和管理，这是两条绝然不同的路，虽然“条条大路通罗马”，但沿途的风景却是完全不一样。一旦你从事了项目管理，你将看到不同的另一片天地。
（1）在管理的天地里，你将不再有职业瓶颈。
程序员虽然也可以干一辈子，但工资水平是有天花板的，不要问我为什么，行业就是这样。项目经理则有无限上升的空间，不但工资更高，职位上也可以升至部门经理、副总经理甚至总经理职位。
（2）促进项目经理内在成长，心智更加成熟。
虽然不当项目经理也可以发展情商，但在项目中锻炼是自我成长、自我完善的捷径。
（3）项目管理知识可以用在生活中的各个方面。
生活中的许多事情，我们并没有称之为一个项目，但可以用项目管理的方法来对待。例如一次婚礼的组织，或一次自助旅游。你在项目管理中培养起来的情商，更是让你面对生活中的各种问题游刃有余，你的家庭也会更家和谐，就像范范的一首歌里唱的：“好像什么困境都知道该怎么办”。当到达这种境界时，你会有一种海阔天高，一览众山小的感觉。
二．项目管理倒底难不难
程序员问：“我现在想当项目经理，但心里没底，不知道项目管理到底难不难？”这个问题确实不好回答。俗话说，“会者不难、难者不会”，很多事情都是如此。
有些人觉得不难，他们好像天生就具有管理的才能，他们举止得体、八面玲珑，具有很强的个人魅力，可以把大事化成小事，把坏事变成好事。这样的人，想不成功都难。
大部分人还是会觉得难。在PMI的知识体系里，项目管理有九大领域，五大过程组，44个过程，有数不清的工具和方法。项目执行中方方面面出了问题，都是项目经理的责任，项目经理又不是超人，怎么应付得过来。项目管理确实有点难。
你若问我，我会说项目管理既难，又不难。对于愿意改变自己的人而言，它不难；对于性格偏执的人而言，项目管理确实太难了。
很多人无法意识到自己的偏执。上级只要提出一点批评，他们就要拼命的辩解和反驳。他们的保护壳太厚了。
项目经理最重要的素质，就是心智的成熟，一个心智成熟的人，不会是一个偏执的人。
毕竟，人无完人，项目经理必须从善如流，才能完成自己角色的转变。对于从程序员转过来的项目经理，做事的方法与以前应是翻天覆地的不同，必须迅速审时夺势，改变自己。否则，那你不还只是个有项目经理职位的程序员么？
因此可以说，项目管理难就难在项目经理要改变自己。这个改变，不只是知识体系的扩充，更可能是性格的改变，而一个人要改变性格是极其困难的。
程序员习惯于与机器打交道，通过严密的代码和逻辑来控制机器；而项目经理是跟人打交道，人是有感情的，绝对不是你给他输入1+1，他就给你输出2。项目经理必须时时用心去思考、体会，然后改进。几番回合下来，项目经理会惊喜的发现自己变了，有种脱胎换骨的感觉—-那是当然的，因为变得更成熟了。
只要你愿意改变自己，假以时日，你一定会成为一个优秀的项目经理。
三．程序员应克服的障碍
程序员与项目经理之间，往往有一条鸿沟。对技术钻研越深的程序员，这条鸿沟可能越大。这是由程序员的性格特征决定的。
程序员普遍有非常多的优点：例如聪明、逻辑思维强、学习能力强、创新能力强、直率等。但优点往往也是弱点之所在，例如：
（1）太讲逻辑：与人相处时容易忽视人际关系、感情等方面的因素。
（2）过于直率：说话直来直去，容易伤害他人感情。
（3）自傲：总觉得自己技术不错、比周围的人要强一点。好比一只鸡看到同类觉得自己最大，看到鹅觉得跟自己差不多，看到火鸡才觉得比自己大一点。
（4）固执：在自己的逻辑中不能自拔，无法听取别人的意见。
（5）沟通能力较弱：大部分程序员在口头表达、写作、汇报、交流等方面存在不足。
而这些缺点，也是心智不够成熟有表现，这是项目经理的大忌，往往会成为程序员晋升项目经理的障碍。因此，必须要克服这些障碍，给自己制定符合项目经理要求的行为准则，时时提醒自己，每日进行反省，坚持下去，必然会成功。
被任命为项目经理，是职业生涯的第一次飞跃，既惊喜又紧张。从现在开始，你要思考怎样才能胜任项目管理的工作，否则等着你的，很可能是一场悲剧。
一．升职之辨
1.为什么是我
不是每个人都能当项目经理，程序员中只有一小部分能成为项目经理，大部分人会随着岁月的流逝，成为了“资深程序员”。
那为什么领导要选择我呢？一般人对自己所拥有的东西都会很快习以为常，认为这是自己应得的。一点也没错，这就是你应得的，原因也很简单，那是因为你比别人优秀一点。
其实领导挑选人才的标准很简单，那就是你比别人优秀，而且只需一点点。你不需要“鹤立鸡群”，“鸭立鸡群”已经足够了。俗话说：“群众的眼睛是雪亮的”，其实领导眼睛才是真正雪亮的，如果他还没有发现你，那是因为你还不够优秀，没有引起他的注意。
因此，如果你工作多年仍然没有职位上升，不要埋怨公司不给你机会，而应该从自己身上找原因，机会只会给有准备的人。如果你不知道自己准备好了没有，就试着回答下面的问题吧：
●工作是不是比别人积极主动一点；
●加班是不是比别人多一点（如果贵公司喜欢员工加班的话）；
●提交成果是不是比别人提前一点；
●成果质量是不是比别人要好一点；
●学习是不是比别人勤奋一点；
●面对问题是不是比别人勇敢和执着一点；
●人际关系是不是更和谐一点。
如果你能做到这些，相信机会迟早会属于你的。
2.彼得定律的启发
这也就是彼得定律的内涵：“在一个等级制度中，每个员工趋向于上升到他所不能胜任的职位”。
从彼得定律中，我们可以得到以下启发：
（1）在公司里面，大部分人都干着他不能胜任的事情。这听起来真是一个悲剧，好在我们暂时还不用操心。
（2）金子是一定会发光的，人才绝对不会被埋没的。这是由于人才的稀缺性造成的，只要是胜任当前职位，晋升是迟早的事。因此，无论是程序员还是项目经理，都要做好你的本职工作，这才是最重要的。试想，如果本职工作都没做好，怎么可能提拔到更高职位呢？别告诉我还可以走后门。
（3）当上了项目经理，只是说明你可以胜任程序员职位，而不意味着你可以胜任项目经理。因此，别急着庆祝，还是多想想怎么来管项目的事情吧，否则你就可能是下一场悲剧的主角。
二、新任项目经理的误区
新任项目经理，由于经验和知识储备的不足，往往会出现相同类型的问题。
1.农夫的一天
有一个小故事，讲的是一个农夫的一天：
有一个农夫一早起来，告诉妻子说要去耕田，当他走到40号田地时，却发现耕耘机没有油了；原本打算立刻要去加油的，突然想到家里的三四只猪还没有喂，于是转回家去；经过仓库时，望见旁边有几只马铃薯，他想起马铃薯可能正在发芽，于是又走到马铃薯田去；路途中经过木材堆，又记起家中需要一些柴火；正当要去取柴的时候，看见了一只生病的鸡躺在地上……这样来来回回跑了几趟，这个农夫从早上到夕阳西下，油也没有加，猪也没有喂，田也没耕，最后什么事也没做好。
故事看上去很可笑，但笑过之后，回过头思索一下，故事里是不是也有我们项目的影子呢我们将《农夫的一天》换成《项目经理的一天》：
这样的一天无疑令人沮丧，但却经常出现在我们的现实中。当高级经理询问怎么还没有提交项目计划的时候，项目经理无可奈何又理直气壮的说：“我很忙啊！”
项目经理确实很忙，但这是没有效率的忙。其实何止是忙，还“茫”，而且“盲”，“忙、茫、盲”是许多新任项目经理的写照。
●忙：一天到晚都在忙过不停，是为忙碌；
●茫：碰到什么做什么，像个无头的苍蝇，没有计划性，或者无法坚持计划，是为茫然；
●盲：项目经理这一天初始目标究竟要做什么，做着做着就丢了，没有目标性，是为盲目；
2.思维转换
有时候我们会说一个项目经理，不像一个项目经理，那像什么呢？当然是像程序员罗。也就是说，他的职位虽然变化了，但并没有完成相应的角色转换，仍然像程序员那样工作。项目经理之所以会出现“忙、茫、盲”状态，归根到底也是因为他没有实现自己的角色转换。
角色转换本质上是思维转换。思维决定一个人的行为，项目经理不像项目经理，那是因为他的思维仍然是以前的技术思维，而不是管理者应当具备的管理思维。这就好比一个人在陌生的城市，拿着过时的地图，寻找自己的目标，结果只会是四处碰壁，无所适从。
表1技术思维vs管理思维
新任的项目经理，别忘了时刻提醒自己，像一个项目经理一样去当项目经理！
3.项目经理行为分析
第一次当项目经理，往往会由于经验不足、项目管理知识的不足以及角色转换等原因，表现出种种不胜任的迹象。
不胜任的项目经理，通常有以下几种类型：
（1）刺猬型
刺猬型的人非常敏感，随时都保持警惕，只要一感觉受到威胁，便会用豪猪般的刺扎向对手，让人避之不及。他们通常自我封闭，坚守自己的地盘，处处表现出来自己是对的，虽然其实他自己也并没有底气。他不会让别人看到自己的脆弱。
刺猬型项目经理不允许别人干涉自己的项目，哪怕是自己的上级。如果领导询问项目中的某个问题时，他会非常明确的告诉你，那不是我的问题，那是客户的问题，或者是公司制度引起的问题，或者是领导你干预项目造成的问题。总之，我一切都做得很好。
刺猬型项目经理的这种反应通常是不自信的反应。小猫在害怕时，总是拱起背，把全身的毛都竖起来，让自己看起来更强大，但老虎永远不会这样。
（2）绵羊型
绵羊型项目经理的性格非常温顺，他们语气平和，慢条斯理，不急不躁。对待下属非常友好，在他们心里，似乎没有好和不好、对和不对，这些对他们都不重要。项目每天都很平静，似乎永远不会有暴风雨的到来。当上级提出要求时，他们永远都是好的，至于做成怎么样，只要尽力了，那有什么关系呢？
绵羊型项目经理通常工作缺乏计划性，即使有计划，也只是应付上级而已。看到什么事情，就去做什么事情，除此之外，还有什么其它的办法吗？
（3）猴子型
想像一下孙悟空的行为就对猴子型项目经理有了大致的认识。他们技术能力强，很有激情，非常聪明，非常自信。但他们往往性格冲动，做起事来横冲直撞，不讲究方法。
猴子型项目经理悟性很强，进步会很快，他们最终会克服自己的不足，像孙悟空一样，取得正果。这一刻，他已经不是猴子了。
刺猬型和绵羊型项目经理，他们往往缺乏自信，其管理模式一般是被动式的，做事没有计划性，有什么事就做什么事，就像条件反射一样，只会对外界刺激做出反应。
猴子型项目经理则是主动式的管理，他们充满自信，但往往由于经验不足，过于盲目，对问题考虑不周。同时由于冲动的性格，在团队中并不受欢迎。
这三种类型都是不胜任的表现，那怎样才是胜任的类型呢？如果还是用一种动物来比喻，我觉得应该是“头狼”，也就是狼群的首领。
暂时的不胜任不要紧，关键是要有进步。如果一个项目下来，除了很疲惫，你没有感觉到自己有一些积极的变化，那你的危机也要来了。要知道，项目经理并不是“铁饭碗”，虽然公司倾向于选用有经验的项目经理，但当你明显不胜任时，领导不会再在你身上押上赌注，他们宁可重新冒险一次，因为他们不想“两次踏进同一条河流”。
4.心态
新任项目经理没有管理经验，不胜任是可以理解的。也许你认为公司应该给你更多的培训再上岗，但往往形势是箭在弦上，在没有更多资源的情况下，领导把这个成长的机会给了你。
可怜的是公司老板，他的项目成了你的试验田。实际上，公司提拔你做项目经理，就是花巨资送你去培训学校，不是吗？我一直认为，由一个不合格项目经理负责的项目，相比由优秀的项目经理来带，实施成本可能多出50%，甚至更多。不合格的项目经理就像一个给项目减肥的机器，使得肥肉变瘦肉，瘦肉变骨头，骨头变渣滓。
项目经理应该学会感恩。要成为优秀的项目经理，应该有好的心态，而感恩是一切好心态的基础。你只知道自己压力大，却不知道你让老板少赚了多少钱！是老板交学费帮你从一个初出茅庐的项目经理，培养成了一个合格乃至优秀的项目经理。
我见过不少新任项目经理，对公司满肚子怨气，好像是公司一手造成他的项目问题百出，仿佛领导和老板成了他的敌人，刚做完项目甚至还没有做完项目就果断匆匆辞职，带着公司用无形成本换来的宝贵经验，绝决的离去，换取更快的升职加薪。设想一下你是老板，不知会作何感想？
感恩是一个人最重要、最美好的品质之一。网上有一个经典感恩的段子：“…感谢鞭打你的人，因为他激发了你的斗志，感谢遗弃你的人，因为他教导你该独立，…凡事感激,学会感激，感激一切使你成长的人!”而你的领导和你的老板，他们既不是鞭打你的人，也不是遗弃你的人，而是培养你成长的恩人，我们有什么理由不感谢他们呢？
在希腊德尔斐的阿波罗神庙上，刻得着一句神秘的箴言：“认识你自己”。从某种程度上来说，我们都是自己的“最熟悉的陌生人”。认识自己的位置，是每个人获得成长的第一堂课。一个人的位置，对其言行的影响是至关重要的，俗话说：“屁股决定脑袋”，虽然听着粗俗，却饱含人生哲理。既然我们屁股在项目经理的位置上，就应该像项目经理一样去思考问题，做事情。
一．项目经理的处境
经过数年的打拼，怀着美好的向往，我们终于成了他——项目经理。然而，梦做到最真的时候，往往也是梦醒的时候。
项目经理其实也是悲情人物。从“程序猿”到项目经理，可以说是刚出虎穴，又入狼窝。要知道，做一个合格的项目经理，比成为一个优秀的程序员，还要难得多。
本来以为当上了项目经理，王子和公主从此就可以幸福的生活在一起了，没想到，跋涉的路才刚刚开始。我实在不想打碎这美好的梦想，这有些残忍，但清醒的痛着，总好过麻木的睡着。更何况人生本来就是一个接一个的杯具，每个角色都有他的难处，我们只能接受这个现实。人生就像登山，当你到达一个山头时，发现还有更高峰，一山还比一山高。
王子和公主，一直在路上。
1.高和低
没有成为项目经理之前，期望着当上了项目经理，可以拿着更高的工资，被别人尊敬的称呼为某某经理，还可以干着更少、更简单的活——指挥别人干活，这谁不会啊？
然而，人生不如意十之八九。更高的工资，应该是有的，但往往还不会达到让你眼前一亮的数字。被尊称为经理，也是应该的，ProjectManager，名正言顺的经理。然而，在大部分公司里，项目经理也就是像弼马温一样的小官，明白真相之后，又难免有一些失落。至于干更少、更简单的活，那就只能说是痴人说梦了。
事实上，在兴奋过后，等你翻到硬币的另一面，你会看到和你想像不一样的高和低：能力要求高、职位低。
（1）能力要求高
能力要求高不高，口说无凭，我在网上随便找了一个软件项目经理的招聘信息，要求如下：
上面的要求写得比较随意，我帮他整理一下，并点评一番：
表1项目经理职责要求
怎么样，要求很高吧？能完全达到这样的要求，我想去铁道部当个CIO应该是没什么问题了。即便如此，对于项目经而言，这些要求也没有哪一项是多余的，也就是说，项目经理必须成为一个超人，最好是像《蜘蛛侠》里面沙人那样，可以随心所欲的变化自己，穿越一切障碍，拥有无穷的威力。
（2）职位低
2.大和小
项目经理之所以需要很强的个人能力，归根到底是由项目经理的责任所决定的。项目是一种个人责任制的管理方式，项目经理是项目组的核心，责任无疑很大；与之相对应，其权力又是比较小的，这让项目经理的处境更加困难。
（1）责任大
项目经理作为项目组的最高领导，对项目的成败起着至关重要的作用。对项目的目标和实施过程中的一切问题，负有最终的责任。影响项目成败的因素也许有许多，但不管是什么原因，最终的责任会落实在项目经理身上，领导会说，项目经理不给力。
（2）权力小
项目经理的正式权力包括指挥权、人事权、财权、技术决策权以及采购权等，项目经理一般在某一限度内具有完全的权力，无需沟通汇报即可自行做出决定；在超出限度时，则需要与高级经理或职能经理商议决定。在一个矩阵型组织结构的公司中，项目经理的权力大致如下表所示：
表1矩阵型组织中项目经理权力情况
3.夹心饼
项目经理的位置是比较尴尬的。下面的兄弟要你多争取一些奖金；领导要你经费更省一些；客户要你更快一些；用户要你的产品更好用一些。在员工面前，你代表老板；在老板面前，你代表项目组员工；在客户面前，你代表公司。你代表了很多人，就是没有代表自己的时候。
项目经理就是一个不折不扣的夹心饼。做人难，做项目经理更难啊。
图1项目经理成了夹心饼
4.为什么还要做项目经理
也许你会问，既然项目经理这么难、这么惨，好像比“程序猿”还要苦逼，那我为什么还要做项目经理呢？这看上去不是个问题，“人往高处走，水往低处流”嘛，高处虽然艰险，向上追求的脚步却不能停止。无限风光在险峰，还是别埋怨攀登的辛苦，好好享受一路的风景吧。
当然，人的一生有不同过法，有些人喜欢在泳池中游水，有些人在热衷于在大海的激流中冲浪，还有些人，一辈子也不会游泳，他们只是偶尔到河边洗洗手，用冷漠或者好奇的目光看着那些乘风击浪的人们。每种活法的选择权在自己手上，一旦选择，无怨无悔。
二．项目经理素质模型
1.素质模型的作用
谈素质模型是一件很严肃的事情。因为素质模型就像一面镜子，项目经理拿来一照，可以发现自己的优势和弱点。只有扬长补短，才能在职业发展之路上步步高升。
管理方面的素质模型很多，但不是每一个都是客观的镜子，如果不能在镜中看到一个真实的自己，那它也就失去了应有的价值：
如果它是一面哈哈镜，那看到的将是一个变形的自己，无法作为自己的参照；
如果镜子太小，就只能照到自己的局部，会导致产生盲目的悲观或乐观；
如果镜子太大，可能会看到太多无关的东西，反倒干扰了自己的视线。
2.他山之石
（1）PMI知识体系模型
PMI将项目经理应具备的知识和技术分为五类，即：项目管理知识体系，应用领域知识、标准与规章制度，理解项目环境，通用管理知识与技能，人际关系技能，如下图所示：
图2PMI的项目经理知识技术体系
（2）麦克利兰的素质模型
美国心理学家麦克利兰经过研究提炼并形成了21项通用素质要项，并将21项素质要项划分为6个具体的素质族，同时依据每个素质族中对行为与绩效差异产生影响的显著程度划分为2～5项具体的素质。6个素质族及其包含的具体素质如下：
①管理族，包括团队合作、培养人才、监控能力、领导能力等；
②认知族，包括演绎思维、归纳思维、专业知识与技能等；
③自我概念族，包括自信等；
④影响力族，包括影响力、关系建立等；
⑤目标与行动族，包括成就导向、主动性、信息收集等；
⑥帮助与服务族，包括人际理解力、客户服务等。
（3）管理者胜任特征模型
胜任力是指任何直接与工作绩效有关的个体特质、特点或技能等，在本质上也就是应该具备的素质组合。有学者利用物元分析和可拓评价方法建立了基于管理技能、个人特质和人际关系3个维度的胜任特征物元模型。
①管理技能的维度，包括团队领导、决策能力、信息寻求和市场意识等；
②个人特质的维度，包括影响力、自信、成就欲、主动性、分析思维和概括性思维等；
③人际关系的维度，包括人际洞察力、发展他人、关系建立、社会责任感和团队协作等。
（4）四种能力论
Roberthogan和RodneyB.Warrenfeltz研究指出管理人员的素质可以分为4种，分别为：自我管理能力、人际关系能力、领导能力和商业能力。
①自我管理能力，包括自我尊重、正确对待权利的态度和自我控制等；
②人际关系能力，包括换位思考、正确预计他人的需要、考虑他人的行动等；
③领导能力，包括建立团队、维持团队、激励团队、建立共同愿景和巩固团队等；
④商业能力，包括制订计划、管理预算、绩效评估、成本管理和战略管理等。
3.几种素质模型的分析
上面这些模型，都是被广泛认可的模型，我本人对四种能力论，更是情况独钟。为了找出一个适合项目经理学习修炼的模型，我们有必要对这几种模型进行评价。
首先确定评价的指标：
（1）针对性：是否适合于项目管理领域；
（2）完整性：是否太过宽泛或狭窄；
（3）实用性：是否适合于项目经理修炼。
表2几种素质模型的评价
那我们能不能找到一种这三个指标都吻合的模型呢？
4.西西吹雪的六种能力模型
“六种能力模型”力图在针对性、完整性和实用性方面达到最佳。六种能力分别是：知识、技能、逻辑思维、执行力、心智成熟和领导力。这六种能力是一个有机的整体，如下图所示：
图3项目经理的六种能力模型
（1）人、事结合
管理，就是管人理事，这个理念已经深人心。这个模型首先就是一个管人理事的素质模型。
从“理事”的角度来讲看，项目经理应当具备四大素质：
●知识
必须具备项目管理的理论知识，所处的行业知识，以及专业知识；
●技能
光有知识是不够的，还要能知道怎么做。主要有项目管理技能、沟通表达技能、写作技能、专业技能等。
●逻辑思维
项目经理必须具有较强的逻辑能力、思维清晰，对项目任务和要做的工作，随时都有清晰的分类和列表。逻辑思维能力有很多种，如果要挑出两种对项目经理最重要，我觉得是归纳能力、判断力。
●执行力
项目经理本人必须具有很强的执行力。如果项目经理像个蔫老头，整个项目的执行结果可想而知。
从“管人”的解度来讲，项目经理应当具备两大素质：
●心智成熟
要管人，首先必须学会与人相处，心智不成熟的人，与人相处往往会无所适从。心智成熟，也就是要管好自己的内心。自己都管不好，怎么管别人呢？
●领导力
项目不是一个人的战斗，有些项目经理，只顾自己埋头干活，乐不滋滋，下面的同事却不知道每人要做什么，这是缺乏领导力的表现。余世维说：“管理就是让别人完成事情”，“真正厉害的人不是自己累死，而是要让手下做事情累死，这个才叫本事”，“优秀的管理者不会让员工觉得他在管人”。这三句话，可以说是领导力的三种境界。
简而言之，项目经理就像一个贤妻良母，要上得厅堂，下得厨房。上得厅堂意味着，项目经理要擅长与人打交道，也就是“管人”的要求。下得厨房则意味着项目经理懂技术、懂业务，能把复杂的事情理清楚，并解决各种问题，这就是“理事”的要求。理事主要靠智商，而管人则主要靠情商。
（2）内、外兼修
这个模型还是一个内外兼修的模型。古人云：“胜人者力，自胜者强”，说的其实就是一个人的外在修养与内在修养的关系。
战胜外在的事物，你需要是“力”，因此模型也有两个力：执行力和领导力。有这两种力，我们可以在管人、理事都做得很好。
要战胜自己，则非要靠一个人的内在修养不可。因此模型中，有四项个人内在素质的修炼：知识、技能、逻辑思维和心智。
从表面上看，“自胜”似乎比“胜人”更牛一些。但是从一个人成长的角度来看，我们主张要先“自胜”，再“胜人”。如果以树类比，“自胜”是根，“胜人”则旧枝干，一棵没有发达根系的树，是不可能长成参天大树的。所以不要让自己一开始就显得很牛，而是首先让自己成为一个真正的牛人，否则大树会过早夭折。
（3）从独立到互赖
一个人有成长过程可以分为三个阶段：依赖期、独立期和互赖期。每到一个新的阶段，都是一次巨大的飞跃。
●依赖期：围绕着“你”这个观念——你照顾我；你为我的成败得失负责；事情若有差错，我便怪罪于你。
●独立期：着眼于“我”的观念——我可以自立；我为自己负责；我可以自由选择。
●互赖期：从“我们”的观念出发——我们可以自主、合作、统合综效，共创伟大前程。
也许你已经注意到了，在素质模型里面没有依赖期，这是因为在依赖期的人是无论如何也成不了项目经理的。这个模型，是一个从独立期走向互赖期的素质模型。
在独立期，我们主要擅长做“理事”的工作。我们是技术英雄，可以把每件事都做得很完美；
在互赖期，我们的精力转向了“管人”。我们懂得如何与各种不同类型的人相处，如果驱动团队为一个共同的目标而努力。
（4）层次分明
这个模型是还是一个层次分明的、渐进的模型。从知识到执行力，实际上是一个从“知道”到“去做”的过程，而从心智成熟到领导力，是发挥团队力量的两个阶段。
图3六种能力的层次
一．从几个招聘要求说起
在上一篇中，我举出了一个招聘需求，引起一些朋友的争论。既然招聘的是项目经理，为什么需要那么多专业技能呢？
在百度上招聘频道搜索“软件项目经理招聘”，可以查到8500多条类似的招聘信息。我们看看国内软件行业老大东软集团的招聘条件：
显然，东软公司也是要求具有较强的专业技能的。当然，也许东软公司太大了，不具有代表性，那么我们再看一个比较小的公司，你绝对没听过(我也没听过)，广东广风隆电子科技有限公司：
8．熟悉unix/Linux操作系统。
9．具备软件团队管理经验，熟悉软件开发流程，能够独立完成项目实施的优先。
10．具备一定的系统框架设计、熟悉开发流程，具有的良好的需求分析、项目设计、规划能力。
13．有如下经验者优先考虑：
a.熟悉BIEE，或有BI项目开发实施经验
b.对BI/DW的概念和架构有比较深入的了解，熟悉维度模型架构
d.有基于java技术项目管理经验的优先，教育行业背景优先
哇啦啦，这个更不得了。这究竟是招程序员还是招项目经理，我也快被弄迷糊了。看来中小公司比大公司更看重专业技能。
二．外行vs内行
1.优势劣势分析
外行和内行究竟谁更适合当项目经理？那些招聘要求似乎已经为我们给出了答案，最少在软件行业内行项目经理更占据优势。然而，外行的项目经理往往也有其独特的优势，比如，他们往往更有大局观，能跳出技术本身看待问题，有更强的领导力等等。事实上，外行领导内行的现象，在国家大型建设工程或科研项目中要屡见不鲜。据说，我国的原子弹工程就是聂荣臻元帅领导的，而聂帅是不懂核物理的。
如果拿外行和内行项目经理来PK，并不是一件容易的事情，因为每一项都不是绝对的，这就如同比较男人和女人谁更适合做厨师一样。当我们拿两者PK的时候，其实包含了一些隐含的信息，就是这个外行的项目经理比内行项目经理，更加懂得管理、情商更高，否则的话，内行项目经理会毫无悬念的胜出，也就没有比较的必要了。
基于这些隐含的信息，我们试着比较一下两种项目经理的优秀和劣势：
2.技术决定论的误区
所谓内行与外行是纯粹从技术的角度来看问题，单纯讨论内行好还是外行好，其实也暗含着一个前提，就是技术决定项目的成败。而实际上，一个项目能否成功的影响因素，远不止是技术，对一个项目经理的素质要求也远不止技术。同是外行或内行来带一个项目，会由于个人修养与经验在差异，项目结果可能相差很远。因此单纯说外行好，还是内行好，是没有意义的。
3.综合素质决定论
问题的关键其实不在项目经理是内行还是外行，而在于他的综合素质。无论是外行还是内行，只要谁的综合素质更高，谁就是更优秀的项目经理。
上一篇我们讲到项目经理的六种能力模型，也就是说，一个优秀的项目经理，应当具备六个方面的素质，即：知识、技能、逻辑思维、执行力、心智成熟和领导力。
在知识层面，包括专业知识、行业知识和管理知识。外行项目经理在专业知识和行业知识方面已经输了，但在管理知识方面按默认值，外行赢了。
在技能导面，包括专业技能和管理技能。外行项目经理在专业技能也又输了，同样管理技能方面，又略胜一筹。
现在打成了平手。剩下的，要拼逻辑思维、拼执行力、拼心智、拼领导力，这就和内行外行无关了，鹿死谁手，要看个人的修养。
因此，项目经理的比拼，拼的不只是管理知识或专业知识这一个方面，而是综合素质的比拼。
三．外行，你凭什么
1.唐僧的团队
外行，也就是不懂专业知识技术，显然不但不是什么优点，反而是一个项目经理的极大缺陷。那为什么领导还会置这么大的缺陷于不顾，任命一个外行为项目经理呢？换一个角度，也就是说，一个外行，在什么情况下，可以成功的管理一个软件项目呢？
一件事情的发生，总有他的内部原因和外部原因。具体到这个问题上，也有它的内因和外因。
（1）在内部因素上，外行项目经理必须具有更高的综合素质。
现在流行分析西游记中的取经团队，其实也是一个典型的外行领导内行的团队。到西天取经，靠的是降妖服魔的本领，显然唐僧是个外行。但是，唐僧并不是一无是处，相反，他的综合素质很高。他外柔内刚，意志坚定，目标明确，还精研佛法，具有很强的人格魅力，因此他的那些徒弟才能凝聚在他周围，虽历尽千难万险而无悔。
（2）在外部因素上，必须有合理的人才结构作为支撑。
唐僧虽然不会打怪，但是孙悟空可以，补齐了唐僧在这方面的不足。试想，如果他的徒弟都不能降妖，任凭唐僧的领导力再强，也注定最终只会被妖怪吃掉。同样一个外行的项目经理，在他的团队中，必须可以信赖的技术骨干，像孙悟空一样能在关键时候解决问题，这些骨干一般就是项目中的组长、系统架构师或者系统分析师，必要时可能要设置项目副经理之职。如果团队中没有技术骨干，都是一些经验不足还不求进取的程序员，那除非项目超级简单，否则项目经理纵然有诸葛亮的才华，也无济于事。
2.规模决定一切
在上面两项条件都具备的情况下，只能说明外行可以担任项目经理了。站在项目本身的角度，除了这两项因素，往往还跟以下方面有着紧密的关系。
（1）项目规模：规模越大，采用外行项目经理的机率越高。
（2）项目所在行业：在建筑、施工、水利等传统行业，采用外行项目经理的机率更高。
（3）项目的技术难度：在项目规模不大时，如果技术难度越大，采用内行项目经理风险更小。
（5）项目管理的层次：有些项目层层分包，对于上面次层的公司，项目不需自己实施，只需对项目进行监管，项目经理自然也不需要很强地专业技术了。但对于底层实施单位而言，项目经理懂技术就很有必要了。同样，有些大型项目分成若干个工程，每个工程又包括若干个子项目，也是类似的情况。
在这些因素中，项目规模是具有决定性的因素。项目规模足够大的时候，也就有足够的经费来配备充分的人才。至于其实方面，其实只是表现而已。
三．透过瓶子看软件行业
为什么软件行业外业项目经理相对较少呢？这与软件项目本身的特殊性有一定关系，但在一定程度上也折射出软件行业的现状：
（1）软件项目规模不够大
在软件行业，几十万的项目很常见，几百万上千万就是大项目了，项目的利润率很低，很多中小型企业都生存在赢利的边缘。据工信部统计，2011年上半年我国软件行业利润仅占软件业务收入的1.28%。这么低的利润率，估计比东莞的制鞋厂还不如吧。而几百万上千万的金额，对建设、国防这些行业来说，简直不值一提啊。前几天太极集团1.99亿中标铁道部IT项目，大家都不服气。也是，人人都在喝汤，你凭什么搞特权吃肉？
（2）成熟的项目经理相对紧缺
软件行业小项目太多，对项目经理的需求量是非常大的，与此同时，成熟的项目经理相对很少。所谓“千军易得，一将难求”啊。当然，即使牛B的项目经理有了，其收入要求也不会低，这是小型项目难以承受的，只能退而求其次，找一个性价比更高的项目经理，或者干脆拔苗助长，找一个不错的程序员来带吧。
学习是一种基础性的能力。然而，“吾生也有涯，而知也无涯。”，如果学习不注意方法，则会“以有涯随无涯，殆矣”。
一．学习也是一种能力
看到这个标题，有人会说：“学习，谁不会？”的确，学习就像吃饭睡觉一样，是人的一种本能，人人都有学习的能力。我们在刚出生的时候，什么也不知道，是一张真正的白纸，我们靠学习的本能，学会了走路、说话、穿衣服…后来，我们上学了，老师把书本上的知识一点一点灌输到我们的脑子里，我们掌握的知识越来越多，与此同时，我们学习能力却好像越来越差了，习惯了被别人喂饱，似乎忘记了怎么来喂自己了。
学习本来只是一种本能，算不上什么能力，然而，经过二十多年的不断学习，学习反而成为了一种真正的能力，因为我们慢慢失去了它，它就更显得珍贵。
在学校里我们基本上被动式学习，然而走出了象牙塔之后，不会再有人对你负责，不会有人主动教你，我们需要主动的学习。所谓的学习能力，其实就是自主学习的能力。
几年前，曾有一本风靡管理界的书，叫《第五项修炼》，这本书倡导建立学习型组织，因为从长远来看，一个组织唯一可持续的竞争优秀，就是比竞争对手更快更好的学习能力。
一个公司如此，一个人又何尝不是如此？众所周知现在是一个知识爆炸的时候代，知识更新非常快。据说，一个大学毕业生所学习到的知识，在毕业之后的2年内，有效的不过剩下5%，更何况我们的学校与社会需要严重脱轨。我们赖以立足的，不在于我们现在掌握了多少知识，而是我们有多强的学习能力！
学习不但是一种能力，而且是一种至关重要的能力，而这种能力的核心，就是学习的方法和心态。
二．买书是最划算的投资
古人云：“书中自有黄金屋，书中自的颜如玉。”这说明先贤们早就认识到，买书是最划算的投资了。
当我刚出道的时候，拿着非常微薄的工资，有一次我向主管抱怨道：“现在的书真贵啊，这点工资连饭都吃不起，更别说买书了！”主管对我说：“不要吝惜买书的钱，宁可忍着不吃饭，也不要忍着不买书，因为买书是回报率的最高的投资了。”
主管的话让我非常震动。后来，我看到喜欢的书时，再有没有手软过。我不断的学习，开发能力也不断的提高，工资水平也获得了大幅度的提高。一年后，我一个月工资的涨幅，就足够买两年的书了。你说，还有比这更划算的投资吗
一本书，哪怕只有一页纸是有用的，它将所产生的潜在价值，也会远远超过书本身的价格。当然，书不在多，能踏踏实实消化掉一本好书，可能比泛泛而读10本普通书，要更有价值得多。
三．多读经典书
十年前，我刚进入IT行业的时候，真是求知渴，每星期都要往购书中心跑，可惜的是，那时给程序员看的书不像现在这么多，高质量的书就更少了。当时我印象中比较经典的书籍就是《Windows程序设计》、《COM本质论》、《Java编程思想》，还有就是谭浩强的《C语言程序设计》。其它充斥书架的，就是类似于《21天精通XXX》、《XXX从入门到精通》、《XX宝典》这样的书籍。
回首往昔，令我比较郁闷的一件事就是在我最有学习动力的时候，看的高质量的书籍太少，就好像是在长身体的时候，天天吃的是没营养的泡面。当然，这跟没有人指导也有很大的关系，独自一个人学习，让我走了很多的弯路。
软件开发方面的书籍，我大致将其分为三类：
（1）浅显的入门类书籍。
这类书的标题往往是《XX天精通XXX》、《XXX从入门到精通》、《XX开发实战》等，这类书往往从软件的安装讲起，喜欢翻译帮助文件。有人批评这类书为烂书、毫无价值，这并不公平。至少我本人，也曾从这些书中学到一些东西。即使是21天系列书，也有适合看的人群，只不过，它一般也就只能看21天而已，过后就可以扔到垃圾堆。这类书只适于还没有入门的初学者，从中学到一些入门的招式。这种书在刚起步的时候一般买上一本就可以了。如果你善于使用搜索引擎，这一本书也可以省了。
（2）国内外高手写的实战类书籍。
（3）国外大牛写的、揭露本质、有丰富思想的书。
然而，阅读这类书并不是一件容易的事情，读者需要有丰富的开发经验，才能与作者产生共鸣。真正能消化经典书的人其实不多，这就好像饮酒，一个新手无论如何也品不出葡萄美酒的醇香。在酒桌上，人人都把杯中酒一饮而尽，当有人点评“这个酒不错”的时候，我只能无奈的苦笑一番，真的是甘苦自知。
当然，你可能会说，“我工作已经做完了，经理没有安排，当然可以学习了”，其实不然。你完成了一件事情，不等于所有的事情都完成了。一个优秀的员工，应该是主动要工作，而不是被动的等工作。工作完成以后，你至少还可以：
（1）主动汇报给你的经理，请他来检查你的成果，并安排新的任务；
（3）你还可以主动请缨，承担额外的工作或更艰巨的任务。
（4）如果一定要学习，也只能对着电脑屏幕来学习，纸质书最多只能拿来翻阅一下，而不能一直捧着，以免影响到其他人的情绪。
我曾发现不少程序员在学习方面找不到方向，一会学学C#，一会学学Java，看了最新的编程语言排行榜，又觉得该学C++。这样左抓抓，右挠挠，只会让你觉得更痒。
学习最忌三心二意。俗话说：“伤其十指不如断其一指”，每门都学一点，还不如专心学好一个方向。这个道理谁都懂，可是又该学哪个方向呢？难道只能跟着感觉走吗？
学习与工作需要的的东西，有很多好处：
首先，可以集中精力，在某一方面钻研得更加深入。所谓“百招会不如一招绝”，有了绝招，你还怕不能在“武林”立足吗？《天龙八部》中的慕容复武功博学无比，最后还不是被只会一招六脉神剑的段誉打得落花流水？
其次，可以学得更快、更深入，因为学习更具有针对性，而且可以立即在工作中运用，可以马上检验出学习的效果，对存在的问题可以进行深入的研究，因此掌握的知识也会更加的牢固。
六．织网式的学习
知识的广度和深度都很重要。作为一个程序员，深入把握技术细节，是写出优质代码的保证。但对于一个项目经理而言，知识的广度更显重要。项目中碰到的问题往往是综合性的，只有具有广博的知识，才能快速的对问题进行分析和定位。在程序员通往项目经理的道路上，我们必须有意识的扩大自己的知识面，形成更完善的知识体系。
每个人的知识体系就好比是一张网，我们学习其实就是要织这样一张网。我曾看过渔网的编织过程，渔网虽大，也是一个结点起步，一个点一个点的编出来的，编织的过程中，始终只有一根主线。
学习又何尝不是这样，知识体系的大网也是由许多小的结点组成，要结这样一张网，只能由一个点起步。牵住一条主线，织出一个个的点，由点带出面，最后才能形成这张大网。
我曾经编写过一个网络信息采集软件，这个软件可以从具有列表页网站中按字段设置采集信息，支持自定义字段、页面多级关联、下载附件、支持多种数据库、可视化定义等特性。刚开始时，觉得这个软件也是一个比较大的功能点而已，后来发现这个不起眼的功能关联着大量的知识点，在开发过程中，我顺藤摸瓜，各个击破，对很多知识点进行了细致的学习研究，软件开发完成后，个人的知识体系网也进一步得到了补充和完善。
图1由知识点形成知识网
七．问题是最好的学习机会
日本经营之神松下幸之助曾经说过：“工作就是不断发现问题、分析问题、最终解决问题的一个过程，晋升之门将永远为那些随时解决问题的人敞开着。”可见，工作过程中有问题是正常，没有问题那才是真正的问题。在发生问题能时，能勇于面对问题、解决问题的人，才是公司真正的核心骨干。
现实中，很多人总是千方百计回避问题，当上司安排一项艰巨的任务时，也是想尽办法推托。殊不知，对于个人而言，其实问题是最好的学习机会。往往那些愿意接受困难工作的人，能力会变得越来越强，那就是因为他们在克服困难的过程中取得了巨大的进步。
碰到困难时，迎难而上吧，千万不要拒绝这个最好的学习机会！
八．经常思考总结
子曰：“学而不思则罔”。只学习不思考，就会迷惑，难以把握事情的本质。这就好比一个学武之人，只习得其形，而未得其神，难以成为真正的高手。
一个程序员从入门，到成为高手的过程中，往往要经过几次顿悟。顿悟会让你跳出知识的丛林，一切豁然开朗，仿佛打通了全身的奇经八脉一般奇妙。记得我有一次，顿悟到了一个很简单的结论：“原来高级编程语言中的类库是封装了WindowsAPI来实现的。”后来碰到一些自带类库无法实现的功能时，我就会想到，其实可以通过调用WindowsAPI来实现。利用这个思路，我解决了一些看起来很难的问题，得到老板的赏识，从而很快获得提升。
顿悟非常可贵，然而它不是随便发生的，而是经过一次次苦苦思索之后、灵光闪现的结果。思考的过程，其实就是将外在的知识内化为自己的知识的过程，而顿悟，则是批量的实现这种内化，将无数个知识点连接在一起，达到融会贯通的境界。
九、克服“高原现象”
这种情况实际上这是由人的学习规律决定的一种“高原现象”。据研究，学习者在刚开始进步快，随后有一个明显的或长或短的进步停顿期，后期进步慢，中间的停顿期叫高原期。
图2技能学习练习曲线
十、学习要有好心态
（1）学习要静心
急于求成是学习过程中普遍存在的一种心态。这可以理解，毕竟作为一个程序员，要学的东西实在太多了，而社会又是那样的浮躁，让人觉得一切都是那样的不安全、不确定，似乎只有学得快一点，才能跟上社会的脚步。
可是“欲速则不达”，想快快的学，往往会形成东一榔头、西一棒槌的学习方式，每一个点都没有吃透。心沉不下去，知识也会沉不下去。要想成为真正的高手，只能静下心来，一步一个脚印的攀登。
（2）学习是一个持续一生的过程
人生的过程，就是一个自我完善过程。
作为一个程序员，更是需要不断更新自己的知识。我们所知道的东西，就像一个白色的圆圈，圈外则是黑暗的未知的世界。当圆圈越大，所接触到的黑暗部分就越多。我们只有不停的学习，打破更多的黑暗，找到更多光明。
（3）保持饥饿，保持愚蠢
看了《乔布斯传》之后，我最喜欢的一句话是“求知若饥，虚心若愚”（StayHungry,StayFoolish），其实我更喜欢它更原生态的翻译“保持饥饿，保持愚蠢”。我们只有认识到自己还很饥饿和愚蠢，才会像没吃饱一样，由衷的需要学习、爱上学习。
当然，知易行难，知行合一才是学习的最高境界。我也始终是一个学习者，一直在路上。
说起程序员三个字，我觉得既骄傲又可悲。骄傲的是，我们曾经是时代骄子，是一群真正改变世界的人；可悲的是，我们很多致力于改变世界的程序员，却生活在自己的世界里，无法自拔，成为了继“书呆子”之后的“电脑呆子”。电脑本来只是一个工具，我们竟然被其所限制、甚至同化，悲夫！
一、警惕成为“电脑呆子”
（1）程序员眼中的自己
程序员是怎样看待自己的呢？看看园子里的发言，码农、码畜、IT民工、苦逼、程序猿…这样的字眼俯拾皆是。
在网上曾经广泛流传一首关于程序员的诗，模仿的是唐伯虎的《桃花庵歌》，我们暂且称之为《程序员之歌》吧：
写字楼里写字间，写字间里程序员；程序人员写程序，又拿程序换酒钱。
酒醒只在网上坐，酒醉还来网下眠；酒醉酒醒日复日，网上网下年复年。
但愿老死电脑间，不愿鞠躬老板前；奔驰宝马贵者趣，公交自行程序员。
别人笑我忒疯癫，我笑自己命太贱；不见满街漂亮妹，哪个归得程序员。
（2）别人眼中的程序员
在别人眼中程序员又是怎样的一个群体呢？在360网站有一个关于程序员形象的热帖，其中回帖的大部分都不是程序员，很多回复都非常生动，没有骂街，可以说比较客观。
总结一下，大家回复的情况大致如下：
工作方面
外在形象
黑眼袋，红眼圈，睡眠不足，瘦小，邋遢，带眼镜。
生活方面
电脑前潇洒自如，世人前胆小腼腆。聪明，思维敏捷，生活刻板。
性格方面
“闷骚”这个词不好听，但还是蛮准确的：程序员大多沉默寡言，不善与人交往，但内心却很丰富。性格腼腆甚至孤僻，圈子小，爱憎分明，有点不食人间烟火的样子。
思维方式
是一种面向问题的思维方式，逻辑灵敏而严谨，无时无刻不在思考攻克解决问题，善于找别人的问题，却对自己的问题视而不见，不善于解决生活中的问题。
综合起来，程序员在世人眼中大抵是一个聪明而又迂腐、善良而又刻板的形象，是不是有点像鲁迅笔下的“孔乙己”先生呢？
（3）“电脑呆子”是怎样炼成的
悲夫！程序员曾是时代骄子，有非常细腻内心、非常丰富的感情世界、非常聪明的大脑，在世人眼里的形象却是如此不堪！
孔子说：“君子御物而不御于物”。电脑只是被我们利用工具而已，而我们的思维却被电脑所限制，甚至变得和电脑一样。
程序员，是该求变的时候了！
我们再也不要闷骚，将我们的内心美好善良的一面勇敢的表达出来吧！
我们再也不要苦逼，我们要金钱，更要快乐，我们要工作，更要生活！
我们再也不要死板，我们可以做出漂亮的程序，同样也可以漂漂亮亮的做人！
（4）一个老程序员的肺腑之言
也有大家会觉得“电脑呆子”这样的词是在骂程序员，是对程序员的不敬，但也许激烈的言辞更能令人警醒。有一个成语叫当头棒喝，据说佛教禅宗和尚接待初学的人常常用棒一击或大喝一声，促他醒悟。
二、懂电脑更要成为人脑
（1）电脑逻辑vs人脑逻辑
程序员写代码离不开电脑，沟通、交际又要与人脑打交道，然而电脑与人脑的逻辑在很多方面却是大相径庭。
电脑的逻辑简单，所以我们愿意与电脑打交道。如果我们把电脑的逻辑带到与人交往的过程中，那就太“简单化”了，当然也就给人以迂腐、刻板、不懂变通的印象。我们毕竟是生活在人的世界中，我们要懂电脑，更要懂人脑。我们不是只懂电脑异类，而只是更懂电脑的正常人。
（2）做回正常人
我曾经很看不起那些不懂技术却八面玲珑的人，看到他们身居高位更是感到愤愤不平，甚至感叹要是生活在西方国家就好了，什么事情都直截了当，不用拐弯抹角。
其实并不是这样做很难，而是我们不愿意这样做而已，不愿意为世俗的观念改变自己。没错，现实是世俗的，但现实也是无法改变的，我们只能承认现实，臣服于现实。我在360的那个帖子中看到有一个对程序员的绝妙评价，“程序员是七仙女中的织女”，难道我们真正的要像仙女一样不食人间烟火吗？
我们不用做仙女，只需要做一个普通的正常人。要顺应人的逻辑，懂人情，明事理，做一个正常人该做的事情，这样并不难。
莫言在领诺贝尔奖时有一段精彩的发言：
最后，我讲一个小故事。听说法兰克福是歌德的出生地。在中国，流传着一个非常有名的关于歌德的故事。有一次，歌德和贝多芬在路上并肩行走。突然，对面来了国王的仪仗。贝多芬昂首挺胸，从国王的仪仗队面前挺身而过。歌德退到路边，摘下帽子，在仪仗队面前恭敬肃立。我想，这个故事向我们传达的就是对贝多芬的尊敬和对歌德的蔑视。在年轻的时候，我也认为贝多芬了不起，歌德太不象话了。但随着年龄的增长，我慢慢意识到，在某种意义上，像贝多芬那样做也许并不困难。但像歌德那样，退到路边，摘下帽子，尊重世俗，对着国王的仪仗恭恭敬敬地行礼反而需要巨大的勇气。
处处与世俗为敌，并不会让世俗变得清高。尊重世俗，也并不意味着失去清高，失去自我。
不要比拼清高，而要自己生活得幸福。当你能自由的游走于世俗的现实与内心卓尔不群的原则之间时，你也就实现在个人修炼的圆满，成为了一个从内心里幸福的人。
我们不需要成为清高之人，也不需要成为世俗之人，我们只要成为普通的正常人，一个外圆内方的人。
追求完美是一种可贵的精神，完美主义也历来被认为是一种优秀的品格。可是在项目中，完美主义也是一种错，虽然是一种“美丽的错误”。项目讲求平衡，要的是合格，而不是优秀；要的是70分，而不是100分！
1.两极分化的程序员
相信在很多人眼里，程序员都是工作一丝不苟、对代码精雕细琢、精益求精的人。瞧，他们在电脑前面一坐就是大半天，如果不是追求完美之人，谁能这样坐得住板凳？
可是依我所见，在“追求完美”这个问题上，程序员其实是严重的两极分化。有一部分程序员确实对自己的代码要求很高，他们在编程时，非常注意逻辑是否严谨、运行效率高不高、代码是不是优雅，经常进行代码重构与优化。他们就像有洁癖农村老太，整天扫把不离手，在哪里看到不顺眼的代码，就要改到哪里，如果让他来维护一个系统，多半最后会让他把整个系统的代码全部重构或者重写了一遍。他们是真正的完美主义者。
后一类程序员，在数量上似乎占据绝对的优势，对于一个不擅于控制项目质量的项目经理来说，他们的代码最终会成为项目的噩梦。系统一旦投入运行，虫子就会像美国恐怖片中的外星生物一样，源源不断的从鼻孔、嘴巴和耳朵缝里冒出来。
第二种程序员这种低标准低要求、随随便便的做法，很容易被识别出来是一种不好的倾向，而完美主义不是这样，因为我们从小就被教导要追求完美，完美主义一般被认为是一种优秀的品格，是每个人应追求的目标。
然而完美主义虽然听上去不错，却并不适合于项目，因为项目的目标是用最少的成本来完成项目，让各方满意，而不是制造一个完美无瑕的产品，以证明个人或公司的能力。显然，完美主义更适合于个人能力的修炼，或者一项没有限期出成果的科学研究，在项目中，完美主义也是一种错，虽然是一种“美丽的错误”。
完美主义者和随随便便的人，这两种程序员都不是项目的最佳人选，他们是恰好是两个相反的极端，如果让他们负责项目，估计就像玩跷跷板一样，要么压到地底下，要么翘到天空上。但是项目经不起这样的折腾，项目中需要有平衡能力的人，他们很好的把握追求完美的“度”，使得软件功能既能满足客户的应用需求，又不至于要花费过多的精力。可惜的是，这种程序员实在是不多，因为度的把握对程序员而言，确实不是一件容易的事情。
2.完美不等于质量100分
其实现代质量管理理论普遍认为，质量并不是越高越好。事实上，市场已经对此无数次给出了证明。很多人骂过微软公司的产品烂，据说乔布斯也曾经大骂windows是坨屎，但微软公司后来却成了软件行业的霸主。
ISO9000对质量的权威定义是：一组固有特性满足要求的程度。看到了吧，是满足，而不是超出，这非常重要。不要少，少了通不过；但也不用多，多了便是浪费。我们需要的不是100分的质量，甚至也不是一流的质量，而只是满足要求的质量。
在项目管理中有一个名词叫“镀金”，也就是在产品达到客户要求后，再多做一些额外的工作，让产品更加完美，以进一步提升客户满意度，这在PMBok中是一种被明确禁止的行为。软件质量100分，在项目中不但是一种巨大的浪费，而且几乎是一个不可达到的目标，只会让项目不堪重负，最后陷入灾难的境地。
3.合格就是完美
追求完美本身并没有错，但如果上升到完美主义，时时处处要做到最好，却不一定符合当时当地的条件限制。一个“最”字会害死人，因为“没有最好，只有更好”，如果一味追求更好，其结果可能就如陷入焦油坑的怪兽一般，无法自拔。在这样一个讲求效率的时代，完美主义更是可能会造成机会的丧失。因此，要保持追求完美的心，但又要懂得权衡，不要陷入极端的完美主义的陷阱。
要完美不要完美主义，本质上是一个度的问题，项目应讲求平衡，避免极端。学过项目管理理论的人都知道，项目管理中有一个“铁三角”，也就是在一定的项目范围的约束下，成本、进度和质量构成三角形的三个端点，为了让三角形面积保持不变，任何一个端点的变动，都会引起其他一个或两个端点的同步变动。这个铁三角本质上就是一种平衡和制约的关系，而完美主义，则只单纯的强调质量，而忽略了其它方面的因素，这显然是一种极端的行为。
那项目中质量的“度”倒底是什么呢？其实就“合格”二字。合格意味着被认可，却不需要达到优秀的代价。客户认可、领导高兴、员工轻松，这不就是完美吗？可以说项目中没有最好，只有合格，合格就是完美。
4.“70分主义”
从小老师和书本就教育我们要追求完美，考试要考100分，90分都嫌太低，那70分还拿得出手吗？
其实70分不低了，要知道现在大学生的口号是“60分万岁，多一分浪费，少一分作废”。当然这种口号容易被批评为不思进取，但万物存在就有其合理的一面，“60分万岁”也是事出有因。
项目如果以70分为目标，适当留出缓冲，就可以做到游刃有余，更容易把控。70分意味着已经达到客户的验收要求，已经能投入正常使用，但可能存在一些影响较小的Bug，个别页面效率有待提升，个别操作不是很顺手，系统扩展性一般，代码组织有等进一步优化……这些不完美的地方，就让他们在那里待着吧，毕竟客户已经觉得已经达到目标，何苦自己跟自己较劲，非要达到100分呢？早验收、早收钱，这才是王道！吃饭只用7分饱，项目也是只要70分，“70分万岁”！
直率听上去是一种美好的品德，然而如果不注意区分实际情况，直率可能会成为一把伤人害己的“双刃剑”！
1.直率是关于说话的问题
公司曾有一位人力资源经理是从传统行业转过来的，有一次她跟我说：“程序员真有意思，他们全都是一根肠子通到底，大脑不会转弯！”
还真是这样的，估计没有哪个行业的人员像程序员这样，具有同样的鲜明的性格特征：直率。
直率很容易理解，其实就是一个关于说话的问题，准确的说这是一个关于说还是不说、以及说多少的问题。过于直率的人，在说话方面往往有两个特征：
(1)想到什么说什么
这是一个说还是不说的问题。显然，不是什么东西都可以随时随地的说，或者对任何人说。可是对于过于直率的人而言，想到了就要说出来，就像俗话所说的：“嘴上没有把门的”，不管好话坏话，不区分场合，不论说话对象是谁，心里想着什么，嘴里马上就出来了。如果是好听话还好，皆大欢喜；如果是让人难堪的话，那就会伤害了别人了。如果是在公众场合让人难堪，人家可能会记住你一辈子。
(2)知无不言、言无不尽
这是一个说多少的问题。“知无不言、言无不尽”毛主席老人家曾大力倡导的，这在讨论具体事情时无疑大有帮助，可是如果作为一种品格，在中国国情（文化氛围）下，还是不宜提倡。话并不是说得越多越好，说得越多，错的机会就会越多，反倒容易被人家抓住弱点或把柄。俗话说：“逢人只说三分话”，对一个项目经理而言，更应是如此。
在情绪方面，过于直率的人，往往不能很好的掌控自己，在说话时容易显得消极或冲动。
(1)消极型
言语显示出消极的态度，例如给人泼冷水。给项目组成员安排工作时，我最怕听到两种话，一种是说“这个我不干了”，还有就是说“我不想干这个”，每次听到这两句话，心里就觉得凉飕飕的，虽然不爽，但作为团队的核心，我只能选择耐心的分析和开导。如果项目经理也以消极的方式来应对，整个团队的士气将会爱到打击。
(2)冲动型
虽然人人知道“冲动是魔鬼”，但魔鬼不是那么容易掌控的，人难免有时会说出冲动的话来，以直率著称的程序员更是如此。冲动的主要表现是言辞激烈固执、情绪激动，一旦过头就会变成人身攻击。我经常看到程序员与项目经理讨论问题，后来争论不休，项目经理被迫使用自己的职位权力，强制执行，但这样可能会导致矛盾激化，搞不好程序员就会拂袖而去：“我不干了！”
无论是消极还是冲动，这都是职场的大忌。这些外在的情绪，在领导的眼中，就是体现出了一个人的工作态度，而在职场上，态度决定一切。对于领导而言，没有积极、合作的态度，就意味着你不能为我所用，那留你何用？！
2.直率的悖论
对于直率的人有很多有意思的词语，好听一点的比如“直性子”、“直来直去”、“心直口快”、“快人快语”、“率性而为”，不好听的如“口无遮拦”、“大嘴巴”、“一根筋”、甚至“缺心眼”。可见在要不要直率这个问题上，中国人真的过得很矛盾、很痛苦，有时甚至无所适从。“说，还是不说，这是个问题”。长此以往，对于修养不够的人，造成人格分裂的倾向也不足为奇。
(1)书上提倡直率，现实鼓励含蓄
其实好像没有哪本书正儿八经的告诉我们做人要直率，那为什么很多人眼里直率是一种美德呢？我想这是从小到大的教科书对我们潜移默化的结果。书上教育我们世界上主要有两种人：好人和坏人。好人多是直率的人，他们流芳青史，而坏人多是阴险狡诈之徒，他们遗臭万年。对比之下，我们当然想做直率的人了，光明正大，而且要直率太简单了，人人都做到，做的过程中还很爽。
另一方面，中国人的含蓄又是出了名的。中国是一个讲人情的社会，什么东西最重要？人情和面子。一个成熟的人不会当面伤害别人的感情，不太好的事情喜欢用暗示，以免伤了面子。不但说话，连中国的诗歌、中国的医学、中国人谈恋爱，也是含蓄的、有点模糊的不清的。
(2)觉得直率好，却很少有人喜欢别人对自己直率
假如做一个调查，你是喜欢别人直率，还是含蓄，我相信大部分会选择直率。当别人含蓄的时候，我们会催着让他“有什么话直接说”，等别人说了，如果事情难办，心里又可能犯嘀咕，“这人说话也太直接了，连退一步的余地也没有了”。
其实我们很少有人希望别人每件事情都对自己直来直去，试想一下，当别人当面揭露我们的缺点时，我们会是什么样的心情？与此相对照的是，我们又希望自己对别人直来直去的时候，别人会高兴的接纳，这可真是奇怪的事情。
(3)网上“直率”，现实中彬彬有礼
有些人在网上非常的“直率”，直率到了一不高兴随时骂娘的地步，骂了又怎么样，反正见不着你。我相信在现实生活中，他们大部分都是讲道理有礼节之人，因为在现实中，我从来没有碰到像网上那么多人动不动就爆粗口、骂娘，祖宗十八代什么都可以骂。这样的人，有人格分裂倾向。一个人格完整健全的人，应该是一个不管什么场合都言行一致的人。
(4)表面直率，心里打算盘
3.直来直去伤人害己
直率这种性格听上去还不错，显得一个人光明正大，无所畏惧。有些人在自我介绍时候会说：“我这个人就是个直肠子”，言语之间还透着一些小小的得意。
很多人将直率视为一种美德。美德应当是对别人对自己都有好处的事情，可是“直率”并不是这样，如果把握不了度，可能反而会伤人害己而不自知。
(1)伤人
要说直率伤人，相信人人都懂，很多人还会有切身的体会。国人最讲面子，一旦面子被伤，很难挽回，正所谓“刀伤易痊，舌伤难愈”。武侠小说中江湖中人，为什么整天打打杀杀的？直率就是一个重要的原因，那些人个个都是直率之人，又不讲礼节，经常出言不逊，一言不合，就兵刃相见。好在祖先教我们注意礼节，用礼节约束我们的言语和行为，社会就会和谐多了。
有一次我收到一个程序员的辞职申请，让我奇怪的是，这名程序员一向工作踏实，为什么突然辞职呢？跟他谈过之后，这才明白原因很简单，就是因为项目经理多次批评他“怎么这么简单的事情都做不好”，而他认为事情并不简单，是项目经理不了解实际情况。但他不想解释，因为他的自尊心被伤害了，不想再待在这里工作。我又找项目经理沟通，项目经理说这是无心之言，只怪现在的员工太脆弱。最后的结果就是员工离职了，项目进度也受到一定的影响。试想，如果项目经理在说话的时候更加注意措辞，怎么会有这样的结果呢？
(2)害己
还记得《三国演义》中的杨修是怎么死的吗？杨修有过人之才，总是能看穿曹操的意图，然后得意洋洋的告诉别人，最后被曹操以扰乱军心的罪名处死。在历史上，许许多多的忠臣最后都没有好下场，因为他们往往是刚直之辈，言语伤了领导的面子，而领导一旦报复，后果是很可怕的。
直率就像没有成熟的柿子一样，好看不好吃。现实中，只听说过因为直率吃大亏，没有听说过谁因为直率升职加薪，不是这样的吗？一个管不住自己嘴巴的人，小则在团队中难以与人和谐相处，大则可能会得罪客户、甚至泄露公司机密，这样的人，领导怎么敢委以重任呢？
一个人能力很强，却因为说话的问题而吃亏，那实在不划算。技术的成长需要日积月累，而一句未经思考的话就有可能毁掉你在公司的前程。因此在把话说出去之前，我们应该多思考，三思而后言，避免犯下言语上的低级错误，后悔莫及。
4.三思而后言
在计算机中，我们常用IPO（输入-处理-输出）图来描述一个过程或一个功能模块的设计，其实人说话也是一个输入-处理-输出的过程。首先我们接收到信息，比如别人说的话、文件、任务指令或其它外部事件，然后大脑对这些信息进行处理、思考，决定要说什么，最后嘴巴将大脑思考的结果输出，也就是说话了。
人与人之间说话的过程，主要区别就在于大脑思考处理这个环节。过于直率从某种程度来说，是一种有失理智的行为，因为他没有经过“理智”的思考，全凭个人的直觉反应来应对外部事件。
(1)两种说话模型
根据人们说话的“输入-处理-输出”过程的不同，可以将说话的分为直率型和谨慎型两种方式。
对于直率型的说话方式，其主要特征是思考问题的方式比较简单，只是根据大脑的直觉做出反应，得到结论，然后直截了当的将结论输出（说出来），而且往往是一个输入对就对应一个输出，整个过程看上去就像一根“直肠子”，如下图所示：
图1直率型说话模型
这个图让人不禁想起了巴浦洛夫的条件反射理论，显然直率型的人在说话方面没有充分利用人的思维能力，发挥人的主观能动性。
而谨慎型的人，他们的思考过程比较复杂，在直觉反应之后，还要经过大脑的分析总结，在说话之前要判断是否可以说，因为除了说之外，他们还可以选择沉默。另外与直率型不同的是，他们往往多个输入对应一个输出，这意味着他们说之前要听对方把话说完，而不是匆匆忙忙下结论。
图2谨慎型说话模型
两种方式比较如下表所示：
（2）三思而后言
从上面的模型可以看到，谨慎型的人主要特征是说话理智，真正做到了三思而后言。说话一定要经考大脑思考，没有思考，我们就如同一个被自己的性格的直觉控制的牵线木偶。因此，当我们与人交流时，务必要时时思考说什么以及怎么说的问题。
●说什么
说什么就是要判断我们想说的内容可不可以说。说话不能逞一时之快，千万不可说极端的话。还有就是要学会察言观色，学会从事件的背景、对方面的性格、脸色、手势等“输入”信息来揣测对方意图，从而做出合适的反应。
●怎么说
这是说话方式的问题。要注意对事不对人，看透不说透，立场要客观，不能偏激，好话可以直接说，不好的话要委婉的说。其实程序员直率一点，尚无大碍，因为程序员最重要的事情就是高效地写出合格的代码，即使你伤害了你和经理，他一般也不会计较；但对项目经理而言，沟通是其最重要的工作，他需要与各方、代表不同利益的人打交道，如果想到什么说什么，不但会被人家认为肤浅，而且你的底牌、你的真实想法全在人家的掌握之中，无论是在处理内部冲突的时候，还是与客户谈判的时候，都会陷入被动的境地。“见人说人话，见鬼说鬼话”，这话虽然“逆耳”，但是“利于行”啊。
养成思考的习惯，刚开始可能会很不适应，觉得很累，但只要坚持，久而久之，就会习惯成自然，用大脑管住嘴巴。
当然慎言也不能过度，否则可能会造成胆怯，什么都不敢说，反而不利于问题的解决。把握好度，不要走向反面，好与坏之间往往只隔着一层纸。
需要说明的是，本人也绝不不是什么说话的高手，我对自己的要求不高，就是尽量照顾别人的感受，不捅漏子！当然即使是这个看上去简单的要求，也必须要改掉过于直率的毛病，凡事三思而后言！
5.守住真我
（1）直率也有可取之处
三思而后言，并不是要将直率一棒子打死。之所以要避免过于直率，是为了避免伤害别人和自己受伤，而不是要把自己藏得很深以进行利益的争斗，更不是要去算计别人，记住这个出发点。
因此该直率的时候还是要直率，否则就容易变成虚伪。比如在讨论技术问题时，就应该畅所欲言，让别人准确了解你的想法，注意就事论事、不搞人身攻击就可以了。在分配工作时也是这样，应该力求清晰明确。再比如，项目遭遇危机的时候，有什么想法要全盘说出来，就算只是头脑风暴也有价值。如果这时候还在考虑要直率还是委婉的说，那就好比一个人都快饿晕了，还在考虑是要吃米饭还是面包一样。在生活中，也有需要直率处理的问题，比如谈恋爱，如果总是含蓄，始终不感说出“我爱你”三个字，说不定你的心上人就要飞了。
（2）真我永存
周星驰在《喜剧之王》中有一句台词：“其实我并不是一个直率的人，我只是个演员！”说出这句话，多少有些无奈，谁不想过恣意纵横的生活呢？每个人都是生活这个舞台上的演员，需要涂脂抹粉，甚至要戴上面具，不然容易伤到别人，或为别人所伤。但这并不意味着要泯灭真我，因为真我就如“挪威的森林”一样，别人无法触碰得到，但永远存在于我们的内心深处。
有人说，直率的人生活更加真实、更有个性，如果人人都像演员，便那岂不人人都失了性格？其实性格是一种内在的秉性，并不会因为你管住了自己的嘴巴就没有了性格，难道含蓄和委婉的人就没有了性格吗？我们说话做事应该以原则为导向，而不是被性格所牵引和控制，只要你内心有自己的原则，你就是一个性格的人。
不要过于直率，但也不要走向了另外一个极端。如果心机太深，或者虚情假意，那就变成了虚伪和狡诈，没有人会愿意与这样的人交往，因为他们的行为是不友好的，已经脱离了善的范畴。只要心存善念，真我就会永存。
“丛林法则”从未离我们远去，“适者生存”仍然是支配社会运行的一般法则。对于一群社会性动物而言，所谓“适者”，不只是体格的强壮，更重要的是能参与群体的公共生活。即使是最强大的狮子，只要离群，也只有死路一条！
1.好汉也要三个帮
我喜欢看动物世界，感受那些发生在非洲大草原上的那些美丽或者哀伤的故事。那里生活着成群的狮子和鬣狗、还有数以百万计的野牛和角马。无论是凶猛的狮子，还是温驯的角马，都属于是群居动物，个体一旦离群，就会离死亡不远了。
其实这段话应该修正一下，许多动物也是要过公共生活的，至于上帝，我们都不曾见过，想必也是差不多的。无论是希腊神话中的宙斯，还是中国神话中的玉皇大帝，他们身边不也是都有一班大小天神簇拥左右吗？
可见下至动物、上至上帝都需要合群，更何况是人？
可是在程序员这样一个群体中，确实还是有不少人不喜欢与别人打交道，喜欢独来独往，过着自我封闭、离群索居的生活。
一个人不合群的原因有很多种，比如：价值观不一致、胆小害羞、不善言辞、性格内向等。而对于一个技术牛人来说，其不合群的原因还要加上一条：看不起别人，觉得“竖子不足与谋”。
中国素来有文人相轻的习惯，其实程序员相轻的现象一点也不比文坛少。程序员多有自傲的性格，容易看高自己，看扁别人。觉得自己一个人也能搞定所有事情，多几个人来弄反倒碍手碍脚。
当今社会是一个高度分工、讲求合作的社会，每个人都是团队中的一员，总想着个人单干的小农思想，已经无法与现实相容。个人英雄主义的时代已经远去，在一个项目中更是如此。俗话说：“一个好汉要三个帮”，一个人再牛，也应该学会欣赏别人的优点、与人和睦相处，因为没有这“三个帮”，他便当不成英雄好汉，空有一身武功，四处碰壁，一事无成。
2.合群谁都可以做得到
每个人都内心里对外在的事物都有一道防线，这是一种自我保护的本能。对于不合群中的人，这道防线显得格外的高大和坚固，以至于将他与其他人隔离成了两个世界。其实合群并不是一件难事，关键是要敞开心扉，卸掉内心的防线，主动与别人交往，融入到所在的团队中。当然，合群也需要注意一些问题，避免盲目交往，或者言行失范。
（1）合什么样的群
合什么样的群，也就是说我们应该与什么样的人交往。所谓“近朱者赤，近墨者黑”，因此与有必要对自己交往的对象加以界定。
如果是一帮举止不端或格调不高的人，应该果断退出，平时也应保持适当距离，以不得对方为限。
交往的重点应该是与自己兴趣相投、对自己有帮助的人。与他们相处，不但可以互相学习，而且人生的快乐和价值可以找到落脚点。
（2）言行的把握
在与人交往中，言行得体是非常重要的。2009年河南有个局长叫逯军，因为一句“你是准备替党说话，还是准备替老百姓说话”名扬天下，沦为笑柄。最近，“表叔”杨达才因为在车祸现场诡异一笑，不但引得丢官弃爵，恐怕还要陷入牢狱之灾！
在我们普通人的生活中，因为言行不慎，招来误解、怨恨的例子同样非常多。
对于言行的把握最重要的是要谦和、通融、合规、适度。例如大家玩的时候你也玩，不要做异类；开玩笑不要过分、让人难堪；举止不要怪异等。
（3）尊重他人，保持平等
这是对牛人的忠告，因为牛人技能超群，更容易觉得自己高人一等，看不起别人。人与人交往最重要的是获得尊重和认同，如果他不能从你这里获得这些，你就是比牛顿还牛，对他而言也是没有价值的。须知，尊重是双向的，合群的首要点便是尊重对方，以平等之心相待，不卑不亢，这样才能赢得别人的尊重与认同。
程序员的成长之路，没有捷径可走，只有坚持不懈的执着追求，才能成为一名优秀的程序员。执着诚然可贵，但如果不能经常自省，则有可能会陷入固执的境地。
1.程序员需要一点执着精神
《士兵突击》中许三多有一句名言：“不抛弃、不放弃”，这是一种可贵的执着精神。正是靠着这种不抛弃、不放弃的执着追求，许三多从一个普通的小兵，成长为团部的精英。在现实生活中也是这样，可以说大凡取得一定成就的人，在工作中都是一个执着的人。
对程序员则言，执着精神尤为可贵。在编程过程中，我们难免会碰到各种问题，如果没有一点执着精神，一碰到问题就抱怨、回避，怎么可能取得技术上的突破呢？又怎么能体会到解决问题的快感呢
程序员都需要一些执着的精神，来磨炼自己、发展自己，要有水滴石穿的决心和勇气，才能够成为真正优秀的程序员。
2.自省消除固执
固执和执着一样，都是一种坚持不放弃的精神，既然如此，那为什么人们总是赞美执着的人，对固执却嗤之以鼻呢？
其实两者的差别全在于坚持的方向。执着和固执，就像一根绳子的两端，虽然是在同一根绳子上，方向却相反。执着是沿着正确的方向前进，是一种理智的坚持，而固执则恰好相反。既然都是坚持，那怎么判断方向是否正确呢？
其实，何为正确，何为错误，两者之间并不是泾渭分明，不然，也就不会有那么多“执迷不悟”的人了。方向是否正确，往往是以结果来衡量的。因此是执着还是固执，其实主要是结果导向，结果好就是执着，结果不好，就是固执。爱迪生发明灯泡的时候，经历了无数次的失败仍然坚持不懈，最后终于找到了用钨丝作为灯丝方法，取得了成功，他的坚持我们称之为执着。后来，爱迪生创立了通用电气公司，坚持用直流电供电，无视交流电在远距离传输方向的巨大优势，最后输给了采用交流电方案的西屋电气公司，他自己也只黯淡离开自己创立的公司，这时候，我们只能说发明大王也有固执的时候。
如此说来，难道我们非要等要结果发生，才能知道自己的坚持是对是错吗？有没有办法让我们在进行过程中就能出判断呢？这只能靠我们的自省。孔子曰：“吾日三省吾身”，大凡善于自省的人，都不会是固执的人。他们能随时察觉自身的问题，具有理智的否定自己的勇气。
自省需要常识。对于一个不具备常识、不明白对错、不理解基本规则的人，怎么能正确判断方向呢？这样的人再怎么自省也是无济于事的，他只有在不断的碰壁中才能获得真正的成长。
我曾经见到一些程序员，在自己的想法与项目经理发生冲突时，总是一味的坚持，不肯让步，甚至与项目经理陷入无休止的争吵，还以为自己掌握了真理。殊不知，与上司顶撞是一种愚蠢的行为，这种过分的坚持，会在上司心目中形成不听话的印象。更何况，服从上级工作安排是基本的职场规则，你可以提意见，但必须尊重上司的决定。毫无疑问，在这场对峙中，不管理项目经理对错，程序员都是固执的一方。如果程序员具备这些基本的常识，并且保持自省，也就不会发生这样的事情了。
自省还需要具有突破思维舒适区的勇气。每个人的都有其思维舒适区，这里一切受潜意识的保护，一切都似乎理所当然，我们的大脑无需对事物做过多的思考，爽爽的享受这种自我封闭带来的轻松和愉悦。毫无疑问，思维舒适区阻挡了我们对事物深层次的探求，以及我们对不同观点的接纳，因而也就无法对自己所坚持的东西做出真正客观的分析。
在程序员与项目经理的争吵中，其实双方都应该勇敢跳出自己的舒适区，心平气和地考虑，对方的观点是否也具有可以接纳的成分，做一个理智的坚持者，这样才能做到双赢。执着还是固执，往往也就只是在一念之间的差别。
从程序员转为项目经理，这是一个巨大的跨越。一个新任的项目经理，对项目管理找不到感觉，一般也被认为是一件正常的事情。这是否意味着，一定要等到当上了项目经理才能学习项目管理吗？一定要做砸一个项目才能成长为合格的项目经理吗？其实未必，项目管理所需要素质和技能并不是什么独门秘籍，而是在生活中时时用到、处处可以锻炼的。只要有心，程序员一样可以学习和实践项目管理知识。从某种程度来说，我们每个人都是管理者。
1.管理是职能而不是职位
可见管理并不是经理、老总的专权，管理不是个职位，而是个职能。无论你在什么岗位，也不论你有没有下属，只要你需要做出决策，需要对结果负责，那你就是个管理者。从这个角度来说，我们每个人都是管理者，因为每个人都需要对自己的生活的工作负责，对碰到问题进行权衡决策，只不过决策的内容不一样而已。
管理只是一项职能，人人都可以随时随地履行这项职能。可惜的是，很多人没有意识到这一点，不自觉的放弃了这项可以做而且应该做的工作，这不能说不是一种“失职”啊。
2.自我管理是一切管理的基础
管理有一个流行的定义，叫做“管人理事”，既然是管人，那必须得有人可管。有人说，我没有一个下属，只是一个“光杆司令”，要说我是管理者，那我都管了谁呢？
其实只要在社会中，没有谁是真的光杆司令，你管理的不一定是下属，每一个你需要打交道的人，包括你的领导，都是你的管理对象。退一步讲，即使你不需要跟任何人打交道，你也可以、而且必须管好一个人——那就是你自己。
彼德.德鲁克说过，“有伟大成就的人，向来善于自我管理。然而，这些人毕竟是凤毛麟角。但在今天，即使是资质平庸的人，也必须学习自我管理。”试想一个连自己都管不好的人，怎么能管得好别人呢？更别说管好一个大的团队了。
那自我管理该管些什么呢？李嘉诚先生曾说：“自我管理是一种静态管理，是培养理性力量的基本功，是人把知识和经验转化为能力的催化剂。”如果更加直白的说，自我管理实际是一个修身的过程，是一个自我约束、自我磨炼、自我精进的过程。作为一个普通人，哪些方面需要磨炼和精进呢？我想无非是一个人的身心和素质技能两个方面，相应的，自我管理的内容也应该是包括身心管理和个人素质技能管理两个方面。
（1）身心管理：包括身体、心态、情绪、世界观、人生观、价值观、人生目标、职业目标等不同层次；
图自我管理是其它管理的基础
既然自我管理是一种修身，那也就可以说，自我管理是其它一切管理的基础，因为不论是什么管理，都离不开管理者自身的身心和技能。一个企业中的所有管理工作，从管理的对象来说，可以分为管理者自己、企业中的人和事、企业组织本身以及企业战略方向几个层次，其中管好自己属于最为基础的层次。一个能管好自己的人，才有能力、有精力管好别人，处理好复杂的事务，才能够通透人性，把握组织和市场的规律，成为一个真正卓越有管理者。
3.每个开发任务都是一个微型项目
作为一个程序员，也许你从来没有把自己放在项目经理的角度来考虑过问题，但实际上，你不只是一个程序员，同样是一个项目经理，因为每次接受了一项开发任务，实际上就是接受了一个小项目。
把自己当项目经理的程序员，才能成为真正优秀的程序员。优秀的程序员，也更容易成长为优秀的项目经理，因为在被正式任命为项目经理之前，他已经负责开发过了无数个微型项目。
多年以前，我就从经理那里听说，厉害的管理者都是很轻松的，因为他的工作全部交出去了，根本不用自己操心，所以他们出去度假十天半个月，一切工作都会如常进行。从那时起，我就充满了对管理的神往，可是后来我才发现原来这只是个传说，现实中忙忙碌碌的经理比比皆是，而轻松自如的管理者则是众里难寻。
(1)工作
(2)下属
因为你的下属不给力，所以你总是要自己来制定计划、自己来做系统架构、自己来监控进度、自己来检查质量、自己来写文档、自己来汇报工作、自己来解决重要问题、甚至自己来编写代码，你整天忙忙碌碌，就是在忙这样的事情。
然而，千万不要怪你的下属，因为他们不给力正是老板雇佣你的原因，况且资源的稀缺性是永远存在的——从原始社会到将来的共产主义社会。要知道，老板做项目为了赚钱，而不是让管理者更轻松，如果每个项目都是精兵强将，你只要一声令下工作就会自动完成，你倒是轻松了，但老板还要你来做什么？
(3)自己
必须要主动、有目标地对工作进行梳理，这是对一个管理者的基本要求。工作梳理就好比整理房间，你不去整理它，杂物就会堆积得越来越多，你房子最终会变得不适合人类居住。一个好的家庭主妇，必定善于将各位物品分门别类，并且适时扔掉一些用处不大的物品。一个好的项目经理也一样，同样需要对工作进行分类，对不同类型工作采用不同的策略，有些工作要现在就做，有些可以晚点做，或者不做；有些工作一定要自己做，有些工作则可以请其他人来完成。
通常对工作梳理，可以采用5W1H法，即：
Why——为什么干这件事？（目的）；
What——什么事情？（对象）；
Where——在什么地方执行？（地点）；
Who——由谁执行？（人员）；
How——怎样执行？采取哪些有效措施？（方法）。
（1）分析要做什么、不做什么，以及先做什么、后做什么
（2）分析由谁来做
解决Who的问题。虽然我们提倡项目经理要以身作则、亲力亲为，但并不是说每件事项目经理要亲自去做。对于下属可以胜任的事情，就把它分配出去。如果出现项目经理很忙、下属很闲的情况，那就说明项目经理你做得太多了，不要和你的下属抢事情做。
（3）如何让工作更有成效
做不做、什么时候做以及谁来做的问题都解决了，剩下就要解决怎么做才能让工作更有成效的问题了。在这里我们不是要讨论编码或写文档的技巧，而是个人的习惯和认识，这对工作成效的影响更是本质上的。
3.做事要分轻重缓急
所谓的“四象限法”，就是将工作按照重要程度和紧急程度两个维度进行分类。我们找一张白纸，以紧急程度为纵轴，以重要程序为横轴，在纸上划上一个十字，将纸面分为四个象限，然后将当前所有要做的工作放到这个四个象限中。
一个典型的项目经理四象限图如下所示：
（1）第一象限：重要紧急
这一类往往是火烧眉毛的事情，需要马上去处理，否则项目会受到重大影响，比如客户服务器崩溃。
（2）第二象限：重要不紧急
这类事情一般是预防型的工作，例如制定项目计划、团队建设等，它们不需要你停下手上的工作马上去做，但如果没做好的话，可能就会导致产生项目危机。许多第一象限工作产生的原因，正是因为第二象限的工作没有去做。
（3）第三象限：不紧急也不重要
这类事情看上去最不需要做了，例如上网偷菜、看新闻、写博客等，但如果你在办公室走上一圈，就会发现很多人正在干着这些不需要干的事情。
（4）第四象限：紧急不重要
（1）重要紧急
优先级最高，需要尽快处理。很多人都玩过《植物大战僵尸》的游戏吧，那你一定知道“一大波僵尸正在逼近”的感觉，是的，你必须要马上打死它们，不然它们就会冲进你的房子，吃掉你的大脑！
（2）重要不紧急
这类事情看上去可以暂缓，但考虑到其重要性，应当与第一象限的工作并行去做。如果不及时去做，它们就会转移到让你头疼的第一象限中去，或者在第一象限产生更多新的“僵尸”。所以，要在僵尸还没有逼近的时候，就好防御工事，并尽快打死它们，如果等到它们冲了过来，你还能不能保住大脑，就要看你的运气了。
（3）紧急不重要
（4）不紧急也不重要
因此，对于一个卓有成效的管理者，其优先级应该是这样的：第一象限=第二象限>>第四角限。第三象限就像数学中的无穷小一样，被舍弃了。
写到这里，我想起了前不久一位项目经理的故事：
项目定于当天上线，项目组决定搬到客户现场办公，以应付可能出现在的突发事件。项目成员电脑已经全部打包好，都围在项目经理周围等待。原来项目经理正在理一大堆发票准备报销，于是发生了这下面这样的对话：
我：“大家都在等你，怎么还在填报销单呢？”
项目经理：“今天是公司的报销日，不填好单子，又得推后很久。”
我：“你的电脑打包了没有？”
项目经理：“没有”
我：“放行条开了没有？”
我：“申请用车了没有？”
4.管理者无需事必躬亲
有一种类型的管理者，他们不论什么事一定要亲自去做，至少也是亲自过问。人们习惯用一个成语来赞美他们，叫“事必躬亲”，仿佛诸葛亮再世一般。凡事亲自去做未必真的可取，为什么诸葛亮只活了53岁，恐怕跟他这种事必躬亲的精神也有莫大的关系吧——他是把自己累死的。
（1）不要和下属抢事做
因此，当你疲惫不堪的时候，就应该问问自己，我是不是管得太多了？如果一件事情下属能做，就应该让下属去做，不然等于是你抢了下属的工作。项目经理最可悲的事情就是，自己累得半死，项目组成员却闲得发慌。
l目标明确：要做什么内容、达到什么质量要求、什么时候完成等等，必须要清晰具体。管理学家们认为目标必须要SMART（S=Specific、M=Measurable、A=Attainable、R=Realistic、T=Time-based），这是很有道理的。
l能力辅导：项目经理要对下属的能力有比较准确的把握，安排工作也应该在其力所能及的范围。如果跳一跳能够得着，就比较理想，但项目经理仍然需要主动辅导，加强监控，当发现偏差时，应及时采取应对措施。如果工作大大超出其能力范围，再怎么跳也够不着，项目经理就要另想高招了。
（3）不做甩手掌柜
项目经理应该做的工作：
l系统性工作由项目经理做，比如制定计划、安排任务、鼓舞士气、项目检查等，具体事务由下属去做。
l重要的事情项目经理来做，紧急的事情让下属去做。
l决策由项目经理来做，执行由下属去做。
l下属能做的事由下属去做，否则由项目经理自己做或带着做。
5.好习惯让工作更有成效
（1）尽力避免返工
是返工！
我见过一个城市三维模型制作的项目，经过一年多的辛苦工作，终于提交成果了，但是由于客户认为模型不够漂亮，最后几十平方公里的模型全部重做！项目组员工身心俱疲，公司遭受严重损失，客户也非常不满，一个三输的结局。
返工并不总是这样严重，其实在一般的软件项目中，返工现象也是大量存在的，只不过我们借着迭代的名义将其掩盖了。例如软件试运行后，客户要求将某项业务流程中的两个环节进行整合，或者将某个环节中的输入信息，转移下一个环节中。单个修改的工作量也许并不算大，但累积起来就相当可观了。很多项目在试运行后要修改几个月，甚至半年以上，这就是返工的代价。
迭代设计还是返工之间，并没有明确的界限。要区分二者，有两条标准：
一是迭代是计划之中的完善，而返工则是计划之外、迫不得已而为之的事情；
二是在工作量的层面，如果抛弃或被重做的功能工作量很大，那只能认为是返工，如果你非要认为这是设计就是要这样干的，那我只好给它取个新名字：“返工式迭代”。这也这给我们一个启发，做系统原型的时候，千万不要写大量的代码，否则的话，迭代最后会变成返工。
（2）打破帕金森定律的魔咒
图帕金森定律的魔咒
归根到底，还是在于我们的内心力量不够强大，面对一点点的外部阻力，就变得消极懒散，不能自我驱动。截止日期是靠不住的，要靠只能靠自己，养成良好的习惯，主动给自己压力和动力，战胜心中的“懒惰小人”，才能真正解除这个“帕金森魔咒”。
l制定规则
l琐碎事情一起做
对于工作中的琐碎问题，不用急着处理，可以启动“碎片整理程序”，将其记录下来，在你不需要“炒菜”的时候一起处理。
我经常听到老板经批评项目经理，做事一点章法也没有。所谓章法，就好比武术中的招式或套路，做项目没有章法，就会胡乱出招，项目要取得成功，那就好像猴子用打字机打出莎士比亚的作品一样希望渺茫。
1.混沌阶段
他们刚刚从程序员岗位上提拔为项目经理，也没有学习过项目管理知识，对项目管理完全处于是懵懂无知的状态。管项目基本上靠被动的等事情做，凭感觉去做，更可怕的是连感觉也没有。
如果用娃娃学走的来打比方的话，他们现在还是在襁褓中躺着睡觉的状态。如果项目就是一场马拉松，他们是没有机会到达目的地了，最后的结果只能是他的上司抱起他上路了。
2.觉醒阶段
终于睡醒了，工作从被动到主动，这是一个巨大的飞跃。他们往往会维护一个事务列表，虽然这个列表往往只是项目的一部分工作，但比没有还要强多了。在他们眼里项目即等于产品，他们会有意识的将产品进行分解，按模块分给其他人做，然后一直往下做，什么到什么时候算什么时候，他们做事没有计划性。
3.入门阶段
他们会走了。项目最终总是可以干到验收的，但返工或重做的现象经常会出现，并且往往员工的士气欠佳，其战斗力并不能充分的发挥出来。
4.全面发展阶段
这一阶段项目经理不但具有比较丰富的实践经验，而且掌握了完整的项目管理理论知识，通过长期的学习、实践、思考、领悟、再实践，各方面的技能已经臻于完善。能顾及到项目中的方方面面，技能也比较全面，对项目控制和团队领导也颇有心得。
他们会跑了。是的，他们确实已经很优秀了，但我认为，到这一阶段才称得上真正合格的项目经理，你也许会觉得要求太高了，但马拉松赛场上的选手必须是跑着的，走完是赢不了比赛的。
5.融会贯通阶段
他们逻辑性强，领导能力极强。他们不是照搬书上教导的知识来管理项目，而是凭借直觉，就能准确的把握项目中潜在的问题，并采取预防措施。他们有着非凡的领导能力，员工不但工作富有成效，而且能工作中得到快乐。到达这种境界，不仅是靠勤奋，还要靠天分。
这一类项目经理，不能用走路来形容他们了，他们就像天上的鸟儿一样，自由自在的飞翔。
我第一次参加项目管理培训的时候，那位老师非常循循善诱。第一天课堂上有一次令人难忘的对话：
老师问：“同学们，现在假设领导把你请到他的办公室，说请你做一件事事，你会问哪些问题呢？”
学生们纷纷回答：“具体要做什么事情，要求什么时候做完，做成什么样，还有有哪些人来做”
老师说：“很好。那对于自己做不了的事情，怎么办呢？”
学生：“请别人做！”
老师：“Verygood!如果很多人一起来做一件事情，最重要的是什么？”
学生说：“每个人协调一致，统一思想和行动。”
老师：“Excellent!除了上面这些，还有什么需要考虑的吗？”
沉默片刻后，有一位学生回答道：“还要考虑一些可能会出现的问题。”
另一位学生接着回答说：“还要对所有的工作进行总体把控。”
老师惊喜的说：“Perfect!同学们，你们已经把项目管理的九大领域给总结出来了！请看下面这张幻灯片…”
老师展示的是这样的一张图：
项目管理好像一头大象，将其大卸九块之后，要装进冰箱就容易多了。
看看书上是怎样解释这九大领域的：
这一节牵涉到比较多的项目管理理论知识，如果你完全没有接触的过的话，读起来可能会比较困难，建议先啃一遍PMBok，或者跳过本节。
1.五大过程组
五大过程组与九大领域一样，同样体现了做事的逻辑，只不过角度有所不同：
可以看出，这是一个完整的做事流程。其中启动和收尾一进一出、一头一尾，就像我们常说的“做事要善始善终”，而规划、执行和监控则是项目的主体，与著名的“戴明环”（即PDCA循环）相对应，构成了一个循环。
在PMBok中用下面这张图来描述五大过程组：
图PMBok中的五大过程组关系图（出自PMBok）
有人将五大过程组画成这个样子：
图网上流传的五大过程组关系图
这张图广泛流传，但它其实是有问题的，就是把监控弱化了。跟PMBok中的原图比较，在这张图中，只有执行属于监控的范围，而在原图中，启动、规划、执行和收尾都是监控的对象，很明显，原图更加严谨。
很多人分不清五大过程组与项目生命周期的关系，两个概念确实比较容易混淆。生命周期，也是就一件事物从开始到结所经历的阶段，一个人的生命周期包括婴儿、儿童、少年、青年、中年、老年等几个阶段，项目也可以这样来分。为什么五大过程组和项目生命周期容易混淆呢？关键在于大过程组看上去很像是项目的几大阶段：启动→规划→执行→收尾，然而两者之间有着巨大的差异：
图项目过程组与生命周期的关系（出自PMBok）
五大过程组与生命周期同时也存在紧密的联系。实际上，启动过程组在项目生命周期的开始阶段作用最为强烈，收尾过程组主要作用于接近完成的阶段，而规划、执行和监控过程组则主要作用于项目的建设实施阶段，如下图所示：
图生命周期与项目过程组的相互作用关系（出自PMBok）
2.四十二个过程
现在我们知道了项目管理有九大知识领域和五大过程组，那项目经理具体要做哪些事情呢？那就要看项目管理的42个过程了，做什么、用什么方法做、做出什么成果全在这里，这对于那些像无头苍蝇一样到处乱飞乱撞的项目经理来说，简直就是雪中送炭啊。然而别高兴得太早，早就听说过PMBok很难啃，它难也就难在这42个过程，每个过程都由输入、工具和技术、输出组成，千篇一律，就如同经书一般乏味，估计你看两个过程就会昏昏欲睡，所有以我也叫它“四十二章经”。
看一看42个过程的分布情况：
知识领域
项目管理过程组
合计
启动过程组
规划过程组
执行过程组
监控过程组
收尾过程组
项目整合管理
制定项目章程
制定项目管理计划
指导与管理项目执行
监控项目工作
实施整体变更控制
结束项目或阶段
6个
项目范围管理
收集需求
定义范围
创建WBS
核实范围
控制范围
5个
定义活动
排列活动顺序
估算活动资源
制定进度计划
控制进度
项目成本管理
估算成本
制定预算
控制成本
3个
项目质量管理
规划质量
实施质量保证
实施质量控制
项目人力资源管理
制定人力资源计划
组建项目团队
建设项目团队
管理项目团队
4个
项目沟通管理
识别干系人
规划沟通
发布信息
管理干系人期望
报告绩效
项目风险管理
规范风险管理
识别风险
实施定性风险分析
实施定量风险分析
规范风险应对
监控风险
项目采购管理
规划采购
实施采购
管理采购
结束采购
2个
20个
7个
11个
42个
如果你想看每个过程的详细讲解的话，那还是得自己动口、丰衣足食——动口啃PMBok。这里我们倒是可以对其进行简要解读，避免由于食物太硬引起消化不良。
42个过程是按照后面两个维度进行划分的。为什么没有生命周期呢？这是因为不同类型的项目生命周期划分会千差万别，例如一个软件项目和一个房地产建设项目的阶段划分毫无疑问会相去甚远，而PMBok是适用于不同行业、不同类型项目的通用的指南，不可能将其固定下来。因此假如具体到某个软件公司，完全可以根据软件生命周期划分、参考PMBok中的过程，重新制定合乎本公司实际情况的项目过程，相信大部分软件公司的ISO9000文件正是这样干的。
主要疑惑点在于“制定项目管理计划”与“制定进度计划”、“制定进度计划”等过程之间的关系。
其实PMBok已经明确说了，它们之间是总子划和分计划的关系。在项目管理计划中，同样可以包括这些分计划的内容。也就是说，只要你愿意，完全可以把规划过程组中的所有工作放到“制定项目管理计划”这一个过程中来完成——总计划把分计划中的事全干了。
监控过程组中一共有11个过程，这11个过程的关系是比较让人迷惑的。在整合控制中有“监控项目工作”和“整体变更控制”两个过程，它们与别外八个领域的中的监控过程是什么关系呢？
通过研究各个过程的输入和输出，可以发现“监控项目工作”过程产生的的一个主要成果是批准的变更请求，而该成果又是另外八个领域中的控制过程的输入，这些控制过程又都有一个重要输出是请求的变更——该成果又是“整体变更控制”的输入。由此，各个过程的关系浮出水面，如下图所示：
从图上可以看出，“监控项目工作”主要是发现问题，提出变更请求，而“控制范围”等过程，则是确定怎样变更，真正的进行项目变更的动作是“整体变更控制”。
启动过程组在两个过程：“制定项目章程”和“识别干系人”。按照五大过程组的特点，这两个过程在项目每个阶段之初都需要执行。难道我们在设计阶段和编码阶段都需要重新制定项目章程和识别干系人吗？
这看上去有点奇怪，在实际项目中，项目章程和干系人一般不会有什么变化，每个阶段都要重新做一次这个工作似乎有点牵强。在PMBok中关于项目章程有一段话是这样说的：“在多阶段项目的以后各阶段，制定项目章程过程的作用是验证原来为项目制定与颁发的章程所做的各种决定。这一过程在必要时还核准项目下一阶段并更新该章程”。原来如此，简单来说，就是看原来制定的章程还好不好使，不好使就需要更新了，算是能说得通。
同样，识别干系人也就是看干系人有没有变化了，但这与项目监控又存在一定的雷同了。我们可以设想一下，如果干系人发生了变化，我们一定需要等到一下阶段初才对做出相应的对策吗？显然不现实，我们会立即做出反应，而能随时识别变化并做出反应的过程只能是监控过程组了。
曾经在培训课有一位老师告诉我们，项目经理主要做项目整合管理的工作。个人认为这种说法有失偏颇。
1.项目管理是关于做事的方法
项目管理不是什么神秘东西，要以平常心来看它，它就是人们总结出来的一种有效的做事的方法而已。这种方法有几个要点：
项目没有目标，就好像踢球没有球门，其重要性不言而喻。但是项目的真正目标并不一定等同于招标文件中提出的目标，招标文件是台面上的东西，是比较表面化的，而客户的真实目的也许并不在于此。因此，项目经理最好对项目的来龙去脉搞清楚，这样才能更好的把握客户心理，理解项目的重点，真正使到客户满意。
项目计划在项目中处于非常基础的地位，项目的实施都应该按照项目计划来进开展。如果项目没有制定计划，或者虽有计划，却是说一套、做一套，那么这不叫项目管理，这叫打乱仗。没有计划，项目实施也就失去了依据，也更谈不项目监控了，项目管理中的42个过程，也就基本失效了。
项目监控是很多人新任项目经理的薄弱环节，为什么那么多人说“计划赶不上变化”，其原因正是在于控制环节的缺失。项目不是一台机器，你只要启动马达，它就会按你设计的那样转个不停。项目的过程中产生偏差是正常现象，甚至是必然的事情，如果不加以控制，计划就会成为摆设，项目也会越偏越远，项目完工也就更加遥遥无期了。因此说控制是手段，是保证项目能按计划达到目标的手段，每个项目经理都必须主动监控项目，用好这一手段。
2.结构化分析方法
还记得什么是结构化分析方法吗？说到它，很多人会想起数据流图、数据字典等等这些工具，但其内在的精神思想，即“自顶向下、由外到内、先整体后局部、逐层分解”，这才是它留给人们最宝贵的财富，
其实结构化分析法方不只是用于软件的分析设计，在人们生活的方方面面都有其用武之地，因为它是对复杂和大型事物的分析方法，符合人们对事物的认识规律。在PMBok中同样深刻的体现了结构化分析方法的思想。
首先PMBok本身就是一个自顶向下、逐层分解的知识体系。没有分解之前，项目管理是一个混沌的整体，PMBok将其按不同的维度分解为五大过程组和九大知识领域，然后又进一步分解为42个过程，每个过程又分解为输入、工作和方法、输出三个部分，这不正是完美的体现在结构化分析的思想吗？
项目经理组织项目实施更加离不开结构化思想。42个过程中有一个非常重要的过程是“创建WBS”，所谓WBS，中文名是“工作分解结构”，它其实就是一种按照“自顶向下、逐层分解”的思想建立的一种树形的项目任务清单，这是整个项目执行和控制的基础，如果你不会使用WBS，那基本上就也就等于说你不会管项目了。
结构化方法在编写项目文档以及汇报材料时同样有其用武之地。项目文档其实也是一种交流汇报的材料，为了能让别人看懂，我们先要把事情总体的讲一下，然后将其分为几个大点，每个大点可能又分成几个小点来讲，这样别人就有对你要讲的内容搞清楚了。我看过一本专门教别人写汇报材料的书，叫《金字塔原理》，其实也就是讲如何自上而下组织材料，让汇报变得更有条理。现在你懂了结构化方法，这本书你也就可以省了。
3.过程思想
ISO9000有八项基本原则，其中一项就是“过程方法”，并将过程定义为：“一组将输入转化为输出的结果”。过程包括三要素：输入、活动、输出，对于这三要素，我想这三素对于程序员来说肯定不会陌生，因为我们在进行软件设计时，所使用的IPO图与它如出一辙，IPO图的三要素是“输入、处理、输出”，两者其实没有什么区别。也就是说，IPO图其实是表达过程的有效工具。
回到PMBok中五大过程组的那张图，它其实就是一张IPO图，它也有由输入-处理-输出组成，即启动-规划、执行、监控-收尾，由此可见，其实整个项目就是一个大的过程，同样，项目阶段也是过程。五大过程组又包含42个过程，每个过程都是由“输入、工具和技术、输出”组成，这与“输入、处理、输出”不是一回事吗？
需要说明的是每个过程并不是个独立的，而是相互关联和衔接的，前一个过程输出成为下一个过程的输入，从而形成了一个个过程链。下图是一个简要的过程链示意图：
图项目管理中的过程链
1.我的第一次顿悟
（1）懂三大目标才算入门
这是我在项目管理方面的第一次顿悟。从这一天起，我才感觉自己像一个真正的项目经理了。也正是从这一天起，我才明白原来项目管理是有章可循的，我买来了项目管理的书籍，参加了项目管理培训，开始了新一轮如饥似渴的学习。
后来在工作中我每天都尝试着问自己这些问题：
l成本：项目计划花多少钱？每项子任务分别打算用多少钱（多少人月）来完成？是否发生了偏差？如果有偏差，怎么处理？
l质量：软件功能完整吗？软件操作方便吗？运行结果正确吗？运行效率够快吗？软件代码符合规范吗？客户用起来满意吗？
我想如果能做到这些，项目管理也就算入门了。项目经理只有心中时刻谨记三大目标，行动才会有方向，才能真正主动、有意识的管理项目，也才能算是一个真正的项目经理。
（2）三大目标就是“快好省”
周总理曾经提出要“多快好省的建设社会主义”，三大目标实际上与“快好省”是一致的。为什么没有多呢，因为“多”绝不是项目管理的目标，项目只需要完成规定的内容即可，如果以“多”为目标，那么项目永远都没有完工的一天。
（3）谁在关心三大目标
三大目标
买方（业主方）
卖方（承建方）
成本
合同签订后，项目实施成本基本上与客户无关。
关心程度：0星
成本要尽量低，对公司至关重要。
关心程度：5星
进度
要快，尽早投入使用。
关心程度：4星
要快，可尽早回收款项。
质量
质量越高，使用越爽。
质量越高，成本越高，质量太低不能验收。公司被迫关心质量。
关心程度：3星
2.从三大目标到五大因素
所谓项目五大因素，就是项目三大目标加上范围和资源，它们是构成项目的基本要素。虽然管理专家们很少将它们并称，但鉴于它们的重要性，以及相互之间的紧密关系，有必要进行一些说明分析，以引起项目经理们重视。
（1）项目五因素
那为什么单单把三大目标拿出来说呢？其实很简单，这是因为项目范围、资源其实是约束性因素，而不是项目目标。其中项目范围是客户对项目的约束，而资源是你的老板对项目的约束。用口语来说就是，有这么一摊事（范围），老板给你这么多人（资源），你把它干好，什么叫干好呢？就是费用不能超支（成本）、干出来的东西还要好用（质量）。
（2）项目约束公式
项目五大因素之间，并不是孤立的，它们之间的变化关系可以用一个简单的公式来表示，我们不妨称之为“项目约束公式”：
根据这一公式，我们可以得到几个“推论”：
●预算不变的情况下，范围变大，只能降低质量，质量要求提高，只能减少范围（少做一点工作）
可见这五大因素这间，是对立统一的关系，它们互相制约，互相影响，又相辅相成，因此必须要进行总体控制，保证各个因素之间的平衡，这也就是项目管理九大知识领域中为什么有一个整合管理的重要原因。
（3）挣值管理的不足
在项目管理中，有一个著名的方法叫“挣值管理”，它是用计划进度、实际进度、预算成本、实际成本这几个值进行运算比较，用来衡量项目绩效的一种方法。该方法对推行项目的数字化管理有着巨大的推动作用，然而由于缺失了一个重要因素，使得这个方法存在着严重的不足。
这个因素就是质量。挣值分析只有成本和进度两个方面的因素，没有质量，将其用于绩效考核时免不了产生很大的漏洞。为什么会没有质量呢？这是因为质量难以用数字进行度量，特别是对于软件项目而言。虽然国标《软件工程产品质量》（GB/16260-2006），提出了比较完整全面的质量模型以及度量的指标，但质量评价成本很高，而且很多指标经依赖于人的主观评价，实用性也就大打折扣了。相对而言，对进度和成本的评价，如果借助合适的信息系统，完全可以通过计算机自动实时生成，不需要人过多的干预，非常方便。
项目经理是否具有积极的心态，直接关系着项目的成败。很多情况下，项目经理并不是真的不愿意积极面对问题，而是觉得问题本身是难以解决的，只能听之任之。而事实上，一切问题都是可以解决的——这不只是一句口号，而是确确实实可以做到的。当你持有这想的信念时，解决问题的能力将会变更为强大。
1.我的第二次顿悟
项目管理培训并不是人人都需要，但对于渴望获得帮助以消化理论知识、尽快掌握要领的项目经理而言，还是很有必要的。我第一次参加项目管理培训时，说实话基本上什么也没有听懂，脑子里只留下了几个诸如“铁三角”、“二八法则”等等这样的词在盘旋。但通过这次培训，我知道了原来项目管理有一整套的理论和方法体系，并不是凭本能出招就可以搞定的，于是我开始系统性的学习这些知识。
但这不是我说的“第二次顿悟”，因为“第二次顿悟”给我的收获是让我以更加积极的态度来处理项目中的问题、来面对生活，这远比我学到一些具体理论知识重要得多。
这一次重要的领悟，起源于我参加的另一次项目管理培训的经历。在培训中，老师让我们做了我们很多训练题，其中有不少是案例分析，大致是讲某项目碰到了什么问题，问该怎么办？答案ABCD选一项。做这些题目的时候，我不由自主想到了公司项目的情况，其实与题目中的描述是如此的相似，而我们曾经那样的无助、不知所措，而老师每次给出的答案又是那样的不容置疑，这让我突然意识到，其实每个问题都是可以解决的，正如每个题目都有答案一样。
回想起以前在公司的项目例会上，项目经理们总是一而再、再而三的提出一些类似的问题，比如：
客户又改了需求，变化较大，工作量比较大，项目只能比计划拖延；
某某功能没有人做，放在那里，要等人腾出来再做；
某位骨干人员要离职了，项目进度要滞后了；
碰到了一个技术难点，公司以前没做过，一直卡在那里；
……
诸如此类问题层出不穷，它们如此让人头疼，却又无可奈何，就好像一个人身患不治之症一样，只能默默等死了。管理层面对这些问题往往也是哑口无言，以至于最后竟然也默认为它们确实不关项目经理的事，只能听之任之了。
现在再来思考这些问题的时候，才发现原来我们一直都在欺骗自己。这些问题虽然让人头痛，但并非毫无办法，它们也有其解决之道：
评估该功能是否在关键路径上，是否可以往后放，等人员腾出来再做
请求将该工作转给研发人员
原来这些看似很棘手的问题，还有这么多解决方法。即使这些方法都不奏效，项目经理也还可以做一件事，就是评估影响，申请项目变更——不要忘了，变更也是一个方法。在有些极端情况下，甚至需要放弃项目，也就是不做了，跟你的业主方说byebye，好聚好散。在必要时，连分手都是一个选择，但只有一条路，你永远不能走，那就是放任不管。要知道，回避问题永远是最差的选择。
2.项目管理就是解决问题
一切问题都有解决之道，这对我是一次非常重要的领悟，因为它改变了我对看待项目的心态。只有勇于面对问题，积极寻找解决的方法，才有可能达到目标。
（1）项目中充满的问题，要积极对待
项目有问题才是常态，没有问题那是特殊情况。项目经理应培养乐观心态，不要因为碰到问题就闷闷不乐，死气沉沉，试想，如果项目没有问题，那项目经理的价值何在？
当然有人说，项目经理应该预防问题，而不是解决问题。如果你能预防所有的问题，当然是好，但这几乎不可能发生。更何况，怎样预防问题，这其实是一个更难的“问题”。
面对问题，还要积极的去解决，而不是认为没有什么好办法、只能这样了。有些项目经理在被上级批评时，总是千方百计的辩解，这是一种非常消极的做法。不要以为你让上司也觉得无可奈何，就可以心安了，甚至还小小得意一番。不要以为上司点头了，就是在赞许你，其实他在通过每件事来评估你，看你究竟是平庸之辈，还是可造之才。
从“无可奈何”到“我可以想办法”，一个小小的变化，足可以实现从平庸到优秀的跨越。积极还是消极，主动还是被动，就在一念之间，而这一念，会直接影响到项目的结果。
虽然每个问题可以解决的，但每个问题都没有标准答案。怎样解决，需要具体情况具体分析，不存在一种简单的方法或规则，就可以解决所有的问题。这就像冲浪时，每个浪头的高度、方向、力度都不一样，冲浪者无法为自己设定一个固定的姿势，只能在浪头扑过来时，根据自己的经验来进行调整，否则很快就会被打翻。
（2）主动面对生活中的问题
生活中也与项目一样，充满的问题。俗话说：“家家都有本难念的经”，其实只要积极面对，人人都可以把这本经念好。
“一切问题都是可以解决的”，在生活中我也用这个观点来勉励自己。当与家庭成员产生矛盾时，我会想到，这是可以解决的，于是我主通沟通，让他们更加了解我的处境，我的真实想法，“理解万岁”这句话一点也没错，许多问题就这样化解于无形，这些都得益于我的这一次领悟。试想，如果我对生活中问题采用回避的方法，对其视而不见，矛盾必然会累积，总有一天会爆发。为什么总有那么多家庭因为鸡毛蒜皮的小事闹得不可开交，甚至弄得家庭破裂？可以说，不能积极主动面对问题，是一个重要的原因。
前几天在网上看到一则新闻，甘肃一男子嫌自己混得不好16年未回家，这就是一个回避问题的典型例子，不回家显然不能解决混得不好的问题，反倒让自己失去了16年的亲情温暖。在项目中，你会因为觉得项目执行不顺利不向上级汇报工作吗？其实越是有问题，就越应该汇报，争取上级的理解和支持，要知道你的上级往往有更宽的知识面、掌握着更多的资源，说不定他可以帮助你呢？
程序员和项目经理是两种完全不同的岗位，工作方式也大不一样。以前是一个人单干，现在是团队一起干，以前是自己亲自干，现在是指挥别人干，这是一种巨大的变化。要适应这种变化，首先必须要转换思维模式。思想决定行为，思维模式就好比在陌生城市找路用的地图，拿着过时的地图，自然无法到达想去的目标。思维不换走老路，思维一换天地宽。
1.从单干到群干
从程序员到项目经理，不只是职位的变化，其工作性质也发生了根本性改变，简单的说，是一个从单干到群干的过程。
严格来说，程序员并不是单干，他们也是在团队中，需要具有团队合作的精神，但其实程序员的工作具很强的单干的特征。在项目中，程序员的基本工作，也就是完成项目经理分配的开发任务，而这些开发任务，是项目经理或团队进行工作分解后的小的工作包，是一个确定的功能点，一个人足可以胜任，因此程序员只需要自己构思、自己编码就可以了，并不需要很多人一起来合作完成。
项目经理不一样，他面临的不是某个确定的功能点，而是整个项目，无法一个人完成，必须要整个项目组齐心合力一起来做，这就是群干，也就是团队作战。项目经理不只是自己需要团队精神，更要能够激发其他人的团队精神。
我们看一看程序员和项目经理两种角色的比较：
角色
正如黄健翔的名言说的一样：“你不是一个人在战斗！”项目经理要时刻记住这一点，不要只顾自己闷头编码。只有学会发挥团队的力量，才能管好项目，成为一名真正合格的项目经理。
2.为什么软件企业人难管
从单干到团队做战，项目经理最大的变化就是以前只需要管自己一个人，现在你要管一个团队，以前独善其身就可以了，现在要兼济他人了。可以说，项目经理最重要的一项工作就是管人。
但是软件企业的人是出名的难管。软件公司的经理管人有两难，一是留人难，人才流失成了很多公司的心病；二是用人难，要把程序员用好，把大家的潜力发挥出来，决非易事。
（1）留人难
每年春节过后大约三月份，是很多软件公司的人力资源部经理最“兴奋”的时候，一方面他们要大量招人，另一方面，大量程序员辞职流失，让他们叫苦不迭。
程序员的离职率高，一直是行业的普遍存在的问题。据前程无忧网站2012提供给《中国经济周刊》的信息表明，IT行业人才流失率高居所有行业的首位。另外据CSDN的一份调查显示，43.6%的开发者在5年内换了3份以上的工作，这么高的跳槽频率真是让人瞠目结舌。我们不禁要问，为什么程序员这么“喜欢”跳槽呢？
我曾经接触过数以百计的人员离职，根据对他们的分析，我将程序员离职的主要原因分为三种：
表程序员离职原因分析
类别
原因
分析
行业原因
程序员就业情况比较好
既然选择多，也就没有必要担心离职问题了。
行业不成熟
很多软件企业生存艰难，大部分软件企业给员工提供的薪资福利有限。
行业内“贫富差距”大
少数优秀的公司如阿里巴巴的高薪，导致程序员这山望着那山高，影响了员工作稳定性。
公司原因
人际关系紧张
人人都向往愉快、和谐的工作环境。
对公司前景没有信心
如果说公司是大海中的一条船，没有人愿意待在一条没有方向，船身也破破烂烂、摇摇晃晃的小船上，不如趁早离开，找一条更大更坚固的船。
晋升机会少，个人能力得不到发挥。
良禽择木而栖，既然英雄无用武之地，那也没有必要在一棵书上吊死。
工作压力太大，或长期出差
要钱也要命啊。为了工作可以忍一时之苦，但长期搏命，那就要考虑值不值得了。很少有公司真的把员工当作家庭成员，那只是说说而已，同样也不要指望员工真的把公司当成自己的家，把公司的事当成自己的事
个人原因
期望获得更高的薪酬
跳槽是公认的涨薪最快的方式。
想换多换几个公司，多学一点东西，开阔视野
自己有一身武功，到哪里都会吃亏。在一个小环境中待久了，不了解外面的世界，能学到的东西也有限。
有些人抱着“此处不留爷，自有留爷处”的想法，不认真对待工作
既然这样，公司也不会认真对待他们，更加不会委以重任，最后他们也就边缘化为可有可无的人物了，跳槽也就成了唯一的出路。
以上枚举显然不能穷尽所有的问题，但能抓住主要原因就可以了。
这么多问题中，最重要的还是薪资问题。据《北京青年报》的调查显示，“职业收入高低”是促使人们跳槽和选择新职业的首要原因。然而在这一问题上，公司其实也有其苦衷。
很多人从学校毕业，对开发基本上一无所知，经过在公司一年多的培训学习，取得了巨大进步，个人能力提升很快，此时必然对薪资要求也比较高，这是可以理解的。然而，站在公司的角度，这一年你基本上还谈不上什么贡献，公司却付出了较大的成本，大幅加薪一时难以接受，难道我把你招进来就是为了培训然后再涨工资干活吗？你也许会认为公司非常短视，这样的公司不待也罢，殊不知，软件行业看似光鲜，其实大量的企业挣扎在生死线的边缘。据工信部统计，2011年上半年我国软件行业利润仅占软件业务收入的1.28%，这么低的利润率，能活下来就是成功，对公司提出过高的要求也是不现实的。
在这一场博弈中，没有谁对谁错，但公司肯定是受伤的一方。真正将员工利益与公司利益统一起来的凤毛麟角，大部分公司里，公司和员工就像一对冤家，虽然互相需要，却又矛盾重重。
当然，其实公司也应该转变思路，不要总抱着我培养了你、你应该感谢我的心态，在程序员进步巨大的情况下，还是要给员工相应的薪酬，真正留住人才，毕竟软件项目禁不起人员剧烈变动的折腾，从长远来看，公司还是划算的。
（2）用人难
留人难，用人更难，要把程序员用好，则是难上加难。员工用得好，每个人都奋勇当先，以一当十。用得不好，员工死气沉沉，没有朝气和干劲。在我所见过的软件项目中，虽然有不少程序员工作主动积极、富有效率，但更多的是缺乏激情、消极怠工、甚至不服从项目经理工作安排情况。
为什么软件开发人才就这么难用呢？这是由多方面的因素所决定的：
软件产品有一个非常显著的特征，就是它是一种无形的东西，在生产过程中看不见也摸不着，完成以后可以看到运行效果，但你还是无法知道它是不是一个“豆腐渣工程”。它里面暗藏的问题也许若干年后才能看到，也就是说它的质量评价非常困难。这与传统的制造行业有着非常大的差别，比如你是造一栋房子，生产过程中我们就能看到它的结构设计是怎样的，它的地基是不是够牢固，它有没有用“牙签钢筋”等等。
总之，软件开发存在非常多的不确定性，非常依赖于每一个开发人员。虽然管理专家们发明了很多方法企图来减少这种不确定性，减少对人的依赖，让软件开发像传统行业一样变得可控，但迄今为止，仍然没有一个通用的行之有效的方法，专家们也不得不无奈的发出“没有银弹”的感慨。
不得不承认，与其它行业人员相比，程序员显得更加内向、不合群，有些人自视甚高，看不起别人。他们做事冲动、不服管，也就不足为奇了。
程序员都很聪明，对自己的期望值也很高，不会满足于现状。有想法本来是好事，但人人都很有想法时，经理就没那么好当了，没有高超的领导技能是难以应付的。
综上所述，软件企业对人的依赖性非常强，却又面临着留人难和用人难这样两难的困境。要解决这些问题，一方面要求软件企业真正要做到以人为本，另一方面也对管理者提出更高的要求。
3.转换思维提升领导力
留人难、用人难，难道我们真的就无能为力了吗？这两难困境中，有行业原因、有公司原因，对于这些，作为项目经理也许力不从心；但也有程序员的原因和项目经理自身的原因，对于这一类问题，项目经理并非无能为力。即使在同一个公司，不同项目组中的人员流失情况、团队士气也会有很大的差别，这说明项目经理完全是可以有所作为的。对于有强大领导力的项目经理而言，人员的流失率会更小，工作效率会更高。要提升领导力，首要的是转换思维。
在前面博文中曾介绍了管理的五大思维：以目标为中心的思维、整体思维、平衡思维、以人为中心的思维、团队思维。其中前面三项与理事有关，而后面两项与管人有关。下面我们对这两种思维进行详细的解析：
表管人的两大思维
思维
主要观点
以人为中心的思维
软件产品主要取决于人
虽然流程、规范也很重要，但软件产品的质量，项目的进度、成本等因素，更多取决于每个人的技能与投入程度。
人的潜力是巨大的
一个人的能力就像海上的冰山，项目经理无所作为，你得到就只是露出水面的那5%。一个优秀的项目经理可以通过其领导力，将员工的潜力挖掘出来。
人是有感情的
员工绝不是木头，可以随便搬来搬去，搬到哪里都是一块木头。首先项目经理不可以做伤害下属感情或面子的事情，进一步可以利用这一点，适当使用感情牌，提高团队的凝聚力。
人是有动机的
员工可以努力工作，但这有动机的，要学会分析、利用员工的动机，并采用合适的激励手段。
人与人之间是有差异的
每个人在能力方面和思维方面均存在差异。这一方面要求项目经理不能吹毛求疵，要容忍员工的不足，另一方面，项目经理不能一味以己之心，度人之腹，要尊重人的个性思维。
团队思维
团队的力量可以是1+1>2，也可以是1+1<2
“三个和尚没水吃”，这是典型的1+1<2，其根本原因是他们之间没有建立坦诚相待、团结合作的关系。一个项目团队也是如此，不要以为人多就力量大，那还要看项目经理会不会领导团队，会不会用人。
团队成员之间相互影响
近朱者赤，近墨者黑。正面的情绪也会给别人施加正面的影响，不好的因素同样会扩散，而且会更快、影响更大。因此，项目经理必须要带动正能量，并注意将那些负面的东西扼杀在萌芽状态。
团队之间的协用程度是团队战斗力的关键
团结就是力量。一个木桶能装多少水，不仅取决于每块木板的长度，还取决于木板之间结合是否紧密。项目经理的领导力，就是木板之间缝隙的粘合剂。
项目经理在团队中起着至关重要的作用
一头狮子领着一群羊，要胜过一只羊带着一群狮子。项目经理是团队的核心，他在团队中起着协调作用、激励作用、榜样作用，可以说他直接决定了团队的战斗力。
可以看出，这种以人为中心的思维和团队思维，真正体现了以人为本的思想。它们与程序员的机器思维、单干思维大相径庭。许多项目中的问题，就是由于项目经理的思维还停留在程序员阶段造成的。
4.项目经理也是人事经理
在管人的方面，除了要建立上面两大思维之外，还要提高一项认识，那就是项目经理其实也是整个团队的人事经理。
我担任部门经理的时候，曾无数次遇到这样的情况：
项目经理找到我说：“经理，某某要辞职了，帮我安排一个人。”
“你跟他谈过没有？”我问道。
“还没有。”
“他为什么辞职？”
“还不清楚，可能是工资问题吧。”
我找员工沟通过之后，原因自然是五花八门，有要求加薪的，有抱怨环境的，还有跟项目经理合不来的，不一而足。经过多轮沟通，该开导的开导，有合理要求的尽力帮助争取，还有一部分可以承诺延迟满足，或者用前景来“诱惑”等等，采取这些方法之后，还是有不少人愿意留下来继续做的。其实，大部分辞职的人并不是喜欢换工作，而是有一个心结，需要上司来帮他打开。
项目经理还有一个普遍存在的误区，就是在评价下属时，习惯于说某某不听话、不好管。殊不知，一个员工好不好管，其实也取决于项目经理本人的态度和做法。一个看似不好管的员工，经过引导，同样可以成为项目的骨干，这样的例子屡见不鲜。
所以项目经理在碰到管人的难题时，不要再总是想“这个我管不了”、“那个我没办法”，而应该抱着“我也是人事经理”这样的心态，主动沟通、想办法。如果经过分析或者努力后，确实需要上司出马的，才去请上司来帮忙解决。直接把问题丢出去，当然是最简单，但这样做一方面你在团队中的威望会受到影响，项目的凝聚力下降，另一方面你的个人价值也大打折扣。
5.打造“凝胶型”团队
著名职业经理人唐骏说，管理的任务就是“造一条船，然后让船划起来”。对项目经理而言，我们已经有了一条船——就是项目团队，现在的任务要把它划起来。
软件质量之父沃兹.汉弗莱曾经提出，一支高效的团队应该是一种“凝胶型”的团队。在这样的团队中，大家有着清晰的共同目标，彼此合拍，每个人都全身心投入，团队显示出超常的战斗力。
2.每天客户下班后开会，与项目组成员一起进一步研究项目存在的问题，按轻重缓急做成任务列表，制定阶段目标，并检查上一阶段完成情况，更新任务列表；
3.向公司申请了充足的经费，保障后勤，改善工作环境和吃、住条件，解除后顾之忧；
4.与团队一起加班加点，一起分析问题，并亲自完成一些力所能及的功能修改。
在这一次经历中，虽然大家都很辛苦，但每个人都过得很充实。大家同心合力，每个人都贡献了自己全部的智慧和力量，也都做到了以前难以想象的事情。
根据项目经理团队中充当的角色和发挥作用的不同，凝胶型团队可以分为两种，即星型和网络型，如下图所示：
图两种“凝胶型”的团队
项目经理处于中心位置，好比一颗红太阳，把大家吸引在自己的周围，整个项目组依靠项目经理领导力团结在一起。这要求项目经理个人能力极强，富有魅力，具有绝对的权威。星型团队的决策方式常常是这样的：项目经理收集意见，项目经理决策，再反馈给大家，或者由项目经理单独决策，再分发给大家。
网络型的团队中，项目经理看似在其中不占主导地位，项目经理的权威被弱化，实则项目经理的对团队的控制已经内化到每个人的潜意识之中，达到了一种近似于“无为而治”的境界，因此对项目经理的要求更高。
这种团队的决策方式一般采用民主制或民主集中制。把大家联结在一起的不只是项目经理领导力，更是富有挑战性、具有吸引力的目标，以及共同的认识和价值观。项目经理往往是外柔内刚，能够不动声色，于无形中实现对项目掌控。
能够建成星型团队的项目经理已经寥寥，能做到网络型更是可遇不可求。不管有多难，目标不能丢。我们就好比是一群已经出发的登山者，来到了山脚下，怎么能够因为看到山太高太难爬就放弃攀登呢？
在项目团队经常有一些比较能干的员工，为项目经理排忧解难，因此渐渐得到项目经理器重。由于互相依赖，两者很容易发展成为朋友关系，有的项目经理甚至将员工当作“心腹”看待，借此来笼络员工，这其实是一种很不明智的做法。
从广义上来说，同事也是朋友，同事之间也是存在友情的。在正常情况下，项目经理与每个人的距离是相等的，整个团队保持一种平衡。如果项目经理与某位员工建立了过于亲密的朋友关系，这种平衡将会被打破，从而影响整个团队的凝聚力。
（1）无法客观公正
一旦下属成为朋友，项目经理在工作就难以像以前一样做到公正客观。毕竟在公司工作主要是讲原则，而朋友之间则要讲感情，如果朋友这间处处以真理为依据，以大是大非为准则，这样的朋友估计是做不长的。同样如果工作中带进过多的感情色彩，工作也会变得难以开展。
我们不妨设想一下，和员工成为朋友这后，碰到下面这些情况你会如何处理：
●朋友在公开场合发表不恰当的言论，或者打乱项目内的等级秩序和工作流程，你会像批评其他人一样直接批评他吗？还是用对方可能听不懂的话进行暗示提醒？
●在对员工进行绩效考核时，你会不会因为感情原因，不自觉的拔高一些他的分数呢？
●在其任务不能保质保量、按时完成时，你的要求是不是也降低或更富有弹性了？
●你是不是不能像以前那样自然的来检查他的工作了？
●在检查他的工作时，发现了技术问题，你是不是也不好意思进行指导了？
●在他变得自以为是、经常对你提一些不切实际的建议和要求时，你是不是也无可奈何了？
一边是原则，一边是友情，该如何抉择？这就是把朋友关系带进工作后，项目经理面临的困境。面对上面的这些问题，项目经理要想持守中道，就必须摒弃感情的因素，以原则为导向，以事实为依据，做出冷静的选择。这样，不管将来项目中会出现什么问题，项目经理都可以做到问心无愧，进退有据。
（2）给所有成员带来错觉和困扰
工作中的朋友关系不只是给双方带来不便，而且会给其他员工带来错觉和困扰，从而影响项目的凝聚力和战斗力。
在IBM日本总部曾发生过一个著名的“东京事件”：
IBM“东京事件”的起因，是IBM东京公司高层决定秘密重奖几位工作出色的骨干分子。这件事本来是机密，在美国IBM本部也是一种例行的激励手段，但让管理层意想不到的是，领奖的几个人刚走不久，一些没有得到奖励的人就跑来要求辞职。他们这么做倒不是出于闹情绪，原因很简单——别人被重奖，而自己没有得到奖励，证明自己工作成绩不突出，得不到领导认可，继续“混”下去没劲，还不如自己知趣点，主动申请走人，免得日后被老板裁掉那么尴尬。令管理层更想不到的是，等这些人刚走，那些受到奖励的人又跑来要求辞职！原因更简单——由于自己被老板重奖的原因，害得同事们丢了饭碗；而同事因此辞职又害得公司工作陷入了被动。所以是既对不起同事也对不起公司，只好坚决辞职，以谢同事和公司。
这个事件看起来很诡异，对骨干员工的奖励居然会导致所有员工辞职，但这件事同时也是可以理解的，因为对个别的秘密奖励破坏了员工之间原有的平衡关系。这件事也让我对日本人的团队精神刮目相看，我想这也是我们该好好学习的地方。
虽然故事中是对部分员工进行物质奖励，与我们谈的朋友关系似乎没有什么联系。但两者对团队和谐的破坏是相同的，我们完全可以进行类比。项目经理和下属的朋友关系，在一定程度上，就好比是对个别员工的特殊奖励。其他员工会想，“既然经理跟他这么亲近，对我们这么疏远，想必我们没有什么价值”，这样团队的士气必然大打折扣。项目经理的同事朋友回头一想，也许会觉得“经理对我一个人这么好，肯定会引起其他人的不满，我还是离经理远一点才好”。这样一来，整个团队都会陷入不必要的困扰中。
一个和谐团队内部，员工之间会保持一种微妙的平衡，它源自项目组成员之间彼此平等、互相尊重的关系，以及相互之间的乐于接受的评价和看法。一旦组织内部出现某种特殊关系，这种平衡就会遭到破坏。
在项目中如果项目经理与个别员工建立亲密的朋友关系，这对其他人的思想观念会产生很大的冲击，搞不好就会其他人“三观尽毁”：
●对自己的看法
他们会想，是不是经理认为我能力差？我在团队是不是不重要？在考核或分配奖金时项目经理会不会也厚此薄彼？在被批评时，会想经理是不是有意对我刻薄？不行，看来没有前途，要走人了！
●对项目经理“朋友”的看法
那个家伙编程不怎么样嘛，有问题还不是问我？只会花言巧语，博得经理高兴。
●对项目经理看法
这个项目经理不怎么样，没有威信，喜欢听好话，跟着他干没前途。
也许那个下属确实能力超群，也许项目经理能够尽力把握公正与平衡，但这些不足以挽回项目经理因表面上“偏心”给团队带来在伤害。
很多公司为了提高凝聚力，宣称“员工是主人翁”、“公司是大家庭”等等，这得到无数人的认可。既然公司是家庭，那员工也就是家庭成员了，这样看起来员工与公司的关系应该非常亲密，员工之间也应该如同兄弟姐妹一般才对，那项目经理与员工怎么连朋友都做不得了呢？
作者在文中伤感的写道：“我突然想起来二战时某位著名将军说的话：“我让士兵上战场的时候，我会把他们想象成一堆蚂蚁，而不是人。因为我一想到他们有妻子、孩子、父母，我就不忍心让他们去送死。”不知道领导在讨论名单的时候，是把我们想象成蚂蚁吗？……我想，我比许多人都体会深刻。员工和公司的关系，就是利益关系，千万不要把公司当成家。”
大裁员是一件很惨烈的事情，但这不能怪公司，它的生存法则决定了它只能这么做。
通过联想这位员工与老板的对话，其实已经清楚的把员工与公司的关系说出来了，其实公司根本不是什么家，只是工作的地方而已，公司出钱请员工干活，就这么简单。柳传志说裁员是为了更好的以人为本，如果公司是家的话，那这就好比家长对孩子说：“为了让全家人都有饭吃，我只好把你仍掉了”，岂不荒谬？所以那些号称“公司是大家庭”的老板们，如果你们做不到永不裁员、永远要给员工生活的保障，那还是请你们自行撤下这虚伪的面具吧，因为没有哪个家庭会抛弃自己的兄弟和子女。作为员工，也必须清醒的认识到，你和公司之间就是一种利益关系，你是为自己工作，绝不是为了公司这个“家”。你之所以在这里工作，是双方利益的需要，绝不是感情的原因。柳传志所说的“考虑问题的角度不同”，其实质只是利益不同而已。
话已经说得很白了，看上去有点残酷。有些人觉得伤感，好像自己对公司的感情被一棒子打入冰窖，就好像一个活生生的人，突然失去了血肉、变成了骷髅一样。其实大可不必这么想。员工与公司有其相处的模式，只不过这种模式绝不是家庭模式，也不是朋友模式。我们应该坦然面对，细心揣摩，谨慎把握。
项目经理作为管理者，在与员工的相处中，他就代表着公司的利益，这个定位不能错。定位错了，一切都会跟着错。经理把员工当朋友，其实就是一种定位的错误，双方都应该明白这一点。
在处理好与骨干员工的关系方面，我有以下几条建议：
（1）让每个人都站在圆周上
也就是所有员都一视同仁。著名职业经理人唐骏的曾提出一个处理管理者与员工关系的“圆心理论”——公司所有的员工都是在圆的周边，管理者在圆心，这就是说管理者和每个员工的距离都是等距离的。
这种圆心距离是一种理想的上级和下级的关系，在这种模式下，团队内部保持了相对的平衡，员工一旦没有这样的平衡，就会有种危机，担心自己是否明天会失宠。这种圆心理论就是让大家感觉到每个人都有一样的机会，只有去努力，认真工作创造成绩才是真正的发展之道。
美学中有一个著名命题：“距离产生美”。人与人之间相处太近，反而不好，就像两只刺猬在一起，只有保持一定的距离，才会相安无事，当然也不可太远，否则就会没有温暖。
要保持这种距离，对项目经理而言，有几点需要特别注意：
●不把员工当作倾谈对象。不要跟员工讲你的感情生活，讲你的家庭生活细节等。
●不要和员工表达你的不满情绪，在员工面前，永远是积极的正面的形象。项目经理即使有千万个不满，也不要对员工说，而是与你的上级沟通。
●不要对某位员工表现出不一样的关系。例如，不要每天固定跟某一位员工一起外出就餐。
●项目经理言行要有“温度”，不可拒人于千里之外，显得不近人情。
（2）不要混淆了“情理法”的界限
我们大部分人都生活在三个圈子中，即亲友圈、职场圈和官场圈，相应的，我们为人处事的主要依据也依次分为情、理、法。也就是，在与家庭成员和朋友交往时，要讲感情；在公司工作时，要讲道理、以原则为导向；而对于有幸为官的人来说，那就凡事要以法律为准绳了。
图圈子与情理法
每个圈子都有其生存之道，三者都可以相互替代。在家庭和朋友中间，不要过去较真，什么都去讲理、讲法，否则家庭就会少了一份温暖，朋友之间就会多层隔阂；在官场，更加要收敛自己的感情，讲原则更要讲法，不管什么原则，如果与法相违背，也不能作为办事的准则。职场有职场的规则，它介于家庭和官场之间，工作中要适当讲情，但不能为情所左右，也要讲法，但法不是主旋律，职场中最重要的还是理。
中国人往往将情理法相混淆不清，该讲感情的地方过于严苛，该讲理和法的地方，却总掺和过多的感情因素，说什么“人情大过天”，视规则如无物，这该引起我们的深思。
（3）要保持管理者的“威严”
无疑管理者应当要有威严。没有威严，则难以获得员工的敬重，指令也不会畅达，甚至有令不行，领导力也就无从谈起。
所谓威严，也就是威信、严格。管理者要保持威严，必须要与员工保持适当的距离，特别要注意不要随便和员工开玩笑、讲黄段子或调侃其他人等。孔子说过一句话：“临之以庄，则敬。”意思就是说，领导者不要和下属过分亲近，要与他们保持一定的距离，给下属一个庄重的面孔，这样就可以获得他们的尊敬。
保持威严也有一个度的问题，不要一不小心把它变成了威风、严厉，甚至走向了反面，变得不近人情。一个优秀的管理者应该是威而不凶，严而不苛。
（4）工作不能讲感情，但要有“人情味”
既然人是有感情的动物，那为什么不能讲感情呢？注意，这里说的“讲感情”，是指做事以感情为导向，被感情所左右，这是工作的大忌。
那管理者与员工之间只能有冰冷的利益关系吗？也不是这样，感情是让团队产生凝聚力的“粘合剂”，管理者在工作中不能讲感情，但是应该要有“人情味”。一个没有人情味的人，不会有人愿意和他交往，一个没有人情味的公司，也不会有员工乐于为它服务。因此作为项目经理，一定要打好感情这张牌，做一个有风度、也有温度的管理者。
项目经理有很多地方可以做得更有人情味，比如：
●体谅员工家庭难处。例如有些员工因为家庭原因，不能出差，项目经理要体谅，不可强求；
●员工身体不适住院，可以去医院看望；
●员工结婚生子，可以送上自己的祝福；
●员工生日可以组织一起聚餐；
●员工家庭困难、遭遇变故可以组织爱心捐款等。
管理者应该更多的去关心员工，这与和员工保持距离两者并不矛盾。哪怕你做了一件只对某个或几个员工的关爱小事，其他员工也会觉得他们受到了关爱，因为大家都是等同的，或者说下一个受到关爱的也许就是他。这是一种一视同仁的关爱，员工不但不会“吃醋”，而且会感觉到内心温暖。
（5）信任员工代替做朋友
对于骨干员工而言，如果你想笼络他，最好的方法就是信任他，并对他委以重任，例如请他在项目中担任小组长。对于他所负责的工作，在目标明确的前提下，不要过多的干预，如果不存在大的偏差，只需稍加过问即可。对员工的不足，也应该委婉的加以提点，这也信任的一种方式。
每个人都会有缺点和不足，作为管理者，如果总想改造属下员工，这是一种不切实际的做法，因为每个人都是一个有思想的个体，只能由内而外的改变。每个人都有其用武之地，项目经理与其费尽心力改造员工，还不如多想想如何利用现在的他。
1.每个人只能由内而外的改变
世界上没有完美的人，程序员也一样，也会存在这样那样的不足。项目经理要想找到一个觉得真正“好用”的人并不容易，如何对待程序员的缺点，是每一个项目经理都需要认真思考的问题。
有些项目经理面对程序员的缺点时，会显得过于急躁，恨铁不成钢。有的程序员思维比较迟钝，什么问题都需要一次次反复沟通确认，项目经理批评他们：“你怎么理解能力怎么这么差！回去看看逻辑的书。”有的人做事慢手慢脚，怎么急也急不来，项目经理忍不住说：“怎么这么简单活也干不了，不就是….这么简单的事情吗”；有的人则什么事都要提出一堆质疑，项目经理要开骂了：“你怎么这么烦！好好想想吧，想过了再来问”。有的人与客户谈了半天，也说不出个所以然，项目经理急得直冒汗，强忍着怒火才没有当着客户的面发飙。
项目经理着急可以理解，无非是希望通过批评的方式给员工施压，以给他们成长的动力。但最后却发现这样的方式无济于事。
面对员工的缺点，很多管理者出于爱才、培养人才的目的，给予过多的提醒、教导、批评、甚至发脾气。其实一个人要改变自己都很困难，想要改变别人多半只是一种徒劳。
联想一下父母对我们的教导。父母不厌其烦的教导我们各种知识、做人的道理，听多了以后就变成唠叨，对个人根本不能产生什么影响。这是因为别人的经验成不了自己的经验，一个人有经验必须要靠自己亲身经历去获得。当别人告诉你玫瑰花好美好香时，如果你没有亲见，你是不会有感觉的，只有你自己用眼睛看到它的鲜艳、用鼻子闻到它的芳香、用手触摸到它的湿润，你对玫瑰花的认识才能成为你自己的经验，内化为你自己的知识。
大部分人只有自己亲身经历了挫折以后，才能真正的成长。每个人的成长就是一个不断犯错的过程，作为一个管理者，固然有提醒和教导的必要，但无需为此伤神。如果过于急躁，一心想快点把员工改造好，这只会让自己失去了耐心，进一步会导致员工也很厌烦，甚至故意避开项目经理，以免难堪。因此，项目经理必须要学会适当的容忍员工的错误，其实这样才是他们真正的给了他们成长的机会。
再退一步讲，员工在公司其实只是打一份工，并不是来改造自己。项目经理没有义务也没有权利要求一个人改变，而只能是用好现在的他。合则继续，不合则分手，就这么简单。成长是一个人要获得发展的内在需求，而不是管理者的外在要求。
美国作家弗格森有一句名言：“谁也无法说服他人改变。我们每个人都守着一扇只能从内开启的改变之门，不论动之以情或说之以理，我们都不能替别人开门。”项目经理不要再苦心孤诣的想要改变你的员工了，否则就可能像拔苗助长的故事中讲的那样，一番好意反倒害了别人。
2.怎样培养员工
每个人只能由内而外的改变，并不是意味着管理者对员工存在的问题完全置之不理，而是应该采用更加科学的方法来培养员工。
（1）像教育孩子一样培养员工
中国父母教育孩子的传统方式有两个重要的误区：
一是模具教育。中国父母教育小孩的一贯方式，就是规定一定要这样、一定要那样，或者这个不能干、那个不能干，父母给孩子划定了各种界限，就像模具一样，孩子只能按照这个模具的形状来生长。这只会让孩子的天性得不到发挥，最终会引起孩子的逆反心理。
第二是填鸭式教育。父母让孩子上各种培训班，不分昼夜灌输各种科学文化知识，不管小孩能不能接受，更不问小孩是否感兴趣。这种把知识硬生生灌到肚子里的教育方式，小孩难免会出现“消化不良”，最后反倒可能会“身体虚弱”。
这两个误区都是不尊重人的本性和人的成长规律的表现。国际上有一种被广泛认同的教育理念，叫做华德福教育。在这种理念中，每个小孩都像一棵小树苗，他具有自我成长的能力，父母应该做的，不应该是去拔树苗、剪树枝，而是为孩子营造良好的成长氛围，提供适合孩子成长的土壤。
虽然讲的是孩子的教育，其实我们完全可以采用相同的理念来培养员工。在一个公司里面，管理者要让员工获得成长，其首要的任务不是机械的告诉员工你应该怎么样做，而是营造良好的团队氛围，打造适合员工成长的土壤，让员工自己成长。
团队具有积极向上的氛围，更能激发员工活力，知识就好比土壤中的养分一样，可以在其中流动，每位员工可以接收到这种养份。而在一个死气沉沉的团队中，每个员工都是一个闭塞的能量体，知识被封闭其中，外面的难以进来，里面的也出不去。项目经理要做的主要工作，就是这将些封闭和能量体连接起来，让能量自由流动，这样每个人都能获得最大的成长。
（2）要区别对待员工的不足
营造氛围固然重要，但对员工存在的不足，我们也不能视而不见。对于员工不同类型的问题，应该采取不同的措施。
●技能欠缺的问题
公司出于人才梯队建设的考虑，必然会经常招聘经验比较欠缺的新员工，他们往往会被安排到项目中进行锻炼。即使是老员工，面对新业务，或者新技术，也同样会一时难以胜任。面对这种问题，项目经理应当主动面对，加强对员工的培训和辅导，必要时可以定期举行内部技术交流，通过互相学习，不但技能获得较大的进步，而且团队的氛围更加活跃，员工更加主动，项目组更加具有凝聚力。
●性格与态度问题
员工性格缺陷或态度消极，常常导致其做出不当的行为，这是令项目经理最痛苦的地方，也是项目经理想要改造员工的地方。但是俗话说，响鼓不用重槌敲，不响的鼓你敲破了也没用。与其严厉的说教、批评，还不如只进行适当的提点，给双方都留有余地，这样可能会更有效果。
顾名思义，提点也就是提醒、点拨。一般情况下，提醒即可，对于重要的问题，则进行点拨，项目经理尽到自己的责任即可。项目经理确实有责任带领员工一起进步，但绝不是要改造他。
对员工行为不当的原因，要进行针对性的分析，区分是外在的因素，还是其性格使然，也就是要看问题出在谁身上，根据实际情况想办法。例如，有些人喜欢和项目经理对着干，有可能是项目经理自身的原因，比如项目经理过于固执、自以为是，不顾及员工感受等。这种情况下项目经理要自我检讨，自我改变。还有可能是综合原因，例如员工待遇偏低，心里不爽，以跟项目经理消极对抗的形式发泄出来。这时项目经理需要对员工的能力和薪资进行分析、评估，设身处地考虑员工感受，帮助员工争取合理的利益。
●正确看待员工特点
人有千百种，很多事情并没有对错之分。有些问题看似是员工的不足，其实换一个角度来看，它就是一个人的特点而已，要以平和心对待。例如员工不善言辞、理解力差，表面上看是缺点，实际上更是他的特点，这就好比软件的设计特性一样，不能算是Bug。一个人的特点是上帝的设计，不是项目经理可以改造的。
3.每个人都有用武之地
李白有一句诗：“天生我才必有用”，这不只是对我们每个人的鼓励，也是在提醒项目经理，要学会用人。
一个优秀的管理者会因材施用。既然每个人都有用，那我们就应该顺应他的特点，发挥他的长处，何必非要盯着他不足的地方呢？
相信大家都见过根雕。好的根雕作品应该是顺应树根的形状进行设计和雕琢，它们往往让人惊讶于大自然的神奇和艺术家的想象力。试想如果对树根进行刀砍斧斫，把它的棱棱角角都削平，搞得很光滑，你摸上去倒是很舒服，但这样反倒失去了其艺术性。
我还曾经看到这样的介绍，画家在纸上随便倒一片墨，然后顺应墨迹对作品进构思，随兴作画，最后整个作品浑然一体，成为精美的艺术品。其实每个人就像被滴了一团墨的白纸，如果想要擦掉这一团墨，最后的结果就是，白纸被擦出一个无法弥补的大洞。
可见，无论是看似歪瓜裂枣的树根，还是奇形怪状的墨滴，在一个艺术家的眼里，都有其独特的价值。
人不也是这样的吗？每个人都有自己的特点，不管是什么样的人才，在善于驾驭的管理者那里，都可以人尽其才，为团队做出相应的贡献。这也是一种艺术。
在项目中，也会有各种不同性格、不同特点的人。与其把精力花在怎样改善员工的不足，不如用其所长。无需改变他，同样可以把他们用好。
管理专家余世维对于如何用人所长，曾举过一段非常精辟的例子：
受余世维的启发，在项目中我们同样可以做到因材施用，例如：
●喜欢提意见的人，可以让也负责质量管理。
●能说会道的人，可以让他负责与客户沟通；
●沉默寡言者，一般心思缜密，可以负责技术性较强的工作；
●对于脾气倔强的人，应该安排确定性的、没有争议的工作交给他；
●思维敏捷的人，可以安排紧急的任务给他。
总之，项目经理应该顺应一个人的特点来安排工作，而不是强人所难，这样才能将团队的力量发挥到最大。
船在大海上航行，需要灯塔的指引。目标就是项目中灯塔。在项目中，目标不但可以指引方向，还可以凝聚人心。
1.把员工团结在目标下面
不善于给工作制定目标的管理者不是优秀的管理者，没有目标的团队也不能称之为团队。一个合适的目标，可以将员工紧紧的凝聚在一起，产生强大的力量。因此，项目经理必须要学会利用这一点，让员工为目标干活，将员工团结在目标下面。
无论是对个人，还是对组织，目标的重要性都不言而喻。为了“实现共产主义”这一伟大目标，无数革命先烈抛头颅、洒热血，献出了自己宝贵的生命，由此可见目标的具大作用。
目标也是一个团队的基本特征。管理学中对团队的一般定义是：“团队是由员工和管理层组成的一个共同体，它合理利用每一个成员的知识和技能协同工作，解决问题，达到共同的目标。团队的构成要素总结为5P，分别为目标、人、定位、权限、计划。”由此可见，要成为一个团队，首先是要有一个共同的目标，否则就不能算做团队，顶多只能叫做“一群人”。
项目也是这样，没有明确的目标，项目经理的领导力也就成了无源之水，项目组也会成为一群“乌合之众”。
（2）领导员工要拉不要推
桌子上放着一根绳子，怎样才能让绳子向前移动呢？你如果向前推，绳子就会拧成一团，它就不是原来的绳子了，最好的办法是把绳子向前面拉。
一个人工作的动力，同样可以分为推力和拉力。项目经理批评、督促员工，这是一种推力，它是一种外在的力；激励员工、给员工制定目标，这是一种拉力，拉力则是一种自我驱动的内在力量。其实人就像绳子一样，是柔软的，这种柔软来自于人内在的思想和感情。对于这种柔软的东西，“拉”显然是一种更加明智的做法。
项目中如果员工的主要动力是推力的话，其工作也就没有什么积极性，项目经理也会觉得自己非常辛苦，却没有成效。因此，项目经理要想轻松一点的话，最后的办法就是改变思路，不要在后面推员工，而是要在前面给员工施加拉力。
拉力主要有两种，一是来自于员工的自我激励，二是靠管理者的激励。为员工制定合适的工作目标实际上是引发员工的自我激励的一种方法，如果员工连要达到什么目标都不知道，那他又拿什么来激励自己呢？
（3）让员工为目标干活
在一个具有超强个人魅力的项目经理的团队中，员工干活的动力很可能是来自项目经理的吸引力，也就是为项目经理而干活。如果换一个项目经理的话，员工的干劲就可能会一落千丈。这样的项目经理就好比是一块磁铁，员工就好比是被磁铁吸引的螺丝钉，现在把磁铁拿走了，螺丝钉们自然就会像一盘散沙。
阿里巴巴公司的创始人马云曾经说过：“不要让你的同事为你干活，而让我们的同事为我们的目标干活，共同努力，团结在一个共同的目标下面，要比团结在你一个企业家底下容易得多。所以首先要说服大家认同共同的理想，而不是让大家来为你干活。”
马云也是这样做的。虽然他本人具有非凡的个人魅力，但他更加重视目标的作用。从阿里巴巴创业之初，马云就定下了做中国最大的电子商务公司的目标，碰到千难万险也从不放弃。阿里巴巴能有今天的成就，可以说跟当初的目标是密不可分的。
一个企业需要目标，一个项目同样需要目标。事实上，项目比企业更加具有目标性，一个项目组也正是因为要完成某一目标而成立的，在招标文件或者合同中往往也会明确写着这些目标。项目经理要做的，就是认真评估这些目标，根据实际情况进行必要的调整和细化，让目标代替项目经理，成为将员工吸引在一起的磁铁，将项目组紧紧团结在一起。
2.项目目标的制定
对公司领导而言，项目目标就是对项目经理考核的指标；对项目经理而言，项目目标是愿景、是动力、是手段、更是项目团队的信用，所以项目经理必须谨慎制定项目目标。
（1）制定项目目标的三种方式
项目目标一般在项目章程或项目任务书或项目立项书中进行确定。项目目标的制定有自上而下、自下而上以及双方共同制定三种方式，这几种方式也体现了公司之间文化氛围的差异。
l自上而下
即项目目标由上司制定，直接下发给项目组。领导在制定目标时，总是希望越高越好，他们相信有压力才会有动力，员工才会拼命的往前赶。他们常见的做法是质量和进度要求直接与合同保持一致，而成本限制往往是合同金额按一定比例计算出来的。这一类型的工作公司往往管理层过于强势和精明，氛围比较紧张，员工的压力比较交大。
l自下而上
由项目组制定后，交给公司领导层进行审批。这种公司的管理层一般比较温和，公司气氛也比较缓和。
l双方共同制定
一般由公司或项目组先制定一份初始的目标，然后根据项目的实际情况，公司和项目组一起进行分析讨论确定。这种公司的氛围一般比较民主化，能够具体问题具体分析，尊重员工的意见。
当然还有的一些运作比较粗放的公司，根本就不会去制定明确的项目目标，也没有项目章程或项目任务书之类的文件。一般直接按照合同要求开展工作，有问题时双方进行口头沟通。
（2）制定项目目标应注意的两大问题
l目标必须是现实可行的
因此在制定目标的过程中，项目经理必须争取自己的话语权，认真分析目标的可行性，充分考虑项目中可能存在的问题和风险，并就双方差异主动与领导进行沟通，力求达成一致。试想，假如等到项目开展到后半段，项目经理才发现原来的目标有很多不切实际的地方，比如工作量与想象的有太大出入，质量要求过于苛刻，费用预算完全是拍脑袋，如果这个时候项目经理才提出目标不科学，将责任推给公司领导，只会让领导更加觉得项目经理无能、没有担当。
有些人担心，这样“讨价还价”领导会不会嫌我烦？确实有个别领导不喜欢员工提出异议，觉得他在讲条件、不听指挥，但大部分领导还是乐于与项目经理讨论这些问题的，因为这说明项目经理对项目有全面系统的思考，重要细节都已经考虑过了，这样做事领导会更加放心。公司最怕的不是挑剔的项目经理，而是没有想法的项目经理。
对于质量和进度目标，由于涉及到客户方的直接利益，如果经过评估确实需要变更，还必须与客户和监理等方面进行沟通，确保各方的认识一致。
l目标必须获得所有人认同
一个目标可以要想将员工团结起来，把大家凝聚在一起，还必须获得项目团队的认同。
项目中经常出现这样的情况，项目经理和上级领导确定目标后，项目经理将目标通知给大家，也不理会员工的意见。等到目标眼看无法完成的时候，项目经理对员工“兴师问罪”，员工会理直气壮的说，我当就说过这个目标不可能实现的。这是一个项目目标没有获得员工认同的典型例子，项目经理等于复制了公司对项目“拍脑袋”的决策模式，是一种不负责任的做法。要想得大家的认同，最好的办法就是让员工直接参与评估和制定项目目标。
（3）团队目标与个人目标
在一个组织中目标可以分为团队目标和个人目标两个层次。团队目标确定以后，项目经理需要根据具体的工作任务、团队成员的构成情况，对目标进行分解，最后形成每个员工的个人目标，从而实现个人目标与团队目标的统一。
图项目目标的层次性
3.弗洛姆“期望理论”的启发
斯大林所曾说过：“伟大的目标产生伟大的动力。”那么一个具体目标对员工究生能产生多大的动力呢？
著名心理学家弗洛姆曾提出一种激励员工的理论，认为“某一活动对于调动某一人的积极性，激发出人的内部潜力的激励的强度，取决于达成目标后对于满足个人的需要的价值的大小与他根据以往的经验进行判断能导致该结果的概率”，用公式来表示就是：
目标的激励力=目标的价值×能实现目标的概率
根据这一理论，我们可以得到以下几点启发：
（1）目标要适当
从公式中我们可以看到，目标的激励力与目标的价值是成正比的，因此在给员工安排工作任务时，可以尽量将目标设定得适当的高一点，让其更具有挑战性。
美国行为学家吉格勒认为：“设定一个高目标就等于达到了目标的一部分。”由此可见，给员工设置一个具有挑战性的目标是非常有必要的。适当的提高目标，可以激发员工的工作热情，增强其抗压能力，而且当工作目标完成时，会更加具有成就感。
然而必须注意的是，上述公式中的两大自变量，即目标的价值、能实现目标的概率两者这间本身也存在一定的函数关系。当目标较低时，实现概率为1，也就是说，员工信心十足，认为完全可以实现；当目标逐渐升高，超过某个点时，实现的概率又逐降低。两者的变化关系如下图所示：
图预期实现概率与目标价值之间的关系
相应的，目标的激励力与目标价值之间的关系也可以用下图来表示：
图目标的激励力与目标价值之间的关系
因此目标不能定得过高，否则“预期的实现概率”将会迅速减小，到达某一临界点后，目标对员工的激励力也会随之降低。
图中有A、B两个点，其中A点是能够完全实的最大目标值，但项目经理给员工安排工作时的最佳点还不在这里，因为此时“目标的激励力”这一变量，要到B点才能达到最大值，这也就是为什么管理专家们建议安排工作时要让员工“跳一跳能够得着”的原因。
（2）改变个人对概率的预期
上面的图只是简单的数学模拟，实际上预期实现概率是一个主观的因素，它与目标的难度固然存在较强的关联，但其本身又受其它诸多因素的影响。项目经理利用这一点，可以通过对员工的引导，提升他对实现概率的预期，从而提高其工作的动力。
要提升员工对实现概率预期，实际上就是提升员工对工作的信心。要实现这一点，项目经理可以做很多工作，例如：
l把客户的肯定、领导的表扬及时传递给员工；
l使员工对目标保持谨慎乐观。如果过于乐观，就会觉得太容易，放松工作要求；
l让工作井井有条，员工看到一切都有条不紊的进行，会觉得一切都在计划之中，其信心自然大大增强；
l加强项目控制，让员工感受到目标正在一步步靠近；
l让员工及时看到整个团队的工作成果；
l项目经理要展示自己的能力、活力和信心，员工首先要对项目经理充满信心，才能对工作充满信心；
l帮助员工克服困难，实现目标。
4.目标是一种承诺
为什么要让目标获得团队的认同？一个重要原因就是获得员工的承诺。当员工接受并认可工作安排的时候，其实就是做出了一种承诺：我承诺按照目标的要求，及时保质保量的完成任务。一个人一旦做出承诺，就会想办法去实现自己的承诺，这是一种内在的力量，可以促使其自主自发的完成任务，达到目标。