我看《最后期限》

《最后期限》（The Dead Line）是我看的第一本关于项目管理的书，更重要的是这本书属于科普读物，通俗易懂，书并不厚，不过我看了好几天，因为我边看边思考，结合我的经历，我想这样才能真正对我起到指导作用。下面我抓住我体会最深刻的一些要点，写出来供大家参考。

 

一、管理的核心是人，不涉及到人的管理，最多只能称得上是文档工作，文档本身不会产生价值，价值只能通过人来创造，人是最重要的。

 

书的一开始就说明了这个观点，其实不光是软件项目了，任何项目都如此，必须重视人的管理，作为一个经理，就必须学会和团队其他成员交流，调动他们的积极性，保持团队的凝聚力。回想我这些年的工作经历，没有了解到这个观点，或者说没有贯彻这个观点的经理，太多了。我曾经在一个做对日外包的公司工作，那里有时候很忙，有时候很闲，忙的时候有事情做也无所谓，闲的时候就找不着北，有段时间我连续几个星期见不到经理，我不知道我在那个公司是一种什么角色，不知道这样下去还有没有发展。后来我才知道其实经理一直在忙，忙什么？忙她的“设计”，设计没有完成，就不好安排我们任务，这个我也同意，但无论多忙，她都不应该中断和我们的交流，她没有给我们任何安排，没有调动我们的积极性，更加无所谓保持“团队凝聚力”，这做法导致我想离开那家公司，而且我确实这样干了。管事不管人的经理要么就是根本没有权力，要么就是水平很糟，这样的经理带出来的项目也肯定好不去哪里，只有人能创造价值是这条法则的根本原因，好的公司都非常重视“人性化的管理”，管理也是以人为本的。著名的经理人余世维曾说过，当他还是一个部门经理的时候，每个月都会拿出自己收入的10%来给他的手下提供便利，当然他因此所得到的认可与回报也是非常可观的。

 

二、除非感到安全，否则人们就不能去迎接变化，但变化在成功的项目中几乎是一定的，所以一定不要给手下施加太多的压力，这些压力能形成危机感，让他们不乐于接受任何变化。

 

和第一条“总则”一样，这条也是关于人的管理，算是细化，其实你会发现之后的法则都和人有关。软件开发是高度依赖于脑力的工作，不管是谁，心理承受力总是有限的，而目前的情况就是经理喜欢“逼”手下尽快完成任务，如果完不成任务，就……这算是一种威胁，有了这种威胁，手下就不可能会有安全感，于是匆匆忙忙设计，匆匆忙忙编码，再匆匆忙忙测试。一旦客户需求有变动，就十分不乐意接受，因为变动就意味着延期，更糟糕的是有些延期难以估算，那会导致无法按时完成项目，然后就受到……

 

三、危胁手下也不是提高业绩的好办法，如果分配的时间已开始就不够，不管威胁有多吓人，工作还是无法按时完成。

 

我完全同意这点，并有深刻体会。我懂得一个软件工程的“经验公式”，用这个经验公司可以比较准确地估算出一个项目需要多长时间完成，公式是这样描述的：静下心来，想想这个项目如果在进行当中没有遇到什么技术难题，没有什么意外人员流动，没有多少需求变更，当然资金也没有问题，再排除大小会议所耗费的时间，那么得出的这个时间基本上很准确，但！注意，把这个时间乘3，甚至乘4！这个经验是《C++编程思想》的作者Bruce Eckell提出的，我可没那么伟大发明这个“公式”。我有次在进行一个Windows平台的小型项目，经理问我需要多长时间完成，我说两个月，他马上反驳说：“太长了！最多只能一个月。”经理说这样，我也没办法，为了快点把东西弄出来，我缩短了设计时间，几天后就转入了编码，我确实在一个月后把东西交付了出来，可惜后来修修补补的时间加起来却一点都不比前面我所说的“两个月”少。另外说一下这个经理，有个毛病，每次征求我的意见问我多少时间完成项目，他都不会同意我的观点，于是我就学乖了，我估算出来需要30个工作日的项目我就跟他说“40个工作日”，他于是说：“这绝对不行，最多25个工作日了。”我和他一番讨价还价之后确定30个工作日，哈哈，正中我的预期的目标，但这样有意义吗？

 

四、对于新的雇员，让他们承担与以前曾经成功过的同样难度的项目，把有挑战性的目标推迟到下一次。

 

