流程是双刃剑，大家都知道。流程的本质，我的理解是通过建议规章约束把最初的用户愿景以最短的路径且高品质的传递给工程端，并由工程端高品质无差别的高品质交付。重要的是交付链条足够短，交付品质足够高。

但流程提效，正确的角色是辅助，不应该是ADC。咱们诺亚前面遇到了很多问题，迫于压力，只能把流程提效和工具提效的角色互换，通过抑制需求，解决故障多的问题。在当时的场景下，是必然也是最优解，这毫无疑问。短时间行，长时间不行。如果要做互联网产品化的金融，要改的地方很多。虽然公司在oa改造发力很多，但要努力的地方还有很多。诸如oa这些的，咱们CICD流程相对完善，但要做的还有很多。比如，发布日的art项目已经推送到平台，代表已经过审，但仍要逐项目举手，意义真的很重要？项目提测的关闭窗口总在变，更没人严格执行，原由很简单，人员变动太，文化没有被传承。但这是各公司都会存在的问题，所以有很多伟大的技术产品出现，解决了很多工程学中人为因素的难题。比如git解决了版本控制，比如springcloud解决了java开发的架构拓扑能力。k8s解决了运维的高可用，高并发，扩缩容的架构能力。

工具提效，在传统公司越来越被重视，但重视度有待商榷。真正伟大的公司在技术和文化的投入是很舍得花钱花时间。

工具提效讲究两点：做的人要懂，更要执着。

从问题中来，最终回归到问题中去。做的人在问题中深受煎熬，最后受不了，跳出来，做了一套工具，甚至一套解决方案，解决了公司痛点，甚至行业痛点。像 Ansible，slatstack，jumpserver，k8s 等工具都是一样的，他们提供的解决方案被行业接受，所以也能得到社会的回馈。

我们现在使用的成熟流行工具都有一个特点：好用。但公司级的产品不一样，cicd，art等还在路上，功能都有，好用和精品有待商榷，但这不能怪我们的团队不行。公司要舍得投入钱和时间，为啥饿了么送外卖的公司，都能在前端变化万千的产品线中做出element 和 ant、vue抗衡，那也是有原因的，值得花大价钱从行业招专家。当然，各家公司有自己的定位，要视自家特色解决问题。个人觉得，我们还是缺懂运维产品的人。