从程序员到项目经理

转自：点击打开链接

　　“从程序员到项目经理”，这个标题让我想起了很久以前一本书的名字《从Javascript到Java》。然而，从Javascript到Java充其量只是工具的更新，而从程序员到项目经理，却是一个脱胎换骨的过程。从Javascript到Java，是一个取巧的方法；而从程序员到项目经理，却并无捷径可走，必须从内而外的改变和提升。

一、为什么要当项目经理

　　1、问题本质

　　如果我对一个老程序员说：“有必要转项目经理啦”，很多人第一反应是“为什么一定要当项目经理？！”，反问很给力，基至会让人哑口无言。但反问成功的结果可能只是使自己麻醉，暂时忘却现实中面临的烦恼和压力，这无异于把头埋进沙子中的鸵鸟。只有理智的分析，才能作为自己行动的指南。

　　首先申明，不是每个程序员都需要当项目经理，也不是每个程序员都想当项目经理，更不是每个程序员都能当项目经理。因此，当不当项目经理，可以说是一个“需不需要、想不想、能不能”的问题。

　　想不想，是一个意愿的问题。这是前提，毕竟强扭的瓜不甜嘛。显然，富二代一般是不想当项目经理的，因为他们想直接当总裁。还有些人，只想钻研技术，不想钻研人，他们也是不会想当项目经理的。如果你没有意愿当项目经理，也就没有讨论的必要了。什么，你不知道想不想？呃，那就继续往下读吧，也许读着读着，你就想当了。

　　能不能，是能力的问题。这是不关键，因为只要有意愿，能力是可以培养的。程序员连复杂得让人琢磨不透的软件都能搞定，还有什么搞不定的？

　　因此最后落实在需不需要这个问题上。这个问题很棘手，需要从程序员自身以及外部环境等方面进行分析。要讨论这个问题，就要弄清楚它和想不想的关系。想和需要是紧密相关的，但并不是一回事。想不想，主是感情的因素，而需不需要则要进行理智的分析的了。理智与感情，并不总是一致的。有些东西，是你需要的，但你未必想要。比如，被困沙漠的时候，有时被逼喝自己的尿液，这是理智战胜了感情。电影《色戒》中的汤唯，则是感情战胜了理智，爱上了敌人，最后造成了悲剧的结局。因此，我们还是少说气话了，不要冲动，冷静的分析自己的处境吧。

　　2、鸭梨山大

　　当我从网上看到码农这个词时，觉得网民很有自嘲精神，后来我看到了码畜和码奴这个两个词，不禁从心底涌起了深深的悲哀，为这个行业，也为这个社会。

　　看看智慧的网民对IT人士级别的划分：

IT领袖：年入过亿（例如任正非、马化腾、李彦宏、丁磊、马云等，包括期权股票以及投资理财等收入。）

IT大哥：年入千万（级别次于以上几位大佬的公司老板，不缺钱，普遍对上一条里的人物羡慕嫉妒恨。）

IT精英：年入百万（各IT公司副总裁级别人物，包括COO、CTO等，大多为职业经理人，赚够钱就跑。）

IT人才：年入50万（各IT公司总监级别人物，有房有车，生活压力相对较小）

IT工程师：年入20万（高级经理级别，有房贷，生活压力大）

IT民工：年入10万（经理级别，基本无房，学会装波一，生活压力大）

码农：年入6万到10万（工作三四年，租房，继续混日子）

码奴：年入3万到6万（工作一两年，租房，混日子）

码畜：年入低于3万（刚毕业的，租房，傻乐）

　　我知道你想问什么问题了。不要问哥赚多少，哥只是一个普通的IT人士而已。前面三级都是牛人，是成功人士，他们的作用不是让去成为他们，而是激励我们自己。你现在读到的也不是一篇成功学的文章，而是和你一起分析程序员的处境、以及怎样缓解压力的文章罢了。

　　言归正传。看到这个表，是不是有鸭梨山大的感觉。找到了自己的位置吗？什么，不好意思？没关系啦，园子里面不是很多人称自己为程序猿或者猴子吗？那大概也就是相当于码畜吧。我想能读到这篇文章的，大概都是“IT工程师（高级经理）”以下,他们的主要特征是“生活压力大”和“混日子”。如是你是前面四级，建议你果断退出本文。

　　我在上一篇博文中提到30岁现象，有些人认为车到山前必有路，这是杞人忧天。不错，程序员确实可以干到30多岁，甚至四五十岁，但他们面临的压力却可能是“不足与外人道也”。

　　我经常与30岁以上的程序员交流，他们流露出来的对现状的不满、无奈、无力、对安全感的缺乏，让我感同身受。

　　虽然谈压力并不是一件愉快的事情，但我仍然必须要说出来，因为我宁可清醒的痛着，也不要在麻醉中睡去。那就让我们拿着手术刀，对自己进行痛苦的解剖吧。

　　下面是一个简单的“危机评估表”，总共有30项。在“是否认同”后面打出分数，每一项如果认同为1分，不认同为0分。

类别

评估项

是否认同

身体

悄然发现已经没有以前经折腾了。

 

没有定期的体育运动。

 

中餐午餐都是在外面吃快餐。

 

确信自己是亚健康。

 

家庭

每月开支不算不知道，一算吓一跳。

 

有房贷或房租。

 

有孩子了，上幼儿园是一笔大开支。或者超过30岁了还没结婚。

 

买不起车，或有车子，开不起。

 

家里时有摩擦，经常有不开心的事。

 

每个月存不了多少钱。

 

时间

要花很多时间陪家庭成员。

 

加班时间越来越少。

 

社交时间较少。

 

激情

只想休息，不想工作。

 

对新技术、新工具不甚了解，有心无力。

 

没有制度明确的短期、中期和长期目标。

 

理想已经模糊了。

 

社会

只有交税，没有回报。

 

担心老了病无所依，老无所养。

 

担心国家经济衰退，陷入失业。

 

收入增长跟不上通货膨胀的速度。

 

行业

新人比我更具有性价比。

 

行业竞争激烈，低价抢标现象严重。

 

行业被某些公司垄断。

 

行业正在慢慢衰落。

 

公司

公司发展前景不是很明朗。

 

公司薪资福利一般。

 

公司没有企业文化。

 

公司员工关系比较紧张，有内斗现象。

 

公司缺乏活力。

 

总分

 

　　（说明：此表并不精确，仅供参考）

　　如果总分小于10分，那要恭喜你，说明你生活稳定幸福，让人羡慕。我觉得这篇文章你也不用往下看了。

　　如果你的总分大于20分，说明你承受的压力过大，可能面临职业方面的危机，应当寻求改变了。

　　如果总分在10-20分，说明你生活比较稳定，收入方面可能是中上等水平，但职业发展方面仍有风险。

　　3、另一片天地

　　所谓“穷则变、变则通”，如果你还是普通的老程序员，并且还在为自己的职业彷徨和苦闷，那就应该寻求变化之道了。

　　如果你愿意，转向项目管理乃是上上之策。

　　当然转项目管理只是程序员很多选择中的一个。显然不是每个程序员都需要当项目经理。一般每个公司都最少提供了技术和管理两条职业发展通道，如果你技术超牛，你完全可以从程序员做到系统分析师，一直做到技术总监。如果技术方面你信心不足，转项目管理就是一件自然而然的事情了。

　　技术和管理，这是两条绝然不同的路，虽然“条条大路通罗马”，但沿途的风景却是完全不一样。一旦你从事了项目管理，你将看到不同的另一片天地。

　　（1）在管理的天地里，你将不再有职业瓶颈。

　　程序员虽然也可以干一辈子，但工资水平是有天花板的，不要问我为什么，行业就是这样。项目经理则有无限上升的空间，不但工资更高，职位上也可以升至部门经理、副总经理甚至总经理职位。

　　（2）促进项目经理内在成长，心智更加成熟。

　　美国项目管理协会PMI认为，项目经理75%-90%的时间应该用在沟通上。沟通的对象显然是人，因此，项目管理主是要一项与人打交道的工作。如果说解决技术问题人主要是靠一个人的智商，那么与人打交道，则是要靠一个人的情商。

　　虽然不当项目经理也可以发展情商，但在项目中锻炼是自我成长、自我完善的捷径。

　　（3）项目管理知识可以用在生活中的各个方面。

　　生活中的许多事情，我们并没有称之为一个项目，但可以用项目管理的方法来对待。例如一次婚礼的组织，或一次自助旅游。你在项目管理中培养起来的情商，更是让你面对生活中的各种问题游刃有余，你的家庭也会更家和谐，就像范范的一首歌里唱的：“好像什么困境都知道该怎么办”。当到达这种境界时，你会有一种海阔天高，一览众山小的感觉。

　　因此，即使你不想从事项目管理，也建议你学习一下项目管理知识。有一本书叫《不懂项目管理，还敢拼职场》，虽然觉得内容一般，但对标题深以为然。

二、项目管理倒底难不难

　　程序员问：“我现在想当项目经理，但心里没底，不知道项目管理到底难不难？”这个问题确实不好回答。俗话说，“会者不难、难者不会”，很多事情都是如此。

　　有些人觉得不难，他们好像天生就具有管理的才能，他们举止得体、八面玲珑，具有很强的个人魅力，可以把大事化成小事，把坏事变成好事。这样的人，想不成功都难。

　　大部分人还是会觉得难。在PMI的知识体系里，项目管理有九大领域，五大过程组，44个过程，有数不清的工具和方法。项目执行中方方面面出了问题，都是项目经理的责任，项目经理又不是超人，怎么应付得过来。项目管理确实有点难。

　　你若问我，我会说项目管理既难，又不难。对于愿意改变自己的人而言，它不难；对于性格偏执的人而言，项目管理确实太难了。

　　很多人无法意识到自己的偏执。上级只要提出一点批评，他们就要拼命的辩解和反驳。他们的保护壳太厚了。

　　项目经理最重要的素质，就是心智的成熟，一个心智成熟的人，不会是一个偏执的人。

　　毕竟，人无完人，项目经理必须从善如流，才能完成自己角色的转变。对于从程序员转过来的项目经理，做事的方法与以前应是翻天覆地的不同，必须迅速审时夺势，改变自己。否则，那你不还只是个有项目经理职位的程序员么？

　　因此可以说，项目管理难就难在项目经理要改变自己。这个改变，不只是知识体系的扩充，更可能是性格的改变，而一个人要改变性格是极其困难的。

　　程序员习惯于与机器打交道，通过严密的代码和逻辑来控制机器；而项目经理是跟人打交道，人是有感情的，绝对不是你给他输入1+1，他就给你输出2。项目经理必须时时用心去思考、体会，然后改进。几番回合下来，项目经理会惊喜的发现自己变了，有种脱胎换骨的感觉----那是当然的，因为变得更成熟了。

　　只要你愿意改变自己，假以时日，你一定会成为一个优秀的项目经理。

三、程序员应克服的障碍

　　程序员与项目经理之间，往往有一条鸿沟。对技术钻研越深的程序员，这条鸿沟可能越大。这是由程序员的性格特征决定的。

　　程序员普遍有非常多的优点：例如聪明、逻辑思维强、学习能力强、创新能力强、直率等。但优点往往也是弱点之所在，例如：

　　（1）太讲逻辑：与人相处时容易忽视人际关系、感情等方面的因素。

　　（2）过于直率：说话直来直去，容易伤害他人感情。

　　（3）自傲：总觉得自己技术不错、比周围的人要强一点。好比一只鸡看到同类觉得自己最大，看到鹅觉得跟自己差不多，看到火鸡才觉得比自己大一点。

　　（4）固执：在自己的逻辑中不能自拔，无法听取别人的意见。

　　（5）沟通能力较弱：大部分程序员在口头表达、写作、汇报、交流等方面存在不足。

　　而这些缺点，也是心智不够成熟有表现，这是项目经理的大忌，往往会成为程序员晋升项目经理的障碍。因此，必须要克服这些障碍，给自己制定符合项目经理要求的行为准则，时时提醒自己，每日进行反省，坚持下去，必然会成功。

被任命为项目经理，是职业生涯的第一次飞跃，既惊喜又紧张。从现在开始，你要思考怎样才能胜任项目管理的工作，否则等着你的，很可能是一场悲剧。

一、升职之辨

　　1、为什么是我

　　不是每个人都能当项目经理，程序员中只有一小部分能成为项目经理，大部分人会随着岁月的流逝，成为了“资深程序员”。

　　那为什么领导要选择我呢？一般人对自己所拥有的东西都会很快习以为常，认为这是自己应得的。一点也没错，这就是你应得的，原因也很简单，那是因为你比别人优秀一点。

　　其实领导挑选人才的标准很简单，那就是你比别人优秀，而且只需一点点。你不需要“鹤立鸡群”，“鸭立鸡群”已经足够了。俗话说：“群众的眼睛是雪亮的”，其实领导眼睛才是真正雪亮的，如果他还没有发现你，那是因为你还不够优秀，没有引起他的注意。

　　因此，如果你工作多年仍然没有职位上升，不要埋怨公司不给你机会，而应该从自己身上找原因，机会只会给有准备的人。如果你不知道自己准备好了没有，就试着回答下面的问题吧：

• 工作是不是比别人积极主动一点；
• 加班是不是比别人多一点（如果贵公司喜欢员工加班的话）；
• 提交成果是不是比别人提前一点；
• 成果质量是不是比别人要好一点；
• 学习是不是比别人勤奋一点；
• 面对问题是不是比别人勇敢和执着一点；
• 人际关系是不是更和谐一点。

　　如果你能做到这些，相信机会迟早会属于你的。

　　2、彼得定律的启发

　　心理学中有一个词，叫“光环效应”，是说当我们对一个人某个方面有好的印象时，我们会倾向于认为他的其他方面也是好的。因此，当你能胜任你现有职位、比别人优秀一点时，领导会认为你是下一个职位的最佳人选。然而实际上，你不一定是最合适的，但有什么关系呢，你已经是项目经理了，你有很多时间，可以边做边学。但是，如是你长期不胜任项目管理工作，项目经理就会成为你职业生涯的最高职位。

　　这也就是彼得定律的内涵：“在一个等级制度中，每个员工趋向于上升到他所不能胜任的职位”。

　　从彼得定律中，我们可以得到以下启发：

　　（1）在公司里面，大部分人都干着他不能胜任的事情。这听起来真是一个悲剧，好在我们暂时还不用操心。

　　（2）金子是一定会发光的，人才绝对不会被埋没的。这是由于人才的稀缺性造成的，只要是胜任当前职位，晋升是迟早的事。因此，无论是程序员还是项目经理，都要做好你的本职工作，这才是最重要的。试想，如果本职工作都没做好，怎么可能提拔到更高职位呢？别告诉我还可以走后门。

　　（3）当上了项目经理，只是说明你可以胜任程序员职位，而不意味着你可以胜任项目经理。因此，别急着庆祝，还是多想想怎么来管项目的事情吧，否则你就可能是下一场悲剧的主角。

　　（4）如果你已经担任项目经理很长时间，还没有得到升迁，不要骂老板，这只是说明你没有完全胜任项目经理的职位，还是赶快想想怎样完善自我，提升内功吧。

二、新任项目经理的误区

　　新任项目经理，由于经验和知识储备的不足，往往会出现相同类型的问题。

　　1、农夫的一天

　　有一个小故事，讲的是一个农夫的一天：

　　有一个农夫一早起来，告诉妻子说要去耕田，当他走到40号田地时，却发现耕耘机没有油了；原本打算立刻要去加油的，突然想到家里的三四只猪还没有喂，于是转回家去；经过仓库时，望见旁边有几只马铃薯，他想起马铃薯可能正在发芽，于是又走到马铃薯田去；路途中经过木材堆，又记起家中需要一些柴火；正当要去取柴的时候，看见了一只生病的鸡躺在地上……这样来来回回跑了几趟，这个农夫从早上到夕阳西下，油也没有加，猪也没有喂，田也没耕，最后什么事也没做好。

　　故事看上去很可笑，但笑过之后，回过头思索一下，故事里是不是也有我们项目的影子呢? 我们将《农夫的一天》换成《项目经理的一天》：

　　软件项目经理小赵打算今天完成本周五项目阶段汇报的材料，他打开电脑，想起了还有一个重要的技术问题没有确定最终方案；于是他召集项目技术骨干准备继续讨论，一个钟过去了，还没有结论，这时老板来电话，要去老板办公室汇报工作，原来昨天老板跟客户吃饭，客户说到系统有一项功能无法使用，两周了还没解决；从老板房里出来，小赵继续写汇报材料，没多久，项目组的小张找来要反映项目组绩效考核结果以及加班工资的问题；快下班的时候，销售部经理匆匆忙忙地找到小赵：“快帮我估算一下这个项目的实施成本，明天我要给客户报价”……就这样，小赵一天都忙得不可开交，终于下班了，汇报材料没写多少，重要技术问题也没有解决，客户的问题也没安排处理，绩效考核的问题还要跟部门经理以及人力资源部沟通。唯一完成的一件工作，就是帮销售部估算成本，可惜跟自己负责的项目却没什么关系……经过一天的奋战，问题不但没有减少，反倒变多了。

　　这样的一天无疑令人沮丧，但却经常出现在我们的现实中。当高级经理询问怎么还没有提交项目计划的时候，项目经理无可奈何又理直气壮的说：“我很忙啊！”

　　项目经理确实很忙，但这是没有效率的忙。其实何止是忙，还“茫”，而且“盲”，“忙、茫、盲”是许多新任项目经理的写照。

• 忙：一天到晚都在忙过不停，是为忙碌；
• 茫：碰到什么做什么，像个无头的苍蝇，没有计划性，或者无法坚持计划，是为茫然；
• 盲：项目经理这一天初始目标究竟要做什么，做着做着就丢了，没有目标性，是为盲目；

　　2、思维转换

　　有时候我们会说一个项目经理，不像一个项目经理，那像什么呢？当然是像程序员罗。也就是说，他的职位虽然变化了，但并没有完成相应的角色转换，仍然像程序员那样工作。项目经理之所以会出现“忙、茫、盲”状态，归根到底也是因为他没有实现自己的角色转换。

　　角色转换本质上是思维转换。思维决定一个人的行为，项目经理不像项目经理，那是因为他的思维仍然是以前的技术思维，而不是管理者应当具备的管理思维。这就好比一个人在陌生的城市，拿着过时的地图，寻找自己的目标，结果只会是四处碰壁，无所适从。

表1 技术思维 vs 管理思维

 

比较方面

技术思维

管理思维

关注中心

以过程为中心的思维

关心每项任务本身，而不是整体目标。不重视计划，对任务缺乏控制。

以目标为中心的思维

以终为始。关注整体目标、实现的路线、影响目标实现的因素、各种事件对目标的影响，区分重点。

事物结构

局部思维

过于关注细节，对整个项目工作的内容、完成路线没有概念。上来就干，工作缺乏计划性、条理性。

整体思维

采用结构化分析方法，自顶向下，先整体后局部。有时亦采用头脑风暴，先将细节展开再归纳。

逻辑思维

以机器为中心的思维

思想单纯，性格直率。在人际问题上过于讲究逻辑。

以人为中心的思维

人是执行项目的主体，关注事情本身，更关注人的价值。学会包容，能与各种不同情格的人打交道。

决策依据

完美思维

不关心进度和成本，只关心完美的功能和代码，并视之为艺术。经常对上一任的工作推倒重来。

平衡思维

拒绝渡金，项目不需要艺术。在进度和质量之间取得平衡，在员工个性与团队凝聚力之间取得平衡，在员工、项目、公司和客户之间取得平衡。

人际关系

个人思维

以个人为中心，单兵作战，依赖个人能力。个性固执，工作方法简单。

团队思维

你不是一个人在战斗，发挥每个成员的作用比个人埋头苦干重要得多。关注团队分工、配合以及士气和凝聚力。