我曾经遇到过这么个问题：你认为软件开发者偏向于像科学家还是艺术家？外行人可能会回答像科学家，可几乎所有的软件人都会回答像艺术家。软件开发过程可以看作一种创作的过程，其实我也是因为喜欢创作，才会从事这个行业，创作就意味着一种开拓与创新，而不是机械与重复，所有的软件人都喜欢新鲜的项目，对新的技术十分推崇，而经理人也往往会因为他们的热情而把这些工作交给他们。但这种开拓没有过往的经验，是十分具有挑战性的，风险也是很大的，作为经理，不能打击手下的积极性，而应该好好沟通，如要点所说，让新雇员先着手去完成一个曾经成功过的同样难度的项目，把有挑战性的项目推迟到下一次，这样风险会降低很多，并且不会太让手下感到挫折。

 

五、没有“短期生产力提高”这种东西，生产力的提高来自长期的积累，CMM往往会让它本身变成目的，添加累赘，而起不到什么提高的作用，这个世界根本没有立杆见影的方法。

 

我对CMM是有所了解的，它的本意是好的，通过减少重复劳动来提高软件生产力，通过严格的文档控制来提高软件可靠性，嗯，理论上确实可行，而实际上却如标题所言，“CMM往往会让它本身变成目的”，我在那家做对日外包的公司工作时候，有幸参加过CMM的培训，岂是“枯燥”两个字了得，文档文档还是文档，文档本身几乎成了目的，我搞不懂那么多的文档对我们最底下人员的开发会有什么帮助，而CMM是要求整个公司去实施的，也就是最底层的开发人员也需要产生相应的文档，于是60%-70%的时间都迷失在文档中，弄得怨声四起……总的来说，CMM的代价是很昂贵的，收益是不确定的，改进的风险是巨大的，它根本不是提高软件生产力的灵丹妙药，如果你想说CMM也许对大公司来说是必需的，那我可以明确告诉你，Microsoft就没把CMM放在眼里。所以不要尝试引进什么方法来大幅度提高生产力，生产力来自自身的长期发展与积累。书中还有句稍微委婉点的话：“过程改进的出发点是好的，从理论上来说也是可行的，但特定的过程改进工作会拖延项目进度，最终体现在生产力上的提高恐怕也难以抵销这个损失。”

 

六、进行风险评估很重要，不要以为什么都能很好地完成。最先知道危机存在的是底下的人，必须想办法建立通道，让坏消息及时传递上来。

 

国内普遍的情况是：风险不用评估，想办法把东西做出来就是。不是我们不怕风险，而是评了也白评，项目摆在那里，做也得做，不做也得做。所以要说这个风险评估有用，那就是我们用它考虑了所有我们可能会在项目进行过程中遇到的风险，并且我们准备好了一些对策。壕沟里的战士最了解战局的情况，而不是在办公室里的将军。报喜不报忧是种“中国特色”，你不见每次开会时候必说的话都是“取得了良好的成绩”么？要不是破产，我看成绩从来就没有过不“良好”，领导都说良好了，手下还能说不良好？于是种种危机就这样徘徊在底下传不到上层，某天发现项目出现了重大的问题，可调整已经来不及了，那可就迟了。

 

七、成型的团队是宝贵的，不轻易拆散。

 

作者提到了许多公司喜欢在项目完成之后对项目组进行拆散重组，其实这等于破坏了这个团队通过长期合作赢来的默契配合，好团队的形成确实是不容易的，天时地利人和。根据我的经验，如果一个团队成立于公司刚成立之时，或一个大型项目刚启动之时，这个团队往往是很优秀的，而之后的团队就感觉“一蟹不如一蟹”，拆散了成熟的团队，又得再花大量时间来培养一个团队，成本是很高的。公司并购在软件业不是什么新鲜事，而并购过程中往往出现人员流失，使得本来优秀的团队变得缺乏战斗力，没有以前的团队，花大价钱买回来的代码也就成了废品。

 

八、项目开始时浪费一天和最后阶段浪费一天对项目造成的伤害是同等的。有无数种方法可以浪费一天时间，但没有任何一种方法可以拿回一天的时间。

 

“有无数种方法可以浪费一天时间，但没有任何一种方法可以拿回一天的时间。”这句话就出现在这本书中，并且广为人知。时间是宝贵的，不展开了，人都应该知道。

 

九、团队中的人数和产出不成正比。指望靠增加团队人数来提高生产力，是错误的。

 

项目让一个人来做需要花费100天，如果让两个人来做呢？三个呢？单纯增加人数根本不能缩短软件的生产时间，为什么？1、新增加的成员要适应工作，得花费时间；2、要融入团队，需要花费时间；3、成员间交流需要花费时间；4、成员间冲突会浪费一部分时间；5、人员过多的情况下根本无法进行软件设计。可能还有别的原因，但我想这5个肯定是重要原因。这也是这本书的一个核心观点。软件设计的队伍必须非常精简，100人的项目，只需要4-5个人参与设计，如果让这100人全部参与，我想那就跟菜市场差不多，乱哄哄了，一个人一个意见，设计根本无法进行。而当设计完成，转入编码阶段，才是全部需要这100人的时候。我们传统的认为从头到尾都需要给他们参与进来的观点其实是不对的，一个项目从头到尾所需要的人员数目不是一致的。所以书中的主人公让那些没有参与到设计的人去做一些软件外包的工作，而不是让他们全部挤到设计组去。

 

