标题模仿了一下狄更斯的《双城记》——有一个最好的团队，有一个最糟的团队。我同时是两个团队的一员。两个规模类似的团队，在大致相同的情况下，用一年左右的时间为一个细分的利基（niche）市场开发一种新产品。这两款产品都有适度的目标。一个软件开发团队几乎超过了所有期望，而另一个则几乎在所有的方面都失败了。这里的问题是，哪个团队获得了成功而哪一个失败了？为什么？一个团队显然是为成功而建立的。7名程序员个个都经过很好的培训并且经验丰富，其中三个是名校计算机科学专业的毕业生。他们被看做工程部门的精英，为了打造一种令人兴奋的新产品把他们汇集在了一起。团队中的多数人曾经多年在一起工作，一些还是生活中的朋友，团队在工作之外还经常一起做事。该公司是美国软件开发的沃土之一，拥有优秀的设计资源、测试工程师以及非常好的工作环境，程序员几乎能得到所需的一切。这个产品的初始发布版的时间表合理而有弹性。另一个团队鱼龙混杂，更多的是基于现状而非计划凑到了一起。6个程序员都有良好的经验，其中之一是名校计算机科学专业的毕业生。其他人的专业背景虽然不算引人注意，但也很坚实。他们从未一起工作过，个性也有很大的不同。他们过去并不熟悉，在一起甚至还感到不自在，他们之所以聚在一起工作只是因为经理的要求。和第一个团队一样，然而，该公司是美国软件开发的沃土之一，程序员几乎能得到所需的一切。该产品的时间表也很合理。现在或许你可能已经猜到，第一个显然是为成功而打造的团队失败了，而第二个团队获得了巨大的成功。是的，确实如此，第二个团队成功了，而第一个团队失败了。成功的团队早于计划的时间表交付，而且其产品获得了多个奖项，尽管市场有限，还超过了采用目标，几乎没有什么技术问题。由于公司的管理者从前对该团队本来就没有什么期待，反而在他们的眼中放大了这种成功。失败的团队从来没有交付真正的产品，仅仅交付了一个原型，即便是这样，项目也花费了原定的交付时间的两倍。（因为团队在中途决定重新设计内部架构。）尽管市场大肆宣传，而原型是如此之差，问题是如此之多，以至于取消了项目进一步的工作。考虑到对于这个团队有如此高的期望，我们可以说这个失败更惨。作为两支团队的成员，我也可以说我更怀念在失败的团队中工作的时光。每个人都很友善、愉快而且非常聪明。我每天期待着与他们工作，而且我已经与团队的许多成员保持了联系。与另一个团队的工作不像这样愉快。因为我们是如此不同，我们的工作彼此独立，而且几乎没有什么互动，几乎没什么刺激。工作场所的气氛有些紧张，几个团队成员都不怎么对视。他们的政治派别对立，有时候会带到工作中来，而且他们的哲学差异扩展到了软件设计。出于某些原因，我喜欢的团队从未凝聚在一起，而且我们都对于团队的结果非常失望。大家都不认为项目应该继续，虽然如果做得好的话，这个项目是个不错的想法，而且也应该能够产出一个好的产品。相反，尽管不太愉快的团队有明显的差异，但凝聚起来而且产出了软件，而不只是传说（现在它已经不再流传了），彼时团队做得很好，并且我至今仍然为此感到骄傲。那么，为什么应该成功的团队失败了，而被怀疑的团队成功了呢？这两个项目都是很多年前的，但根据记忆，我重建了关于团队和程序员的一系列关键数据。（特别提醒——这是通过重建获得的。）数据显示在表3-1和表3-2中。第一个（失败的）项目历时10个月，第二个项目历时13个月，所以当查看数据时要考虑该因素。由于只有一个产品事实上发布了，因此我在这里关注于发布前的程序员技能数据而不是发布后的用户采用、产品bug、支持问题或者竞争排名的数据。
两个团队的数据比较让我明白了三件事。其一是，对于成功的团队，复杂的任务集中在少量的程序员手里。其他的程序员承担了数量较多但复杂度不高的任务。对于失败的团队，差不多每个人的工作负载类似，而且平均复杂度较高。我注意到的第二件事是，对于成功的团队，团队成员很多都工作在多个产品领域。而对于失败的团队，几乎每个人工作在较少的领域。第三件事是成功的团队的多个程序员都有较多加分译注1，而失败的团队则少得多，也就是创新和主动要少很多——在本章的前面称为“惊喜”。从这里我们可以明白什么道理？我有个关于两支团队之间的差异的理论来解释为什么一个成功一个失败，而且我认为数据同我的理论是一致的。我相信，第一个失败的团队，太舒服、太和睦，也过于自信。每个人都希望做有趣的、复杂的工作，每个人都希望驾驭他人。因而，更无聊、更琐碎的任务，虽然对完成产品有真正的帮助，却从来没有真正地完成。而且，复杂性四处散布，使得设计的内聚性和整合为一个真正的产品更加困难。由于程序员的沟通不畅，他们的原来的工作并没有得到协调，这种复杂度的平衡分布实际上是项目中期系统不得不重新设计的主要原因。最后，因为这支团队如此舒适和自信，所以我相信他们变得有些自满，这导致了很少出现主动和创新。尽管每个人都在努力，但并没有令人吃惊、令人兴奋的或新的东西出现。另一方面，第二个成功的团队得益于一个事实，即几个程序员负责中心设计和更复杂的任务，而较小的任务由团队的其他人负责。这导致了每个人几乎都跨产品领域工作，而这有助于产生一个更加内聚的设计。因为团队不是特别和睦，所以在承担更有趣的或者让他人承担不那么出彩的任务时，并没有人太担心伤害别人的感情。因为每个人的地位并不那么牢靠，而且知道他们正在遭受质疑，所以他们寻求打动和超出预期的途径，从而促使了更多的主动性和创新。如果我是对的，那么从这个单一案例研究得到的经验教训是，如果这样，则软件开发团队更容易取得成功：
将更高复杂度的任务集中于少量的程序员；一定数量的程序员跨多个产品领域工作；程序员感到挑战并且希望证明自己。当然，你有得出自己的结论并形成自己的理论的自由——这是乐趣的一部分。拥有数据和度量可以让你分析结果并形成理论，然后你就可以随着时间的推移验证这些理论。
相关资源：七夕情人节表白HTML源码(两款)