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

一．为什么要当项目经理

组件设计》等。以前这类书都是从国外翻译或从台湾引进，现在国内高手越来越多，出自国内作者的也越来越多。这类书如果在你学习的每个方向看个两三本，并且通过实践消化掉，那么毫无疑问，你会成为一个优秀的程序员。

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

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

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

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

四．不要在上班时间看书

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

图1 由知识点形成知识网

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

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

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

有一次，一位项目经理对我说：“有一个问题，客户有一台HP服务器要装磁盘阵列，没人会做，怎么办啊？”“可以学啊，没有人愿意去吗？”“我都问了，没人想去。”“哦，正好明天我有时间，我也没装过磁盘阵列，那我明天去学着弄一下。”我说的是真心话。第二天早上，当我准备出发时，项目经理告诉我不用我去了，因为项目组好几个同事都想去“学着弄一下”。结果服务器很快就装好了，远远没有之前大*想像的那么困难嘛。更重要的是，在解决这个问题的过程中，大*都学会了怎么装磁盘阵列。

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

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

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

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

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

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

图2 技能学习练习曲线

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

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

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

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

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

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

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

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

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

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

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

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

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

（1）程序员眼中的自己

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

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

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

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

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

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

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

（2）别人眼中的程序员

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

二、懂电脑更要成为人脑

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

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

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

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

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

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

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

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

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

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

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

追求完美是一种可贵的精神，完美主义也历来被认为是一种优秀的品格。可是在项目中，完美主义也是一种错，虽然是一种“美丽的错误”。项目讲求平衡，要的是合格，而不是优秀；要的是70分，而不是100分！

开发一个地图应用系统，到用一个基于COM的地图开发组件库叫做ArcGIS Engine。在用该组件库操作某个数据表时，总是报告内存出错，我百思不得其解，搜索了无数的资料，将代码修来改去、变化腾挪，仍无济无事，耗费了我近一个月的时间，最后形容憔悴，不由得感到一丝失落和悲怆。有一次老板走到我身边，听取我的苦闷之后，他和蔼的说，看看能不能用其它方法实现。

真是一语点醒梦中人。对啊，我干嘛一定要用它用处理数据表呢？说不定是这个组件的Bug呢，那我跟它较劲不是太不划算了吗？用ado.net同样可以操作数据表啊，而且无疑效率会更高。于是我花了2个小时换了一种实现方式，再也没有出现过内存报错。虽然最后没能亲手干掉这个“仇*”，但总算解决了问题，避免了浪费更多的时间。

经过这一件事情之后，我觉得自己后来处理事情就变得“聪明”多了。

有一次我看到一个程序员在实现条形码功能时，在自己编写条形码组件，由于经验不足，在那里长吁短叹，我对他说，你用条形码字体试试看看。果然，没多久他就告诉我成功了。

有时客户需要某项功能，要实现比较复杂。但换个做法，却很简单。例如有一次客户要求将统计结果导出为Excel文件，这需要引用Excel类库，既增加了系统的耦合性，而且需要熟悉的人来开发，另外还要考虑客户是否安装Excel的问题（由于版权问题，不少用户在用WPS表格）。这时如果换一种思路，将统计结果导出为csv格式，不但可以实用Excel打开，而且实现起来非常简单。

类似的例子不胜枚举，只要做有心人，连梳子都能卖给和尚，我们还有什么做不到的？！

《致加西亚的信》是一本奇书，据说它是全球有史以来最畅销图书的第6名。这本书讲的是19世纪末美西战争中的一个故事，美国必须立即跟西班牙的反抗军首领加西亚取得联系，加西亚在古巴山中的丛林里——没有人知道确切的地点，所以无法带信给他。于是总统找到罗文，交给他一封写给加西亚的信。罗文没有说一句多余的话，就开始了这次充满凶险的旅程，最后不辱使命，完成了这个光荣而艰巨的任务。

不说一句多余的话，看似是一件简单的事情，然而却蕴含着*贵的敬业精神，和一往无前的执行力。其实每个员工都是信使，身负为领导送信的重任，我们要学习罗文，更要超越他，让执行力始于接受任务的一刻。

《致加西亚的信》这本书在国内没想到遭到了许多人的批评，他们认为这本的书的核心思想是员工要忠诚，因此是一本培养员工奴性的书，这实在是一个天大的误解。

首先，忠诚并没有错。如果说罗文忠诚的话，那他忠于的也不是哪一个人，而是忠于他的职业，这难道有错吗？作为军人，要忠于祖国；作为员工，要忠于工作，这是天经地义的事情。如果你不打算做好自己的工作，那你为什么还要拿老板的钱？忠诚绝不是让你去给老板当“走狗”、当奴才，而只是尽力做好本职工作而已，这也有错吗？

其次，忠于职守本质上是一种诚信。一旦当你接受了任务，意味着你对上级做出了承诺：我会去做好的。接下来你再怎么辛苦、再怎么百折不挠也只是为了履行你自己的承诺而已，这与所谓“奴性”何关？

最后，这本书真正倡导的其实并不是忠诚、更不是奴性，而是一种“少问多做”的做事方法，或者说是一种敬业的精神。我们来看一段作者的原话：

我要强调的重点是：美国总统把一封写给加西亚的信交给罗文，而罗文接过信之后，并没有问：“他在什么地方？”

这才是作者真正想说的，也是我在这里想说的：要少问多做。

其实少问还是多问，这本身并不是一个问题，这只是表面的东西，它背后真正的问题是，员工没有担当、不能勇于承担工作、不能主动去解决问题、不能立即采取行动，这才是大问题，这才是让领导真正头痛的地方。如果员工在问了一大堆问题之后，能又快又好的解决问题，那领导被多问上一阵又有什么关系呢？事实上，没有执行力的人，一般是问得多，做得少；反之，执行力强的人，则往往是少问多做。

