![名家经典系列：人件（原书第3版） [Peopleware: Productive Projects and Teams]](https://pic.qciss.net/11520202/53e875a8Ne26c11e7.jpg)
具体描述
编辑推荐
公认对软件行业影响、具价值的著作之一，历时15年全面更新；
与《人月神话》共同被誉为软件管理图书领域最为璀璨的“双子星”；
近30年全球畅销不衰；
ThoughtWorks中国区优秀咨询和开发团队精心翻译。
海报：
内容简介
《名家经典系列：人件（原书第3版）》是软件管理领域的传奇经典，被誉为“对美国软件业影响的一本书”。全书从管理人力资源、创建健康的办公环境、雇用并留用正确的人、高效团队形成、改造企业文化和快乐工作等多个角度阐释了如何思考和管理软件开发的问题——人（而不是技术），以得到高效的项目和团队。
作者在第3版中添加了6章内容，并对先前的内容做了调整，使其更能应对当今软件的开发环境和挑战。例如，第3版讨论了一些领导力上的病理症状，这些是先前版本中没有作为病理来归纳的；书中还讲述了会议文化的演进，以及如何管理新旧成员水火不容的混合团队，讨论了为何一些日常使用的工具会成为团队前进的阻力而非动力。任何需要管理软件项目或软件组织的人员都能从本书中寻找到有价值的建议。
作者简介
TomDeMarcoAtlanticSystemsGuild公司首席咨询师，结构化分析和设计的创始人之一。他共出版了9本书，如《最后期限》、《与熊共舞：软件项目风险管理》和《项目百态：深入理解软件项目行为模式》等。目前，他在缅因大学教授伦理学。
TimothyListerAtlanticSystemsGuild公司首席咨询师，除本书外，还参与撰写了《与熊共舞：软件项目风险管理》和《项目百态：深入理解软件项目行为模式》。他是IEEE、ACM和CutterITTrends的会员，并且是Cutter的研究员。
译者简介：
肖然，ThoughtWorks中国区咨询负责人。在过去的5年时间里，先后为国内外10多家大中型IT企业提供了敏捷开发相关的流程、实践及技术架构的咨询及辅导。由于敏捷开发对内建质量保障体系的强调及对全员参与测试的要求，在为各个研发组织设计、落地组织及技术架构的过程中，肖然积累了很多在不同业务背景及研发团队中实施敏捷质量保障体系的经验。作为思特沃克中国区管理团队一员，肖然也在实践并探索如何建立更加有效及创新的IT组织。
张逸，软件开发生涯经历了从程序员、项目经理、测试经理、开发部长、技术总监到架构师的一个循环，现在幸福地回到程序员的起点。现为ThoughtWorks咨询师、程序员。管理上，正大力推进敏捷与精益在软件开发过程中的实践与转型；技术上，热衷于在传统设计领域中引入函数式设计思想。著译包括《软件设计精要与模式》、《WCF编程》、《Java设计模式》和《恰如其分的软件架构》。
滕云，一个半路出家的程序员；一个军事武器狂热分子；一个并不合格的古典音乐爱好者；一个拙劣的填词。目前主要从事金融和保险领域的企业级软件开发，主要感兴趣的技术领域包括JavaEE、Linux、领域驱动设计和持续交付等。他的译著有《实现领域驱动设计》。
目录
译者序
前言
作者简介
译者简介
第一部分管理人力资源
此时此刻，一个项目正在走向失败
游戏的名称
高科技的幻觉
干酪汉堡，做一个，卖一个
错误在所难免
管理：傻瓜定义
人力商店
稳定的项目濒临死亡
我们只是做事，没时间考虑工作自身
维也纳在等你
西班牙理论
来自家里的一句话
不存在加班的谎言
工作狂
工作效率：赢得战斗，输掉战争
反思
质量——如果时间允许
飞离卓越的航班
质量是免费的，但是……
否决的力量
再谈帕金森定律
帕金森定律和牛顿定律
如果经历了我们的见闻，你就不会这样说了
来自新南威尔士大学的数据
帕金森主题的变异
苦杏素
在睡梦中减肥
七宗罪
这就是管理
第二部分办公环境
家具警察
警察思路
统一的塑料地下室
“朝九晚五在这里啥也完成不了。”
弃权政策
编码战争游戏：观察生产效率的因素
个体差异
生产效率的非相关因素
你可能不想让你的老板知道
工作环境的影响
我们证明了什么
在空间上省钱
席卷大地的瘟疫
让我们暂停抨击，来谈几点事实
工作环境质量和产品质量
诺贝尔奖级别的发现
躲起来
间奏曲：生产效率度量和不明飞行物
吉尔布定律
但是，不知你可否接受
闭上你的眼睛去度量
大脑时间与身体时间
流
没有流的无休止状态
根据流来计算时间
E参数
一座丝巾花园
对工作的思考
电话
进入另一个世界
魔界奇谭
修改过的电话道德
不兼容的多任务处理
门的回归
表演还未结束，直到胖妈开始演唱
闪亮的问题
创意空间
活力空间
打破企业常规
采取保护步骤
亚历山大的有机控制理论
模式
第一个模式：从工具箱里定制工作空间
第二个模式：窗户
第三个模式：室内和室外空间
第四个模式：公共空间
模式之模式
回归现实
第三部分正确的人
霍恩布洛尔因素
天生与后天练就
整齐的塑料人
着装标准
词汇代号：专业
企业熵
谈谈领导力
作为工作压榨机制的领导力
作为服务的领导力
领导力和创新
领导力：言与行
雇一名杂耍演员
作品集
技能测试
组织一场试演
与他人良好合作
首先，机遇
食物魔法
是的，但是……
童年的终结
科技——和它的反面
持续不断的局部注意力
明确合同
昔日的杀手级应用
在这儿很开心
离职率：明显的花费
离职的隐性成本
人们为何要离开
一种特殊的病理学：公司搬迁
永恒之地的观念
人力资本
对人来说呢？
谁在意这些？
衡量人力资本投资
新人上手需要多长时间？
玩华尔街的游戏
第四部分高效团队养成
整体大于部分之和
有凝聚力团队的概念
歇斯底里式的乐观管理
纳瓦隆大炮
有凝聚力团队的标志
团队和团伙
黑衣团队
传奇团队的人员组成
可怜的地球生物，谁能拯救你们呢？
小结
团队自毁
防御式管理
官僚主义
物理分隔
时间碎片
牺牲产品质量
伪造截止日期
团伙控制
重游伤心地
再谈团队自毁
可恶的标语和纪念牌
加班：一种意外的副作用
竞争
考虑一个类比
这有关系吗？辅导的重要性
再谈团队自毁
混合的隐喻
一顿意面晚餐
团队效应开始起作用
这里发生了什么？
敞开和服
感觉好，请“病”假
走出去
存在规则，但我们要打破规则
带嘴唇的鸡
这里谁说了算？
团队形成的化学反应
对质量的执著追求
结婚时，我告诉她我爱她
精英团队
不要拆散洋基队
团队行为的网络模型
中餐菜谱的选择
做个总结
第五部分沃土
自我愈复系统
确定性与非确定性系统
方法学的隐蔽含义
疯狂的方法学
恶意合规问题
鸡和鸡蛋
再论高科技假象
与风险共舞
不要逃避风险
我们几乎从不管理的一种风险
为什么不达标的风险总是没有得到管理
会议、独白和交流
神经硬化
“科技手段增强”的会议
站立会议
基本的健康会议
仪式
太多参与者
开放空间社交
治愈会议上瘾组织的处方
终极管理罪恶得主是……
举例说明
项目状态会议只关于状态
早期超编
再说碎片化
尊重你自己的投资
“邪恶”电邮
忆往昔
公司内垃圾邮件
“FYI”到底啥意思？
是开放型组织，还是公社？
撤销被动的同意
建立一个少垃圾邮件、自我协调的组织
让改变成为可能
现在，聆听另一位著名顾问的几句话
老板，这想法很妙。我马上着手进行
一个更好的变化模型
安全第一
组织型学习
经验与学习
一个重新设计的例子
组织型学习的关键问题
管理团队
空白地带的危险
构建社区
偏离公司政治
为什么需要社区
没有魔法
第六部分快乐地工作
混乱与秩序
进步是我们最大的问题
试点项目
战争游戏
头脑风暴
培训、旅行、会议、庆祝和撤退
自由电子
小作坊现象
同事、大师、内部创业者
没有前车之鉴
霍尔加?丹斯克
然而，为什么是我？
沉睡巨人
醒来吧，霍尔加
精彩书摘
第一部分
管理人力资源
作为管理者，我们多数人很容易陷入一种典型的失败情境：习惯把人当作固定的模块来管理。当然，这种惯性来源显而易见。回顾我们在走上管理岗位之前所做的准备：我们之所以被认为具备管理者的素质，是因为作为办事员、技术员或开发者的我们所表现出来的良好绩效。这样的绩效得益于我们能够将资源划分为模块，例如软件的过程、电路板或其他工作单元。我们用黑盒的特性来构建这些模块，从而达到屏蔽模块内部特性的目的。设计这些模块，使得它们可以通过标准接口来使用。
由于长年累月对模块化方法的依赖，新晋的管理者很少会怀疑是否能沿用同样的方法对人力资源进行管理。很不幸，这常常并不奏效。
在第一部分，我们一起来探索一种迥然不同的思考人及管理人的办法。这种办法考虑的是怎样去适应人的“非模块化”特征。
01
此时此刻，一个项目正在走向失败
自计算机被广泛使用以来，编写出了数以万计的应收账款程序（AccountsReceivableProgram）。当你正在阅读这些文字时，可能又有数十个或者更多的应收账款程序即将完成。然而，此时此刻，一个项目正在走向失败！
想象一下！一个没有真正技术创新的项目正在滑向失败的深渊。应收账款程序不过是一个“重复发明的轮子”，经验老到的开发人员面对这样的项目总能驾轻就熟。即便如此，有时在项目中付出的努力却南辕北辙，最终将项目推向失败。假设其中一个走向崩溃的项目结束，并邀请你前往会诊。（当然，这事儿永远不会发生，我们这个行业自有一条金科玉律来阻止我们分析失败。）
现在假设在所有参与者寻觅到各自的借口之前，你有机会分析到底什么地方出现了差错。自然，你不会将项目遭遇覆顶之灾归因于技术。就当前的技术发展来看，在技术上完全可以实现应收账款系统。一定存在其他因素造成了失败。
在人件（peopleware）项目的第一个十年中，我们对开发项目及其结果进行了调研。我们评估了项目的大小、成本、缺陷、加速因素以及项目工期的成败。最终，我们统计了500多个项目的历史，它们都来自开发一线的项目数据。
统计结果表明有15%的项目出现问题：项目取消、终止、延迟或者交付的产品从未被使用。项目越大，出现问题的几率就越高。对于持续时间达到25个工作年及以上的项目，足有25%的项目最后宣告失败。在早期分析中，我们舍弃了这些失败项目的数据，而对其他项目进行了分析。但自1979年以来，我们一直努力联系项目上可以找到的人员，期望发现究竟是哪里出现了问题。我们研究的绝大多数失败项目中，没有一个是因单纯的技术问题导致失败的。
游戏的名称
“政治”（politics）是被访问者最常提及的失败原因。但这个词经常被人们习惯性地含混使用。在“政治”这个词语下，包含着诸多不相关联或松散关联的东西，如交流问题、人员安排问题、与上级或客户关系不和、缺乏动力、高离职率等。人们经常用政治来描述所有与人相关的工作，但语言学对这些内容提供了更为准确的描述：它们构成了项目的社会学。真正的政治问题不过是这些病态特征的冰山一角而已。
倘若你认为一个问题属于政治的范畴，你会宿命般地逆来顺受。我们总是能直面技术的挑战，然而坦率地讲，我们又有几人能自信地面对政治这个圈子呢？认识到问题真正的本质分属社会学的范畴，而与政治无关，能帮助我们面对问题时更游刃有余。项目及团队社会学或许超出了你的专业范畴，却没有超出你的能力之外。
不管你怎么命名这些与人相关的问题，它们都比所有的设计、实现及方法论问题更有可能在下一个项目中给你制造麻烦。事实上，本书的基本论调都是基于这个想法：
我们工作中的问题更多属于社会学范畴，而非技术范畴。
大多数管理者坦承：他们对人的担心更甚于对技术的担心。但他们很少以此种方式去管理。他们的管理方式总是视技术为主要关注点。他们总是越俎代庖，将大量时间耗费在本该由团队解决的复杂而又有趣的难题上，就好像他们是自己完成工作，而非进行管理。他们总是在寻求某种技术银弹（technicalwhizbang），以期让工作实现自动化（参见第6章）。在他们的职责中，最重要的与人相关的要素却被放到了最低优先级。
滋生这种现象的部分原因来自于管理者的提拔机制。对新晋管理者的训练是如何完成一项工作，而不是如何管理它。很少有公司会考察新晋管理者在工作中是否展示出相应的能力与良好的心态来胜任管理工作。他们缺乏管理经验，也没有具体的实践。那么，新晋管理者又是如何自我说服应该花更多的时间考虑问题的技术因素而非人的因素的呢？
高科技的幻觉
问题的症结或许在于高科技的幻觉：广为人知的理论认为凡是接触新技术的人（我们谁不是呢？）就被想当然地看做属于高科技领域。在鸡尾酒会上，当人们畅谈自己就职“计算机行业”、“电讯行业”或者“在线电子交易行业”时，很容易沉溺于这种假象中，认为他们自己就是高科技世界的一部分。在我们看来，他们通常都不是。只有在上面那些领域从事基础研究、获得根本突破的科研人员才是高科技工作者，其他人只是在运用他们的研究成果。我们使用计算机和其他技术来开发我们的产品或者帮助组织我们的事务。由于我们以团队、项目或者其他紧密协作工作小组的形式来完成工作，我们大多数人是在从事人类交流的职业。我们的成功源自于所有参与者良好的人与人之间的互动，我们的失败则归因于这种互动的缺失。
我们习惯性地专注于工作中的技术问题，主因并非它们重要，而是因为它们更简单。安装一块新的硬盘，比寻思为何Horace显得忧郁而恐慌，Susan入职几个月就对公司不满要容易得多。人与人之间的互动非常复杂，没有简单规律可循，但在工作中它的确更为重要。
倘若你发现自己更加关注技术问题而非社会问题，那你就像是一名杂耍演员，在一条昏黑的街道丢失了钥匙，却逡巡至邻近的街道去寻找，并美其名曰：“那里的灯光更明亮。”
……
前言/序言
30多年前的一次越洋旅途中，在航班上的漫长夜晚，我们萌生了撰写人件相关内容的想法。当时，我们正从洛杉矶赶往悉尼去教授软件工程的系列课程。在飞机上，我们难以入眠，索性谈论起自己经历的以及从客户那里了解到的软件系统的高复杂度。我们中的一人（不记得到底是谁了）从我们的讨论中总结道：“也许……软件系统的主要问题不在于技术，而在于社会性因素。”
我们花了好一会儿才想明白这其中的缘由，这和我们先前对软件的理解完全不同。我们和那些沉迷于高科技的人士一样，坚信技术就是一切，无论出现什么问题，总会有更好的技术为我们找到出路。但是，如果我们所面对的问题天生就属于社会学的范畴，再好的技术可能也提供不了什么帮助。例如，对于一组必须工作在一起的人彼此不信任的情形，就没有什么软件包或万能工具能改变他们，以解决这个问题。
这样的想法一经产生，就驱使我们展开对一些案例的研究，进而我们俩都认识到，在大多数项目中，社会性的复杂度远比技术上的挑战要难处理得多。而且，不可避免地，我们还要面临一个更加严峻的问题：即便我们意识到社会性因素比技术上的因素重要得多，也从来没有用这样的思维观念管理过团队。是的，我们也会不时地改善团队的协作环境，或者缓解团队的紧张情绪，但这些事情从来没有成为我们工作的核心。
如果我们早些知道人的因素要重于技术因素的话，我们的管理方式会有什么不同呢？于是，我们开始梳理这些想法。正好，我们手头上有空白胶片和油笔，可以将这些令人炫目的想法记录到胶片中，传神而又真实地展现给我们在悉尼的观众。哦，天呐！悉尼可是与美国和欧洲相隔了半个地球那么远，要是我们不回家，谁又会知道我们此时此刻的重大发现呢？
接下来的一周，悉尼的观众立马加入了对人件的讨论行列，当然他们还有那么一点儿懊恼（看来，不只是我们才有唯技术是用论的观点）。最重要的是，人们踊跃发言，分享了不少他们自己的案例，这让我们感激万分，而又备受鼓舞。
较之本书在1987年出版的第1版，我们通过大量的问卷调查和一线实验证明了第1版中关于环境影响的猜测（见本版中的第二部分），同时验证了我们关于团队结构和沟通上的一些更为激进的建议（见本书其余部分内容）。
本书的前两版使我们成了技术项目中人文问题研究的专家，而我们也在按着这个思路不断前进。在本版新增的章节中，讨论了一些领导力上的病理症状，在先前版本中这些没有作为病理来归纳；书中还讲述了会议文化的演进，以及如何管理新旧成员水火不容的混合团队；我们也越来越清楚地认识到，一些日常使用的工具会成为我们前进的阻力而非动力。
对于本书的出版，非常感谢DorsetHouse出版社的WendyEakin和Addison-Wesley出版社的PeterGordon为我们编辑了手稿。此外，还要感谢我们在TheAtlanticSystemsGuild公司的同事——PeterHruschka、SteveMcMenamin和SuzanneRobertson，感谢他们30年来给我们提供想法，和我们一起进行头脑风暴、开展辩论，为我们提供餐饮美食，以及给予我们的这份浓浓的友谊。
TomDeMarco于缅因州卡姆登市
TimothyLister于纽约
2013年2月
PEOPLEWARE
ProductiveProjectsandTeams
用户评价
阅读《名家经典系列：人件（原书第3版）》的过程，更像是一次自我反思和对过往工作经历的重新审视。我发现，许多我们在软件开发过程中遇到的“技术难题”，往往并非技术本身，而是与“人”相关的因素造成的。这本书的独特之处在于，它将焦点从“软件”转移到了“人”身上，探讨了如何构建高效、协作、有活力的团队。它可能深入分析了团队成员的心理特征，以及这些特征如何影响项目的进程。例如，书中或许会探讨“创新”与“稳定性”之间的平衡，如何理解不同性格的开发者的优缺点，以及如何有效地管理他们的期望。我曾经遇到过一个项目，团队成员之间缺乏有效的沟通，导致许多需求被误解，最终返工率极高。这本书让我意识到，这并非简单的技术问题，而是团队沟通机制的缺失。它可能提供了关于如何建立清晰的沟通流程，如何鼓励开放的讨论，以及如何通过有效的反馈来减少误解的宝贵建议。这种对“人性化管理”的深入挖掘，是我在其他技术书籍中鲜有见过的。它让我明白，一个成功的项目，不仅需要优秀的技术，更需要优秀的人际关系和团队协作。
评分初拿到这本《名家经典系列：人件（原书第3版）》时，我并未抱有太高的期望。近些年，“如何提升团队效率”、“打造卓越项目”之类的书籍层出不穷，但真正能触及本质、带来颠覆性思考的却屈指可数。大多数书籍要么停留在泛泛而谈的口号层面，要么陷入对工具和流程的微观纠缠，而忽略了项目成功的根本——人。我带着一丝审慎和几分好奇翻开了它，心想着，或许又是一本“老生常谈”。然而，随着阅读的深入，一种久违的“醍醐灌顶”之感逐渐在我心中蔓延开来。作者并未像许多技术书籍那样，将重点放在代码、算法或者项目管理软件上，而是将目光精准地投向了软件开发中最核心、也最容易被忽视的要素：人。他深刻地剖析了团队成员的心理、动机、协作方式以及个体在团队中的成长与发展。书中对于“人件”这个概念的阐释，让我眼前一亮。它不再是冰冷的“产品”，而是充满活力、情感和智慧的“人”，是项目的灵魂所在。这种视角上的转变，无疑为我理解和实践项目管理打开了新的维度。我开始反思过往的诸多项目，那些曾经的瓶颈和挫折，或许并非技术难题，而是源于对团队成员的理解不够深入，对人际关系的忽视，以及未能有效地激发团队的潜能。这本书就像一盏明灯，照亮了我前进的方向，让我看到了团队建设和项目成功的另一条重要路径。
评分这本书带给我的冲击，远不止于理论上的启发，更多的是一种实操上的指导，尽管我并没有直接读到书中具体的“内容”，但它所散发出的那种洞察力，让我不禁联想到过往无数次团队协作的场景。我常常觉得，很多项目之所以会陷入泥潭，并非技术本身有多么高深莫测，而是团队内部的沟通不畅、责任不清、信任缺失，甚至是领导者与成员之间缺乏有效的反馈机制。书中似乎点出了这些问题的根源，并提供了思考的方向。例如，它可能深入探讨了如何构建一个能够容忍失败、鼓励试错的文化，如何识别并应对团队中的“低效能者”，以及如何设计合理的激励机制来驱动团队成员的积极性。我曾经参与过一个项目，团队成员都是技术大牛，但项目进度却屡屡受阻，究其原因，是大家各自为战，缺乏共同的目标和协作意识。书中对“团队动力学”的探讨，或许能解释当时我们遇到的困境，并提供相应的解决思路。它可能引导读者去思考，如何将个体目标与团队目标对齐，如何建立清晰的沟通渠道，如何通过有效的领导来凝聚人心。这种对“软技能”的强调，恰恰是当前软件开发领域最容易被技术光环所掩盖，却又至关重要的一环。
评分在阅读《名家经典系列：人件（原书第3版）》的过程中，我最大的收获是，它让我意识到，软件开发并非一项孤立的技术活动，而是一项充满人情味的集体创作。这本书可能深刻地剖析了，如何将一群拥有不同技能、不同性格的人凝聚成一个高效协作的团队。它或许会探讨“知识共享”的重要性，如何鼓励团队成员之间的互相学习和帮助，以及如何建立一个支持性的学习环境。我曾经在团队中遇到过知识孤岛的问题，每个成员只专注于自己的领域，缺乏横向的沟通和交流，导致整个项目的进度受到阻碍。这本书的出现，让我意识到，这并非一个技术问题，而是一个团队文化和协作机制的问题。它可能提供了关于如何打破知识壁垒，如何鼓励开放的知识分享，以及如何通过有效的引导来促进团队成员之间的协作的实用建议。这种对“协作的力量”的强调，让我觉得这本书极具价值。它让我明白，一个真正强大的团队，是能够将个体力量汇聚成集体智慧，共同创造出超出个体能力的成果。
评分这本书给我最深刻的感受是，它彻底颠覆了我之前对项目管理的一些刻板印象。我一直以为，项目成功更多地取决于严谨的流程、先进的技术和精密的计划。然而，《名家经典系列：人件（原书第3版）》却像是在告诉我，这一切都建立在“人”的基础上。它可能非常详细地探讨了，如何在团队中培养一种积极的文化，如何让成员感到被尊重和被重视，以及如何激发他们的内在驱动力。我曾经参与过一个项目，团队成员士气低落，工作效率不高，我们尝试了各种技术手段，但效果甚微。这本书的出现，让我意识到，问题的根源可能在于团队的整体状态。它可能提供了关于如何识别和解决团队冲突，如何建立互信的关系，以及如何通过有效的领导来提升团队士气的深刻见解。这种对“人文关怀”的重视，让我觉得这本书不仅仅是一本技术读物，更是一本关于如何成为一个更好的领导者和团队成员的指南。它让我明白，关注“人”的成长和福祉，才是实现项目成功的根本。
评分买了充充电，最近又要面试了，希望有用
评分618买的，感觉挺不错的
评分现在真受不了这些，必须让人写评价，还有字数问题
评分经常从京东买书，不错，配送快，书的质量很好，而且很全。我买的好多书，书店没有，都是从京东买的！！！
评分深入浅出，印象深刻，一场奇妙般的旅行。
评分偏管理，比较受用，印刷质量不错，包装精美
评分买来看看，京东快递很好，送货速度很快
评分书写的还行，可是翻译真是烂透了，怀疑是直接机器翻译的！建议不要买，要买就买英文版的吧，中文版真是骗钱的。
评分红红火火经济和环境及坎坎坷坷
相关图书
本站所有内容均为互联网搜索引擎提供的公开搜索信息，本站不存储任何数据与内容，任何内容与数据均与本站无关，如有需要请联系相关搜索引擎包括但不限于百度，google,bing,sogou 等
© 2025 book.cndgn.com All Rights Reserved. 新城书站 版权所有