懂人心的软件开发：不现实的机器化软件人假设

我是70后。1993年从大学计算机应用专业毕业后，就一直在企业IT部门一线团队，从事软件开发和咨询工作。先后在国企、私企和外企，做过IT系统管理、Web应用开发、软件测试、项目管理和软件开发咨询。2014至2022年，我在Thoughtworks公司做过8年的软件开发技术教练，帮助几十家企业的IT部门，落地持续集成和自动化测试等敏捷软件工程实践。2022年底我从公司离职，成为独立咨询师。目前专注做懂人的软件开发的培训和咨询。我是《驯服烂代码》的作者，《发布！》第2版译者，《混沌工程》合译者。

什么是懂人的软件开发？

难道目前主流的软件工程和敏捷软件开发不懂人吗？相比已经接纳懂人的行为经济学的观点的主流经济学来说，当前主流软件工程和敏捷软件开发，就像1979年Daniel Kahneman和Amos Tversky发表论文《前景理论》之前主宰经济学领地的新古典主义经济学一样，确实不懂人。

什么是懂人？这里的人，指的是在软件开发和应用领域，做软件的人和用软件的用户。其中做软件的人，指规划、设计和实现软件的人员，包括在企业业务部门规划软件需求的业务人员及其相关管理者，和在IT部门为这些业务人员设计和实现软件的需求分析、用户界面和体验、开发、测试和运维人员及其相关的管理者。

作为起点，懂人的软件开发，主要研究做软件的人的社会和心理特点，暂不考虑软件用户。

这样，懂人，就是指做软件的人搞懂有关自己、自己所属的一线团队（针对非管理者的做软件的人）、所管理的团队及其成员（针对是管理者的做软件的人），在工作中做出行为和决策时的社会和心理特点。这里的社会，涉及社会心理学；心理，涉及心理学和行为经济学。其中，心理学会涉及它的一些子学科，包括社会心理学、认知心理学、神经心理学和进化心理学。

什么是懂人的软件开发？针对软件开发业界主流，当前只重视技术和过程，不关注做软件的人的社会和心理特点，导致做软件的人消极应付企业软件开发规范的问题，懂人的软件开发，将社会心理学和行为经济学研究成果，应用于软件工程和敏捷软件开发中，用助推方法，以较低成本，让做软件的人在工作中自然而然地做出有助提升软件产品质量和用户价值的行为。

社会心理学与行为经济学与软件开发有什么关系？

企业IT部门软件开发的成败，乃至企业数字化的成败，不仅取决于企业能否选择合理的软件开发技术和过程，更取决于运用这些技术和过程的做软件的人，能否做出提升软件产品质量和用户价值的有效行为。

“心理学的目标，就是描述、理解、预测和干预人们的行为”（Coon, D.; Mitterer, J. O.; 2013）。

社会心理学是一门研究下述事物的科学研究，即人们的思想、情感和行为如何受到真实或想象的他人存在的影响的方式（Allport; 1985）。注意，与社会心理学所研究的对象不同，人格心理学是研究使个体之间彼此不同的特征的科学。虽然人格的研究增加了我们对人类行为的理解，但社会心理学家认为，主要通过人格特质来解释行为，忽略了一个关键：社会影响力所发挥的强大作用（Aronson, E.; 2021）。因为软件开发的成功，十分依赖不同角色的做软件的人的密切协作，所以社会心理学的研究成果在此会发挥重要作用。

另外，包括行为经济学在内，“所有的经济学，都是研究行为的，即研究人们在不同情境下，当需要采取行动和分配资源时，如何做出选择”（Wilkinson, N.; Klaes, M. ; 2017）。

由此可见，为了提升软件产品质量和用户价值，企业需要描述、理解、预测和干预做软件的人在工作中的行为，这就将软件开发与社会心理学和行为经济学联系在一起。

不懂人地做软件开发会怎样？

举一个不懂人强推敏捷工程实践，导致浪费的例子。某企业IT部门管理者认为，开发人员在写代码前，采取先写测试代码的TDD（Test-Driven Development，测试驱动开发）实践，能促使开发人员在实现需求前，思考该如何验收生产代码，并做小步重构。由于良好的测试代码只测试封装良好的接口，所以这样做，有利于设计或重构出高内聚低耦合的代码。另外所写出的自动化测试代码，能保护生产代码的逻辑，不会在将来被自己或其他人破坏掉。

开发人员听明白了这些好处，也在编程道场里练过了TDD。但等回到工位上，看到管理者走过来催进度，在进度的压力下，开发人员就会很自然地把TDD抛脑后，只关注对自己绩效考核直接挂钩的进度，毕竟这是管理者最看重的。

