导语:你是否也觉得在开始工作前做时间预期反而是一种时间的浪费?可惜项目经理似乎永远和你思路相反,咄咄逼人。侯世达定律:做事所花费的时间总是比你预期的要长,即使你的预期中考虑了侯世达定律。——道格拉斯·侯世达(Douglas Hofstadter)
Kat Busch曾经是Dropbox的项目领队,如今他的工作是一名软件工程师。听听作为程序员的他是如何理解“时间预期”的重要性的。
图片来源:Rogerborrell [CC BY-SA 4.0 (http://creativecommons.org/licenses/by-sa/4.0)]维基百科
我有一个朋友是产品经理,有一天她和我吐槽:“软件工程师永远无法预估完成一个项目需要多长时间。你说我到底该怎么办?”除了她以外,另外两个公司CEO也这么和我吐槽。
作为一个程序员,我也可以作证。我遇见过有个程序员预期一个项目两天完成,却最终花了四个月。如果每次都是这种情况,单单把预期时间乘以二都远远不够,而且错误的预估时间会对工作产生极大的负面影响。有的公司甚至因为预期时间错误而将整个项目的发行推迟了数个月,这是件真事。
宏观地来看,问题全都源于工程师和产品经理、公关等人的时间预估方式不同。大部分软件工程师只是简单地计算如果万事顺利,写出一份工程原型需要的最少时间。然而对于那些产品经理,他们只想知道项目具体在什么时候可以发布。而这两种概念截然不同。
对于软件工程师,可能要花一辈子的时间学会准确预估时间。但如果忽视这项技能的学习,你和周围的人都会被拖累。精准地预估时间能让你轻松鹤立鸡群,也会让你的同事感受到你的专业水平与高质量的工作。
学习预估时间的原因
经常有软件工程师问我:“为什么要做时间预估那么麻烦的事?”还有人认为这简直又增加了工作成本。(当然,事实就是如此)他们抱怨:“不用预估时间的话我可能完成得更快呢?”
然而学习预估时间有两个重要理由:外界依赖重点排序
外界依赖
要知道,历来没有任何要事是只靠一个人或者一个团队可以完成的。任何项目都会有或多或少的“外界依赖性”——比如要和非工程师团队协调(零售商品部、金融部、公关部、用户支持等等),再比如和其他的工程师团队,甚至是终端用户协调。对于公司的客户经理或者CEO,与外界协调是工作的重要一部分。而这就意味着,需要做出精确时间预期的人,即软件工程师,恰恰不是最需要知道预期时间的人。这一矛盾性在一定程度上解释了程序员不喜欢做时间预估的原因。
重点排序
预估时间可以让你轻易地找出工作的侧重点。在编写程序时,“物有所值”这四个字很重要。然而如果你不能做出正确的时间预期,你就无法获得相应价值的回报。即使你正在处理世界上最酷的软件特性,如果你可以预先匀出一点点精力做个时间预期,你就可能意识到就算再酷的软件特性也不值得你花费那么多时间。
做一个假设——用同等的时间,你可以提升一个网站50%的运行速度;或者你也可以同时分别提升两个网站40%的运行速度。如果你跳过了时间估计这一环节,你可能永远不会知道你的能力所及比你目前所完成的更厉害。
时间预估
既然现在大家都对时间预估的必要性有了一定的认识,那我们就来说说时间预估的方法。
程序员常常以为自己要写的程序很简单,所以导致低估了需要花费的时间。然而发布程序远没有那么容易。时间预估必须囊括编码、测试、调试以及最终完善等所有步骤。况且你还不能排除参加会议、访谈、代码评审、发送邮件这些零碎的时间。
程序员总是低估项目时间的另一大原因是在编码过程中,我们很可能遭遇一些目前无法预计的未知领域。当然,你不必指望自己可以预见这些未知领域——比如说你的IDE忽然更新打断了你的项目,然后你还需要花费一整天来修复项目。这些意料之外的情况当然不可能被事先预计到。
除此以外,尝试下面这些方法,你或许可以更好地做出时间预估。
第一步:制定一个技术方案
在着手项目以前,你应该先制定一个技术方案,或者梳理出重要部分的解决办法。把方案给团队其他成员参考,他们才能知道你的想法并给出回馈。制定技术方案就给时间预期开了一个好头。依照方案逐步完成,你会发现你已经“神奇地”预计到了大部分可能遇到的未知领域的问题。你可能在制定方案时就预测到自己要花一天时间更新数据库,所以预期的时间也会精准不少。
在这一步中,“粒度”是个重要概念。如果在实施过程中你遭遇到任何模糊不清的步骤,必须使用图解或者进一步分步解决,那么这一步很可能出现问题而导致全盘皆输。
如果你想具体了解如何制定技术方案,可以参考Alicia Chen的文章《当你要求更多时间的时候你在要求什么?》(What do you mean we need more time)。制定技术方案时,最重要的就是和产品经理或者股东沟通好一切模糊不清的环节,这样才不至于到最后一步功亏一篑。
第二步:预估每个步骤的具体时间
你要预计技术方案中每一步大概要用多少时间能够完成。当然在预估的时候你需要细化到各种细节的时间预估,比如“是否已经建立了数据库”等问题。如果仅仅靠以往的经验之谈,以为自己只需要建立一个简单的原型,在具体实施的过程中你会遭遇更多问题。
第三步:在预估时间上加一点宽裕时间
如果已经规划好了大致的时间框架,你还需要考虑到:
  • 调试时间:
项目过程中永远可能出现新的问题。大部分的调试都需要你靠自己的经验解决。
  • 会议、访谈、放假时间等
你不可能一整天都坐着写代码。你要计算的是你每天实际工作的时间。做时间预估之前,好歹先看一下自己的日程安排。
  • 最终测试及扫除故障:
基本上大部分程序员都是边写代码边做测试的,但是大部分的团队都会在项目结束后进行额外的测试环节,以确保代码一切无误。在预估时间时也要为最终测试留一部分时间。如果你操作的还是一个分阶段上线的项目,初次上线就可能暴露你需要修复的问题。所以一定要留出这部分时间。
  • 代码评审:
先问问自己,一般而言,这类代码需要评审多少次?一共需要花费多少时间?务必要为评审员留出充分的时间(所以不妨也和他们确定一下日程安排)。如果你编写的这类项目只可能找到一个评审员,那就要确保事先和他约好行程 ,并且提前问问能否找到其他人。毕竟你约到的人很有可能在关键时刻忽然出去旅行,或者忙得不可开交。
当你学会把这些琐碎的小事都考虑在内,你就能做出更精确的时间估算。不过这样预估出的时间一定比你以前预估出的时间长得多。然后,你一定会倍感压力想要缩短时间。不过要相信,一旦合作伙伴发现你的工作非常可靠,他们不会介意你的预期工作时间太长的。
第四步:项目发表后,回顾一遍你时间预估的过程
虽说项目发表之后还要回顾一遍听起来简直是痛苦的折磨。但是回顾一遍可以让你吸取经验,下一次才能做得更好。
想想在写代码的过程中,哪个环节比你预期的时间用时更长?如果最终的综合测试比你预期的时间长得多,那就记录下来,在下一次预估时预留更多时间——或者就索性改进一下你们的综合测试环节。
沟通交流永远是最重要的一步
一定要和队员沟通好日程安排,如果有冲突一定要尽早解决。如果你发现数据库里有个安全问题有待解决,在软件发布的一个月前就通知项目经理,你才能有时间重新来过,他们也能有时间通知公关、用户等各个环节,保证延迟计划可行。
与工作团队的有效沟通还可以让你知道原本预期的时间是否会受到影响。项目过程中,设计师很可能忽然说:“哎呀,写这个酷炫的动画要花一周时间,不如全都删了吧。”或者项目经理可能会忽然说:“这就是个试验用的原型设计,不用在这个迭代上花太多时间修复bug。”或者会有经理直接帮你搞定任何需要参加的会议。
作为一个软件工程师,永远不要有太大的压力,仅仅为了取悦上层而报一个不可能完成的最短预估时间。要知道,上报一个可行的预期时间并且随时更新项目进程才会显得你更专业。
当然对于团队里的其他人而言,可能需要一段时间的适应来尊重你的专业判断。记住,或许删掉程序的一些特性和内容可以缩短项目时间,但是双方的抱怨争吵却不会放过你。
最后,我想说没有人可以完美地预测出完全精准的时间。我们唯一能做的就是学会沟通,学会理解,学会分清主次。
继续阅读
阅读原文