大部分当过经理、主管的人，相信都曾有被问到无可奈何、甚至忍无可忍的经历，这时你唯一想做的事情，就是如何让他从眼前消失。我本人也曾多次深受其害，下面是我的一次真实的经历：

某项目已经开展了一个多月，还没有计划，于是我让项目经理老张赶快写一份实施计划。老张惊讶的说：“啊？还要写计划啊？不用写了吧，没什么用。”

我说：“怎么说没用呢？没有计划怎么知道你打算怎么安排工作呢？”

老张：“写了也没用，形式上的东西而已。我一直都是这么管的，我知道怎么做。”

中间省去十多分钟与老张你来我去的辩论，讨论项目究竟是否需要计划。

经过我一番苦口婆心的说教，最后老张终于屈服了，无可奈何的说：“那好吧。要写多少页？”

“你有多少内容可写就写多少页。”说完我又觉得不妥，知道又会招来一场不必要的讨论，于是补充道：“你就写十几页吧。”

“有没有project软件？”

“服务器上有。”我压制住自己的情绪回答道。

“服务器上是32位的，我电脑是64位的操作系统，装不了。”

我快要崩溃了，大声说道：“这你也要找我呀，是不是要我帮你装啊？”

老张委屈的看了我两眼，没有说话。过了半晌，似乎想起了什么问题，说：“领导，我工作太忙了，实在没时间写啊。你安排一个善于写文档的员工给我吧。”

我忍住最后一点性子说：“没有多余的人了。”

“那等我把手上的工作做完了再写吧。”老张不假思索的回答道。

听到这句话，我不由得长叹了一口气，好吧，这计划看来我是要不到了，我只能认输了。

一次次类似的经历，让我更加明白了罗文的可贵之处。《致加西亚的信》之所以能够长盛不衰，从一个方面也说明了像罗文这样少问多做的人是非常稀缺的。公司的主管、经理、领导们被下属员工的问题烦透了，事情却常常得不到解决，他们多么盼望多一些像罗文一样少问多做的员工啊。

在《致加西亚的信》中，罗文是一个接受任务后不问一句话、立即动手去做、并且能把事情做成的人。可是现实中，如果真的像罗文一样，什么也不问，可能会误事。要知道，不是每次领导都能把员工需要的信息讲清楚，也不是每次员工都能准确无误的理解领导的意图。

因此，不问问题未必就一定是好事。有些员工，对于领导交办的问题，一概回答没问题，什么也不问，埋头就做，看起来态度很棒，很敬业，但结果却不一定理想。观察一下，你身边是不是经常也有这样的对话：

项目经理：“小赵你把某功能做一下。”小赵：“好的。”小赵马上开干不问一句话。

领导：“这个项目你来负责吧。”项目经理：“没问题。”项目经理立即行动不问一句话。

这样的场景也是很多的，最后工作很有可能会出问题，因为接受任务的人没有充分掌握工作所需要信息，例如时间要求、质量要求、可用资源、关键点等。

所以不要因为罗文不问问题，你也不敢问了。领导之所以怕被问，是因为他们被问的问题，很多都是员工自己应该去面对和解决的问题，或者是没有意义的问题。因此少问多做的本质不是问不问、问多少，而是要问什么。我们要学习罗文，更要超越罗文，要少问但不是不问，而是要合理的问，要想清楚之后再问，这才是关键。在问之前，要经过大脑思考，一定要注意不要问以下两类问题：

例如：“计划文档要写什么内容？”“计划要写多少页？” 这样的问题会让自己显得肤浅，给人的感觉就是不但没有经验，而且没脑子。

l 自己要解决的问题

例如：“哪里可以找到project软件？”这种问题让人觉得你偷懒、怕麻烦，甚至有推卸责任嫌疑。

余世维认为，中国人对执行力的态度存在的第一大问题是“对执行偏差没有感觉，也不觉得重要”，因此不管领导安排的任务是多么的SMART，不管时间要求是多么紧迫，员工始终按照自己的节奏来工作，内心里不会有一丝紧张或不安的感觉。不管这项任务持续多长的时间，他会一直像死守机密一样，绝对不会主动给你透露半点关于工作进展的消息。一旦上级质问为何没达到目标，他又总会有各种各样看似充分合理的理由。

这样说或许稍有夸张，但无疑代表了不少员工的工作状态，在这些员工的眼中，做好做坏无所谓，也正是这一点伤透了公司领导的心，他们退无可退，只好举起了“达摩克利斯之剑”，用数字对员工进行考核，让员工的收入与这个数字挂钩。

然而经过无数公司的亲身实验，证明绩效考核非但不是灵丹妙药，而且可能引发许多其它更加严重的问题，例如引起员工与公司的对立，钻制度空子，考核标准难以公正客观，评分主观性太强等。尽管人们想出了形形色色的考核方案，但真正成功实施的公司寥寥无几，倒是有很多公司因为考核失去了活力。索尼公司常务董事天外伺郎曾写了一篇文章《绩效主义毁了索尼》，痛陈绩效考核之害，考核让索尼公司变得死气沉沉，官僚主义盛行。可见绩效考核对一个企业的文化的杀伤力是致命的。

绩效考核之所以负面作用如此之大，是因为它本身存在以下几点难以克服的问题：

1．它是一种外在的驱动力量

天外伺郎认为绩效主义就是“业务成果和金钱报酬直接挂钩，职工是为了拿到更多报酬而努力工作。”说白了，也就是胡萝卜加大棒的管理方式，而这以前这一种用来管理驴子的方法，在驴子前面挂一根永远也够不着的胡萝卜，后面用鞭子使劲抽打。把人当作动物来看待，急功近利，无视人的内在需求，忽视人性的力量，这就是绩效考核的“原罪”。

