我們可以將R&D效率團隊的工作邊界定義為(需求管理+任務管理+項目管理)平臺+devops+APM+應用運維，負責從用戶需求到上線、應用運維的全過程。它的存在是為了打破團隊四分五裂各自為戰的局面，同時可以集中各個團隊的需求，使整個開發活動順暢高效的運行。R&D效率團隊壹旦和某個團隊在壹起，就沒有更高的眼光去思考這件事。如果業務方向控制得好，業務可能會誤入歧途。R&D效率接近的團隊會專註於團隊的業務，服務團隊的功能會做得很好，對整個R&D流程的關註度會降低，從而影響R&D效率團隊的定位和作用。
我見過R&D效率團隊和運維團隊在壹起。當初，Aauto Quicker的運維合作夥伴也是負責流水線的建設。這是可以理解的，因為運維合作方負責公司的基礎設施，公司的服務要想上線運維基礎設施，必須要有上線的系統。偷換，運維夥伴也做了流水線，他們只做流水線。流水線前的部分不涉及，因為那些和運維關系不大，受人力物力限制，運維夥伴不涉及流水線前的部分。相比機器運維部分，產研場景更高級，涉及產品經理、項目管理、RD、QA學生的部分，精簡、標準化、自動化難度要大得多。這種組合的優點和缺點非常明顯:
R&D效率團隊和QA團隊在壹起，我見過這個組織結構。後來組織架構調整，R&D效率團隊和QA夥伴在壹起。如果R&D效率和QA團隊合作形成合力，他們做的事情和影響力絕對高，這是我見過的發揮1+1 & gt；2的組織結構。可惜天時地利都占了，效果卻不理想，非常可惜。
根據我長期的觀察，我認為主要是用人和定位的問題；本文主要談定位問題。R&D效率和QA的結合，其實是在兩個專業領域發力，然後共同產生更大的成果，而不是在QA平臺上長出壹個R&D效率平臺。Aauto更快效率項目在這方面做得很好。R&D效率團隊支持所有的平臺建設，通過接口和內部QA自動化測試平臺，各自的業務可以按照自己的節奏走，同時在“組合”的功能點上可以互相協作、共建、支持。
R&D效率團隊和PMO團隊在壹起。我也經歷過這種組織結構。PMO向業務線的R&D效率團隊推廣平臺，帶來用戶的訴求，R&D效率支持這些用戶的訴求，在日常工作中給予他們支持和幫助。該模式的關鍵點是R&D效率團隊應直接與壹線人員掛鉤。否則，平臺最後很容易變成項目管理平臺，最大程度滿足PMO夥伴的管理訴求，而不是壹線產學研團隊小夥伴的訴求。壹線團隊在那個平臺上的工作不切實際，不好用，體驗差，都是沒做過產研團隊的人想象出來的需求；R&D效率團隊也非常沮喪。妳說的要求我都做到了。其實平臺提出的訴求都是“PMO”的訴求，“壹線實際用戶”的痛點並沒有得到解決。
項目管理專家的意見和建議需要得到重視和評估，同時也不能忽視壹線實際用戶的訴求。當然，這裏也有合作的正面例子可供參考。
該表是服務器R&D效率相關工作的壹部分。從上表可以看出，每個角色關註的R&D效率域不同，即使在同壹個R&D效率域，不同角色關註的也不同。有些公司認為R&D效率和運維團隊既是“成本中心”，又是支持團隊，於是把R&D效率和運維團隊放在壹起，組成壹個龐大的“基礎架構”、“基礎平臺”或“平臺架構”團隊。事實上，我們應該從用戶的角度將R&D效率團隊推向其客戶。運維團隊並不是R&D效率服務的第壹個用戶。我們的主要用戶是產品經理、項目經理、RD、QA合作夥伴，但是運維團隊支持R&D效率團隊，最近經常打交道。我們只是運維資源的大客戶。
因此，我傾向於成立壹個獨立的R&D效率小組並行使其職能。如果妳必須和其他球隊在壹起，那麽和R&D隊在壹起是第二選擇；只是RD合夥人通常是按業務線/產品線閉環到壹個獨立的團隊，而R&D效率團隊作為公共資源很難劃分到某個業務線/產品線。第四種方案是和QA組成大團隊，有利於質保平臺的搭建，最終研發效率和運維壹起。
然而，Aauto faster中的效率項目走了壹條不同的道路。我們將上述所有支撐平臺的生產和研發(包括部分運維平臺的建設)劃分到壹個團隊來支撐，相當於R&D效率+QA平臺支撐+基礎設施平臺+運維平臺(部分)，避免了重復建設，實現了資源利用的最大化。最後的結果和效果也很好。個人認為1，000人以下的規模可以采用這種組織架構。1000多人可以參考我下壹篇文章的內容，主要講的是2000人左右的R&D效率團隊的組織架構和團隊建設。