一、背景
移動互聯網行業中，為了應對市場環境和競品的競爭壓力，為了快速滿足海量用戶的多樣化需求，同時當業務團隊規模擴大到一定程度（如50人以上）時，會遇到許多影響團隊協作和業務交付效率問題（如需求各方PK、各方步調與節奏不一致、關聯配合協調困難、職能墻的困擾、bug后期爆發、hotfix與patch多、等）。
如何提升大業務團隊的快速交付能力，就成為了非常重要和急需解決的命題。下面以UC瀏覽器和九游大業務團隊為例，以班車模式為核心來闡述打造大業務團隊快速交付能力的模式與關鍵實踐。
二、快速交付模式
總關鍵詞：
統一業務目標與發布節奏
業務、技術與團隊解耦
團隊協作規則
工程化與工具支撐
關鍵說明：
1、統一業務目標與發布節奏：
定期（季度、月）拉通各業務方進行業務目標和重點的規劃，并分解到版本，確定每個版本的發布發布節奏。達到大業務團隊聚焦業務目標和價值，步調統一和協同作戰之目的。
2、業務、技術與團隊解耦：
A、按特性來進行業務解耦，把大產品分解成多個相對對立的特性功能。
B、從系統架構出發，將大系統分解成多個相對對立的模塊。
C、按特性來組建特性或專項團隊，把大團隊拆分成多個由產研測組成的敏捷小團隊，每個敏捷小團隊人數控制在10人左右。特性團隊長期打磨某個獨立功能，專項團隊則更多是組織精銳攻關解決TOP重點問題。
通過業務、技術與團隊等維度的解耦，達到降低系統復雜度、減少互相關聯與干擾、降低溝通和協作成本，確保各特性團隊和專項團隊能（相對）獨立各自快速迭代與交付。
3、大團隊協作規則：
A、各特性團隊和專項團隊各自分支獨立規劃、迭代和交付：大需求按業務場景拆分成獨立小需求，分支上完成后分批回trunk；小需求分支上完成后可及時回trunk。
B、各特性團隊和專項團隊匹配班車發布節奏：需要發布的需求依據主線班車迭代計劃來做上班車的匹配。大需求和基礎模塊改造需求（比如研發工作量超過10人天）回trunk的計劃時間點最好比主線班車版本分支開出時間點早1-2個工作日，以便應對風險和降低趕不上班車的幾率。
C、需求提交到trunk的質量要求：大需求和基礎模塊改造需求（比如研發工作量超過10人天）需要在分支上完成內測與灰度，產研測項目綜合評估通過后才能提交到trunk。各專項可招募各自的粉絲用戶參與產品需求交流和內測等活動，和用戶交流互動，及時獲得和更好滿足用戶的真實需求，及時收集到用戶反饋的問題和建議，并及時做修復和處理。
D、分支灰度策略和要求：分支上發灰度時需要在最近發布的穩定版本基礎上進行。
4、工程化與工具支撐：
為了保障交付的效率和質量，需要逐步提升團隊工程化和工具化能力，如持續集成和UI自動化測試、穩定性自動化測試、一鍵提測和發布系統等。
三、實施階段與效果
在UC瀏覽器和九游游戲大業務團隊快速交付能力打造過程中，按初始、穩定、持續優化三個階段推進和實施。
1、初始階段
當業務面臨發布周期長、質量不高、大團隊協作復雜等問題時，引入班車模式，重點是完成團隊協作規則制定和團隊建立，并快速的行動起來。
2、穩定階段
大業務團隊采用班車模式運作一段時間后，團隊已逐步熟悉班車模式的運作框架、發布節奏等，但交付效率、版本質量、人員成長等還需要繼續提升，此時需要快速總結并對重點問題進行優化。
3、持續優化階段
快速交付模式已經過完善和優化，團隊在交付效率、交付質量、團隊能力成長等多方面都已成熟和得到了提升。此時引導團隊做更多思考，確定新的目標和下一階段優化重點，不斷思考和探索，不斷追求極致，持續提升交付能力。
目前UC瀏覽器大業務團隊班車模式實施已經進入持續優化階段，較好解決了早期發布周期較長、Patch較多、關聯協作困難等問題，團隊交付能力已得到大幅度的提高，正在探索隨發模式。九游游戲在2015年中引入班車模式，班車模式基本運作順利，在團隊協作效率方面已取得初步成效，目前重點是提升班車交付質量和交付效率。
(本文于2016-03-19首次發布)