2．它是一种治病的措施

如果每个人绩效都很高，激情也很高，谁还用得着考核呢？创业阶段的公司一般员工都很有激情，所以它们从不做绩效考核，每个人的绩效也很高。因此热衷于绩效考核的其实都是缺乏活力、绩效低下的公司，这是领导生病，让员工吃药。这种治病的措施，就好比医生不给病人开处方，却对他的*属说：“如果明天他的病情好转，我就奖你吃一颗糖；如果恶化，我就打你屁屁”，两者一样可笑。不针对病因，而只是根据发病的表现来治疗，只能治标不治本——其实连“标”也治不了。

绩效考核的一个根本要点，就是用量化的数字来评价员工的表现。而每个人是如此的复杂，受如此多因素的影响，岂能跟一个数字等同起来？而且量化本身是一件非常困难事情，戴明认为真正重要的东西能量化只有3%，要把另外97%也变成数字，显然难以做到公正客观，对于软件企业尤其如此。

首先，一个人的表现难以量化。无论是KPI考核，还是，还是360度考核，都离不开一些荒诞的指标，例如沟通技巧、人际关系、领导能力、行政能力、态度……这些如何量化？谁能告诉我，一个人的态度究竟是如何变成一个精确的数字的？55分的态度和60分的态度真的有高下之分吗？

其次，软件质量难以量化。软件是无形的，要进行量化非常困难，即使强行量化，评估成本也很高，主观性强。所以很多软件企业在计算项目绩效时，有意无意忽略了质量因素。对项目组来说，你不考核质量，那我也不要质量，到后面质量问题爆发，管它呢。所以不少项目在考核时，总是前半段月月得奖，后半段苦苦度日。

最后，绩效考核依赖于上级的主观评价。莎士比亚认为“一千个人眼中有一千个哈姆雷特”，每个人的评价标准都不一样，如何体现其客观性？每个评价者打分的时候会受到其主观好恶的左右，公正性更是无从体现。

4. 引发公司与员工的对立

绩效考核不可避免会造成员工和公司之间的博弈。公司当然希望目标越高越好，以充分挖掘员工的潜力；而员工则希望越低越好，这样可以赚到更多的奖金，这种不可调和的矛盾，会将昔日的亲密战友变成绩效考核战场上的敌人。

然而公司总是强势的一方，最后员工往往被迫接受目标，时间一长，员工也就不争了。哀莫大于心死，你爱怎么着就怎么着吧。正所谓“此处不留爷，自有留爷处”，等你把爷罚急了，爷走人行不？

5. 破坏激情、团结，助长官僚主义风气

天外伺郎认为绩效考核最大弊端是“搞坏了公司内的气氛。上司不把部下当有感情的人看待，而是一切都看指标、用评价的目光审视部下。”昔日以工作目标为导向的想法，被迫转变为以个人利益为导向。为了赚到更多的钱，员工就会动起“歪脑筋”，诸如钻制度空子、与公司讨价还价、巴结讨好上级等，而上级手握重权，只管结果、不问过程，无疑也助长了官僚主义的风气。这些“不正之风”盛行，最终必然会毁了公司的文化氛围。

怎样才算是一名合格的项目经理？最根本的一点，就是要胸有成竹，否则管项目就好比浑水摸鱼，最后的结果就是得到一只死鱼！

成功的项目经理都有一个共同的特征，那就是胸有成竹。如果做不到这一点，意味着项目经理缺乏总体的盘算，只能走一步看一步，项目究竟会走多少弯路，那就只能看运气了。

1.胸有成竹是项目经理胜任的标志

顾名思义，胸有成竹就是说一个画*，在画竹子之前，心里就有了竹子的形象，画*所做的，只不过是把心里所想的东西，誊到纸面上而已，当然可以做到驾轻就熟、游刃有余了。

胸有成竹是对一个优秀画*的要求，同样可以看作是一个项目经理胜任的标志。简单的来说，胸有成竹就是一开始就知道怎么做，只有这样才能做得好，如果不知道怎么做那不就成了碰运气吗？这个道理很简单，可是很多人却没有意识到，或者不敢于承认，实在是一种浑水摸鱼的心态。

有人会说：“没有人能一开始就胸有成竹，失败是成功之母嘛，哪个项目经理不是逐步成长起来的呢？我不多练怎么能知道怎么做呢？”把它翻译一下，就是这样一个思想：一个项目经理不搞砸几个项目，是无法成长为一名合格的项目经理的。

在现实中这个思想确实被一而再、再而三的实践着。大部分项目经理都是从项目的泥潭中摸爬滚打锻炼出来的——准确的说，是把项目搞成了泥潭，然后再慢慢爬上岸的。就这好像资本原始积累一样，每个暴富的资本*背后，都有说不清的原罪，每个项目经理成长的背后，都笼罩着若干个项目失败的暗影。虽然每种现象的存在有其合理的一面，但显然不是一种良性循环。

管项目就好比带兵打仗，如果你不懂兵法，那你还是安心做士兵好了，不要去做将军。你不能说我到战场上再学习怎样排兵布阵，到时灵光一闪、计上心来，这样可能会付出生命的代价。同样你也不能指望带了项目才开始学项目管理，才开始锻炼思维，才开始培养自己的心智，这时已经太晚了，虽然这对项目经理而言，并没有任何损失，可是对于老板来说，却要付出数十万甚至数百万人民币的代价。呜呼，可怜的老板们！

所以从对老板负责的角度，如果你做不到胸有成竹，最好还是知难而退，不要拿公司的项目当学习课程和小白鼠。让能胜任的人上，这才是真正负责任的做法。

