软件管理沉思录

出版者:人民邮电出版社

作者:[美] Watts S. Humphrey

页数:217

译者:黄 征

出版时间:2012-6

价格:35.00元

装帧:平装

isbn号码:9787115269393

具体描述

本书为软件工程领域权威人士之作，书中首先深入讲解了计划类型和计划过程，接着分析了项目团队建设和激励，然后描写了如何与经理共事，如何说服他们采用最佳实践，最后探讨了个人职责、承诺和过程。

本书适合软件项目管理人员阅读。

作者简介

作者介绍：

Watts S. Humphrey（沃茨•汉弗莱）

ACM会士，IEEE终身会士，卡内基—梅隆大学软件工程研究所（SEI）的资深研究员，SEI软件过程研究奠基人，SEI软件过程成熟度模型发明人。2005年被授予由美国总统颁发的美国国家技术奖。他曾在IBM工作了长达27年，担任技术研发部门副总裁，掌管IBM所有软件产品的研发工作。他还是PSP和TSP先驱。除本书外，汉弗莱还著有包括《TSP：领导开发团队》、《TSP：培训开发团队》在内的12本书，这些书在软件管理和过程改进领域非常具有影响力。

William R. Thomas（威廉•托马斯）

SEI技术交流团队主管，拥有近30年的传播、公关以及新闻从业经历，并负责过俄亥俄州扬斯敦和得克萨斯州加尔维斯敦多家报纸的商业和技术版面。

目录信息

目　 　 录
第一部分　 管理你的项目
第1章　 交付高质量的产品　 　 2
1.1　 软件质量的挑战　 　 2
1.2　 什么是软件质量　 　 5
1.3　 缺陷并非“漏洞”　 　 8
1.4　 质量是永无终点的旅程　 　 9
1.5　 以明确目标为起点　 　 12
资料来源　 　 14
第2章　 为高质量项目制订计划　 　 15
2.1　 最难以制订计划的时候，也是最需要计划的时候　 　 16
2.2　 作两类计划：阶段计划和产品计划　 　 18
2.3　 为每一项主要的工作制订产品计划　 　 21
2.4　 与你的管理者共同审查详细的计划　 　 23
2.5　 每个人都会因不恰当的计划蒙受损失　 　 25
2.6　 计划必须满足五条基本要求　 　 27
2.7　 若你不能使计划准确无误，那就常作计划　 　 30
2.8　 计划必须得到维护　 　 31
资料来源　 　 33
第二部分　 管理你的团队
第3章　 高效团队的基本要素　 　 36
3.1　 团队致力于共同的目标　 　 37
3.2　 团队合作会比个人独立工作表现更出色　 　 38
3.3　 团队遇到的七个常见问题　 　 40
3.4　 团队失败的四条原因　 　 42
3.5　 凝胶型团队　 　 47
3.6　 高效团队必备的四个条件　 　 48
3.7　 团队随时间而成长　 　 50
3.8　 团队交流的三要素　 　 52
3.9　 组建－动荡－规范－执行　 　 54
3.10　 群体的最佳类型　 　 57
3.11　 团队采用不同的工作风格　 　 60
3.12　 自主指导型团队的特征　 　 64
资料来源　 　 69
第4章　 做一位高效的团队成员　 　 70
4.1　 优秀的团队成员会做任何需要做的事　 　 71
4.2　 承诺是一项必须要学习的道德规范　 　 72
4.3　 目标就是你想要实现的　 　 74
4.4　 所有的新思想都始自仅有一人的少数派　 　 75
4.5　 团队所有成员都应当奉献他们所知道的一切　 　 76
4.6　 团队创建需要所有成员的主动参与　 　 78
4.7　 优秀的谈判者都有一种有效的策略　 　 81
4.8　 有一位未参与者就会影响所有人的表现　 　 84
4.9　 请求帮助并提供帮助　 　 85
资料来源　 　 87
第5章　 领导和指导你的团队　 　 88
5.1　 领导力决定成败　 　 89
5.2　 三条最重要的激励因素是恐惧、贪婪和承诺　 　 90
5.3　 作出并维护承诺　 　 94
5.4　 用短期目标制造紧迫感　 　 96
5.5　 当选择新团队成员时要让整个团队都参与　 　 97
5.6　 指导的力量　 　 99
5.7　 让所有团队成员都参与的技巧　 　 100
5.8　 在动荡阶段让团队进入工作状态　 　 112
5.9　 构建管理团队　 　 114
5.10　 理性管理的本质　 　 116
资料来源　 　 118
第三部分　 管理你的领导
第6章　 讨论项目并捍卫你的计划　 　 120
6.1　 项目从一开始就陷入麻烦　 　 121
6.2　 让团队聚焦于优先级最高的事　 　 124
6.3　 在作出任何承诺之前都要先制订一个计划　 　 126
6.4　 让管理者与你进行商谈　 　 129
6.5　 少意味着差　 　 132
6.6　 当一个项目注定失败时要做什么　 　 133
6.7　 专断的领导使员工失去动力并且严重影响工作表现　 　 136
6.8　 你的工作环境是专制的吗　 　 140
6.9　 为过程改进给出理由　 　 141
6.10　 为过程改进给出战略性理由　 　 146
6.11　 为过程改进给出战术性理由　 　 153
6.12　 管理者对团队领导者的期望是什么　 　 159
资料来源　 　 161
第四部分　 管理你自己
第7章　 控制你的工作　 　 164
7.1　 一个明确的过程会帮助你提高　 　 165
7.2　 做你自己的管理者，而不要像一个受害者　 　 166
7.3　 如何提高工作质量　 　 167
7.4　 18小时工作周　 　 169
7.5　 在高度紧张的项目中抵制幻觉　 　 173
7.6　 支持人员能够帮助你　 　 175
7.7　 时间管理的逻辑　 　 176
7.8　 负责任是一种主人翁心态　 　 179
7.9　 拖延几乎总是最糟糕的选择　 　 182
7.10　 信守承诺是一种精神状态　 　 184
7.11　 管理承诺，这样你就不会忘记承诺或耗尽时间　 　 187
7.12　 你想在人生中获得些什么　 　 188
7.13　 执著追求卓越　 　 190
资料来源　 　 191
第8章　 学会领导　 　 192
8.1　 你的所作所为会影响你的团队　 　 192
8.2　 领导者要为团队树立榜样　 　 194
8.3　 学会避免领导力低下的一些症状　 　 196
8.4　 领导力必须是赢得的　 　 198
8.5　 努力成为一名变革型领导　 　 200
8.6　 领导者是由环境造就的　 　 202
8.7　 做好中下层领导者　 　 203
资料来源　 　 205
后记　 软件工程师是知识工作的先行者　 　 206
附录　 PSP、TSP和CMMI　 　 212
参考文献　 　 216
· · · · · · (收起)

