產品探索驅動的敏捷開發

摘要： 注：本文內容曾經在“2018敏捷之旅杭州站”上做過公開分享，由於資料安全的原因，部分內容有刪減 在VUCA時代，產品的需求變得越來越難以明確，競爭的激烈導致行業細分越來越專業化，客戶對產品體驗的要求也越來越苛刻。在常見的產品研發管理實踐中，不論使用的scrum還是kanban，往往關注...

注：本文內容曾經在“2018敏捷之旅杭州站”上做過公開分享，由於資料安全的原因，部分內容有刪減

在VUCA時代，產品的需求變得越來越難以明確，競爭的激烈導致行業細分越來越專業化，客戶對產品體驗的要求也越來越苛刻。在常見的產品研發管理實踐中，不論使用的scrum還是kanban，往往關注的是產品研發和交付的敏捷，而忽視了產品需求來源這個關鍵的問題。只有把需求產出的過程融合到整個產品開發的框架裡，完成產品需求探索敏捷和產品研發交付敏捷的結合才能形成完整的價值生產閉環，以讓組織獲得更大的競爭優勢。

這裡主要是介紹阿里新零售業務場景下產品探索驅動的敏捷開發實踐，從問題出發，結合產品共創的理論模型和完整的共創性專案管理框架，讓大家對阿里新零售的敏捷專案管理有一個全貌的瞭解，供大家參考。

敏捷開發的特點

說到“產品探索驅動的敏捷開發”，那我們先想想什麼是敏捷開發、敏捷開發有什麼特點。敏捷開發這個說法是相對於傳統的“瀑布”開發模式來說的，那敏捷開發和瀑布式的開發最主要的不同是什麼呢？

有一個最常見的觀點就是，敏捷開發比傳統開發速度更快，開發的節奏更快了，產品的交付上線更快了，這樣我們對外界環境變化的反應也就更快了。就像中國武功裡常說的：“天下武功唯快不破”。為什麼我們希望軟體開發能變得更快呢？因為人類的社會正在進入VUCA時代，我們的社會環境正在變得越來越多變、不確定、複雜和模糊，我們的產品正式要適應VUCA時代的這些挑戰，所以必須要具備更快的反應速度，提高敏捷性。那麼我的問題又來了，是不是我們的研發變得更快了，我們就一定能取得業務上的成功呢？

顯然不是，我們的開發變得更快了並不一定能幫我們取得業務上的成功。有一句話叫做“一開始就錯了方向，跑得越快離終點越遠”。谷歌的google+，阿里的來往，在我們行業有太多這樣的例子。

為什麼要做產品探索

我們可以這樣畫一個象限圖，縱座標是正確的方法，橫座標是正確的產品。如果方法和產品都不對，那結果就一定是垃圾；如果方法正確，產品選錯了，那結果一定是業務上的失敗；如果產品選對了，但是方法有問題，有可能你最終還是交付了價值，但是你會陷入維護的噩夢，這個事情是不可持續的；當只有方法和產品方向都對了，最終你才可能得到成功的產品。

我們常見的敏捷框架，不管是Scrum還是Kanban，更多的都是關注在更快更早的交付產品，也就是聚焦在正確的方法上，但至於怎麼樣找到正確的產品方向，卻一直是被忽視的領域。

所以我們說敏捷，我們認為就是要建立兩種能力，一種是“更快更早交付產品的能力”，我們稱之為開發交付的敏捷，還有一種能力就是“更靈活響應變化，找對產品方向的能力”，我們稱之為產品探索的敏捷，只有具備了這兩種敏捷的能力，才能說我們達到了全鏈路的敏捷。而其中產品探索的敏捷是經常被我們忽視的。

說到產品探索的工作容易被忽視，我們就不得不提到PO這個角色（在有的組織裡叫產品經理或PD）。PO主要的職責有兩個部分的工作，一個是產品交付相關的，比如給開發團隊澄清需求、拆分需求、規劃和跟進迭代的計劃；第二個部分是產品探索的，比如規劃產品方向、澄清產品價值、收集客戶反饋等等（在需求源頭的事）。產品交付類的工作屬於HOW的部分，產品探索的部分屬於WHAT。我們經常發現在一些組織裡，PO花在產品交付上的時間比例非常高，很多PO花在交付上的時間往往有80%左右，甚至有些技術轉PO的會高達90%以上。這個其實是非常不健康的情況，按照我們對PO的期望，他應該把80%的時間花費在產品探索上，產品交付只需要花20%的時間，產品交付的責任PO可以讓開發團隊一起來分擔。