胸有成竹要求项目经理在项目的初期阶段就要做到心中有数，对整个项目的工作有了通盘的考虑。那么具体来说，项目经理都需要考虑什么内容呢？

一个项目的核心无非是做什么、怎么做和资源这三个方面，如果你在这几个方面都觉得自己清楚明白了，在你的掌握之中了，那你也就大致上做到了胸有成竹。如果你还是不确定的话，好吧，那我们再围绕这三个中心，再试着问自己六个问题，把这些问题好好的想一想，你都能回答出来吗？

如果你对这6个问题，都觉得有信心的话，那你这个项目经理就当仁不让了。相反，如果你觉得心虚，这说明你发现了一些潜在的问题，给自己三天的时间去理解它、解决它，再回来看这些问题，如果还没有觉得心安的话，则说明你还没有准备好，基本上也就可以让贤了。

需要说明的是，胸有成竹并不是要事事了解得一清二楚。项目这三个方面，就像竹子的主干，我们自问的这六个问题，则是竹子的枝丫，把主干和枝丫搞清楚了，也就够了，没有必要细化到每个人每一天要做什么事情，这就好像没有哪个画*在动笔之前就把每片叶子的颜色、位置、大小都想好一样。胸有成竹意味着项目经理在很短的时间内构筑出项目的图景，尽管这个图景并不精确，但没有关系，因为胸有成竹的项目经理会在项目执行过程中随着形势的变化更新这个图景。

为什么有些项目经理能够做到胸有成竹呢？俗话说：冰冻三尽，非一日之寒。其实胸有成竹只是一种表面现象，就好像一座冰山露出水面的部分，水面以下还有庞大的支撑。对项目经理来说，水下的部分就是其思维、知识技能和经验，如下图所示：

经验是胸有成竹最直接的支撑因素。见过竹子自然知道竹子长什么样，做过同类项目，就可以将以前的做法照搬过来，省去了摸索的过程，这就是经验的可贵之处。为什么很多公司只招有经验的员工？这是因为有了经验就知道怎么做，从而为公司节约了培训的成本，可以更快的创造效益。

知识技能体现在其广度和深度上。有广度，方能举一反三、触类旁通，能迅速理解客户要求，发现项目中未考虑到的方面。有深度，才能察觉到潜在的问题，发现项目的难点。这些都是胸有成竹的重要支撑。

没有见过竹子的人，还有一个办法可以画出竹子，就是听别人对竹子的描述，在头脑中形成竹子的模样，这靠的是一个人的思维能力。同样，即使没有同类项目经验，但是领导和客户也都会告诉我们要做什么，就看我们能理解到什么程度。如果凭借自身的分析、综合、分类、比较、归纳、演绎、抽象、概括等思维能力，通过学习、沟通、总结等方法，对自己所迷惑的问题各个击破，也可以成为一名胸有成竹的项目经理。

因此，胸有成竹决不是一朝一夕学来的，也不是靠一个灵感顿悟出来的，而是需要在经验、知识技能、思维这三个方面的不断的学习、锻炼和积累。具体来说，要做到以下几点：

学习项目管理知识，业务知识和软件开发设计技术。在还没有当项目经理的时候就往死里学，把自己变成专*，不要事到临头才发出“书到用时方恨少”的感慨。

看看你的项目经理是怎样管理的，想想他哪些地方做得好，项目又存在哪些问题，如果是你，你打算怎样解决？所谓“功夫不负有心人”，保持这个习惯，你将来管项目也必定能够做到得心应手。

项目管理其实并不神秘，它就是一种做事的方法而已，而几乎我们做的每一件事都可以看成微型项目，能做好这些微小的“项目”，才可能在将来的“大项目”中一展身手。相反，如果这些小事总是做不好，可以肯定的说，要想管好一个真正的项目，比登天还难。

如果有一天领导叫你汇报一下项目状况，你会怎样来回答呢？在项目汇报方面，我总结有三种类型的项目经理，看看你是属于哪一种：

第一种，报喜不报忧。这种项目经理就像和珅一样圆滑，传达给领导的永远是好消息：进展总是顺利的，团队一定是和谐的，客户必定是满意的，天下永远是太平的，仿佛天气永远是晴空万里，永远不会刮风下雨似的。领导听了往往也是眉开眼笑，点头赞许。

第二种恰好相反，总是显得忧心忡忡。也许是由于项目经理有很强的危机感，每次汇报必然是听上去大问题套着小问题，项目危机重重，好像天快塌下来了似的。这种项目经理就象纪晓岚一样实在，一开口就是民不聊生，百姓受苦，皇帝听了难免会愁眉不展，忧心不已。

还有一种就是一五一十陈述项目的现状，比如这个星期完成了什么模块，客户又要求增加什么功能，系统设计方面碰到了什么问题，某某员工结婚要请两周假等等。整个过程基本上不带一句点评，领导听得云里雾里，估计还得寻思半小时才能大概总结出个一二三。

看起来，报喜不报忧是一种理想的汇报模式。从让领导开心的角度和较短的时间周期内来说的确如此。但这毕竟不是客观的情况，带有蒙蔽的性质，时间长了，问题暴露之后，难免会让领导觉得你工作不扎实，甚至夸夸其谈，好大喜功。

可以说，这三种项目经理都没有理解领导究竟在关心什么，到底想要得到什么样的信息。难道领导心真的如海底针一样难以琢磨吗？

领导之所以想要听汇报，无非是想看看项目干得怎么样。那怎样才算是干得好呢？其实只有两个字：受控。所以项目当前完成了多少功能，碰到了多少问题，领导并不会真的关心。只要情况在控制之中，有一些意外、偏差，有什么关系呢？ 孙猴子不是很能翻筋斗吗？翻吧，反正也逃不出如来佛的手心，这就是一种受控。