　　实现思维转换需要时间，这期间是一个懵懂的、左右为难的、痛苦难熬的阶段。有些人可以在很短的时间内完成蜕变，有些人却可能一辈子都在这个阶段，这跟一个人能不能改变自己有关。这些不能改变自己的人，理论知识往往也很丰富，说什么都头头是道，可惜的是，这是无效的知识，因为不能用在自己的实践中。这样的人，往往有一定的人格分裂倾向，因为他的知识和他的行为不统一，甚至是矛盾的。知行合一才是学习的最高境界。

　　新任的项目经理，别忘了时刻提醒自己，像一个项目经理一样去当项目经理！

　　3、项目经理行为分析

　　第一次当项目经理，往往会由于经验不足、项目管理知识的不足以及角色转换等原因，表现出种种不胜任的迹象。

　　不胜任的项目经理，通常有以下几种类型：

　　（1）刺猬型

　　刺猬型的人非常敏感，随时都保持警惕，只要一感觉受到威胁，便会用豪猪般的刺扎向对手，让人避之不及。他们通常自我封闭，坚守自己的地盘，处处表现出来自己是对的，虽然其实他自己也并没有底气。他不会让别人看到自己的脆弱。

　　刺猬型项目经理不允许别人干涉自己的项目，哪怕是自己的上级。如果领导询问项目中的某个问题时，他会非常明确的告诉你，那不是我的问题，那是客户的问题，或者是公司制度引起的问题，或者是领导你干预项目造成的问题。总之，我一切都做得很好。

　　刺猬型项目经理的这种反应通常是不自信的反应。小猫在害怕时，总是拱起背，把全身的毛都竖起来，让自己看起来更强大，但老虎永远不会这样。

　　（2）绵羊型

　　绵羊型项目经理的性格非常温顺，他们语气平和，慢条斯理，不急不躁。对待下属非常友好，在他们心里，似乎没有好和不好、对和不对，这些对他们都不重要。项目每天都很平静，似乎永远不会有暴风雨的到来。当上级提出要求时，他们永远都是好的，至于做成怎么样，只要尽力了，那有什么关系呢？

　　绵羊型项目经理通常工作缺乏计划性，即使有计划，也只是应付上级而已。看到什么事情，就去做什么事情，除此之外，还有什么其它的办法吗？

　　（3）猴子型

　　想像一下孙悟空的行为就对猴子型项目经理有了大致的认识。他们技术能力强，很有激情，非常聪明，非常自信。但他们往往性格冲动，做起事来横冲直撞，不讲究方法。

　　猴子型项目经理悟性很强，进步会很快，他们最终会克服自己的不足，像孙悟空一样，取得正果。这一刻，他已经不是猴子了。

　　刺猬型和绵羊型项目经理，他们往往缺乏自信，其管理模式一般是被动式的，做事没有计划性，有什么事就做什么事，就像条件反射一样，只会对外界刺激做出反应。

　　猴子型项目经理则是主动式的管理，他们充满自信，但往往由于经验不足，过于盲目，对问题考虑不周。同时由于冲动的性格，在团队中并不受欢迎。

　　这三种类型都是不胜任的表现，那怎样才是胜任的类型呢？如果还是用一种动物来比喻，我觉得应该是“头狼”，也就是狼群的首领。

　　暂时的不胜任不要紧，关键是要有进步。如果一个项目下来，除了很疲惫，你没有感觉到自己有一些积极的变化，那你的危机也要来了。要知道，项目经理并不是“铁饭碗”，虽然公司倾向于选用有经验的项目经理，但当你明显不胜任时，领导不会再在你身上押上赌注，他们宁可重新冒险一次，因为他们不想“两次踏进同一条河流”。

　　4、心态

　　新任项目经理没有管理经验，不胜任是可以理解的。也许你认为公司应该给你更多的培训再上岗，但往往形势是箭在弦上，在没有更多资源的情况下，领导把这个成长的机会给了你。

　　可怜的是公司老板，他的项目成了你的试验田。实际上，公司提拔你做项目经理，就是花巨资送你去培训学校，不是吗？我一直认为，由一个不合格项目经理负责的项目，相比由优秀的项目经理来带，实施成本可能多出50%，甚至更多。不合格的项目经理就像一个给项目减肥的机器，使得肥肉变瘦肉，瘦肉变骨头，骨头变渣滓。

　　项目经理应该学会感恩。要成为优秀的项目经理，应该有好的心态，而感恩是一切好心态的基础。你只知道自己压力大，却不知道你让老板少赚了多少钱！是老板交学费帮你从一个初出茅庐的项目经理，培养成了一个合格乃至优秀的项目经理。

　　我见过不少新任项目经理，对公司满肚子怨气，好像是公司一手造成他的项目问题百出，仿佛领导和老板成了他的敌人，刚做完项目甚至还没有做完项目就果断匆匆辞职，带着公司用无形成本换来的宝贵经验，绝决的离去，换取更快的升职加薪。设想一下你是老板，不知会作何感想？

　　感恩是一个人最重要、最美好的品质之一。网上有一个经典感恩的段子：“…感谢鞭打你的人，因为他激发了你的斗志，感谢遗弃你的人，因为他教导你该独立，…凡事感激,学会感激，感激一切使你成长的人!” 而你的领导和你的老板，他们既不是鞭打你的人，也不是遗弃你的人，而是培养你成长的恩人，我们有什么理由不感谢他们呢？

在希腊德尔斐的阿波罗神庙上，刻得着一句神秘的箴言：“认识你自己”。从某种程度上来说，我们都是自己的“最熟悉的陌生人”。认识自己的位置，是每个人获得成长的第一堂课。一个人的位置，对其言行的影响是至关重要的，俗话说：“屁股决定脑袋”，虽然听着粗俗，却饱含人生哲理。既然我们屁股在项目经理的位置上，就应该像项目经理一样去思考问题，做事情。

一、项目经理的处境

　　经过数年的打拼，怀着美好的向往，我们终于成了他——项目经理。然而，梦做到最真的时候，往往也是梦醒的时候。

　　项目经理其实也是悲情人物。从“程序猿”到项目经理，可以说是刚出虎穴，又入狼窝。要知道，做一个合格的项目经理，比成为一个优秀的程序员，还要难得多。

　　本来以为当上了项目经理，王子和公主从此就可以幸福的生活在一起了，没想到，跋涉的路才刚刚开始。我实在不想打碎这美好的梦想，这有些残忍，但清醒的痛着，总好过麻木的睡着。更何况人生本来就是一个接一个的杯具，每个角色都有他的难处，我们只能接受这个现实。人生就像登山，当你到达一个山头时，发现还有更高峰，一山还比一山高。

　　王子和公主，一直在路上。

　　1. 高和低

　　没有成为项目经理之前，期望着当上了项目经理，可以拿着更高的工资，被别人尊敬的称呼为某某经理，还可以干着更少、更简单的活——指挥别人干活，这谁不会啊？

　　然而，人生不如意十之八九。更高的工资，应该是有的，但往往还不会达到让你眼前一亮的数字。被尊称为经理，也是应该的，Project Manager，名正言顺的经理。然而，在大部分公司里，项目经理也就是像弼马温一样的小官，明白真相之后，又难免有一些失落。至于干更少、更简单的活，那就只能说是痴人说梦了。

　　事实上，在兴奋过后，等你翻到硬币的另一面，你会看到和你想像不一样的高和低：能力要求高、职位低。

　　（1）能力要求高

　　能力要求高不高，口说无凭，我在网上随便找了一个软件项目经理的招聘信息，要求如下：

职责范围：

1、负责软件项目管理及计划实施；

2、具备较强管理、协调及沟通能力，帮助开发人员解决开发过程中遇到的技术问题，做好日常的开发团队管理工作；

3、与各团队协同工作，确保开发工作正常顺利的开展；

4、具备较强的分析问题、解决问题的能力，能够解决项目团队在开发过程中遇到的技术难题；

任职要求：

1、计算机相关专业，4年以上JAVA软件从业经验，2年以上开发经理或团队管理经验；

2、精通java、jsp、HTML、JS、xml、AJAX编程语言，精通Struts、Hibernate、Spring、IBatis等常用框架技术；

3、精通中间件技术，对Websphere、WebLogic等有很深的了解；

4、快速适应工作环境，应变能力强，抗压能力强；

5、重视成本和进度控制，合理有效利用资源，有较强的责任心；

6、熟悉Android开发、Hadoop技术者优先考虑；

　　上面的要求写得比较随意，我帮他整理一下，并点评一番：

表1 项目经理职责要求

类别

职责/要求

点评

专业技术

精通多种编程语言和技术框架；精通中间件技术；熟悉Android及Hadoop。

项目经理必须是技术专家，也许你自己不用写代码，但你必须能指导下属，解决技术问题。必要时，还得参与做系统架构和系统分析。

管理技能

项目整体管理；成本管理；进度管理；资源管理；团队管理；沟通协调能力。

难道风险管理、质量管理、采购管理就不需要了吗？九大领域一个都不能少。

个人内在

适应能力；应变能力；抗压能力；责任心；分析问题解决问题的能力。

①     适应能力：像变色龙。能适用不同公司文化和氛围，不同性格的同事，特别是上司。

②     应变能力：像变形虫。项目过程中会出现各状况，必须能调整自己、调整计划，以适应变化。

③     抗压能力：像驴子。项目管理压力很大哦，天塌下来要也扛着。

④     责任心：项目出问题，基本上责任都是你的，决不可推卸责任，勇敢的去解决问题吧，不要辜负领导的重托。

⑤     逻辑思维：项目经常会出问题的，所以你必须思维清晰，能够客观的分析问题和解决问题。

相关经验

4年开发经验+2年管理经验

老板可不想冒险，把项目给你去做试验田。

　　怎么样，要求很高吧？能完全达到这样的要求，我想去铁道部当个CIO应该是没什么问题了。即便如此，对于项目经而言，这些要求也没有哪一项是多余的，也就是说，项目经理必须成为一个超人，最好是像《蜘蛛侠》里面沙人那样，可以随心所欲的变化自己，穿越一切障碍，拥有无穷的威力。

　　（2）职位低

　　说职位低，有以偏概全之嫌。在项目型组织结构的公司中，项目经理的职权还是很大的，项目经理一般直接向总经理汇报工作。但在IT行业中，比较少采用项目型组织结构，大部分是矩阵型或职能型的组织结构。在这种架构中，项目经理基本上就是最小的官了。

　　2. 大和小

　　项目经理之所以需要很强的个人能力，归根到底是由项目经理的责任所决定的。项目是一种个人责任制的管理方式，项目经理是项目组的核心，责任无疑很大；与之相对应，其权力又是比较小的，这让项目经理的处境更加困难。

　　（1）责任大

　　项目经理作为项目组的最高领导，对项目的成败起着至关重要的作用。对项目的目标和实施过程中的一切问题，负有最终的责任。影响项目成败的因素也许有许多，但不管是什么原因，最终的责任会落实在项目经理身上，领导会说，项目经理不给力。

　　（2）权力小

　　项目经理的正式权力包括指挥权、人事权、财权、技术决策权以及采购权等，项目经理一般在某一限度内具有完全的权力，无需沟通汇报即可自行做出决定；在超出限度时，则需要与高级经理或职能经理商议决定。在一个矩阵型组织结构的公司中，项目经理的权力大致如下表所示：

表1 矩阵型组织中项目经理权力情况

 

权力类型

完全的权力

部分权力

指挥权

对项目内的人、财、物的调度安排，可以自主决定。

对项目结果产生较大影响时，需与高级经理讨论。

人事权

可以依据公司制度对员工进行考核、奖惩。

人员的聘用、辞退等决定一般由职能经理安排，项目经理可以作出建议。

财权

小额活动经费一般可以自主决定

达到一定金额需要申请，由高级经理直至总经理审批

技术决策权

一般技术措施可以自主决定

重大技术措施，必须通过外部评审，并请上级领导拍板

采购权

小额采购项目必须品

达到一定金额需要申请，由高级经理直至总经理审批

　　乍看上去项目经理权力并不小。但在实际操作中，项目经理权力范围的这个限度往往比较小，并不足以保证项目经理推动项目顺利开展，项目经理必须花去大量的时间去与上级领导沟通、汇报、提出建议、争取支持。在有些公司，甚至连项目组聚餐也要向上汇报请示。项目经理的这种处境往往会导致其工作畏首畏尾，做事犹豫不决，久而久之，失去了对工作的激情。

　　3. 夹心饼

　　项目经理的位置是比较尴尬的。下面的兄弟要你多争取一些奖金；领导要你经费更省一些；客户要你更快一些；用户要你的产品更好用一些。在员工面前，你代表老板；在老板面前，你代表项目组员工；在客户面前，你代表公司。你代表了很多人，就是没有代表自己的时候。

　　项目经理就是一个不折不扣的夹心饼。做人难，做项目经理更难啊。

 

图1 项目经理成了夹心饼

　　4. 为什么还要做项目经理

　　也许你会问，既然项目经理这么难、这么惨，好像比“程序猿”还要苦逼，那我为什么还要做项目经理呢？这看上去不是个问题，“人往高处走，水往低处流”嘛，高处虽然艰险，向上追求的脚步却不能停止。无限风光在险峰，还是别埋怨攀登的辛苦，好好享受一路的风景吧。

当然，人的一生有不同过法，有些人喜欢在泳池中游水，有些人在热衷于在大海的激流中冲浪，还有些人，一辈子也不会游泳，他们只是偶尔到河边洗洗手，用冷漠或者好奇的目光看着那些乘风击浪的人们。每种活法的选择权在自己手上，一旦选择，无怨无悔。

二、项目经理素质模型

　　1. 素质模型的作用

　　谈素质模型是一件很严肃的事情。因为素质模型就像一面镜子，项目经理拿来一照，可以发现自己的优势和弱点。只有扬长补短，才能在职业发展之路上步步高升。

　　管理方面的素质模型很多，但不是每一个都是客观的镜子，如果不能在镜中看到一个真实的自己，那它也就失去了应有的价值：

　　如果它是一面哈哈镜，那看到的将是一个变形的自己，无法作为自己的参照；

　　如果镜子太小，就只能照到自己的局部，会导致产生盲目的悲观或乐观；

　　如果镜子太大，可能会看到太多无关的东西，反倒干扰了自己的视线。

　　2. 他山之石

　　（1）PMI知识体系模型

 　　PMI将项目经理应具备的知识和技术分为五类，即：项目管理知识体系，应用领域知识、标准与规章制度，理解项目环境，通用管理知识与技能，人际关系技能，如下图所示：

图2 PMI的项目经理知识技术体系

　　（2）麦克利兰的素质模型

　　美国心理学家麦克利兰经过研究提炼并形成了21项通用素质要项，并将21项素质要项划分为6个具体的素质族，同时依据每个素质族中对行为与绩效差异产生影响的显著程度划分为2～5项具体的素质。6个素质族及其包含的具体素质如下：

　　①管理族，包括团队合作、培养人才、监控能力、领导能力等；

　　②认知族，包括演绎思维、归纳思维、专业知识与技能等；

　　③自我概念族，包括自信等；

　　④影响力族，包括影响力、关系建立等；

　　⑤目标与行动族，包括成就导向、主动性、信息收集等；

　　⑥帮助与服务族，包括人际理解力、客户服务等。

　　（3）管理者胜任特征模型

　　胜任力是指任何直接与工作绩效有关的个体特质、特点或技能等，在本质上也就是应该具备的素质组合。有学者利用物元分析和可拓评价方法建立了基于管理技能、个人特质和人际关系3个维度的胜任特征物元模型。

　　①管理技能的维度，包括团队领导、决策能力、信息寻求和市场意识等；

　　②个人特质的维度，包括影响力、自信、成就欲、主动性、分析思维和概括性思维等；

　　③人际关系的维度，包括人际洞察力、发展他人、关系建立、社会责任感和团队协作等。

　　（4） 四种能力论

　　Robert hogan和Rodney B.Warrenfeltz研究指出管理人员的素质可以分为4种，分别为：自我管理能力、人际关系能力、领导能力和商业能力。

　　①自我管理能力，包括自我尊重、正确对待权利的态度和自我控制等；

　　②人际关系能力，包括换位思考、正确预计他人的需要、考虑他人的行动等；

　　③领导能力，包括建立团队、维持团队、激励团队、建立共同愿景和巩固团队等；

　　④商业能力，包括制订计划、管理预算、绩效评估、成本管理和战略管理等。

　　3. 几种素质模型的分析

　　上面这些模型，都是被广泛认可的模型，我本人对四种能力论，更是情况独钟。为了找出一个适合项目经理学习修炼的模型，我们有必要对这几种模型进行评价。

　　首先确定评价的指标：

　　（1）针对性：是否适合于项目管理领域；

　　（2）完整性：是否太过宽泛或狭窄；

　　（3）实用性：是否适合于项目经理修炼。

表2 几种素质模型的评价

 

模型

针对性

完整性

实用性

PMI的项目经理知识技术体系

好

太小

好

麦克利兰的素质模型

较差

太宽

较差

管理者胜任特征模型

中

太宽

较差

四种能力论

中

太宽

中

　　那我们能不能找到一种这三个指标都吻合的模型呢？

　　4. 西西吹雪的六种能力模型

　　“六种能力模型”力图在针对性、完整性和实用性方面达到最佳。六种能力分别是：知识、技能、逻辑思维、执行力、心智成熟和领导力。这六种能力是一个有机的整体，如下图所示：

图3 项目经理的六种能力模型

 

　　（1）人、事结合

　　管理，就是管人理事，这个理念已经深人心。这个模型首先就是一个管人理事的素质模型。

　　从“理事”的角度来讲看，项目经理应当具备四大素质：

• 知识

必须具备项目管理的理论知识，所处的行业知识， 以及专业知识；

• 技能

光有知识是不够的，还要能知道怎么做。主要有项目管理技能、沟通表达技能、写作技能、专业技能等。

• 逻辑思维

项目经理必须具有较强的逻辑能力、思维清晰，对项目任务和要做的工作，随时都有清晰的分类和列表。逻辑思维能力有很多种，如果要挑出两种对项目经理最重要，我觉得是归纳能力、判断力。

• 执行力

项目经理本人必须具有很强的执行力。如果项目经理像个蔫老头，整个项目的执行结果可想而知。

　　从“管人”的解度来讲，项目经理应当具备两大素质：

• 心智成熟

要管人，首先必须学会与人相处，心智不成熟的人，与人相处往往会无所适从。心智成熟，也就是要管好自己的内心。自己都管不好， 怎么管别人呢？

• 领导力

项目不是一个人的战斗，有些项目经理，只顾自己埋头干活，乐不滋滋，下面的同事却不知道每人要做什么，这是缺乏领导力的表现。余世维说：“管理就是让别人完成事情”，“真正厉害的人不是自己累死，而是要让手下做事情累死，这个才叫本事”，“优秀的管理者不会让员工觉得他在管人”。这三句话，可以说是领导力的三种境界。

　　简而言之，项目经理就像一个贤妻良母，要上得厅堂，下得厨房。上得厅堂意味着，项目经理要擅长与人打交道，也就是“管人”的要求。下得厨房则意味着项目经理懂技术、懂业务，能把复杂的事情理清楚，并解决各种问题，这就是“理事”的要求。理事主要靠智商，而管人则主要靠情商。

　　（2）内、外兼修

　　这个模型还是一个内外兼修的模型。古人云：“胜人者力，自胜者强”，说的其实就是一个人的外在修养与内在修养的关系。

　　战胜外在的事物，你需要是“力”，因此模型也有两个力：执行力和领导力。有这两种力，我们可以在管人、理事都做得很好。

　　要战胜自己，则非要靠一个人的内在修养不可。因此模型中，有四项个人内在素质的修炼：知识、技能、逻辑思维和心智。

