要说项目管理的招式，最受欢迎的当数美国项目管理协会的《项目管理知识体系指南》（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个过程的分布情况：

 如果你想看每个过程的详细讲解的话，那还是得自己动口、丰衣足食——动口啃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个过程，每个过程都是由“输入、工具和技术、输出”组成，这与“输入、处理、输出”不是一回事吗？

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

图：项目管理中的过程链

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 利用碎片时间

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

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）不紧急也不重要

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1.程序员需要一点执着精神

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

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

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

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

2.自省消除固执

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

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

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

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

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

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

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

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

1.好汉也要三个帮

　　我喜欢看动物世界，感受那些发生在非洲大草原上的那些美丽或者哀伤的故事。那里生活着成群的狮子和鬣狗、还有数以百万计的野牛和角马。无论是凶猛的狮子，还是温驯的角马，都属于是群居动物，个体一旦离群，就会离死亡不远了。

　　其实人也是一样。人是一种社会性动物，我们只能生活在社会群体中，离开了群体，我们的人生价值也就无所依附。在社会心理学名著《社会性动物》的扉页上，印着一段亚里士多德的名言:“从本质上讲人是一种社会性动物；那些生来离群索居的个体，要么不值得我们关注，要么不是人类。社会从本质上看是先于个体而存在的。那些不能过公共生活，或者可以自给自足不需要过公共生活，因而不参与社会的，要么是禽兽，要么是上帝。”

　　其实这段话应该修正一下，许多动物也是要过公共生活的，至于上帝，我们都不曾见过，想必也是差不多的。无论是希腊神话中的宙斯，还是中国神话中的玉皇大帝，他们身边不也是都有一班大小天神簇拥左右吗？

　　可见下至动物、上至上帝都需要合群，更何况是人？

　　可是在程序员这样一个群体中，确实还是有不少人不喜欢与别人打交道，喜欢独来独往，过着自我封闭、离群索居的生活。

　　一个人不合群的原因有很多种，比如：价值观不一致、胆小害羞、不善言辞、性格内向等。而对于一个技术牛人来说，其不合群的原因还要加上一条：看不起别人，觉得“竖子不足与谋”。

　　中国素来有文人相轻的习惯，其实程序员相轻的现象一点也不比文坛少。程序员多有自傲的性格，容易看高自己，看扁别人。觉得自己一个人也能搞定所有事情，多几个人来弄反倒碍手碍脚 。

　　当今社会是一个高度分工、讲求合作的社会，每个人都是团队中的一员，总想着个人单干的小农思想，已经无法与现实相容。个人英雄主义的时代已经远去，在一个项目中更是如此。俗话说：“一个好汉要三个帮”，一个人再牛，也应该学会欣赏别人的优点、与人和睦相处，因为没有这“三个帮”，他便当不成英雄好汉，空有一身武功，四处碰壁，一事无成。

2.合群谁都可以做得到

　　每个人都内心里对外在的事物都有一道防线，这是一种自我保护的本能。对于不合群中的人，这道防线显得格外的高大和坚固，以至于将他与其他人隔离成了两个世界。其实合群并不是一件难事，关键是要敞开心扉，卸掉内心的防线，主动与别人交往，融入到所在的团队中。当然，合群也需要注意一些问题，避免盲目交往，或者言行失范。

　　（1）合什么样的群

　　合什么样的群，也就是说我们应该与什么样的人交往。所谓“近朱者赤，近墨者黑”，因此与有必要对自己交往的对象加以界定。

　　如果是一帮举止不端或格调不高的人，应该果断退出，平时也应保持适当距离，以不得对方为限。

　　对于自己不感兴趣或者对自己助益较少的群体，不要一概拒绝，否则会给人以不近人情的印象。可以适当参与他们的活动，但不能过多，否则会占用自己过太多时间。

　　交往的重点应该是与自己兴趣相投、对自己有帮助的人。与他们相处，不但可以互相学习，而且人生的快乐和价值可以找到落脚点。

　　（2）言行的把握

　　在与人交往中，言行得体是非常重要的。2009年河南有个局长叫逯军，因为一句“你是准备替党说话，还是准备替老百姓说话”名扬天下，沦为笑柄。 最近，“表叔”杨达才因为在车祸现场诡异一笑，不但引得丢官弃爵，恐怕还要陷入牢狱之灾！

