软件开发过程管理被比作放养猫。换句话说，你不能真的做到这件事，但你可以尽你*大的努力去做。再换句话说，软件项目就像试图在 NBA 防守勒布朗·詹姆斯 (LeBron James) 一样。你根本就阻止不了他，*多只能希望牵制到他。

软件项目的开发管理是一门不精确的科学，这不是什么秘密。以下是我这些年来学到的 11 条真理，它们帮助我理解了，要管理软件开发项目这个奇怪的世界，我们的能力是多么的有限。

无论是你花一个小时还是一年的时间来做估算，估算结果都是错误的。事情本来就是这样的。结果不一定错得大相径庭，可能只错了那么一点点，但肯定还是错的。如果你看到一份错误报告，并认为“修复它需要一个小时”，那么几乎可以肯定的是，它不会正好需要一个小时。它可能需要 45 分钟，也可能需要 3 个小时，但正好花上一小时的可能性很小，甚至可能仅仅相差一两分钟。现在，你可能会说，“大约一个小时”。这实际上是一个更好的估算，因为具体的、精确的估算是错误的。眼下，对于一个可能只需要一个小时的短小项目来说，这不是什么大问题。但是…

项目越大，估算就越不精确，尤其是在项目一开始就做的估算。就像上例那个一小时的估算，如果你将一个项目估算为一年，那么它可能需要 9 个月或者 36 个月。在某些情况下，它甚至可能需要五年时间。没有办法知道这个项目是什么时候开始的。项目越大，“未知的未知”就越多。通常项目越大，就会有越多的人参与。也就是说，随着项目规模的增加，会有更多的变量和更多的事情发生，而这些你根本就无法预料。所有这些事情都会增加项目的时间，而这些时间你一开始就不会做到计划里，原因很明显，你并不知道它们会发生。

在构建软件时，完成一个项目所需的*有价值的一件东西，就是团队中的开发人员以不受干扰的方式集中精力的能力。分心的事情越少，团队的效率就越高。就是这么简单。软件开发经理的主要职责之一就是减少团队分心的次数和持续时间。当软件开发人员不受干扰时，他们有很高的工作效率。当他们被打断时（无论是由于开会还是被人问问题或者其他的什么事情），他们会快速丧失工作效率。我们都知道“心流”，都知道进入并维持在“心流”状态有多困难。流动的时间就像黄金一样宝贵，应该予以保护。

霍夫施塔特定律是这么说的：“即使你考虑到了霍夫施塔特定律, 项目的实际完成时间也总是比预期的要长。”——维基百科（//en.wikipedia.org/wiki/Hofstadter%27s_law）这与估算有关，但值得注意的是这句格言的妙处。你可以虚报你的估算，因为你认为这样可以为你赢得完成任务的时间。你可以添加额外的因素，将“未知的未知因素”做到计划里，并增加你的估算，从而考虑到实际将比你认为的时间更长，但是*终，实际上完成一个项目仍然会比你认为的实际上更长的时间要更长。

这条真理对于一些管理者来说真的很难理解。软件需要多久就需要多久。没有办法让它更快。你可以要求团队投入更多的时间。你可以挥起鞭子、拿起大棒。你可以乞求、哄骗、恳求开发人员。你可以说，“但是，这应该只需要三个月啊！”但*后从长远来看，你无法提高软件开发团队的速度。如果你开始意识到霍夫斯塔德定律的正确性并认为“我能让这些人工作得更快”那么你就错了。你所能做的就是减少他们的干扰，让他们自主工作，从而防止他们降低工作速度。这个区别很微妙，但却很重要。

同样地，你可以要求团队投入更多的时间，熬夜、周末加班，以及种种“鞭笞”的手段，你可能会从中获得一些 (非常) 短期的收益。但如果你试图让它成为一种常态，如果你试图让团队的引擎始终在 RPM 的红线上运行，它就会被烧坏。很快，你就会看到收益递减。人，就像赛车上的引擎一样，不能长时间承受过多压力，否则就会出现故障。