　　从表面上看，“自胜”似乎比“胜人”更牛一些。但是从一个人成长的角度来看，我们主张要先“自胜”，再“胜人”。如果以树类比，“自胜”是根，“胜人”则旧枝干，一棵没有发达根系的树，是不可能长成参天大树的。所以不要让自己一开始就显得很牛，而是首先让自己成为一个真正的牛人，否则大树会过早夭折。

　　（3）从独立到互赖

　　一个人有成长过程可以分为三个阶段：依赖期、独立期和互赖期。每到一个新的阶段，都是一次巨大的飞跃。

　　●依赖期：围绕着“你”这个观念——你照顾我；你为我的成败得失负责；事情若有差错，我便怪罪于你。

　　●独立期：着眼于“我”的观念——我可以自立；我为自己负责；我可以自由选择。

　　●互赖期：从“我们”的观念出发——我们可以自主、合作、统合综效，共创伟大前程。

　　也许你已经注意到了，在素质模型里面没有依赖期，这是因为在依赖期的人是无论如何也成不了项目经理的。这个模型，是一个从独立期走向互赖期的素质模型。

　　在独立期，我们主要擅长做“理事”的工作。我们是技术英雄，可以把每件事都做得很完美；

　　在互赖期，我们的精力转向了“管人”。我们懂得如何与各种不同类型的人相处，如果驱动团队为一个共同的目标而努力。

　　（4）层次分明

　　这个模型是还是一个层次分明的、渐进的模型。从知识到执行力，实际上是一个从“知道”到“去做”的过程，而从心智成熟到领导力，是发挥团队力量的两个阶段。

一、从几个招聘要求说起

　　在上一篇中，我举出了一个招聘需求，引起一些朋友的争论。既然招聘的是项目经理，为什么需要那么多专业技能呢？

　　在百度上招聘频道搜索“软件项目经理招聘”，可以查到8500多条类似的招聘信息。我们看看国内软件行业老大东软集团的招聘条件：

工作职责：

带领团队完成需求分析，开发计划制定与跟踪，项目组关键技术问题解决，负责项目QCD。

岗位要求：

1、3年以上软件开发项目经验，2年以上项目管理经验；

2、熟练掌握JAVA、WEB开发，精通基于Oracle/Mysql数据库的MIS系统开发；

3、具有较强的沟通、组织能力和较好的文字表达、写作能力；

5、有医疗业务开发经验者优先。

　　显然，东软公司也是要求具有较强的专业技能的。当然，也许东软公司太大了，不具有代表性，那么我们再看一个比较小的公司，你绝对没听过(我也没听过)，广东广风隆电子科技有限公司：

任职要求：

1．能很好的把握开发质量和项目进度，规避风险。

2．具有较强的语言和文字表达能力、沟通协调能力、良好的团队合作精神。

3．具备至少3年项目管理经验或大型系统开发实施经验的优先。

4．掌握JAVA技术，能熟练应用J2EE，Spring，Struts，Hibernate等开发和测试。

5．熟悉基于java的B/S架构应用技术。

6．熟悉基于Tomcat、WebSphere、weblogic等应用服务器的开发；

7．熟悉大型数据Orecle/SQL Server等，熟练掌握存储过程编写、数据库表设计。

8．熟悉unix/Linux操作系统。

9．具备软件团队管理经验，熟悉软件开发流程，能够独立完成项目实施的优先。

10．具备一定的系统框架设计、熟悉开发流程，具有的良好的需求分析、项目设计、规划能力。

13．有如下经验者优先考虑：

a.熟悉BIEE，或有BI项目开发实施经验

b.对BI/DW的概念和架构有比较深入的了解，熟悉维度模型架构

c.熟悉Oracle数据库开发，或有ETL工具ODI经验，精通SQL

d.有基于java技术项目管理经验的优先，教育行业背景优先

　　哇啦啦，这个更不得了。这究竟是招程序员还是招项目经理，我也快被弄迷糊了。看来中小公司比大公司更看重专业技能。

　　当然，我再多举一千条也代表不了所有的企业。但诸位如果有时间一条条看，会发现绝大部分公司对“软件项目经理”这个职位，都对专业技能有较高的要求。那么，传说中的“外行领导内行”究竟是不是真的？外行真的可以领导内行，带领项目走向成功吗？

二、外行 vs 内行

　　1. 优势劣势分析

　　外行和内行究竟谁更适合当项目经理？那些招聘要求似乎已经为我们给出了答案，最少在软件行业内行项目经理更占据优势。然而，外行的项目经理往往也有其独特的优势，比如，他们往往更有大局观，能跳出技术本身看待问题，有更强的领导力等等。事实上，外行领导内行的现象，在国家大型建设工程或科研项目中要屡见不鲜。据说，我国的原子弹工程就是聂荣臻元帅领导的，而聂帅是不懂核物理的。

　　如果拿外行和内行项目经理来PK，并不是一件容易的事情，因为每一项都不是绝对的，这就如同比较男人和女人谁更适合做厨师一样。当我们拿两者PK的时候，其实包含了一些隐含的信息，就是这个外行的项目经理比内行项目经理，更加懂得管理、情商更高，否则的话，内行项目经理会毫无悬念的胜出，也就没有比较的必要了。

　　基于这些隐含的信息，我们试着比较一下两种项目经理的优秀和劣势：

项目经理类型

优势

劣势

外行

一般具有更强的领导力，更善于激发员工的士气、战斗力；

一般具有更强的谈判能力、资源协调能力，客户和上级领导满意度会更高；

一般具有更强的沟通汇报的能力；

更容易跳出技术本身，看清问题本质；

一般更善于权衡轻重缓急，更善于取舍。

项目详细计划要依靠技术骨干，对其评估的准确性无法做出自己的判断；

无法对技术人员进行辅导；

无法对技术问题做出分析判断，帮助解决棘手问题；

无法对技术人员进度拖延原因做出准确分析、不能很好控制项目；

容易造成瞎指挥；

容易和技术人员互相看不起对方。

内行

外行的劣势往往是内行的优势

外行的优势往往是内行的劣势

　　2. 技术决定论的误区

　　所谓内行与外行是纯粹从技术的角度来看问题，单纯讨论内行好还是外行好，其实也暗含着一个前提，就是技术决定项目的成败。而实际上，一个项目能否成功的影响因素，远不止是技术，对一个项目经理的素质要求也远不止技术。同是外行或内行来带一个项目，会由于个人修养与经验在差异，项目结果可能相差很远。因此单纯说外行好，还是内行好，是没有意义的。

　　3. 综合素质决定论

　　问题的关键其实不在项目经理是内行还是外行，而在于他的综合素质。无论是外行还是内行，只要谁的综合素质更高，谁就是更优秀的项目经理。

　　上一篇我们讲到项目经理的六种能力模型，也就是说，一个优秀的项目经理，应当具备六个方面的素质，即：知识、技能、逻辑思维、执行力、心智成熟和领导力。

　　在知识层面，包括专业知识、行业知识和管理知识。外行项目经理在专业知识和行业知识方面已经输了，但在管理知识方面按默认值，外行赢了。

　　在技能导面，包括专业技能和管理技能。外行项目经理在专业技能也又输了，同样管理技能方面，又略胜一筹。

　　现在打成了平手。剩下的，要拼逻辑思维、拼执行力、拼心智、拼领导力，这就和内行外行无关了，鹿死谁手，要看个人的修养。

　　因此，项目经理的比拼，拼的不只是管理知识或专业知识这一个方面，而是综合素质的比拼。

三、外行，你凭什么

　　1. 唐僧的团队

　　外行，也就是不懂专业知识技术，显然不但不是什么优点，反而是一个项目经理的极大缺陷。那为什么领导还会置这么大的缺陷于不顾，任命一个外行为项目经理呢？换一个角度，也就是说，一个外行，在什么情况下，可以成功的管理一个软件项目呢？

　　一件事情的发生，总有他的内部原因和外部原因。具体到这个问题上，也有它的内因和外因。

　　（1）在内部因素上，外行项目经理必须具有更高的综合素质。

　　现在流行分析西游记中的取经团队，其实也是一个典型的外行领导内行的团队。到西天取经，靠的是降妖服魔的本领，显然唐僧是个外行。但是，唐僧并不是一无是处，相反，他的综合素质很高。他外柔内刚，意志坚定，目标明确，还精研佛法，具有很强的人格魅力，因此他的那些徒弟才能凝聚在他周围，虽历尽千难万险而无悔。

　　（2）在外部因素上，必须有合理的人才结构作为支撑。

　　唐僧虽然不会打怪，但是孙悟空可以，补齐了唐僧在这方面的不足。试想，如果他的徒弟都不能降妖，任凭唐僧的领导力再强，也注定最终只会被妖怪吃掉。同样一个外行的项目经理，在他的团队中，必须可以信赖的技术骨干，像孙悟空一样能在关键时候解决问题，这些骨干一般就是项目中的组长、系统架构师或者系统分析师，必要时可能要设置项目副经理之职。如果团队中没有技术骨干，都是一些经验不足还不求进取的程序员，那除非项目超级简单，否则项目经理纵然有诸葛亮的才华，也无济于事。

　　2. 规模决定一切

　　在上面两项条件都具备的情况下，只能说明外行可以担任项目经理了。站在项目本身的角度，除了这两项因素，往往还跟以下方面有着紧密的关系。

　　（1）项目规模：规模越大，采用外行项目经理的机率越高。

　　（2）项目所在行业：在建筑、施工、水利等传统行业，采用外行项目经理的机率更高。

　　（3）项目的技术难度：在项目规模不大时，如果技术难度越大，采用内行项目经理风险更小。

　　（4）项目进度要求：时间要求越紧，更倾向于采用内行项目经理。

　　（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）国内外高手写的实战类书籍。

　　这类书实战性很强，把技术及原理讲得很透彻。比如《windows环境下32位汇编语言程序设计》、《深入解析MFC》、《Delphi深度探索》、《深入浅出WPF》、《深入剖析Asp.net组件设计》等。以前这类书都是从国外翻译或从台湾引进，现在国内高手越来越多，出自国内作者的也越来越多。这类书如果在你学习的每个方向看个两三本，并且通过实践消化掉，那么毫无疑问，你会成为一个优秀的程序员。

　（3）国外大牛写的、揭露本质、有丰富思想的书。

　　这类书就是所谓的经典书了，例如《代码大全》、《编程珠玑》、《设计模式》、《重构》、《代码整洁之道》等。经典书就像一个有深度、有思想的朋友，他会给你启发、每次阅读都会有新的收获，这类书具有真正的收藏价值。看经典书永远是正确的选择，它绝不会浪费你的时间，因为经典书是无数人沙里淘金、帮你挑选过的结果。

　　然而，阅读这类书并不是一件容易的事情，读者需要有丰富的开发经验，才能与作者产生共鸣。真正能消化经典书的人其实不多，这就好像饮酒，一个新手无论如何也品不出葡萄美酒的醇香。在酒桌上，人人都把杯中酒一饮而尽，当有人点评“这个酒不错”的时候，我只能无奈的苦笑一番，真的是甘苦自知。

　　如果一本经典书你看得很辛苦，很有可能就是因为你功力未够，这种情况下不要着急，慢点来，不妨先将其先束之高阁，多看看第二类实战型书籍，过一段时间再回头来看，也许你会有新的惊喜。

　　四．不要在上班时间看书

　　一个善于学习的人，首先要善于利用一切时间来学习。不知是伟大的雷锋叔叔还是鲁迅爷爷曾经说过：“时间就像海绵里的水，只要愿挤，总还是有的。”然而，当我们从上班时间中挤时间学习时，就千万要注意了，不要在上班时间看书！

　　上班时间看书不但是一件很敏感的事情，而且非常吸引眼球，很快就会引起周遭的不爽。首先老板心里不爽，他想：“我给你钱是让你来工作的，不是来学习的！”；其次同事们也不爽：“我们工作都做不完，瞧，这小子真闲哪！”用不了多久，你就会成为被众人排斥的异类。

　　当然，你可能会说，“我工作已经做完了，经理没有安排，当然可以学习了”，其实不然。你完成了一件事情，不等于所有的事情都完成了。一个优秀的员工，应该是主动要工作，而不是被动的等工作。工作完成以后，你至少还可以：

　　（1）主动汇报给你的经理，请他来检查你的成果，并安排新的任务；

　　（2）如果公司这一段时间确实比较闲，没有什么具体的任务，可以进行代码重构、优化；

　　（3）你还可以主动请缨，承担额外的工作或更艰巨的任务。

　　（4）如果一定要学习，也只能对着电脑屏幕来学习，纸质书最多只能拿来翻阅一下，而不能一直捧着，以免影响到其他人的情绪。

　　五、只学习与工作相关的东西

　　我曾发现不少程序员在学习方面找不到方向，一会学学C#，一会学学Java，看了最新的编程语言排行榜，又觉得该学C++。这样左抓抓，右挠挠，只会让你觉得更痒。

　　学习最忌三心二意。俗话说：“伤其十指不如断其一指”，每门都学一点，还不如专心学好一个方向。这个道理谁都懂，可是又该学哪个方向呢？难道只能跟着感觉走吗？

　　不！最实际的方向，应该跟着工作走，工作需要什么，我们就学什么，把工作需要的技能熟练掌握。我们为什么要学习和工作弱相关的东西呢？是为了转行或跳槽吗？可是，如果我们连现在本职工作都不能做好，又怎么能保证到新的岗位、用新学的技能就可以做得更好呢？

　　学习与工作需要的的东西，有很多好处：

　　首先，可以集中精力，在某一方面钻研得更加深入。所谓“百招会不如一招绝”，有了绝招，你还怕不能在“武林”立足吗？《天龙八部》中的慕容复武功博学无比，最后还不是被只会一招六脉神剑的段誉打得落花流水？

　　其次，可以学得更快、更深入，因为学习更具有针对性，而且可以立即在工作中运用，可以马上检验出学习的效果，对存在的问题可以进行深入的研究，因此掌握的知识也会更加的牢固。

　　第三，学习与工作结合在一起，工作时间也就成了学习时间，这样突破了三个8小的限制。有人说，我们每天所有拥有的时间可以分为三个8小时，工作8小时，睡觉8小时，另外还有8小时自己可以自由支配的时间。工作和睡觉的两个8小时大家都一样，决定人生高度的是另外这个8小时。当我们把学习的焦点放到与工作相关的知识上时，工作时间中的很大一部分，同时也就成了宝贵的学习时间，这真是一举两得的美事啊。

　　六．织网式的学习

　　知识的广度和深度都很重要。作为一个程序员，深入把握技术细节，是写出优质代码的保证。但对于一个项目经理而言，知识的广度更显重要。项目中碰到的问题往往是综合性的，只有具有广博的知识，才能快速的对问题进行分析和定位。在程序员通往项目经理的道路上，我们必须有意识的扩大自己的知识面，形成更完善的知识体系。

　　每个人的知识体系就好比是一张网，我们学习其实就是要织这样一张网。 我曾看过渔网的编织过程，渔网虽大，也是一个结点起步，一个点一个点的编出来的，编织的过程中，始终只有一根主线。

　　学习又何尝不是这样，知识体系的大网也是由许多小的结点组成，要结这样一张网，只能由一个点起步。牵住一条主线，织出一个个的点，由点带出面，最后才能形成这张大网。

　　我曾经编写过一个网络信息采集软件，这个软件可以从具有列表页网站中按字段设置采集信息，支持自定义字段、页面多级关联、下载附件、支持多种数据库、可视化定义等特性。刚开始时，觉得这个软件也是一个比较大的功能点而已，后来发现这个不起眼的功能关联着大量的知识点，在开发过程中， 我顺藤摸瓜，各个击破，对很多知识点进行了细致的学习研究，软件开发完成后，个人的知识体系网也进一步得到了补充和完善。

图1 由知识点形成知识网

　　七．问题是最好的学习机会

　　日本经营之神松下幸之助曾经说过：“工作就是不断发现问题、分析问题、最终解决问题的一个过程，晋升之门将永远为那些随时解决问题的人敞开着。”可见，工作过程中有问题是正常，没有问题那才是真正的问题。在发生问题能时，能勇于面对问题、解决问题的人，才是公司真正的核心骨干。

　　现实中，很多人总是千方百计回避问题，当上司安排一项艰巨的任务时，也是想尽办法推托。殊不知，对于个人而言，其实问题是最好的学习机会。往往那些愿意接受困难工作的人，能力会变得越来越强，那就是因为他们在克服困难的过程中取得了巨大的进步。

有一次，一位项目经理对我说：“有一个问题，客户有一台HP服务器要装磁盘阵列，没人会做，怎么办啊？”

“可以学啊，没有人愿意去吗？”

“我都问了，没人想去。”

“哦，正好明天我有时间，我也没装过磁盘阵列，那我明天去学着弄一下。”我说的是真心话。

第二天早上，当我准备出发时，项目经理告诉我不用我去了，因为项目组好几个同事都想去“学着弄一下”。

结果服务器很快就装好了，远远没有之前大家想像的那么困难嘛。更重要的是，在解决这个问题的过程中，大家都学会了怎么装磁盘阵列。

　　碰到困难时，迎难而上吧，千万不要拒绝这个最好的学习机会！

　　八．经常思考总结

　　子曰：“学而不思则罔”。只学习不思考，就会迷惑，难以把握事情的本质。这就好比一个学武之人，只习得其形，而未得其神，难以成为真正的高手。

　　一个程序员从入门，到成为高手的过程中，往往要经过几次顿悟。顿悟会让你跳出知识的丛林，一切豁然开朗，仿佛打通了全身的奇经八脉一般奇妙。记得我有一次，顿悟到了一个很简单的结论：“原来高级编程语言中的类库是封装了Windows API来实现的。”后来碰到一些自带类库无法实现的功能时，我就会想到，其实可以通过调用Windows API来实现。利用这个思路，我解决了一些看起来很难的问题，得到老板的赏识，从而很快获得提升。

　　顿悟非常可贵，然而它不是随便发生的，而是经过一次次苦苦思索之后、灵光闪现的结果。思考的过程，其实就是将外在的知识内化为自己的知识的过程，而顿悟，则是批量的实现这种内化，将无数个知识点连接在一起，达到融会贯通的境界。

　　九、克服“高原现象”

　　爱学习的人都会有这样的经历，学习持续了一段时间之后，往往会有一个瓶颈期，长时间似乎很久没有什么进步，于是内心非常着急。

　　这种情况实际上这是由人的学习规律决定的一种“高原现象”。据研究，学习者在刚开始进步快，随后有一个明显的或长或短的进步停顿期，后期进步慢，中间的停顿期叫高原期。

图2 技能学习练习曲线

　　在我看来，高原期实质是一个消化期，由于前期的学习积累了太多的知识点，这些知识点在大脑中乱作一团，还没有形成一个知识体系。这时需要一定的时间来消化它，将它融会贯通，经常思考总结可以快速帮你跨过高原期。

　　在处于高原期的时候，还可以换一个相关的方向来学习，例如编程语言学不下去了，你可以学习一下设计模式，设计模式也学不下去了，再换成数据库。通过学习这些相关的知识，不但补齐了知识体系中的短板，而且各个知识点之间可以互相启发，帮助你实现顿悟，跨过高原期。

　　十、学习要有好心态

　　（1）学习要静心

　　急于求成是学习过程中普遍存在的一种心态。这可以理解，毕竟作为一个程序员，要学的东西实在太多了，而社会又是那样的浮躁，让人觉得一切都是那样的不安全、不确定，似乎只有学得快一点，才能跟上社会的脚步。

　　可是“欲速则不达”，想快快的学，往往会形成东一榔头、西一棒槌的学习方式，每一个点都没有吃透。心沉不下去，知识也会沉不下去。要想成为真正的高手，只能静下心来，一步一个脚印的攀登。

