緣起

2017年3月，應移動事業群智慧營銷平臺專案管理部負責人邀請，我開始支援智慧營銷平臺CRM團隊。智慧營銷平臺是阿里文娛廣告團隊，是阿里巴巴淘外變現的主力軍。CRM團隊負責開發和維護CRM系統。CRM系統服務於銷售和代理商，串起商機管理、客戶開發、合同管理、風控稽核、賬戶管理、財務結算等業務鏈條。CRM系統的質量和交付速度，直接影響銷售和代理商服務廣告主的效率和體驗。

3月初我訪談了銷售、產品、開發、測試等團隊核心成員，並觀察了團隊的週會、站會和需求討論會。當時團隊的目標是在3月25日交付框架合同功能，主要工作圍繞框架合同功能開展。根據訪談內容梳理出框架合同專案研發過程的時間線如下：

從圖中可以看出，這個專案基本按照瀑布模式推進，開發2個月後整體提測，測試1個月後一次性發布。開發2個多月後，業務方才有機會試用產品並給出反饋。

這個專案暴露了瀑布模式的弊端：

1.接力棒的協作模式帶來資訊差

瀑布模式下，業務、產品、研發三方很少共同參與討論。需求如同接力棒從業務方傳遞給產品經理，再從產品經理傳遞給研發團隊。資訊每經過一次傳遞都有損失，業務方、研發團隊得到的大部分是二手資訊；產品經理成為團隊溝通的瓶頸，業務方和研發團隊直接討論可以解決的問題，要經過兩輪甚至多輪溝通才能達成共識；業務方和研發團隊缺乏相互理解，研發團隊不瞭解需求背後真正的業務訴求，業務方不瞭解技術方案背後的權衡。

2.難以響應變化

瀑布模式下，所有的需求分析和設計工作在開發前完成，並假設需求不會改變，研發過程只需遵循最初的專案計劃和範圍。實際專案中，變化在所難免。 即使再多花一倍的時間評審需求和制定專案計劃，也無法預見所有的變化。事實也正如此，框架合同專案中業務方組織結構調整，客戶URL與銷售的對映關係發生變化，原有的設計無法相容這種變化，已實現的功能需要重新設計。正如何勉老師在《精益產品開發》所說：“希望一開始就能設定完整和正確的需求，這對軟體產品越來越不可能，因為使用者也不知道或說不清楚自己想要什麼。事實上，對需求的發掘和理解，應該是一個持續的過程，需要不斷地反饋。”

3.很遲才得到使用者反饋

瀑布模式下，所有的產出在專案末期交付，專案的風險也累計到最後，專案過程中沒有機會驗證假設和得到真實反饋。框架合同專案中，業務方在3月初才第一次試用產品，此時距離釋出時間不到兩週，反饋的大部分問題在釋出前來不及修改。3月底釋出後，產品功能持續迭代了數月，才達到業務方的期待。

CRM團隊深受其痛，團隊的訴求主要有：

1.業務、產品、研發密切協作，作為一個團隊為共同的目標努力。

2.縮短需求交付時長，貼合業務需要完善CRM系統。

改進方案和落地實施

結合團隊的訴求和CRM團隊的實際情況，與智慧營銷平臺業務、產品、研發、專案管理負責人溝通後，確定了改進方案。改進方案聚焦於兩點：

1. 組建One Team，促進跨部門協作

One Team由業務、產品、研發核心成員組成，後來又加入了負責產品落地的運營同學。

One Team負責制定季度產品規劃。以往各職能部門分頭組織季度規劃，業務、產品、研發的目標可能有偏差，執行過程中容易對需求優先順序產生分歧。One Team成立後，成員共同制定季度規劃。目標對齊後，團隊的工作圍繞季度規劃展開，對需求優先順序容易達成共識。看一下CRM KA的例子：

產品路線圖

2018財年Q1的季度規劃執行情況

One Team召開雙週會，會議有3個固定議題：

• 回顧上個迭代已釋出功能的使用者反饋；
• 同步當前迭代的進展；
• 梳理下個迭代的核心需求。

通過One Team雙週會，串起了需求反饋環。大家不再侷限於部門和角色分工，快速同步資訊，迅速解決問題。以前使用者反饋的問題在部門間層層流轉可能幾個月才解決，現在雙週會上大家商量一下方案立即排期解決。