十、“病态的政治”对项目威胁很大，但又不得不经常面对它，它的特征是对个人权势的渴望超过了组织本身的目标。

 

举个例子吧，十九世纪的时候，沙俄工程师设计了一条铁路准备修建，为了表示对国王的尊重，就把设计图拿给了国王过目，国王一看大为恼怒：“你画的这条铁路弯弯曲曲，这样要多浪费多少资金材料？不行，必须改为这样。”国王拿起笔把始点终点用直线连了起来。国王的命令，不敢不听，但这样的铁路如何修建？直线就意味着要穿过高山，要跨过洼地，技术根本达不到，项目最后流产。四个字形容这种“病态的政治”再恰当不过——“刚愎自用”，这种威胁来自上级，遗憾的是我们往往没有什么对策，除了我们自己被迫离开这个鬼地方。

 

十一、要学会对工作量进行评估，用自己的单位即可，比如“功能点”，凭直觉对项目进行量化。

 

软件项目的工作量很难用什么尺度来衡量，所以我们需要因地制宜建立自己的标准，把这个单位命名为“功能点”，这样就便于任务划分了，当然“功能点”也是很主观的，不可能是精准的，但它却十分有效。比如有“数据库设计”这么个任务，我们把它细化，对一个表的设计算一个功能点，有些表很大，算两个功能点，表之间的约束，关联，算五个功能点，这样的一个任务，算下来一共16个功能点，如果做八个功能点一天，那么这个任务需要两天。

 

十二、标准的过程的危险就在于人们可能失去重要的走捷径的机会。

 

团队合作就需要一些规范，一些标准，但过多的标准，就会让人厌烦，而这些规范也会变成团队的绊脚石，真可谓作茧自缚。我曾经负责过公司编码规范的制订，我考虑到了过多的规范难以记忆与实施，于是对规范一再精炼，只制订了3页不到的“规范”，其中还包括一些范例，但整篇“规范”条条有理，非常容易记忆，后来的实践证明了我的“规范”还是成功的，大家基本上都按照上面所说的去做了，而且这个规范足够让我们的代码看起来很赏心悦目，这是一个避开繁琐的标准与规范，走捷径的例子。试想想看，对一个小型项目，如果完全依循软件工程的那些方法，需求，需求分析，概要设计，详细设计，编码……其中需要产生多少文档？文档有文档的规范，整理一篇有水准的文档绝对不是件容易的事情，那又需要耗费多少时间？而这些开销，对这么个项目来说都是划不来的。有时候我们必须要走捷径。

 

十三、对程序的调试往往会占据相当长的时间，减少调试时间是项目成功的一个关键，那就是把更好的设计拿出来，在编码前反复推敲分析，当编码完成时，产品也基本上完成。

 

理论上是这么说，我还没有对这个观点有什么深刻的体验。根据作者的意思，设计所花费的时间是最长的，占全部时间的2/3，而编码调试，仅仅花费了1/6不到的时间，看来我的水平还太低，没怎么理解这点。

 

十四、压力下人不能更快地思考，增加加班时间会降低生产力，所以加班通常都不是让项目及时完成的好办法，偶尔加班是可以的，但长期加班绝对不行。

 

又是一个敏感话题，加班。这个观点上面写得已经够明确了，加班不是办法！相反作者提出了一个非常新颖的办法，那就是向员工提出要求：你们要完成这些项目，严禁加班。嗯，没错，是严禁，下班时间一到，就开始赶人，这样一来，员工就不会在宝贵的上班时间里开小差去做别的事情，拖沓的习惯也就能改掉，更重要的是没有了加班，员工得到更充足的休息时间，便于开展第二天的工作。这个由不得我去实践，但无疑加班是下策的下策，而我们的经理人又有几个会意识到这点？

 

十五、回到人的管理，列举几条法则：

 

1、如果你不关心别人，不照顾别人，就不要指望他们会为你做一些不同寻常的事情，如果要让他们改变，就必须了解并赞赏他们的过去。

2、愤怒和耻辱是会传染的，如果高层管理者喜欢骂人，低层管理者也会有样学样。辱骂员工并不能提高其工作效率。用辱骂方式刺激员工的经理是无能的经理。

3、冲突一定会存在，承认冲突，并确信冲突并非缺乏职业道德引起，谈判困难，调解容易。

4、存在一种员工，业务水平一般，人缘却非常好，对整个团队起到很好的调节作用，让团队保持健康和生产力，这种“催化剂”式的员工是可贵的。