多产品团队协作及工程优化
在多产品阶段，跨团队协作和之前单产品会所有区别。不同产品团队之间的“距离”会更远一些，所以在系统设计上需要更高层次的一致性，而产品内部设计需要有一定的自由度。前面已经讨论了公共部分的设计问题。下面我们谈一下产品间的设计协作问题。
产品职责划分共识
多个产品团队需要从业务出发，确定好各产品和公共业务领域划分的原则。在原则的指导下便于更高效的沟通和决策，对于例外情况专门进行讨论，反过来优化划分原则。完成职责的确定后，再根据实际情况来确定具体由哪个团队来实现，以及后续的计划。
举个例子：商品的优惠信息开始只有原产品中使用，随着业务发展，发现新产品也需要使用。这时候根据划分原则，商品的优惠信息需要划分到公共业务团队来负责。但由于优惠信息和原产品的功能的耦合较多，无法在快速安全的抽离出来，所以本次迭代还是由原产品团队提供接口给新产品团队，同时将优惠信息抽离到公共的事项列入下个迭代的技术需求池中。
具体的职责划分可以从产品功能开始，产品经理一起参与讨论，确定业务边界。然后由前、后端的虚拟团队和各团队技术负责人一起讨论技术部分的划分原则。
甲乙方协作模式
在迭代过程中，不可避免的会出现跨团队的需求，有的可以在需求规划阶段识别，有的可能在设计或开发阶段才识别出来。原则越早识别越好，尽量在迭代规划阶段向需要协作的团队提出需求，否则进入迭代开发再提出，会对迭代节奏造成冲击，变更代价往往也比较大。产品团队间可以采用甲乙方的模式来进行协调，例如A产品需要B产品团队协作，由A产品经理（甲方）向B产品经理（乙方）提出需求，确定好产品和功能解决方案；A产品的开发团队（甲方）需要向B产品开发团队（乙方）提出技术需求，B产品团队完成接口规格设计后和A产品团队确认。完成设计后，双方就可以根据约定的接口进行开发了，开发过程可以使用Mock接口自测，完成后由A开发团队进行联调。同我们在多团队协作中提到的一样，接口提供方式需求保障接口质量和兼容性。
开发及发布协调
随着团队的进一步扩大，跨团队的协作增多，风险也随之变大，开发及发布的协调变得至关重要，延期和质量问题可能影响到多个团队，导致整体效能下降，严重的可能导致迭代失败。因此建议采用更加严谨的策略：
- 使用统一的迭代节奏，提前确定对接时间，避免多团队步调不一致导致的开发联调、集成测试、功能上线协调困难；
- 优先保障跨团队需求，重视对外承诺，避免对其他团队节奏造成影响，甚至导致连锁反应；
- 保障对外提供接口、SDK的质量，避免集成质量差、时间过长，导致团队相互等待；
- 强化代码质量，保持良好的代码设计，使用工具在CI/CD过程中自动化检测，有利于功能在团队间进行转移；
- 使用接口自动化测试，用于保持对外接口的兼容和稳定。
当系统和团队达到一定的规模，集成不可避免的会耗费很多时间，而且某个团队出现问题时，其他团队可能就需要等待问题处理完成后才能上线。如果每次迭代发布都要搞到三更半夜，战战兢兢，就需要考虑采用灰度发布了。一方面可以在灰度环境提前完成所有的上线动作，有更灵活的集成策略和更长的集成时间，另一方面出现问题也能减小爆炸半径。关于灰度发布的技术挑战和解决方案，我们后面会专题讨论。