2. 向迭代模式轉型，縮短需求交付時長

One Team成員商議後，在月迭代和雙週迭代之間選擇了更有挑戰的雙週迭代。

從瀑布模式向迭代模式轉型有兩個關鍵的實踐：拆分需求和建立節奏。

拆分需求是小步迭代的前提，對於剛剛轉型到雙週迭代的團隊，我們沒有一刀切。進入研發環節前，需求最好拆分到1周內可以提測的粒度，以便在一個迭代內釋出。如果需求確實難以拆分，也可以跨迭代交付。同時我們會關注需求的開發時長，以此衡量需求的粒度。期待隨著實踐的深入，越來越多的需求可以在一個迭代內釋出。

需求拆分採用使用者故事地圖方法：對於一個複雜的大需求，按照使用者在特定場景下要解決的問題切分出使用者旅程，每次釋出儘量交付一個完整的使用者旅程。一般會按照從簡單到複雜的順序，先實現MVP（Minimum Viable Product），交付一個最簡單的使用者旅程。在此基礎上不斷豐富和完善，逐步實現附加功能和定製功能。以下是一個需求拆分的例項，其中“普遍品專詢價”和“普通品專合同”組成了一個MVP。

對敏捷開發有個普遍的誤解，敏捷就是快，需求沒定義清楚就急於開工。事實上，這麼做往往得不償失。正如Marco Behler所說：程式設計師的生產力始於“恰當的需求”。

為了減少研發過程的返工和浪費，需求進入研發前要符合准入標準DoR（Definition of Ready），釋出前要符合準出標準DoD（Definition of Done)。需求釋出後，產品經理會觀測埋點資料，業務和運營會蒐集使用者反饋。One Team會上大家根據使用者反饋決定下一步的改進和優化。

迭代活動有節奏地進行，迭代才能有序運轉。One Team成員商議後，一致同意嘗試如下的節奏：

從圖中可以看出，本迭代的開發測試與下迭代的需求分析併發進行，這樣可以最大限度地減少研發環節的等待。代價是部分開發和測試同學要投入一些精力梳理下個迭代的需求，例如評估技術可行性、澄清驗收標準。大部分的需求梳理工作在One Team雙週會上進行，如果雙週會上發現一些待確認的問題，會記錄下來並由專人負責跟進。

迭代第一天，研發團隊按照優先順序把符合准入標準的需求拉入迭代，做初步的設計和估算。根據估算做出嚴肅的承諾，並制定研發計劃：

從圖中可以看出，為了降低風險和分散壓力，團隊儘量做到小批量逐步提測。提測前測試同學會設計好測試用例，提測時開發同學要跑通P0、P1測試用例。測試同學驗證基本功能可用，立即邀請產品經理和業務同學試用，以便儘快發現體驗問題。功能釋出前，業務方驗收即將釋出的版本，業務驗收通過後才可以釋出。

在確定節奏的同時，我們對迭代活動的產出、責任人、截止日期做了明確約定。大家分工協作，迭代很快有序運轉起來：

為了增加透明性，我們用工作流描述需求狀態的流轉：

用看板跟蹤需求的狀態：

效果評估

1.One Team機制促進跨部門協作

業務、產品、研發之間曾經相互埋怨，業務覺得交付的功能不是最需要的，急需的功能反而沒給做，研發覺得辛苦做出來的功能沒人用非常冤，產品夾在中間兩頭受氣。

One Team機制落地後，大家綜合權衡業務價值、技術風險、人員情況、外部依賴、投入產出比等相關因素，一起決定需求優先順序。即便最初大家的意見不一致，通過開誠佈公的討論，對最後的結論也能夠認可，並積極推進執行。CRM SME雙週會上，產品經理預先準備了一些產品優化需求。業務方提出目前更需要看到資料報表。大家迅速達成共識，資料報表是最高優先順序，產品優化需求靠後。

CRM產品團隊季度總結時，CRM KA的產品經理和業務介面人表示：One Team機制建立以來，跑通了業務需求從提出到上線後反饋的大閉環，業務、產品、研發有序協作，接下來會把這個機制順利地運轉下去。

CRM SME的業務介面人在郵件中提到：“目前中小CRM的產品工作在正常有序推進，專案進行的同時，也在積極進行存量需求的消化”，並感謝團隊付出的努力。

