作为企业IT部门某个开发团队负责人的你，从书上和大佬那里得知，软件开发团队中的开发人员，如果在将所完成的功能提交给测试人员之前，加强自测，那么就能降低软件开发过程中的返工。
于是你为每位开发人员，都准备了自测环境。然后告诉开发人员，在完成功能的开发，向测试人员提测前，需要在自测环境完成自测。
但很快你就发现， 测试人员还是经常抱怨，开发人员即使拥有自测环境，但所提测的代码，经常连基本的功能都没有跑通，需要打回去修复。
这个问题该如何破？
你读了塞勒和桑斯坦的《助推》，其中行为经济学的“锚定效应”和“心理账户”给了你很大的启发。即开发人员对于自测的态度，被其岗位名称“开发”所锚定，即“开发”意味着设计和写代码，而“自测”属于测试，应该由测试人员负责。这种锚定效应会带来“心理账户”效应，即开发人员设计和写代码的时间，与修复包括自测在内的测试所发现bug的时间，分属两个不同的心理账户。在开发阶段，他们不会使用修bug阶段的账户里的时间。
如果把“开发人员”和“测试人员”这两个岗位名称，更名为能反映整个软件系统的质量的名称，是否能破解上述问题？
如果将开发人员的岗位改名为*系统红军*，即需要对所设计和编写的软件特性在整个系统中正常运行负全责，而测试人员的岗位改名为*系统蓝军*，即从整个系统的角度模拟现实生产环境各种*刁钻*的场景来*考验*系统红军所设计和实现的软件特性，能否正常运行，那么这两个岗位之间的关系，就转变为红蓝军对抗。这样是否能摆脱锚定和心理账户，从而助推开发人员进行自测？
你觉得可以设计一个实验，来找到引导开发人员做好功能自测的一种方法。
该如何设计这个实验？
我在下面帮你列出这个实验的6个步骤和具体实施方法。你可以根据团队具体情况，*做适当的调整*。
1 基于观察
测试人员经常抱怨，开发人员即使拥有自测环境，但所提测的代码，经常连基本的功能都没有跑通，需要打回去修复。
2 问出问题
是什么阻碍了开发人员进行自测？
3 形成可验证的解释性假说
根据行为经济学的“锚定效应”，开发人员对于自测的态度，被其岗位名称“开发”所锚定，即“开发”意味着设计和写代码，而“自测”属于测试，应该由测试人员负责。这种锚定效应会带来行为经济学的“心理账户”效应，即开发人员设计和写代码的时间，与修复包括自测在内的测试所发现bug的时间，分属两个不同的心理账户。在开发阶段，他们不会使用修bug阶段的账户里的时间。
4 基于假说做出预测
如果将开发人员的岗位改名为*系统红军*，即需要对所设计和编写的软件特性在整个系统中正常运行负全责，而测试人员的岗位改名为*系统蓝军*，即从整个系统的角度模拟现实生产环境各种*刁钻*的场景来*考验*系统红军“所设计和实现的软件特性，能否正常运行，那么这两个岗位之间的关系，就转变为红蓝军对抗。这样就能摆脱锚定和心理账户，从而助推开发人员进行自测。
5 设计并执行有对照组且只改变一个变量的实验检验预测
你需要设法吸引IT部门负责人和测试团队负责人对这个实验感兴趣，并获得她/他的支持，比如帮助你找到另一个有同样多开发和测试人员的开发团队作为*对照组*，并获得那个开发团队负责人的支持。而你所在的团队，可以作为*实验组*。
由IT部门负责人、测试团队负责人和实验组与对照组这两个开发团队负责人，四人成立实验小组。
为了让实验结果不会因为实验组和对照组两个开发团队的开发和测试人员，因相互攀比而有损数据的准确性，该实验*从始至终秘密进行*。即实验的事情，只有实验小组的那四人知道。若其他人问起实验过程中一些事情的缘由，可以编一个理由。总之不要透露正在开展的实验和实验意图。
在实验开始前，两个开发团队的负责人，需要各自保证开发人员都拥有自测环境，并准备好度量开发人员自测一次通过率的观测工具。即能统计出开发人员开发完功能，次给测试人员测试且一次通过的比例。
对照组对于开发和测试人员的岗位名称保持不变。对照组团队负责人在实验开始前一天，召集所有开发和测试人员，告诉他们在完成功能的开发，向测试人员提测前，需要在自测环境完成自测。
实验组团队负责人，就是你，在实验开始前一天，召集所有开发和测试人员，向他们宣布，在本开发组，开发和测试人员的岗位，在未来一段时间内，比如6周，分别改名为*系统红军*和*系统蓝军*。并告诉他们，系统红军需要对所设计和编写的软件特性在整个系统中正常运行负全责，而系统蓝军需要从整个系统的角度模拟现实生产环境各种刁钻的场景来考验系统红军所设计和实现的软件特性，能否正常运行，
设置一个开展实验时间段，比如6周。两个团队同时开展实验，并同时采集数据。
每2周作为一个迭代。实验小组在迭代末就开一次碰头会，分析和对比这2周采集的观测数据。
6 根据实验结果可回到第3步不断迭代优化假说/预测/实验过程
到第6周结束，总结和对比这3个迭代实验组和对照组的数据。根据实验数据，看看是否支持第4步的预测，并决定是否回到第3步，改进假说、预测或实验过程。
如果遇到问题，欢迎在评论区留言，与我交流。*非常欢迎*你把实验的步骤、过程和结果分享给我，以便一起*改进这个实验*。我会在这个实验的将来的版本的致谢段落，*署上你的名字和你所做的改进*。
如果觉得本文对你有帮助，欢迎*点赞*，并*转发*给其他志同道合的小伙伴。你觉得引导开发人员做好功能自测，还有什么其他好办法？你还希望我聊有关做软件的其他什么新话题？欢迎在评论区留言。我会仔细阅读每一条留言。期待听到你的声音。
企业生意好，系统运行稳。你所阅读的文章，来自“吾真本说混沌工程”知乎专栏。