　　（2）学习是一个持续一生的过程

　　人生的过程，就是一个自我完善过程。

　　孔子曾经说：“吾十有五而志于学，三十而立，四十而不惑，五十而知天命，六十而耳顺，七十而从心所欲，不逾矩。”可见孔子也不是天生的圣人，也在不停的学习、进步，从“志于学”到最后“从心所欲，不逾矩”，孔子一共花了55年的时间。

　　作为一个程序员，更是需要不断更新自己的知识。我们所知道的东西，就像一个白色的圆圈，圈外则是黑暗的未知的世界。当圆圈越大，所接触到的黑暗部分就越多。我们只有不停的学习，打破更多的黑暗，找到更多光明。

　　（3）保持饥饿，保持愚蠢

　　看了《乔布斯传》之后，我最喜欢的一句话是“求知若饥，虚心若愚”（Stay Hungry,Stay Foolish），其实我更喜欢它更原生态的翻译“保持饥饿，保持愚蠢”。我们只有认识到自己还很饥饿和愚蠢，才会像没吃饱一样，由衷的需要学习、爱上学习。

　　当然，知易行难，知行合一才是学习的最高境界。我也始终是一个学习者，一直在路上。

说起程序员三个字，我觉得既骄傲又可悲。骄傲的是，我们曾经是时代骄子，是一群真正改变世界的人；可悲的是，我们很多致力于改变世界的程序员，却生活在自己的世界里，无法自拔，成为了继“书呆子”之后的“电脑呆子”。电脑本来只是一个工具，我们竟然被其所限制、甚至同化，悲夫！

　　一、警惕成为“电脑呆子”

　　（1）程序员眼中的自己

　　程序员是怎样看待自己的呢？看看园子里的发言，码农、码畜、IT民工、苦逼、程序猿…这样的字眼俯拾皆是。

　　在网上曾经广泛流传一首关于程序员的诗，模仿的是唐伯虎的《桃花庵歌》，我们暂且称之为《程序员之歌》吧：

　　写字楼里写字间，写字间里程序员；程序人员写程序，又拿程序换酒钱。

　　酒醒只在网上坐，酒醉还来网下眠；酒醉酒醒日复日，网上网下年复年。

　　但愿老死电脑间，不愿鞠躬老板前；奔驰宝马贵者趣，公交自行程序员。

　　别人笑我忒疯癫，我笑自己命太贱；不见满街漂亮妹，哪个归得程序员。

　　这首诗的作者不知姓甚名谁，但可以肯定的是，他是一名程序员，因为只有程序员才能这样生动的写出程序员的酸甜苦辣。从诗中看出程序员眼中的自己的形象：敬业、辛苦，每天的时间全部花在写程序和上网；思想单纯；清高不合群，自傲自恋；清贫不得志，自悲自叹。

　　（2）别人眼中的程序员

　　在别人眼中程序员又是怎样的一个群体呢？在360网站有一个关于程序员形象的热帖（http://bbs.360.cn/3237987/254486286.html），其中回帖的大部分都不是程序员，很多回复都非常生动，没有骂街，可以说比较客观。

　　总结一下，大家回复的情况大致如下：

• 工作方面

富有钻研精神，是技术方面的高手，没有时间概念，加班多，辛苦劳累，工作认真严谨，懂制作软件却不懂这软件如何运行更好。

• 外在形象

黑眼袋，红眼圈，睡眠不足，瘦小，邋遢，带眼镜。

• 生活方面

电脑前潇洒自如，世人前胆小腼腆。聪明，思维敏捷，生活刻板。

• 性格方面

“闷骚”这个词不好听，但还是蛮准确的：程序员大多沉默寡言，不善与人交往，但内心却很丰富。性格腼腆甚至孤僻，圈子小，爱憎分明，有点不食人间烟火的样子。

• 思维方式

是一种面向问题的思维方式，逻辑灵敏而严谨，无时无刻不在思考攻克解决问题，善于找别人的问题，却对自己的问题视而不见，不善于解决生活中的问题。

　　综合起来，程序员在世人眼中大抵是一个聪明而又迂腐、善良而又刻板的形象，是不是有点像鲁迅笔下的“孔乙己”先生呢？

　　（3） “电脑呆子”是怎样炼成的

　　上面描述让我想起了一个词：“书呆子”。书呆子是指那些死读书、读死书、不通人情世故、不会用书上的知识变通的人。书呆子是与书待一起的时间太久了，以至于生活在书的世界里，用书里的道理来评价和要求真实的世界。而我们程序员呢，日复一日，年复一年在代码间摸爬滚打。每天用在与电脑交流的时间，比大部分书呆子看书的时间有过之无不及。每天基本上就是“电脑一开，一关就过去了，嚎”。

　　俗话说：“带着锤子三年，看什么都是钉子”。当程序员三年，看到谁都当作是电脑。于是产生了计算机时代的“书呆子”，不妨称之为“电脑呆子”。电脑呆子用电脑的时间太久了，生活在电脑的世界里，用电脑的逻辑来要求别人，不懂生活，不懂人情世故。可能你对这样的措辞感到不满，但对多我们身边有些程序员，是不是有几分神似呢？

　　悲夫！程序员曾是时代骄子，有非常细腻内心、非常丰富的感情世界、非常聪明的大脑，在世人眼里的形象却是如此不堪！

　　孔子说：“君子御物而不御于物”。电脑只是被我们利用工具而已，而我们的思维却被电脑所限制，甚至变得和电脑一样。

　　程序员，是该求变的时候了！

　　我们再也不要闷骚，将我们的内心美好善良的一面勇敢的表达出来吧！

　　我们再也不要苦逼，我们要金钱，更要快乐，我们要工作，更要生活！

　　我们再也不要死板，我们可以做出漂亮的程序，同样也可以漂漂亮亮的做人！

　　（4） 一个老程序员的肺腑之言

　　也有大家会觉得“电脑呆子”这样的词是在骂程序员，是对程序员的不敬，但也许激烈的言辞更能令人警醒。有一个成语叫当头棒喝，据说佛教禅宗和尚接待初学的人常常用棒一击或大喝一声，促他醒悟。

　　我曾经是一个程序员，现在仍是。我也曾经是一个真正的“电脑呆子”，我曾独自在黑暗中摸索，花了多年的时间才摸着石头过河—也许我还远未过河。那些曾狠狠骂我的人，我把他们当作我的恩人，因为他们激励和启发了我的成长。当我逐渐走向成熟时，已经错过了无数的机会。

　　二、懂电脑更要成为人脑

　　（1）电脑逻辑 vs 人脑逻辑

　　程序员写代码离不开电脑，沟通、交际又要与人脑打交道，然而电脑与人脑的逻辑在很多方面却是大相径庭。

比较方面

电脑的逻辑

人脑的逻辑

差异性

同一个程序在每台电脑上的运行结果都一样

任务交给不同的人，结果可能大相径庭

多样性

每台电脑都一样（换一台电脑编程完全没问题）

每个人都不一样，人千差万别，因此要适应不同性格的人

确定性

程序正确，电脑一定能得到正确结果

任务明确，做出来的结果与预期可能相去甚远

思维

电脑无自主思维。

个人存在理解力，执行力，判断力等方面的问题

情感

电脑没有感情、情绪等因素的影响

人受感情、情绪的影响

自主性

电脑无自主性，完全受程序的控制

人具有自主性，但行为由很多因素决定

社会性

电脑与电脑之间只在严格的逻辑交互，无社会性

人与人之间的关系微妙

合作

1台电脑+1台电脑，运算能力更强

1人+1人，结果无法预知，团队合作至关重要

　　电脑的逻辑简单，所以我们愿意与电脑打交道。如果我们把电脑的逻辑带到与人交往的过程中，那就太“简单化”了，当然也就给人以迂腐、刻板、不懂变通的印象。我们毕竟是生活在人的世界中，我们要懂电脑，更要懂人脑。我们不是只懂电脑异类，而只是更懂电脑的正常人。

　　（2）做回正常人

　　我曾经很看不起那些不懂技术却八面玲珑的人，看到他们身居高位更是感到愤愤不平，甚至感叹要是生活在西方国家就好了，什么事情都直截了当，不用拐弯抹角。

　　然而，经历了无数的挫折之后，我明白了一个道理：“世事洞明皆学问，人情练达即文章”。人家能说会道、八面玲珑也是一种本事啊。不然，我们怎么做不到啊？

　　其实并不是这样做很难，而是我们不愿意这样做而已，不愿意为世俗的观念改变自己。没错，现实是世俗的，但现实也是无法改变的，我们只能承认现实，臣服于现实。我在360的那个帖子中看到有一个对程序员的绝妙评价，“程序员是七仙女中的织女”，难道我们真正的要像仙女一样不食人间烟火吗？

　　我们不用做仙女，只需要做一个普通的正常人。要顺应人的逻辑，懂人情，明事理，做一个正常人该做的事情，这样并不难。

　　莫言在领诺贝尔奖时有一段精彩的发言：

　　最后，我讲一个小故事。听说法兰克福是歌德的出生地。在中国，流传着一个非常有名的关于歌德的故事。有一次，歌德和贝多芬在路上并肩行走。突然，对面来了国王的仪仗。贝多芬昂首挺胸，从国王的仪仗队面前挺身而过。歌德退到路边，摘下帽子，在仪仗队面前恭敬肃立。我想，这个故事向我们传达的就是对贝多芬的尊敬和对歌德的蔑视。在年轻的时候，我也认为贝多芬了不起，歌德太不象话了。但随着年龄的增长，我慢慢意识到，在某种意义上，像贝多芬那样做也许并不困难。但像歌德那样，退到路边，摘下帽子，尊重世俗，对着国王的仪仗恭恭敬敬地行礼反而需要巨大的勇气。

　　处处与世俗为敌，并不会让世俗变得清高。尊重世俗，也并不意味着失去清高，失去自我。

　　不要比拼清高，而要自己生活得幸福。当你能自由的游走于世俗的现实与内心卓尔不群的原则之间时，你也就实现在个人修炼的圆满，成为了一个从内心里幸福的人。

　　我们不需要成为清高之人，也不需要成为世俗之人，我们只要成为普通的正常人，一个外圆内方的人。

1.两极分化的程序员

　　相信在很多人眼里，程序员都是工作一丝不苟、对代码精雕细琢、精益求精的人。瞧，他们在电脑前面一坐就是大半天，如果不是追求完美之人，谁能这样坐得住板凳？

　　可是依我所见，在“追求完美”这个问题上，程序员其实是严重的两极分化。有一部分程序员确实对自己的代码要求很高，他们在编程时，非常注意逻辑是否严谨、运行效率高不高、代码是不是优雅，经常进行代码重构与优化。他们就像有洁癖农村老太，整天扫把不离手，在哪里看到不顺眼的代码，就要改到哪里，如果让他来维护一个系统，多半最后会让他把整个系统的代码全部重构或者重写了一遍。他们是真正的完美主义者。

　　还有一部分人，他们写代码似乎只是为了完成任务。他们对自己负责的功能，缺乏计划和设计的过程，想到哪里就写到哪里，最后按下F5，编译通过，欧耶！他们甚至不愿意多点一下自己创建的按钮，更加不会在一个身份证号码文本框中输入一个电话号码来测试一下，最关键的是终于可以向经理交差了，至于代码中多少隐藏的问题，以后再说吧。这让我想起了程序员部落酋长Joel所说的，他们编写的程序“看上去像是给狗吃的早餐，只要狗能吃饱就行了，何必再花钱让食物变得色香味俱全呢？”我们甚至可以想象一下，他们的电脑屏幕上是不是铺满了灰尘，键盘缝里是不是塞满了头发和食物碎屑，电脑桌面的图标是不是如七彩拼图一般，让人眼花缭乱。

　　后一类程序员，在数量上似乎占据绝对的优势，对于一个不擅于控制项目质量的项目经理来说，他们的代码最终会成为项目的噩梦。系统一旦投入运行，虫子就会像美国恐怖片中的外星生物一样，源源不断的从鼻孔、嘴巴和耳朵缝里冒出来。

　　第二种程序员这种低标准低要求、随随便便的做法，很容易被识别出来是一种不好的倾向，而完美主义不是这样，因为我们从小就被教导要追求完美，完美主义一般被认为是一种优秀的品格，是每个人应追求的目标。

　　然而完美主义虽然听上去不错，却并不适合于项目，因为项目的目标是用最少的成本来完成项目，让各方满意，而不是制造一个完美无瑕的产品，以证明个人或公司的能力。显然，完美主义更适合于个人能力的修炼，或者一项没有限期出成果的科学研究，在项目中，完美主义也是一种错，虽然是一种“美丽的错误”。

　　完美主义者和随随便便的人，这两种程序员都不是项目的最佳人选，他们是恰好是两个相反的极端，如果让他们负责项目，估计就像玩跷跷板一样，要么压到地底下，要么翘到天空上。但是项目经不起这样的折腾，项目中需要有平衡能力的人，他们很好的把握追求完美的“度”，使得软件功能既能满足客户的应用需求，又不至于要花费过多的精力。可惜的是，这种程序员实在是不多，因为度的把握对程序员而言，确实不是一件容易的事情。

2.完美不等于质量100分

　　程序员心中的完美和项目经理心中的完美并不是一回事，因为两者关注中心不一样。程序员关注的是自己的软件功能本身，力争将软件产品质量做到最好，因此程序员的完美实际上是质量的完美。

　　而项目经理眼中，看到的是整个项目，包括质量、进度、成本、范围、风险等方方面面，需要进行平衡，花最少的成本、用最少的时间、达到各方满意、实现项目验收，这就是完美。单纯产品质量一流，而进度拖延、成本超支，这显然不是什么完美的项目。

　　其实现代质量管理理论普遍认为，质量并不是越高越好。事实上，市场已经对此无数次给出了证明。很多人骂过微软公司的产品烂，据说乔布斯也曾经大骂windows是坨屎，但微软公司后来却成了软件行业的霸主。

　　ISO9000对质量的权威定义是：一组固有特性满足要求的程度。看到了吧，是满足，而不是超出，这非常重要。不要少，少了通不过；但也不用多，多了便是浪费。我们需要的不是100分的质量，甚至也不是一流的质量，而只是满足要求的质量。

　　在项目管理中有一个名词叫“镀金”，也就是在产品达到客户要求后，再多做一些额外的工作，让产品更加完美，以进一步提升客户满意度，这在PMBok中是一种被明确禁止的行为。软件质量100分，在项目中不但是一种巨大的浪费，而且几乎是一个不可达到的目标， 只会让项目不堪重负，最后陷入灾难的境地。

3.合格就是完美

　　追求完美本身并没有错，但如果上升到完美主义，时时处处要做到最好，却不一定符合当时当地的条件限制。一个“最”字会害死人，因为“没有最好，只有更好”，如果一味追求更好，其结果可能就如陷入焦油坑的怪兽一般，无法自拔。在这样一个讲求效率的时代，完美主义更是可能会造成机会的丧失。因此，要保持追求完美的心，但又要懂得权衡，不要陷入极端的完美主义的陷阱。

　　要完美不要完美主义，本质上是一个度的问题，项目应讲求平衡，避免极端。学过项目管理理论的人都知道，项目管理中有一个“铁三角”，也就是在一定的项目范围的约束下，成本、进度和质量构成三角形的三个端点，为了让三角形面积保持不变，任何一个端点的变动，都会引起其他一个或两个端点的同步变动。这个铁三角本质上就是一种平衡和制约的关系，而完美主义，则只单纯的强调质量，而忽略了其它方面的因素，这显然是一种极端的行为。

　　那项目中质量的“度”倒底是什么呢？其实就“合格”二字。合格意味着被认可，却不需要达到优秀的代价。客户认可、领导高兴、员工轻松，这不就是完美吗？可以说项目中没有最好，只有合格，合格就是完美。

4.“70分主义”

　　从小老师和书本就教育我们要追求完美，考试要考100分，90分都嫌太低，那70分还拿得出手吗？

　　其实70分不低了，要知道现在大学生的口号是“60分万岁，多一分浪费，少一分作废”。当然这种口号容易被批评为不思进取，但万物存在就有其合理的一面，“60分万岁”也是事出有因。

　　在学习方面，我是主张完美主义的，前提是学的是个人感兴趣、有用的、切合实际的东西，可以我们大学的大部分课程，基本上是背道而驰。上课、考试，无非是为了不挂科，顺利拿到毕业证和学位证。这种情况下，60分万岁也就容易理解了。何必要考100分，节省下来的时间，完全可以用来学习自己更感兴趣东西。

　　从某种程度来说，做项目也是一种考试：有考试内容（项目范围）、考试时间（进度要求），还有及格线（质量要求和验收标准）。项目的及格线如果用分数来表示，也是60分，既然60分就够了，为什么还果提出“70分主义”呢？其实很简单，因为要想刚好考60分，实在太不容易了，搞不好就会弄个不及格。所以我提出“70分主义”，一种超越完美主义的新主义，力求在及格和完美之间达到平衡。

　　项目如果以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.程序员需要一点执着精神

　　《士兵突击》中许三多有一句名言：“不抛弃、不放弃”，这是一种可贵的执着精神。正是靠着这种不抛弃、不放弃的执着追求，许三多从一个普通的小兵，成长为团部的精英。在现实生活中也是这样，可以说大凡取得一定成就的人，在工作中都是一个执着的人。

　　对程序员则言，执着精神尤为可贵。在编程过程中，我们难免会碰到各种问题，如果没有一点执着精神，一碰到问题就抱怨、回避，怎么可能取得技术上的突破呢？又怎么能体会到解决问题的快感呢?

　　回想起我刚入门学习GIS（地理信息系统）编程时，经理就给我安排了一个之前让不少人望而却步的难题，用MapObjects实现地图符号化，要求具有自定义符号库的功能。以我当时的经验，根本不知道从何下手，但也只能硬着头皮上。首先我把MapObjects的帮助文件全部仔仔细细看了一遍后，找到一个CustomDraw接口。但是只是一个接口而已，离完整的符号化功能还相差很远。怎样利用这个接口呢？当时网络还很落后，网上的编程资料更少，关于MapObjects的中文开发资料则几乎没有，于是我又通过蜗牛速度的网络，查阅国外的相关英文资料，在片言只语中寻求灵感。那一段时间我无论是吃饭、睡觉，还是走了路上，无时无刻不在思考技术上的问题，由于坚持不懈的努力，我一次次获得小小的启发，一步步接近问题的解决之道。6个月艰苦摸索之后，我终于彻底搞定了这个在公司内公认的难题，我本人也从一个门外汉，一举成为了公司的核心技术人员。这一段时间，我不但把MapObjects每个接口弄得烂熟，还学会了一百多个Windows API的使用，无论是技术方面，还是个人的职业生涯，都取得了一次飞跃。

　　程序员都需要一些执着的精神，来磨炼自己、发展自己，要有水滴石穿的决心和勇气，才能够成为真正优秀的程序员。

　2.自省消除固执

　　固执和执着一样，都是一种坚持不放弃的精神，既然如此，那为什么人们总是赞美执着的人，对固执却嗤之以鼻呢？

　　其实两者的差别全在于坚持的方向。执着和固执，就像一根绳子的两端，虽然是在同一根绳子上，方向却相反。执着是沿着正确的方向前进，是一种理智的坚持，而固执则恰好相反。既然都是坚持，那怎么判断方向是否正确呢？

　　其实，何为正确，何为错误，两者之间并不是泾渭分明，不然，也就不会有那么多“执迷不悟”的人了。方向是否正确，往往是以结果来衡量的。因此是执着还是固执，其实主要是结果导向，结果好就是执着，结果不好，就是固执。爱迪生发明灯泡的时候，经历了无数次的失败仍然坚持不懈，最后终于找到了用钨丝作为灯丝方法，取得了成功，他的坚持我们称之为执着。后来，爱迪生创立了通用电气公司，坚持用直流电供电，无视交流电在远距离传输方向的巨大优势，最后输给了采用交流电方案的西屋电气公司，他自己也只黯淡离开自己创立的公司，这时候，我们只能说发明大王也有固执的时候。

