引言
中臺是最近兩年纔出現的組織架構形式，一種新的組織架構形式必然會帶來協作方式的改變。本文將介紹伴魚技術中臺在發展過程中，技術中臺內部以及技術中臺與業務部門之間協作方式的探索過程，以及目前已經形成或正準備實踐的最佳協作方式。
高效做事，專業的人做專業的事
基礎設施平臺化是中臺化的基礎階段，伴魚技術中臺早期的時候，我們希望每個團隊都能獨立負責自己團隊基礎設施的平臺化，比如數據庫平臺由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 對齊
- 高效響應，研發體驗保障的關鍵
- 高效影響，值得一試的輪崗制度
- 高效調查，獲得最直接的研發體驗報告
並且，目前伴魚技術中臺通過上面的協作方式獲得了研發部門非常好的研發體驗評價。