第一章 项目管理失当

   尽管“你的任务估算是怎么产生的？”这样的疑问总是列在诸如“不要对你的项目经理或同事抱怨”的话题之首。但当我与刚出道的工程师们讨论问题时，首先的话题不是估算，而是职业发展和一些大众话题。这就是为什么问题总是在高谈阔论中变得无法控制。估算就是在预测未来，有太多的问题是未知而不可预见的，因而想为一个精神错乱的暴君提供一个精确的估算简直不可能。是不是？肯定是这样的，对吧？

    错了。估算来自于软件工程师在规范的基础上对最小细节的把握。要身体力行。其实很简单，有非常多看似不同的方法会为你的完工时间提供精确的预测。所有这些方法皆源自于一个简单的概念——上一次用了多长时间，那么这次也是这么长时间。没有比这更容易的了。

    通过对比之前的工作你已经明白现在的事是怎么回事了。但这还不够，真正的问题不是任务估算，真正的问题是接受这份估算。估算很简单，让人接受可不容易。

    作者注：很多咨询顾问、研究小组及试验项目把精力花在估算上。我敢肯定他们会跟你说，估算很精确，他们都专注于用技术来避免缺陷。一切搞定之后，最麻烦的是让人相信这个估算是对的。这是最难办的事，但这对于精确度却是最重要的。

    没有人会接受这样一个计划

    让我们假设一下，在执行很多项任务时，你确实记录了一下这些任务要花去你多少天时间（你是这样干了——你邮箱里邮件的日期就说明了这一点）。让我们再进一步设想，你以之前所用的时间作为今天执行类似事情的估算（你已经变得精熟多了）。你的项目经理将会有什么反应呢？我想，那将是：“哦，算了吧。你在耍我呢？”

    这只是玩笑话。让我们更深一步探讨。设想，你对你的项目经理说你的估算是来自于对之前项目艰难度的总结。他们不相信这种委屈的理由又是什么呢？以下有三条：

    上次跟这一次不一样。

    你第二次本该要比第一次快。

    上次发生了少见的令人痛苦的事情。

    让我们逐一驳斥这些强词夺理的说法。

    完全两码事

    对于来自于上一个项目经验一成不变的计划表数据，你的项目经理拒绝它的第一个借口就是：上次不一样。什么都变了，或许开发环境及工具都变了；或者设计变了，意味着工程程序也得变；或者需求变了，管理变了；或许月亮跟土星的相对位置也变了呢。

    撇开这些借口不讲，只有两个因素对你的估算有那么点影响——工具和工程程序的变化，其他因素对这次开发来说都影响甚少，或者说都微不足道。

    就算工具及工程程序的变化可能将极其明显地提升你对估算的准确性——工具的变化要必须使实现端对端功能缩减1/5的时间，工程程序的变化要必须使一周的工作量减少数天。不然，其对于估算的影响不过算是一种干扰。

    看看吧，万变不离其宗。搞定它。

    作者注：我们假设一下，一项任务需要花去你两个星期时间，这个时间有一两天的偏差。因此，工具及程序变化如果只节省一天，这对于两个星期来说已经不重要了。

    我越来越棒了

    第二个拒绝你的计划表数据的理由是：你这次本该会比上一次干得好。但有意思的是，这仅仅是因为你这是第二次。问题在于你不是干同样的项目（尽管希望是）。仅有的相同点是你所用的工具、工程程序、项目规模以及软件工程的一般性任务。

    你对软件工程的一般性任务本应该很稔熟，所以你更了解上一次的项目细节对于估算下一次的项目是没什么作用的。当然，如果你是学校刚毕业的新生，那么用在第二个项目上的时间当然比第一次要少。

    如果你改变了工具及工程程序，你的进展将会变得很慢，因为你是第一次使用它们。或许它们变化很小，或许带来效益不错，这当然很好。但不要欺骗自己，它们同样带来了难题。

    你确实很想以一个相同的模式对当前项目与前一个项目进行比较。比较越到位，这次估算就越精确。但两次估算方法的最大不同在于，它们从哪方面进行比较。

    哦，不。不会再发生了

    你的项目经理拒绝你的计划表数据的最后一个理由是：令人痛苦的事只在上一次恰巧发生了。比如意想不到的安全补丁，或者功能模块比起预期的复杂得多，组织结构及关联工程的重置，更不用提类似暴风雪、地震这样的事了。对的，地震，你根本没办法预测地震。

    就算你有测算恐怖地震这样的本领。还是有出人意料的补丁、功能模块、组织重构及灾难性事故在项目的每一个环节中等着你。通常，随机事件会时而发生，但是它们的影响并非你所想象的不可预测。感谢李雅普诺夫的中心极限定理，随机事件的总体影响服从于统一均值分布。不管上次花了多少时间，这次花的时间也差不多一样。就是说，只要你不自以为这一次不一样（译者注：概率上讲随机事件分布是服从一定规律性的）。

    旧瓶装新酒

    好了，我们已经论证了你的项目经理会拒绝你提出的估算方案。因此，他们一方面强迫你去设计个你认为根本不可信的可笑方案，一方面责备你动作慢没有早些拿出这样的估算方案。

    我们已经知道，精确的估算非常注重细节。重要的问题是，“你怎么将你认为细致入微的精确估算变成让你的项目经理愿意信服的那样？”

    假设你的工作时间是可以把控的——这些时间是排除了像地震、查看Email、浴室漏水等事件干扰之外的正常工作时间，那么你将按小时而不是按天数设计你的估算方案。没有了这些琐事的分心，你的估算方案看起来将更精致、更可信，就算它跟原来的还是没什么两样。

    按小时估算看似有点难，因为你手头没有这么多详尽的数据。但是，你确实可以通过一些简单的方法，如计划扑克法（或者团队DELPHI法，它更精确、更具灵活性），从而快捷、简易又精确地按小时安排你的工作时间。

    计划扑克法是由三个以上的工程师围着一张桌子各自私下对同一项任务做出自己的估算。他们同时出示各自的估算从而不会彼此施加不当的干扰。如果大家的估算是相符合的，事情就算完了。如果不一样，最高及最低估算者解释一下他们的原因，在团队中讨论他们的想法，并不断重复直至达成共识。这个过程将各种潜在问题的可能性摆上桌面。

    当你们出台了一个可信的按小时计量的估算方案后，还是不能得出结论说完成某项任务要用多少时间，而只是说你在一星期内需要花多少小时用在一项任务上。即便除去假期、培训及大型会议时间，大多数团队只将不到一半的工作时间花在项目任务上，其他的时间他们都在开会、回复邮件、午休等。如果你的项目经理不相信，很简单，只要花两个星期的时间让这个团队记录他们的工作时间，数字是不会骗人的。

    作者注：即使除去假期、培训时间、线下会议以及其他安排好的非任务时间，大多数工程师团队只用了大概42%的时间在他们的任务上。你可以通过多种方式，如不收发邮件，不开会，或者让功能团队合署办公及自我管理，或者可以使用诸如Scrum迅步法加强团队专注度，从而为你的任务增加几天或几个下午的时间。

    我目前的团队使用“事务监控点”代替按小时计量任务。这个概念很简单，你可选用一种监控点计量法代表任务平均长度，比如8个这样的点。通过这种任务平均长度来估算其他相关任务。大多数团队使用块状长度来估算，而我使用斐波那契数（1,2,3,5,8,13,21,34,…）。几星期后，你计算一下你的团队一个星期可以完成多少个监控点。这就是你团队的速率。你可以在实际操作中更新这种速率并利用它来精确地将事务监控点转换成天数。

    你的成果可能各种各样

    就像我之前提到的，有一种稳定的随机性或“变异性”贯穿于整个项目的各个环节。虽然它们有平均值，但每个估算都会因为有标准误差而出现状况。标准误差是基于百分比的，它的大小决定于估算范围的大小。因此，为期两天的估算可能左右误差就一两小时，为期两星期的估算误差就在一两天时间了（同样可能多一两天或少一两天），而为期三个月的估算误差就将是一两星期。

    只要你不要过于乐观，随机性并不会产生波澜。在项目完成时，整个项目的标准误差跟各个个体任务的标准误差差不多是一样的。如果你太过乐观（说“下次肯定花不了这么多时间”），你的标准误差就会不断增加，而不是平均值了。

    我的观点是，估算两天的任务有多少分钟的误差或者是三个月的任务有多少天的误差并不重要。重要的是你需要一个数量级的时间估算，就像在几年前我的第一篇文章中说的：“开发时间表、飞猪和其他幻想。”

    我要相信

    你应该怎么估算？与同事们专注于你手头上的任务或是通过计划扑克法或团队DELPHI法等手段将这些任务按优先等级排序（计划扑克法对理解一般任务有帮助，DELPHI法则对其他有用）。这只是相对容易的部分。

    真正的问题在于最后让人相信并接受你的估算，然后按计划进行。如我之前所述，过多的承诺是愚蠢的，它的要命处在于会导致“向死亡进军”（参看前述内容）。死亡行军是一个重要的风向标，它表示管理是脆弱的、无力的、充满谎言的和不负责任的。

    计划安排出现的问题如恶魔一般，但是可以避免的。如果你适当地安排工作的先后次序，先搞清楚什么是最首要的，你就会在计划执行中减少压力。当你基于你的估算做出可行性的承诺时，就会让你的客户及合作伙伴感到可信，从而建立信任，提升你的团队及公司的名誉。要有个好的估算是相对容易的，但相信他们并相信自己是个挑战。