注意：本文已过时。请看新版：2023-07-05修订版：懂人的软件开发：不现实的机器化软件人假设 https://zhuanlan.zhihu.com/p/641562423
我是70后。1993年从大学计算机应用专业毕业后，就一直在企业IT部门一线团队，从事软件开发和咨询工作。先后在国企、私企和外企，做过IT系统管理、Web应用开发、软件测试、项目管理和软件开发咨询。2014至2022年，我在Thoughtworks公司做过8年的软件开发技术教练，帮助几十家企业的IT部门，落地持续集成和自动化测试等敏捷软件工程实践。2022年底我从Thoughtworks公司离职，成为独立咨询师。目前专注做懂人心的软件开发的培训和咨询。我是《驯服烂代码》的作者，《发布！》第2版译者，《混沌工程》合译者。
什么是懂人心的软件开发？
难道目前主流的软件工程和敏捷软件开发不懂人心吗？相比已经接纳懂人心的行为经济学的观点的主流经济学来说，当前主流软件工程和敏捷软件开发，就像1979年Daniel Kahneman和Amos Tversky发表论文《前景理论》之前主宰经济学领地的新古典主义经济学一样，确实不懂人心。
什么是懂人心？这里的人，指的是在软件开发和应用领域，*做软件的人*和用软件的用户。其中做软件的人，简称*软件人*，指规划、设计和实现软件的人员，包括在企业业务部门规划软件需求的业务人员及其相关管理者，和在IT部门为这些业务人员设计和实现软件的需求分析、用户界面和体验、开发、测试和运维人员及其相关的管理者。
作为起点，懂人心的软件开发，主要研究软件人的心理，暂不考虑软件用户的心理。
这样，懂人心，就是指软件人搞懂有关自己、自己所属的一线团队（针对非管理者的软件人）、所管理的团队及其成员（针对是管理者的软件人），*在工作中做出行为和决策时的心理*。这里的心理，涉及心理学和行为经济学。其中，心理学会涉及它的一些子学科，包括社会心理学、认知心理学、神经心理学和进化心理学。
什么是懂人心的软件开发？针对软件开发业界主流，当前*只重视技术和过程*，*不关注做软件的人的心理*，导致*软件人消极应付*企业软件开发规范的问题，懂人心的软件开发，将心理学和行为经济学研究成果，应用于软件工程和敏捷软件开发中，用*助推方法*（如图1），以较低成本，让软件人在工作中*自然而然*地做出有助*提升软件产品质量和用户价值的行为*。
图1 象妈妈用身体轻轻地推着调皮的小象往前走，象征着行为经济学家所提倡的*容许自由的温和家长制*的助推
心理学和行为经济学与软件开发有什么关系？
企业IT部门软件开发的成败，乃至企业数字化的成败，不仅取决于企业能否选择合理的软件开发技术和过程，*更取决于运用这些技术和过程的软件人*，能否做出提升软件产品质量和用户价值的*有效*行为。
而“心理学的目标，就是描述、理解、预测和干预人们的行为”（Coon, D.; Mitterer, J. O.; 2013）。
另外，包括行为经济学在内，“所有的经济学，都是研究行为的，即研究人们在不同情境下，当需要采取行动和分配资源时，如何做出选择”（Wilkinson, N.; Klaes, M. ; 2017）。
由此可见，为了提升软件产品质量和用户价值，企业需要描述、理解、预测和干预软件人在工作中的行为，这就将软件开发与心理学和行为经济学联系在一起。
不懂人心地做软件开发会怎样？
举一个不懂人心强推敏捷工程实践，导致浪费的例子。某企业IT部门管理者认为，开发人员在写代码前，采取先写测试代码的TDD（Test-Driven Development，测试驱动开发）实践，能促使开发人员在实现需求前，思考该如何验收生产代码，并做小步重构。由于良好的测试代码只测试封装良好的接口，所以这样做，有利于设计或重构出高内聚低耦合的代码。另外所写出的自动化测试代码，能保护生产代码的逻辑，不会在将来被自己或其他人破坏掉。
开发人员听明白了这些好处，也在编程道场里练过了TDD。但等回到工位上，看到管理者走过来*催进度*，在进度的压力下，开发人员就会很自然地把TDD抛脑后，只关注对自己绩效考核直接挂钩的进度，毕竟这是管理者看重的。
即使企业IT部门为了提升产品质量，制定了必须把测试代码和生产代码同时提交的开发规范，并在部门内进行了宣贯，在持续集成流水线上设置了门禁，若发现测试代码没有和生产代码一同提交的情况，就不允许提交代码，但开发人员还是有办法*应付差使*——随手写几个没有assert断言的测试代码，与生产代码一起提交了事。
这样没有断言的测试代码，能让其所覆盖的生产代码运行起来，通过工具能让测试覆盖率在研发效能仪表盘上显示出令人振奋的数据。但由于测试代码不做任何有关代码逻辑质量是否达标的判断，所以根本起不到生产代码质量保护网的作用。这种不懂人心的软件开发实践，只会让开发人员浪费宝贵的时间，写一个花架子测试代码，摆样子罢了。
懂人心的软件开发会是怎样的？
那懂人心的软件开发，面对同样的问题，会怎样做呢？开发人员有一个心理特点，就是*视生产环境为神明*（如图2）。有的开发人员会在新代码上生产环境之前，烧香拜佛，祈求保佑。
图2 开发人员希望佛祖保佑代码上线成功
如果IT部门的蓝军小组（这是国内的叫法，在国外一般叫红队；Hoffman, B. G.; 2017），事先与开发人员合作，设计出生产环境故障注入实验。之后告诉开发人员，在新代码上线后，会有一个自动化的故障注入工具，专门在上班时间，针对生产环境关键业务逻辑的代码，注入事先设计好的故障，验证开发人员所设计的系统稳定性代码是否奏效。这样会有什么结果？当然，这种生产环境的故障注入实验，会预先在实验设计中，对故障爆发的范围进行了控制，设计了紧急情况下的恢复预案，并在准生产环境进行了验证，以避免生产环境故障注入实验严重影响业务。
由于懂人心的蓝军小组，充分顺应了开发人员敬畏生产环境的心理特点，所以开发人员此时*会把自己手上其他的工作暂时放一放*。在故障注入前，会优先做强化生产环境系统稳定性的设计和实施；在故障注入后且出现小范围的生产故障时，会优先排查和解决生产问题。
这样的懂人心的软件开发，再加上与之配套的混沌猴工具，Netflix公司在2011年就已经在其亚马逊云生产环境上大规模实践过了，且取得了良好的规模化提升系统稳定性的成效。之后，该公司将这种实践，命名为混沌工程，并在2020年，出版了同名书籍。
但遗憾的是，包括《混沌工程》一书的作者和该书所有篇章作者在内的混沌工程实践者，都只强调混沌工程的技术和过程，却*忽视了顺应软件人视生产环境为神明的心理特点*。而这才是规模化落地生产系统稳定性的关键点。
虽然混沌工程的原则，明确指出要在生产环境进行故障注入实验（Rosenthal, C.; Jones, N.; 2020），但由于没有强调上述关键点，其后果，就是我在为客户做混沌工程咨询项目时，以及在阅读一些企业混沌工程实践经验分享文章时，看的这样的场景：国内众多企业的故障注入实验，往往*止步于测试环境和准生产环境*。在生产环境进行故障注入实验，他们犹豫再三，终究下不了决心。这导致混沌工程实践，沦落为另一种软件测试。“混沌工程不就是测试吗。出问题给我发邮件。”开发人员对测试人员说完后，就*又忙着手上进度要求紧的事情了*。混沌工程实践在准生产环境所发现的生产系统稳定性问题，被抛入长长的bug待办项列表里，不知何时有出头之日。
作为《混沌工程》一书的合译者，我在翻译这本书时，当看到要在生产环境进行故障注入实验这条原则，也只是目光一扫而过。只有在后来，当我在做混沌工程咨询工作时，看到故障注入实验仅在测试和准生产环境进行，引不起开发人员的重视，并且在阅读了行为经济学的书籍，进行了深入的思考，才悟出开发人员视生产环境为神明的心理特点，才是混沌工程成功的关键点。由此看来，只有*在生产环境中进行的故障注入实验，才配得上叫混沌工程*。只在测试和准生产环境中执行的实验，不能叫混沌工程，只能叫测试。
问题的根源是不现实的机器化软件人假设
目前业界主流软件工程和敏捷软件开发，不懂人心，其背后的原因到底是什么？
大的原因，就是*地基不稳固，即底层的机器化软件人假设不现实*。
什么是机器化软件人假设？先看看新古典主义经济学中的理性经济人假设。为了让经济学更像基础牢固的自然科学，新古典主义经济学会大量使用数学模型，计算经济参数。为了让数学建模更加方便，新古典主义经济学家假设经济主体的代表是理性经济人。理性经济人追求自我利益大化（自利性），能从众多可选项中理性地做出自我效用大化的决策（理性），能获取做决策所需的完备信息（信息完备性），具备不会被无关因素干扰的前后一致的风险偏好（偏好一致性）。
在软件开发行业，对于软件人，虽然不存在一个类似理性经济人那样明确的假设，但会在软件人的潜意识里，存在*隐性*的机器化软件人假设。
*机器化软件人假设*，指软件人，尤其是企业IT部门的管理者和相关业务部门的管理者，会*不自觉地把非管理者的软件人，看作是可按照预设好的逻辑，随时运转的机器，或者运行指令的代码模块，且能随时替换*（如图3）。这个假设没有明确地书写在纸面上，但却隐性地常驻在软件人的心里。为命名简洁起见，机器化软件人这个名字，同时也有将软件人视作代码模块的含义。
图3 不现实的机器化软件人假设
机器化软件人假设，明显不现实。一个活生生的人，为何做了软件后，就变成了可运行和可替换的机器或代码模块？
这也不能怪软件人。他们之所以能不自觉地做出这样的假设，也是有原因的。原因就是行为经济学所发现的*锚定效应*。
锚定效应，是一种认知偏见。指个人的决定或估算，会受到初的信息（称为 "锚"）的影响。这种信息往往是不相关的或随意的。这个锚会作为一个参考点，影响后续的判断和决策。比如，在一个实验中，行为经济学者先要求一组学生写下他们身份证号码后两位数字。这基本上是00和99之间的随机数字。然后行为经济学者要求他们对6个不同的产品进行估价，包括一盒巧克力、两瓶不同牌子的酒、一个无线鼠标、一个无线键盘和一本设计书。结果显示了显著的一致性，即身份证号码较大的学生，对所有产品的估价都比较高。身份证号码大的前20%的人（从80到99）估价高，他们的估价与身份证号小的20%的人（从00到19）的估价的比值，竟然在216%到346%之间！（Wilkinson, N.; Klaes, M. ; 2017）
软件人包括了管理者和非管理者。先看锚定效应是如何对管理者起作用的。首先，IT部门的管理者，一般都是因为软件开发技术好，而提拔上来的。他们在管理者岗位上，会经常参与架构评审等技术活动。他们在工作中的大部分时间，都会与代码模块打交道。这些代码模块就是锚。当他们再看到软件人的时候，由于锚的作用，会不自觉地将软件人视为能运行指令和随时替换的代码模块。而业务部门的管理者，虽然不会与代码打交道，但每天会使用电脑这种机器。而IT部门有大量的电脑。这些机器就是锚。当业务部门的管理者一边使用电脑，一边与来自本部门或IT部门的软件人打交道时，在锚的作用下，会自然地将软件人视作能随时运转和替换的机器。
在锚的作用下，管理者将软件人视作机器或代码模块，会有什么后果？后果就是管理者会*一厢情愿*地为软件人制定一系列*他自认为*符合软件工程和敏捷软件开发原则的规范，而*不关心*软件人在执行这些规范时，*是否有难处*。“*反正你是机器或代码模块。我要你怎么做，你就该怎么做*。”管理者的潜意识会这样对自己说。
更糟糕的是，对于业务部门和IT部门非管理者的软件人，由于天天与电脑和代码模块打交道，他们也会在锚的作用下，把自己视作机器或代码模块。后果就是这些软件人即使发现企业软件开发规范设计得不合理，也很少向管理者提出来，因为*自己的职责就应该是像机器或代码模块一样，执行管理者的指令*。另外，由于机器或代码模块可以随时被替换，所以在*惧怕管理者替换自己的心理*驱使下，软件人一般会优先做有助于自己通过绩效考核的工作，比如赶上开发进度。但对于提升产品质量和用户价值这些开发规范所要求的事情，就没时间和精力做了，只好对付一下。
锚定效应所导致的机器化软件人假设，让企业管理者只是一厢情愿地制定软件开发规范，而不去关注软件人的难处；另外软件人也在锚定效应的作用下，不去向管理者指出开发规范不合理的地方，而只是草草应付规范了事。在这种情况下，企业数字化和IT部门的软件开发，还能取得让软件人心服口服的成功吗？
如何应对不现实的机器化软件人假设？
对软件人的假设，是企业成功实践软件工程和敏捷软件开发的地基。现在的地基，是不现实的机器化软件人假设。地基不稳，大厦将倾。
要改变这个局面，软件人需要首先抛弃不现实的机器化软件人假设，同时建立现实的*社会化软件人假设*。这里的社会化软件人，指软件人具备社会心理学、认知心理学、神经心理学和进化心理学特点，*决策时大脑经常使用直觉思维系统，偶尔使用理性思维系统*，*已经进化了600万年*的活生生的人。
软件人中的管理者，在制定完软件开发规范后，会意识到非管理者角色的软件人，不会是听任摆布的机器或代码模块。此时，管理者可以看似若无其事地在他们工位或茶水间附近溜达，听听他们对开发规范的评论，观察他们实际的工作行为，体会他们的难处，思考背后的原因。然后顺应他们的心理，用大胆假设，小心求证的科学实验方法，把软件开发规范规划得能让他们在工作中，自然而然地做出能提升产品质量和用户价值的行为。
注意，这个过程只能使用助推。要从管理者抛弃机器化软件人假设的观念，并做行为助推规划开始。此时*切忌强推*。切忌。
什么是助推？什么是行为助推规划？为何强推不行？懂人心的软件开发还有什么内容？请关注之后的系列文章。
哪里能找到懂人心的软件开发的资料？
鉴于国内外软件开发行业主流，片面重视技术和过程，忽视软件人及其团队的心理特点和实际行为的现状，讨论懂人心的软件开发的材料少之又少。下面列出6本书我读过且认为较好的书籍，供大家参考。今后的文章也会不定期推荐一些好的材料。
因为相关研究成果和资料较少，要掌握懂人心的软件开发，除了读书，还少不了讨论，以及用科学方法做实验，以便在企业内验证一些助推软件开发的假设。只有用科学方法亲身提出问题，形成假设，做出预测，做实验验证预测，并根据实验结果进行迭代，才能实现懂人心的软件开发。
如有兴趣参与讨论和做实验，请把你的微信号发我邮件wzb@wuzhenben.com，*邮件标题注明“懂人心”*。我会拉你入群，一起用科学方法，探索和实践懂人心的软件开发。
本文*欢迎转载*。转载时*请不要*修改文章内容，并在文章开头*注明*以下文字：“懂人心的软件开发：不现实的机器化软件人假设；作者：吾真本；邮箱：wzb@wuzhenben.com”。
懂人心的软件开发还有什么内容？可以关注之后的系列文章。
