书 · 1987 · 汤姆·迪马可（Tom DeMarco）、蒂莫西·利斯特（Timothy Lister）

《人件》

计算机与 AI书单第 34 名

一句话结论

软件项目的成败，很大程度上取决于组织能否让合适的人专心工作、彼此信任，并共同做出值得自豪的成果。

值不值得读完整本？

值得读完整本。它能帮助计算机与 AI 读者理解：技术能力怎样经过工作环境、管理方式和团队关系，才真正变成项目成果；但其中的经验判断需要与严格研究区分。

第1—6章值得细读，重点看作者怎样反驳把软件开发当作流水线生产、靠压力提高产出的想法。
第7—13章把办公环境与实际产出联系起来；读到电话、隔间和门时，可以对照今天的即时消息与会议干扰。
第14—23章是另一处重点：招聘、留人、团队凝聚与管理者的放权，需要连起来理解。
第24—26章篇幅不长，建议读完，看看作者为什么把乐趣、探索和主动改变组织也算作管理问题。
本导读按1987年初版的26章组织；阅读增订版时请按章节主题对应，章号可能不同。

核心观点

1. 先解决人的协作问题，再谈技术提效

作者认为，软件项目的主要障碍往往来自组织和人际关系。选择并留住合适的人，是管理工作的中心。

为什么：软件开发需要判断、交流和共同理解，成果不能像标准零件一样只靠工时累加。工具可以改善局部操作，却不能自动解决互不信任、沟通失灵或人员流失。招聘时若只看履历和抽象测验，就可能漏掉实际工作能力与表达能力。人员离开还会带走已经形成的业务理解和协作关系，因此管理者要同时关心选人、工作条件和长期留任。

2. 长期产出依靠质量认同，不能靠持续透支

持续加班和人为制造紧迫感，并不能稳定增加有效产出；允许员工做出自己认可的高质量成果，反而能支持生产率。

为什么：作者认为，短期增加的工作时间，常会被随后恢复精力、补偿个人生活的时间抵消。持续施压还容易把员工对工作的投入，变成对组织要求的勉强应付。质量则与专业人员的自尊相连：做出的东西值得自豪，人们才愿意持续投入。为了赶工而强迫团队接受低质量，会破坏这种内在动力，也会削弱团队对共同成果的认同。

3. 保护连续思考，比统计在岗时间更重要

知识工作的关键资源是能够持续专注的时间。办公空间和干扰管理，应当被视为生产条件。

为什么：复杂任务要求人在脑中建立问题的上下文，进入专注状态需要时间。一次打断损失的不只是接电话或回答问题的几分钟，还包括重新进入工作状态的成本。于是，同样八小时在岗，可能包含完全不同数量的有效思考时间。只节省办公面积、忽略噪声和打断，可能省下容易看见的租金，却损失更昂贵的人员产出。

4. 真正的团队有共同身份，价值超过个人能力之和

高效团队不只是把优秀个人放在一起，而是形成共同目标、相互信任和对集体成果的认同。

为什么：当成员把成功理解为共同成功，交流、互助和承担责任就更容易发生。共同身份还能让困难成为大家一起解决的问题，而不是个人之间争功或推责的机会。这种关系需要共同经历和持续合作，不能通过一次团建活动直接制造出来。官僚手续、切碎成员时间、降低质量和随意拆散团队，会破坏这些积累，因此保护已经形成的团队本身就是一项管理成果。

5. 管理要保留团队自行判断和修正的能力

管理者应提供方向、资源与信任，并让团队决定许多具体做法。把所有判断都写成强制流程，会削弱组织应对意外的能力。

为什么：真实工作总会出现制度设计者没有预料到的情况，现场人员需要依据经验补上缺口。如果每一步只能按规定执行，明显不合适的做法也可能继续下去，因为执行者既没有权限，也不再觉得自己应当负责。作者因此把人的判断看作系统能够自行修复的重要来源。共同训练和交流可以帮助方法趋于一致，而不必把一致性完全建立在命令上。

6. 乐趣和适量探索，是组织保持活力的条件

健康的工作需要挑战、学习和一定的自主探索空间。把一切不确定性和非例行活动都消除，可能同时消除创造力。

为什么：高度重复、处处受控的工作，会减少人们主动尝试和投入的理由。小规模试验让人有机会接触新方法，并在实际行动中学习。庆祝、交流和有趣的挑战也能增强成员之间的联系，使共同工作本身具有吸引力。作者主张有意识地留下少量建设性的无序，并给少数成熟、有判断力的人更大的行动空间。

反对意见

有启发的故事，还不足以支持精确结论（Mark Bernstein）

伯恩斯坦在《Peopleware: Productive Projects and Teams》书评中肯定本书对团队与办公环境的重视，但认为一些断言主要依靠轶事，论证不够充分。他特别质疑把促进团队凝聚的人直接折算成两名普通工作者价值的说法：承认这种贡献存在，并不意味着已经测出了它的数量。

可靠过程也能提高质量，不能只强调自主（Watts S. Humphrey）

汉弗莱在《Managing the Software Process》中主张，通过过程定义、评审、标准和数据分析，让软件开发逐步变得可重复、可改进。这提供了一种不同解释：项目表现不稳定，也可能源于组织缺少共同过程，过度依赖个人经验。这不是对《人件》的直接反驳，但提醒读者，应该区分替人思考的僵化流程，与帮助人协作的必要制度。

有挑战的目标可能有效，关键在目标如何设置（Edwin A. Locke、Gary P. Latham）

洛克和莱瑟姆在2002年的目标设定研究综述中指出，在具备能力、反馈和目标承诺等条件时，具体而有挑战的目标能够引导注意、增加努力并延长坚持。这限制了把《人件》读成“管理者越少提出要求，表现就越好”的解释。两人也指出，复杂新任务可能更适合学习目标；因此，这项研究支持区分有效挑战与单纯施压，而不是为持续加班背书。该论文并非针对《人件》的直接回应。