各团队间协同工作是常有的事，若协调的不好，那么对产品的输出会产生阻碍，要么是推迟上线，要么是携带bug的线上产品。最近有这样一种业务逻辑需求，它涉及到四个团队成员的开发，在这里我分别用A、B、C、D四个字母来代表四个团队，A团队是输出最终提供给业务需求方使用的产品，B团队是处理数据供其它团队使用，C团队是提供相关的数据结构和数据源给B团队，D团队是输出产品供A团队服务。
上面介绍完此业务场景的四个团队的分工，现在来说说平时是如何协同开发的吧，只要各个团队之间产生交互，各开发人员都会进行联调开发，将链路打通，形成各自的闭环；这样团队开发完成的模块就可以已微服务的方式或者组件库的方式供别的团队使用，这样A团队就可以完成一次自测的闭环。为了提高对于协同工作方式的效率，前提是各个团队之间根据业务需求定义好相关服务能力的接口，然后各个团队可以同时展开开发，彼此之间互不干扰，每当完成服务接口的开发都可以找需要交互的团队进行自测，将此段的链路调通，此阶段可以暂时不检验数据的有效性。等到一条业务需求的完整链路开发完成后，开发人员就可以进行此链路的闭环测试，这个时候就需要校验数据的有效性了。
以上是开发协调的基本流程，接下来说说测试验收环节。测试阶段是检验产品是否符合发布的最后一个环节，它把控着产品的质量，找出显性或隐性的缺陷，以便产品带修改后可以满足正常发布的条件。若是在上述四个团队协作的场景中，谁担任测试职责呢？正常来说，应该来说谁真正接触客户，谁就该担任测试职责，来监管产品的质量。在该场景中应该由A团队抽出人力来担任测试职责，他们即对业务需求有所掌握，同时也对数据源把控，可以根据真正的业务需求场景以最真实的输入来检验产品的最终输出结果。若对结果不满意或者结果没达到需求的验收标准，那么可以否决这个流程达标了，立刻让开发人员修补。若模拟的输出结果已满足了需求验收标准，那么恭喜各团队已经完成了对该流程的使命。
目前在团队中有个不足的地方是A团队的测试人员没有把整个流程进入深度测验，只是测验了A团队自身开发的一些功能，这样的坏处是若产品上线（当然是B、C、D团队已经在同一个时刻上线了）后会含有其它团队没有被暴露的问题，那么这就相当于是在产线来测验产品质量，这种方式极不合理，也是必须要禁止的，先不说成本高，就单单说工作态度和方式，就不够端正和流程混乱，这样的团队leader是及不合格的，需要负担起产品质量问题的责任。若leader让团队这样玩，那只会输出失败的产品，这样的团队离over也就不远了。
每一步都无愧，人生才能无悔。
------20191215闪