　　在我们普通人的生活中，因为言行不慎，招来误解、怨恨的例子同样非常多。

　　对于言行的把握最重要的是要谦和、通融、合规、适度。例如大家玩的时候你也玩，不要做异类；开玩笑不要过分、让人难堪；举止不要怪异等。

　　（3）尊重他人，保持平等

　　这是对牛人的忠告，因为牛人技能超群，更容易觉得自己高人一等，看不起别人。人与人交往最重要的是获得尊重和认同，如果他不能从你这里获得这些，你就是比牛顿还牛，对他而言也是没有价值的。须知，尊重是双向的，合群的首要点便是尊重对方，以平等之心相待，不卑不亢，这样才能赢得别人的尊重与认同。

1.直率是关于说话的问题

　　公司曾有一位人力资源经理是从传统行业转过来的，有一次她跟我说：“程序员真有意思，他们全都是一根肠子通到底，大脑不会转弯！”

还真是这样的，估计没有哪个行业的人员像程序员这样，具有同样的鲜明的性格特征：直率。

直率很容易理解，其实就是一个关于说话的问题，准确的说这是一个关于说还是不说、以及说多少的问题。 过于直率的人，在说话方面往往有两个特征：

　　(1)想到什么说什么

　　这是一个说还是不说的问题。显然，不是什么东西都可以随时随地的说，或者对任何人说。可是对于过于直率的人而言，想到了就要说出来，就像俗话所说的：“嘴上没有把门的”，不管好话坏话，不区分场合，不论说话对象是谁，心里想着什么，嘴里马上就出来了。如果是好听话还好，皆大欢喜；如果是让人难堪的话，那就会伤害了别人了。如果是在公众场合让人难堪，人家可能会记住你一辈子。

　　(2) 知无不言、言无不尽

这是一个说多少的问题。“知无不言、言无不尽”毛主席老人家曾大力倡导的，这在讨论具体事情时无疑大有帮助，可是如果作为一种品格，在中国国情（文化氛围）下，还是不宜提倡。话并不是说得越多越好，说得越多，错的机会就会越多，反倒容易被人家抓住弱点或把柄。俗话说：“逢人只说三分话”，对一个项目经理而言，更应是如此。

　　在情绪方面，过于直率的人，往往不能很好的掌控自己，在说话时容易显得消极或冲动。

　　(1) 消极型

　　言语显示出消极的态度，例如给人泼冷水。给项目组成员安排工作时，我最怕听到两种话，一种是说“这个我不干了”，还有就是说“ 我不想干这个”，每次听到这两句话，心里就觉得凉飕飕的，虽然不爽，但作为团队的核心，我只能选择耐心的分析和开导。如果项目经理也以消极的方式来应对，整个团队的士气将会爱到打击。

　　(2)冲动型

　　虽然人人知道“冲动是魔鬼”，但魔鬼不是那么容易掌控的，人难免有时会说出冲动的话来，以直率著称的程序员更是如此。冲动的主要表现是言辞激烈固执、情绪激动，一旦过头就会变成人身攻击。我经常看到程序员与项目经理讨论问题，后来争论不休，项目经理被迫使用自己的职位权力，强制执行，但这样可能会导致矛盾激化，搞不好程序员就会拂袖而去：“我不干了！”

　　无论是消极还是冲动，这都是职场的大忌。这些外在的情绪，在领导的眼中，就是体现出了一个人的工作态度，而在职场上，态度决定一切。对于领导而言，没有积极、合作的态度，就意味着你不能为我所用，那留你何用？！ 

2.直率的悖论

　　对于直率的人有很多有意思的词语，好听一点的比如“直性子”、“直来直去”、“心直口快”、“快人快语”、“率性而为”，不好听的如“口无遮拦”、“大嘴巴”、“一根筋”、甚至“缺心眼”。可见在要不要直率这个问题上，中国人真的过得很矛盾、很痛苦，有时甚至无所适从。“说，还是不说，这是个问题”。长此以往，对于修养不够的人，造成人格分裂的倾向也不足为奇。

　　(1)书上提倡直率，现实鼓励含蓄

　　其实好像没有哪本书正儿八经的告诉我们做人要直率，那为什么很多人眼里直率是一种美德呢？我想这是从小到大的教科书对我们潜移默化的结果。书上教育我们世界上主要有两种人：好人和坏人。好人多是直率的人，他们流芳青史，而坏人多是阴险狡诈之徒，他们遗臭万年。对比之下，我们当然想做直率的人了，光明正大，而且要直率太简单了，人人都做到，做的过程中还很爽。