　　如此说来，难道我们非要等要结果发生，才能知道自己的坚持是对是错吗？有没有办法让我们在进行过程中就能出判断呢？这只能靠我们的自省。孔子曰：“吾日三省吾身”，大凡善于自省的人，都不会是固执的人。他们能随时察觉自身的问题，具有理智的否定自己的勇气。

　　自省需要常识。对于一个不具备常识、不明白对错、不理解基本规则的人，怎么能正确判断方向呢？这样的人再怎么自省也是无济于事的，他只有在不断的碰壁中才能获得真正的成长。

　　我曾经见到一些程序员，在自己的想法与项目经理发生冲突时，总是一味的坚持，不肯让步，甚至与项目经理陷入无休止的争吵，还以为自己掌握了真理。殊不知，与上司顶撞是一种愚蠢的行为，这种过分的坚持，会在上司心目中形成不听话的印象。更何况，服从上级工作安排是基本的职场规则，你可以提意见，但必须尊重上司的决定。毫无疑问，在这场对峙中，不管理项目经理对错，程序员都是固执的一方。如果程序员具备这些基本的常识，并且保持自省，也就不会发生这样的事情了。

　　自省还需要具有突破思维舒适区的勇气。每个人的都有其思维舒适区，这里一切受潜意识的保护，一切都似乎理所当然，我们的大脑无需对事物做过多的思考，爽爽的享受这种自我封闭带来的轻松和愉悦。毫无疑问，思维舒适区阻挡了我们对事物深层次的探求，以及我们对不同观点的接纳，因而也就无法对自己所坚持的东西做出真正客观的分析。

　　在程序员与项目经理的争吵中，其实双方都应该勇敢跳出自己的舒适区，心平气和地考虑，对方的观点是否也具有可以接纳的成分，做一个理智的坚持者，这样才能做到双赢。执着还是固执，往往也就只是在一念之间的差别。

　从程序员转为项目经理，这是一个巨大的跨越。一个新任的项目经理，对项目管理找不到感觉，一般也被认为是一件正常的事情。这是否意味着，一定要等到当上了项目经理才能学习项目管理吗？一定要做砸一个项目才能成长为合格的项目经理吗？其实未必，项目管理所需要素质和技能并不是什么独门秘籍，而是在生活中时时用到、处处可以锻炼的。只要有心，程序员一样可以学习和实践项目管理知识。从某种程度来说，我们每个人都是管理者。

　　1.管理是职能而不是职位

　　管理学之父彼德.德鲁克曾说：“任何一位做决策的人，其工作性质和董事长，和行政领导相同。即使他的管辖范围有限，甚至于他的职能或他的大名，不见于组织系统里，办公室连专线电话也没有，但他确实也是一位管理者。”

　　可见管理并不是经理、老总的专权，管理不是个职位，而是个职能。无论你在什么岗位，也不论你有没有下属，只要你需要做出决策，需要对结果负责，那你就是个管理者。从这个角度来说，我们每个人都是管理者，因为每个人都需要对自己的生活的工作负责，对碰到问题进行权衡决策，只不过决策的内容不一样而已。

　　程序员显然也需要对工作进行决策。当接受任务时，程序员需要对工作量、工作难度、时间限制进行评估，以确定能否实现项目经理的目标；开发一个功能点时，我们需要思考哪些实现方式，哪种方式开发速度、运行效率、对资源的占用几个方面综合最优；最进度滞后时，是要加班赶回来，还是要调整工作方法，提高开发效率……这些不都是决策的过程吗？在每一个决策点，程序员完全可以像一个真正的项目经理一样，发挥其主观能动性，主动进行管理，保证任务又快又好的完成。我们的管理才能，就在这一次一次的决策过程中，逐步积累、逐渐提高。

　　管理只是一项职能，人人都可以随时随地履行这项职能。可惜的是，很多人没有意识到这一点，不自觉的放弃了这项可以做而且应该做的工作，这不能说不是一种“失职”啊。

　　2.自我管理是一切管理的基础

　　管理有一个流行的定义，叫做“管人理事”，既然是管人，那必须得有人可管。有人说，我没有一个下属，只是一个“光杆司令”，要说我是管理者，那我都管了谁呢？

　　其实只要在社会中，没有谁是真的光杆司令，你管理的不一定是下属，每一个你需要打交道的人，包括你的领导，都是你的管理对象。退一步讲，即使你不需要跟任何人打交道，你也可以、而且必须管好一个人——那就是你自己。

　　彼德.德鲁克说过，“有伟大成就的人，向来善于自我管理。然而，这些人毕竟是凤毛麟角。但在今天，即使是资质平庸的人，也必须学习自我管理。”试想一个连自己都管不好的人，怎么能管得好别人呢？更别说管好一个大的团队了。

　　那自我管理该管些什么呢？李嘉诚先生曾说：“自我管理是一种静态管理，是培养理性力量的基本功，是人把知识和经验转化为能力的催化剂。”如果更加直白的说，自我管理实际是一个修身的过程，是一个自我约束、自我磨炼、自我精进的过程。作为一个普通人，哪些方面需要磨炼和精进呢？我想无非是一个人的身心和素质技能两个方面，相应的，自我管理的内容也应该是包括身心管理和个人素质技能管理两个方面。

　　（1） 身心管理：包括身体、心态、情绪、世界观、人生观、价值观、人生目标、职业目标等不同层次；

　　（2） 素质技能管理：包括学习管理、时间管理等。其中时间管理时自我管理中非常重要的一环，因为它与项目管理、企业管理等内容直接交织在一起。要成为一个卓有成效的管理者，首先就是要能管好你的时间。

图 自我管理是其它管理的基础

　　既然自我管理是一种修身，那也就可以说，自我管理是其它一切管理的基础，因为不论是什么管理，都离不开管理者自身的身心和技能。一个企业中的所有管理工作，从管理的对象来说，可以分为管理者自己、企业中的人和事、企业组织本身以及企业战略方向几个层次，其中管好自己属于最为基础的层次。一个能管好自己的人，才有能力、有精力管好别人，处理好复杂的事务，才能够通透人性，把握组织和市场的规律，成为一个真正卓越有管理者。

　　3.每个开发任务都是一个微型项目

　　作为一个程序员，也许你从来没有把自己放在项目经理的角度来考虑过问题，但实际上，你不只是一个程序员，同样是一个项目经理，因为每次接受了一项开发任务，实际上就是接受了一个小项目。

　　一项开发任务，同样具备项目的典型特征：临时性、独特性和渐进明细。临时性是显然的，因为每一项开发任务都有开发时限，而不是重复无休止的工作，当目标达到，任也就结束了。同时每一项开发任务又是独特的，时间、地点、完成人、成果、项目环境等，总有一样是不同的，就便是其独特性。越往后开发，对细节的把握越具体，这渐进明细。

　　由此可见，一项开发任务就是真真实实的一个微型项目。只不过这个项目，只是由你一个人来完成而已。在完成任务的过程中，同样需要像管理项目那样，进行计划、时间安排、偏差控制和领导（自我领导）。

　　把自己当项目经理的程序员，才能成为真正优秀的程序员。优秀的程序员，也更容易成长为优秀的项目经理，因为在被正式任命为项目经理之前，他已经负责开发过了无数个微型项目。

对很多项目经理而言，是没有什么所谓的“我的时间”的，因为他们不是在管项目，而是被工作的潮水带着跑而已，他们的时间被工作主宰了。项目经理必须要主动的管理自己的时间，合理安排自己的工作，才能真正“翻身”做自己时间主人。

　1.谁动了我的时间

　　时间对于每个人而言，都是最稀缺的资源，对于一个管理者更是如此，时间不够用成为几乎所有管理者共同的问题。如果要对项目经理常说的话做一个调查的话，想信“我很忙”一定可以名列前茅。以我的经验，当要求项目经理按时提交项目材料，或者临时支援某件紧急事务的时候，经常会听到同样的回答：“我很忙”。

　　多年以前，我就从经理那里听说，厉害的管理者都是很轻松的，因为他的工作全部交出去了，根本不用自己操心，所以他们出去度假十天半个月，一切工作都会如常进行。从那时起，我就充满了对管理的神往，可是后来我才发现原来这只是个传说，现实中忙忙碌碌的经理比比皆是，而轻松自如的管理者则是众里难寻。

　　为什么管理者都这么忙呢？是谁动了他们的时间？实际上，这是一个综合性的问题，既有内部原因，也有外部原因，既有主观原因，也有客观原因。总的来说，让经理们不堪重负的因素有三：

　　(1)工作

　　对于一个程序员来说，他的工作是比较单纯的，基本上是单线程运作，只需要项目经理交待开发任务即可，可是当上了项目经理就不一样了。以前好比在游泳池中游泳，现在是在大海里冲浪，各种事情如潮水一般向你涌来，让你顾此失彼，手足无措。

　　(2)下属

　　下属也是一种资源，即人力资源，这种资源与时间一样，同样具有稀缺性。其实我们可以设想一下极端情况，如果你的下属人数足够，能力也很强的话，你完全可以像我的经理说的一样，把你的全部工作授权给你的下属，你自己也就不用整天焦头烂额了。

　　因为你的下属不给力，所以你总是要自己来制定计划、自己来做系统架构、自己来监控进度、自己来检查质量、自己来写文档、自己来汇报工作、自己来解决重要问题、甚至自己来编写代码，你整天忙忙碌碌，就是在忙这样的事情。

　　然而，千万不要怪你的下属，因为他们不给力正是老板雇佣你的原因，况且资源的稀缺性是永远存在的——从原始社会到将来的共产主义社会。要知道，老板做项目为了赚钱，而不是让管理者更轻松，如果每个项目都是精兵强将，你只要一声令下工作就会自动完成，你倒是轻松了，但老板还要你来做什么？

　　(3)自己

　　既然资源受限是一定的，项目经理还是应该反求诸己，从自己身上找到解决之道。这就好比天下雨了，你怪老天是没有用的，只能怪你自己没有带雨伞。经常问一问自己，我对工作安排合理吗？我抓住了主要问题吗？我在旁枝末节的事情上浪费时间了吗？我有充分发挥下属的能力吗？我自己工作拖拖拉拉吗？…通过不断的自省，改善自己的管理方法和行为习惯，我们对时间利用也必然会变得越来越高效。

　2.时间管理的本质是对工作的梳理

　　要破解忙的难题，必须要有意识的对时间进行管理。其实时间本身是没法管理的，因为无论你怎样管理，时间既不会变多，也不会变少，既不会变快，也不会变慢。所谓的时间管理，其实就是如何更有效的利用时间的问题，更加直白地说，其本质就是工作管理，即通过对工作的梳理，让我们在有限的时间内，使得工作更有条理、更有成效。

　　必须要主动、有目标地对工作进行梳理，这是对一个管理者的基本要求。工作梳理就好比整理房间，你不去整理它，杂物就会堆积得越来越多，你房子最终会变得不适合人类居住。一个好的家庭主妇，必定善于将各位物品分门别类，并且适时扔掉一些用处不大的物品。一个好的项目经理也一样，同样需要对工作进行分类，对不同类型工作采用不同的策略，有些工作要现在就做，有些可以晚点做，或者不做；有些工作一定要自己做，有些工作则可以请其他人来完成。

　　通常对工作梳理，可以采用5W1H法，即：

　　Why——为什么干这件事？（目的）；

　　What——什么事情？（对象）；

　　Where——在什么地方执行？（地点）；

　　When——什么时间执行？什么时间完成？（时间）；

　　Who——由谁执行？（人员）；

　　How——怎样执行？采取哪些有效措施？（方法）。

　　在一般的项目中，Why和where往往不是什么问题，或者说对项目经理的时间管理影响较小，因此我们不妨将其简化为3W1H，也就是确定要做什么，不做什么；先做什么，后做什么；谁来做；怎样做才更有效。基于此，项目经理可以按以下三个步骤来梳理工作：

　　（1）分析要做什么、不做什么，以及先做什么、后做什么

　　解决What和When的问题。事有轻重缓急，事情的重要程度和紧急程序直接决定其处理的优先级。虽然很多事情来势汹汹，但并不表示一定要当即处理，有些事情只是静静的躺在那儿，也并不意味着要“等有了时间再做”。

　　（2）分析由谁来做

　　解决Who的问题。虽然我们提倡项目经理要以身作则、亲力亲为，但并不是说每件事项目经理要亲自去做。对于下属可以胜任的事情，就把它分配出去。如果出现项目经理很忙、下属很闲的情况，那就说明项目经理你做得太多了，不要和你的下属抢事情做。

　　（3）如何让工作更有成效

　　做不做、什么时候做以及谁来做的问题都解决了，剩下就要解决怎么做才能让工作更有成效的问题了。在这里我们不是要讨论编码或写文档的技巧，而是个人的习惯和认识，这对工作成效的影响更是本质上的。

　3.做事要分轻重缓急

　　老外就是善于总结，中国有词语叫“轻重缓急”，可是到了国外摇身一变，变成了“时间管理四象限法”——自从美国总统艾森豪威尔提出以来，人人将其奉为圭臬，成为时间管理领域最重要的方法论。

　　所谓的“四象限法”，就是将工作按照重要程度和紧急程度两个维度进行分类。我们找一张白纸，以紧急程度为纵轴，以重要程序为横轴，在纸上划上一个十字，将纸面分为四个象限，然后将当前所有要做的工作放到这个四个象限中。

　　一个典型的项目经理四象限图如下所示：

　　（1） 第一象限：重要紧急

　　这一类往往是火烧眉毛的事情，需要马上去处理，否则项目会受到重大影响，比如客户服务器崩溃。

　　（2） 第二象限：重要不紧急

　　这类事情一般是预防型的工作，例如制定项目计划、团队建设等，它们不需要你停下手上的工作马上去做，但如果没做好的话，可能就会导致产生项目危机。许多第一象限工作产生的原因，正是因为第二象限的工作没有去做。

　　（3）第三象限：不紧急也不重要

　　这类事情看上去最不需要做了，例如上网偷菜、看新闻、写博客等，但如果你在办公室走上一圈，就会发现很多人正在干着这些不需要干的事情。

　　（4） 第四象限：紧急不重要

　　这类事情虽然不重要，却需要马上去处理。一个典型的例子就是桌上的电话响了，你接还是不接？当然要接，因为你不知道是谁。接通后，发现是推销保险的，你又不好意思立即挂掉，只好被对方折磨一番了。

　　我们到底该怎样安排四个象限的工作呢？对于一个普通的管理者，其工作的优先级一般是这样的：第一象限>第四象限>第二角限>第三象限。可是，等做完了第一、四象限的工作，根本就没有时间来人做第二象限的工作，于是项目到了后期项目经理只好四处救火。

　　管理大师彼德.德鲁克十分推崇“时间管理四象限法”，并将其总结为“要事第一”的原则。根据这个原则，每个象限的工作处理策略是不一样的。

　　（1）重要紧急

　　优先级最高，需要尽快处理。很多人都玩过《植物大战僵尸》的游戏吧，那你一定知道“一大波僵尸正在逼近”的感觉，是的，你必须要马上打死它们，不然它们就会冲进你的房子，吃掉你的大脑！

　　（2）重要不紧急

　　这类事情看上去可以暂缓，但考虑到其重要性，应当与第一象限的工作并行去做。如果不及时去做，它们就会转移到让你头疼的第一象限中去，或者在第一象限产生更多新的“僵尸”。所以，要在僵尸还没有逼近的时候，就好防御工事，并尽快打死它们，如果等到它们冲了过来，你还能不能保住大脑，就要看你的运气了。

　　（3）紧急不重要

　　它们就像是在你耳边“嗡嗡嗡”地叫着的苍蝇，你必须要花时间去赶走它们。这多少让人有些无奈，但这些事情确实层出不穷。有些公司在实施紧急项目时，经常采用封闭式开发，这样做的一个重要原因就是要回避那些紧急不重要的事情。很多管理专家建议我们在必要的时候勇敢说“不”，其实就是针对这类事情。如果实在无法说不，建议安排或委托其他人来做。

　　（4）不紧急也不重要

　　如果不是时间充裕的话，建议不要去做。如果碍于人情的话，建议安排或委托其他人来做。它们就像一群在几百米远处飞的苍蝇而已，你完全不必要放下手中的饭碗，举起苍蝇拍跑过去和它们决斗。

　　因此，对于一个卓有成效的管理者，其优先级应该是这样的：第一象限=第二象限>>第四角限。第三象限就像数学中的无穷小一样，被舍弃了。

　　写到这里，我想起了前不久一位项目经理的故事：

　　项目定于当天上线，项目组决定搬到客户现场办公，以应付可能出现在的突发事件。项目成员电脑已经全部打包好，都围在项目经理周围等待。原来项目经理正在理一大堆发票准备报销，于是发生了这下面这样的对话：

　　我：“大家都在等你，怎么还在填报销单呢？”

　　项目经理：“今天是公司的报销日，不填好单子，又得推后很久。”

　　我：“你的电脑打包了没有？”

　　项目经理：“没有”

　　我：“放行条开了没有？”

　　项目经理：“没有”

　　我：“申请用车了没有？”

　　项目经理：“没有”

　　我不知道说什么好了。要知道公司的报销单粘贴和填写非常严格，经常被打回重新弄，那一堆发票，显然不是十几分钟可以搞定的事情。还有公司的用车也比较紧张，不赶紧申请，说不定就没有了，到时就只能租车或打的，这无疑又会耽误更多的时间。更何况六七个同事都在等项目经理一个人，耽误的时间还得要乘以他们的人数。万一系统上线，状况频出，客户火烧眉毛，项目组却仍然在路上，这样的后果是很严重的。

　　贴报销单看上去一件重要紧急的事情，实际上它既不重要也不紧急，因为今天不报销，以后还是可以报销，可是因此耽误的宝贵时间，却无法再要回来。如果项目经理更加理智一些，分清楚什么才是真正紧急重要的事，也就不会出现这样的状况了。

对很多项目经理而言，是没有什么所谓的“我的时间”的，因为他们不是在管项目，而是被工作的潮水带着跑而已，他们的时间被工作主宰了。项目经理必须要主动的管理自己的时间，合理安排自己的工作，才能真正“翻身”做自己时间主人。

　4.管理者无需事必躬亲

　　有一种类型的管理者，他们不论什么事一定要亲自去做，至少也是亲自过问。人们习惯用一个成语来赞美他们，叫“事必躬亲”，仿佛诸葛亮再世一般。凡事亲自去做未必真的可取，为什么诸葛亮只活了53岁，恐怕跟他这种事必躬亲的精神也有莫大的关系吧——他是把自己累死的。

　　（1）不要和下属抢事做

　　管理者相对于操作层员工，多了一项法宝，就是授权。理论上，只要员工可以胜任，所有的工作都可以授权。事实上，总经理为什么能对全公司发号施令、对工作进行变革，那是因为董事会授予了这个权限。连这么高层的工作都可以授权，一个项目里面的工作还有什么不可以授权的呢？

　　因此，当你疲惫不堪的时候，就应该问问自己，我是不是管得太多了？如果一件事情下属能做，就应该让下属去做，不然等于是你抢了下属的工作。项目经理最可悲的事情就是，自己累得半死，项目组成员却闲得发慌。

　　管理者必须学会授权。授权不只是为项目经理分担工作，也是项目培养下属成长的必要方法。如果项目经理总觉得下属能力行，不给他分配具的挑战性的工作，这显然不利于下属的能力成长，从长远看，对项目、对公司也是有百害而无一利。

