一件偶然事件想到的软件责权匹配问题

近期有团队跟我反馈说他们团队一直在做通道和转发这类公共性质的组件，在需求密集的时候每个需求都需要他们团队修改，导致人力非常紧张加班非常严重，能不能把这部分工作交给各业务组件团队，他们只负责打分？

从架构设计的目的之一是为了节省人力角度来说，这个要求我认为是合理的，我们希望每个团队都能够端到端交付需求，同时一个需求尽可能减少需要参与进来的团队和人力。通道和转发组件除了基本设施之外，不可避免地需要了解一部分业务概念，换言之通道和转发组件内存在大量与其他组件耦合的数据，这在组件设计上似乎是不可避免的。从人力角度，多一个人参与需求就会多一份学习成本和理解不一致风险。我们可以要求业务组件去完成通道转发组件内业务相关的代码修改。从这个角度来说，我认为是合理的。

从架构守护角度来说，一个团队不能只打分而不负责。就是说，通道和转发同样是一个组件，组件必须有守护团队，守护团队只打分不负责的话，三个月之后就会演变成这个团队随意打分的局面，也就是我说的责权失配。我想强调的是：代码可以交给业务组件修改，但这个公共组件出现的所有问题，都需要公共组件团队去负责，必须有人为组件的长期演进考虑。从个人角度，可能觉得很难接受这个结果，“别人改代码改出的问题，凭什么我要背锅？”。我们是组件团队，不是特性团队，在都是组件团队的团队群里，为了守护架构，bug应该是守护者的责任。是不是可以具体问题具体对待？比如某个需求业务理解偏差导致的问题，是不是可以认为是业务组件的责任？我想你很难说清楚到底是软件本身（比如单一职责、分层设计等因素导致别人改代码改出问题）的问题还是业务理解的问题，扯皮也是成本，不如都算守护团队的责任。

那特性团队改出了bug怎么办？对特性团队谈架构守护是很难谈的，你不可能只有特性团队没有组件团队。有人会说，全部划分特性和领域之后，特性自然会包住软件的所有方面，我想说这只是理想情况，在资源受限的嵌入式环境，纯特性式开发导致的代码重复是不能接受的。目前我还没找到可行的发展之路，但既然已经有了特性团队，我们只好先做好功能隔离，保证特性是完全可关闭的；同时责权要匹配，业务组件要对组件架构有话语权，同时要对bug和长期演进负责。