新零售怎麼做產品探索

在阿里新零售我們的產品探索實踐叫“ 產品共創 ”。

產品共創

實際工作中，我們經常會看到PO去走訪客戶，那走訪一趟客戶回來就算完成了共創嗎？顯然沒有那麼簡單。我們把和客戶在一起的活動分成了三個層次：

• 最常見的一個層次就是“ 客戶訪談 ”，訪談很好理解，就是聽取客戶聲音，就是聽聽客戶是怎麼看、怎麼想的、有什麼反饋，客戶訪談之後我們能得到一個資訊的總結，比如客戶對什麼滿意，什麼不滿意，有什麼痛點等等；
• 往上一個層次是“ 客戶調研 ”，客戶調研和客戶訪談有一個比較大的區別是訪談是不設引導方向的，調研其實是有一個預設的方向的，調研一般是帶著一個特定的疑問，希望客戶在一個問題上提供更多的資訊。調研的結果是我們能得到我們的工作方向，就是說調研之後我們就形成一個結論，什麼該做，什麼不該做，找到我們的產品方向；
• 那 共創 就是在訪談、調研的基礎上再前進一大步，共創的結果是要直接形成我們的產品方案，或者也可以理解是要直接得到需求。

產品共創模型

為了把產品共創說明白，來我們一起看一下這個產品共創的理論模型，我們把產品共創的過程分解為5個步驟。

• 第一個步驟叫“ 感同身受 ”，這個意思就是我們要真正進入到客戶的實際場景中去，去體驗在實際場景中客戶真正的痛點是什麼，真正在意的是什麼，你不去體驗，你就永遠沒有感覺，比如說設計一個功能讓線下門店的導購開啟釘釘就有一個二維碼，就可以讓到店的顧客掃碼加會員，但你到了客戶現場才發現，很多門店裡是不允許導購在上班時間用手機的。
• 第二步叫“ 定義問題 ”，在第一步裡我們體會到了客戶的痛點我們是不是就馬上去要給他一個東西去解決他的問題呢？不是這樣的，這個時候我們要開始獨立思考了，我們首先要定義這個問題，這個問題的本質是什麼？不能簡單的按照客戶的要求直接給出產品。舉個大家非常熟悉的例子，比如客戶說我要一匹跑得更快的馬，那我們真的要去找一匹汗血寶馬給他嗎？當然不行，這個時候我們要獨立思考一下，重新定義一下問題，客戶的問題應該是是希望更快的出行方式，這樣問題從找馬到了出行方式了，那這樣我們的思維就一下子打開了，也不會被客戶帶到死衚衕裡了。
• 第三步是“ 形成概念 ”，有了重新定義的問題，這個時候就能對問題開始構建解決方案的模型了，在一個什麼邊界的範圍內，通過什麼手段，解決客戶的什麼問題，這個階段，基本的產品方案就形成了。
• 第四步是“ 製作原型 ”，到了這個階段才是真正設計產品原型了，需要把上一步的產品方案給具化出來，設計產品原型是PO最基本的工作了，這裡就不贅述了。
• 第五步是“ 驗證效果 ”，這步就很重要了，原型出來後不是馬上投入開發，而是要把原型拿到客戶現場來，和客戶一起檢驗這個產品是否是能真的解決客戶的問題，是否能產生真正的價值。這裡需要再補充一個小環，在使用產品原型圖和客戶完成了共創之後，產品可能就進入了開發，在開發完成之後不能著急著上線，這時候需要把可用的產品再拿到客戶這裡來，再次讓客戶來驗證一下，看看真實的產品是否還是能得到客戶的認同。

在這樣一個環的共創模型中，可以看到第1步和第5步是一定需要和我們的客戶在一起的，2、3、4這三步是需要我們的獨立思考的。

共創三部曲

模型可能比較枯燥，我們來看看在實際的工作中，我們是怎麼樣來操作產品共創的。在新零售產品線上，我們把共創分成三個階段，簡稱為共創3步曲。第一步是“ 原型共創 ”，第二步是“ 產品共創 ”，第三步是“ T+14反饋 ”。

