阿里新零售戰役項目如何實現持續價值交付

最新 08-30

洪永潮：阿里巴巴敏捷教練。阿里有一個敏捷教練團隊，我曾輔導過天貓、淘寶、新零售事業部做敏捷轉型，今天分享的案例是在天貓新零售的一個戰役項目。

董小華：阿里巴巴天貓新零售技術部的PMO項目經理，我其實是開發出身的，轉型做項目經理，最近在帶天貓新零售的一個比較大的戰役項目，在這個項目當中跟永潮一起合作。

洪永潮：今天的分享包含四部分：

1）背景；2）如何驅動端到端的持續價值交付；3）持續交付價值的實施過程；4）總結

我會講前面兩部分。

1. 背景

阿里巴巴馬老師從2016年提出新零售概念以後，現在國內新零售的風氣很足。今天分享的案例是6月24日釘釘發布會上提到智能導購項目，類似的產品在騰訊、京東都有布局，可以說競爭相當激烈。

其次是新零售概念提出來之後，像盒馬這樣的模式出來了，我們完全無法確定，接下來會發展成什麼樣子，這是一個我們無法去準確預測時代，我們能做的就是想辦法比競爭對手更快的速度更低的成本來交付價值、驗證假設和響應業務的變化，這是一個業務的訴求。

目前很多研發模式裡面會涉及到瀑布流，這個對持續價值交付是不利的，瀑布流在分析和編碼階段是埋bug的過程，到測試階段才逐步把bug消掉，分析和編碼過程中埋的Bug需要到測試階段一起逐步修復，這樣的話是很難做到持續交付的。

我們希望產品缺陷能持續保持在一個低水位的過程，甚至零缺陷，這樣就更容易做到持續發布。而瀑布流下的Code Then Fix模式離持續交付有一定的距離。我們要建立持續交付價值的管道，保持存量缺陷在低水位的同時來快速交付價值。

2. 驅動端到端的持續價值交付

第二個部分講如何驅動端到端持續價值交付，通過三個方面來講。

首先需要產品探索這一塊做的更准更快，對市場更準的把握，更快得獲得市場的反饋。

其次是產品交付過程能夠持續快速交付有用的價值。

再次是團隊要建立快速響應，以業務目標為驅動的文化，來為產品探索和產品交付做支撐，同時這三方面需要在一起持續協作的，今天這裡主要講產品探索和產品交付這兩部分。

產品探索里的一個雙鑽模型，和適合2B項目，做產品是希望去解決一個有價值的問題，價值的問題是什麼？用什麼方法來解？跟誰來討論？最後的方案？這些都是不確定的，我們需要找到一個途徑把我們的問題和方案能夠澄清，我們有哪些辦法呢？

一開始會有一個初步的業務大圖，同時會設定一個產品的目標和走向，產品經理需要去定義產品的用戶路徑和業務流程，從中去發現問題，然後把某一個主題或者是某一個領域作為專項，在某一階段去驗證這個專項，拿到業務的目標獲得市場的反饋。

團隊會根據業務大圖來確定目前最需要解決的問題，然後根據這些問題來確定主題，產品經理根據主題來確定相關的抓手和功能，然後再畫出用戶操作流程和最初的交互稿。交互稿畫出來以後怎麼辦？

是不是讓開發同學直接把需求開發完成，然後讓市場來檢驗問題是否已經被解決，這是一個方法，同時也可以有更好的方法，如果開發完了，交付給客戶，客戶說這不是我想要的怎麼辦？

有會出現兩個問題，首先是浪費了開發同學的時間和精力，同時也失去了一次做更有價值需求或功能的機會成本；

其次是對業務方和客戶來說反饋偏慢。我們會拿著交互稿直接到客戶那邊去，找幾家天使用戶，和他們一起共創，第一時間給天使用戶看到交互稿，他們會給很直接的反饋。

通過輸出交互稿的方式，在客戶那裡快速獲取反饋，這是第一次從客戶那裡拿到反饋，我們把它叫做原型共創。

在原型共創的同時，會跟客戶進行深入的訪談和調研，會與客戶不同的角色去溝通和交流，站在客戶的視角，聆聽客戶的聲音，解決客戶最期待解決的問題。

原型共創和客戶訪談做完以後，產品經理會收集到多方的反饋、建議和述求，然後根據這些信息，同時加上自己對產品的理解和思考，進行抽象，根據主題去明確主題相關的目標，根據這些目標再來看我們需要做什麼，這時會理出來真正要解決的問題和要做的功能點。

這裡尤其重要的是需要去反推：即實現了這些功能後，是否真的能解決客戶的問題（包括原型共創和客戶訪談的問題）和實現業務目標，這個反推特別重要。

在問題域產品經理會做很多細緻的準備工作，包括各種的分析和討論，然後再收斂和定義問題。

