名家经典系列：人件（原书第3版） [Peopleware: Productive Projects and Teams] 下载 mobi epub pdf 电子书 2024

编辑推荐

公认对软件行业影响、具价值的著作之一，历时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

概念书

有塑封，质量也不错，跟人月神话一起买的，待有时间了拜读一下

很好，别人介绍的书，很好

书不错，值得买。。。。

最给力的就是京东小哥儿，晚上11点半了，还在送快递，把我惊呆了，我以为今天不会送到，为小哥点赞，书很不错，送来第一时间我就浏览了一遍

还好还好还好还好哈还好还好哈

很不错，有收获，很早看过，收藏

人月神话 + 人件。两本书一起买了！

非常好的经典书籍，值得一读，总之而言不错。