修炼2 这个任务，估计一下工作量，需要多少天？

    终于，两个星期后，还是Francois出手了，最终还是他解救了我。

    “Ying，熟悉Java吗？”他兴冲冲地跑过来问我。

    “不会……曾经课堂上讲过一节课……算会一点么？”如果是两个星期前，我会很肯定地说，“不会。” 然而卖不出去的肉是没有底气说“不会”的，只能说，“我可以学。”

    “我可以学！虽然几乎等于零……”

    “好样的！你是程序员，懂编程就可以的，项目上先让别人带一带就可以了。”

    终于上了第一个项目，摆脱了鄙视链的最底端。路过其他那帮“InterContract”的老伙计们的时候，似乎头就不自觉抬得更高一些。

    然而这种项目上“带一带”的经历都是很痛苦的。我在简短的4天观摩期过了之后，就开始被安排独立做开发任务了。

    项目一般般，也没啥，不过就是北约陆军OTAN的战地指挥系统而已，还包括了战地通讯系统，泰雷兹集团（全球军工企业第九）和北约部队联合开发的项目。

    随便凡尔赛一下。如此草率的招我这样一个人进项目，真替他们战斗力捉急。

    项目经理是一个华裔的法国人，他是我的第一个项目经理，忘了名字了，就叫“PM1”吧。虽然亚洲面孔好歹有一点亲切感，但是经验告诉我，自己人才需要提防。

    “这个功能，估计做多少天？” PM1指着一个任务项的标题问我。标题显示着几个单词，每个单词我都认识，但是合在一起我就不认识了。

    现在回想起来，这是后来整个职业生涯中，第一次遇到这个经典问题。在此之前，都是对一个课题进行研究，没有那么强的任务管理和时间管理的性质。后来工作之后，在各种大大小小的项目里，都反反复复遇到这个经典的，毁人不倦的问题。

    “这个任务，估计一下工作量，多少天能完成？”我认为这个问题是万恶之源，所有一切项目上的不幸都与这个问题多多少少相关。

    作为一个嫩得不能再嫩的新手来说，这个就是灵魂拷问了。

    “不知道啊，需求我还不清楚呢。”我反问，这是新手弱鸡发起的最真实的呐喊。

    “这个得看你的预估了，我没法说。”项目经理是个老手，这是一场满级大佬与新手弱鸡的对决。

    “哦，我不知道啊……”我挠着头说。

    “大概估一个就行，不要紧的。”满级大佬满脸堆笑，见我还不就范，于是虚晃一枪，使出了常见的一招——烟雾弹。

    马上我就会学到，“不要紧”的事情是不存在的。

    【大概估一个】其实是：【你自己说的话，将来自己要认的。】

    【不要紧的】其实是：【我们后面的计划工作全部会基于这个预估。】

    “嗯……不好说啊，我也不清楚，只能瞎估计啊。”这不是在矫情或者反抗，是真的没有估计能力。

    “差不多就行……两天？三天？四天？”项目经理看我仍然负隅顽抗，终于忍不住使用了另外一招——引诱法。

    像我这种新手弱鸡那里能辨识得到这种陷阱，能抵抗到这里就已经不错了，于是懵懵懂懂选择了4天。

    “好，那就四天了。”项目经理满意地在那个任务项旁边的工作量一栏里，填上了4天。

    结果，做了4个星期……

    还没做完。

    我就不谈过程中每天如何加班熬夜，每天厚着脸皮向别人请教，每天晚上9点半去买麦当劳汉堡当晚餐，每天被催着交活，每天说自己还没做完，还需要大概3、4天。

    有一幕印象非常深。

    那天公司我所在的Openspace工作区已经走空了，连灯都已经关了，只剩下我和我面前的电脑屏幕。

    电脑显示的时间，晚上9：30。

    走廊尽头的另外一个部门的工作区人声鼎沸，应该在开派对，音乐声与欢笑声交织在一起，偶尔有开香槟的“砰”的一声。这边整个大办公区只有我啪嗒啪嗒敲键盘的声音。

    我正专心盯着面前的屏幕的时候，黑暗中有个人影从过道里走过，我们把对方都吓了一大跳。

    我抬头看的时候，老熟人，Francois，我亲爱的经理。

    他是过来去储物间拿酒的，没想到还有人没走。于是过来关切的问我，“怎么回事啊，这么忙吗？遇到了困难了吗？怎么晚了，需要做这么晚么？白天时间不够用吗？”

    “哦，白天……帮别的同事处理了一些问题，晚上需要把自己的工作搞定。就晚了点。”我碍于面子找了个好听的理由。

    “那不行啊……是谁自己的工作不搞定？占用你的时间？我去找他，跟他的经理谈谈！” 虽然明知是假的客套话，但是我还是蛮感动的。

    不痛不痒地寒暄几句之后，Francois走了。我那天11点半才到家。这个时间虽然在国内的互联网公司来说，不算加班。但是那个时候，整个公司都走光很久了，打扫卫生的阿姨和保安轮番来赶人走的滋味，我想很少人体验过。

    四个星期之后，项目经理PM1也慌了，不能总这么“还有3、4天”循环播放下去啊。因为我的活还没有做完，后面其他同事也进行不下去了，不得已就请另外一个更有经验的程序员过来接手帮忙。资深玩家就是不一样，简单看了一下我的任务，就点爆真相了。

    “这是给你一个人的任务吗？这任务这么分配有问题啊，这不是一个人能干的活啊。”

    于是带着我重新拆解任务。将做完的，正在做的和没开始做的重新梳理一遍，将任务分割成了若干个阶段，若干个模块，最后把一项一项的任务告诉给了PM1，询问他哪些必须先做，哪些得后做，哪些可以不做。

    于是，我开始做重新分配给我的那些工作项，其他的工作项另一同事也在帮着同期处理，两天后，任务完成。

    等终于完成了这项任务，我才猛然领悟，自己领的第一份任务就掉进了一个巨坑里。

    最初以为这就是正常程序员的日常，以为只是自己的能力不够，就是需要付出更多努力，但是发现其实并不光是努力不努力的问题。经过很浅显易懂的任务拆分之后，一项庞大的任务也就这么迎刃而解。更有经验的程序员大哥并不只是技术比我更牛叉，而是从做事方式的角度就把我甩了几条街。

    后面的工作中，我逐渐从第一个任务的惨痛经历中走出来。慢慢地，一个人加班的情况也越来越少，下班的时间也越来越按时。

    在我后来认领开发任务的时候，学会了花一些时间吃透需求内容，如果有非常不明确的内容，那就建议PM1把任务拆分成不同阶段的子任务，明确的内容优先处理。尤其重要的是，学会了拒绝接受那些很庞大很模糊的一大块任务。

    因为任务切分得比较仔细，难度不会很大，因此经常地还能比预估的时间更早地完成任务，更早去领下一个任务，无形中增加了PM1的工作量，搞得他都有些应付不过来了。

    除了工作方式上的改变之外，技术上也有所成长，还能时不时地参加大佬之间的讨论，发表自己的意见。难能可贵的不只是提出了比较好的实现方案，而是以当时蹩脚的法语还能说得大家认真去听我的方案。

    记得有一次，几个比较资深的同事和项目技术负责人在一起讨论问题的时候，看了我实现的功能。发现我不只是按照其他同事实现的方案照搬过来，而是加入了我的重新设计，将时钟和报警提示放在了另一个位置，用了更好的显示逻辑和方法，这也是得益于开始动手干活之前做了一番研究。我以为他们过来是要批我一顿，没想到技术负责人却很开心的说：

     “ying，其他人都是一直复制这块功能，你这么改了之后，效果好很多呀，是你自己想出来的吗？”

    我记得很清楚那天我是哼着小曲一路回家的，作为一个半路出家的程序员，在2、3个月之后就开始得到技术负责人的表扬，看到一帮比我资深很多很多的大佬们围在一起看我的代码，问我怎么实现的这个功能，问我如何解决这个那些问题的时候，我感觉已经这份工作给我带来了巨大的荣誉感。

    虽然事后想想可能是自作多情，但是这不就是程序员的简单快乐源泉么？虽然只是一块被卖给客户的“肉”，但也被人夸赞是一块有“想法的肉”、“不一样的肉”，这才终于第一次体会到做“肉”的乐趣。

