第一章 项目管理失当

    该对我6月份的那个栏目（“开发时间表、飞猪和其他幻想”）的评论做出一些回应了。其实，大部分评论都是恭维之词，这里就不再赘述了，因为没有必要再次证明我有多么正确。我这里要做的是，回应一下那些对那个栏目还在无知中徘徊但又非常热情的读者朋友们。

    作者注：这是我仅有的一个“邮包”栏目，收集了我对一些读者来信的回复。我还在持续不断地收到读者对我的栏目的大量“反馈”，但一旦一个栏目很受欢迎，很多新的话题便会涌现出来；讨论那些新话题的价值要远远超过对一个老话题邮件的回复。不管怎么样，当我回顾这个早期的栏目时，我意识到，可能Wright先生应该再次清空他的邮包了。

    软件工程绝对是含糊的

    我对关于不能也不应该对一个功能的开发做时间安排的论断表示怀疑。文中精确地论述了“编码”活动。遗憾的是，这是初中生干的事情——拼凑一个VB程序来解密信息、相互通信。我们可是软件工程师啊，不是电脑苦工。

    ——一个充满怀疑的无知者

    我经常听到这种说法，但请就此打住。银行经理并不管理银行，软件工程师也不在软件上做工程。他们开发软件，定制软件，通常事无巨细、从头至尾参与其中，并不需要了解操作范围、公差、故障率、压力条件等度量标准。的确，我们的系统有这些标准，但这些标准不是为软件编码准备的。

    我曾到一个工程学校进修过。我的朋友当中也有很多是电力、基建、航空、机械等方面的工程师。这些工程师做的项目，其构造模块和结构流程都经过了很好的定义和提炼，而且都是可预测的。虽然有时候为了达到客户的要求需要一个合适的设计，但只要用一种新颖的方法把各个模块组合在一起就很有创造性了，就算是最标新立异的建筑也会符合一定的公差要求，并且具有严格的可控质量和功能。

    但对软件开发来说，情况就不一样了，尽管很多人竭力想让这两者达成一致。软件的各个构造模块太底层了，变数太多。它们之间的交互影响太难预料了。像Windows、Office、Visual Studio及MSN等大型软件系统的复杂度，已经远远超过了工程的正常范围，以致哪怕只在这些系统中做微小的功能改动，也无法粗略估计出这些改动所引起的“平均失效时间”。

    因此无论好坏，还是抛开痴心妄想和崇高理想，回到现实中来吧！我们必须承认，我们是开发者，而不是工程师。我们不能奢望轻易得到传统的工程领域积累了成百上千年的经验才做到的“可预测性”。这无异于我们奢望：不用跟电脑说什么，电脑就能按照我们心里的想法去做事。我们还办不到！

    作者注：在我写下这个栏目6年后的今天，微软已经对很多软件进行了“平均失效时间”的评估。除此之外，把编程当做工程看待的各种方法也逐渐出现了。这个我会在第5章的“软件发展之路——从雕虫小技到系统工程”栏目中再次介绍。纵然如此，我仍然认为本栏目很好地见证了软件开发作为一个专业领域，它已经走过了幼年，但跟它早已长大成人的传统工程兄弟相比，他还只是个十几岁的小朋友。

    相信一半你看到的，别信你听到的

    如果我在某个功能或者一段代码上依赖于另外一个团队或产品组，我肯定不想听到像“你要的东西应该可以在这个里程碑期间内完成”这样的说法。我需要一个很具体的交付日期。我要有具体细节。

    ——一个需要日期的人

    我想写几个关于依赖关系和组件团队的栏目，也许将来会吧，但眼下我只想讨论依赖方的开发时间表。首先，假设你的依赖方确实有一份开发时间表，你会相信它吗？你也许会说：“当然要信，我有其他选择吗？”建议在你的胃病恶化之前赶紧吃一点PepcidTM（一种胃酸抑制剂）。不光只是开发时间表，不要相信依赖方所说的任何事情。如果他们坐在隔壁房间，他们告诉你外面正在下雨，你首先要做的是到自己的窗口去看一下。

    但我并不是说你不能跟依赖方合作。相反，你应当与他们很好地合作，因为依赖方可能为你的团队、产品和客户带来大量的经验和意外的收获。我只是告诫你要高度警惕当前正在发生的事情。要向他们提出定期多次交付的要求，并对交付的东西进行自动化测试。获取他们对RAID进行读和写的RDQ，观察它们的数量以及存在问题的地方。派你的项目经理去参加他们的分诊会议。加入他们的邮件列表。

    作者注：查一下本书最后的“术语表”，以便理解这些用于Bug跟踪的词汇。

    基本上，你需要像鹰一样盯着依赖方。他们是你的团队和产品的一个扩充。你跟他们接触、沟通得越多，你在规避其短处以及促进其改变方面的能力就越强。至于他们承诺的功能什么时候能够完成，你必须依赖你在如下3个方面上的影响力：提高优先级，沟通渠道，独立测试（为了知道他们的功能是否真正可用了）。