前言
告别失控：软件开发团队管理必读
软件开发常常被认为是难以管理的。进度安排和费用预算完全不靠谱的软件项目比比皆是。规范化的软件开发实践对这一状况有所改善，但也未能真正解决问题。我们软件开发行业已经积累了超过60年的技术经验，并已经投入了大量的时间，以及美元/日元/卢比/欧元来尝试把管理规范化，但为什么软件开发至今仍然如此难以管理呢？
本书用一个简单的观察结果来回答这个长期存在的问题：管理者首先必须学会管理程序员和软件团队的技巧。也就是说，必须学会了解员工—如何聘用他们，激励他们，进而领导他们开发并交付杰出的产品。本书基于我们自身的经验，以及我们所认识的几乎所有类型的软件行业的优秀管理者的经验，来为读者讲述如何开展软件开发的管理工作。如果把我们两位对各类软件程序和项目的开发与交付方面的经验加起来，都有70多年了，其中有超过55年的时间是在管理交付软件程序和软件项目的程序员和团队。希望本书能够帮助读者避免我们曾经犯过的许多错误，也希望我们学到的思想和技能能够帮助读者获得成功。
在我们职业生涯的初期，还都是程序员的时候，我们俩就都读过Fred Brooks写于1975年的《人月神话》（The Mythical Man-Month）一书。该书面世后很快就被程序员们奉为经典，其真知灼见直到今天仍有着重大意义，被认为是软件管理艺术方面的一部权威著作。与其他许多读者一样，我们最难忘的部分是Brooks的那些只有一行的至理名言，例如：“向进度落后的项目中增加人手，只会使进度更加落后。”在管理软件项目时，我们无数次地引用过这句名言。我们希望能够找到其他类似的令人难忘的经验法则，这也是写作本书的灵感和动力来源。
在我们俩成为富有经验的管理者后，作为朋友，我们开始定期碰面，讨论各自正在从事的工作以及软件开发中遇到的挑战性问题。我们发现彼此都能从对方那里获得帮助，时不时还能共同总结出一条至理名言或经验法则。我们把这些至理名言和经验法则带回到工作中，整合到管理方法中，并与团队分享。我们从阅读过的书籍和访问过的网站上收集法则和名言，但从未发现一组专门用于管理程序员和软件开发团队的法则或名言。出于对这组法则或名言的需要，我们最终决定撰写这本书。
当我们开始写作并与经理、总监、首席技术官们交流时，我们的眼界更加开阔了。显然，我们可以从自身的行业经验出发进行撰写，而不只是提供我们所收集的那些经验法则。我们还可以分享自己开发的工具，以及在创业公司和各种规模的组织中工作所获得的见解。
当然，有些领域是我们在职业生涯中没有触及的，如大规模政府订单和国防系统。但我们的经验适用于当前从事软件开发的大多数公司，包括那些致力于前沿创新的公司。在后面所说的这类公司中，管理人员往往比较年轻，普遍缺乏（或很少有时间接受）正规的管理培训和组织上的支持。遗憾的是，现在太多的管理者都是如此，都只能在工作中边做边学。
我们希望写一本能够为程序设计经理提供指导的书——一本富含见解、故事和指导的书，这些见解、故事和指导都是多年来我们在为获取成功而走过的艰辛历程中得来的。
我们觉得还可以在书中分享多年来自己开发过的一些工具，使管理变得更容易。这些工具包括职位描述、排名电子表格、项目工作手册、团队技术详单、程序员首日日程模板和招聘检查清单等。如果管理者所在的组织很不成熟，不能为其手下的员工提供所需的工具（在快速发展的软件开发领域中这种现象很普遍），那么这些工具可以帮助管理者节省下从头开始做的时间。我们真希望在当年刚开始从事管理工作时就能拥有这些工具。
我们曾经思考过是否有必要把这些与软件开发相关的内容写成一本书。毫无疑问，随着大量与工程软件、管理过程和管理项目有关的书籍、文章和网站的出现，一些杰出的工程管理人员一定已经分享了他们的秘诀。然而我们发现，与我们职业生涯初期的那个年代相比，专注于管理程序员和软件开发团队的实例并没有增加多少。
对于新上任的开发经理而言，管理、领导、指点和评价程序员团队的工作没有一般性的方法，很多时候，他自己加入该团队也才几天而已。现成的管理方法是不存在的。与项目经理不同（项目经理需要在自己规划的职业道路上花大量的时间学习以获取证书），开发经理一般都是优秀编码员出身，有一点点人事关系处理能力。
在我们所能找到的书籍中，没有一本像本书一样包含了各类幕后故事和趣闻。这些故事和趣闻是直接围绕着如何处理管理者面对的各种具体情况而展开叙述的。
目录
第1章 程序员为何难以管理
**1.1 程序员都做什么
1.2 成功的程序设计经理为什么难当**
第2章 理解程序员
**2.1 程序设计工种
2.2 程序员的类型
2.3 领域知识
2.4 程序员的工作要求与能
2.5 工作地点与关系
2.6 代系特点
2.7 个性特点
2.8 小结
2.9 工具**
