修炼4： 一个万能的按钮

这个项目的客户是法国三大电信运营商之一，作为当时最热的科技话题——3G网络正在强势席卷全球，堪比现在炙手可热的“大数据、云计算、人工智能、区块链、元宇宙”。

我所在的团队，日常工作是对3G网络进行系统的规模化测试。团队有7、8个人，基本上都是通信专业背景，工作就是撰写对“内测版”3G网络的测试，保证仪器设备将来联网后符合通信功能要求。

而我是唯一一个程序员。团队的小伙伴们管理着几百个网络设备，几千个测试脚本，每天产生上万条测试日志。而每天的测试日志报告都在一个“result.txt”文本文档里用文字记录着。整个团队每天花将近一上午的时间，分析这个测试报告，从密密麻麻的文字中，找出哪些测试挂了，哪些设备可能有问题，然后再手动对设备进行调试验证……

看了一眼那个几分钟都翻不到头的“result.txt”文档，我隐隐约约明白为什么需要程序员思维了。

“昨晚上的测试结果显示，跑了6772个测试。有3千多个没过。”Fouzzi指着文档末尾的一行记录说到。

“没过的那些测试，接下来要怎么处理呢？”

“我们要通过关键词去搜索，记录是在文档的哪个位置，去搜寻一下当时的执行记录有没有帮助……实际上，我们这一步经常直接跳过，翻看这么个又长又复杂的文档还不如直接去仪器上操作看有没有问题来得快。”

“所以这个测试和这个报告并没有给多大帮助。”我觉得Fouzzi和这帮同事还蛮辛苦的。“但是起码报告能够告诉我们，哪些测试挂了，总也有点用嘛。”

“兄弟，我搞网络搞了这么多年了，记住我说的，网络，他是活的。”Fouzzi认真地对我说。“我们执行的测试，有的是因为网络问题，前一分钟是好的，这一分钟就坏了，下一分钟可能又好了。也有的是我们的测试脚本就有错，也有可能执行的方法不对，只有最后都排除了，才可以确定，是否是仪器真出了什么故障。

“所以，我们的梦想是，就按下一个万能按钮，我们的测试会自己去运行，什么网络不稳定啊、系统不稳定啊，它都能够自己绕过去，因为误操作犯的低级错误，它能够指出来，最后哪些是真正的故障，它告诉我们是哪里有问题，直接发给对应的负责人员手里。网络环境、误操作、故障都难不倒它的一个万能按钮。“

Fouzzi说完这么多，自己都笑了。“我是开玩笑的，我知道目前肯定不现实。”

“一个万能的按钮。”后来也成为了我们经常半开玩笑、半当真的口头禅。

我很喜欢这个项目经理，他的目标很清晰，但也能够清晰的控制自己的预期。

我之所以如此详细地介绍这个项目的背景，是因为我觉得用这个例子可以说明一下程序员思维可以解决一个什么样的问题。

十多年之后，也出现过类似“我要五彩斑斓的黑。”，或者“我想要手机壳跟随着屏幕的颜色变色。”这种看似荒唐的需求。

但是我觉得比起那时候的”万能按钮“来说，应该不算什么。

开玩笑归开玩笑，我依然傻傻地把这个玩笑话当成了目标。

在开始准备写代码的时候，我并没有直接开始写功能，而是对不同的“模块”进行分解，让各个模块负责不同的任务，花了一个上午在A4纸上自己画了一遍，并没有任何的设计思维来指导，只是凭着感觉梳理了第一个版本的框架，后来发现原来这叫做写架构。

之后，在上面一步一步地叠加或者拆分，慢慢长出来了各种版本。

第一步，能够执行所有的测试，并且对测试结果进行统计，放在一个”.txt"文档里。

这个阶段只是完成了对原来就有的功能的梳理和重构，我并不愿意在原有代码的基础上改动，这样花的时间还多一些，干脆重新写就好了。

第二步，把“.txt”的文档改造成“.xml”，这样每个节点就是一个测试，测试的属性有执行时间，执行结果。

