从具体技术问题看流程和管理的问题
今天上午9：38在微信群里看到团队内做脚本调试的同事小w和一个开发的对话。
是说发了一个报文，结果失败了。于是就问这个项目组A的开发小a，小a一看，这不是项目组B的错吗？
这时是10：00：于是就@了项目B的小b；小b一看，唉，这不是项目组C的配置没加上嘛，于是 就@了项目组C的小c。
这时是10：17：小c一看，我靠，真没参加这个渠道的配置。于是立即加上了。
这时是10：32：小c说，加好了。
于是小w就再调了一次，一看，咦，真通了。于是群里回复了一下，通了！于是大家都放下了问题，说，接着调下一个。
这时是10：38。
上面的流程是不是看着团队间的合作妥妥的？一点没耽误，对不对？大家工作都很努力对不对？有人一看我这样问，就觉得，嗯？哪里有问题吗？又仔细看了一遍。哈哈。
从worker的角度看，那是肯定对！做事情的没有耽误，是谁的问题都没有推托。从做事情的人的层面看，确实大家都是尽责的人。
但是，为什么没有配置呢？这才是问题的关键。于是我上楼把项目组A、B、C的人都拉到一起，问为什么这个配置没有？这不应该在部署的时候就有的吗？这个是项目组C没有配置，而项目组A、B为什么部署之后不做连通性测试就交到性能组手里呢？
所以要问清楚这几件事。项目组A、B表示他们能部署完就已经是紧赶着的了，根本没时间验证。而项目组C需要去查他们的部署过程为什么这个增量里的内容在四个环境中的其他三个环境都有，唯独这个环境没有。聊了一圈，是项目组C的工作失误，并且他们部署完也没有检查。
于是从流程上需要做如下增强：
- 规范部署动作；
- 部署之后的要有check list；
简单地示例如下：
这样就可以确保以后不会有遗漏。要有人说，那如果这样也出问题呢？这种情况当然是存在的，但是如果项目组A、B、C都出现问题，我觉得这种可能性还是小了很多呀。
那为什么以前流程上没有这样的步骤呢？那就要再追制定和管理流程的人了。客户说也表示他们的配置管理、部署规范现在都处在混乱的状态，没有正规的流程来制约。他们将把这样的事情作为后续的流程规范的重点来做。所以第3点是：
加强流程规范。
流程是要走项目级announce的方式的。不然一个项目组做好了，其他项目组也会有类似问题。
所以测试过程中发现问题，解决问题，只是一部分工作。还需要的是要尽量让同样的问题以后不再出现，这才是关键。
就这么个简单的事情，我上午就沟通了一圈圈。
紧接着，项目组A又出现了一个配置缺失的问题……
于是，我这个问题我就要报风险给他们的综合部了。让他们从 Project Managment 的角度来负起责任来。