可见，受控可以看做是项目健康的标志。项目平时有一些小小的异常没有关系，只要项目经理能牢牢把控全局，它就是一个健康的项目。这就好比我们平时受点皮外伤、得个普通的感冒，也没有什么关系，因为“病情”的发展是可以预见的，是受控的，因此我们仍然可以自豪的说，我们是健康的。但对于一个癌症患者来说，我也许初期看不出什么异常，但由于癌细胞不受控制的扩散，那就不能再被称之为健康了。

从这个角度来说，领导要求汇报，其实是在寻求信心。要给领导信心，最重要的就是展示受控。受此启发，下次你再汇报工作时，就可以这样来汇报了：

首先，简要陈述项目总体情况。例如总体的进度，成本使用情况，员工士气等等。对于好的地方一定要展示出来，要知道和珅的存在也是有其道理的。这实际是在暗示领导，你是个明白人，在你的治下，工作井井有条。

然后，汇报项目中的大事，以及你的对策。比如重要员工的离职，项目的里程碑，客户领导的检查等等，同时一定要记得说一下你准备怎样应对。这样做的内在含义是告诉领导，项目经理不但有大局观，而且对重要细节也跟得很紧，而且很有想法，虽然有一些问题，但不足为惧。

最后可以汇报下一步的工作计划，工作重点，需要支援等，从而让领导明白，你的思路很清晰。

总之，围绕一个核心目的：项目在控制之中，请领导放心。这样一通汇报下来，相信无论哪个领导也会点头赞许：嗯，这个项目经理不错，项目也干得不错！

当然，让领导放心，也要建立实事求是的基础上。如果项目本身一团糟，你把领导忽悠得再开心，也是没有意义的。

从程序员到项目经理（28）：该死的结果导向（只看结果，不问过程到底行不行？）

在当今流行的管理体系中，结果导向由于迎合了公司高层的味口而大行其道。项目成功，你就是英雄；出了问题你就是狗熊，而不管是什么原因。正因为如此，在传统的目标管理中，公司与员工之间充满了博弈，导致双方出现了难以调和的矛盾。这一节我要为项目经理鸣不平，同时也替公司着想，将员工从不近人情的“成王败寇”的模式中解脱出来，实现公司与员工的双赢。

1.两种评价项目的导向之争

公司和项目经理博弈，主要体现在项目目标的制定、以及对项目结果的评价方面。毫无疑问，公司是结果导向的，结果好才是真的好，其它全部都是假的。可是，项目经理有话要说！然而公司又是如此强势，以至于项目经理根本无法发出声音。假如项目经理和公司领导之间是平等的，设想他们之间展开了一场辩论，会是怎么样的呢？

领导：你的项目延期了，要扣绩效工资。

项目经理：客户上个月换领导了，建设思路有比较大的变化，我要申请项目变更。

领导：出了问题就变更，那还要考核做什么？记住：没有任何借口！

项目经理：这不是借口，是实情。

领导：我只看结果，其它一切都是空谈。

项目经理：过程也要看，项目中总有许多不受项目经理控制的因素。

领导：车到山前必有路。只有不努力的项目经理，没有解决不了的问题。

项目经理：天上掉下一块陨石，把路面砸出一个坑，你的车还能开过去吗？等你把坑填平，或者绕道过去，还能准时到达目的地吗？是的，一切问题都可以解决，但并不是说一切目标都可以达到。

领导：我给你工资，你就要搞定一切问题、达到目标。不能实现目标，我还要你干什么？

项目经理：我卖艺不卖身，是人不是机器,只能达到可以实现的目标。

项目经理：你蛮不讲理！

虽然带有戏谑的意味，但相信说出了很多项目经理的心声。对于如何公正客观的评价项目，公司和项目经理其实分别代表了两种不同的倾向，即结果导向和过程导向。

结果导向有不公平的嫌疑

传统的评价标准是结果导向的，即项目完成后要达到既定的目标：范围、时间、成本、质量等因素均要达到规定的要求。结果导向是站在公司领导层的角度来看待问题，公司领导当然希望项目经理能将一切承担起来，每次都给出完美的结果，至于怎么实现，他们是不会想知道的。然而，对于项目经理而言，项目中总有许多的因素是自己无法控制的，只看结果显然并不公平。

比如，有些项目实在是预算太少、工期太紧、要求过高，本身就是Mission Impossible。但项目已经中标，必须得做。项目经理即使拼尽全力，把该做的、能做的工作都做了，且执行顺利，效率也高，没有返工，最后仍然没有达到目标。甚至有些项目受政策支配，验收标准频繁修订，验收时间遥遥无期。

这能怪谁？把责任都推给项目经理是没有意义的，因为你就是换一个能力再强的项目经理也无事无补。只能说这个项目本身不是一个好项目，应该追究的是只顾拿单、不计后果的销售经理，而不是找项目经理的麻烦。

项目经理负有管理责任，但管理不是万能的

有人认为，管理是万能的，管理者对组织的成败负责完全的责任；也有人认为，管理者对管理成果的影响是十分有限的。因为存在着大量管理者无法控制的因素，组织的成败在很大程度上归因于这些无法控制的因素，管理者真正能够影响的是象征性的成果。

现实中管理显然不会像“”说的那样无力，但也绝不是万能的。事物均有其运行的规律，超出规律支配的范围，任你管理能力再强，也是无济于事。乔布斯能造得出IPad，但造不出飞碟；要让杨元庆明年把联想集团的销售额翻一番，恐怕他也会无能为力。

