一个问题引发的思考模式的探讨

今天又是一个点引发的讨论

事情的经过是这样：

开发小组因为用git提交代码，覆盖的同事提交的代码，导致上线后出现bug。

对于这个问题，我的思考逻辑是这样，首先需要团队内部沟通，当出现合并代码冲突时候，需要仔细操作，不确定时候找冲突的代码作者一起讨论，如何进行合并，或者反馈给自己的主管。就是通过仔细对待，来避免类似的问题再次发生。

但是这个问题不止一次出现，是反复的一个出现。因为新人是会不断的进来。所以就想到了通过发研发公告文件的方式来解决，通过企业级别的公告文件，来将合并代码遇到冲突如何解决的事情文档化，再有新人时候进行培训解决。

但是这个事情到了领导这里（领导不懂技术），那就不是这种解决方式了。

领导信奉的是，人都是不靠谱的，这个事情能不能流程化，建立流程机制，通过打造一个流程体系来解决。

比如：

遇到合并代码冲突的时候，直接就拒绝提交成功，必须先合并到本地，解决冲突了才能提交。

遇到合并代码冲突的时候，立马触发消息推送，给相应的责任人，主管发送消息推送，让主管第一时间介入。

就是把这个事情的解决不依赖于每一个员工，而是流程，流程规定了在遇到冲突的时候必须要按照某一个要求来，不管说是解决冲突了才能合并还是说必须要通知到主管，主管介入了才能继续往下走，这里的思路就是不局限于以前对这个工具的熟悉，可能以前都是提交人自己来解决的，有了这个惯性依赖，现在就是需要通过流程来限制，最大程度的减少这个导致问题发生的频率。

思维的方式就是：

发生问题-分析问题-找到原因-解决这个问题

发生问题-分析问题-跳出问题-找到根因-解决这个问题-解决其他问题

这里就是存在本质的区别。

造成这个本质区别的原因也是在于只是为了解决当前的问题，还是说想要深挖，找到深层次的原因，然后通过流程和机制来解决问题。

始终把团队的管理，组织的管理放在要考虑的重要位置。