引言
中台是最近两年才出现的组织架构形式，一种新的组织架构形式必然会带来协作方式的改变，下面介绍伴鱼技术中台在发展过程中，技术中台内部以及技术中台与业务部门之间协作方式的探索过程，以及分享目前已经形成或正准备实践的最佳协作方式。
高效做事，专业的人做专业的事
基础设施平台化是中台化的基础阶段，伴鱼技术中台早期的时候，我们希望每个团队都能独立负责自己团队基础设施的平台化，比如数据库平台由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 也是伴鱼技术中台文化的一部分，是伴鱼技术中台人必须做到的事情。
短期和临时的问题，通过当面沟通来解决是非常不错的方式，但是对于长期规划的对齐，就显得力不从心了，通过每季度的 OKR 对齐会是一个非常好的方式。伴鱼是通过 OKR 来进行目标管理的，每一个季度的开始，技术中台和业务部门的研发同事会一起讨论和对齐大家的研发计划，确定业务部门这个季度需要技术中台提供的能力和服务，技术中台也会提一些需要业务部门进行升级解决技术债的需求，一起推动公司的技术进化。
高效响应，研发体验保障的关键
快速响应是研发体验的关键指标，这也是伴鱼技术中台早期就决定确保做到的关键点。将一些长期和关键的要求变成文化，通过文化潜移默化的方式去影响大家是伴鱼在这些事情上的做法，所以业务优先是伴鱼技术中台文化的第一条。现在大家在碰到排期问题的时候，业务优先是第一条需要考虑的准则。
高效响应业务，业务部门就会更愿意通过技术中台的能力来解决它们的问题，而不是自己造轮子。技术中台的目标是提供企业级的复用能力，很多时候，提供企业级的复用能力不是最难的地方，难的是业务部门愿意使用中台提供的能力，所以中台高效响应业务，是研发体验的保障的关键，也是实现中台目标的关键。
高效影响，值得一试的轮岗制度
这是本文中伴鱼技术中台唯一还没有实践但是一定会尝试的机制。其实这是受到一个偶然机会启发的，有一次业务部门找技术中台借调一个工程师去支持一个紧急需求，差不多一个星期的时间。在这一个星期中借调工程师发现了一些共性问题，业务部门有一些地方没有采用技术中台最新的技术方案，导致一些最新的能力没有在业务部门发挥出来，这是我们非常不期望的事情。
目前技术中台和业务部门的沟通其实是非常顺畅的，我们所有新的技术方案也会实时公告给业务部门，但是业务部门的关注点在业务迭代上，通知与公告这一类的浅影响是很难推动业务部门进行升级的，而轮岗却是一种非常深度的影响方式。一个业务工程师和一个中台工程师交换工作岗位一个星期，业务工程师到技术中台部门工作，充分了解目前技术中台的做事方式和最新的技术方案，中台工程师到业务部门工作，如果发现一些技术债务，则将目前技术中台最佳实践告诉大家，通过这种高效、深度的影响来拉齐中台和业务部门的技术实践方式。
高效调查，获得最直接的研发体验报告
技术中台做得好不好，唯一的评价指标就是研发体验，就像产品做的好不好，用户体验说了算一样。前面的每一条都是提高研发体验的方法，但是研发体验好不好，这个需要研发同事来回答，所以我们决定做研发体验调查。
目前技术中台的研发体验调查每季度一次，通过在线调查的方式进行，技术中台所有的平台和服务以及一些关键的体验指标比如沟通和响应等都是调查的内容，研发工程师对调查指标进行评分，技术中台通过对收集的调查数据进行分析来发现一些需要改进的问题。
特别是对于一些评分比较低的情况，项目的 Owner 需要找到评分研发同事进行一对一的深度沟通来了解评分低的原因，如果是理解的偏差，那么通过沟通解决，如果问题确实存在，那么记录下来并且给好解决问题的截止时间。
每一期的研发体验调查都会形成一个研发体验报告在公司内部公布，目前伴鱼技术中台进行了第一次的研发体验调查，平均评分最低的项目得分为4.3（5分制），这是一个非常好的开始，能获得业务部门研发同事的认可，对于技术中台来说是最一件非常值得骄傲的事情，当然我们还会努力做到更好。
总结
由于技术中台和业务部门是独立的部门，所以保证技术中台能够真正实现提供企业级的复用能力的关键除了技术因素外，中台和业务部门的协作方式也是一个非常重要的影响因素，本文从六个方面来描述了伴鱼技术中台和业务部门的协作方式：
- 高效做事，专业的人做专业的事
- 高效分享，既是技术评审也是技术分享
- 高效沟通，当面沟通与 OKR 对齐
- 高效响应，研发体验保障的关键
- 高效影响，值得一试的轮岗制度
- 高效调查，获得最直接的研发体验报告
并且，目前伴鱼技术中台通过上面的协作方式获得了研发部门非常好的研发体验评价。