　　（2）授权绝不是简单的把工作交出去

　　授权两个字说起来简单，但做起来效果却会因为而异。有效的授权必须把握以下几个要点：

　　l 目标明确：要做什么内容、达到什么质量要求、什么时候完成等等，必须要清晰具体。管理学家们认为目标必须要SMART（S=Specific、M=Measurable、A=Attainable、R=Realistic、T=Time-based），这是很有道理的。

　　l 跟踪反馈：项目经理应当经常性对任务完成情况进行检查，这是很多项目经理非常欠缺的一个重要环节。只授权不检查，最后的情况可能就是进度大大延迟，或者与你想要的东西大相径庭，下属进行种种解释，但为时已晚。

　　l 能力辅导：项目经理要对下属的能力有比较准确的把握，安排工作也应该在其力所能及的范围。如果跳一跳能够得着，就比较理想，但项目经理仍然需要主动辅导，加强监控，当发现偏差时，应及时采取应对措施。如果工作大大超出其能力范围，再怎么跳也够不着，项目经理就要另想高招了。

　　（3）不做甩手掌柜

　　是不是任何事情都可以授权呢？理论上是可以，但由于资源的稀缺性，这种条件往往并不具备。至于什么可以授权，什么不可以，这要因项目而异，根据项目工作与资源的实际情况，两厢权衡之后才能决定。不管怎么说，授权不可过度，否则项目经理就成了甩手掌柜，实际也等于放弃对项目的控制权。

　　项目经理应该做的工作：

　　l 系统性工作由项目经理做，比如制定计划、安排任务、鼓舞士气、项目检查等，具体事务由下属去做。

　　l 重要的事情项目经理来做，紧急的事情让下属去做。

　　l 决策由项目经理来做，执行由下属去做。

　　l 下属能做的事由下属去做，否则由项目经理自己做或带着做。

　5.好习惯让工作更有成效

　　高尔基曾这样来描述时间：“世界上最快而又最慢，最长而又最短，最平凡而又最珍贵，最易被忽视而又最令人后悔的就是时间。”的确，时间是快还是慢，是长还是短，不在于钟表是的指针转了多少圈，而是在于在我们如何使用时间。一个人的习惯，对如何利用时间具有至关重要的作用。

　　（1）尽力避免返工

　　项目中最浪费时间的事情是什么？

　　是返工！

　　一旦发生返工，不但所耗时间将会成倍增加，而且会大大降低员工的成就感，打击员工士气，降低员工作效率，使得项目时间进一步滞后。

　　我见过一个城市三维模型制作的项目，经过一年多的辛苦工作，终于提交成果了，但是由于客户认为模型不够漂亮，最后几十平方公里的模型全部重做！项目组员工身心俱疲，公司遭受严重损失，客户也非常不满，一个三输的结局。

　　返工并不总是这样严重，其实在一般的软件项目中，返工现象也是大量存在的，只不过我们借着迭代的名义将其掩盖了。例如软件试运行后，客户要求将某项业务流程中的两个环节进行整合，或者将某个环节中的输入信息，转移下一个环节中。单个修改的工作量也许并不算大，但累积起来就相当可观了。很多项目在试运行后要修改几个月，甚至半年以上，这就是返工的代价。

　　迭代设计还是返工之间，并没有明确的界限。要区分二者，有两条标准：

　　一是迭代是计划之中的完善，而返工则是计划之外、迫不得已而为之的事情；

　　二是在工作量的层面，如果抛弃或被重做的功能工作量很大，那只能认为是返工，如果你非要认为这是设计就是要这样干的，那我只好给它取个新名字：“返工式迭代”。这也这给我们一个启发，做系统原型的时候，千万不要写大量的代码，否则的话，迭代最后会变成返工。

　　（2）打破帕金森定律的魔咒

　　英国学者帕金森通过多年的调查研究，发现一个规律：“工作会自动地膨胀占满所有可用的时间。”一个人可以在十分钟内看完一份报纸，也可以看半天；一个程序员开发一个功能，可以两小时完成，也可能花上一周的时间；项目经理制定计划，可以半天完成，也可能一个月还不见影子......总之，只要还有时间，工作就会不停的扩展。

　　帕金森定律就像一个魔咒一个样，困扰着很多人。它之所以起作用，表面上原因在于时间充裕，外部压力太小。因赖床而上班迟到的人常有，但因赖床而误飞机的则很少，因为误机的后果很严重。因此，有必要对每件工作确定一个时间期限——dead line，一过这条线dead！给下属安排工作时，这的确是一个好办法，但对于管理者而言，约束别人容易，约束自己则很困难。即使工作到期，还可以告诉自己，再推迟几天也没关系，这件事情还可以让某某来完成，即使到了dead line还可以说这件事其实不重要，少做一点没关系。

图 帕金森定律的魔咒

　　归根到底，还是在于我们的内心力量不够强大，面对一点点的外部阻力，就变得消极懒散，不能自我驱动。截止日期是靠不住的，要靠只能靠自己，养成良好的习惯，主动给自己压力和动力，战胜心中的“懒惰小人”，才能真正解除这个“帕金森魔咒”。

　　（3）合理利用时间

　　每个人都希望工作不被打扰，但作为一个管理者，你的时间不是自己的，你的上级和你的下属都有权来随时打扰你。你坐在那里，就会有人过来找你签字，找你谈工资，找你讨论技术问题，找你支援其他工作……每天的时间就这样被打成了无数的碎片，所以经理们常不由自主的感慨：“白天真的做不了事，只能晚上和周末才能工作”——加班才能做事，你说经理能不累吗？

　　的确，项目经理很多工作都需要大块时间，比如制定计划、编写文档、分析风险、关键技术实现等，都需要较长时间的思考。一个人要让心静下来，进入工作状态是时间的，一旦被打断，再次进入这种状态会花很多时间。这就好比炒菜，把锅烧热是需要时间的，你刚放下油，来了电话，等你接完电话，锅又冷了。

　　时间碎片的问题对管理者而言是不可避免的，但可以采取方法更加合理的利用时间，将其影响降到最低。

　　l 制定规则

　　例如约定在指定的时间签单、讨论技术问题、反馈进展等，而不是随时进行。

　　l 琐碎事情一起做

　　对于工作中的琐碎问题，不用急着处理，可以启动“碎片整理程序”，将其记录下来，在你不需要“炒菜”的时候一起处理。

　　l 利用碎片时间

　　碎片时间并非不可利用，而是要安排合理的工作。几块大石头中间的缝隙，肯定塞不下另一块大石头，但放一些小石子或沙子还是没问题。例如与员工沟通、向领导汇报工作、检查员工工作、辅导员工、项目风险分析、项目目标回顾、发传真、收邮件等，这些工作就是小石子一样，利用小块小块的时间就可以完成。

我经常听到老板经批评项目经理，做事一点章法也没有。所谓章法，就好比武术中的招式或套路，做项目没有章法，就会胡乱出招，项目要取得成功，那就好像猴子用打字机打出莎士比亚的作品一样希望渺茫。

　　要说项目管理的招式，最受欢迎的当数美国项目管理协会的《项目管理知识体系指南》（PMBok）了，他们提出的“九大领域、五大过程组和四十二个过程”，风靡天下，不懂一些的话，你不都好意思说你是项目经理。现在PMBok已经成为项目管理界的公认的全球性标准，国际标准化组织（ISO）以它为框架，制定了ISO10006标准。

　1. 项目经理成长的五个阶段

　　一个优秀项目经理炼成，并不是一朝一夕的事。特别是对于从程序员转型过来的情况，受制于其原有的思维方式、知识体系、管理经验乃至性格缺陷，往往要经过很长时间的才能逐渐胜任。我将这一过程分为五个阶段，每个阶段实际上也代表了一种类型的项目经理，以及项目管理的一层境界。

　　1. 混沌阶段

　　他们刚刚从程序员岗位上提拔为项目经理，也没有学习过项目管理知识，对项目管理完全处于是懵懂无知的状态。管项目基本上靠被动的等事情做，凭感觉去做，更可怕的是连感觉也没有。

　　如果用娃娃学走的来打比方的话，他们现在还是在襁褓中躺着睡觉的状态。如果项目就是一场马拉松，他们是没有机会到达目的地了，最后的结果只能是他的上司抱起他上路了。

　　2. 觉醒阶段

　　终于睡醒了，工作从被动到主动，这是一个巨大的飞跃。他们往往会维护一个事务列表，虽然这个列表往往只是项目的一部分工作，但比没有还要强多了。在他们眼里项目即等于产品，他们会有意识的将产品进行分解，按模块分给其他人做，然后一直往下做，什么到什么时候算什么时候，他们做事没有计划性。

　　他们算是会爬了。爬是慢了点，但总一天会到达终点的——如果有毅力能坚持足够长时间的话。

　　3. 入门阶段

　　处于入门阶段的项目经理，会有意识将项目划分为若干阶段，确定每阶段的可交付成果，并制定项目制定里程碑；有意识制定计划，并且希望按计划去做。对项目管理理论有一定了解，但缺乏深入理解。他们会有意识关注三大目标。他们的薄弱环节是控制和领导能力差，自己却没有意识到这一点，反倒将项目中的问题归咎于外部因素。许多有数年项目管理经验的项目经理仍然停留在这一阶段，这是因为他们不求上进的原故，以为天下的项目就只能做成这样了。

　　他们会走了。项目最终总是可以干到验收的，但返工或重做的现象经常会出现，并且往往员工的士气欠佳，其战斗力并不能充分的发挥出来。

　　4. 全面发展阶段

　　这一阶段项目经理不但具有比较丰富的实践经验，而且掌握了完整的项目管理理论知识，通过长期的学习、实践、思考、领悟、再实践，各方面的技能已经臻于完善。能顾及到项目中的方方面面，技能也比较全面，对项目控制和团队领导也颇有心得。

　　他们会跑了。是的，他们确实已经很优秀了，但我认为，到这一阶段才称得上真正合格的项目经理，你也许会觉得要求太高了，但马拉松赛场上的选手必须是跑着的，走完是赢不了比赛的。

　　5. 融会贯通阶段

　　他们逻辑性强，领导能力极强。他们不是照搬书上教导的知识来管理项目，而是凭借直觉，就能准确的把握项目中潜在的问题，并采取预防措施。他们有着非凡的领导能力，员工不但工作富有成效，而且能工作中得到快乐。到达这种境界，不仅是靠勤奋，还要靠天分。

　　这一类项目经理，不能用走路来形容他们了，他们就像天上的鸟儿一样，自由自在的飞翔。

　2. 把项目管理大卸九块

　　PMBok并不是专家们书房里琢磨出来的神秘东西，而中是将我们日常做事的方法进行提炼而已，项目管理本质是就是一套做事的思想和方法。PMBok将项目管理分为九大知识领域，其实也我们平时做事的思维息息相关。

我第一次参加项目管理培训的时候，那位老师非常循循善诱。第一天课堂上有一次令人难忘的对话：

老师问：“同学们，现在假设领导把你请到他的办公室，说请你做一件事事，你会问哪些问题呢？”

学生们纷纷回答：“具体要做什么事情，要求什么时候做完，做成什么样，还有有哪些人来做”

老师说：“很好。那对于自己做不了的事情，怎么办呢？”

学生：“请别人做！”

老师：“Very good!如果很多人一起来做一件事情，最重要的是什么？”

学生说：“每个人协调一致，统一思想和行动。”

老师：“Excellent!除了上面这些，还有什么需要考虑的吗？”

沉默片刻后，有一位学生回答道：“还要考虑一些可能会出现的问题。”

另一位学生接着回答说：“还要对所有的工作进行总体把控。”

老师惊喜的说：“Perfect!同学们，你们已经把项目管理的九大领域给总结出来了！请看下面这张幻灯片…”

　　老师展示的是这样的一张图：

　　这就是项目管理的九大领域：整合管理、范围管理、时间管理、费用管理、质量管理、人力资源管理、沟通管理、风险管理、采购管理。

　　项目管理好像一头大象，将其大卸九块之后，要装进冰箱就容易多了。

　　看看书上是怎样解释这九大领域的：

● 整合管理：包括识别、确定、结合、统一与协调各项目管理过程组内不同过程与项目管理活动所需进行的各种过程和活动。

● 范围管理：确保项目包括成功完成项目所需的全部工作，但又只包括必须完成的工作的各个过程。

● 时间管理：包括使项目按时完成必须实施的各项过程。

● 费用管理：包括涉及费用规划、估算、预算、控制的过程，以便保证能在已批准的预算内完成项目。

● 质量管理：包括保证项目满足原先规定的各项要求所需的执行组织的活动，即决定质量方针、目标与责任的所有活动，并通过诸如质量规划、质量保证、质量控制、质量持续改进等方针、程序和过程来实施质量体系。

● 人力资源管理：包括项目团队组建和管理的各个过程。

● 沟通管理：包括保证及时与恰当地生成、搜集、传播、存储、检索和最终处置项目信息的所需的过程。

● 风险管理：包括项目风险管理规划、风险识别、分析、应对和监控的过程。

● 采购管理：包括从项目团队外部购买或获得为完成工作所需的产品、服务或成果的过程。

　3. 五招四十二式

　　要把大象装进冰箱，分成九块还是太大了，还得切小一点。因此在PMBok第四版中，又将九大知识领域细分为42个过程，这些过程可以分为5个组，启动过程组、规划过程组、执行过程组、监控过程组和收尾过程组。这五大过程组42个过程，就是武术中的招式，可以直接用来实战中了，因此不妨称之为“五招四十二式”。

　　这一节牵涉到比较多的项目管理理论知识，如果你完全没有接触的过的话，读起来可能会比较困难，建议先啃一遍PMBok，或者跳过本节。

　　1. 五大过程组

　　五大过程组与九大领域一样，同样体现了做事的逻辑，只不过角度有所不同：

● 启动：确定是否要做，以及做什么

● 规划：打算怎么做

● 执行：按照计划去做

● 控制：做对了没有

● 收尾：做完了收工

　　可以看出，这是一个完整的做事流程。其中启动和收尾一进一出、一头一尾，就像我们常说的“做事要善始善终”，而规划、执行和监控则是项目的主体，与著名的“戴明环”（即PDCA循环）相对应，构成了一个循环。

　　在PMBok中用下面这张图来描述五大过程组：

图 PMBok中的五大过程组关系图（出自PMBok）

　　有人将五大过程组画成这个样子：

图 网上流传的五大过程组关系图

　　这张图广泛流传，但它其实是有问题的，就是把监控弱化了。跟PMBok中的原图比较，在这张图中，只有执行属于监控的范围，而在原图中，启动、规划、执行和收尾都是监控的对象，很明显，原图更加严谨。

　　很多人分不清五大过程组与项目生命周期的关系，两个概念确实比较容易混淆。生命周期，也是就一件事物从开始到结所经历的阶段，一个人的生命周期包括婴儿、儿童、少年、青年、中年、老年等几个阶段，项目也可以这样来分。为什么五大过程组和项目生命周期容易混淆呢？关键在于大过程组看上去很像是项目的几大阶段：启动→规划→执行→收尾，然而两者之间有着巨大的差异：

● 生命周期是从时间维度来描述项目管理，而五大过程组则是从职能的维度来理解的，告诉项目经理应该做哪些工作：项目经理你要做项目启动的工作、你要制定项目计划、你要组织和指导大家开展实施工作、你要监控项目、最后不要忘了做收尾工作！

● 五大过程组还体现在了项目的过程化思想，五大过程组本身即具有“输入-处理-输出”的关系（启动为输入，收尾为输出），而生命周期仅是前后贯通的时间序列。

● 生命周期是前后连接的阶段，而五大过程组是一个有进有出的环，在项目中大环套小环，有点像套娃娃。整个项目可按五大过程组的思路来开展，每个生命周期的阶段也可以，甚至一项细化的开发任务也可以。

图 项目过程组与生命周期的关系（出自PMBok）

　　五大过程组与生命周期同时也存在紧密的联系。实际上，启动过程组在项目生命周期的开始阶段作用最为强烈，收尾过程组主要作用于接近完成的阶段，而规划、执行和监控过程组则主要作用于项目的建设实施阶段，如下图所示：

图生命周期与项目过程组的相互作用关系（出自PMBok）

　　2. 四十二个过程

　　现在我们知道了项目管理有九大知识领域和五大过程组，那项目经理具体要做哪些事情呢？那就要看项目管理的42个过程了，做什么、用什么方法做、做出什么成果全在这里，这对于那些像无头苍蝇一样到处乱飞乱撞的项目经理来说，简直就是雪中送炭啊。然而别高兴得太早，早就听说过PMBok很难啃，它难也就难在这42个过程，每个过程都由输入、工具和技术、输出组成，千篇一律，就如同经书一般乏味，估计你看两个过程就会昏昏欲睡，所有以我也叫它“四十二章经”。

　　看一看42个过程的分布情况：

知识领域

项目管理过程组

合计

启动过程组

规划过程组

执行过程组

监控过程组

收尾过程组

项目整合管理

制定项目章程

制定项目管理计划

指导与管理项目执行

监控项目工作

实施整体变更控制

结束项目或阶段

6个

项目范围管理

 

收集需求

定义范围

创建WBS

 

核实范围

控制范围

 

5个

项目时间管理

 

定义活动

排列活动顺序

估算活动资源

估算活动持续时间

制定进度计划

 

控制进度

 

6个

项目成本管理

 

估算成本

制定预算

 

控制成本

 

3个

项目质量管理

 

规划质量

实施质量保证

实施质量控制

 

3个

项目人力资源管理

 

制定人力资源计划

组建项目团队

建设项目团队

管理项目团队

 

4个

项目沟通管理

识别干系人

规划沟通

发布信息

管理干系人期望

报告绩效

 

5个

项目风险管理

 

规范风险管理

识别风险

实施定性风险分析

实施定量风险分析

规范风险应对

 

监控风险

 

6个

项目采购管理

 

规划采购

实施采购

管理采购

结束采购

4个

合计

2个

20个

7个

11个

2个

42个

 　　如果你想看每个过程的详细讲解的话，那还是得自己动口、丰衣足食——动口啃PMBok。这里我们倒是可以对其进行简要解读，避免由于食物太硬引起消化不良。

　　● 看待项目的三个维度

　　PMBok中有三个重要的词：生命周期、五大过程组、九大知识领域，其实是看待项目的三个维度，即 ：时间维度、职能维度和管理对象维度。时间维度是要求项目经理将项目分成若干个阶段，逐步接近目标，项目更容易控制；管理对象维度是要告诉项目经理管什么，要关注什么，即范围、时间、成本、质量、人力资源、风险等；而职能维度则是代表要做什么，即要启动项目、规划项目等。

　　42个过程是按照后面两个维度进行划分的。为什么没有生命周期呢？这是因为不同类型的项目生命周期划分会千差万别，例如一个软件项目和一个房地产建设项目的阶段划分毫无疑问会相去甚远，而PMBok是适用于不同行业、不同类型项目的通用的指南，不可能将其固定下来。因此假如具体到某个软件公司，完全可以根据软件生命周期划分、参考PMBok中的过程，重新制定合乎本公司实际情况的项目过程，相信大部分软件公司的ISO9000文件正是这样干的。

　　● 关于规划过程组

　　 主要疑惑点在于“制定项目管理计划”与“制定进度计划”、“制定进度计划”等过程之间的关系。

其实PMBok已经明确说了，它们之间是总子划和分计划的关系。在项目管理计划中，同样可以包括这些分计划的内容。也就是说，只要你愿意，完全可以把规划过程组中的所有工作放到“制定项目管理计划”这一个过程中来完成——总计划把分计划中的事全干了。

　　● 关于监控过程组

　　监控过程组中一共有11个过程，这11个过程的关系是比较让人迷惑的。在整合控制中有“监控项目工作”和“整体变更控制”两个过程，它们与别外八个领域的中的监控过程是什么关系呢？