智慧營銷平臺的技術負責人高度評價One Team機制：“不僅提升了團隊的開發效率，也提升了團隊的溝通效率”。

One Team成員在持續的協作中，增進了信任和了解，研發更瞭解業務，業務也更體諒研發。以下是兩個具體的例子：

2.雙週迭代縮短需求交付時長

CRM團隊的所有需求都在Aone中跟蹤，團隊在站會上更新需求狀態，根據需求狀態流轉生成的統計圖表能夠反映真實情況。

雙週迭代的首要目標是縮短需求交付時長。結合這個目標，我們主要關注2個指標：開發時長和從開發到釋出的交付時長。需求拆分得越小，開發時長越短，越適合迭代開發。交付時長越短，研發團隊的適應性越好。業務需要時，團隊能夠迅速實現需求並交付到使用者手裡。

CRM KA團隊從6月中開始嘗試雙週迭代，開發時長和交付時長的周移動平均值如下：

從圖中可以看出，開發時長從12天縮短到6天以下，說明需求拆分得更小了。交付時長基本都在20天以內，唯一的例外是7月31日至8月6日一週。原因是這部分功能要跟關聯方同步上線，CRM KA團隊完成了開發測試後，等待兩週才與關聯方聯調上線。

值得一提的是，在向雙週迭代轉型的過程中，CRM團隊保持了很高的質量水準，無論是提測質量、線上質量還是缺陷修復速度，都達到了集團領先水平。

更短的交付時長、更頻密地交付功能，有利於快速驗證假設、交付價值、響應變化。以業務方急需的資料報表為例，CRM團隊把55個業務指標按照優先順序分批交付，確保每兩週都交付一些報表，縮短了業務方的等待時間，貼合業務方的反饋快速調整和優化，贏得了業務方的高度肯定。

應對挑戰

在人力有限的情況下，如何以最快的速度、最低的成本迅速滿足業務發展的需要，是CRM團隊在未來一段時間內面臨的最大挑戰。One Team和雙週迭代的實踐為團隊通力協作、小步快跑、持續改進奠定了基礎，未來繼續深化敏捷實踐能夠獲得更大的收益。

1. 聚焦於持續快速交付業務價值

相比於交付更多功能，我們更應關注為業務帶來了多大價值。從眾多的需求中，如何發掘提煉出業務價值最高的需求？在多種解決方案中，如何找到最佳迭代路線優先解決業務痛點？把80/20原則發揮到極致，我們就有機會以小博大，為業務發展贏得更多機遇。要做到這一點，需要我們善於取捨，相比於決定做什麼，更重要的是決定不做什麼。相比於一次性交付一個大而全的解決方案，更合理的是先實現一個小而輕的方案滿足核心使用者的核心訴求，迅速交付給使用者使用，基於真實的使用者反饋迭代優化。

2. 用技術手段提高生產率

相比於專案結束時一次性發布，每兩週都發布的確會帶來額外的釋出成本，例如迴歸測試的成本、部署上線的成本。為了獲得雙週迭代帶來的靈活性，我們要想辦法不斷降低釋出成本，直至釋出變得如此容易以至於我們完全可以忽略釋出成本。這正是持續整合、持續部署等敏捷工程實踐解決的問題。

持續部署流水線能夠實現從程式碼提交到單元測試、靜態掃描、編譯、打包、部署、測試、釋出全流程的自動化。把一切重複的工作交給機器，解放工程師去做更有創造性的工作，是提升效率的根本之道。CRM測試團隊已經實現部分自動化測試，也有自動編譯打包的Jenkins job，再努力一步完全可以實現持續整合、甚至持續部署。智慧營銷平臺測試團隊已經在朝著這個方向努力，這是非常有價值的工作。如果研發同學也加入進來，大家齊心協力，相信很快就有成果。

總結

通過One Team機制，業務、產品、研發間增進了信任和了解，彼此協作更順暢。

通過拆分需求和有節奏的短迭代，CRM團隊從瀑布開發模式比較順利地轉型到了迭代開發模式。釋出頻率從數月一次變為兩週數次，基本做到6天以內提測，20天以內釋出。更可喜的是，在轉型過程中，團隊保持了高質量。

研發團隊持續快速交付業務急需的功能，得到了業務團隊的高度認可。

轉自：《敏捷開發，你真的做對了嗎？阿里文娛廣告團隊敏捷實踐總結》