即使企业IT部门为了提升产品质量，制定了必须把测试代码和生产代码同时提交的开发规范，并在部门内进行了宣贯，在持续集成流水线上设置了门禁，若发现测试代码没有和生产代码一同提交的情况，就不允许提交代码，但开发人员还是有办法应付差使——随手写几个没有assert断言的测试代码，与生产代码一起提交了事。

这样没有断言的测试代码，能让其所覆盖的生产代码运行起来，通过工具能让测试覆盖率在研发效能仪表盘上显示出令人振奋的数据。但由于测试代码不做任何有关代码逻辑质量是否达标的判断，所以根本起不到生产代码质量保护网的作用。这种不懂人的软件开发实践，只会让开发人员浪费宝贵的时间，写一个花架子测试代码，摆样子罢了。

懂人的软件开发会是怎样的？

那懂人的软件开发，面对同样的问题，会怎样做呢？开发人员有一个社会和心理特点，就是视生产环境为神明。有的开发人员会在新代码上生产环境之前，烧香拜佛，祈求保佑。

由于懂人的蓝军小组，充分顺应了开发人员敬畏生产环境的社会和心理特点，所以开发人员此时会把自己手上其他的工作暂时放一放。在故障注入前，会优先做强化生产环境系统稳定性的设计和实施；在故障注入后且出现小范围的生产故障时，会优先排查和解决生产问题。

这样的懂人的软件开发，再加上与之配套的混沌猴工具，Netflix公司在2011年就已经在其亚马逊云生产环境上大规模实践过了，且取得了良好的规模化提升系统稳定性的成效。之后，该公司将这种实践，命名为混沌工程，并在2020年，出版了同名书籍。

但遗憾的是，包括《混沌工程》一书的作者和该书所有篇章作者在内的混沌工程实践者，都只强调混沌工程的技术和过程，却忽视了顺应做软件的人视生产环境为神明的社会和心理特点。而这才是规模化落地生产系统稳定性的关键点。

虽然混沌工程的高级原则，明确指出要在生产环境进行故障注入实验（Rosenthal, C.; Jones, N.; 2020），但由于没有强调上述关键点，其后果，就是我在为客户做混沌工程咨询项目时，以及在阅读一些企业混沌工程实践经验分享文章时，看的这样的场景：国内众多企业的故障注入实验，往往止步于测试环境和准生产环境。在生产环境进行故障注入实验，他们犹豫再三，终究下不了决心。这导致混沌工程实践，沦落为另一种软件测试。“混沌工程不就是测试吗。出问题给我发邮件。”开发人员对测试人员说完后，就又忙着手上进度要求最紧的事情了。混沌工程实践在准生产环境所发现的生产系统稳定性问题，被抛入长长的bug待办项列表里，不知何时有出头之日。

作为《混沌工程》一书的合译者，我在翻译这本书时，当看到要在生产环境进行故障注入实验这条高级原则，也只是目光一扫而过。只有在后来，当我在做混沌工程咨询工作时，看到故障注入实验仅在测试和准生产环境进行，引不起开发人员的重视，并且在阅读了行为经济学的书籍，进行了深入的思考，才悟出开发人员视生产环境为神明的社会和心理特点，才是混沌工程成功的关键点。由此看来，只有在生产环境中进行的故障注入实验，才配得上叫混沌工程。只在测试和准生产环境中执行的实验，不能叫混沌工程，只能叫测试。

问题的根源是不现实的机器化软件人假设

目前业界主流软件工程和敏捷软件开发，不懂人，其背后的原因到底是什么？

最大的原因，就是*地基不稳固，即底层的机器化软件人假设不现实*。

什么是机器化软件人假设？先看看新古典主义经济学中的理性经济人假设。为了让经济学更像基础牢固的自然科学，新古典主义经济学会大量使用数学模型，计算经济参数。为了让数学建模更加方便，新古典主义经济学家假设经济主体的代表是理性经济人。理性经济人追求自我利益最大化（自利性），能从众多可选项中理性地做出自我效用最大化的决策（理性），能获取做决策所需的完备信息（信息完备性），具备不会被无关因素干扰的前后一致的风险偏好（偏好一致性）。

在软件开发行业，对于做软件的人，虽然不存在一个类似理性经济人那样明确的假设，但会在做软件的人的潜意识里，存在隐性的机器化软件人假设。

