1.總體介紹41.1技術(shù)創(chuàng)造新商業(yè)—阿里巴巴二十年的技術(shù)發(fā)展歷程回顧41.2提升研發(fā)效能所要解決的問題61.3下一代精益產(chǎn)品開發(fā)81.4案例集的組織92.第一板斧：全鏈路精益協(xié)作及精益需求分析112.1實踐案例一ET大腦精益產(chǎn)品研發(fā)的實踐112.2實踐案例二云效助力互聯(lián)網(wǎng)+醫(yī)療「遠圖互聯(lián)」提效522.3實踐案例三敏捷團隊的病與藥——阿里健康醫(yī)藥B2B團隊敏捷轉(zhuǎn)型手記602.4方法案例一基于事件風暴的需求分析802.5方法案例二實例化需求：不可或缺的精益、敏捷需求實踐972.6方案案例三每日站會：你的站會姿勢正確嗎？1213.第二板斧：中臺化技術(shù)及云原生的工程實踐1293.1實踐案例一云效助力「商米」從”蒸汽時代”到”高鐵時代“DevOps轉(zhuǎn)型之路1293.2實踐案例二云效攜手ACK助力「上海博卡」DevOps轉(zhuǎn)型之路1453.3實踐案例三通過度量把發(fā)版過程的不確定變成確定-構(gòu)建閑魚版本持續(xù)交付管道及度量1533.4方法案例一為什么你應(yīng)該關(guān)心領(lǐng)域模型1623.5方法案例二撩云效流水線的正確姿勢：請叫我云效Flow1724.第三板斧：精益互聯(lián)網(wǎng)創(chuàng)新方法1804.1實踐案例一10個月，15億，阿里云如何賦能企業(yè)打造交付和創(chuàng)新競爭力1804.2方法案例一從持續(xù)交付到業(yè)務(wù)創(chuàng)新（上）：互聯(lián)網(wǎng)時代研發(fā)效能的核心1924.3方法案例二《從持續(xù)交付到業(yè)務(wù)創(chuàng)新》（下有效的業(yè)務(wù)創(chuàng)新2125.綜合轉(zhuǎn)型案例2275.1實踐案例一4個迭代，從批量交付到持續(xù)交付的轉(zhuǎn)型實踐2275.2實踐案例二云效助力新金融DevOps轉(zhuǎn)型——南京銀行實踐之路2395.3實踐案例三把效能帶到游戲里！仙峰紅海蛻變突破之路2456.總結(jié)2537.云效專家團2541.總體介紹1.1技術(shù)創(chuàng)造新商業(yè)—阿里巴巴二十年的技術(shù)發(fā)展歷程回顧阿里巴巴成立20周年之際，回顧技術(shù)發(fā)展歷程，將其總結(jié)為3個階段。圖：阿里二十年的技術(shù)發(fā)展歷程這三個階段分別是：1）技術(shù)支撐商業(yè)發(fā)展（1999年~2008年）：從B2B阿里巴巴到C2C淘寶，支付寶和B2C天貓，技術(shù)支撐了商業(yè)的高速發(fā)展。2）技術(shù)拓展商業(yè)邊界（2009年~2016年從阿里云的第一行代碼，到構(gòu)建引領(lǐng)DT時代的“大中臺、小前臺”組織、業(yè)務(wù)機制和技術(shù)路線，技術(shù)與業(yè)務(wù)開始融合，并拓展了商業(yè)邊界。3）技術(shù)創(chuàng)造新商業(yè)（2016年~從提出包含新零售、新金融、新制造、新技術(shù)、新能源在內(nèi)的“五新戰(zhàn)略”，到創(chuàng)立達摩院，再到阿里云加速引領(lǐng)行業(yè)數(shù)字化轉(zhuǎn)型，技術(shù)成為創(chuàng)造新的數(shù)字化商業(yè)的核心動力。圖：技術(shù)與商業(yè)關(guān)系變化回望這三個階段，20年來技術(shù)與商業(yè)的關(guān)系，發(fā)生著持續(xù)且深刻的變化，從相對獨立，到相互融合，直至技術(shù)成為商業(yè)的內(nèi)核。下圖是我們對技術(shù)與業(yè)務(wù)的關(guān)系進一步闡述。首先，內(nèi)核是云原生基礎(chǔ)設(shè)施，以及云原生的開發(fā)運行環(huán)境；其次，云原生內(nèi)核之上是包括業(yè)務(wù)、數(shù)據(jù)和AI在內(nèi)的中臺。最后，是以三中臺為基礎(chǔ)，業(yè)務(wù)開發(fā)團隊快速組合并拓展新的業(yè)務(wù)形態(tài)，和快速響應(yīng)新的業(yè)務(wù)需求。圖：對技術(shù)與商業(yè)關(guān)系的細化技術(shù)創(chuàng)造新商業(yè)，技術(shù)成為商業(yè)的內(nèi)核。這對產(chǎn)品技術(shù)團隊是機會，他們承擔著前所未有的責任。這對產(chǎn)品技術(shù)團隊更是挑戰(zhàn)。做的好，技術(shù)會成為創(chuàng)新和發(fā)展的原動力，起到加速業(yè)務(wù)發(fā)展、引領(lǐng)業(yè)務(wù)創(chuàng)新的作用；做的不好，則會成為業(yè)務(wù)發(fā)展的瓶頸和阻礙。而區(qū)分好與不好的關(guān)鍵是研發(fā)的交付效能。以中臺化為例，它為解決現(xiàn)實問題而生，如：突破業(yè)務(wù)和組織豎井，打通不同業(yè)務(wù)的流程和數(shù)據(jù)；最大化軟件資產(chǎn)的價值，減少重復建設(shè)和維護，并敏捷響應(yīng)業(yè)務(wù)訴求。但是中臺戰(zhàn)略，必須有協(xié)作、工程和技術(shù)實踐支持，才能實現(xiàn)研發(fā)交付效能的持續(xù)提升，實現(xiàn)良好的初衷。否則，配套的技術(shù)和協(xié)作實踐方法跟不上，反而增加協(xié)作和技術(shù)的復雜度，讓中臺成為交付效能和業(yè)務(wù)發(fā)展的瓶頸環(huán)節(jié)。研發(fā)效能直接關(guān)系業(yè)務(wù)的發(fā)展和成敗。產(chǎn)品技術(shù)團隊必須持續(xù)的提升研發(fā)效能，真正起到加速業(yè)務(wù)發(fā)展和引領(lǐng)業(yè)務(wù)創(chuàng)新的使命。如何才能提升研發(fā)效能呢？我們第一個重要的經(jīng)驗就是：從定義正確的問題開始。1.2提升研發(fā)效能所要解決的問題研發(fā)效能究竟面臨怎樣的問題？在長期的實踐過程中，我們將研發(fā)研發(fā)效能的問題，提煉為3個“不等于”。圖：提升研發(fā)效能所要解決的核心問題第一：局部效率不等于高效交付。局部的效率是基礎(chǔ)，但真正的效率，必須以用戶視角來衡量——快速解決用戶問題、快速上線和交付用戶需求。系統(tǒng)的協(xié)同和改進，將局部的效率轉(zhuǎn)化為順暢高質(zhì)量的業(yè)務(wù)交付。這是研發(fā)效能提升要解決的第一個核心問題。第二：高效交付不等于持續(xù)高效。開發(fā)過程中，我們希望不斷積累軟件和工程資產(chǎn)，高質(zhì)量的既有資產(chǎn)讓效率持續(xù)增長。但，缺乏良好的工程（如持續(xù)交付）和技術(shù)（如領(lǐng)域設(shè)計）實踐，積累的就會是債務(wù)而非資產(chǎn)，軟件的擴展和維護越來越困難，效率難持續(xù)。構(gòu)建并應(yīng)用合理的技術(shù)和工程實踐，積累資產(chǎn)而非債務(wù)，保證交付效率的可持續(xù)。這是研發(fā)效能提升要解決的第二個核心問題。第三：高效交付不等于業(yè)務(wù)成功。我們的目標是業(yè)務(wù)成功，但要想成功，必須保證交付的是用戶和市場所需要的，并構(gòu)建起合理的商業(yè)模式。在不確定性陡增的今天，這是一個不斷探索和試錯的過程。應(yīng)用系統(tǒng)的創(chuàng)新方法，解決真實的用戶問題，探索和構(gòu)建可行的商業(yè)模式，保證交付價值的有效性，獲取業(yè)務(wù)成功。這是研發(fā)效能提升要解決的第三個核心問題。圖：持續(xù)地順暢高質(zhì)量交付有效價值提升研發(fā)效能，就是要解決以上三個問題，從而實現(xiàn)：“持續(xù)地、順暢高質(zhì)量地交付有效價值”。定義正確的問題是開始。解決問題則需要系統(tǒng)方法。在長期的實踐過程，我們總結(jié)并形成了下一代精益開發(fā)方法（AdvancedLeanProductDevelopment簡稱ALPD，它是對阿里效能提升實踐的提煉和總結(jié)。1.3下一代精益產(chǎn)品開發(fā)精益思想最初源自生產(chǎn)制造領(lǐng)域，今天已被廣泛應(yīng)用于并深刻影響和改造了許多行業(yè)，如業(yè)務(wù)運營、客戶服務(wù)等，當然也包括產(chǎn)品開發(fā)和業(yè)務(wù)創(chuàng)新在內(nèi)。精益思想的核心是：“最小化浪費、最大化價值和持續(xù)改善”，它與研發(fā)效能改進的的目標——持續(xù)地順暢高質(zhì)量交付有效價值——高度一致，催生了產(chǎn)品開發(fā)領(lǐng)域一系列革命性的方法，如：精益看板方法，精益需求，精益創(chuàng)業(yè)等。然而，這些方法相對獨立，沒能為提升研發(fā)效能提供系統(tǒng)的方法體系，更缺少有效的落地解決方案。這正是ALPD（下一代精益產(chǎn)品開發(fā)）要解決的問題，它以系統(tǒng)解決研發(fā)效能問題為牽引，構(gòu)建了系統(tǒng)的方法體系和完整的解決方案。本案例集將集中于ALPD的方法體系部分。ALPD方法體系，源自我們在阿里巴巴經(jīng)濟體以及業(yè)界的長期深入實踐，其目標正是前文所述的：持續(xù)地、順暢高質(zhì)量地交付有效價值。我們將其具像化為，相對傳統(tǒng)開發(fā)方法10倍效能提升的愿景，其中包括：l10倍響應(yīng)速度：如對需求業(yè)務(wù)需求響應(yīng)從1至3個月左右的版本周期改進至1周左右的交付周期；l10倍過程質(zhì)量：產(chǎn)品開發(fā)過程中最大缺陷存量從近100改進至10個以內(nèi)；l10倍有效價值：這是最有改進空間，也最值得改進的地方，它的衡量是以更少的需求交付更有效的價值，探索并獲取業(yè)務(wù)成功。1986年，布魯克斯曾在《沒有銀彈》一文中斷言：“未來十年，沒有單一的技術(shù)能夠10倍提升軟件開發(fā)的產(chǎn)出效率”。三十多年后的今天，這一斷言依然成立。支撐10倍效能提升的愿景，需要包含協(xié)作、需求、工程、技術(shù)、創(chuàng)新等在內(nèi)的系統(tǒng)方法。這正是ALPD方法體系的內(nèi)容，下圖展示了ALPD方法全貌——ALPD方法屋。圖：ALPD方法體系屋頂是效能提升目標和10倍提升的愿景；底層以及兩側(cè)灰色部分是基礎(chǔ)設(shè)施和組織保障。而中間的藍色和橙色部分則是具體的效能方法。藍色的部分，是關(guān)于精益交付的實踐。具體包括：全鏈路數(shù)字化的精益協(xié)作、精益需求分析實踐，領(lǐng)域驅(qū)動的架構(gòu)和實現(xiàn)實踐，以及云原生的工程實踐。其中，精益協(xié)作實踐及需求實踐保障順暢和高質(zhì)量的交付，技術(shù)及工程實踐則主要保障可持續(xù)性。圖中橙色部分，是用戶目標驅(qū)動的創(chuàng)新實踐。分為業(yè)務(wù)探索和創(chuàng)新實踐，以及更上層的動態(tài)投資組合管理兩個部分。它們共同保障交付有效的價值。我們將以案例的形式來闡述ALPD方法體系。1.4案例集的組織本案例集主要會用真實的案例來說明這些實踐方法。同時我們也會選取部分方法加以闡述。我們將這些實踐分成三個部分，它們也是阿里巴巴的研發(fā)效能提升的三板斧。.10I圖：ALPD方法體系的效能三板斧上圖是這三板斧的劃分，其背后的原則是：每一板斧可以獨立實施，解決一個研發(fā)效能的核心問題，并實現(xiàn)效能提升。這三板斧分別是：第1板斧：全鏈路精益協(xié)作及精益需求分析。解決局部效率不等于高效交付的問題第2板斧：中臺化技術(shù)及云原生的工程實踐。解決高效交付不等于持續(xù)高效的問題第3板斧：精益互聯(lián)網(wǎng)創(chuàng)新方法。解決高效交付不等于業(yè)務(wù)成功的問題2.第一板斧：全鏈路精益協(xié)作及精益需求分析這一部分是研發(fā)效能提升三板斧的第一板斧，解決的問題是：局部效率不等于高效交付。它包含兩類主要實踐方法：1.全鏈路精益協(xié)作方法。它的目標是打通端到端的業(yè)務(wù)價值流，促進整個組織圍繞業(yè)務(wù)需求展開協(xié)作，快速交付。它的核心實踐包括：1）拉通端到端的業(yè)務(wù)價值流；2）對齊業(yè)務(wù)并快速交付；3）內(nèi)建過程質(zhì)量。2.精益需求分析方法。業(yè)務(wù)需求是協(xié)作和交付的源頭，保障源頭的需求分析質(zhì)量和效率是高效交付的基礎(chǔ)。為此我們整合了事件驅(qū)動的業(yè)務(wù)分析及實例化需求方法，幫助組織高效分析和管理業(yè)務(wù)需求。2.1實踐案例一ET大腦精益產(chǎn)品研發(fā)的實踐本文旨在對阿里云智能事業(yè)群-數(shù)據(jù)智能產(chǎn)品研發(fā)事業(yè)部ET大腦精益產(chǎn)品研發(fā)模式的實踐，以及在ET工業(yè)大腦產(chǎn)品線的試點情況進行總結(jié)與分享，實踐過程是基于云效云研發(fā)何勉老師的《從持續(xù)交付到業(yè)務(wù)創(chuàng)新》方法論，充分結(jié)合部門業(yè)務(wù)特點，產(chǎn)品特點，技術(shù)特點，團隊人員特點等方面，逐步探索形成的落地方案，未來方案仍將會不斷迭代演進。圍繞“價值型”數(shù)據(jù)智能產(chǎn)品，從技術(shù)到產(chǎn)品，再從產(chǎn)品到商品，如何縱向打穿，橫向復制，真正讓AI在產(chǎn)業(yè)中落地，需要更多的關(guān)注與探討出現(xiàn)，希望本文也能起到“拋磚引玉”的效果。從整體環(huán)境看，近年來，我們面臨的商業(yè)環(huán)境越來越復雜、模糊不清、難以預測和不斷變化，業(yè)界稱其為烏卡（VUCA）時代。烏卡最早用來形容冷戰(zhàn)后的國際政治環(huán)境，它由Volatility（易變性Uncertainty（不確定性Complexity（復雜性Ambiguity（模糊性）四個單詞的首字母構(gòu)成。今天烏卡被更多用來形容技術(shù)和商業(yè)環(huán)境，而這也是產(chǎn)品交付和創(chuàng)新所必須面對的環(huán)境。從產(chǎn)業(yè)環(huán)境看，經(jīng)歷了IT時代信息化建設(shè)的過程，典型的產(chǎn)業(yè)均形成了一些固有的格局（固有的項目服務(wù)模式，固有的ISV小生態(tài)，固有的三產(chǎn)公司等等但隨著數(shù)字化轉(zhuǎn)型浪潮的到來，加之整體經(jīng)濟下行壓力催生的產(chǎn)業(yè)結(jié)構(gòu)調(diào)整的加速，云計算與人工智能本身作為戰(zhàn)略性新興產(chǎn)業(yè)，結(jié)合各個產(chǎn)業(yè)目標客戶強烈的“自證高端“的訴求（例如：國稅總局在國務(wù)院層面下屬同級機構(gòu)自證領(lǐng)先，各省公安與交警要在公安部層面下自證領(lǐng)先，各傳統(tǒng)制造業(yè)也要自證其向高端制造業(yè)的轉(zhuǎn)型，申報各類創(chuàng)新項目等等“數(shù)據(jù)智能”與“產(chǎn)業(yè)”結(jié)合的機遇十分難得。從內(nèi)部環(huán)境看，隨著阿里云事業(yè)群升級為阿里云智能事業(yè)群，我們需要在選定的戰(zhàn)略行業(yè)加大投入，產(chǎn)品做精做深，通過生態(tài)放大，以支撐云智能業(yè)務(wù)的商業(yè)成功。作為產(chǎn)品研發(fā)板塊下，數(shù)據(jù)智能產(chǎn)品研發(fā)事業(yè)部（原飛天一部&城市大腦事業(yè)部），為配合好阿里云智能事業(yè)群的“智能”戰(zhàn)略，我們需要在“產(chǎn)業(yè)AI”方向上持續(xù)發(fā)力，聚焦客戶痛點，沉淀并打磨出具有競爭力的數(shù)據(jù)產(chǎn)品，并且既要有產(chǎn)品深度，也要有孵化速度。因此，打造一套合適的數(shù)據(jù)智能產(chǎn)品研發(fā)體系，能夠持續(xù)改進高質(zhì)量順暢價值交付的能力，不斷提升組織工程效率，是支持組織業(yè)務(wù)創(chuàng)新的必選項，也是組織的一項重要目標。建立ET大腦精益產(chǎn)品研發(fā)體系，持續(xù)改進高質(zhì)量順暢價值交付的能力，支持業(yè)務(wù)創(chuàng)新。在云效云研發(fā)何勉團隊的大力支持下，首先確定了基本路線——基于精益的持續(xù)交付到產(chǎn)品創(chuàng)新。組織落地分為四個階段：調(diào)研、方案、試點、推廣。第一調(diào)研階段：為了保證本項目的目標與組織戰(zhàn)略目標對齊，以及對現(xiàn)狀的充分了解，部門Leader、PD與研發(fā)Leader、一線的PD與研發(fā)，都是調(diào)研的對象。調(diào)研形式上除了典型的訪談，也參與了個別產(chǎn)品研發(fā)過程，如各類例會、評審會等等。從結(jié)論上看，基本面上沒有統(tǒng)一的產(chǎn)品研發(fā)體系，進一步細分則高矮胖瘦各不相同，例如：經(jīng)歷了2年商業(yè)項目打磨的城市大腦-交通產(chǎn)品線，已經(jīng)形成了一些規(guī)約流程來支撐幾十人的產(chǎn)品研發(fā)與項目交付，而處于孵化起步階段的工業(yè)、農(nóng)業(yè)等產(chǎn)品線，則以小團隊內(nèi)靈活組織的形式來支撐產(chǎn)品研發(fā)。下面列舉一些共性、有待改進的問題：l產(chǎn)品規(guī)劃層面的中長期目標不夠清晰，版本規(guī)劃不夠清晰。l缺少穩(wěn)定高效的渠道獲取達成產(chǎn)品目標的需求輸入。l需求描述不夠清晰，研發(fā)不能足夠理解，有頻繁修改甚至返工的風險。需求評審、UED評審、技術(shù)方案評審，缺少規(guī)范化組織形式，過程與產(chǎn)出并不高效。研發(fā)階段,范圍不鎖定導致研發(fā)節(jié)奏經(jīng)常被打亂，趕工等情況時有發(fā)生。缺乏標準化的代碼質(zhì)量管理機制，可能對測試與上線產(chǎn)生影響。缺乏測試人員，缺乏自動化測試工具。l缺少嚴格的上線發(fā)布流程，發(fā)布后的穩(wěn)定性保障較欠缺。l缺少成熟的產(chǎn)品部署方案，大量產(chǎn)品研發(fā)同學在干現(xiàn)場交付的工作。l基本只針對bug有反饋，缺少持續(xù)運營，缺少針對價值的持續(xù)跟蹤。第二方案階段：經(jīng)過前期調(diào)研，需要解決的問題不僅僅是在研發(fā)這個層面，規(guī)劃這個層面也需要關(guān)注，因此形成的方案要覆蓋三個方面：目標管理、業(yè)務(wù)規(guī)劃、產(chǎn)品交付。通過場景向目標看齊，需求向場景看齊，持續(xù)聚焦價值的交付。和產(chǎn)品研發(fā)核心目標是：持續(xù)、快速、高質(zhì)量地交付有用的價值?；谶@一目標，我們在實踐中沉淀形成了“ET大腦精益產(chǎn)品研發(fā)模式”。遵循的核心4個原則是：拉通、對齊、反饋、改進。具體包含9項關(guān)鍵活動：l目標對齊和管理l產(chǎn)品規(guī)劃l需求澄清l研發(fā)周排期l每日站會l持續(xù)發(fā)布l客戶實施l效能反饋及改進l業(yè)務(wù)反饋ET大腦精益產(chǎn)品研發(fā)模式概述產(chǎn)品研發(fā)的核心目標是：持續(xù)、快速、高質(zhì)量地交付有用的價值?；谶@一目標，我們在實踐中沉淀形成了“ET大腦精益產(chǎn)品研發(fā)模式”。它遵循的核心原則是：l拉通：聚焦客戶價值，拉通包含業(yè)務(wù)、產(chǎn)品、開發(fā)、測試、實施在內(nèi)的端到端價值交付過程，從而為系統(tǒng)的績效提升（而非局部的優(yōu)化）提供基礎(chǔ)。l對齊：以端到端的拉通為基礎(chǔ)，建立月規(guī)劃、周排期和日站會節(jié)奏，對齊目標、規(guī)劃和進度，從而保障價值的有效性和順暢交付。l反饋：建立產(chǎn)品研發(fā)反饋閉環(huán)和業(yè)務(wù)成果反饋閉環(huán)，提供即時、可靠的定性反饋和數(shù)據(jù)度量，從而為持續(xù)和深層次的研發(fā)效能和業(yè)務(wù)改進提供基礎(chǔ)。l改進：基于研發(fā)反饋閉環(huán)和業(yè)務(wù)反饋閉環(huán)，建立持續(xù)改進機制，定義、落實和跟蹤改進行動，從而持續(xù)地提升研發(fā)交付效能和組織業(yè)務(wù)效能。流程框架下圖描述了“ET大腦精益產(chǎn)品研發(fā)模式”的總體框架，具體包含：l端到端的研發(fā)流程l流程中的關(guān)鍵活動l研發(fā)和業(yè)務(wù)反饋閉環(huán)1、目標對齊和管理2、產(chǎn)品規(guī)劃3、需求澄清基于愿景目標、戰(zhàn)略規(guī)劃和用戶述求對齊各團隊目標。節(jié)奏：按月負責人：業(yè)務(wù)負責人參與人：業(yè)務(wù)負責人，產(chǎn)品負責人，技術(shù)負責人，PMO負責人基于業(yè)務(wù)需求、產(chǎn)品目標等輸入，抽象和組織需求，并規(guī)劃產(chǎn)品的版本和交付。節(jié)奏：每月一次，是版本開發(fā)的啟動活動負責人：PD參與人：技術(shù)TL、測試負責人和項目經(jīng)理分析和澄清需求，定義驗收標準，保證產(chǎn)品、開發(fā)和測試對需求的一致理解，做到以終為始。節(jié)奏：按需進行，發(fā)生在需求排期之前負責人:PD參與人：開發(fā)和測試.16I4、研發(fā)周排期5、每日站會6、持續(xù)發(fā)布需求小批量輸入，減少開發(fā)的并行度，保證高質(zhì)量的需求持續(xù)輸出和交付。節(jié)奏：每周負責人:PD/TL參與人：開發(fā)、測試和項目經(jīng)理促進團隊有效協(xié)作和聚焦，促進價值順暢流動和交付，同步需求進展和暴露問題及風險。節(jié)奏：每天負責人:TL/PM參與人：產(chǎn)品、開發(fā)和測試構(gòu)建高質(zhì)量的產(chǎn)品，及時響應(yīng)市場變化和縮短交付周期，減少發(fā)布時間和成本節(jié)奏：每周到每天負責人:開發(fā)、測試參與人：產(chǎn)品7、客戶實施8、效能反饋及改進9、業(yè)務(wù)反饋對外：為了滿足項目要求。對內(nèi)：為了建立效能研發(fā)業(yè)務(wù)反饋閉環(huán)，產(chǎn)品新版本在客戶側(cè)部署實施后，可以收集到客戶側(cè)的實際使用反饋。節(jié)奏：按需負責人:產(chǎn)品參與人：實施團隊獲得效能反饋，定義、跟蹤和落實改進項，建立效能持續(xù)改進機制節(jié)奏：每月負責人:TL/PMO參與人：產(chǎn)品、開發(fā)和測試為更好的達成業(yè)務(wù)目標，在需求發(fā)布后確認上線的效果，建立業(yè)務(wù)機制，從做正確的事出發(fā)節(jié)奏：按月負責人:產(chǎn)品負責人參與人：產(chǎn)品，開發(fā)負責人，PMO上圖標出了“ET大腦精益產(chǎn)品研發(fā)模式”的9個關(guān)鍵活動，它們串起了核心流程。后續(xù)章節(jié)將分別介紹這幾個關(guān)鍵活動，幫助大家快速掌握“ET大腦精益產(chǎn)品研發(fā)模式”。下表列出了這些活動的的目的、節(jié)奏和負責人，具體流程、方法等請參考各自對應(yīng)章節(jié)。4.試點階段：數(shù)據(jù)智能產(chǎn)品研發(fā)事業(yè)部產(chǎn)品成熟度各不相同，成熟較高的產(chǎn)品線往往經(jīng)過了挖坑填坑階段已經(jīng)探索成型了一套基本方法，不適宜作為試點對象，剛剛孵化的產(chǎn)品線往往業(yè)務(wù)方向處于摸索階段，同樣不適宜作為試點對象。ET工業(yè)大腦，無論是內(nèi)部創(chuàng)新驅(qū)動，還是外部商業(yè)項目需要，均會不斷給產(chǎn)品帶來新的需求輸入，正是處于適中迭代階段的產(chǎn)品，在產(chǎn)品團隊和研發(fā)團隊成員的支持下，其成為第一批試點對象。.18I方案的試點落地依賴思想建設(shè)和行動建設(shè)。思想建設(shè)的主要目的是讓產(chǎn)品同學和研發(fā)同學充分理解方案，清楚方案能幫助自己解決了哪些問題，以及會給自己帶來哪些新的工作量，知道自己如何參與；行動建設(shè)的主要目的是與產(chǎn)品和研發(fā)同學共同更加合理的落地具體活動，深入產(chǎn)品研發(fā)過程，將高階的方案結(jié)合產(chǎn)品特點，做細節(jié)填充與適配落地。思想建設(shè)，主要是通過組織集中培訓，完成方案背后精益交付原理的介紹，基于Aone（云效）實踐的案例分享，對相關(guān)的產(chǎn)品同學、研發(fā)同學、外包同學進行全覆蓋。行動建設(shè)，需要深度參與到產(chǎn)品研發(fā)過程中，參加各類例會，評審會，基于團隊已有的活動去落地試點方案。關(guān)鍵活動如下：分別針對核心PD和研發(fā)進行調(diào)研，形式可以面聊，也可以是發(fā)送調(diào)研問卷。產(chǎn)品經(jīng)理相關(guān)問題如下：l產(chǎn)品規(guī)劃的方式（需求的來源、規(guī)劃節(jié)奏、組織形式、參加人員等）？l如何做產(chǎn)品版本發(fā)布后的追蹤、價值運營？l需求管理現(xiàn)狀?如Aone（云效）、語雀、excel等。l請問PD如果跟進需求的落地進度（跟進的方式和頻度）？l交付周期當前的平均值大概是多久?從需求規(guī)劃確定納入版本計劃到需求最終的上線時間間隔。）l需求的類型包含哪些類業(yè)務(wù)類、技術(shù)類、算法類、數(shù)據(jù)類等。。。）l需求的交付過程中，各專業(yè)之間的流轉(zhuǎn)流程分那些階段：如（收集-梳理拆分-初步溝通-錄入需求-到PRD-.......到最后上線的完全的過程）？產(chǎn)品規(guī)劃及交付過程中的相關(guān)會議情況：當前所在的產(chǎn)品線，在產(chǎn)品規(guī)劃和研發(fā)交付過程中的痛點（最大的3點）和3個期望：產(chǎn)品架構(gòu)圖：本產(chǎn)品線的產(chǎn)品大圖，依賴的架構(gòu)圖等。參與該產(chǎn)品的各職能角色人員清單：【直接對模板進行修改】研發(fā)相關(guān)問題如下：l需求的管理，及開發(fā)任務(wù)的管理現(xiàn)狀?如Aone（云效）、語雀、excel等。l需求的交付過程中，各專業(yè)之間的流轉(zhuǎn)流程分那些階段：如（收集-梳理拆分-初步溝通-錄入需求-到PRD-.......到最后上線的完全的過程）？l進入待研發(fā)狀態(tài)的需求，準入條件是什么?l目前是如何對研發(fā)資源調(diào)配？l目前是如何如何管理研發(fā)進度？l是否有自動化測試？質(zhì)量如何保障？是否有專職測試？l目前管理缺陷BUG的方式（如Aone（云效）、語雀、excel等）？l目前如何做代碼部署及發(fā)布的？l所負責的產(chǎn)品中，阿里自有研發(fā)人數(shù)多少？外包研發(fā)人數(shù)多少？l所負責的產(chǎn)品中，是否存在產(chǎn)品共建？產(chǎn)品共建情況說明（共建內(nèi)容、共建合作伙伴名稱、合作伙伴接口人）產(chǎn)品規(guī)劃及交付過程中的相關(guān)會議情況：2.第一板斧：全鏈路精益協(xié)作及精益需求分析<20當前所在的產(chǎn)品線，在產(chǎn)品規(guī)劃和研發(fā)交付過程中的痛點（最大的3點）和3個期望：產(chǎn)品相關(guān)架構(gòu)圖：本產(chǎn)品線的產(chǎn)品大圖，依賴的架構(gòu)圖等。參與該產(chǎn)品的各職能角色人員清單：【直接對模板進行修改】目前一個需求的開發(fā)周期多久從需求的評審設(shè)計等確立清晰后，進入開發(fā)排期狀態(tài)開始到測試完成待發(fā)布狀態(tài)的時長。結(jié)合調(diào)研情況，尋找產(chǎn)品線的切入點，如工業(yè)大腦先從當前版本的需求價值流動切入，建立Aone（云效）看板，再逐步落地關(guān)鍵活動（日站會、周排期、月規(guī)劃、效能數(shù)據(jù)反饋、業(yè)務(wù)反饋等建立PD與研發(fā)的協(xié)作規(guī)則。工業(yè)大腦Aone空間：3.需求線上化（基于Aone（云效））為了進行需求的有效收口，以及支撐各個環(huán)節(jié)研發(fā)數(shù)據(jù)的積累，將需求上線至Aone（云效）是落地過程中的基礎(chǔ)動作，原則上需要投入研發(fā)資源的需求，必須100%線上化，畢竟研發(fā)資源是有限的，不能出現(xiàn)的隱藏的研發(fā)成本消耗。需求管理的方案:需求模板及工作流設(shè)置：需求模板和工作流設(shè)置需求模板產(chǎn)品研發(fā)層新項目空間創(chuàng)建成功后，首先重點關(guān)注的是需求，需求中最重要的需求模板和需求工作流的設(shè)置，這一節(jié)介紹需求模板的設(shè)置。鼠標光標到Aone（云效）頁面的左側(cè)一欄“設(shè)置”上面，會彈出浮層，選擇“服務(wù)管理”。2.第一板斧：全鏈路精益協(xié)作及精益需求分析<22進入服務(wù)管理頁面，點擊需求服務(wù)中的“設(shè)置”，如下圖：23>2.第一板斧：全鏈路精益協(xié)作及精益需求分析進入需求設(shè)置頁面，默認已配置好“產(chǎn)品類需求”這一類型的需求，如下圖點擊“產(chǎn)品類需求”可進入設(shè)置頁面。從“基本信息”切換到“模板”，配置需求模板信息（需求模板的內(nèi)容建議提前和PD共識如下圖：需求模板配置完成后，新建“產(chǎn)品類需求”會有需求模板出現(xiàn)，恭喜你“產(chǎn)品類需求”的模板已配置成功。2.第一板斧：全鏈路精益協(xié)作及精益需求分析<24設(shè)置需求工作流設(shè)置好需求模板后，設(shè)置需求工作流，默認的工作流在標準模板設(shè)置好，如下圖：更新工作流克隆一個新的工作流后，可以根據(jù)團隊實際情況進行添加狀態(tài)，“已選擇”、“待開發(fā)”、“待發(fā)布”和“已發(fā)布”這四個狀態(tài)建議保留，原因見下一節(jié)。添加必選狀態(tài)產(chǎn)品研發(fā)層的目的是為了促進價值順暢流動和交付，這里的價值就是指需求。為了要度量需求的流動和交付，定義了需求的響應(yīng)周期，包括交付周期和需求開發(fā)周期。25>2.第一板斧：全鏈路精益協(xié)作及精益需求分析需求交付周期默認從狀態(tài)“已選擇”到“已發(fā)布”，需求開發(fā)周期默認從狀態(tài)“就緒(待開發(fā))”到"待發(fā)布"，所以在工作流中把“已選擇”、“就緒(待開發(fā))”、“待發(fā)布”和“已發(fā)布”設(shè)置成必選狀態(tài)，工作流設(shè)置如下：高級設(shè)置如果團隊沒有交付周期和開發(fā)周期中的幾個默認狀態(tài)，可以在高級設(shè)置中設(shè)置交付周期和開發(fā)周期的起點和終點。工業(yè)大腦價值流：27>2.第一板斧：全鏈路精益協(xié)作及精益需求分析日站會的目標是：促進團隊有效協(xié)作和聚焦，促進價值順暢流動和交付，同時通過站會同步需求進展和暴露問題及風險，把可視化價值流實踐落地到位。日站會的方案請參見本案例集中另一案例：“每日站會：你的站會姿勢正確嗎？”。每日站會我們講講如何利用站會，更好地實現(xiàn)促進團隊有效協(xié)作和聚焦，促進價值順暢流動和交付，同時及時的暴露問題和風險。站會的目標說到站會，人們最熟悉的Scrum站會，典型的形式是團隊圍成一圈，依次回答三個問題：昨天做了什么？今天準備什么？有什么阻礙或問題？通過站會，Scrum團隊成員了解其他成員的工作，從而更好地協(xié)作，達成迭代目標?？窗宸椒☉?yīng)用得當，可視化價值流實踐執(zhí)行到位，以上三個問題完全可以清晰地展示在看板上，所以沒有必要再回答這些問題了。那站會的目標是什么呢？2.第一板斧：全鏈路精益協(xié)作及精益需求分回到精益看板方法本身的目標：順暢和高質(zhì)量地持續(xù)交付有用的價值。相應(yīng)的，看板站會要聚焦于價值的流動，而非個人工作。站會的目標是：促進團隊有效協(xié)作和聚焦，促進價值順暢流動和交付，同時通過站會同步需求進展和暴露問題及風險，把可視化價值流實踐落地到位。站會的前提在建立了如下圖的精益看板系統(tǒng)的可視化價值流，明確流轉(zhuǎn)規(guī)則和限制在制品數(shù)量的三個實踐之后，還需要管理價值流動和建立效能反饋閉環(huán)并持續(xù)改進。管理價值的流動具體包含管理價值流動過程，價值的輸入和價值的輸出，關(guān)于管理價值流動過程的一個很重要的實踐就是每日看板站會。關(guān)于如何建立精益看板系統(tǒng)，后續(xù)會有專門的文章來詳細講解。看板示例站會組織形式1.頻次：每天（每個工作日時長不超過15分鐘，一般在早上，具體時間團隊可根據(jù)實際情況調(diào)整，建議9:45或10點開始；2.三個相同：同一個團隊在同一時間、同一地點在看板前進行日站會，形成固定的節(jié)奏后，會變成團隊的習慣；3.協(xié)調(diào)人：團隊成員站在圍在看板前，由一位協(xié)調(diào)人來帶領(lǐng)團隊從右往左逐列走讀看板；協(xié)調(diào)人可以固定，也可以輪流進行；4.電腦：為了讓站會更加聚焦和高效，負責投屏和記錄的同學可以帶電腦，其他人不需要帶電腦；站會前：需求和任務(wù)的狀態(tài)已更新29>2.第一板斧：全鏈路精益協(xié)作及精益需求分析1.團隊已按照統(tǒng)一優(yōu)先級的規(guī)范更新需求的優(yōu)先級，輔助優(yōu)先級，狀態(tài)、期望日期等。2.開發(fā)同學按照實際情況更新需求和任務(wù)的狀態(tài)（任務(wù)向需求對齊）。l需求負責人負責協(xié)調(diào)把開發(fā)中的需求拆分成任務(wù)（如下圖并協(xié)調(diào)需求從開發(fā)完成，測試，直到發(fā)布完成為止；l已拆分好的任務(wù)需指派到個人，任務(wù)的顆粒度在1-2天的工作量，確保每天都有看得見的進展，及時暴露風險和問題；l任務(wù)責任人已更新好任務(wù)的狀態(tài)和截止日期；l如有外包-接口人合作：外包同學也需要在站會前更新狀態(tài)，接口人按照流轉(zhuǎn)規(guī)則進行狀態(tài)流轉(zhuǎn)。2.第一板斧：全鏈路精益協(xié)作及精益需求分析<30站會重點關(guān)注的信息站會上不需要檢視每一張卡片，本著“促進價值順暢流動和交付”的目的，我們要重點關(guān)注影響價值流動的問題和阻礙項，如下圖所示，絕大部分問題會標記橙色或紅色，可以很清晰地體現(xiàn)在看板上。l瓶頸和隊列：某個環(huán)節(jié)不順暢時，需求積壓形成隊列，這就是瓶頸所在，瓶頸是站會第一重點關(guān)注點，因為系統(tǒng)的流量往往是由瓶頸決定，只有解決了瓶頸問題，價值才能順暢地流動?？窗迳系谋憩F(xiàn)就是某一列的需求卡片數(shù)量特別多。l關(guān)鍵的缺陷：缺陷會阻礙需求的流動，而且缺陷多容易出現(xiàn)需求積壓，從而阻礙其他需求的流動。阻塞需求流動的缺陷需要及時解決，期待做到缺陷日清（缺陷發(fā)現(xiàn)后24小時內(nèi)解決，甚至當天就解決在Fixed狀態(tài)（指缺陷已修復，待提出缺陷者驗證）的缺陷需要及時驗證和關(guān)閉。保持缺陷及時發(fā)現(xiàn)即時解決和關(guān)閉，保持存量缺陷保持低水位。站會時需要抽1-2分鐘過一下整體缺陷的狀況。l重點關(guān)注的需求：指涉及重點商業(yè)利益或風險的重點需求，看板上會用紅色的標簽來l阻礙和問題：指因外部（如依賴）或內(nèi)部（如設(shè)計缺陷）原因無法正常流動的需求。團隊需關(guān)注被阻礙的需求，跟蹤和推動問題解決，及時恢復它們的流動?？窗迳蠒t色的阻礙項來標記。l到期或即將到期的需求：部分需求有明確的完成時間要求，例如存在對外承諾的需求。如果它們即將到期或已經(jīng)到期，就需要特別關(guān)注，以確保承諾的達成?？窗迳峡斓狡诘男枨髸贸壬癸@時間，已到期的需求會用紅色凸顯時間。l中斷：指某個步驟供給不足，價值流出現(xiàn)中斷，如上圖中，就緒（待開發(fā)）這列沒有需求，此時上游隊列需要盡快供給到該列。l未反應(yīng)在看板上的問題：走讀完看板，還需要添加一個問題：“是否有未反映在看板上的問題需要溝通”。團隊當然需要關(guān)注沒有反映到看板上的問題，同時，團隊和站會的協(xié)調(diào)人需要有意識地思考，這類問題是否可以和應(yīng)該反映在看板上，以提高可視化和執(zhí)行的效果。l站會中：促進價值順暢流動。l站會上：團隊按照"站會重點關(guān)注信息6+1"從右向左檢視各列，促進價值順暢流動，同時要避免在一個問題上花費過長時間，耗時長的討論要放在會后小范圍進行。15人以內(nèi)的團隊，站會要能在15分鐘內(nèi)完成，在現(xiàn)實中，效果不好的站會，往往耗時會比較長。站會中討論帶來的變化，需即時更新到看板上，如有問題，也需要及時記錄。下圖給出了站會中應(yīng)該做到和應(yīng)避免的問題：還需要明確的是，站會只是團隊溝通的一個場景，更多的溝通要在平時和更小范圍內(nèi)發(fā)生，而不是過度依賴于站會。2.第一板斧：全鏈路精益協(xié)作及精益需求分析<32站會后：信息透明，風險和問題跟進站會需要達成的成果：l看板已處于最新的狀態(tài)，反映站會討論的結(jié)果。l識別阻礙需求流動的問題，并現(xiàn)場解決或則安排會后跟蹤的Action。l團隊成員了解項目的整體進展和狀態(tài)。l團隊成員清楚工作的優(yōu)先級。l會后小范圍討論需求較長時間才能解決的問題?？偨Y(jié)：l站會的目標是：促進團隊有效協(xié)作和聚焦，促進價值順暢流動和交付。l站會要以價值交付為線索，從右向左檢視需求的狀態(tài)，聚焦于發(fā)現(xiàn)和處理價值流動中的問題。l不應(yīng)該依賴站會檢查每個人的工作，價值交付的狀態(tài)和問題應(yīng)該已清晰的體現(xiàn)在看板上，良好設(shè)計和應(yīng)用的看板是高效站會的基礎(chǔ)。l更多的協(xié)作應(yīng)該即時發(fā)生，不應(yīng)該完全依賴站會來進行團隊協(xié)作。l一個好的站會，幫助團隊了解整體的價值流動狀況，促進有效的協(xié)作，并即使處理價值流動的問題，保障價值順暢流動。站會Checklist:l需求和任務(wù)的狀態(tài)在站會前已更新；l提醒帶電腦同學合上電腦，只有投屏和做記錄的同學使用電腦；l從右往左檢視各列，按照6+1類關(guān)注點進行；l開發(fā)中的需求數(shù)量是否已超過卡片數(shù)量的限制；l開發(fā)中任務(wù)是否向需求對齊；l需求是否按照既定的流轉(zhuǎn)規(guī)則進行流轉(zhuǎn)；l單獨快速過一下缺陷的總體狀況，保持缺陷庫存低水位；l記錄要跟蹤的問題和依賴項；l會后小范圍討論遺留要解決的問題；33>2.第一板斧：全鏈路精益協(xié)作及精益需求分析站會中會碰到的問題：Q：在Scrum站會中，典型的形式是團隊圍成一圈，依次回答三個問題：昨天做了什么？今天準備什么？有什么阻礙或問題？為啥看板上不需要回答這三個問題了呢？A：看板方法應(yīng)用得當，可視化價值流實踐執(zhí)行到位，以上三個問題完全可以清晰地展示在看板上，所以沒有必要再回答這些問題了，同時我們需要按照需求來組織站會，關(guān)注價值流動，而不是按人來組織站會。Q：開發(fā)同學站會上講了很多，可產(chǎn)品經(jīng)理同學卻聽不懂，同時對需求的進展也不太清A：按照Scrum的方式，回答三個問題，開發(fā)同學往往說的是技術(shù)實現(xiàn)和細節(jié)，產(chǎn)品經(jīng)理自然會聽不懂。需求作為價值是產(chǎn)品經(jīng)理的輸入，看板關(guān)注的是價值流動，不是任務(wù)的完成情況，需求的狀態(tài)和問題可以很清晰地在看板上體現(xiàn)出來，同時在開發(fā)中的需求也會拆分成各端或各模塊的任務(wù)，拉通技術(shù)各角色之間的協(xié)同。這樣既可以看到價值的流動，也可以看到任務(wù)的進展和對齊，產(chǎn)品和開發(fā)同學都可以一目了然知道目前的進展與問題。Q：為啥看板要從右到左檢視各列，而不是從左到右檢視呢？A：從右往左，一方面體現(xiàn)價值拉動的方向，另一方面是為了更好地貫徹“暫緩開始，聚焦完成”的原則，讓接近完成的需求盡快的完成，而不是開始更多的需求開發(fā)。譬如測試中發(fā)現(xiàn)的Bug，從右到左更方便優(yōu)先解決Bug。Q：站會時間到了，但還有個別同學沒有到，是等他還是不等？A：團隊需要共識此類事情發(fā)生的機制，避免這樣的事情發(fā)生。當確實有個別成員遲到了，一般建議站會還要在固定的時間和地點進行，當然團隊對于遲到可以有團隊處理的辦法，譬如邀請遲到的同學給大家買水果吃等等。Q：團隊處于兩地，甚至多地，站會如何開？A：電子看板的好處就是便于異地開發(fā)，各地成員都打開看板頁面，同時用電話會議的方式接入，進行異地站會。目前Aone看板已可以做到需求卡片移動后瞬間同步。Q：兩個需求都進行了近一半?yún)s都不能提測？如下圖A：圖中用紅框圈起來的兩個需求，一個是前端任務(wù)已完成，后端任務(wù)在處理中，另一個是前端任務(wù)在處理中，后端任務(wù)已完成，這種情況需要避免，團隊需要聚焦其中一個需求，讓其快速完成，而不是啟動兩個，讓兩個都只是完成一半或90%。2.第一板斧：全鏈路精益協(xié)作及精益需求分析<34團隊開站會的照片：Aone（云效）協(xié)作域團隊：35>2.第一板斧：全鏈路精益協(xié)作及精益需求分析信息平臺訴訟團隊：阿里云飛天一部工業(yè)大腦：CEM客戶運營平臺的物理看板的站會：站會上很多人都帶電腦，效率就會相對低，不建議出現(xiàn)這種情況。37>2.第一板斧：全鏈路精益協(xié)作及精益需求分析工業(yè)大腦的日站會：周排期的目標是實現(xiàn)對就緒（待開發(fā)）隊列有節(jié)奏的填充，明確最近一次的發(fā)布計劃，讓準備好的需求持續(xù)的進入開發(fā)階段。周排期的方案（流程與步驟研發(fā)周排期周排期主要實現(xiàn)對就緒（待開發(fā)）隊列有節(jié)奏的填充，明確最近一次的發(fā)布計劃。l讓準備好的需求持續(xù)的進入開發(fā)階段l負責人和參與人l負責人：PD/TLl參與人：開發(fā)、測試和項目經(jīng)理操作流程2.第一板斧：全鏈路精益協(xié)作及精益需求分如上圖所示：就緒（待開發(fā)）隊列一般在已選擇（月規(guī)劃后確定要做的需求）隊列之后，開發(fā)團隊正式開始設(shè)計和實現(xiàn)之前，是開發(fā)團隊的輸入列，用以放置就緒（已澄清，只要有開發(fā)資源就可以開始實現(xiàn)的）的需求，就緒隊列是開發(fā)團隊的源頭，必須管理好。就緒隊列填充是指業(yè)務(wù)方與開發(fā)團隊從需求池中選擇接下來要做到需求，充分澄清和做出承諾后，將需求放入就緒隊列的過程。需求進入就緒隊列，意味著業(yè)務(wù)方和開發(fā)團隊雙方達成承諾業(yè)務(wù)方：這是我要的需求，原則上不會再變。開發(fā)團隊：我們理解這些需求了，會盡快開發(fā)完成。既然是雙方的承諾，就緒隊列填充就是雙方共同責任，參加會議的通常包含業(yè)務(wù)方（如產(chǎn)品經(jīng)理）和開發(fā)團隊（如開發(fā)和測試人員他們一起準備好足夠下一次填充會議前團隊去實現(xiàn)的需求。就緒隊列是開發(fā)團隊輸入列，就緒隊列填充是一個計劃活動，是周排期的一個重要活動，意味著也業(yè)務(wù)方和開發(fā)團隊的共同承諾。就緒隊列準入標準：l明確優(yōu)先級排序的需求列表。l需求已澄清，明確定義驗收標準，驗收標準包含：要解決的問題，用戶與系統(tǒng)的交互流程，具體業(yè)務(wù)規(guī)則和驗收標準。39>2.第一板斧：全鏈路精益協(xié)作及精益需求分析l需求過大時需拆分，需求顆粒度在一周內(nèi)能開發(fā)和測試完成，最大不能超過兩周。l已與業(yè)務(wù)關(guān)聯(lián)方（如有）確認相關(guān)計劃。l識別大的技術(shù)風險并定義應(yīng)對方案。l涉及三個（含三個）開發(fā)人員以上的需求，指定好協(xié)調(diào)人，負責進度協(xié)調(diào)。具體步驟周排期（每周固定一個時間段，團隊如有周會，可以把周排期放在周會上）需要包含的l根據(jù)上一周排期的情況查看需求完成情況。l檢查場景和需求發(fā)布和遺留情況，有可能調(diào)整優(yōu)先級。2.計劃：往將來看兩周的需求：l下一周排期的需求。l梳理場景計劃，做到需求向場景對齊，按照場景組織需求。l按照優(yōu)先級選擇和準備好適當數(shù)量的滿足就緒準入標準的需求，適當數(shù)量是保證在下次周排期前，團隊有足夠數(shù)量的需求做，但也不應(yīng)太多，稍有富余即可。l下下周的需求準備：下下周準備排期的需求，為UED設(shè)計預留時間。l本期已排期的需求列表項目空間中用“迭代”標識本期已排期的需求。l確定需求的提測和發(fā)布計劃，提測時間點離周排期當天的兩周以后的，需確認需求顆粒度是否過大，如是需求顆粒度（超過兩周才能開發(fā)測試完成）比較大的情況，需要做需求拆分，拆分到一周內(nèi)。l明確已排期需求的計劃提測時間點。l明確已排期需求的計劃發(fā)布時間點。l明確最近一次的發(fā)布計劃，包含發(fā)布時間和發(fā)布范圍。2.第一板斧：全鏈路精益協(xié)作及精益需求分析<40工業(yè)大腦周排期：周排期周排期作為ET大腦精益產(chǎn)品研發(fā)模式重要的組成部分，在月規(guī)劃會議部署的場景及主要需求的實現(xiàn)過程中起到承上啟下的作用。對就緒（待開發(fā)）隊列有節(jié)奏的填充，明確最近一次的發(fā)布計劃。讓準備好的需求持續(xù)的進入開發(fā)階段。時間：每周一下午17:00-18:00地點：xx會議室遠程參與方式：投屏+電話+阿里郎會議組織者：沐瑾輔助組織者：PA同學與會者：輸入l上上個迭代的發(fā)布情況、未完成需求和遺留情況。l上上個迭代的發(fā)布評審紀要。l上個迭代的需求完成情況。l下個迭代配置。l可能出現(xiàn)的優(yōu)先級調(diào)整。l預計進入本次迭代的需求已進入“待排期”，符合“就緒（待開發(fā)）”的準入標準。過程l總結(jié)上上個迭代發(fā)布后的完成情況和遺留問題。l回顧上次個代開發(fā)（測試）的完成情況，潛在的優(yōu)先級調(diào)整。l安排當前迭代的需求，排列優(yōu)先級和輔助優(yōu)先級。l計劃下個迭代的需求，本周需要評審和設(shè)計的需求。輸出l本次迭代的需求列表，可能還包含上上次迭代和上次迭代遺留的需求和新產(chǎn)生的需求。l可能影響交付的風險列表。l會后遺留工作。l會議紀要。周排期輸出的需求checklistl業(yè)務(wù)方：這是我要的需求，原則上不會再變。l開發(fā)團隊：我們理解這些需求了，會盡快開發(fā)完成。l需求的狀態(tài)是“就緒（待開發(fā)）”。l需求有歸屬的版本。l需求有歸屬的迭代。l需求有合理的期望日期。前文提到VUCA時代要擁抱變化是從偏宏觀層面去看的，微觀到某個產(chǎn)品的研發(fā)過程，其節(jié)奏一定是主動規(guī)劃，而非被動響應(yīng)的，只看眼前不看未來是無法保障產(chǎn)品的競爭力的。產(chǎn)品月規(guī)劃，正是承接產(chǎn)品目標到產(chǎn)品需求的關(guān)鍵環(huán)節(jié)，明確一個月，前瞻三個月，是基本要求。月規(guī)劃的方案：產(chǎn)品月規(guī)劃l業(yè)務(wù)場景：可發(fā)布和運營的基本單元，有明確業(yè)務(wù)目標，提供完整業(yè)務(wù)能力。2.第一板斧：全鏈路精益協(xié)作及精益需求分析<42l需求：可測試和部署的基本單元，是用戶可感知的功能，服務(wù)于具體的業(yè)務(wù)場景。產(chǎn)品規(guī)劃的來源有很多，比如說來自業(yè)務(wù)的整體規(guī)劃、客戶輸入的原始需求、體驗的優(yōu)化及技術(shù)改造等等。產(chǎn)品規(guī)劃就是要綜合這些輸入，從業(yè)務(wù)目標出發(fā)，通過以實現(xiàn)業(yè)務(wù)場景來發(fā)現(xiàn)并設(shè)計產(chǎn)品需求，最終形成有效組織的產(chǎn)品需求列表和具體的交付節(jié)奏。所以，整個產(chǎn)品規(guī)劃，需要有明確的業(yè)務(wù)目標，及為了完成業(yè)務(wù)目標的業(yè)務(wù)場景。所有產(chǎn)品需求以實現(xiàn)業(yè)務(wù)場景為目標。通過完成產(chǎn)品需求，來快速實現(xiàn)業(yè)務(wù)場景，并形成業(yè)務(wù)目標的反饋閉環(huán)。產(chǎn)品規(guī)劃需要做到以下幾點：l明確業(yè)務(wù)階段目標（目標需要SMART化各團隊間的目標和進度對齊，明確依賴方和被依賴方的協(xié)作；l按場景分析和組織產(chǎn)品需求，業(yè)務(wù)場景向業(yè)務(wù)目標對齊，產(chǎn)品功能向業(yè)務(wù)場景對齊；l既見樹木又見森林：既能看到產(chǎn)品全貌，又能看到各場景和需求；l能基于場景進行測試和交付，快速交付完整的業(yè)務(wù)場景，并形成業(yè)務(wù)閉環(huán)；需求的組織層次如下圖：43>2.第一板斧：全鏈路精益協(xié)作及精益需求分析場景規(guī)劃和業(yè)務(wù)流程以下圖的方式呈現(xiàn)：操作流程參與人召集人：產(chǎn)品負責人參與方：產(chǎn)品團隊、技術(shù)TL、被依賴方和PMO時間：按產(chǎn)品版本的計劃進行，每月進行一次。發(fā)生在具體的需求評審之前，為后續(xù)的需求設(shè)計和評審做準備。輸入上一次產(chǎn)品規(guī)劃的業(yè)務(wù)場景完成情況、目標和結(jié)果評價和Review，如下圖：2.第一板斧：全鏈路精益協(xié)作及精益需求分析<44l明確的下一版本業(yè)務(wù)目標、要解決的客戶問題和下一季度的目標；l實現(xiàn)下一版本業(yè)務(wù)目標和解決客戶問題所需要的業(yè)務(wù)場景；l業(yè)務(wù)場景列表及其目標的描述和明確的驗收標準（如帶來了什么價值，解決了什么問題，具備了什么能力，提升了性能等，各項需要包含時間、范圍和閾值，譬如數(shù)據(jù)處理時長從60分鐘縮短到30分鐘）；l服務(wù)業(yè)務(wù)場景所需要的業(yè)務(wù)步驟和功能需求列表；操作步驟進展回顧：回顧上一月規(guī)劃完成情況和業(yè)務(wù)目標達成情況；對齊目標：對齊產(chǎn)品近一月和近一個季度的目標，保障業(yè)務(wù)團隊方向一致；業(yè)務(wù)場景梳理：l列出版本業(yè)務(wù)目標及各業(yè)務(wù)目標對應(yīng)的衡量指標；l列出支持版本業(yè)務(wù)目標的業(yè)務(wù)場景和最小MVP場景；l列出實現(xiàn)該業(yè)務(wù)場景的產(chǎn)品需求（需要確認：列出的需求全部發(fā)布后，業(yè)務(wù)場景也可完整發(fā)布）；l按業(yè)務(wù)優(yōu)化級排列業(yè)務(wù)場景和產(chǎn)品需求；l版本計劃：要有明確的版本計劃并對應(yīng)到客戶；l列出需求的優(yōu)先級（優(yōu)先級+輔助優(yōu)先級）；l列出需求（功能點）的依賴項，及依賴相關(guān)方。輸出l確定的規(guī)劃版本目標和可解決的客戶問題；l確定的業(yè)務(wù)場景及優(yōu)先級；l明確的業(yè)務(wù)場景驗收標準；l明確支撐業(yè)務(wù)場景的產(chǎn)品功能需求最小集，并排優(yōu)先級，并能落到具體團隊；l明確的發(fā)布時間，版本，外部依賴及潛在風險；l相關(guān)依賴的時間安排。45>2.第一板斧：全鏈路精益協(xié)作及精益需求分析方法和實踐影響地圖用戶故事地圖工具支持用戶故事地圖Aone（云效）規(guī)劃項服務(wù)l以數(shù)據(jù)資源平臺為例，把規(guī)劃項（業(yè)務(wù)場景）和需求按如下方式錄入到Aone空間；l規(guī)劃項在規(guī)劃層的父項目中，需求在研發(fā)層（交付層）的子項目中；在Aone（云效）上更新：包括目標、場景和需求的對應(yīng)關(guān)系，場景和需求的版本號，場景和需求的優(yōu)先級。2.第一板斧：全鏈路精益協(xié)作及精益需求分產(chǎn)品規(guī)劃看板檢查清單實例數(shù)據(jù)資源平臺月規(guī)劃已交付業(yè)務(wù)場景效果反饋情況工業(yè)大腦月規(guī)劃工業(yè)大腦月規(guī)劃：形式：所有PD+研發(fā)TL，通過客戶視角-業(yè)務(wù)視角-產(chǎn)品視角，層層展開，將客戶提出的業(yè)務(wù)場景細分至多個子產(chǎn)品支撐。時間：每月中旬，規(guī)劃下月底要發(fā)布的內(nèi)容。47>2.第一板斧：全鏈路精益協(xié)作及精益需求分析2.第一板斧：全鏈路精益協(xié)作及精益需求分效能度量和反饋是系統(tǒng)呈現(xiàn)團隊持續(xù)交付價值的能力，通過深入分析和分解問題，找出導致問題的根因，從而驅(qū)動系統(tǒng)性的改進。效能反饋及改進的方案：效能反饋及改進效能度量和反饋是系統(tǒng)呈現(xiàn)團隊持續(xù)交付價值的能力，通過深入分析和分解問題，找出導致問題的根因，從而驅(qū)動系統(tǒng)性的改進。團隊復盤是持續(xù)改進的發(fā)動機，它是當前階段改進的起點，結(jié)合當前的效能度量數(shù)據(jù)，同時也是上一次復盤的檢查點。旨在參與復盤同學一同為團隊的持續(xù)改進貢獻自己的想法，加深大家對同一問題的認識，達成共識，形成改進項，并能落地。操作流程參與人召集人：技術(shù)TL參與方：產(chǎn)品、開發(fā)和測試時間：每月一次，可在每月版本發(fā)布進行輸入：按照持續(xù)價值交付能力度量維度提供度量數(shù)據(jù)和圖表，提前準備好數(shù)據(jù)解讀操作步驟l建立平臺：[描述清楚-WHY(為了)-]l信息收集:[做的好的，需要改進的]l發(fā)現(xiàn)洞察49>2.第一板斧：全鏈路精益協(xié)作及精益需求分析l信息分類l根因分析l明確方案l落實行動主要檢查項：l數(shù)據(jù)收集及分析：缺陷數(shù)據(jù)分析、交付效率數(shù)據(jù)分析l團隊成員反饋l形成基于流程操作、基礎(chǔ)環(huán)境、代碼設(shè)計、測試守護或人員技能的改進項l形成團隊持續(xù)改進待辦列表，并檢查改進項清單輸出l團隊持續(xù)改進待辦列表l方法和實踐lScrumRetrospective附1：持續(xù)價值交付能力效能改進的度量維度2.第一板斧：全鏈路精益協(xié)作及精益需求分析<50附2：數(shù)據(jù)智能產(chǎn)品事業(yè)部的效能目標50%的需求實現(xiàn)111的目標：工業(yè)大腦效能review：業(yè)務(wù)反饋周期往往較長，需要將產(chǎn)品交付至項目中，讓用戶使用一段時間，再進行關(guān)鍵用戶或者關(guān)鍵合作伙伴的業(yè)務(wù)反饋收集，此部分實踐目前正在進行中?；趯I(yè)大腦以及其他產(chǎn)品線試點的總結(jié)，整體方案自身也會迭代優(yōu)化，再結(jié)合不同產(chǎn)品線的成熟度、特有痛點、人員結(jié)構(gòu)，目前正在全面推廣方案的落地。從實踐的過程看，統(tǒng)一性更多是體現(xiàn)在體系框架以及框架下的關(guān)鍵動作，差異性更多是在關(guān)鍵動作執(zhí)行層面去結(jié)合產(chǎn)品研發(fā)現(xiàn)狀，例如：零基礎(chǔ)的產(chǎn)品線可以完全參照，有一定基礎(chǔ)的產(chǎn)品線去做適配，最終形成的是產(chǎn)品線特有的活動月歷，活動的組織形式與標準。2.具體產(chǎn)品線的抓手怎么找？整體來說，抓手一定是因產(chǎn)品線而異，痛點可能分布在業(yè)務(wù)規(guī)劃、需求管理、研發(fā)過程、質(zhì)量管理等等；一種具體到快速的方法可以是分層級的痛點調(diào)研，對象可以是Leader，PD，Dev等等，先取Top3痛點，再取Overlap。在數(shù)據(jù)智能產(chǎn)品研發(fā)事業(yè)部的主航道上亟需具備競爭力的產(chǎn)品，產(chǎn)品一定是出自具備競爭力的組織，競爭力的基礎(chǔ)是組織能夠高效運行，那么一定需要適配的方法體系。方法的落地過程不會是理想化的“一拍即合”，更多是現(xiàn)實化的“慢慢磨合”，ET大腦精益產(chǎn)品研發(fā)的實踐已經(jīng)起航，未來將繼續(xù)全速推進。寶劍鋒從磨礪出，梅花香自苦寒來，每一位參與這個過程中的同學，都是在為組織達到新的高度儲備力量。本文作者：肖宏飛2.2實踐案例二云效助力互聯(lián)網(wǎng)+醫(yī)療「遠圖互聯(lián)」提效目前越來越多的企業(yè)開始有了從“研發(fā)信息化”走向“研發(fā)數(shù)字化”的需求和想法，云效在幫助企業(yè)做數(shù)字化轉(zhuǎn)型的道路上也是越走越穩(wěn)，今天給大家分享的是云效怎么幫助客戶解決需求管理復雜的問題的。浙江遠圖互聯(lián)科技股份有限公司是一家互聯(lián)網(wǎng)+健康醫(yī)療整體解決方案提供商，通過互聯(lián)網(wǎng)+健康醫(yī)療區(qū)域服務(wù)平臺提供SAAS化平臺服務(wù)，致力于為患者提供就診全流程優(yōu)化服務(wù)。在互聯(lián)網(wǎng)+醫(yī)療快速發(fā)展的趨勢下，公司業(yè)務(wù)高速發(fā)展，產(chǎn)品線以及團隊規(guī)模也在快速擴張。當前產(chǎn)品研發(fā)團隊已超過200人，對團隊協(xié)作、研發(fā)效能提升帶來了很大挑戰(zhàn)，傳統(tǒng)的項目管理方式難以持續(xù)，出現(xiàn)了越來越多的問題。當團隊在內(nèi)需推動下，探索新的效能提升方案，尋求突破升級之際，阿里巴巴云效2020走進了我們的視線。從人員組織結(jié)構(gòu)上，產(chǎn)品研發(fā)團隊分為產(chǎn)品、前端、后端、測試，研發(fā)運行按產(chǎn)品線采用虛擬團隊的方式。為了提高人員利用率，以及對緊急任務(wù)進行快速處理，一個人有時會負責多個虛擬團隊的事務(wù)，產(chǎn)品線與人員組織關(guān)系如下圖所示：53>2.第一板斧：全鏈路精益協(xié)作及精益需求分析在需求來源上，由于公司基于城市區(qū)域SAAS平臺模式對外提供服務(wù)，采用項目簽單模式進行交付式合作，一般每個業(yè)務(wù)線的需求來源包括：區(qū)域項目交付需求、區(qū)域項目售后以及產(chǎn)品運營規(guī)劃，需求來源如下圖所示：隨著簽約及上線的區(qū)域越來越多，需求來自多方，且緊急程度不一，需求變更以及緊急需求插入也變得難以管控，整體的需求管理復雜度越來越高。需求產(chǎn)生的任務(wù)分解、排期、人員協(xié)調(diào)難度也變得越來越大，管理和溝通消耗了大量資源。為了完成需求交付，研發(fā)團隊長期高壓力高負荷運行，但項目交付延期的情況依然較嚴重。由于管理和研發(fā)工作沒有清晰留痕，流程優(yōu)化和升級也無從著手?；谝陨蠁栴}，需求管理模式升級也變得越來越迫切。在引入云效2020之前，研發(fā)團隊曾經(jīng)嘗試過以下方案：2.第一板斧：全鏈路精益協(xié)作及精益需求分析<54采用表格的方式進行任務(wù)分配管理，把任務(wù)分解到人，并進行研發(fā)排期管理。這種方式存在幾個比較嚴重的弊端：l表格文檔不利于共享，維護后無法通知到個人；l由于多個產(chǎn)品線并行，很難跟蹤每個人進行中的任務(wù)，排期難度較大；l歷史記錄難以維護，不利于問題分析；l需求、文檔、任務(wù)管理是分離的，需求描述及交付相關(guān)文檔不能統(tǒng)一管理。采用釘釘任務(wù)對需求分版本進行任務(wù)分解和排期，在一定程度上解決了進度狀態(tài)同步的問題，歷史交付也在一定程度上有所留痕，但依然存在一些不足的地方：l不支持跨產(chǎn)品虛擬團隊人員的全量任務(wù)跟蹤；l不支持需求描述和資料關(guān)聯(lián)；l缺乏整體性的、框架式的需求看板。為了加強從需求到產(chǎn)品的合理管控，控制研發(fā)周期，提高交付質(zhì)量，我們對整個研發(fā)流程與每個階段的產(chǎn)物進行了規(guī)范：l需求必須經(jīng)過嚴格分析，有清晰完整的產(chǎn)品方案和交互稿；l部分需求必須有完整的技術(shù)方案，且進行評審后，方可進行開發(fā)；l產(chǎn)品發(fā)布需經(jīng)產(chǎn)品驗收，方可發(fā)布等等…從需求到交付全流程如下圖所示：55>2.第一板斧：全鏈路精益協(xié)作及精益需求分析需求開發(fā)進度在云效看板中清晰可見：需求拆解成不同類型的任務(wù)進行執(zhí)行，任務(wù)清晰到人，完成時間明確，可以有效控制需求交付時間，任務(wù)開發(fā)進度如下圖所示：通過每日站會，基于看板同步任務(wù)狀態(tài)，從整體上反映一個項目進展情況；通過云效還可方便地跟蹤團隊成員任務(wù)情況，查看指定人員當前手頭上的任務(wù)；4.任務(wù)產(chǎn)出管理云效知識庫提供了豐富的文檔工具，可在線共享項目文檔，團隊成員可見，需求與知識庫關(guān)聯(lián)，便于鏈接并查看；57>2.第一板斧：全鏈路精益協(xié)作及精益需求分析出于加強質(zhì)量監(jiān)督的目的，質(zhì)量控制與測試團隊在組織架構(gòu)上是獨立部門，有其相應(yīng)的管理要求。在云效上我們建立了獨立的研發(fā)質(zhì)量管理項目，通過以下步驟跟蹤管理測試任務(wù)：l研發(fā)質(zhì)量管理項目創(chuàng)建提測需求；l測試任務(wù)關(guān)聯(lián)提測需求；l測試同學負責維護需求和任務(wù)狀態(tài)。測試完成后發(fā)布測試報告，研發(fā)同學執(zhí)行發(fā)布計劃，然后基于發(fā)布計劃在云效流水上進行功能發(fā)布基于云效2020，結(jié)合自定義的研發(fā)流程，實現(xiàn)了需求分解、開發(fā)排期、人員分配、狀態(tài)跟蹤，達到了需求任務(wù)管理清晰、便于跟蹤的目標，解決了需求管理復雜的問題。同時基于云效的強大功能，還帶來了更多的附加價值和效能提升：59>2.第一板斧：全鏈路精益協(xié)作及精益需求分析第一階段的目標已順利完成，達到了預期的效果，但離設(shè)想中的完整形態(tài)還有一些距離，后續(xù)將繼續(xù)探索云效2020的各項能力，基于云效2020完成整個研發(fā)生命周期的管理：l代碼庫的管理，打通需求與代碼管理的連接；l代碼庫與流水線的連接；l代碼質(zhì)量管理，包括代碼提交審核流程、代碼檢測工具的使用等；l充分利用云效的數(shù)據(jù)統(tǒng)計分析能力，發(fā)現(xiàn)問題，提高研發(fā)效能。特別感謝本文的案例作者：燕強，平臺技術(shù)團隊負責人，負責遠圖平臺技術(shù)團隊的研發(fā)管理、架構(gòu)設(shè)計工作，主導互聯(lián)網(wǎng)醫(yī)療、互聯(lián)網(wǎng)醫(yī)院等產(chǎn)品線以及基礎(chǔ)平臺建設(shè)。致力于研發(fā)管理流程優(yōu)化，研發(fā)效能提升以及研發(fā)管理變革的推動落地。2.第一板斧：全鏈路精益協(xié)作及精益需求分析2.3實踐案例三敏捷團隊的病與藥——阿里健康醫(yī)藥B2B團隊敏捷轉(zhuǎn)型手記2017年10月，應(yīng)阿里健康研發(fā)部負責人邀請，我開始幫助阿里健康的研發(fā)團隊敏捷轉(zhuǎn)型。醫(yī)藥B2B是第一個吃螃蟹的試點團隊。沒想到，這個試點一點兒也不輕松：每次上線都出問題，好不容易BD來的客戶都流失了，業(yè)務(wù)團隊急得冒火；研發(fā)團隊已經(jīng)996超過兩個月，辛苦又焦慮，竟然全都病倒了。這是一個5月才上線的新業(yè)務(wù)，如果不能抓住機會證明自己，未來發(fā)展岌岌可危。幸運的是，我們挺過來了。經(jīng)過3個月的持續(xù)改進，不僅質(zhì)量、響應(yīng)力和發(fā)布能力有了顯著提升，業(yè)務(wù)也找到了突破口：2.第一板斧：全鏈路精益協(xié)作及精益需求看到團隊不斷進步，如同醫(yī)生看到病人漸漸痊愈，我由衷地高興。我不禁想到，敏捷教練輔導團隊跟醫(yī)生幫助病人康復有不少相似之處：1.二者都需要“望聞問切”，系統(tǒng)全面分析問題，才能做出正確判斷。2.療效如何要看病情是否緩解，要盡快建立反饋環(huán)，獲得客觀全面的反饋。3.有哪些治療方案，各方案的好處弊端都要一五一十告訴病人，由病人選擇治療方案。病人做好準備再開始治療，不可欺騙病人，更不可威逼利誘。4.治療過程并非坦途，病人中途膽怯退縮在所難免。唯有熱情鼓勵和耐心引導，不可遇難而退。5.授人以魚不如授人以漁，教會病人強身健體的方法，病人可以自助甚至助人，才是上佳結(jié)果。6.讓我們一起來看看，如何幫助敏捷團隊擺脫困境，走出低谷。10月我進團隊調(diào)研時，發(fā)現(xiàn)問題真不少：63>2.第一板斧：全鏈路精益協(xié)作及精益需求分析感謝團隊信任我這個三腳貓大夫，大家一起摸索試錯，終于找到了解藥：我為大家一一詳述。2.第一板斧：全鏈路精益協(xié)作及精益需求分析剛進團隊時我竟然找不到一個熟悉業(yè)務(wù)的開發(fā)同學。原來職能經(jīng)理每個月按需求分配資源，大家臨時搭伙做項目。B2B特別艱苦，開發(fā)同學堅持了一個月就要求換業(yè)務(wù)。難怪業(yè)務(wù)同學最大的愿望就是研發(fā)同學穩(wěn)定，不然總要給新來的開發(fā)講業(yè)務(wù)，剛講明白就換人了。我跟職能經(jīng)理一個個聊，終于各端開發(fā)和測試經(jīng)理都答應(yīng)未來三個月內(nèi)現(xiàn)有研發(fā)同學至少50%的時間做B2B業(yè)務(wù)。50%是個神奇的數(shù)字，如果一件事占到了50%以上的時間，就不能不重視它的結(jié)果并為之努力。研發(fā)同學開始關(guān)注業(yè)務(wù)指標了。65>2.第一板斧：全鏈路精益協(xié)作及精益需求分析非常感謝B2B業(yè)務(wù)負責人的支持，特意出差過來給大家講業(yè)務(wù)目標和業(yè)務(wù)打法。藥品流通環(huán)節(jié)最多有7層，通過B2B平臺，可以減少到3層。研發(fā)同學第一次感受到自己的工作跟千萬人的生活息息相關(guān)。一個區(qū)域內(nèi)藥品批發(fā)的龍頭企業(yè)（大B）只有幾家，做砸了一家，這個區(qū)域就很難開展業(yè)務(wù)了。零售終端（小B）非常分散，都是業(yè)務(wù)小二一家家跑下來的。聽到業(yè)務(wù)同學三伏天騎著電瓶車拜訪客戶中暑摔倒了，大家都有些動容。很快，研發(fā)團隊立下了軍令狀：上線質(zhì)量要好，交付速度要快。大家終于擰成了一股繩。立了軍令狀還不夠，做得怎么樣，還要看反饋。工作項進Aone（云效），大家隨時都能看到研發(fā)進展和度量數(shù)據(jù)。真正做到目標對齊，過程透明。3.打開范圍鎖，嚴把質(zhì)量關(guān)發(fā)布質(zhì)量差導致線上問題多，修復線上問題打斷了新功能開發(fā)。業(yè)務(wù)和研發(fā)團隊之間還沒有建立起信任，大家更像是合同博弈，上線時間和范圍早早就鎖定了。沒有持續(xù)集成和自動化測試，全靠手工測試回歸，測試時間又一再被壓縮，發(fā)布質(zhì)量可想而知。本來可以白天發(fā)布，對質(zhì)量沒信心，推遲到半夜沒有交易了才敢發(fā)布。發(fā)了改，改了再發(fā)，折騰到后半夜幾乎成了發(fā)布日的慣例。要打破這個惡性循環(huán)，先從打開范圍鎖入手。我跟業(yè)務(wù)團隊商量，有嚴格截止日期的需求保證按時發(fā)布，其它功能符合發(fā)布標準才發(fā)布，不能讓客戶承擔質(zhì)量風險。業(yè)務(wù)團隊答應(yīng)試一個月。我跟測試同學對線上問題做了回歸分析，有針對性地增加了回歸測試用例。發(fā)布前一天做上線評審，不符合發(fā)布標準的一律打回。符合發(fā)布標準的上線前都要有預案，代碼回滾、數(shù)據(jù)訂正都在預發(fā)環(huán)境演練過，避免出現(xiàn)問題時手忙腳亂。試了一段時間，效果很明顯。原本每次上線都出問題，11月發(fā)布成功率提高到了50%，12月更是17次發(fā)布100%成功。隨著發(fā)布信心的提升，發(fā)布時間也改到了白天，發(fā)布日再也不用熬夜加班啦。4.協(xié)作澄清需求67>2.第一板斧：全鏈路精益協(xié)作及精益需求分析正如質(zhì)量不只是測試的事，需求也不只是產(chǎn)品經(jīng)理的事。做產(chǎn)品如同尋寶，產(chǎn)品經(jīng)理好比向?qū)?，知道寶貝在哪里；技術(shù)同學好比駕駛員，最了解車子的性能。大家一起想辦法，才能快速又經(jīng)濟地找到寶貝。有些技術(shù)同學一心只想寫代碼，殊不知代碼是客觀世界的映照，符合業(yè)務(wù)模型才易于維護和拓展。更何況很多隱性的業(yè)務(wù)知識無法用語言傳遞，談需求時好像都共識了，驗收時才發(fā)現(xiàn)想的根本是兩回事。既然是一個團隊，當然要協(xié)作。需求是源頭，協(xié)作就從需求共創(chuàng)開始。業(yè)務(wù)和產(chǎn)品大致梳理出需求概要，就拉上技術(shù)同學一起梳理。全體都參與需求梳理不現(xiàn)實，業(yè)務(wù)、產(chǎn)品加上一位開發(fā)和測試組成跨職能的需求小組。先弄明白需求給誰做，解決什么問題，大家再一起尋找解決方案。討論過程中，大家不自覺就突破了角色的限制，研發(fā)開始關(guān)注業(yè)務(wù)價值，業(yè)務(wù)開始關(guān)注技術(shù)可行性。好玩的是，B2B團隊由開發(fā)同學講解需求，產(chǎn)品經(jīng)理補充答疑。團隊先后做了兩個營銷玩法的需求。第一個需求，評審時技術(shù)同學才參與，上線半個月了還有各種問題。第二個需求，用共創(chuàng)方式，上線后立即就能做活動，活動效果也特別好。2.第一板斧：全鏈路精益協(xié)作及精益需求分析<68工欲善其事，必先利其器。用戶故事地圖和實例化需求雙劍合璧，是協(xié)作梳理需求的利器。用戶故事地圖最大的好處是一張圖看到全貌。此外，從用戶角色和用戶目的出發(fā)，逼得我們想清楚需求的價值。想明白了價值，再逐個場景梳理用戶旅程，走完一個旅程就能幫用戶解決一個場景的問題。實例化需求最適合厘清復雜的業(yè)務(wù)規(guī)則。如圖所示，PRD上兩句話，深究下去，竟然要用8個例子才能說明白?？雌饋硇枨笫崂砘艘恍r間，實際上開發(fā)過程會省時間。拿到需求就開始寫代碼，并不一定最快。有一個H5頁面反復改了6次，兩周才做完。如果想明白再做，最多半天就搞定了。69>2.第一板斧：全鏈路精益協(xié)作及精益需求分析如果按照從簡單到復雜，從主流程到異常場景的順序梳理用戶故事地圖，很容易確定發(fā)布優(yōu)先級。如同地鐵可以分段通車，一個用戶旅程的功能也可以分段交付，只要交付的功能對用戶有價值就行。圖中的營銷活動需求，就分了好幾段交付：先上線給運營同學用的后臺功能，可以創(chuàng)建活動、配置活動和展示活動，運營同學可以預熱招商了；接下來支持正向和逆向交易的價格調(diào)整，用戶下單可以享受折扣了；為了控制活動預算，活動中要實時展示預算消耗；最后，支持每月一次跟商家對賬。對賬是離線統(tǒng)計，只要在活動開始后第一個對賬日之前上線就行。2.第一板斧：全鏈路精益協(xié)作及精益需求分析<70有了優(yōu)先級，開發(fā)按照輕重緩急逐步開工，每周都有功能提測，符合發(fā)布標準的盡快上線。發(fā)布次數(shù)增加了，發(fā)布范圍變小了，風險分攤了，質(zhì)量更好了，上線前也不用集中加班了，讓大家提心吊膽的bigbangrelease消失了。71>2.第一板斧：全鏈路精益協(xié)作及看板的5個核心實踐在團隊中如何落地呢？首先，在Aone（云效）中建立工作流，每天更新需求狀態(tài)，所有人隨時都可以看到最新進展。關(guān)鍵狀態(tài)的流轉(zhuǎn)，團隊討論確定了三個標準：定標準不難，自律自治執(zhí)行到位才是關(guān)鍵。以開工標準為例，全票通過的需求才能進入開發(fā)，倒逼需求小組認真準備。結(jié)果需求評審進行得更快了，需求質(zhì)量提高了，返工浪費減少了。限制在制品數(shù)量（WIP）常常成為看板方法落地的難點，其實做起來并不難。WIP初始值可以按照每人處理一個需求來設(shè)置，如果團隊有5個開發(fā)，那么開發(fā)中的需求最多5個。同時一定要按照優(yōu)先級拉動需求，遇到緊急需求插隊，就先中斷最低優(yōu)先級需求。確保每位同學每一個時刻只處理一個需求，盡量避免上下文切換帶來的開銷。領(lǐng)了需求，除非遇到不可抗力，一定要想辦法完成。不能遇到困難就放在一邊，再開始一個容易的需求。因為我們的目標不是開始更多，而是一旦開始就盡快完成。在產(chǎn)品/開發(fā)和開發(fā)/測試之間設(shè)立緩沖區(qū)，時刻關(guān)注緩沖區(qū)的需求數(shù)量：需求太少了容易造成等待，需求太多了容易造成過載。通常緩沖區(qū)會儲備未來1-2周的工作量。73>2.第一板斧：全鏈路精益協(xié)作及精益需求分析新功能上線后，業(yè)務(wù)團隊常要做營銷和推廣。研發(fā)團隊和業(yè)務(wù)團隊配合好，才能得到理想的效果。需求明確后，研發(fā)同學根據(jù)當前情況做一個簡單的排期計劃，便于業(yè)務(wù)團隊安排營銷活動。軟件開發(fā)出現(xiàn)意外一點兒都不意外，這時研發(fā)同學第一時間通知業(yè)務(wù)同學。大家一起商量對策，或是砍范圍，或是推遲上線。及時溝通，通常都有很多選擇。切忌hold不住了才告訴業(yè)務(wù)，這時候選擇就很有限了。及時記錄研發(fā)過程中出現(xiàn)的意外以及造成的延遲，事后分析一下往往能找到改進的機會。2017年12月，我們發(fā)現(xiàn)緊急需求插隊帶來了18天的延遲，占總延遲的30%。有些“緊急需求”其實沒那么緊急，大家覺得劃不來。于是明確了緊急需求的定義，只有真（不）正（做）緊（會）急（死）的需求才允許插隊，其它需求都按優(yōu)先級正常排期。2.第一板斧：全鏈路精益協(xié)作及精益需求分析<74效果很明顯，需求延遲交付的總時長從12月的61天縮短到了1月的12天：75>2.第一板斧：全鏈路精益協(xié)作及精益需求分析明明很重要卻難以落地的敏捷實踐，持續(xù)集成也許算一個。其實項目啟動時引入持續(xù)集