　　另一方面，中国人的含蓄又是出了名的。中国是一个讲人情的社会，什么东西最重要？人情和面子。一个成熟的人不会当面伤害别人的感情，不太好的事情喜欢用暗示，以免伤了面子。 不但说话，连中国的诗歌、中国的医学、中国人谈恋爱，也是含蓄的、有点模糊的不清的。

　　(2)觉得直率好，却很少有人喜欢别人对自己直率

假如做一个调查，你是喜欢别人直率，还是含蓄，我相信大部分会选择直率。当别人含蓄的时候，我们会催着让他“有什么话直接说”，等别人说了，如果事情难办，心里又可能犯嘀咕，“这人说话也太直接了，连退一步的余地也没有了”。

　　其实我们很少有人希望别人每件事情都对自己直来直去，试想一下，当别人当面揭露我们的缺点时，我们会是什么样的心情？与此相对照的是，我们又希望自己对别人直来直去的时候，别人会高兴的接纳，这可真是奇怪的事情。

　　(3) 网上“直率”，现实中彬彬有礼

　　有些人在网上非常的“直率”，直率到了一不高兴随时骂娘的地步，骂了又怎么样，反正见不着你。我相信在现实生活中，他们大部分都是讲道理有礼节之人，因为在现实中，我从来没有碰到像网上那么多人动不动就爆粗口、骂娘，祖宗十八代什么都可以骂。这样的人，有人格分裂倾向。一个人格完整健全的人，应该是一个不管什么场合都言行一致的人。

　　(4)表面直率，心里打算盘

　　在中国什么类型电视剧最热？我想无非是武侠剧、宫廷剧、历史剧，这些电视剧无一不充斥着人与人之间勾心斗角的故事。有一位伟人说：“与人斗，其乐无穷”，试想一个什么都藏不住的人，与人斗，还不被别人玩死啊？因此，无耻的政客们不论心里面打着多坏的算盘，表面上也得笑着，一副给人家交了老底了样子，好叫别人不要防着。当然，职场中还没有这么夸张，那是因为我们没有那大的利益需要去争斗，但中国人长期受这种文化的熏陶，表里不一的人到处都是。

　　上面这些所谓的“悖论”只为了引起大家的思考，对于直率是好是坏这样的问题，并没有标准答案。但凡事过犹不及，过于直率无疑不但会伤害别人，最后也会反过来伤害到自己。

3.直来直去伤人害己

　　直率这种性格听上去还不错，显得一个人光明正大，无所畏惧。有些人在自我介绍时候会说：“我这个人就是个直肠子”，言语之间还透着一些小小的得意。

很多人将直率视为一种美德。美德应当是对别人对自己都有好处的事情，可是“直率”并不是这样，如果把握不了度，可能反而会伤人害己而不自知。

　　(1)伤人

　　要说直率伤人，相信人人都懂，很多人还会有切身的体会。国人最讲面子，一旦面子被伤，很难挽回，正所谓“刀伤易痊，舌伤难愈”。武侠小说中江湖中人，为什么整天打打杀杀的？直率就是一个重要的原因，那些人个个都是直率之人，又不讲礼节，经常出言不逊，一言不合，就兵刃相见。好在祖先教我们注意礼节，用礼节约束我们的言语和行为，社会就会和谐多了。

　　有一次我收到一个程序员的辞职申请，让我奇怪的是，这名程序员一向工作踏实，为什么突然辞职呢？跟他谈过之后，这才明白原因很简单，就是因为项目经理多次批评他“怎么这么简单的事情都做不好”，而他认为事情并不简单，是项目经理不了解实际情况。但他不想解释，因为他的自尊心被伤害了，不想再待在这里工作。我又找项目经理沟通，项目经理说这是无心之言，只怪现在的员工太脆弱。最后的结果就是员工离职了，项目进度也受到一定的影响。试想，如果项目经理在说话的时候更加注意措辞，怎么会有这样的结果呢？

　　(2)害己

　　还记得《三国演义》中的杨修是怎么死的吗？杨修有过人之才，总是能看穿曹操的意图，然后得意洋洋的告诉别人，最后被曹操以扰乱军心的罪名处死。在历史上，许许多多的忠臣最后都没有好下场，因为他们往往是刚直之辈，言语伤了领导的面子，而领导一旦报复，后果是很可怕的。