机器化软件人假设，指做软件的人，尤其是企业IT部门的管理者和相关业务部门的管理者，会不自觉地把非管理者的做软件的人，看作是可按照预设好的逻辑，随时运转的机器，或者运行指令的代码模块，且能随时替换。这个假设没有明确地书写在纸面上，但却隐性地常驻在做软件的人的心里。为命名简洁起见，机器化软件人这个名字，同时也有将软件人视作代码模块的含义。

注意，“软件人”和“做软件的人”这两个提法是有区别的。前者因为有“软件”这个锚，所以还是把人物化的概念。后者虽然也有“软件”，但在物化方面，会比前者好很多。当我们需要强调有社会和心理特点的人的时候，就用后者。反之用前者。

机器化软件人假设，明显不现实。一个活生生的人，为何做了软件后，就变成了可运行和可替换的机器或代码模块？

这也不能怪做软件的人。他们之所以能不自觉地做出这样的假设，也是有原因的。原因就是行为经济学所发现的锚定效应。

锚定效应，是一种认知偏见。指个人的决定或估算，会受到最初的信息（称为 "锚"）的影响。这种信息往往是不相关的或随意的。这个锚会作为一个参考点，影响后续的判断和决策。比如，在一个实验中，行为经济学者先要求一组学生写下他们身份证号码最后两位数字。这基本上是00和99之间的随机数字。然后行为经济学者要求他们对6个不同的产品进行估价，包括一盒巧克力、两瓶不同牌子的酒、一个无线鼠标、一个无线键盘和一本设计书。结果显示了显著的一致性，即身份证号码较大的学生，对所有产品的估价都比较高。身份证号码最大的前20%的人（从80到99）估价最高，他们的估价与身份证号最小的20%的人（从00到19）的估价的比值，竟然在216%到346%之间！（Wilkinson, N.; Klaes, M. ; 2017）

做软件的人包括了管理者和非管理者。先看锚定效应是如何对管理者起作用的。首先，IT部门的管理者，一般都是因为软件开发技术好，而提拔上来的。他们在管理者岗位上，会经常参与架构评审等技术活动。他们在工作中的大部分时间，都会与代码模块打交道。这些代码模块就是锚。当他们再看到做软件的人的时候，由于锚的作用，会不自觉地将做软件的人视为能运行指令和随时替换的代码模块。而业务部门的管理者，虽然不会与代码打交道，但每天会使用电脑这种机器。而IT部门有大量的电脑。这些机器就是锚。当业务部门的管理者一边使用电脑，一边与来自本部门或IT部门的做软件的人打交道时，在锚的作用下，会自然地将做软件的人视作能随时运转和替换的机器。

在锚的作用下，管理者将做软件的人视作机器或代码模块，会有什么后果？后果就是管理者会一厢情愿地为做软件的人制定一系列他自认为符合软件工程和敏捷软件开发原则的规范，而不关心做软件的人在执行这些规范时，是否有难处。“反正你是机器或代码模块。我要你怎么做，你就该怎么做。”管理者的潜意识会这样对自己说。

更糟糕的是，对于业务部门和IT部门非管理者的做软件的人，由于天天与电脑和代码模块打交道，他们也会在锚的作用下，把自己视作机器或代码模块。后果就是这些做软件的人即使发现企业软件开发规范设计得不合理，也很少向管理者提出来，因为自己的职责就应该是像机器或代码模块一样，执行管理者的指令。另外，由于机器或代码模块可以随时被替换，所以在惧怕管理者替换自己的心理驱使下，做软件的人一般会优先做有助于自己通过绩效考核的工作，比如赶上开发进度。但对于提升产品质量和用户价值这些开发规范所要求的事情，就没时间和精力做了，只好对付一下。

锚定效应所导致的机器化做软件的人假设，让企业管理者只是一厢情愿地制定软件开发规范，而不去关注做软件的人的难处；另外做软件的人也在锚定效应的作用下，不去向管理者指出开发规范不合理的地方，而只是草草应付规范了事。在这种情况下，企业数字化和IT部门的软件开发，还能取得让做软件的人心服口服的成功吗？

如何应对不现实的机器化软件人假设？

对做软件的人的假设，是企业成功实践软件工程和敏捷软件开发的地基。现在的地基，是不现实的机器化软件人假设。地基不稳，大厦将倾。

要改变这个局面，做软件的人需要首先抛弃不现实的机器化软件人假设，同时建立现实的人性化做软件的人假设。这里的人性化做软件的人，指做软件的人具备社会和心理特点，决策时大脑默认使用直觉思维系统，必要时才使用理性思维系统，已经进化了600万年的活生生的人。