是不是產品經理單獨收斂和定義了問題就可以了呢？好多產品業務團隊都是這麼做的，大家知道，在軟體行業最不缺的就是需求，不管有多少開發同學，需求的數量總是會超過開發的人力投入，所以需求需要精簡再精簡，為了不讓需求蔓延和有YY的需求出現，咱們啟動了一個客戶需求准入活動，准入活動的需求必須有交互稿且跟客戶共創過，同時要有明確的優先順序。

輸出是一個需求列表，這個列表中的需求可以進一步進行分析，並逐步可進入開發，大家看到上圖列表中有些需求是會被踢掉。

接下來就相對簡單了，一旦確定你的要解什麼問題，需求是什麼，就會很快把方案給定下來，確定方案對阿里同學相對簡單，有很明確的業務場景，也有很明確的業務流程，也有明確的交付過程。

方案確定後，就是細化方案和明確需求，然後再把需求交給我們的開發同學去交付。

2.2 產品交付-建?立持續交付價值的管道

從一個故事講起，最近世界盃正如火如荼的進行著，晚上和朋友一起到酒吧里看球一件很痛快的事情，酒吧前一個醉漢在地上找來找去，很長時間了。警察上前問他：你在幹嗎？「我在找我的鑰匙」。警察找了一下什麼也沒發現，問：鑰匙是丟在這嗎？醉漢說：不是。那他為什麼在這找？醉漢的回答是，因為這有光啊。

鑰匙英文是Key，也可以譯成關鍵。在光照亮的地方尋找答案，但那並不是關鍵所在。產品開發中類似的情況時有發生，產品開發的關鍵究竟在哪裡?

產品開發的關鍵是需要關注端到端的價值流動是否順暢，所以第一步就是把端到端的價值流完全可視化出來，讓我們可以看到需求的整個交付過程，這才是創造改進機會的第一步，然後根據看板上數據去度量去拿反饋，建立持續改進的文化。

所以需要讓看板裡面每個階段都能很清晰的表明出來，圖中藍色的是需求卡片，開發中泳道後面淺藍色的小卡片是隸屬於該需求的任務，紅色的是缺陷或則阻礙項，價值從左邊到右邊要能順暢的流動起來。

在產品開發中，我們的根本問題從來不是停滯的資源，而是停滯的用戶需求。然而，許多管理者特別偏愛去關注資源，看資源的忙閑，而停滯的需求卻很少被關注和即時發現，價值流可視化出來後，這些就很容易被關注和即時發現。

明確流轉規則。價值流可視化出來以後，不但要讓價值流順暢的流動起來，更要讓價值高質量的流動起來，所以需要明確各個狀態的流轉規則，沒有規則不成方圓。

我們從設計中到待開發有明確的流轉規則，從開發中到待測試也有明確的流轉規則，有了規則以後，各角色需要按照規則流轉，一方面提升各階段的質量，另一個方面，大家有明確的共識，減少溝通和澄清的成本。

上圖中的泳道數量是有限的，它也意味著並行需求的數目是有限制的，限制的好處有兩點。第一：並行少，更快地完成進行中的需求，需求從開始到完成的時長自然縮短；第二：如果產生了問題，我們必須儘快解決，讓需求能順暢流動。

問一個問題：在站會的時候，看板上的需求是要從從右往左還是從左往右看呢？為什麼？

在站會時，看板上的需求是需要從右往左看的，是因為右邊的需求是更接近完成，是讓靠近完成的需求更快的完成，而不是去啟動更多的需求，我們來看一個生活中的例子：

北京被稱為堵城，早晚高峰特別堵，當路口遇堵的時候交警一般會怎麼做？首先交警會做一個推的手勢，是讓還未進入路口的車輛不要再進來了，明確未進入路口的車輛暫時停住；然後做一個來的姿勢，讓接近離開路口的車輛趕緊離開。

交警關注的是車輛流動，產品開發中關注的價值（需求）的流動。

當然在產品開發中，既要關注需求的流動，也需要關注代碼的流動，持續集成等工程實踐會讓代碼流動更加順暢，為持續交付價值起來支撐保障的作用，關於持續集成這裡不做詳細的展開。

需求流和代碼流，流動到最後，就成為產品。在產品正式發布前，還需要做一輪產品共創，前面提到有一個原型共創，是拿著交互稿與客戶一起共創。產品開發完成後，正式上線之前，會讓用戶體驗可真正可操作的產品。

這個是在產品規模化上線前，在客戶那裡獲取的第二次反饋，來決定下一步的動作，這一步需要符合幾個條件：

1）產品上線可體驗：這個是必要條件，產品不上線就無法進行產品共創。

2）選擇不低於三家企業：這是量的要求，需要明確確實解決了客戶的問題，同時又是各企業共性的問題。

3）人在現場，不做引導：這一點特別重要，很多的APP在用的時候，我們產品經理會去現場指導，告訴客戶怎麼用，或則根本就不去現場，隨便用戶怎麼用，當用戶碰到問題的時候我們才給出指導，而我們要求的是在產品經理或則開發人員在客戶現場，卻不能引導他怎麼操作，看著用戶操作是否順暢，然後在功能體驗後再獲取客戶的反饋，可以檢驗產品的體驗是否做到足夠好，足夠把用戶的場景考慮完善。