因此，如果完全不顾项目实际情况，将项目的成败完全归结于项目经理的管理能力，是不合适的。

每个领导都喜欢说“我只看结果，不问过程”，可是要达到什么样的结果，往往也只是领导自己说了算，项目经理只有听的份。目标不能是领导拍脑袋拍出来的，而应该与项目经理开诚布公、平等协商，否则领导拍脑袋，员工最后只能拍屁股了。不信的话，你可以在任命项目经理时把你的真实想法如实交底，这样对项目经理说：

“小赵，这个项目交给了，总共8个人，工期是一年。你知道我是只看结果，不问过程的，不管发生什么事，如果今年年底不能验收，你要承担全部责任。所以今年你能不能拿到年终奖，就看这个项目了。”估计还没等你说完，小赵就会回话说：“老板，我想辞职…”很显然，你不会得到项目经理的认可，一厢情愿是没有用的。

当然，也没有哪个领导会傻傻的这样说话，他们一般在项目启动时很显得*柔、很宽容，告诉你项目很简单，真等到项目不尽人意的时候，再跟你秋后算账，这时也正是他一厢情愿的愿望破产的时候。

哪个领导都想“只看结果、不问过程”，这样多轻松啊，整个项目领导只用出现两次，第一次是启动的时候下达目标，第二次是完成的时候验收结果，这期间项目组就像一架运作精密的机器，有条不紊的按照指令完成任务。

只可惜这种情况在童话里也不会出现。如果这样有用的话，那公司老板也不用干活了，只要在年初对高层经理说一声今年要完成产值多少个亿，就可以去国外旅游了。

事实上，“只看结果、不管过程”是领导的失职。只要是管理者，都要履行计划、组织、领导、控制四大职能，你把项目交出去了，最多只能算完成了计划和组织的工作，而领导和控制这两项与过程息息相关的职能还没有去做。如果不履行这两项职能，在一定程度上就等于放弃了管理，甚至可以说是一种懒汉行为。

2.“不白花一分钱”才是成功的项目

“不白花一分钱”这几个字看起来简单，却包含着非常丰富的内涵。

在一个结果导向型的公司里，领导喜欢扔下一句话：“我要的是结果”，听上去很酷，还可以让项目经理哑口无言，但项目中的问题还是在哪里，于事无补。更重要的是，这种做法相当于把员工一棍子打死了，连同他的努力和价值也一并否定了，伤了员工的心，显得过于冷酷、不近人情，显然并不可取。但只管做事、不问结果也是不合适的，这会引诱员工放松自我管理，寻找借口，推卸责任，从而伤了老板的心。

那有没有一种评价标准，能够兼顾结果和过程两个方面、让领导和项目经理都满意呢？有！那就是“不白花一分钱”，也就是说，要看一个项目经理干得怎么样，关键就看他在项目中白花了多少钱。按照这个标准来管理项目，项目经理不但需要重视过程，同样需要重视结果，而且一定要竭尽全力、毫无保留，才能真正做到“不白花一分钱”。

这个标准看上去有点“惊世骇俗”，好像与传统经典的目标管理背道而驰，其实不然。目标管理首要一点是目标是可以实现的，这意味着必须要考虑项目实际情况，特别是项目中的不可控因素，应该将它从对项目经理的考核中剔除——任何考核只能考核项目经理能够控制的因素。其次目标管理并不是指领导下达了目标就等着收获结果，中间同样需要对目标完成情况进行监控，并根据实际情况对目标进行调整，这与“不白花一分钱”重视过程的思想是一致的。

也就是说，“不白花一分钱”融合了目标和过程两种导向， 既考虑到了绩效，也勇于面对问题，无疑更加的客观公正。正因为如此，它对项目执行过程具有很强指导作用——鼓励项目经理要做到人尽其才，物尽人用，不能做镀金的工作，更不能出现返工，要把每一分钱都用在刀刃上等，这样才能保证项目结果是最好的——没有多花一分钱。

没白花一分钱就是最佳结果

没白花一分钱意味着项目组已经发挥了最大的能力，并且项目没有走弯路，所以这已经是最好的结果了。如果这样达不到领导的要求的话，只能说明领导的要求实在太高了，而不是项目的执行太差了。

我们设想有一个项目，老板要求1年内完成，预算100万，如果项目经理用了1年半，花了150万，按照传统的意义，这个是一个执行失败的项目。但按照“不白花一分钱”的思想，这也许是一个失败的项目，但却不一定执行失败。如果每一天、每一分钱都是必须要花的，执行就是成功的。也就是说在当前资源配置下，当前结果已经是最好的了，换成其他人、采用其它做法，只会成本会更高、时间更长。既然如此，还有什么好苛求的呢？

因此，项目失败并不意味着执行失败，项目经理只能保证执行是最好的，但不能保证老板是赚钱的。

“不白花一分钱”不只是钱的问题

“不白花一分钱”这个提法，容易让人觉得它只包括了成本这一个方面的因素，而项目目标包括成本、进度、范围等方面，因此不具有说服力。

这实际上是一种误解，这个标准看似只有一个“钱”字，实则暗含了质量、进度、范围、人力资源等因素。无论是进度滞后，还是范围蔓延，或者质量低下，这些无不与一个“钱”字息息相关，它们最后都会反应在“钱”上。因此，要评价项目经理做得如何，完全可以通过衡量他白花了多少钱来进行评价。

表 项目问题最后都会体现在钱上

当然，要精确计算白花了多少钱，并不是一件容易的事情，同样可能存在争议，所以并不建议将其用于绩效考核——再次重申我是戴明的，从头到尾就不支持对软件项目进行绩效考核。管理的重点应该是如何提升绩效，而不是对绩效进行考核，如果每个人都绩效很高，也就没有考核的必要了。