　　通过研究各个过程的输入和输出，可以发现“监控项目工作”过程产生的的一个主要成果是批准的变更请求，而该成果又是另外八个领域中的控制过程的输入，这些控制过程又都有一个重要输出是请求的变更——该成果又是“整体变更控制”的输入。由此，各个过程的关系浮出水面，如下图所示：

　　从图上可以看出，“监控项目工作”主要是发现问题，提出变更请求，而“控制范围”等过程，则是确定怎样变更，真正的进行项目变更的动作是“整体变更控制”。

　　● 关于启动过程组

　　启动过程组在两个过程：“制定项目章程”和“识别干系人”。按照五大过程组的特点，这两个过程在项目每个阶段之初都需要执行。难道我们在设计阶段和编码阶段都需要重新制定项目章程和识别干系人吗？

　　这看上去有点奇怪，在实际项目中，项目章程和干系人一般不会有什么变化，每个阶段都要重新做一次这个工作似乎有点牵强。在PMBok中关于项目章程有一段话是这样说的：“在多阶段项目的以后各阶段，制定项目章程过程的作用是验证原来为项目制定与颁发的章程所做的各种决定。这一过程在必要时还核准项目下一阶段并更新该章程”。原来如此，简单来说，就是看原来制定的章程还好不好使，不好使就需要更新了，算是能说得通。

　　同样，识别干系人也就是看干系人有没有变化了，但这与项目监控又存在一定的雷同了。我们可以设想一下，如果干系人发生了变化，我们一定需要等到一下阶段初才对做出相应的对策吗？显然不现实，我们会立即做出反应，而能随时识别变化并做出反应的过程只能是监控过程组了。

　　● 项目经理到底该做什么

　　曾经在培训课有一位老师告诉我们，项目经理主要做项目整合管理的工作。个人认为这种说法有失偏颇。

　　由于整合管理往往涉及多个领域，因此，由项目经理亲自把控是有道理的。但项目经理是不是只需要做项目整合管理，或者可不可以授权其他人来负责整合管理中有一部分工作，这就要视项目实际人力资源情况而定了。

　　如果你不幸领着一群毛手毛脚的毛头小子，那上面这个表里的工作只能全是你的了；如果你有几个得力干将，那就好办多了，授权嘛。整合管理中工作同样是可以授权的，没有谁规定一定要由项目经理来做。当然授权不等放权，绝不意味着放任不管，至于管到什么程度，只能由你自己拿捏了。

　4. 懂章法还要懂点心法

　　在武侠小说里，常有争夺剑谱之事，可是千辛万苦拿到剑谱，由于不懂“心法”，还是练不成。在项目管理领域，PMBok就好比是一本剑谱，项目经理要做什么、怎么做，书里面都有，但每个人运用起来，威力会大不相同。古人云：“运用之妙，存乎一心”，可见心法的重要性。

　　下面介绍一些项目管理的入门心法，帮助项目经理理解和运用书中的招式。至于高级心法在后续文章中会逐步介绍。

　　1. 项目管理是关于做事的方法

　　项目管理不是什么神秘东西，要以平常心来看它，它就是人们总结出来的一种有效的做事的方法而已。这种方法有几个要点：

　　● 以客户为中心

　　以客户为中心，看上去很简单，却蕴含着项目管理的终极秘密：让客户满意。记住，是让客户满意，而不是开发一个软件，或者完成合同内容，也就是说我们的关注重点是客户需要什么，而不是软件本身。为什么那么多项目开发了大量强大功能，客户仍不满意，就是因为我们没有把关注焦点放在客户身上，去琢磨客户真正需要什么，而不是客户说要什么；去琢磨怎样满足客户的实际应用，让他们用起来更方便，而不是需求文档写着什么。

　　● 以目标为导向

　　项目没有目标，就好像踢球没有球门，其重要性不言而喻。但是项目的真正目标并不一定等同于招标文件中提出的目标，招标文件是台面上的东西，是比较表面化的，而客户的真实目的也许并不在于此。因此，项目经理最好对项目的来龙去脉搞清楚，这样才能更好的把握客户心理，理解项目的重点，真正使到客户满意。

　　● 以计划为基础

　　项目计划在项目中处于非常基础的地位，项目的实施都应该按照项目计划来进开展。如果项目没有制定计划，或者虽有计划，却是说一套、做一套，那么这不叫项目管理，这叫打乱仗。没有计划，项目实施也就失去了依据，也更谈不项目监控了，项目管理中的42个过程，也就基本失效了。

　　● 以控制为手段

　　项目监控是很多人新任项目经理的薄弱环节，为什么那么多人说“计划赶不上变化”，其原因正是在于控制环节的缺失。项目不是一台机器，你只要启动马达，它就会按你设计的那样转个不停。项目的过程中产生偏差是正常现象，甚至是必然的事情，如果不加以控制，计划就会成为摆设，项目也会越偏越远，项目完工也就更加遥遥无期了。因此说控制是手段，是保证项目能按计划达到目标的手段，每个项目经理都必须主动监控项目，用好这一手段。

　　2. 结构化分析方法

　　还记得什么是结构化分析方法吗？说到它，很多人会想起数据流图、数据字典等等这些工具，但其内在的精神思想，即“自顶向下、由外到内、先整体后局部、逐层分解”，这才是它留给人们最宝贵的财富，

　　其实结构化分析法方不只是用于软件的分析设计，在人们生活的方方面面都有其用武之地，因为它是对复杂和大型事物的分析方法，符合人们对事物的认识规律。在PMBok中同样深刻的体现了结构化分析方法的思想。

　　首先PMBok本身就是一个自顶向下、逐层分解的知识体系。没有分解之前，项目管理是一个混沌的整体，PMBok将其按不同的维度分解为五大过程组和九大知识领域，然后又进一步分解为42个过程，每个过程又分解为输入、工作和方法、输出三个部分，这不正是完美的体现在结构化分析的思想吗？

　　项目经理组织项目实施更加离不开结构化思想。42个过程中有一个非常重要的过程是“创建WBS”，所谓WBS，中文名是“工作分解结构”，它其实就是一种按照“自顶向下、逐层分解”的思想建立的一种树形的项目任务清单，这是整个项目执行和控制的基础，如果你不会使用WBS，那基本上就也就等于说你不会管项目了。

　　结构化方法在编写项目文档以及汇报材料时同样有其用武之地。项目文档其实也是一种交流汇报的材料，为了能让别人看懂，我们先要把事情总体的讲一下，然后将其分为几个大点，每个大点可能又分成几个小点来讲，这样别人就有对你要讲的内容搞清楚了。我看过一本专门教别人写汇报材料的书，叫《金字塔原理》，其实也就是讲如何自上而下组织材料，让汇报变得更有条理。现在你懂了结构化方法，这本书你也就可以省了。

　　3. 过程思想

　　ISO9000有八项基本原则，其中一项就是“过程方法”，并将过程定义为：“一组将输入转化为输出的结果”。过程包括三要素：输入、活动、输出，对于这三要素，我想这三素对于程序员来说肯定不会陌生，因为我们在进行软件设计时，所使用的IPO图与它如出一辙，IPO图的三要素是“输入、处理、输出”，两者其实没有什么区别。也就是说，IPO图其实是表达过程的有效工具。

　　回到PMBok中五大过程组的那张图，它其实就是一张IPO图，它也有由输入-处理-输出组成，即启动-规划、执行、监控-收尾，由此可见，其实整个项目就是一个大的过程，同样，项目阶段也是过程。五大过程组又包含42个过程，每个过程都是由“输入、工具和技术、输出”组成，这与“输入、处理、输出”不是一回事吗？

　　需要说明的是每个过程并不是个独立的，而是相互关联和衔接的，前一个过程输出成为下一个过程的输入，从而形成了一个个过程链。下图是一个简要的过程链示意图：

图 项目管理中的过程链

　项目管理的三大目标即时间、成本和质量，实际是告诉项目经理应重点关注什么因素，项目控制应该做什么工作。三大目标虽然简单，但如果能将其真正贯彻到自己的行动中，那么对项目计划制定、过程控制等工作，均能起到引导作用。有了努力的方向，项目经理也就可以真正告别“盲目”了。

　1.我的第一次顿悟

　　（1）懂三大目标才算入门

　　我曾经也是一个混沌型的项目经理，每天浑浑噩噩，不要知要管什么，要做什么，在项目的大浪中随波逐流。直到有一天，我的上司在跟我聊天时说到项目有三大目标：时间、成本和质量，我当时就像被雷击一般，如梦初醒。时间、成本、质量，这不正是项目经理最应该要关注的事情吗？

　　这是我在项目管理方面的第一次顿悟。从这一天起，我才感觉自己像一个真正的项目经理了。也正是从这一天起，我才明白原来项目管理是有章可循的，我买来了项目管理的书籍，参加了项目管理培训，开始了新一轮如饥似渴的学习。

　　后来在工作中我每天都尝试着问自己这些问题：

　　l 时间：项目计划在什么时候完成？有哪些工作，分别在什么时候完成？是否发生了偏差？如果有偏差，怎么处理？

　　l 成本：项目计划花多少钱？每项子任务分别打算用多少钱（多少人月）来完成？是否发生了偏差？如果有偏差，怎么处理？

　　l 质量：软件功能完整吗？软件操作方便吗？运行结果正确吗？运行效率够快吗？软件代码符合规范吗？客户用起来满意吗？

　　我想如果能做到这些，项目管理也就算入门了。项目经理只有心中时刻谨记三大目标，行动才会有方向，才能真正主动、有意识的管理项目，也才能算是一个真正的项目经理。

　　（2） 三大目标就是“快好省”

　　项目管理的三大目标，其实是项目管理九大领域中的三块，分别代表花多少钱、多少时间、做成什么样，显然这些都是项目管理中至关重要的问题，如果项目经理连这三个问题都不关心，那也就没有什么可以关心的了。

　　周总理曾经提出要“多快好省的建设社会主义”，三大目标实际上与“快好省”是一致的。为什么没有多呢，因为“多”绝不是项目管理的目标，项目只需要完成规定的内容即可，如果以“多”为目标，那么项目永远都没有完工的一天。

　　（3）谁在关心三大目标

　　既然是三大目标，那应该是项目各方都非常关心的，其实不然。三大目标是平衡了项目业主方和承建方双方利益，为实现双方而综合考虑的结果。比如成本，就是花出去的钱，显然是承建方的命根子，但是业主方并不关心，签订合同后，你花多少钱跟他们有什么关系呢？他们才懒得理呢。而质量，虽然对业主方至关重要，但承建方却往往并不上心。为什么有那么多豆腐渣工程，就是因为承建方只关注成本，不关心质量的后果。

三大目标

买方（业主方）

卖方（承建方）

成本

合同签订后，项目实施成本基本上与客户无关。

关心程度：0星

成本要尽量低，对公司至关重要。

关心程度：5星

进度

要快，尽早投入使用。

关心程度：4星

要快，可尽早回收款项。

关心程度：4星

质量

质量越高，使用越爽。

关心程度：5星

质量越高，成本越高，质量太低不能验收。公司被迫关心质量。

关心程度：3星

　　从上表可以看出，业主方和承建方其实是存在一定的利益冲突的。项目经理必须能够平衡好双方的利益关系，要使双方都满意。时间、成本和质量，就像是构成木桶的三块板子，哪块板上有洞，木桶都是装不了水的。

　2.从三大目标到五大因素

　　所谓项目五大因素，就是项目三大目标加上范围和资源，它们是构成项目的基本要素。虽然管理专家们很少将它们并称，但鉴于它们的重要性，以及相互之间的紧密关系，有必要进行一些说明分析，以引起项目经理们重视。

　　（1） 项目五因素

　　如果说三大目标是项目管理中最重要的因素，难道项目范围、资源就不重要的了吗？其实它们也很重要，甚至可以说更加重要，因为它们是解决做什么与谁来做的问题，这五大因素都是项目经理必须要关注的问题。

　　那为什么单单把三大目标拿出来说呢？其实很简单，这是因为项目范围、资源其实是约束性因素，而不是项目目标。其中项目范围是客户对项目的约束，而资源是你的老板对项目的约束。用口语来说就是，有这么一摊事（范围），老板给你这么多人（资源），你把它干好，什么叫干好呢？就是费用不能超支（成本）、干出来的东西还要好用（质量）。

　　（2）项目约束公式

　　项目五大因素之间，并不是孤立的，它们之间的变化关系可以用一个简单的公式来表示，我们不妨称之为“项目约束公式”：

　　成本 = 范围 × 质量 = 时间 × 资源投入

　　根据这一公式，我们可以得到几个“推论”：

　　●项目范围、质量、时间和资源投入都与项目成本成正比。

　　●如果客户要求添加额外工作（范围变大），或者质量要求提高，那么项目实施成本将升高。当资源投入一定时，项目所用时间会变长。如果期限不变，则需要加大资源投入。

　　●预算不变的情况下，范围变大，只能降低质量，质量要求提高，只能减少范围（少做一点工作）

　　可见这五大因素这间，是对立统一的关系，它们互相制约，互相影响，又相辅相成，因此必须要进行总体控制，保证各个因素之间的平衡，这也就是项目管理九大知识领域中为什么有一个整合管理的重要原因。

　　（3）挣值管理的不足

　　在项目管理中，有一个著名的方法叫“挣值管理”，它是用计划进度、实际进度、预算成本、实际成本这几个值进行运算比较，用来衡量项目绩效的一种方法。该方法对推行项目的数字化管理有着巨大的推动作用，然而由于缺失了一个重要因素，使得这个方法存在着严重的不足。

　　这个因素就是质量。挣值分析只有成本和进度两个方面的因素，没有质量，将其用于绩效考核时免不了产生很大的漏洞。为什么会没有质量呢？这是因为质量难以用数字进行度量，特别是对于软件项目而言。虽然国标《软件工程 产品质量》（GB/16260-2006），提出了比较完整全面的质量模型以及度量的指标，但质量评价成本很高，而且很多指标经依赖于人的主观评价，实用性也就大打折扣了。相对而言，对进度和成本的评价，如果借助合适的信息系统，完全可以通过计算机自动实时生成，不需要人过多的干预，非常方便。

项目经理是否具有积极的心态，直接关系着项目的成败。很多情况下，项目经理并不是真的不愿意积极面对问题，而是觉得问题本身是难以解决的，只能听之任之。而事实上，一切问题都是可以解决的——这不只是一句口号，而是确确实实可以做到的。当你持有这想的信念时，解决问题的能力将会变更为强大。

　　1.我的第二次顿悟

　　项目管理培训并不是人人都需要，但对于渴望获得帮助以消化理论知识、尽快掌握要领的项目经理而言，还是很有必要的。我第一次参加项目管理培训时，说实话基本上什么也没有听懂，脑子里只留下了几个诸如“铁三角”、“二八法则”等等这样的词在盘旋。但通过这次培训，我知道了原来项目管理有一整套的理论和方法体系，并不是凭本能出招就可以搞定的，于是我开始系统性的学习这些知识。

　　但这不是我说的“第二次顿悟”，因为“第二次顿悟”给我的收获是让我以更加积极的态度来处理项目中的问题、来面对生活，这远比我学到一些具体理论知识重要得多。

　　这一次重要的领悟，起源于我参加的另一次项目管理培训的经历。在培训中，老师让我们做了我们很多训练题，其中有不少是案例分析，大致是讲某项目碰到了什么问题，问该怎么办？答案ABCD选一项。做这些题目的时候，我不由自主想到了公司项目的情况，其实与题目中的描述是如此的相似，而我们曾经那样的无助、不知所措，而老师每次给出的答案又是那样的不容置疑，这让我突然意识到，其实每个问题都是可以解决的，正如每个题目都有答案一样。

　回想起以前在公司的项目例会上，项目经理们总是一而再、再而三的提出一些类似的问题， 比如：

　　l 客户又改了需求，变化较大，工作量比较大，项目只能比计划拖延；

　　l 项目组新手太多，效率很低，干不不活，还要浪费时间来指导他们；

　　l 某某功能没有人做，放在那里，要等人腾出来再做；

　　l 某位骨干人员要离职了，项目进度要滞后了；

　　l 这段时间一直在做投标的事情，没时间管项目；

　　l 碰到了一个技术难点，公司以前没做过，一直卡在那里；

　　l ……

　　诸如此类问题层出不穷，它们如此让人头疼，却又无可奈何，就好像一个人身患不治之症一样，只能默默等死了。管理层面对这些问题往往也是哑口无言，以至于最后竟然也默认为它们确实不关项目经理的事，只能听之任之了。

　　现在再来思考这些问题的时候，才发现原来我们一直都在欺骗自己。这些问题虽然让人头痛，但并非毫无办法，它们也有其解决之道：

 

问题参考解决方法

客户变更需求

l 了解客户为什么要变更，很多情况是我们没了解客户需求，而不是客户要求在变

l 评估是否确实需要变更

l 是否有其它替代方案

l 是否可以放到下一期建设

新手太多

l 给新手安排合适的工作

l 多检查、多辅导

l 请求上级上调更合适的资源

有些功能没人做

l 向上级申请资源，说明问题的重要性与紧迫性

l 请求招聘项目人员

l 项目组赶工

l 利用项目缓冲时间

l 评估该功能是否在关键路径上，是否可以往后放，等人员腾出来再做

骨干人员离职

l 与他开诚布公的沟通，消除其心结

l 利用上级与他沟通，适当满足其要求，力求留住人才

l 如果真的离职了，参考上面“有些功能没人做”

项目经理忙投标，没时间管项目

l 加班。工作忙时只能如此。欲成大事者，不加班工作不可能

l 将投标事情分给比较工作宽松的下属来完成

l 向上级说明项目工作很紧，请求将投标工作安排给其他人

碰到技术难点

l 组织公司技术骨干讨论

l 去国外网站上找方案

l 在技术论坛上请求帮助

l 利用外部资源，如同学或熟人等

l 请求将该工作转给研发人员

　　原来这些看似很棘手的问题，还有这么多解决方法。即使这些方法都不奏效，项目经理也还可以做一件事，就是评估影响，申请项目变更——不要忘了，变更也是一个方法。在有些极端情况下，甚至需要放弃项目，也就是不做了，跟你的业主方说byebye，好聚好散。在必要时，连分手都是一个选择，但只有一条路，你永远不能走，那就是放任不管。要知道，回避问题永远是最差的选择。

　　2.项目管理就是解决问题

　　一切问题都有解决之道，这对我是一次非常重要的领悟，因为它改变了我对看待项目的心态。只有勇于面对问题，积极寻找解决的方法，才有可能达到目标。

　　（1）项目中充满的问题，要积极对待

　　项目有问题才是常态，没有问题那是特殊情况。项目经理应培养乐观心态，不要因为碰到问题就闷闷不乐，死气沉沉，试想，如果项目没有问题，那项目经理的价值何在？

　　当然有人说，项目经理应该预防问题，而不是解决问题。如果你能预防所有的问题，当然是好，但这几乎不可能发生。更何况，怎样预防问题，这其实是一个更难的“问题”。

　　面对问题，还要积极的去解决，而不是认为没有什么好办法、只能这样了。有些项目经理在被上级批评时，总是千方百计的辩解，这是一种非常消极的做法。不要以为你让上司也觉得无可奈何，就可以心安了，甚至还小小得意一番。不要以为上司点头了，就是在赞许你，其实他在通过每件事来评估你，看你究竟是平庸之辈，还是可造之才。

　　从“无可奈何”到“我可以想办法”，一个小小的变化，足可以实现从平庸到优秀的跨越。积极还是消极，主动还是被动，就在一念之间，而这一念，会直接影响到项目的结果。

