关于项目管理进度计划的故事

春如四季的2010年杭州，项目经理柳哥和公司人力资源经理杨姐再一次坐在西湖边喝茶。柳哥半年前被任命为项目经理，中途接手了公司战略产品V3.0的管理。
“这群小伙子又把我给忽悠了！”柳哥看起来遇到了一些工作上的麻烦。
“是这样的，”他继续说，“3月份的版本发布计划明确要求发布报表中心这个核心构件，工程人员和客户已经期待这个很久了！小伙子们本来承诺3月15日交付Release版本，然而他们食言了没有按时提交！现在，测试任务要重新调整，人员培训计划和版本发布计划也受到了影响，小伙子们应该早点提出来的，好让我有时间想办法补救他们工作的失败！”
“是不是他们遇到了什么技术困难，或者最近的一些突发任务影响了他们的工作？你也知道，发生这种情况一定有原因存在，某些情况肯定是情有可原的！”杨姐说，“据我所知，你们项目组的成员的工作表现和人员素质在公司所有项目内都是最优的！”杨姐知道，柳哥虽然有点脾气火爆，但一向都是就事论事，并不是那种睚眦必报、寻机找事的人。
“扯！”柳哥笑道，“为了保证这个任务的顺利开展，我安排了专门的人员，给了他们足够的时间，甚至在他们自己预估的开发所需时间之上另外增加了20%的弹性时间！在这个周期内，项目组中没有减员，什么遇到不可克服的障碍纯属胡扯!我也曾经怀疑他们是否遇到了技术困难，开始他们并没有跟我提出来需要技术研究部门的配合，也没有在推进过程中提出需要技术支持！现在问他们呢，只说我不懂技术问题，跟我说了也不明白，还说技术问题他们总归会得到解决。”
常言说，“没吃过猪肉还没见过猪跑吗？”，作为一个软件公司的人力资源经理，杨姐经常与公司内的软件工程师进行交流，对软件开发还是有一定了解的，在她看来：软件业的不同之处在于，让软件开发人员彻底的坚守自己的承诺是不可能做到的，公司的、乃至业内的软件项目，绝大多数都是滞后的。
“杨姐，我承认这种认知在业内是普遍的，包括我们的很多客户都默认我们的进度计划延误，像微软这样的公司也存在发布计划一改再改的事故！但是这种认知总体来说是错误的，而且危险。因为这会帮助那些不注重承诺的人找到借口，并且从根本上刺激大量不专业的行为发生，例如制定开发计划缺乏严谨、忽视任务风险分析等。”
“那好，我问你，对于不能按时完成任务，大家一般都有些什么借口呢？你怎么看待这些借口的，应该如何处理？”杨姐也想了解一下，对于开发人员总是不能按时完成其承诺的任务这个现象，柳哥有什么深入见解。
柳哥陷入了沉思，他在想该怎么回答杨姐的这个问题。
“回答这个问题，我想应该说明一下软件开发人员对于承诺这种行为的理解上存在的几个误区。”柳哥开始回答杨姐的问题。
“软件开发人员的第一个不会明言的东西是，我的承诺不是联邦快递的‘使命必达’，我只是‘尽力而为’。一个表现是，大家都喜欢设置一系列的前提条件，便于后来承诺无法实现的时候作为护身符。”对于这一点，杨姐深有体会，因为以往参加过几次公司内项目总结会，未能完成任务的人通常都要费劲口水的解释他们是如何如何的努力，他已经尽力了，他认为尽力了就应该免责了，即使未能完成任务也应该得到原谅。柳哥继续道，“我认为承诺包含两个方面，第一，我愿意，第二我能够。没有意愿就不会有承诺，但是没有能力，承诺还是虚假的。因此当开发人员向我作出承诺的时候，我认为他们不仅有意愿而且有能力完成，就应该毫无例外的完成任务，否则他们就不应该作出承诺。”
杨姐点点头，“你上次跟我喝茶是说起过。你认为，软件项目的开发，是由一系列的任务组成。承担任务就是作出承诺，在你的团队内，视承诺为合同，一旦作出承诺，就必须坚定不移的执行，不能找理由。因为如果承诺没有兑现，信用就失去了，累计到一定程度客户也就失去了！”
“软件开发人员还会有第二个未表明的东西，我承诺到时候一定拿出这个东西，但我不保证这个东西一定是好用的。举个例子，上个月小武哥承诺一周内编写完成票据格式自定义工具，到了期限工具提交上来了，然而代码中BUG多多，修复这些BUG又要花一个礼拜的时间。然后我们又发现现有的设计需要在辅助开发工具上增加一个受控的资源，增加了开发人员的工作量，实施人员操作极其不方便，要修改这些设计缺陷不得不花几个星期的时间。所有基于这个工具的后期工作不得不停息来等待。”
柳哥停下来，喝了口茶，继续，“这个问题的根本我和他并未在到期需要交付的东西上面共识。他认为不过是一段代码，而我希望得到的是一个经过良好设计、开发和调试的可发布工具。如果我和他争论多少缺陷是可接受的，那我可就麻烦了，因为你知道缺陷定义和缺陷数是与工程人员使用场景，测试人员的专业技能等有关系的。我认为避免这种情况发生，需要在达成共识的过程中明确提出涉及具体质量指标的详细需求规范。”
“接下来我说说一般软件开发人员是怎么忽悠项目经理的！在我看来，这个行业里，有三个最常见的借口！”
“第一个，‘我被许多计划外的事情打断了。’例如客户突然提出的一个紧急需要，领导临时安排的一项突发任务。这是谁的问题呢？无非天灾人祸而已，如果是天灾，例如盖房子遇到下雨，这种情况要求作出承诺的人员不要基于一切顺利的情况下进行承诺，要知道‘人生不如意者十有八九’，体现在项目管理里就是制定任务开发计划的时候预留一定余量。而如果是人祸，那么明显就是他没有重视对我的承诺，因为他让其他事情优先了，那么对不起，承诺不是我作出的，而是他作出的，在缺乏预先沟通的情况下，他这是擅作主张。”
“第二个，‘这活儿比我想象的要难。’这又是谁的问题呢？注意，进行任务难度估算的的不是我，而是他。如果他无法确定是否能够完成就不要作出承诺，如果没有充分理解任务难度并作出预计，也不该作出承诺。坦白的讲，出现上述问题，都是不专业的表现！”
“等等，有个问题！”杨姐打断道，“我记得项目组会讨论和制定开发计划明确任务的总体计划和细节安排，并定期检查和调整。为什么还会发生你说的这些意外呢？”
“你提了一个很好的问题！呵呵，熟能生巧了嘛！”柳哥朝杨姐翘了大拇指，“很多项目经理都会采取类似的方法，经典的项目管理理论是这样建议我们的！但是，一个现实的问题是，试图让计划的每一个细节都一清二楚是困难的，可以肯定的是，项目经理很难将所有的依赖关系都整理妥当，编制过类似图表的项目经理都体会到过，在项目执行过程中总会有你未能列入计划的新任务插入其中。所以，这些像蜘蛛网一样复杂的图表网络，完成编制可能问题不大，但要保持更新使与项目实际状况保持协同就是一件极其痛苦和艰巨的事情了，到后来很可能就变成了装裱项目组和应付CMMI、ISO等检查的装饰品了！”
“我们知道，在项目管理理论中，制定进度计划工具与技术很多，诸如关键路径法CPM，计划评审技术PERT，前导图法PDM等。这些方法和技术可以帮助我们识别任务队列中的关键任务或者高优先级别的活动，使我们清楚如果其中某一条链路出现问题，进度方面会受到什么样的影响。因此我们通常会关注关键路径，而不在关键路径上的延误行为，经常会被忽视，或者未能及时察觉。个人认为，后面这种行为恰恰是很多项目遇到麻烦的原因，因为项目组的每一个任务和活动的优先级是会变的，例如取决于这个任务被延误的时间有多长，项目组遇到的麻烦通常都是由许多环节的延迟日积月累造成的，量变引起质变！”
“最后一个经常被使用的理由是，‘某某没有按时完成他的任务，影响了我的工作’，这里某某可能是项目组内的人员，也可能是参与这个项目的第三方分包商。例如前段时间我们实施的一家客户，在PACS接口开发上，由于公司、医院与厂商之间的沟通问题，导致我们的这个接口开发人员等待了一个礼拜。这种情况确实存在，但是可以尝试避免，任务承担人员在提交计划之前应该就时间安排与相关单位和人员沟通确认并以传真件等类似的契约形式保证下来。所以发生这种情况的时候，我认为上报计划、作出承诺人员应该承担他的责任！”
“柳哥！像你这样做的话，我担心每个人对任务的估计都会变得相当保守，确保他对你的承诺都是旱涝保收的。但这会使你整理整个进度计划的时候发现，完成项目所需的时间将是预计的N倍了，你可能没法对老板交代了！”
“不错，这确实是一个问题！我想到的可能的解决办法有几个！”
“第一，度量计划使用资源的合理性！对于保守之极的估算，必须想挤压海绵里的水一样。我想，采用专家估算或者行业数据作为参考还是比较可行的。在共同确定这个数据的时候，我们要给开发人员一个猴子摘香蕉的难度，就是说开发人员按照这个计划是需要稍微努力一下的，例如加加班之类的。这里面一个引申的问题，很多开发人员说他的任务已经完成80%，听到这个我认为项目经理都是持怀疑态度的，因为这个80%怎么得出来的是很难给出可支持的证据的，很多情况下都是他个人主观估算的，或者纯粹就是为了欺骗QA或满足项目经理的期望。”
“第二，很多开发人员估算进度都是基于自己完成任务的最乐观估计进行的，这不是进度表了，我认为是痴心妄想，这样的项目未开始就注定失败的。当整体时间有限制的时候，尽早的取消一些过多的项目任务是比较合适，即所谓的项目范围控制，确保把有限的资源优先用在关键的任务上。”
“最后，我认为，大部分软件开发项目延迟的原因不是因为研发阶段的延迟，毕竟这项工作的真实投入只能占据整个流程中的一个很小的部分，而且这些工作在我们公司内基本上是机械性的。造成开发项目延迟的更多原因在于计划没有得到很好的贯彻，研发就成了替罪羊。因为大家都好像比较能接受研发阶段把事情搞砸这样的说法，事实上开发人员就经常抱怨由于产品工程师的工作延误或低劣的分析制品延误了开发，又要保证后端的测试时间，很多任务都是匆忙赶工交付，无法保证开发质量。因此，需要在研发之外的环节上加强计划控制，这是需要我尽快准备跟老板和其他部门经理进行沟通的。”
后记：
大多数的软件开发项目都有比较激进的计划和日程安排。很少有项目不会去尝试一些新东西，可能是新技术，也可能是新管理思路。管理层总是在尽可能短的时间内完成项目，项目的风险要素却无处不在。很多开发人员都有失败项目的参与经验，某些人一加入项目就发现项目已经落后于进度计划，而不得不通过加班等形式痛苦的加快进度。因此，很多新项目一提出，团队就开始发怵：这次又会遇到什么麻烦？
克服这种“望而生畏”的情绪非常重要，因此处在这种状态下的成员工作效率是低下的。举行一些团队建设活动，例如聚餐、K歌并非解决之道。一个比较可行的办法是，整合各个团队成员的意见，制定一个合理的计划，在深入各个不同的子团队并与他们一起讨论。在很多关于成功会议的讨论里面我们已经说明，将整个团队拉进会议室用PPT给他们讲解计划基本没有什么用，因为影响计划的一般来说是细节和实务，在非正式场合与一小撮人一起进行小范围讨论反而更加有效，因为这种环境下大家的发言积极性会更高，而且时间方面更为宽松，有利于把所有问题都做充分的讨论。每个小型团队会议的最后，项目经理要确认一遍，是否每个与会人员都已经明确了自己需要承担的任务，只有团队领导明白了是不够的，因为工作是所有人一起配合完成的。如果某人认为你的计划漏洞百出，你都要让他说详细阐述自己的想法。如果还是不能达成一致，你就要考虑作出决定，是否应该让他在继续与大家一起进行这一计划。因为，“承担任务”真正的含义就是彼此的一个承诺。
有一点仍然需要提醒各位项目经理：千万不要试图强迫别人作出你所希望但是在他看来却不现实的任务承诺。别人或许会屈服于你的压力作出承诺，但是如果最终没有完成，吃亏的是你、是整个团队、乃至整个公司。任务的承诺在经理和开发人员双方互相妥协的情况下比较合理。
最后，强调一点，重视承诺是建设团队信赖关系的基础！我们总是希望在一个高度信任的环境下工作，这样的环境可以使我们变得潜意识的信赖团队的伙伴