“从程序员到项目经理”这个標题让我想起了很久以前一本书的名字《从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项目管理理论遵循结构化的思想即自顶向下、逐层分解。 这一规律同样可以用来指导文档的编写项目文档在结构上同样应该是“结构化”的，自顶向下、逐层分解形成金字塔形的结构。

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

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

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

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

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

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

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