技术项目的失败，屡见不鲜，不论你运营的是一个持续跟进一些项目的软件公司，还是一个需要顾问来为你提供系统集成的非技术公司，你都有可能遭遇这个问题。一个项目延期数年，超支数百万，已经不是新鲜事了。进度延期、预算疯涨、直至最后完全失败，这在软件世界非常普遍。
例如，在2003年，我飞去洛杉矶出席微软为软件开发者举办的其中一个会议。活动中，微软发表了激动人心的消息：下一个版本的windows将会带 来一些革命性的新功能。回顾我的笔记，其中有一个新功能叫做WinFS。具体细节不讲，简单来说，WinFS建议将操作系统的文件系统功能(文件和文件夹 的位置信息)和数据库功能(个人对文件的描述信息)合而为一，放进一个又大又邪恶的“文件数据库混合体”。
这是一个挺有野心的动作。从技术上来说，WinFS约等于重新安排一个国家的交通系统，以适应会飞的汽车。是的，这样会使航空公司停业。同样，所有车库也要变宽来适应带翼的车子。但先别想太远，还是让这功能在一年或最多两年内面世再说吧。
三年过去了。一个叫Quentin Clark的微软经理在博客里说道，WinFS根本不能准时面世，并且它阻碍了微软推出其最新的操作系统。因此这个功能要延期，或者放到以后版本的数据库 上，这意味着没有了“将文件系统与数据库系统合而为一”这唯一的亮点。有鉴于此，你怎么知道你某个技术项目哪一天会注定成为另一个WinFS?这里我有五 步指引来确证一个软件的失败：
错误一：采用平庸的开发团队
软件设计是有难度的，而且不幸的是，很多自称程序员的人确实不能胜任软件设计。尽管这是项目失败的首要原因，你也不曾从官方的失败报告中得知。在所 有的行业，软件业，物流业，或者客服业，人们对同事的无能都太过宽容。你从来都不会听到有人说“我们团队没有足够的智慧来完成这件事”。为什么要这样伤人 的心呢?显而易见的，如果这队分得了任务的人员并不擅长这份工作，他们的工作会日复一日，日复一日……等等……但软件却没有做出来。你也不用太担心HR会 阻挠你招聘一班废物。在大多数的案例里，我向你保证，HR对此毫无建树。
错误二：按周来定目标
假设你想改造你的厨房。你请来的师傅已经搞过很多厨房，而且不作详细蓝图就能估算出这项工作的成本。但软件开发者是在制造前所未有的东西。如果前所 已有，他卖张拷贝的光盘给你就行了。因此，粗略的估计是不可能的。他们需要在写代码之前做好详尽的计划。无论你是客户还是开发经理，你的责任就是确保开发 人员带着详尽计划来开展工作。当你向开发人员询问计划时，他们大多数人可能只会给你一份把进度按周来划分的时间表。这看似非常合理，但其实不然。如果你让 软件团队提交一份大粒度的时间表(大是指需要两天以上的工作)，那么你可以认定他们没有考虑到所有需要实现的细节，而这些细节将会积累，导致延期。
错误三：为截止时间而谈判
还有什么比按周划分软件项目更糟糕?就是要求团队承诺大大地提早完成工作。根据我的经验，大多数开发者都会乐观地接受你的暗示并参与讨价还价。然后你会得到一份友好的协定时间表，但却无法按时执行。
试想以下情况：海象妈妈会在怀孕15到16个月后，生出小海象。你可能会叫海象妈妈保证在15个月内做到，而她也说没问题。或者你说，“15个月? 疯了吧?我们要在8个月内生出”。当然，这样谈判是无法促进事成的，而且即使得到一份8个月的进度表，我还是告诉你一个小秘密：这是不可能实现的。你可以 取得
一份11个月的时间表，但你还是要等15个月，因为小海象就是要15个月才能出产，有时甚至16个月。
错误四：均分任务
这里有一个破坏项目的好方法。列出人们需要做的所有工作，然后给重新均分给各人。如果Mary有太多的工作，就分一些给John。这听起来完全合 理，使得你不会被质疑。但我向你保证，时间一长肯定会出现问题。那是因为当一个开发者去替代另一个时，我们有理由假设效率降为十分之一。John将会花费 无数小时去搞清楚Mary其实已经熟悉的那部分代码。而且John改bug也不及Mary快，因为Mary才了解所有的陷阱在哪里。