我們按照這三個階段，一個一個來看我們是怎麼做的。

1. 原型共創

第一個階段是“原型共創”，原型共創，按名字就可以理解，就是和客戶一起基於產品原型的共創，這個共創的結果就是要得到一個客戶認可的產品原型，在模擬的情況下證明產品的價值。這個階段，PO需要拿著產品原型設計稿，和客戶一起討論並確認產品方案。

在原型共創的時候有一個點非常關鍵，這個是我們來判斷共創的產品需求是否靠譜的一個判斷依據，就是“超出預期”。超出預期的意思就是我們在原型共創的產品原型必須要能帶給客戶超出預期的感覺。如果不能給客戶帶來超出預期的感覺，這個就要小心了，這個產品方案很可能就是不靠譜的。

2. 產品共創

第二個階段是“產品共創”，產品共創就是在產品開發完成之後，正式上線之前，我們拿產品到客戶這裡讓他在正式產品上來驗證業務價值的過程。在一般敏捷的做法裡，開發完成的東西，我們就會希望能儘快能交付到客戶的手裡收集反饋，但有沒有想過，會有兩個問題：一個是遠離客戶，你能拿到的只能是一些冷冰冰的資料反饋，你很難得到有體感的使用者直接反饋；二個其實線上資料的反饋還是太慢，等你收集到足夠讓你分析的資料的時候可能都過了好幾天了，這個時候如果有問題，其實已經實際的傷害了我們的客戶了。所以，我們需要在產品規模化上線之前要來到我們的客戶這裡，邀請共創客戶來體驗我們的產品，看是不是能在真實場景裡解決實際問題。

在產品共創的過程中有幾個點需要注意的：一個是選擇共創的客戶，之前的原型共創的客戶是需要安排產品共創的，但是也需要找一些沒有參加原型共創的客戶，看看第一次看到這個新功能的客戶是怎麼反應的。二個就是人在現場，但是不對客戶的使用做引導，不要講這個新功能該怎麼操作，讓他自己直接去試用，看看憑直觀的理解，客戶會怎麼操作，這個和功能設計的易用性關係非常大，你的一個新功能，到了客戶手上，很有可能就不是按照你設想的那樣去操作的，怎麼提供最直觀傻瓜式的操作體驗，就是衡量你產品好壞的一個標準之一了。

3. T+14反饋

通過了第二階段的“產品共創”，沒有問題的話，那你就能正式批量上線了。第三階段就是“T+14反饋”了。T+14反饋的意思是在正式上線14天之後需要一個這個功能的線上資料報告，這個報告基本就是用來證明你的功能是否取得成功的一個證明了，這個報告是一個以資料展示為主的報告，需要有目標和現狀資料的對比，比如UV、PV、轉化率、跳出率等等。或者從資料中發現了什麼關鍵的結論，或者新的需求需要加在後續的迭代中完成的。

產品探索驅動的敏捷開發

現在我們一起捋一捋在整個研發流程中共創三部曲的位置：在新零售產品線，一個完整的迭代是先從主題輸入開始，主題就是我們的產品方向或叫目標方向。有了這個主題的輸入，PO同學就要去到客戶那邊尋找產品機會，並且完成產品原型共創；原型共創完成之後會有一個需求准入評審，這個需求准入評審主要就是評審原型共創的質量，並且達成各個敏捷團隊之間的需求拉通；然後就正式進入了研發階段；在下一步是灰度上線；灰度上線了之後就進入了共創三部曲的第二步：產品共創；通過白名單選擇共創客戶，完成了產品共創後又會有一個釋出評審，釋出評審的目的就是驗證產品共創的質量，評估收集到的反饋，決定產品是否可以全量釋出；最後是14天之後的一個T+14反饋報告。

這是一個完整迭代的整個流程，可以看到，在整個流程中，共創三部曲的位置是非常重要的，可以說是整個迭代流程的主心骨。開發的前提是共創（原型共創），開發的產出是為了做產品共創，產品開發的價值是靠T+14的資料來證明。這個模型我們就稱之為 產品探索驅動 的敏捷開發。