读后感

作者好像是一位在IBM工作个好几十年的牛人。 虽然其实很多在IBM工作过的同事都觉得IBM不是啥管理高效的公司，但是个人觉得这本书里面讲的很多理论和方法，确实很多工作在一线的manager非常有价值 如何组件你的团队 如何从一个manager成为一个leader。 如何打造All ...

作者好像是一位在IBM工作个好几十年的牛人。 虽然其实很多在IBM工作过的同事都觉得IBM不是啥管理高效的公司，但是个人觉得这本书里面讲的很多理论和方法，确实很多工作在一线的manager非常有价值 如何组件你的团队 如何从一个manager成为一个leader。 如何打造All ...

作者好像是一位在IBM工作个好几十年的牛人。 虽然其实很多在IBM工作过的同事都觉得IBM不是啥管理高效的公司，但是个人觉得这本书里面讲的很多理论和方法，确实很多工作在一线的manager非常有价值 如何组件你的团队 如何从一个manager成为一个leader。 如何打造All ...

作者好像是一位在IBM工作个好几十年的牛人。 虽然其实很多在IBM工作过的同事都觉得IBM不是啥管理高效的公司，但是个人觉得这本书里面讲的很多理论和方法，确实很多工作在一线的manager非常有价值 如何组件你的团队 如何从一个manager成为一个leader。 如何打造All ...

作者好像是一位在IBM工作个好几十年的牛人。 虽然其实很多在IBM工作过的同事都觉得IBM不是啥管理高效的公司，但是个人觉得这本书里面讲的很多理论和方法，确实很多工作在一线的manager非常有价值 如何组件你的团队 如何从一个manager成为一个leader。 如何打造All ...

用户评价

这部作品给我带来了强烈的共鸣，尤其是在探讨那些关于系统架构和技术演进的深层思考上。作者的笔触细腻而富有洞察力，他不仅仅是在描述“如何做”，更是在追问“为何如此”。我印象最深的是其中关于技术债务和架构僵化的论述，那简直就像是把我心中那些模糊不清的疑虑，用清晰的逻辑和生动的比喻一一梳理了出来。他没有陷入那种空泛的技术术语泥潭，而是将抽象的概念与我们日常面对的工程实践紧密结合。阅读过程中，我常常会停下来，反复咀嚼那些关于决策权衡和组织结构对技术路线影响的段落。那种感觉就像是找到了一位经验丰富、又充满哲思的前辈，他用一种近乎“禅思”的方式，引导我重新审视那些我们习以为常的管理范式。这本书的价值不在于提供标准化的SOP，而在于激发我们对现有状态的反思，去质疑那些被奉为圭臬的“最佳实践”，从而寻求更适合自身土壤的解决方案。这种引导式的启发，远比直接的指导更有力量，它让你在合上书本后，依然能在脑海中继续那场深刻的对话。