本章小结：

    作为对项目结果负责的一方，希望掌控项目的过程，这一点无可厚非。所以“这个任务，估计一下工作量，需要多少时间？”这个问题经常会被问起。

    但希望获得一个准确的回答，只是一个美好的愿望而已。

    软件工程项目的实施过程，是一个知识创造的过程，这个过程之中，我们的认知是发生了变化的，包括客户、用户的认知都在不断地发生变化。

    需求会变化，实施方案会变化，人员会请假，偶然性地会有突发事件处理，再加上我们与生俱来的对困难的低估判断本性，我们不可能准确地判断做完一件任务需要多少时间。

    另外，在开始实施一个任务的时候，往往我们对这个任务是缺少实际认知的。“只有做了才知道。”这就是大部分的实际情况。

    所以要“估一下时间”，并且基于这个“估计的时间”来安排做计划，基本上相当于往天上扔一堆二极管，然后掉下来一台电脑的概率。

    经历了这么多年项目洗礼之后，如果我能够回到第一次PM1问到我那个灵魂拷问的那一时刻，我想我当时应该这么回答：

    “这个功能，用户关注的核心价值在哪里？客户希望在哪一个时间节点达到什么样的目的？我建议不要考虑我做这个任务需要多少时间，而是基于客户的真实目的安排任务，我们不妨可以和业务方讨论一下，在能投入的范围内，有没有最优的方案达到最理想的效果。“

    当然，无论话说得多么漂亮，方案订得多合理，但如果技术上啥都搞不定的话，所有这一切，就只能是纸上谈兵了。

    再后来，接触敏捷开发之后，再次验证了这是一个普遍问题。对啊，事情就是变化的，计划就是被用来打破的，因此关注价值，明确哪些事情是“正确的事情”，比知道一个任务是花2天、3天、还是4天更重要得多。