引言
中台是最近两年才出现的组织架构形式，一种新的组织架构形式必然会带来协作方式的改变。本文将介绍伴鱼技术中台在发展过程中，技术中台内部以及技术中台与业务部门之间协作方式的探索过程，以及目前已经形成或正准备实践的最佳协作方式。
高效做事，专业的人做专业的事
基础设施平台化是中台化的基础阶段，伴鱼技术中台早期的时候，我们希望每个团队都能独立负责自己团队基础设施的平台化，比如数据库平台由 DBA 部门来负责建设，但是在实施的过程中出现比较多的问题：
-
招聘很难，招聘研发能力强的 DBA 是不容易的，很难碰到合适的人，如果招聘研发能力比较勉强的 DBA 来做平台化，那么平台的质量很难得到保证；
-
如果直接招聘研发工程师到 DBA 部门，但是数据库平台的开发不是一个需要长期不断研发的事情，一般是阶段性的研发需求，会导致的阶段性的人力过剩；
-
特别是如果招聘的是经验比较浅的研发工程师，那么他们的培养与成长也会是一个问题。
经过一段时间的摸索后，我们通过临时项目组的方式解决了这样的问题，DBA 做产品经理和项目经理，负责数据库平台的产品设计工作和项目管理的工作，在技术中台内部统一协调研发工程师来参与项目，项目完成后临时项目组解散，待下一次平台需要迭代的时候再重新组建项目组进行开发。
这样充分利用了 DBA 在数据库平台方面的专家经验，并且 DBA 是平台的使用者，所以数据库平台的产品形态和产品体验都是有保障的；让研发工程师来负责开发，并且研发工程师的 Leader 也会参与项目的讨论，这样平台的研发团队的专业性和质量都是非常有保障的；研发工程师由部门的研发 Leader 来管理，对研发工程师的成长与培养是有保证的。
通过上面的方式，确保了专业的人做专业的事，伴鱼的平台化推进的非常迅速和顺利，目前技术中台除了数据库平台外，运维方面的 CMDB 和 Paas 等平台都是按这个方式做的协作的，非常高效和高质量。
高效分享，既是技术评审也是技术分享
在伴鱼我们要求技术中台打造公司的技术氛围，做技术分享是一种很好营造公司技术氛围的方式，但是选择分享什么样的主题是一个很关键的地方，如果业务部门的工程师对分享的主题不感兴趣，那么大家要么不参加，要么参加后感觉没有收获，不管怎样都是一件非常浪费时间的事情。
在技术中台的发展过程中，我们发现研发工程师对于和他们非常相关的平台或者服务的技术评审是很感兴趣的，这样我们就找到切入点了，通过提高技术评审的质量，将技术分享融入技术评审，同时达到技术评审和技术分享的目的。
现在在伴鱼技术中台，每一个新项目的开发流程是这样的：
-
项目的 Owner 负责调研国内外一线大厂的方案，特别是 Google、Facebook 等大厂的论文，然后结合我们的需求，形成技术方案的初稿；
-
项目的 Owner 在组内进行技术评审，不论是作为技术评审还是技术分享质量都需要达到要求，才能算组内评审通过；
-
在公司范围内发起该项目的技术评审，邀请大家来参加，由于是研发工程师非常关心的主题，所以大家的参与度会很高，并且技术评审又兼顾了技术分享，大家可以充分的讨论和交流，使得同时达到技术评审和技术分享的目的。而且良好的技术分享质量会建立起口碑，后续的技术评审业务部门研发工程师的参与意愿会更高。
-
到这里还没有完，还有一个非常关键的部分，项目做完后，Owner 需要写一篇文章来对这个项目进行归纳和总结，这篇文章会放公司的技术博客上面，也会在公司范围内分享。
高效沟通，当面沟通与 OKR 对齐
技术中台和业务部门是两个独立的部门，业务部门需要依赖技术中台底层能力的支撑，所以如果技术中台和业务部门的沟通不顺畅，那么将是非常严重的问题，也很容易导致业务部门重新造轮子而导致技术中台的价值得不到体现，这将是技术中台部门最大的失败。
伴鱼技术中台在建设的过程中，我们对外非常鼓励业务部门的同事当面来反馈问题，对内强调 Feedback is a gift，确保技术中台和业务部门沟通流畅，通过沟通来解决问题。Feedback is a gift 也是伴鱼技术中台文化的一部分，是伴鱼技术中台人必须做到的事情。
