告别失控软件开发团队管理必读

软件开发常常难以管理。新闻中充斥着各种项目计划拖延与预算超支的悲剧故事。虽然在开发过程中引入一些正式的规范状况能得到改善，但没有哪种手段完全解决了问题。投入了这么多时间和资金来加强对软件开发的控制，为何仍然如此难以控制？

在本书中，Mickey W. Mantle和Ron Lichty通过一个简单的观察发现回答了这个困扰已久的问题：首先必须让程序员和软件团队变得可控。也就是说，你需要先理解你的员工——如何招聘、激励他们，并带领他们开发和交付杰出的产品。Mantle和Lichty总结了他们合起来超过70年的软件开发管理经验，并结合其他成功管理者的洞见和智慧，为需要为了成功交付软件来管理员工与团队的你提供了充分的指导。

不论你是软件管理新手还是老手，还是已经有多年经验，都会欣赏本书中丰富的实用知识和实践工具。

这是一本系统阐述面对混乱而容易失控的技术开发团队时，如何管理、建设和强化团队，成功交付开发成果的大作。两位作者Mickey W. Mantle和Ron Lichty以合起来近70年的开发管理经验为基础，通过深刻的观察和分析，找到了软件开发管理的核心问题——人的管理，并围绕如何真正理解程序员、找到合适的程序员、与程序员沟通这几个核心话题，一步步展开，扩展到如何以人为本地进行团队建设、管理和项目管理。

Mickey W. Mantle
从事软件开发工作超过40 年，作为软件和硬件产品创建者、管理者和领导者，先后供职于Evans& Sutherland、Pixar、Br?derbund 和Gracenote 公司。他现在从事移动/ 平板应用开发、写作和咨询工作。
他的经验包括指导全球的研发团队和管理跨学科的团队进行7×24小时的高效工作以交付成功的产品。凭借在印度、俄罗斯、加拿大和日本挑选、创建和管理离岸开发机构的经验，他对使用跨时区、跨地域的不同人员和团队进行软件开发所面临的管理挑战有深刻的见解。

Ron Lichty
从事软件开发工作超过30 年，历任程序设计经理、开发总监、产品与工程副总裁，先后供职于苹果、富士通、Razorfish 和Schwab。他写过4 本书和数百篇文章，为创业公司和其他大小公司提供咨询，解决软件开发的难题，确保运行正常。
他是6 家创业公司的顾问。他曾是硅谷历史悠久的开发者组织SVForum 的董事会成员，目前是新兴技术特别兴趣组的联合主席，创办了它的软件架构特别兴趣组，还担任过东湾创新组软件管理实践特别兴趣组的主席。


译者简介
赵普明，从事软件开发工作近十年，从程序员、项目经理、开发经理到技术总监一步步走过来，对技术团队管理深有感触。带领过多个技术团队，崇尚敏捷、开源、分布式的核心小团队开发，也做过远程开发。译有《像计算机科学家一样思考Python》一书。

黄倩，工学博士，河海大学副研究员，先后毕业于南京大学计算机科学与技术系、中国科学院计算技术研究所，主要从事视频压缩、视频处理等方向的研究工作。参与了AVS、HEVC等国内外视频压缩标准的制订，发表学术论文近20篇。译有《编程珠玑（第2版）》等技术书籍。

张维维，爱书，多年从事软件行业，担任过开发工程师、系统架构师、技术经理、产品经理、创业者等，关注能改善人的生活的技术和思考，并力图有所贡献。

钱昊，毕业于北京大学计算机系，现在北京师范大学第二附属中学工作，从事数学和信息等方面的课程教学。将程序设计作为业余爱好，喜欢摆弄各种电子设备，对语言和翻译领域饶有兴趣。另有独立译著和合译译著各一本。

第1章　程序员为何难以管理　1
1．1　程序员都做什么　3
1．2　成功的程序设计经理为什么难当　6
第2章　理解程序员　8
2．1　程序设计工种　9
2．1．1　客户端程序员　9
2．1．2　服务器程序员　10
2．1．3　数据库程序员　10
2．1．4　Web开发人员及其他脚本编写者　11
2．2　程序员的类型　11
2．2．1　系统工程师/架构师　12
2．2．2　系统程序员　12
2．2．3　应用程序员　13
2．2．4　非真正意义上的程序员　13
2．3　领域知识　14
2．4　程序员的工作要求与能力　14
2．5　工作地点与关系　18
2．5．1　内部雇员　18
2．5．2　远程雇员　19
2．5．3　合同工　19
2．5．4　合同管理团队和外包公司　20
2．6　代系特点　20
2．7　个性特点　22
2．7．1　左脑型的人与右脑型的人　23
2．7．2　夜晚型的人与白天型的人　24
2．7．3　“牧童”与“农民”　25
2．7．4　英雄　25
2．7．5　内向的人　26
2．7．6　愤世嫉俗的人　26
2．7．7　奇葩　27
2．8　小结　27
2．9　工具　27
第3章　寻找并招聘优秀的程序员　28
3．1　确定要招聘哪种程序员　30
3．2　编写职位描述　32
3．3　推销职位　35
3．4　招聘全职雇员　37
3．4．1　持续不断地招聘　37
3．4．2　招聘预算　38
3．4．3　招聘案例分析　40
3．4．4　雇员推荐　41
3．4．5　高效的招聘　43
3．4．6　招聘秘诀　43
3．5　招聘合同工　45
3．6　审查简历　46
3．7　缩小范围　48
3．8　准备面试　49
3．9　面试　54
3．10　做出雇用一个程序员的决定　59
3．11　给程序员发合适的录取通知　62
3．12　跟进直到程序员答应　67
3．13　小结　68
3．14　工具　68
第4章　帮助新员工顺利入职　69
4．1　引导员工尽早入职　69
4．2　为新员工的到来做准备　71
4．3　介绍　76
4．4　确保成功　77
4．5　最初的预期　78
4．6　小结　81
4．7　工具　81
第5章　成为高效的程序设计经理：向下管理　82
5．1　赢得技术尊重　82
5．2　招聘杰出的程序员　87
5．3　强化现有的团队　87
5．4　管理不同类型的程序员　87
5．5　引导　92
5．6　保护　92
5．7　评判和改进绩效　94
5．7．1　设立目标　94
5．7．2　绩效审查　97
5．7．3　知道何时削减损失　101
5．8　组织思维　102
5．8．1　人员配置　102
5．8．2　组织　107
5．8．3　对功能失调的组织进行故障诊断　115
5．9　交付成果和庆祝胜利　116
5．10　小结　117
5．11　工具　117

