下面是这本书的前言部分
你可能从来没有奢望自己成为一名经理。像我所知道的大多数软件开发人员一样，要是能够让你坐在那里安安静静地写代码，你就会感到由衷地高兴。不过，作为一名最优秀的开发人员，在小组老领导Nigel出了那场不幸的包装绳与笔记本电脑事故之后，你晋升为小组的主角似乎显得顺理成章了。 这样一来，现在你有了自己的办公室（而不是与整日待在房间里的暑期打工仔共用一间卧室），并且必须去填写每年两次的业绩评估表（而不是整天两眼盯着CRT乐此不疲）。也就是说，现在不用浪费时间去处理女首席程序员提出的奇怪要求，应付拍肩膀的推销员，以及倾听充满创造力的“用户界面设计人员”（因为Pete之故，他们是作为图形设计人员而录用的）。这些设计人员想凸现有反射光的亮丽的“OK/ Cancel”按钮。我想知道，“反射光”的RGB值是多少？另外，还要应对高级副总裁的空洞提问，他所知道的关于软件的一切知识来源于Delta航班的旅途消遣杂志文章。“我们为什么不用Java，而要用Oracle？我听说它显得更为统一！” 欢迎进入管理世界！猜想到什么了吗？软件项目的管理与程序设计是完全不相干的两码事。假如到现在为止你所做的一切就是写代码，那么你会看到，人类大概比像花园里的杂草一样品种繁多的Intel CPU还要不可预测。 无论怎么说，老领导Nigel从来就不很精于此道。“我不想成为那种将所有时间都花在毫无意义的会议上的经理人员！”他用充满几分自信的口吻说。“我觉得仍然可以将85%的时间用在编写代码上面，在管理方面只花一点点时间就行了。” Nigel真正想说的话是：“我对如何管理这个项目没有任何心血来潮的想法，也不会像我以前全心全意编写代码的时候充满希望，在某种程度上，一切都像自然而然地自动产生一样。”事情当然不会那么顺利发展，要切实解释在那个命该如此的日子里为什么Nigel会被IBM ThinkPad电得跳起来，会有很长的一段路去走。 不管怎么说，Nigel真的恢复得令人吃惊得好。鉴于此，他现在担任一家小公司的CTO。该公司是从难兄难弟WhatTimeIsIt.com起家的，他只用了六个月的时间就从零开始发布了一个全新的系统，他再也不能碰运气了。 软件项目管理不是一门很知名的艺术。没有人有软件项目管理的学位，这方面的书籍也很少。那些在软件项目方面真正做得很成功的稀有人物当中，有许多人在有机会将自己积累的经验传给下一代之前，就很富有并隐退到养鱼场垂钓去了，另外一些人则筋疲力尽，找一份强度不大的工作，如给市内的瘪三补习英语聊以度日。 结果就是，许多软件项目以这样那样的方式，或公开，或无声地失败了，因为项目组当中没有人知道一个成功的软件项目可能是如何去运作的。于是乎，太多的小组永远无法交付他们的产品，或者交付产品的时间显得过长，或者交付的产品没有人愿意使用。不过，最让我生气的部分还是项目组的人不乐观，整日里抱怨这抱怨那。人生如此短促，没有时间去厌恶自己的工作。 几年前，我在自己的网站上提出了“Joel测试”概念，其中列举了运作良好的软件项目组表现出的12个指标。比如说，维护一个跟踪故障信息的数据库，让求职人员当场编写代码等（不要担心，后面我还要就此进行更为详细的说明）。令人惊讶的事情是，如此众多的人通过电子邮件告诉我，他们的项目组在12项测试中只能得两三分。 两三分！ 太异乎寻常了——可以设想一下，几个从来没听说过螺钉是怎么一回事的木匠却试图去做家具，会是怎样一番情景！他们完全要靠钉子来干活，给木头钉钉子居然用舞鞋，因为没有人告诉他们可以用榔头。 软件项目管理需要一套与编写代码完全不同的技能和方法，它们是两个截然不同且毫不相关的领域。写代码与软件项目管理之间的差别大得就像脑外科与烤法国面饼。没有理由希望一位才气横溢的脑外科医生，因时空倒错而到一家法国烤面饼工厂，会精通烤面饼，即便他毕业于哈佛医学院。然而人们还是不可避免地认定，用不着任何调整就可以让一位顶尖编码人员去承担管理性工作。 像前面提到的那位脑外科医生一样，你和Nigel会突然感觉到自己要从事一个全新的工作，管理，需要你与——上帝啊——项目组的人员，而不是编译器进行交流。要是你认为Java编译器故障很多且不可预见，那么等着出现第一个首席女程序员问题好了。管理由人组成的队伍使C++模板看起来显得过于琐碎。 软件项目的成功管理是要有技术的。该项管理艺术目前发展的状况远远超过了钉子与舞鞋的情形。我们已经有榔头、螺丝刀与双面两用锯可用。本书的写作目的在于从各个层面尽我所知向你介绍一些方法，小到项目组负责人制订进度表，大到软件执行总裁提出富有竞争性的战略，都在该书的介绍范围内。 在本书当中，你可以学到： 如何聘用与激励最优秀的员工——软件项目成功当中惟一的最至关重要的因素。 如何评估与调度工作，以及为什么要这样做。 如何设计软件功能，撰写确实有用的规格说明书，而不仅仅是用做维修集体宿舍的“只写不看”的包装纸。 如何避免落入软件开发常见的陷阱，以及当程序员坚持按照“丢弃它而从头开始”的想法行事时，为什么总是错误的原因。 如何组织与激励项目小组，以及为什么程序员需要办公室门窗都紧闭。 即使可以从网上下载足够好用的软件版本，那么什么时候需要自己从零开始去写代码。 为什么软件项目总是在经过开头几个月的快速奔跑之后就似乎裹足不前了。 拥有好的软件策略意味着什么，以及为什么BeOS从第一天起就命中注定了灰色的结局。 其他更多的内容。 书中的内容显得有些主观，我只能如此。为了简洁起见，每句话的开头我都把“在我看来”的短语去掉了，因为实际上书中的每句话都是我的看法。这虽然不完整，但或许是一个很好的开头。 呵，如此说来，你看过我的网站了…… 本书的许多内容最初是以系列文章的形式在我的网站“Joel说软件”（www. joelonsoftware.com）上发表的。那是承载我多年思想的地方。我希望你手中的这本书能够比网站更有“粘结性”，我说粘结性的意思是“你可以在浴缸里阅读而不用担心触电”。 本书分三个主要部分。第一部分是关于开发小范围软件的所有内容：每件事情都应该由自己的团队来完成，以确保软件不会给人们带来危害。第二部分包含关于程序员与开发小组管理方面的文集。第三部分虽然显得有点随意，但是介绍的主要精力放在构筑可行的软件开发业务大战略之上。在这里，你将了解到为什么大件总是赢得现在，为什么Ben & Jerry式公司与Amazon不一样，并且我会试图指出一种情形——存在成套的软件开发模式通常是缺乏胜任工作的员工的一种表现。 虽然在这里说了很多，但还是深入书本开始阅读为好。
如果大家感兴趣，可以到 dearbook 或 china-pub 购买