　　直率就像没有成熟的柿子一样，好看不好吃。现实中，只听说过因为直率吃大亏，没有听说过谁因为直率升职加薪，不是这样的吗？一个管不住自己嘴巴的人，小则在团队中难以与人和谐相处，大则可能会得罪客户、甚至泄露公司机密，这样的人，领导怎么敢委以重任呢？

　　一个人能力很强，却因为说话的问题而吃亏，那实在不划算。技术的成长需要日积月累，而一句未经思考的话就有可能毁掉你在公司的前程。因此在把话说出去之前，我们应该多思考，三思而后言，避免犯下言语上的低级错误，后悔莫及。 

4.三思而后言

　　在计算机中，我们常用IPO（输入-处理-输出）图来描述一个过程或一个功能模块的设计，其实人说话也是一个输入-处理-输出的过程。首先我们接收到信息，比如别人说的话、文件、任务指令或其它外部事件，然后大脑对这些信息进行处理、思考，决定要说什么，最后嘴巴将大脑思考的结果输出，也就是说话了。

人与人之间说话的过程，主要区别就在于大脑思考处理这个环节。过于直率从某种程度来说，是一种有失理智的行为，因为他没有经过“理智”的思考，全凭个人的直觉反应来应对外部事件。

　　(1) 两种说话模型

　　根据人们说话的“输入-处理-输出”过程的不同，可以将说话的分为直率型和谨慎型两种方式。

　　对于直率型的说话方式，其主要特征是思考问题的方式比较简单，只是根据大脑的直觉做出反应，得到结论，然后直截了当的将结论输出（说出来），而且往往是一个输入对就对应一个输出，整个过程看上去就像一根“直肠子”，如下图所示：

图1 直率型说话模型

　　这个图让人不禁想起了巴浦洛夫的条件反射理论，显然直率型的人在说话方面没有充分利用人的思维能力，发挥人的主观能动性。

　　而谨慎型的人，他们的思考过程比较复杂，在直觉反应之后，还要经过大脑的分析总结，在说话之前要判断是否可以说，因为除了说之外，他们还可以选择沉默。另外与直率型不同的是，他们往往多个输入对应一个输出，这意味着他们说之前要听对方把话说完，而不是匆匆忙忙下结论。

图2 谨慎型说话模型

　　两种方式比较如下表所示：

　　（2）三思而后言

　　从上面的模型可以看到，谨慎型的人主要特征是说话理智，真正做到了三思而后言。说话一定要经考大脑思考，没有思考，我们就如同一个被自己的性格的直觉控制的牵线木偶。因此，当我们与人交流时，务必要时时思考说什么以及怎么说的问题。

• 说什么

说什么就是要判断我们想说的内容可不可以说。说话不能逞一时之快，千万不可说极端的话。还有就是要学会察言观色，学会从事件的背景、对方面的性格、脸色、手势等“输入”信息来揣测对方意图，从而做出合适的反应。

• 怎么说

　　这是说话方式的问题。要注意对事不对人，看透不说透，立场要客观，不能偏激，好话可以直接说，不好的话要委婉的说。其实程序员直率一点，尚无大碍，因为程序员最重要的事情就是高效地写出合格的代码，即使你伤害了你和经理，他一般也不会计较；但对项目经理而言，沟通是其最重要的工作，他需要与各方、代表不同利益的人打交道，如果想到什么说什么，不但会被人家认为肤浅，而且你的底牌、你的真实想法全在人家的掌握之中，无论是在处理内部冲突的时候，还是与客户谈判的时候，都会陷入被动的境地。“见人说人话，见鬼说鬼话”，这话虽然“逆耳”，但是“利于行”啊。

　　养成思考的习惯，刚开始可能会很不适应，觉得很累，但只要坚持，久而久之，就会习惯成自然，用大脑管住嘴巴。

　　当然慎言也不能过度，否则可能会造成胆怯，什么都不敢说，反而不利于问题的解决。把握好度，不要走向反面，好与坏之间往往只隔着一层纸。

　　需要说明的是，本人也绝不不是什么说话的高手，我对自己的要求不高，就是尽量照顾别人的感受，不捅漏子！当然即使是这个看上去简单的要求，也必须要改掉过于直率的毛病，凡事三思而后言！

5.守住真我

　　（1）直率也有可取之处

