个人观点

1. 这样做，只是为了方便管理，但是效率性，可能达不到理想状态
2. 业务部门自己开发测试工具，开发之后，会更符合业务需求，并且需求沟通，会比较顺利
3. 统一提交到技术部，可能会存在需求沟通障碍，毕竟，技术部，也不懂业务，只懂开发
4. 就好比，把家里的早餐，中餐，晚餐，全部外包出去，做成什么样，全凭外包良心，哈哈，谁也给你加了什么，谁也不知道会做什么菜色给你

稳重向好

越来越好

技术最大话事权的都这么不靠谱了，不是工资很有吸引力的话，建议赶紧跑

还能咋地 自己卷起来，卷到那个技术部门受不了，你就能去这个技术部门了，你想要业务精通，你就继续钻你的业务

拼命给技术部工具找各种问题，找到他们放弃

如果我是做业务的，我会点技术，利用业务时间开个工具提升我自己的测试效率，这还不行？

• 好
  • 全局效率更优，专业的人做对口的事情，不容易被其他事情分心
  • 不同团队的职能更加单一更容易管理
  • 需求集中到工具部门，可以从全局决策集中投入人力搞，同时工具的收益更容易被量化
• 坏
  • 破坏整体技术氛围，有综合诉求的人才会加速流失
  • 工具部门无法以同样优先级支持不同业务线的特殊需求，所以更倾向于选择通用需求或者核心部门的需求去做，一方面通用就是不好用，另一方面总有业务线的需求不受待见

具体要看公司发展到什么阶段，要 case by case 分析。如果公司只是很早期的阶段，这样做无可厚非，因为人本来就少，业务线内部重复建设再浪费一些人力确实在 CTO 眼里是不合适的。如果是其他阶段，说法又不一样了。

很多大公司都是这样的，有一个底盘支撑团队，负责各种中间件，或者研发流水线 cicd 之类通用工具的开发
业务部门只要会用各种底盘团队的工具写业务代码就行了

这个技术部门有点像技术中台部门，我目前所在厂的每个事业部都有这么个部门，主要负责各类流水线和软件公版、测试开发等活，但是业务部门也会配相应的开发，对接公版需求和落地业务等。

很好啊，技术的归技术管，业务归业务管。想做技术就卷到技术部门去呗。