没有什么比要求工作时长更能降低生产力了（例如，你的开发人员要连续几个小时坐在椅子上）。你可以度量工作时长，感觉得到了一个能够真正显示出人们工作效率的指标。但是这样做就错了。要求工作时长只会使团队士气低落，因为他们实际上是想把时间花在思考上。大脑时间才是*重要的。你这样想：假设你是一位经理，对于你来说*重要的是看到团队坐在电脑前“工作”。你在办公室里走来走去，看着那些开发人员坐在椅子上敲击着键盘。真是一番繁荣景象。但之后你偶然发现一些开发人员只是坐在那里盯着屏幕。就是这样傻坐着，他们只是坐在那里傻看。搞什么鬼！大概半个小时，他们什么都没做！但是，他们确实是在工作。他们正在思考。他们在用大脑思考解决一个非常困难的问题。也许他们甚至会站起来，在办公室里转上一圈。*后，他们坐下来，写下 11 行代码，并将用户故事标记为完成。他们符合你的“屁股时间”标准吗？不符合。他们是否为一个非常困难的问题想出了一个巧妙的解决方案？是的。屁股时间证明不了什么。大脑时间意味着一切。

开发人员其实很贵的。要吸引顶尖人才，你就得支付有竞争力的薪水。他们每一个小时的时间都不便宜。尽管如此，许多公司并没有意识到开发人员这一个小时的时间具有极高的价值，舍不得为团队提供硬件。还是算了吧，电脑很贵的！额外的内存会让硬件预算超标的！好吧，可能是会超出预算，但那是因为你的预算有问题！现在我们来算一笔账：假设你每年付给每名开发人员 10 万美元，或者每小时大约 50 美元。假设他们每天花一个小时等待编译器完成工作。然后，假设你可以为开发人员的机器添加一些内存和更快的处理器，将等待编译的时间减少到每天 45 分钟。那么一名开发人员每天就能节省 15 分钟。以一年 200 天计算，也就是总计 50 个小时。按每小时 50 美元计算，每名开发人员每年可节省 2500 美元。如果速度更快的机器的增量成本是 500 美元，结果如何呢？我们来算一下。如果你有 20 个开发人员，那么用更快的机器反而会为你节省 4 万美元的投资。口算应该就能算得出来。这只是为了减少编译时间的等待。另外，做其他事情的速度也都会更快。如果你的预算不允许更快的机器，那么就需要调整你的预算。

就这一主题我曾写过一篇文章。可以这么说，试图以一种客观的方式衡量开发人员的生产力是徒劳的，根本就不应该这样做。有一些方法可以从主观上度量生产力，但这些方法需要经验和良好的判断。这些能力都很难得到，一旦拥有它们，就能为你带来非常宝贵的价值。

在我看来，只有一本书能教你如何管理软件开发人员：那就是由 Tom DeMarco 和 Timothy Lister 一起编写的《人件》(一定要选择第三版……)。这本书非常**，见解深刻，一针见血，条理清晰，毫无保留。这本书里面充满了管理软件项目和软件开发人员的智慧。它是永恒的经典之作。快快找来读一读吧！

这一点真的让人很难接受。基本前提是：你的缺陷管理工具中的缺陷已经趋近于零，而人们却仍然可以认为你的软件有缺陷。你的缺陷管理工具中可能有大量的缺陷，而人们却可以认为你的软件像磐石一样坚固。缺陷管理工具中的缺陷数量与软件质量之间没有关系。在此，我并不是说你不应该尝试减少你的缺陷数量，而是恰恰相反。但是*终，你的软件只有在你的客户认为它质量够高的时候才可以说它是高质量的，而你的缺陷数量不一定能说明这一点。很奇怪，是吧？当我们谈到这个话题时，“高”的缺陷数量意味着什么？如果你的代码库有 100,000 行代码，“高”的定义是什么？那么 500 万行代码呢？谁说的？

即使在*好的情况下，让一个软件项目在短跑道上安全着陆也是一个具有挑战性和困难的命题。在这个过程中，再加上一些模棱两可，再加上一些随时可能出错的定时炸弹，成功才是奇迹。诀窍在于接受和理解这些模棱两可，并与之和谐相处，而不是与之对抗。接受这 11 条真理将有助于解决这一问题。