　　三思而后言，并不是要将直率一棒子打死。之所以要避免过于直率，是为了避免伤害别人和自己受伤，而不是要把自己藏得很深以进行利益的争斗，更不是要去算计别人，记住这个出发点。

因此该直率的时候还是要直率，否则就容易变成虚伪。比如在讨论技术问题时，就应该畅所欲言，让别人准确了解你的想法，注意就事论事、不搞人身攻击就可以了。在分配工作时也是这样，应该力求清晰明确。再比如，项目遭遇危机的时候，有什么想法要全盘说出来，就算只是头脑风暴也有价值。如果这时候还在考虑要直率还是委婉的说，那就好比一个人都快饿晕了，还在考虑是要吃米饭还是面包一样。在生活中，也有需要直率处理的问题，比如谈恋爱，如果总是含蓄，始终不感说出“我爱你”三个字，说不定你的心上人就要飞了。 

　　（2） 真我永存

　　周星驰在《喜剧之王》中有一句台词：“其实我并不是一个直率的人，我只是个演员！”说出这句话，多少有些无奈，谁不想过恣意纵横的生活呢？每个人都是生活这个舞台上的演员，需要涂脂抹粉，甚至要戴上面具，不然容易伤到别人，或为别人所伤。但这并不意味着要泯灭真我，因为真我就如“挪威的森林”一样，别人无法触碰得到，但永远存在于我们的内心深处。

　　有人说，直率的人生活更加真实、更有个性，如果人人都像演员，便那岂不人人都失了性格？其实性格是一种内在的秉性，并不会因为你管住了自己的嘴巴就没有了性格，难道含蓄和委婉的人就没有了性格吗？我们说话做事应该以原则为导向，而不是被性格所牵引和控制，只要你内心有自己的原则，你就是一个性格的人。

　　不要过于直率，但也不要走向了另外一个极端。如果心机太深，或者虚情假意，那就变成了虚伪和狡诈，没有人会愿意与这样的人交往，因为他们的行为是不友好的，已经脱离了善的范畴。只要心存善念，真我就会永存。

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分万岁”！

转自：http://www.cnblogs.com/watsonyin/archive/2012/11/26/2788987.html

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

（1）程序员眼中的自己

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

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

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

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

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

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

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

（2）别人眼中的程序员

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

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

l     工作方面

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

l     外在形象

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

l     生活方面

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

l     性格方面

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

l     思维方式

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

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

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

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

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

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

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

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

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

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

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

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

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

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

二、懂电脑更要懂人脑

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

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

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

（2）做回正常人

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

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

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

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

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

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

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

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

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

转自：http://www.cnblogs.com/watsonyin/archive/2012/10/30/2746529.html

一．学习也是一种能力

看到这个标题，有人会说：“学习，谁不会？”的确，学习就像吃饭睡觉一样，是人的一种本能，人人都有学习的能力。我们在刚出生的时候，什么也不知道，是一张真正的白纸，我们靠学习的本能，学会了走路、说话、穿衣服…后来，我们上学了，老师把书本上的知识一点一点灌输到我们的脑子里，我们掌握的知识越来越多，与此同时，我们学习能力却好像越来越差了，习惯了被别人喂饱，似乎忘记了怎么来喂自己了。

学习本来只是一种本能，算不上什么能力，然而，经过二十多年的不断学习，学习反而成为了一种真正的能力，因为我们慢慢失去了它，它就更显得珍贵。

在学校里我们基本上被动式学习，然而走出了象牙塔之后，不会再有人对你负责，不会有人主动教你，我们需要主动的学习。所谓的学习能力，其实就是自主学习的能力。

几年前，曾有一本风靡管理界的书，叫《第五项修炼》，这本书倡导建立学习型组织，因为从长远来看，一个组织唯一可持续的竞争优秀，就是比竞争对手更快更好的学习能力。

一个公司如此，一个人又何尝不是如此？众所周知现在是一个知识爆炸的时候代，知识更新非常快。据说，一个大学毕业生所学习到的知识，在毕业之后的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 由知识点形成知识网

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

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

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

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

八．经常思考总结

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

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

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

九、克服“高原现象”

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

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

图2 技能学习练习曲线

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

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

十、学习要有好心态

（1）学习要静心

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

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

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

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

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

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

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

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

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

转自：http://www.cnblogs.com/watsonyin/archive/2012/10/22/2734741.html