第一部分 1995
简介　　 2
有关软件的思考　　 3
项目的阶段　　6
开局阶段　　 7
组织　　 7
质保人员是“少数民族”吗　　 8
到底谁负责产品设计　　 8
经验法则1 建立共同前景　　 9
经验法则2 使大家主动投入　　 18
经验法则3 制定多版本的技术计划　　 20
经验法则4 不要认为别人是笨蛋　　 25
死亡行军　　27
经验法则5 搜集情报　　 30
经验法则6 注意团队成员组成的比例　　 32
经验法则7 组建功能小组　　 33
经验法则8 项目经理的重要性　　 41
团队精神　　 42
经验法则9 做权威，而非掌权者　　 44
竞争　　47
人类学分析　　 47
软件竞争　　 49
经验法则10 缺乏竞争对手？未必是好事　　 50
经验法则11 与竞争对手不相上下？进行功能竞赛 　　52
经验法则12 落后于竞争对手？更频繁地推出新版本　　 52
经验法则13 领先于竞争对手？绝不放松　　 55
经验法则14 紧跟潮流　　 55
客户　　 57
简单的购买模型　　59
经验法则15 让客户惊喜　　 60
经验法则16 找到靶心　　 62
经验法则17 与客户建立良好的关系，而不只是生意往来　　 63
经验法则18 加快产品周期　　 65
设计　　67
经验法则19 追求伟大　　 67
经验法则20 确定主题　　 68
经验法则21 将依赖减至最少　　 70
经验法则22 平息客户的抱怨　　 71
经验法则23 软件的可移植性　　 71
经验法则24 在设计阶段考虑时间因素　　 71
开发　　73
经验法则25 拒绝错误指示　　 75
经验法则26 以游戏的心情开发软件　　 76
中期阶段　　　79
经验法则27 像医生一样　　 79
经验法则28 记住软件开发金三角：功能、资源和时间　　 82
经验法则29 不要不懂装懂　　 84
经验法则30 提交中间产品　　 87
经验法则31 小心“闭门造车型”开发人员　　 91
经验法则32 经常、定期构建软件产品　　 94
经验法则33 始终完全了解产品的状态　　 97
掌握进度　　　98
经验法则34 利用零缺陷里程碑　　 99
经验法则35 一个也不能少，才算真的到达零缺陷里程碑　　 100
经验法则36 完成每个里程碑后进行事后总结，但不要指责 　　101
经验法则37 把握里程碑的字面意义与精神　　 101
经验法则38 掌握什么是“正常的” 　　 102
经验法则39 里程碑的合理数目　　 107
经验法则40 每一个小的里程碑都有专属的意义（故事）　　 107
经验法则41 寻找自然出现的里程碑　　 109
经验法则42 虽落后，别趴下　　 112
经验法则43 不要落后多久就把原定日期延后多久　　 122
经验法则44 延误了这个里程碑，一定要按时到达下一个里程碑　　 123
经验法则45 从延误中学习经验教训　　 124
经验法则46 要有全局观　　 124
经验法则47 与时俱进　　 125
推出阶段　　127
推出阶段：启动　　 127
推出阶段：移交　　 129
推出阶段：收尾　　 129
经验法则48 关怀多于要求　　 130
经验法则49 Beta 版不是修改产品的时候　　 131
经验法则50 利用Beta 测试来调整宣传策略　　131
经验法则51 严格执行类选法　　 132
经验法则52 小心保持软件的稳定　　 134
发布阶段　　　135
经验法则53 伟大的软件应该有一个伟大的故事　　 136
经验法则54 建立赢家形象　　 140
结束语　　140
附录：聘用和留住人才　　142
雇用聪明的人　　 142
适才适任　　144
赛马必须奔跑　　 144
好高骛远者需要你的推动　　 145
软件开发领导的一些参考资源　　 150
第二部分 2006
新的经验法则　　 154
经验法则55 做完美的老板　　 154
经验法则56 老板就是你最重要的客户　　 156
一种更好的方式　　 157
在如何看待老板上的转变　　 157
经验法则57 支付木材税和下阿尔法赌注　　 159
阿尔法（或阿尔法能量） 　　 160
The Core System V. 3.0 的元素　　 163
形成共同前景的4 个步骤　　 164
第1 部分：“签到”的元素　　164
第2 部分：决策过程的元素　　 166
第3 部分：校正的元素　　 168
第4 部分：共同前景的元素　　 169
The Core Protocols V. 3.0　　 173
核心承诺　　　173
核心准则　　　174
放弃/取消放弃　　 174
签到　　 174
离开　　175
求助　　176
准则检查　　177
目的检查　　177
决策过程　　178
解决　　180
完美行动　　180
个人校正　　181
调查　　182