第二輪共創會決定了這些功能是否能規模化，也就說這是產品規模化前獲取用戶的第二次反饋

產品共創結束前，會從用戶那裡拿到滿意度調查，包括易用性、易懂性和能夠解決問題三個方面做反饋，產品團隊會根據這個反饋和綜合考慮，決定這項功能是否需要做規模化推廣，這個是產品上線前第二次獲取用戶反饋。

第三次是T+14的業務反饋，功能在規模化上線後的14天查看業務數據。各場景的需求會設定一個小目標，小目標會通過業務數據的反饋來確認是否達成了，譬如頁面訪問PUPV到多少，目標定下來，會在上線14天去看反饋的數據，為什麼是14天呢，產品團隊認為功能上線後14天沒有看到效果，後面基本上就看不到效果了。

在T+14之前，各小團隊會先去分析各自數據，到T+14的時候，整個大團隊會一起來看數據是否達成了當初設定的目標並分析原因作為下一輪的基礎。

建立三步高效快速的業務驗證：包括原型共創、產品共創和T+14業務反饋。

同時會建立一個持續價值交付的管道，讓價值順暢流動起來，關於持續價值交付，團隊會設定效能目標，譬如周期時長，內外部的質量等，這一塊有一個完整度量體系來度量。

接下來會由董小華來講關於這一塊如何在團隊裡面實施的，謝謝大家。

3. 持續價值交付的實施過程

大家可以看到我們分了三步：從技術提效，到組織提效，再到產品提效。

通過技術提效先拿到持續交付價值的效果，給老闆和團隊建立信心；

在技術提效的過程按照現有的職能團隊劃分，發現了一些問題，譬如目標一致性不夠，團隊的向心力和凝聚力可以更好，所以啟動了組織提效，設立以業務為目標的全功能團隊，這方面HR和BU老大給了很大的支持。

同時也對產品團隊提出了要求，需要關注業務的價值，而不是交付更多的需求，從關注Output轉變到關注Outcome上來，這個過程了為了從用戶出發，減少YY需求，引入了2B產品特有的共創機制。

建立持續交付價值的管道，首先是明確價值流轉規則及度量規則。需求按狀態進行流轉，默認是待處理，可以是一個點子，也可以是一個想法，也可以是待辦列表。

在迭代前，會選擇價值優先順序最高的需求，已選擇的需求表示已經確認要做的需求。當需求設計好後，達到待開發的條件，會被置成待開發狀態。

提測是一個比較嚴肅的事情，需要開發同學通過自測和冒煙用例的測試，還是需要進行團隊演示，只有這些過了後，才會到提測狀態。何時由待發布狀態進入發布是由產品和業務的策略來定的。

除了需求狀態，這裡有兩個周期，一個是交付周期，從已選擇到已發布；一個開發周期，從待開發到待發布。

交付周期是整個團隊的交付能力的體現，開發周期是開發過程流動效率的體現。這是咱們很關注的效能指標，當然同時質量也是必須要保證的。

這是一個雙層端到端的物理看板，包括需求和任務，開發中的子列較多，是指一個需求被拆分到不同端的任務，體現一個需求需要各端同學一起協作交付。

每日站會，相信很多公司都在採用這個實踐，這個實踐真的很好，值得推薦，每天花10到15分鐘就可以暴露你項目當中進展、問題和風險，通過物理看板的透明化機制，整個團隊的聚焦到這裡一起協同。

看板上的需求是按照優先順序來拉動的，團隊要聚焦在價值最高的需求上，讓價值最高的需求儘快的交付。

大家看到開發中的泳道數量是有限制的，如果都泳道都被佔滿了，我們應該怎麼做呢？我們應該做的不是開始更多的需求，而是儘快去完成那些已經開始的需求，讓需求流動起來。

問題在於停滯的需求，需求如果停滯就會在這排隊，提示該環節中可能存在問題。

來看看實際實踐的效果：項目的三個階段，交付周期、開發周期都是在不斷地變短，同時有效bug數也是在不斷地減少，可以說交付周期變短，交付質量提升。

再一起看看內建質量對比，這是一個缺陷趨勢圖，是一幅很好呈現持續交付價值的圖。橫軸是日期，縱軸是bug數量，紅色柱子是當天新建的bug，綠色柱子是每天解決的bug數量，藍色曲線是存量bug的數量，敏捷前和敏捷後有一個分界線，之前是典型的批量開發，批量提測的瀑布方式，到最後集中修復大批量的Bug，開發和測試同學壓力都非常大。

敏捷實施後，缺陷是持續被發現持續被解決，而且總體數量明顯下降，修復缺陷的壓力被分散。最後還是有一個小高峰，是因為一個大需求不能做拆分，到最後才測試，所以建議大家對於能拆小的需求盡量去做拆分。