“不白花一分钱”对领导层的要求

要贯彻“不白花一分钱”的思想，首先要从公司的高层做起，转变心态，说实在话，做实在事，实现与员工双赢。

高层应该具备宽容、共赢的心态

在“只看结果，不管过程”的公司里，管理层和员工之间一直在进行博弈。公司要员工对结果负责，给员工的目标要尽量的高，而员工不想对无法控制的东西负责，希望目标尽量的低。这种冷冰冰的结果导向，将公司和员工分隔在两个世界中，公司和员工的心不能往一处想，劲也不能往一处使，从而产生了巨大的内耗，对双方都造成巨大的伤害。

产生这种博弈的主要原因，在于公司领导层急功近利的思想。许多公司领导总觉得给员工发了工资，就应该把他们榨干用尽，以实现利润最大化。其实大可不必这样想，员工是来帮你的，他们从来不欠你什么东西。公司领导必须明白，员工承担不了他无法承担的责任，如果强压，他就只能拍拍屁股走人了。多一分理解，就多一分和谐。公司领导应抱着平和、宽容的心态，以求得和员工共赢。

在行动上要了解项目、支持项目，不要脱离基层

求全责备是没有意义的，不会使事情变得更好，只会让问题变得更遭。纯粹只看结果也无助于整个项目管理水平提升，问题始终在那里。公司领导同样需要“地头力”，只有扎根于项目现场，以实际行动去支持项目，帮助员工去分析问题、解决问题，才是最实在、最有用的做法，公司的管理水平才能得到真正的提升。

从程序员到项目经理（29）：怎样写文档

在软件项目中，文档既是一项的重要成果，也是项目管 理的有力工具。通过文档，可以稳定、明确的传达信息，实现项目内的有效沟通。所以写文档对项目经理来说，是一项必备的技能。

然而很多项目经理害怕写文档，似乎这是一个很麻烦、 很困难的工作。其实会不会写文档，只是一种外在的表现，通过一个人写文档的情况，可以看出他对工作的理解程度，发现潜在的问题和风险。一个合格的项目经理，不但不会怕写文档， 而且会觉得这是一件简单、很自然的情，就像一个人吃饭、喝水一样，何难之有？

1.编写文档的常见问题

每个项目都要写不少文档，比如项目实施计划、系统需 求说明书、系统概要设计设计、系统详细设计、测试计划……在不少软件项目中，大部分文档写出来只是为了应付检查或验收，如果要对这些文档较真的话，就会发现它们存在着各种各样的问题。

什么叫该有的文档？我想有两点含义：一是合同、招标 文件规定必须提交的文档；二是项目本身确实需要的文档。如果仅仅是前者没有，我一般不会怪项目经理，因为事后可以补上。但如果是第二种情况，那就不只是文档本身的问题了。试想 ，如果项目执行了一半，还没有项目计划，显然就无法就事论事只谈论计划了，这反映了项目经理对整个项目的管理具有随意性，盲目性；如果没有设计文档就完成了大部分编码工作，那 么代码的质量就得打上一个大大的问号了。

项目需要的文档没有，要么是项目经理的疏忽，要么是 写不出来，这本身也是很危险的信号。如果项目经理连必需的文档都可以疏忽，说明他的工作完全没有系统性，那他对项目的管理工作怎么值得信任呢？如果是写不出来，这说明项目经理 没有想好怎么做，同样也是一件很危险的事情。

丢 三落四，内容不完整

打开文档一看，总是有一些你想看的内容找不到，或者 对关键的内容轻描淡写，这多少会让人觉得有点生气。项目计划没有工作分解，设计文档没有系统逻辑结构，项目周报没有当前进度情况，试运行报告没有系统运行的统计数据 ……出现这样的状态，说 明项目经理缺乏经验，对项目没有总体的认识，更加把握不了工作的重点。

照 搬模板，徒具形式，内容空洞

这种文档还真让人有点无可奈何。乍一看，文档格式规 范、内容完整，似乎没什么问题，但心里总觉得少了一些东西，看完了什么也没记住，仿佛没看过一样。简单的说，就是没有实质性内容，缺乏对问题的具体分析，同样的内容，改一下名 字，可以给其它项目用。

这样说项目经理可能会不服气：我文档有几百页，怎么 会没内容呢？好吧，我们来清理一下，把模板自带的内容去掉、把合同和招标文件中Copy的内容去掉、把网上抄的内容去掉、把不相关的内容去掉、再把不重要内容去掉，再来看看究竟还剩下几页？这剩下的内容才是真 正有价值的东西。如果这一部分内容很少，你文档越长，就会越像懒婆娘的裹脚布，让人生厌。

看这样的文档，让人觉得就像吃了苍蝇一样难受。有人 将这种文档称之为“模板僵尸”，真是既准确、又解恨。这种文档徒具形式，没有灵魂、没有精神，就像一具只有骨架、没有血肉的僵尸。

写出或者接受这种文档的项目经理也很可怕。 他有经验，但是没想法；他知道流程，但不知道变化；他能把握形式，但把握不了内在；他明白要做什么，却永远也理不清楚工作的内容；他写的内 容很多，脑中却几乎一片空白。他们写出来的文档像僵尸，做项目也像被僵尸附身一样，只能沿着固定的路径一蹦一跳的前进，哪怕前面有深渊，他也会直接跳下去，因 为他压根就看不到！

我见过不少工作十年以上、管过项目五年以上的同事， 对于写项目文档仍然是愁眉苦脸、痛苦不堪。难道写文档真的有这么难吗？怎样才能写出合格的项目文档呢？

最核心的一点，写你所想的