在这个阶段完成之后，我每天试跑一遍，中间总是因为某些测试中断而导致所有的执行中断，手动继续之后，最终也能形成一个完整的xml文件。我又找了一个比较好的xml文件的编辑器，给同事们的电脑安装上，查看测试的结果就方便了很多。起码有了图形化的界面，比翻看原来的txt要好多了。

第三步，如果测试执行时出现问题，那么尝试重新执行一次，把报错信息记录下来，以及返回值等等。

这个阶段比较痛苦，需要与各种莫名其妙的测试报错斗争，盯着几个小时的测试运行等着看哪里报错是常态，好在报错后自动重新执行一次的功能最后也完成了，运行稳定了许多，后来扩展成为三次容错之后，基本上几千个测试能够稳定运行了，发现了几十个错误原因，知道为什么错就好办了，后来错误信息也得以收集。有种柳暗花明又一村的感觉。

第四步，每天晚上自动执行测试，执行完成后，自动把xml文件发送给大家。

既然大多数时候能够稳定运行，执行自动化测试也就常态化了，已经能够晚上无人值守的自动运行了。每天上午，大家到办公室的时候，邮箱里也就稳稳地躺着那个xml文件。不仅能够很清晰地看出来哪个测试报错，什么时候报错，错误的原因也明明白白地标注在旁边。

做到这里，按照最初的设想，工作已经妥妥地完成了。如果细究的话，完成得更远，因为连万能的按钮都不需要按，全部自动化进行。这里时间只过去了一个半月，离最初报的3个月，只用了一半的时间。剩下的时间怎么办呢？

Fouzzi说，你自己想想呗，上上网摸一下鱼也无妨啊！（请问哪里找这么好的PM？？）只是不能告诉客户我们已经做完啦！完成的工作只能有计划，有节奏的慢慢抛出来，不能一下全抖出来。

这个观点在后来的项目经历中，我经常与小伙伴们提到：作为项目经理，手里要存一点“货”，因为总有意料之外的事情发生，进展时有会不如意，这时候需要一个缓冲池来释放一些进展来稳定甲方或者需求方的信心。而平常的时候需要内部积攒一些进展，但这些进展“不能让外部人知道”。这么做的本质是管理甲方的心理预期，项目上经常有两个甲方心理预期需要控制：

第一个想象，效率会无止境的递加。甲方或者上级会单纯的以为今天团队完成了10个点的任务，明天团队应该就能完成11个点的任务，效率稳步逐渐递加。没有递加那么表明团队就开始懈怠了，或者没有成长了。就好像一个鞭子无形之中一直在后面抽打一样。

第二想象，单位时间总会有产出。其实有些技术债需要还，有些看不到的东西总是需要做，或者团队成长需要尝试新事物，即使失败也值得。但这不符合甲方的利益，甲方需要的是能干活的人。我付钱给你干活，你的成长，为什么要花我的钱？但是从本质上来看，这与团队利益是矛盾的。

因此如果甲方固执地坚持这些心理预期，那么为了权衡团队利益和甲方利益，那么只能管理“存货”和“进展”。

这里或许与敏捷理念矛盾了，敏捷不是要强调反馈吗？不是要透明吗？怎么可以暗箱操作呢？

当然我们希望能够毫无保留地坚定立场，但是实际项目中的客户关系和信任是需要经营的，就像夫妻或情侣之间的感情需要经营一样。

条件允许的话，余量和提前量是需要控制的。我们希望能够有一个平稳的节奏输出，这样无论对哪一方都会有好处。

在摸鱼摸了两天之后，我总觉得哪里还距离这个万能的按钮还有很大的距离。xml文件固然很好，但是可不可以更好呢？于是我又花了一段时间把xml做成了html，做成了网站，加了自动生成的饼状图，柱状图，曲线，表格等等，我还不甘心的加上了动画特效，甚至Linux下执行命令的命令行，我都做成了皮卡丘的动画头像来交互式对话……

这时候回头看看之前的xml，已经完全不是一个概念的产品了。团队其他小伙伴已经完全成了忠实用户。

没有人让我做这些啊，我为什么做这些呢？

闲的。

所以闲下来是第一生产力，让团队闲下来，是让团队升级的最简单粗暴的办法。想要做一个万能的按钮吗？那先让团队闲下来。