我发现作者对于复杂系统理论的理解，已经深入到了骨髓，并巧妙地将其融入到了对软件生命周期的观察之中。全书的逻辑铺陈极其严密，如同一个精密的钟表，每一个章节的论点都环环相扣，共同指向一个核心：管理即是控制熵增的过程。书中对于“意外性”和“黑天鹅事件”在软件开发中如何被系统性地放大或抑制的分析，令我醍醐灌顶。他没有回避管理的困境，反而直面那些看似无解的悖论，比如：如何在追求稳定性的同时，保持创新的活力？如何既要快速迭代，又要保证系统的健壮性？作者并未提供简单的答案，而是提供了一套观察问题的全新框架。这种框架论的构建，使得这本书具有极高的耐读性和反复咀嚼的价值。每一次重读，似乎都能从那些看似简单的文字中，挖掘出新的层次和更深远的含义，这绝非一蹴而就的快餐读物所能比拟。

这本书的叙事风格非常独特，它不是一本传统意义上的教科书，更像是一本充满智慧和个人色彩的观察手记。作者的文风时而如清泉般流畅，时而又如同击石般的犀利，尤其是在批判那些僵化的流程和层层叠叠的汇报机制时，那种不加修饰的直率让人拍案叫绝。我特别欣赏他对于“维护成本”这个概念的延展性解读，他将之从单纯的代码层面的理解，提升到了组织文化、人员流动乃至企业战略的高度。这让我意识到，我们过去只看到了冰山一角。书中对于不同规模团队如何处理技术变迁的案例分析，也极为精妙。它们不是那种被过度美化的成功学故事，而是充满了现实的挣扎与妥协。这种真实感，是那些浮于表面的管理类书籍所无法比拟的。读完后，我感觉自己看待技术决策的角度被拓宽了，不再局限于眼前的效率，而是开始审视其长远的影响，这对于任何身处复杂系统中的管理者来说，都是一次重塑认知的洗礼。

这本书给我最深刻的印象是它对“权力的分散与集中”这一主题的探讨，这在技术管理领域往往是一个敏感而又避而不谈的话题。作者以一种近乎历史学家的宏大视角，审视了技术决策权如何在不同的组织阶段发生转移，以及这种转移对最终产品质量和团队士气的影响。他没有停留在表面的工具之争，而是直击权力结构背后的哲学基础。特别是关于“谁拥有最终的‘否决权’”的讨论，描绘出了一个清晰的权力地图，这对于任何试图优化组织流程的领导者来说，都是一份极其宝贵的路线图。全书的论证过程严谨到几乎没有可以被轻易攻击的薄弱点，它建立在一个扎实的工程哲学之上。阅读过程是一次持续的、高强度的智力挑战，它要求读者不仅要有技术背景，更需要有足够的哲学思辨能力来跟上作者的思路，实属难得。

这部作品的行文节奏把握得极好，它能让你在平静的思考中突然被一个深刻的观点猛地击中。作者在描述软件团队的日常运作时，那种对人性的洞察力，几乎是文学性的。他谈论代码评审，谈论知识沉淀，但字里行间透露出的，却是对个体工作状态、职业倦怠以及团队化学反应的深刻理解。这种将技术问题“人文化”的处理方式，极大地增强了阅读的代入感。我尤其喜欢他对“隐性知识”与“显性文档”之间张力的探讨，他敏锐地指出了过度依赖流程文档所带来的“智能的退化”。这迫使我反思我们团队内部的知识传递机制是否已经陷入了一种低效的循环。这本书的语调是克制而权威的，它不煽动情绪，而是用一种近乎冷静的科学家的态度，去解剖那些日常中令人沮丧的管理现象。

看到的第二本SEI的书，感觉TSP是个好东西。但本书的内容全是讲故事，只能看着玩了，想要学干货不能看这本书

看来要加深自己的管理经验，才能有更深的体会。

看到的第二本SEI的书，感觉TSP是个好东西。但本书的内容全是讲故事，只能看着玩了，想要学干货不能看这本书

非常好的一本书，推荐大家读读，非常棒

带着问题去读会有不少收获