经验法则与至理名言　118
管理中面临的挑战　121
人员管理　141
管理团队，顺利交付　164

第6章　成为高效的程序设计经理：向上管理、对外管理及自我管理　183
6．1　向上管理　183
6．1．1　了解你的上司　184
6．1．2　准备好沟通材料　185
6．1．3　了解你老板的老板　186
6．1．4　时机　187
6．1．5　成为模范员工　188
6．1．6　概要　188
6．2　向外管理　189
6．2．1　与你部门内的人合作　189
6．2．2　了解其他部门　189
6．2．3　利用重要的支持功能部门　191
6．2．4　管理跨公司关系　196
6．2．5　概要　201
6．3　自我管理　202
6．3．1　个人风格　202
6．3．2　时间和优先级管理　205
6．3．3　沟通管理　207
6．3．4　管理实践　209
6．3．5　跟踪管理　213
6．3．6　寻找导师　215
6．3．7　概要　215
6．4　小结　216
6．5　工具　216
第7章　激励程序员　217
7．1　激励理论　217
7．1．1　马斯洛的需求层次理论　218
7．1．2　麦格雷戈的X-Y理论　219
7．1．3　赫茨伯格的激励因素和保健因素理论　220
7．2　适用于程序员的激励因素　222
7．3　理论付诸实践　226
7．4　基本因素——（缺乏时）不满的原因　227
7．4．1　作为上司被尊重　227
7．4．2　有趣　231
7．4．3　学习与成长　232
7．4．4　良好的工作条件　233
7．4．5　合理的公司政策和管理　237
7．4．6　合乎职业道德的管理　240
7．5　关键激励因素　244
7．5．1　改变世界　244
7．5．2　学习与成长　245
7．5．3　工具和技术　247
7．5．4　认可与称赞　247
7．5．5　和员工快乐相处　249
7．5．6　利益　249
7．6　个人承诺　251
7．7　技术攻守　253
7．8　了解你的程序员的动力——从头开始　254
7．9　小结　255
7．10　工具　255
第8章　建立成功的开发文化　256
8．1　定义“成功”　257
8．2　程序设计文化　257
8．3　公司文化　258
8．3．1　利用公司文化的复杂度　259
8．3．2　规避公司的负面文化　259
8．3．3　技术在你的公司中扮演什么样的角色　260
8．3．4　什么力量在推动你的公司　262
8．4　成功的程序设计文化的特征　263
8．4．1　互相尊重　264
8．4．2　创新　265
8．4．3　标准　266
8．4．4　交付　267
8．4．5　沟通　267
8．4．6　虚拟团队间的沟通　269
8．4．7　公平　271
8．4．8　授权　271
8．4．9　职业精神　272
8．4．10　拒绝傻瓜和笨蛋　273
8．4．11　卓越　274
8．4．12　程序设计上的卓越　274
8．4．13　团队精神和协作　275
8．4．14　激情　275
8．4．15　关注客户：“最重要的是客户体验，笨蛋！”　275
8．4．16　学习　277
8．4．17　环境　278
8．5　小结　279
8．6　工具　279
第9章　管理成功的软件交付　280
9．1　定义项目　281
9．1．1　确保需求和假设都足够清晰　282
9．1．2　把需求限制在“什么”上，而不是“如何”　284
9．1．3　力求取悦客户　285
9．1．4　迅速估计工作的规模　286
9．1．5　识别无法商榷的日期　287
9．1．6　激励团队　288
9．2　规划工作　289
9．2．1　将项目拆分为功能点，并按优先级排序　290
9．2．2　将功能点拆分为任务和子任务　291
9．2．3　发动团队进行自底向上的估计　292
9．2．4　将任务估计集成为项目估计　293
9．2．5　寻找估计中的不足　294
9．2．6　对风险达成共识，而不只是时间表　295
9．2．7　为单元测试与项目测试分配足够的时间　297
9．2．8　每一次估计都是独立的挑战　297
9．2．9　确定项目的节奏　298
9．3　展开计划　298
9．3．1　参与项目启动　299
9．3．2　定义“完成”　299
9．3．3　定义“成功”　300
9．3．4　建立项目工作手册　301
9．4　执行工作　304
9．4．1　设计工作　304
9．4．2　进行设计复审　307
9．4．3　完成项目原型来传达设计　307
9．4．4　设立共同认可的里程碑　308
9．4．5　确保设立常规代码检入会议　309
9．4．6　积极驱动开发　310
9．5　终盘结束期　316
9．5．1　不再增加新功能　316
9．5．2　运行产品　317
9．5．3　准备好宣布成功以及开启更新版本的工作　317
9．5．4　知道何时减损　319
9．5．5　OEM或国际版　320
9．6　交付软件　321
9．6．1　庆祝　321
9．6．2　反思　322
9．6．3　分享　325
9．6．4　重构　325
9．6．5　小版本升级　326
9．7　小结　326
9．8　工具　326
工具　327