流程规范应该按照公司统一的吧，这种我理解就是虚线管理，我了解到的大多公司现在都是这种方式，至于个业务之间的协调配合建议项目经理协调，我司目前是这样操作的，所以不会出现不配合的情况，质量按各自业务划分就好了啊

唉，某度某部门刚这么拆的，各有优劣吧，我理解就是瞎折腾，谁有话语权谁喜欢哪样就搞成哪样。

测试应该统筹分配，统一管理，否则光是测试之间的扯皮就很耗时耗力

虽然在组织架构上还是一个，但是实际上根本不会 care 另外组的测试，在人力协助，问题沟通上更加如此，基本上都是各自有各自的规范

这个的关键就是你们部门 leader 怎么做跨组的沟通协调了，比如一起早会、周会啥的保持跨组沟通和信息同步。每个组自己的组长肯定首先关注自己组的利益，而这些跨组共同利益必须由部门领导来重点关注指挥。

这样拆分，就算是部门 leader，也肯定会优先自己组内的工作。这种模式，有问题，甩锅项目经理，叫他去协调。

之前我们老大说，每个测试人员应该有自己主要负责的项目或者自己主要负责的测试类型（比如专项测试、性能测试、接口测试等），这样工作干起来才有意思。后面我才 get 到这实际是在培养测试人员的 owner 意识。但是这并不代表其它的项目或者其它的模块或者其它的测试类型你就不需要关注了。其它项目或者其它模块可以通过交叉测试或者团队 bug 大扫除的形式去保障测试工作的完整性。这样测试很好，那样测试也不差，我觉得可以集百家之长，把项目干好，而不是相互扯皮推诿。

业务没划分好吧。。。正常来说独立的业务相互甩锅可能性不大

噢 最近我们也在转型 你说的各自玩各自的解决 我这边是统一出一个基层的敏捷流程规范 然后各条业务线遵循这个最小化规范去执行 可以在一定的范围内定制 同时测试还是属于一个大的团队 划分业务线去进行支援协调

都一样，但是我们测试的 leader 还不放权，各种插手各个敏捷小组的测试，相当于测试不仅要做敏捷小组的工作，还要做这个测试 leader 安排的工作，导致大家怨声载道，像敏捷教练投诉吧，敏捷教练也没有办法，因为测试 leader 是老板心腹

我公司现在碰到的情况和你类似。
如果业务不独立有耦合的话，这么搞问题很多，但是上头领导发话了，也只能尽力去协调配合。最终的结果就是突出一个心累、效果差。
主要问题就是出现在跨小组配合下。随便举几个例子：开发被其他小组借用，因为之前是他负责的这块，导致定好的内容延期；测试内容跨小组时，对测试的压力非常大，经常有漏测的情况出现；基础服务、刷数等内容，经常某个小组处理了，另一个小组没处理导致 BUG 甚至阻塞测试进度。
还有很多吧，就不一一细数了。
我非常不推荐在业务不独立的情况下搞敏捷小组，效率没有提升，反倒将信息封闭成了一个个孤岛。

这些都是阶段性的，放宽心。认真做好自己，别人甩锅过来，接就好了，解决掉能力范围内的问题，尝试解决能力范围外的问题，解决不了，及时抛给领导，领导不接再抛回去。正所谓，不在其位，不谋其政。心累还是考虑了不是自己范畴的事，再说目前的境况又不是你造成的，我们说应该怎么或怎么怎么，喊你去改规则也不合适，都比不上你的自我调节。调节好了，就不心累了。。

个人习惯与层主比较类似。不在其位，不谋其职，不担其责。当然不是说全部逃避不管，能解决的问题肯定要解决，但是解决不了的问题，不属于自己的问题肯定要及时向上反馈抛回去。