俗话说：“言为心声”，写作也是一种 “言”，同样体现了作者的内心想法。写项目文档，最重要的就是要写自己的真实想法，展示自己的思路。如果说写文档有什么诀窍的话，这就是最重要的诀窍。从哲学上来说 ，这是知行合一的重要一环；从写文档本身来说，只有这样才写得好、写得快。所以如果有谁说自己不会写文档，我们首先应该想到的不是什么技巧问题，而是他真的想好了吗？

“知行合一”也就是“想”和 “做”应当保持一致。知行合一最简单的方法，就是想了就去做，由想直接到做。在软件行业个人英雄主义年代，程序员有好的想法，然后实现它，就有可能成就一段传奇，例 如UCDOS、WPS、RichWin、江民杀毒等都是那个时代的产物。由想直接到做，这对于一个人完成的 简单工作是可以的，但并不适合于由多人协作完成的复杂任务，因为团队作战还有一个关键环节——沟通。

沟通有口头和书面两种方式，也就是说和写。想、说、 写、做四者统一，才完整体现了项目中的知行合一。说你所想的，写你所想的，否则就是言不由衷、表里不一；然后做你所说的，做你所写的，这叫说到做到、一诺千金。

图 想说写做的统一

由此可见，写你所想的，是知行合一的重要体现。

写所想的才能写得好、 写得快

为什么有些人写文档写得很慢 、觉得很痛苦呢？最根本的原因就是因为他没有想法，或者说没想好，肚子里没货自然拿不出来。比 如说，如果你不熟悉Java技术，让你 来写一个Java系统的设计文档，你自 然不知从哪里下手，纵使你有莫言一样的文采和想象力，也没有办法完成。

写你所想的，其实只是把想法 誊到纸上而已，就像把杯子里的水倒出来一样。有思路的话，当然能写得快、写得好。如果没有想法 ，千万不要不懂装懂，到网上到处复制一些看上去相关的内容来填补，因为这会误导别人，虽然掩盖了自己的无知，但也掩盖项目隐藏的问题和风险。所以对于没有想清楚的地方，最好的 处理方法就是直接写上“没想好”三个大字，等想好了再补上。记住：说假话的人最辛苦，因为他总是要琢磨该怎样编故事，怎样自圆其说。讲真话的人最轻松，写文档就是要 写自己的真心话。

有些人说：“我有想法，就是写不出来。” 这种情况多半是由于写作者拘泥于文档的形式，不知该如何下笔。这样的话，有一个简单的方法：先把你的想法说出来，用手机把声音给录下来，然后对照录音来整理文档。也就是说，我 们要像说话一样写文档，说话是很自然的事情，写文档也是很自然的事情。如果你没办法说清楚，那估计神仙也法办法了——除非有谁懂得读心术。

文档最重要的是内容和思想，让读者能读懂你的思路， 而不是构思有多精巧，语言有多优美。如果总是在琢磨先写什么，再写什么，用什么词，怎么能快得了呢？

不拘泥于形式的另一含义是不要有过多形式化的内容。 有时一篇30页的文档，项目背景、建 设目标、参考资料之类就占掉15页， 并且在每一篇中都千篇一律。这些东西不是完全没用，但过多就会影响对文档重点的把握，尽可砍掉或简化。

另外不要凑篇幅。项目文档是用来指导项目实施的，因 此把问题写清楚就可以了，多写无益。有些人写文档时，喜欢问要写多少页，其实这根本不应该成为一个问题，如果把想说的都说清楚了，你管它有多少页呢 ？

在第三章中，曾经提到PMBok项目遵循结构化的思想，即自顶向下、逐层分解。 这一规律同样可以用来指导文档的编写，项目文档在结构上同样应该是“结构化”的，自顶向下、逐层分解，形成金字塔形的结构。

还记得在学校里老师教我们怎样写作文了吗？要按 “总分”或“总分总”的结构来写，这其实也是结构化方法的体现。结构化方法之所以放之四海而皆准，是因为它符合人对事物的认识规律。

设想我们要研读一本书，一般我们首先会看书名、作者 ，再看目录、前言或简介，对全书全形成一个总体的印象，这是“总”的过程。然后我们会逐章逐节的阅读，一步一步消化全书的内容，这是一个“分”的过程。部 分读者在读完以后，可能还会对全书的内容进行再次总结回顾，以进一步加深理解，这又是一个“总”的过程。通过这样一个“总分总”的过程，我们形成了对事物 的深刻理解。

所以一本书按照金字塔结构来组织文档，其实就是为了 迎合读者，降低他们理解的难度，让他们只需要更少的时间就可以对整个文档的精要有一个完整准确的理解。作者写得轻松、读者读得开心，真是皆大欢喜。

结构化方法不但适用于文档的整体结构，同样适用于局 部结构，例如文档的某一节。只要事物具有一定的复杂度，我们都可以用这种方式将其讲得更加透彻。

采用结构化方法来编写文档还有一个好处，就是可以检 验思维的严谨性。结构化方法的一个重要工作就是对事物进行分解，而分解的过程其实是一个再次深入思考的过程，例如分解的标准是什么，上层结构是否完整的包含了下层结构等，从而 发现被遗漏的问题，并进行完善。

文档排版是许多人容易忽视的问题。一份内容上乘的文 档，如果用工整悦目的排版来展现，那就是锦上添花了，反之就有损文档作者的形象。这就好比一个人心灵美固然重要，但如果穿着邋遢，面目可憎，也不大可能会受到别人的欢迎。

排版并非难事，只需要投入很小工作量，就可以为文档 获得一定的加分，这就是排版的价值。事实上，排版还是对读者尊重的表现。作者多花一点点精力，就可以让读者拥有更好的阅读心情，更快的阅读速度，实在是一种设身处地为他人着想 的美德。