做软件的人中的管理者，在制定完软件开发规范后，会意识到非管理者角色的做软件的人，不会是听任摆布的机器或代码模块。此时，管理者可以看似若无其事地在他们工位或茶水间附近溜达，听听他们对开发规范的评论，观察他们实际的工作行为，体会他们的难处，思考背后的原因。然后顺应他们的社会和心理特点，用大胆假设，小心求证的科学实验方法，把软件开发规范规划得能让他们在工作中，自然而然地做出能提升产品质量和用户价值的行为。

注意，这个过程只能使用助推。要从管理者抛弃机器化软件人假设的观念，并做行为助推规划开始。此时切忌强推。切忌。

什么是助推？什么是行为助推规划？为何强推不行？懂人的软件开发还有什么内容？请关注之后的系列文章。

哪里能找到懂人的软件开发的资料？

鉴于国内外软件开发行业主流，片面重视技术和过程，忽视做软件的人及其团队的社会和心理特点和实际行为的现状，讨论懂人的软件开发的材料少之又少。下面列出6本书我读过且认为较好的书籍，供大家参考。今后的文章也会不定期推荐一些好的材料。

1 《人件》（第3版）; Tom DeMarco / Timothy Lister 著; 张逸 / 肖然 / 滕云 译; 电子工业出版社; 2023年4月

2 《人件集》; Larry L. Constantine 著; 谢超 / 刘颖 / 谢卓凡 / 李虎 译; 机械工业出版社; 2011年12月

3 《助推》; 理查德·塞勒 / 卡斯·桑斯坦 著; 刘宁 译; 中信出版社; 2018年3月

4 《行为经济学》; 尼克·威尔金森 著; 贺京同 / 那艺 等 译; 中国人民大学出版社; 2012年9月

5 An Introduction to Behavioral Economics, 3rd Edition; Nick Wilkinson, Matthias Klaes; Springer; January 1, 2017

6 《打胜仗的策略》; 布赖斯·霍夫曼 著; 张琪 译; 天津科学技术出版社; 2020年中文版

这6本书中，前两本主要讨论了软件开发中的社会性因素。但由于缺乏心理学的视角，这两本书只讨论了做软件的人应该做的行为，比如追求产品的高质量，但没有讨论做软件的人为何从内心需要追求高质量这样深层的心理学原因。

要了解这些原因，可以读后3本书。其中2012年出版《行为经济学》的中文版，只对应2007年出版的英文版第1版，内容比较陈旧。第5本是该书英文版第3版。内含行为经济学最新的研究成果。可以在翻译工具的帮助下阅读。

第6本讨论了如何将行为经济学所研究出来的人类的认知偏见和经验式方法，运用于企业关键行为的决策中。这可以供那些希望在本企业IT部门尝试蓝军小组的做软件的人参考。

因为相关研究成果和资料较少，要掌握懂人的软件开发，除了读书，还少不了讨论，以及用科学方法做实验，以便在企业内验证一些助推软件开发的假设。只有用科学方法亲身提出问题，形成假设，做出预测，做实验验证预测，并根据实验结果进行迭代，才能实现懂人的软件开发。

如有兴趣参与讨论和做实验，请*加我微信wubinben28*，*注明“懂人”*。我会拉你入群，一起用科学方法，探索和实践懂人的软件开发。也可以给我发邮件。我的邮箱是wzb@wuzhenben.com。

本文欢迎转载。转载时请不要修改文章内容，并在文章开头注明以下文字：“懂人的软件开发：不现实的机器化软件人假设；作者：吾真本；邮箱：wzb@wuzhenben.com”。

懂人的软件开发还有什么内容？可以关注之后的系列文章。

参考书目

Allport, G. W.; 1985; The historical background of social psychology. In G. Lindzey & E. Aronson (Eds.), The handbook of social psychology (3rd ed., Vol. 1, pp. 1–46). New York: McGraw-Hill

Aronson, E.; 2021; Social Psychology (10th Edition, Global Edition); Pearson Education Limited

Coon, D.; Mitterer, J. O.; 2013; Psychology: A Journey

Hoffman, B. G.; 2017; 打胜仗的策略; 张琪 译; 天津科学技术出版社; 2020年中文版

Rosenthal, C.; Jones, N.; 2020; 混沌工程：复杂系统韧性实现之道; 吾真本 / 黄帅 翻译; 机械工业出版社; 2022年中文版

Wilkinson, N.; Klaes, M. ; 2017; An Introduction to Behavioral Economics, 3rd Edition