智能造车软件研发是一个高度复杂的工作场景，有些复杂的功能开发涉及的链路会特别长，动则涉及三五个跨域的团队，团队之间的逻辑高度耦合，而每个团队内部又另有复杂的逻辑链路。
这样的复杂的链路开发，很难找到既懂全链路业务，又是各域技术专家的全才大牛。所以，在方案设计时我们通常会让功能发起域作为主域提供总方案负责人，其他关联域又称之为对手件则提供相应的方案负责人辅助配合。
这种场景，在敏捷团队中其实常常会存在，架构或技术方案由团队成员共同打磨完成。共同的意思并不意味着每个人都同等地参与，而是由主要负责人牵头，其他人根据各自的背景和能力提供不同程度的输入，帮助主负责人进行最优方案的打磨。因此，敏捷宣言中的十二原则才会提到：最好的架构、需求和设计出自自组织团队。
针对前面提到的汽车软件功能长链路开发，我也理所应当地带着敏捷团队自组织分工协作的印象，默认在一个团队已经有一个主域方案总负责人的情况下，团队产出一份优秀的方案应该不是什么难题。
今天临近下班时刻，正当我集中处理完一大波工作任务，稍微得以喘息的时候，迎面碰上了愁眉不展的小翠。细细问来才发现，原来她刚刚结束了一场艰难的会议。而这场会上，伙伴们正是为谁应该完成一个新项目的方案设计争论不休，而这个项目的情况正如前面所说，需要集跨域团队的智慧和力量，才有可能打磨出可靠的方案。
无奈小伙伴们还带着传统知识型组织的深刻印迹，即每个人的工作责任边界都应该被定义得清清楚楚，明明白白，并且，他们的工作任务都应该有非常明确的流程定义；同样的，一件事情就必须有确定的责任人独立承担。这样一来，在没有找到全能大拿的情况下，就无人能挑起全链路方案设计的大任了。但项目又有明确的交付预期目标，小翠感觉压力很大，但一时又无计可施，只得先结束会议，让团队成员各自冷静后再做打算。
在听完小翠的吐槽之后，我们一起梳理了一下这个项目链路上核心技术域、对手件域以及它们之间的依赖关系，其实我们很快就发现了谁应该负责哪部分，以及伙伴之间该如何配合。看来，小翠需要找到一个办法让小伙伴们真正理解并接纳在复杂项目中并不存在所谓的泾渭分明的责任划分。这也是为什么我们在敏捷组织中总是强调责任共担。
期待小翠明天有好消息。
