在1995年当我在美国从事IT工作时，曾以咨询师的身份加入一个有数千员工的大公司的研发团队，使用Visual C++实现一个汽车修复估价系统。当时我们没有什么项目管理工具。因为没有足够的数据可借鉴，项目经理对一个项目完成所需的时间完全就是拍脑袋得到的。不仅如此，就是完成某个功能（如，汽车修复的估价报表）的时间也是可以偏差到百分之几百。

当时Jeff是我们的项目经理，所做的项目是把一个现有的COBOL汽车修复估价系统转换成更为先进的C/S （Client/Server）系统。公司给外部聘来的咨询师的费用是以小时计价的，在项目做完后合同便解除。如果咨询师不安好心，一个月可做完的项目可以做成两个月，他不但工作轻松还可以多赚一个月的工钱。那时Jeff并没有一个有效的方法来保证雇用的人都认真在工作。他唯一能做的也就是，每日开会听听大家报告进展，并经常在我们背后走来走去，用余光瞄我们的电脑荧幕，看看有没有人在做和工作无关的事。当时，这种对员工不信任的低效管理方式是如此之普遍，以至于英文中还特定地有个词句叫“look over one’s shoulder”，就是用来形容经理老要从其属下的肩膀后看他到底在做什么。这实在形容得很形象。

无独有偶，事隔十几年后，我认识了在北京IT公司的研发管理部的宋经理，也看到同样的情况。他在美国拿了个硕士学位，之后就加入了这北京的IT公司，当了两年程序员便升为经理。当我和他聊到研发项目的现状时，他感叹道：“我们的项目总是没法如期完成。每个程序员和测试人员看起来都很忙，但效率却很低。我怀疑他们常常在做与工作无关的事，但我唯一能做的也就是look over the shoulder”。我听后笑了出来，“你的英文口语真还学得不错呀！”之后他解释说，他们在把项目分解成任务，在将任务布置给团队成员后，便是看成员的良心办事了。如此操作使他不断地面对一些管理问题，归纳后大概是下列几点。

1．员工总说工作很忙，但不知道在忙什么。员工在项目进行中不愿接受新任务。

2． 绩效考核时缺乏数据，每个员工都认为他做得比别人多，但工资却比别人少。

3．项目延期是家常便饭。任务完成所需时间由资深人员决定，但实际完成时间可以短到只是1/3，或是长到数倍。所以没有人相信计划是真格的，连做计划的资深人员也没把计划当一回事，敷衍了事。

4．每个项目组都要求要加人，高层也无从判断那个项目组是低效，还是真的缺人。

知道问题后，我建议宋经理使用工作日志。他说，工作日志流于形式，他们用过，但没提高效率，后来大家认为它浪费时间，就废除了。我跟他解释到，那已经是老黄历了，在新方法的帮助下，每人每天只费10分钟就能产生巨大的效果。他听了后半信半疑。但不论如何，我们还是花时间把整个团队的管理问题研究了，并且在几个月后对一个新项目作了实验。过程简述如下：

1．由于这项目是将现有的C/S （Client/Server）系统改写为B/S （Browser/Server）系统，需求相当的确定，瀑布模式最为适合。

2．资深人员在项目启动前粗略地把项目分解为125个需求、编程和测试任务。

3．这125任务中的80个由15个团队成员（产品专家、程序员和测试人员）自行认领，剩下的则由资深人员与大伙协调分配。（请特别注意，一个任务可以由多人一起负责。）

4．每个任务完成所需时间是由任务负责人与资深人员讨论后决定的，而非以往直接由资深人员决定。由于任务负责人也参与，他对他的承诺要负责任。

5．全部125个任务所需时间加起来共是780人天。依照以往经验，开会、协调、处理突发事件和填写工作日志所需时间约占25%，所以整个项目需要时间为（780 * 1.25）= 975人天。如果没人请假，975人天的工作分配给15人，大约需要三个月完成。

6．项目开始后15个团队成员每人每日花大约10分钟填写工作日志。填写的数据中最重要的两个是（一）每日对每个任务所花的时间，和（二）任务还需多少时间才能完成。（注意，任务还需多少时间是由团队成员根据实际情况对余下的工作重新作出的估计，这样做能够确保实事求是地掌握工作量及进度，不至于造成浪费或不切实际的期望。）

在这个新项目中宋经理不再把精力花在监督团队成员是否认真工作，而是开会协调和阅览下列页面以及报表：

l  小会– 经常开小会能保证每个人把他个人的技术问题尽早曝露出来，通常团队里总会有一两人能提出解决问题的建议。

l  个人任务中心– 此图详细显示了每位员工名下的任务，以及各任务已花费的时间、还需花费的时间、完成百分比、预期完成日期等，让管理者一眼就能明了每项任务的进展状况，从而在需要的时候能够及时对资源进行调配。

l  团队人员工作量视图– 此图形象化的表现了团队人员时间的分配状态。

l  甘特图– 若某项任务发生延期，则甘特图中将有红星作为标识，用以及时提醒管理者相关信息，无须逐一核实任务时间，即可了解任务是否在正常状态。

项目实际上花了三个半月完成，比预估的三个月多了半个月。这主要的原因是在项目实施中发生了：（一）需求的增强和改变，和（二）员工请假。虽然实际花的时间比预估的多了半个月，公司高层对项目完成的结果还是非常满意。我小结了这个项目的心得：

1．因为在整个过程中，没有任何团队成员离职，没浪费任何时间在工作交接上，项目完成的结果（产品质量和时间）还是比较理想的。

2．虽然使用的是瀑布模式，但同时也采用了不少更为敏捷的做法，比如经常性的会议，确保顺畅的沟通并及早暴露问题、解决问题，每天都对完成和未完成的工作进行回顾等。

3．团队成员并没经过任何方法论（如敏捷或CMMI）的训练，但前期充分的沟通和使用工作日志的培训克服了这些困难。培训是一个很重要的关键是，要让参与者不仅知道操作的方法（how），更要让他们知道如此操作的目的（why）。

4．由于程序员和测试人员是第一次参与估算任务所需时间，他们还是把任务所需时间低估了些。精确度在下一项目应该可以大幅改善。

项目完成后一段时间，当我和宋经理一起喝咖啡时，他和我分享了他的感受。他说，有这么一次经验，以后把瀑布模式转换为迭代模式也没太多难度。此外，

1．执行中团队成员的责任心变重了。每个任务完成所需时间是由任务负责人自己承诺。有的人为要在承诺的时间内完成任务，自己还偷偷地加班。

2．团队成员因能及时完成任务而很有成就感，工作很有激情。

3．团队成员对评估满意度提高了。

4．还有，他下楼喝咖啡和闲聊北京国安足球队的时间也增加了。呵呵！

我说，那你不用再look over the shoulder了？他说，是呀！我说，那今天的咖啡你请客呀！他欣然答应了。