可以看到，我們一般稱之為開發迭代（或sprint）的階段是整個流程中的一個部分，在我們部門，中間的這個開發的迭代一般是兩週的時間，但是整個產品週期大概需要7-8周的時間。

那現在我們再回到我們的敏捷框架中來，scrum和kanban，如果我們在scrum和看板的基礎上增加產品共創三部曲就相當於增加了三個產品共創的反饋節點，目的是通過直面客戶，以得到更快更直接的使用者反饋，進而實現產品探索的敏捷。在看板的框架上也是類似的，通過增加產品反饋節點，以得到更快更多的反饋，從而達到產品探索的敏捷。

新零售專案管理框架

這個就是我們新零售的整個專案管理大圖，上面相對內容比較多，簡單來看，這個框架分為上下兩層，上面可以理解是產品級別的層面，下一層是特性團隊的層面，在多個敏捷團隊上，我們拉齊了各個團隊的需求准入和需求驗收評審的節奏，並在需求准入評審和需求驗收評審的會議上完成了對產品共創質量的把控，也就是說我們把整個產品共創和產品共創的質量檢查融入到了整個產品線的運作機制中來，從而保證了產品共創機制能夠持續有效的執行下去。

產品共創要點總結

• 第一個是產品共創方法適用的領域，目前我們還是覺得這個方法在2B的業務領域裡是比較適用的。首先2B的業務領域往往是非常複雜的，我們的PO其實往往並不是這個領域產品的真正使用者，比如我們做零售行業的產品，但我們自己卻沒有線上下店裡賣過貨，我們怎麼敢說我們已經比客戶更瞭解他們的需求呢？比如電信產品，我們也沒有在運營商的公司裡真正運營過這麼大的網路，我們真的比運營商更瞭解他們需要什麼嗎？而且2B的商家他們在有自己的痛點，他們更願意花時間、投精力陪你一起來共創，C端的使用者往往就很難；但是C端的產品怎麼做類似的產品探索，這個以後有機會也可以和大家一起探索；

• 第二個是要實現產品探索的敏捷開發一定要建立真正意義上的特性團隊，或者叫feature team。這裡有一個誤區，有的時候我們覺得把開發、測試、產品等跨職能的人組織在一起，好像就形成了一個特性團隊，其實這裡往往有很大的問題。把這些不同職能的人聚在一起就一定是feature team了嗎？還有一個概念叫做專案組，這樣的一個team和專案組有什麼區別？這裡就不展開講專案組和特性團隊的區別了，但有一點，一般專案組裡不同角色的人的目標是不一致的，比如產品的目標一般是業務導向的，但是開發的目標很可能是交付導向的，這個時候大家對產品探索這個事情的理解就不一樣了，開發同學這個時候就會希望需求早點訂好了就不要再動了，這樣開發效率才最高，但是產品探索的方式很容易帶來需求的頻繁變動，這樣就不可避免帶來團隊內的衝突。所以，建立真正意義上的特性團隊，團隊裡所有的角色都統一到業務目標上來，就非常必要了；

• 第三個對待產品探索的態度，拒絕拍腦袋需求，因為拍腦袋來的需求最容易，坐在辦公室裡，幾個人一合計，一天可以產出一個月都做不完的需求，這樣產出的東西可能最終有價值很少。我們有一個口頭禪就是，“無共創、不產品”；

• 第四個是“最小閉環”，也稱為MVP，一個新的功能，我們只從最小閉環開始做，產品探索不就是嘗試嘛，哪有嘗試時就下大注的？這個時候不要擔心功能不全客戶會不滿意，只要是真的對客戶有價值的功能，就算不完整，客戶也是會非常興奮的，如果真的是痛的厲害的地方，你的藥就算只能治好一部分，那對客戶來說也是靈丹妙藥；

• 第五個要“資料說話”，產品探索的目的還是實現業務價值，以終為始，用資料說話才是最有效的檢驗產品探索效果的方法。每個新特性啟動開發前都必須有目標，每個特性上線後都必須檢查目標是否達成；

• 最後一個是“機制”保障，共創其實不是一個輕流程，這個流程對PO提出了巨大的挑戰，怎麼保障這個流程能夠有效的運作下去，這個就需要可行的機制保障。我們建立了一套需求准入和需求驗收的評審機制，這個是業務和產品老闆直接主持的評審，通過這個方式保障共創機制的可靠運轉；