　　虽然每个问题可以解决的，但每个问题都没有标准答案。怎样解决，需要具体情况具体分析，不存在一种简单的方法或规则，就可以解决所有的问题。这就像冲浪时，每个浪头的高度、方向、力度都不一样，冲浪者无法为自己设定一个固定的姿势，只能在浪头扑过来时，根据自己的经验来进行调整，否则很快就会被打翻。

　　（2）主动面对生活中的问题

　　生活中也与项目一样，充满的问题。俗话说：“家家都有本难念的经”，其实只要积极面对，人人都可以把这本经念好。

　　“一切问题都是可以解决的”，在生活中我也用这个观点来勉励自己。当与家庭成员产生矛盾时，我会想到，这是可以解决的，于是我主通沟通，让他们更加了解我的处境，我的真实想法，“理解万岁”这句话一点也没错，许多问题就这样化解于无形，这些都得益于我的这一次领悟。试想，如果我对生活中问题采用回避的方法，对其视而不见，矛盾必然会累积，总有一天会爆发。为什么总有那么多家庭因为鸡毛蒜皮的小事闹得不可开交，甚至弄得家庭破裂？可以说，不能积极主动面对问题，是一个重要的原因。

　　前几天在网上看到一则新闻，甘肃一男子嫌自己混得不好16年未回家，这就是一个回避问题的典型例子，不回家显然不能解决混得不好的问题，反倒让自己失去了16年的亲情温暖。在项目中，你会因为觉得项目执行不顺利不向上级汇报工作吗？其实越是有问题，就越应该汇报，争取上级的理解和支持，要知道你的上级往往有更宽的知识面、掌握着更多的资源，说不定他可以帮助你呢？

程序员和项目经理是两种完全不同的岗位，工作方式也大不一样。以前是一个人单干，现在是团队一起干，以前是自己亲自干，现在是指挥别人干，这是一种巨大的变化。要适应这种变化，首先必须要转换思维模式。思想决定行为，思维模式就好比在陌生城市找路用的地图，拿着过时的地图，自然无法到达想去的目标。思维不换走老路，思维一换天地宽。

　　1.从单干到群干

　　从程序员到项目经理，不只是职位的变化，其工作性质也发生了根本性改变，简单的说，是一个从单干到群干的过程。

　　严格来说，程序员并不是单干，他们也是在团队中，需要具有团队合作的精神，但其实程序员的工作具很强的单干的特征。在项目中，程序员的基本工作，也就是完成项目经理分配的开发任务，而这些开发任务，是项目经理或团队进行工作分解后的小的工作包，是一个确定的功能点，一个人足可以胜任，因此程序员只需要自己构思、自己编码就可以了，并不需要很多人一起来合作完成。

　　项目经理不一样，他面临的不是某个确定的功能点，而是整个项目，无法一个人完成，必须要整个项目组齐心合力一起来做，这就是群干，也就是团队作战。项目经理不只是自己需要团队精神，更要能够激发其他人的团队精神。

　　我们看一看程序员和项目经理两种角色的比较：

角色

主要特征

目标

主要工作

合作

技能要求

程序员

单干

完成项目经理安排的开发任务

编码

要求具有团队精神，能与其他人合作完成任务

开发能力

项目经理

团队作战

“快好省”实现项目验收，并使各方满意

制定计划、指导和安排工作、项目监控、团队建设等

使团队更具有合作精神，建设凝胶型团队

领导力（管人）

执行力（理事）

　　正如黄健翔的名言说的一样：“你不是一个人在战斗！”项目经理要时刻记住这一点，不要只顾自己闷头编码。只有学会发挥团队的力量，才能管好项目，成为一名真正合格的项目经理。

　　2.为什么软件企业人难管

　　从单干到团队做战，项目经理最大的变化就是以前只需要管自己一个人，现在你要管一个团队，以前独善其身就可以了，现在要兼济他人了。可以说，项目经理最重要的一项工作就是管人。

　　但是软件企业的人是出名的难管。软件公司的经理管人有两难，一是留人难，人才流失成了很多公司的心病；二是用人难，要把程序员用好，把大家的潜力发挥出来，决非易事。

　　（1）留人难

　　每年春节过后大约三月份，是很多软件公司的人力资源部经理最“兴奋”的时候，一方面他们要大量招人，另一方面，大量程序员辞职流失，让他们叫苦不迭。

　　程序员的离职率高，一直是行业的普遍存在的问题。据前程无忧网站2012提供给《中国经济周刊》的信息表明，IT行业人才流失率高居所有行业的首位。另外据CSDN的一份调查显示，43.6%的开发者在5年内换了3份以上的工作，这么高的跳槽频率真是让人瞠目结舌。我们不禁要问，为什么程序员这么“喜欢”跳槽呢？

　　我曾经接触过数以百计的人员离职，根据对他们的分析，我将程序员离职的主要原因分为三种：

　　表 程序员离职原因分析

类别

原因

分析

行业原因

程序员就业情况比较好

既然选择多，也就没有必要担心离职问题了。

行业不成熟

很多软件企业生存艰难，大部分软件企业给员工提供的薪资福利有限。 

行业内“贫富差距”大

少数优秀的公司如阿里巴巴的高薪，导致程序员这山望着那山高，影响了员工作稳定性。

公司原因

人际关系紧张

人人都向往愉快、和谐的工作环境。

对公司前景没有信心

如果说公司是大海中的一条船，没有人愿意待在一条没有方向，船身也破破烂烂、摇摇晃晃的小船上，不如趁早离开，找一条更大更坚固的船。

晋升机会少，个人能力得不到发挥。

   良禽择木而栖，既然英雄无用武之地，那也没有必要在一棵书上吊死。

工作压力太大，或长期出差

要钱也要命啊。为了工作可以忍一时之苦，但长期搏命，那就要考虑值不值得了。很少有公司真的把员工当作家庭成员，那只是说说而已，同样也不要指望员工真的把公司当成自己的家，把公司的事当成自己的事

个人原因

期望获得更高的薪酬

跳槽是公认的涨薪最快的方式。

想换多换几个公司，多学一点东西，开阔视野

自己有一身武功，到哪里都会吃亏。在一个小环境中待久了，不了解外面的世界，能学到的东西也有限。

有些人抱着“此处不留爷，自有留爷处”的想法，不认真对待工作

既然这样，公司也不会认真对待他们，更加不会委以重任，最后他们也就边缘化为可有可无的人物了，跳槽也就成了唯一的出路。

　　以上枚举显然不能穷尽所有的问题，但能抓住主要原因就可以了。

　　这么多问题中，最重要的还是薪资问题。据《北京青年报》的调查显示，“职业收入高低”是促使人们跳槽和选择新职业的首要原因。然而在这一问题上，公司其实也有其苦衷。

　　很多人从学校毕业，对开发基本上一无所知，经过在公司一年多的培训学习，取得了巨大进步，个人能力提升很快，此时必然对薪资要求也比较高，这是可以理解的。然而，站在公司的角度，这一年你基本上还谈不上什么贡献，公司却付出了较大的成本，大幅加薪一时难以接受，难道我把你招进来就是为了培训然后再涨工资干活吗？你也许会认为公司非常短视，这样的公司不待也罢，殊不知，软件行业看似光鲜，其实大量的企业挣扎在生死线的边缘。据工信部统计，2011年上半年我国软件行业利润仅占软件业务收入的1.28%，这么低的利润率，能活下来就是成功，对公司提出过高的要求也是不现实的。

　　在这一场博弈中，没有谁对谁错，但公司肯定是受伤的一方。真正将员工利益与公司利益统一起来的凤毛麟角，大部分公司里，公司和员工就像一对冤家，虽然互相需要，却又矛盾重重。

　　当然，其实公司也应该转变思路，不要总抱着我培养了你、你应该感谢我的心态，在程序员进步巨大的情况下，还是要给员工相应的薪酬，真正留住人才，毕竟软件项目禁不起人员剧烈变动的折腾，从长远来看，公司还是划算的。

　　（2）用人难

　　留人难，用人更难，要把程序员用好，则是难上加难。员工用得好，每个人都奋勇当先，以一当十。用得不好，员工死气沉沉，没有朝气和干劲。在我所见过的软件项目中，虽然有不少程序员工作主动积极、富有效率，但更多的是缺乏激情、消极怠工、甚至不服从项目经理工作安排情况。

　　为什么软件开发人才就这么难用呢？这是由多方面的因素所决定的：

　　●软件开发的特点

　　软件产品有一个非常显著的特征，就是它是一种无形的东西，在生产过程中看不见也摸不着，完成以后可以看到运行效果，但你还是无法知道它是不是一个“豆腐渣工程”。它里面暗藏的问题也许若干年后才能看到，也就是说它的质量评价非常困难。这与传统的制造行业有着非常大的差别，比如你是造一栋房子，生产过程中我们就能看到它的结构设计是怎样的，它的地基是不是够牢固，它有没有用“牙签钢筋”等等。

　　第二个重要特点是对人的依赖性非常大。同样的一个功能点，由不同的程序员来做，所花的时间可能会相差很远，比如有经验的人来做可能只要1天，没经验的人来做，可能1周甚至1个月都完成不了，做出来的质量也可能有天壤之别。即使是同一个人，由于其工作状态的差别，也会产生巨大的差异，如果主动积极做，可能只要1天，消极怠工的做，就无法预期了。这样的情况，在传统行业是无法想象的，只要按规定的程序和规范来做，即使换一拨工人，也可以在同样的时间建造出来，建出来的房子的质量也不会相差太远。要知道，再烂的挖土机也能挖出一个大坑。

　　总之，软件开发存在非常多的不确定性，非常依赖于每一个开发人员。虽然管理专家们发明了很多方法企图来减少这种不确定性，减少对人的依赖，让软件开发像传统行业一样变得可控，但迄今为止，仍然没有一个通用的行之有效的方法，专家们也不得不无奈的发出“没有银弹”的感慨。

　　● 程序员的个性比较强

　　不得不承认，与其它行业人员相比，程序员显得更加内向、不合群，有些人自视甚高，看不起别人。他们做事冲动、不服管，也就不足为奇了。

　　●程序员的想法比较多

　　程序员都很聪明，对自己的期望值也很高，不会满足于现状。有想法本来是好事，但人人都很有想法时，经理就没那么好当了，没有高超的领导技能是难以应付的。

　　综上所述，软件企业对人的依赖性非常强，却又面临着留人难和用人难这样两难的困境。要解决这些问题，一方面要求软件企业真正要做到以人为本，另一方面也对管理者提出更高的要求。

　　3.转换思维提升领导力

　　留人难、用人难，难道我们真的就无能为力了吗？这两难困境中，有行业原因、有公司原因，对于这些，作为项目经理也许力不从心；但也有程序员的原因和项目经理自身的原因，对于这一类问题，项目经理并非无能为力。即使在同一个公司，不同项目组中的人员流失情况、团队士气也会有很大的差别，这说明项目经理完全是可以有所作为的。对于有强大领导力的项目经理而言，人员的流失率会更小，工作效率会更高。要提升领导力，首要的是转换思维。

　　在前面博文中曾介绍了管理的五大思维：以目标为中心的思维、整体思维、平衡思维、以人为中心的思维、团队思维。其中前面三项与理事有关，而后面两项与管人有关。下面我们对这两种思维进行详细的解析：

　　表 管人的两大思维

思维

主要观点

分析

以人为中心的思维

软件产品主要取决于人

虽然流程、规范也很重要，但软件产品的质量，项目的进度、成本等因素，更多取决于每个人的技能与投入程度。

人的潜力是巨大的

一个人的能力就像海上的冰山，项目经理无所作为，你得到就只是露出水面的那5%。一个优秀的项目经理可以通过其领导力，将员工的潜力挖掘出来。

人是有感情的

员工绝不是木头，可以随便搬来搬去，搬到哪里都是一块木头。首先项目经理不可以做伤害下属感情或面子的事情，进一步可以利用这一点，适当使用感情牌，提高团队的凝聚力。

人是有动机的

员工可以努力工作，但这有动机的，要学会分析、利用员工的动机，并采用合适的激励手段。

人与人之间是有差异的

每个人在能力方面和思维方面均存在差异。这一方面要求项目经理不能吹毛求疵，要容忍员工的不足，另一方面，项目经理不能一味以己之心，度人之腹，要尊重人的个性思维。

团队思维

团队的力量可以是1+1>2，也可以是1+1<2

“三个和尚没水吃”，这是典型的1+1<2，其根本原因是他们之间没有建立坦诚相待、团结合作的关系。一个项目团队也是如此，不要以为人多就力量大，那还要看项目经理会不会领导团队，会不会用人。

团队成员之间相互影响

近朱者赤，近墨者黑。正面的情绪也会给别人施加正面的影响，不好的因素同样会扩散，而且会更快、影响更大。因此，项目经理必须要带动正能量，并注意将那些负面的东西扼杀在萌芽状态。

团队之间的协用程度是团队战斗力的关键

团结就是力量。一个木桶能装多少水，不仅取决于每块木板的长度，还取决于木板之间结合是否紧密。项目经理的领导力，就是木板之间缝隙的粘合剂。

项目经理在团队中起着至关重要的作用

一头狮子领着一群羊，要胜过一只羊带着一群狮子。项目经理是团队的核心，他在团队中起着协调作用、激励作用、榜样作用，可以说他直接决定了团队的战斗力。

　　可以看出，这种以人为中心的思维和团队思维，真正体现了以人为本的思想。它们与程序员的机器思维、单干思维大相径庭。许多项目中的问题，就是由于项目经理的思维还停留在程序员阶段造成的。

　　管理学之父彼德.德鲁克说：“管理是一门反映人的内心，与人性息息相关的科学。”项目经理只有跳出程序员思维的局限，实现思维的转换，尊重人性、遵循人的社会法则，才能真正把人留住、用好，项目团队才能具有更强的战斗力。

　　4.项目经理也是人事经理

　　在管人的方面，除了要建立上面两大思维之外，还要提高一项认识，那就是项目经理其实也是整个团队的人事经理。

　　很多项目经理对下属关注的重点往往是他有哪些具体技能，比如他有几年工作经验，他会用JQuery吗，熟悉NHibernate吗等等，而对于项目组成员培训、薪资、离职这些事情，则认为统统是部门经理或人力资源经理的事情。如果将问题交给人力资源部，需要跨部门协调，比较麻烦，因此干脆直接全部推给部门经理。

　　我担任部门经理的时候，曾无数次遇到这样的情况：

　　项目经理找到我说：“经理，某某要辞职了，帮我安排一个人。”

　　“你跟他谈过没有？”我问道。

　　“还没有。”

　　“他为什么辞职？”

　　“还不清楚，可能是工资问题吧。”

　　我找员工沟通过之后，原因自然是五花八门，有要求加薪的，有抱怨环境的，还有跟项目经理合不来的，不一而足。经过多轮沟通，该开导的开导，有合理要求的尽力帮助争取，还有一部分可以承诺延迟满足，或者用前景来“诱惑”等等，采取这些方法之后，还是有不少人愿意留下来继续做的。其实，大部分辞职的人并不是喜欢换工作，而是有一个心结，需要上司来帮他打开。

　　其实我做的这些工作，项目经理一样可以做。项目经理与员工朝夕相处，要时刻关注员工的动态，发现异常情况，及早介入沟通，也就不需要其上司费尽心力了，而且员工可能根本不会走到辞职这一步，沟通效果会更好。

　　项目经理还有一个普遍存在的误区，就是在评价下属时，习惯于说某某不听话、不好管。殊不知，一个员工好不好管，其实也取决于项目经理本人的态度和做法。一个看似不好管的员工，经过引导，同样可以成为项目的骨干，这样的例子屡见不鲜。

　　所以项目经理在碰到管人的难题时，不要再总是想“这个我管不了”、“那个我没办法”，而应该抱着“我也是人事经理”这样的心态，主动沟通、想办法。如果经过分析或者努力后，确实需要上司出马的，才去请上司来帮忙解决。直接把问题丢出去，当然是最简单，但这样做一方面你在团队中的威望会受到影响，项目的凝聚力下降，另一方面你的个人价值也大打折扣。

　　5.打造“凝胶型”团队

　　著名职业经理人唐骏说，管理的任务就是“造一条船，然后让船划起来”。对项目经理而言，我们已经有了一条船——就是项目团队，现在的任务要把它划起来。

　　软件质量之父沃兹.汉弗莱曾经提出，一支高效的团队应该是一种“凝胶型”的团队。在这样的团队中，大家有着清晰的共同目标，彼此合拍，每个人都全身心投入，团队显示出超常的战斗力。

　　我曾有经过一次项目灾难拯救的经历，这一段时间我真正体会到了凝胶型团队的力量。项目上线后发现软件运行效率极低，故障不断，人人疲于奔命，客户发出最后通牒，三天之内搞不定就下线。在这种情况下我临危受命，临时接管项目。接手后我主要做了以下几项工作：

　　1.找出当前影响最大的几个问题，采用头脑风暴法一起找出解决方案，在短时间内让客户体验有较大改善，让客户重拾信心，然后不失时机安抚客户情绪；

　　2.每天客户下班后开会，与项目组成员一起进一步研究项目存在的问题，按轻重缓急做成任务列表，制定阶段目标，并检查上一阶段完成情况，更新任务列表；

　　3.向公司申请了充足的经费，保障后勤，改善工作环境和吃、住条件，解除后顾之忧；

　　4.与团队一起加班加点，一起分析问题，并亲自完成一些力所能及的功能修改。

　　有随后一段时间里，项目团队的状态让人难以置信。项目组虽然夜以继日的工作，却没有一个人说出一句怨言。其中一位同事才刚当上爸爸一个星期，就驻现场无法回家；还有两位同事的女朋友半夜打电话过来，他们只能躲在一边苦苦安慰；还有一位同事，由于个人原因早先已经申请了离职，仍然与我们一起奋战到最后一刻……经过一个多月辛苦修改完善，项目总算彻底摆脱了危机，项目组高高兴兴打道回府。

　　在这一次经历中，虽然大家都很辛苦，但每个人都过得很充实。大家同心合力，每个人都贡献了自己全部的智慧和力量，也都做到了以前难以想象的事情。

　　我为什么举这个一个非正常项目（陷入灾难）的例子呢？这是因为要建设一个真正的凝胶型团队非常不易，不只是依赖于项目经理和每一位成员，还与公司的制度、氛围、项目的任务特点等多方面的因素密切相关。在这个例子中，项目灾难显然也是激发大家战斗力的一个重要因素。不过，即使是不能完全做到，但通过项目经理努力，还是可以近似实现的。

　　根据项目经理团队中充当的角色和发挥作用的不同，凝胶型团队可以分为两种，即星型和网络型，如下图所示：

图 两种“凝胶型”的团队

　　● 星型

　　项目经理处于中心位置，好比一颗红太阳，把大家吸引在自己的周围，整个项目组依靠项目经理领导力团结在一起。这要求项目经理个人能力极强，富有魅力，具有绝对的权威。星型团队的决策方式常常是这样的：项目经理收集意见，项目经理决策，再反馈给大家，或者由项目经理单独决策，再分发给大家。

　　● 网络型

　　网络型的团队中，项目经理看似在其中不占主导地位，项目经理的权威被弱化，实则项目经理的对团队的控制已经内化到每个人的潜意识之中，达到了一种近似于“无为而治”的境界，因此对项目经理的要求更高。

　　这种团队的决策方式一般采用民主制或民主集中制。把大家联结在一起的不只是项目经理领导力，更是富有挑战性、具有吸引力的目标，以及共同的认识和价值观。项目经理往往是外柔内刚，能够不动声色，于无形中实现对项目掌控。

　　能够建成星型团队的项目经理已经寥寥，能做到网络型更是可遇不可求。不管有多难，目标不能丢。我们就好比是一群已经出发的登山者，来到了山脚下，怎么能够因为看到山太高太难爬就放弃攀登呢？