現如今，很多企業在項目研發的體系中走的基本是敏捷流程。對於敏捷開發而言，其中最關鍵的要素是增量開發和需求漸近。
因此，對於敏捷開發大家最關心的是如何做好需求的精益管理？如果需求管理做不到位的話，敏捷就算運行得多麼流暢也沒有意義。在整個敏捷開發過程中，精益管理和敏捷運作相輔相成，兩個同等重要。
為此，5月30日，解放號社區推出的【如何應對外包中的撕逼大戰】系列課第二課中軟國際培訓學院高級講師馬爽在荔枝微課上為大家直播分享了《精益求精需求管理》話題，本次課程從精益思想、產品願景、用戶畫像、用戶故事四個方面進行了分析和講解，乾貨滿滿，贏得了學員的一致好評。
馬爽 中軟國際培訓學院高級講師
馬爽 中軟國際培訓學院高級講師
簡介：西北工業大學軟件工程碩士，曾就職與微軟亞洲工程院、IBM中國系統技術實驗室，歷任軟件測試經理、軟件開發負責人，現任中軟國際 華為業務群 流程IT iBuy產品經理，熟悉Scrum XP等敏捷方法，有豐富的敏捷實施經驗，在產品推行敏捷過程中承擔過敏捷教練，指導過多個開發團隊的敏捷轉型。
人類經歷了機器革命和工業革命後，正處於一場信息技術革命和數據爆炸的浪潮之中，在瞬息萬變的時代中，誰能真正掌握住市場需求的變化，就能成為真正的贏家。
軟件項目調查
但在對軟件項目的調查中發現，人們往往會把大量的精力投入到價值性不高的事情上，對於價值性高的事情只投入20%的精力，這是什麼原因呢？
在原來的產品遠景上，瀑布式開發更多強調的是計劃。在軟件開發過程中，如果按照計劃推演，根本前提是我們能一次性完成需求的澄清和描述，然後根據需求推演計劃，最終完成項目的管理和軟件的開發。
在信息爆炸的時代，需求訊息萬變，我們往往不能在前期就一次性做好需求的澄清和規劃，這就導致在瀑布式開發中研發和資源的大量浪費，可見傳統式的研發體系遠遠不能適應市場需求這種短而快的變化，也不能適應現在這種軟件開發模式。況且，不斷地進行需求的更改和計劃的把控，這對研發項目本身就是一個痛苦的過程。
單向的需求傳遞方式
從上圖可看出：一個漸進的過程，如果沒有回饋和需求精益管理方式的話，就會完全脫離客戶的真實需求，因此需要雙向的需求傳遞方式來實現這個漸進的過程。
雙向的需求傳遞方式
需求精益管理是敏捷的一個配套方法論。需求精益管理搭配敏捷需要做什麼？從我們的觀察、判斷、決策、行動，每一個迭代都需要有一個回饋。回饋主要是用於跟客戶確定需求，進一步的需求論證，保證真正實現客戶的預期。
精益思想的提出，要推演到二戰結束時期，最早是由日本豐田提出的。
二戰結束後，在所有物資都耗盡的情況下，豐田不得不考慮需求的精益和定製化的生產，考慮它與原先的生產模式有什麼區別？其中原先生產模式最典型的代表就是福特。福特擁有完整的生產線，這種生產線工作流的定義最就是不考慮真正的市場，只按照產能來定計劃，能生產多少就生產多少，至於銷售量就是銷售和市場的問題，這種我們認定屬於粗放型的模式，比較適合福特的大規模的生產。但是到了日本的豐田，考慮到資源的匱乏，它並不能採用這種粗放型的生產模式。為此，豐田考慮的是定製化需求，量需生產，根據客戶不同定製化的需求來生產不同的產品，適配客戶真正的需求。從這可以看出，把握市場瞬息萬變的變化，就是豐田需求精益管理的來源。
求需價值驅動和計劃驅動有什麼區別？
計劃驅動：計劃關注完成任務，前期定範圍，由範圍來推成本和時間。關鍵問題是，投入成本和時間之後，反向推演的時候發現範圍已經變化了。
需求價值驅動：在既定的成本和有限的時間裡去反推，通過快速迭代的方式不停地跟客戶回饋，最終驗證需求漸近，以此來推演版本迭代的開發，這就是需求價值驅動跟瀑布式研發的根本區別。
如果想做好需求精益管理的話，必須規劃遠大的產品遠景。
歷來，在各種大型的成功產品中，至少要有3-5年的遠景和堅定的信念才能成功。
比如華為：從交換機起步把握住了市場的需求。可是隨著通訊時代的技術變革，人類對資訊的要求越來越高，而華為順應時代的變化，以前固話的費用比較高，現在座機免費安裝，降低移動資費，華為為人類的通訊生活提供了便利和優質的體驗。
比如淘寶：馬雲能夠快速察覺市場需求的變化，主動地挖掘市場需求。通過自身的需求遠景去創建需求市場，以至於馬雲打造了電商的神話。馬雲經過多年經營，綁定了用戶消費者的習慣，賣家的習慣，通過大數據把握住了時代的變化。馬雲看到市場的需求變化，然後根據自己的切實需要，把握產品的遠景，保證技術方向符合需求變化。因此，淘寶的不可複製，取決於馬雲能快速響應需求的變化，把握電商時代的需求。
再比如滴滴：滴滴先是看到了資源共享的需求，然後集中了很多司機來實現利益的共同體，服務我們人類的出行需求，最終改變了人類的出行方式，讓我們出行更便利。
以上這些產品，最典型的標誌是對產品的遠景有堅定的信念。俗話說：“一個產品看不到自己的需求遠景，是做不好產品的。”
我們再來看一個典型的遠景案例：中國高鐵現狀
地鐵現狀
在以前，北上廣的經濟圈坐車需要一天以上。小經濟圈坐車最少也得2小時以上，而且用戶體驗相當差。為了改善這種體驗，國家對於高鐵的目標規劃為：三大經濟圈的通行時間要縮短到8小時以內，小經濟圈縮小到1小時以內，達到上班通勤時間。
規劃了需求遠景後，那如何做好產品呢？最關鍵的是干係人分析。
干係人分析
干係人分析中最關鍵的考量指標：
1.用戶對產品感興趣的程度；
2.用戶對產品成敗影響的程度。
干係人核心用戶群:
第一層：項目經理、產品經理、客戶方和合作方的代表；
第二層：QC人員、開發人員、運營人員；
第三層：運營商、物流等等。
在很多經典的案例中，就是因為產品干係人的不明造成項目的失敗。比如國內的大型的公路項目，因為沒有考慮環保人士的訴求，導致了項目的停工和改期重新規劃。因此，我們應該近可能多地窮盡產品的干係人。
而在干係人分析中，應該更多考慮用戶的畫像，這是一個共情的概念。所以我們要先思考是站在自己的角度還是站在甲方的角度？用戶想要什麼以及用戶需求的來源？如果不能站在用戶角度考慮問題，就不能真正理解用戶的需求，為什麼？怎麼做？
對於用戶畫像，我們應該更多考慮用戶的特徵，用戶在什麼條件下會提出這樣的需求，對產品的期望如何？可以這麼說，干係人的分析和識別，對項目後期不停的回饋和溝通起到關鍵性的作用。
用戶畫像出來之後，我們開始進入用戶體驗的推演。
實際上，用戶體驗的推演就是一個情景模式，在一個用戶場景中開始整個工作流的推演，發現用戶的痛點在哪，用戶的期望是什麼？
在這裡給大家講一個聯合國組織尼泊爾保溫箱的案例。
在貧窮落後的尼泊爾國家，嬰兒出生後的存活率非常低。因為在當地晝夜溫差大，導致嬰兒沒有得到及時的保暖，為此聯合國想要快速解決這個問題，便研發了一項高科技產品——保溫箱，這款保溫箱不僅有恆溫功能，還有報警監控，可以隨時關注嬰兒的體溫狀況，保證嬰兒的存活率。但是，實際的反饋卻是嬰兒的死亡率根本沒有下降，為什麼呢？經過反饋發現，尼泊爾那些貧窮落後的國家連電都沒有，保溫箱根本用不了，這對於嬰兒存活率提升這個問題可見不是一個切實可行的方案。後來，他們決定採用先進科技的隔熱材料，研發了一款保溫被褥才得以問題解決。
事實證明，並不是高大上的產品就真正適合用戶使用，切合用戶的生活場景的產品才是用戶需要的。需求是漸進的，我們要通過快速的迭代完成增量開發。
首先，我們一定要先做需求原型，再做產品開發。
需求原型做出來後，我們再用demo show的方式跟用戶推演工作流程的功能變化。通過這麼一個流程，其作用是核對用戶的真實需求，我們通過定義原型可以極大程度規避需求漸進和需求不明的風險。如果沒有需求原型匆忙上線，可能就會發現最終完成的不是用戶真實想要的效果。因此，前期需求原型圖相當重要。
對於用戶的需求，產品原型分為低保真、中保真、高保真3種模型（3種模型的區別見下圖）。
產品原型3種模式
其次，就要考慮到快速迭代，而迭代就是需求漸近和增量式開發。
在敏捷的概念中，更多的時候我們要進行功能需求的拆解和解耦。如果需求不能解耦，就沒有辦法通過增量式開發快速迭代，這就需要我們考慮需求的拆解節奏。這就涉及到用戶故事，用戶故事不是研發的最小單位，它是用戶驗收的最小單位，它講求的是能夠單獨驗收。如果說我們用過敏捷項目，就要考慮用狀態牆。不管是手動維護的還是電子版的狀態牆，我們都是把所有的需求通過feature、testsotry的方式放到狀態牆中，來看整個進度處於需求澄清中，開發中，測試中，客戶驗收中，還是什麼狀態，看看它們之間相關的關係，整個的場景和版本的變化，都是在狀態牆中演進的。所以，建議狀態牆放在項目中，通過每日早會的方式去過各種需求進度和整個需求漸進過程。
如果要通過敏捷的方式來拆解團隊的話，我認為一個敏捷scrum團隊人員最好不超過10個人。因為很多敏捷團隊都是通過快速迭代和小團隊規模的漸進方式來達到軟件快速研發任務。
那對於一個大型的項目應該怎麼辦？我們可以通過需求的分解來進行大項目的管理，再通過層級套用的方式開始研發任務和項目管理的拆解，達到需求的管理和敏捷演進。
接下來，我們來看一下需求管理的場景識別。
一個完整的場景識別分為：用戶場景、用戶用例和用戶故事，這裡主要講一下用戶故事。
場景識別
用戶故事是描述業務需求的一種模式，遵循Invest原則。用戶的故事必須是一個最小單元，可以解耦。用戶的故事有一個標準的概念，用戶故事首先必須是一個最強的科研單元。
需求優先級
對於用戶故事這個關鍵環節，主要是它能夠描述出用戶的基本動作。比如說：用戶想要什麼？如何去達成？這就是一個標準的用戶故事。
如果說敏捷迭代中我們進行需求管理，首先要把所有的需求拆解成用戶故事，再把需求放入backlog（需求池）裡，最後進行需求價值管理。對於需求的價值管理主要是根據用戶的迫切性、資源的消耗、實現的風險、技術的可實施性來進行精益需求管理的排序，然後根據需求的排序定用戶故事。
而在用戶故事拆解時，我們首先要考慮到用戶基於什麼樣的角色？希望去做什麼？通過什麼樣的方式去達成？
用戶故事
其中，用戶故事最基本的要素分為以下6個要素：
1.可以獨立交付，可驗收；
2.可以進行協商，可以單獨定義並進行功能的演進和開發；
3.必須是有價值的；
4.可以去被估算工作量的；
5.可以測試的；
6.一個合適大小，在一個用戶故事不應該超過5人，否則沒法進行快速迭代和需求管控。
用戶故事拆解完畢後，我們根據價值排序，把需求放入需求池裡，再將排序需求放入迭代版本中開始漸進開發，最終通過持續集成、增量交付針對產品主線達到需求漸進和增量式開發軟件鑑定的模式。
因此，我們把敏捷迭代中的關鍵過程分為：
進行收集需求的精益管理；需求的排序；根據需求的優先級開始版本迭代；在迭代的過程中通過我們的DevOps的方式進行回饋，跟用戶討論需求變化；在下一個迭代中進行持續的改進；通過這種快速的迭代的和這種需求精益管理的這種方式來達到軟件智能快速開發。
由此可見，敏捷的迭代和需求的精益管理是相輔相成的。
對於評估人員來說，在優先級定義方面，一個需求它到底優先級高不高，要不要排入迭代版本並不是一個簡單的過程。一般在需求排序中，我們要考慮以下個幾個方面：
- 是否能解決用戶的關鍵性痛點；
- 否能響應市場的觀念性變化；
- 是否有足夠的市場粘度粘性，來幫助我們綁定用戶；
- 風險和資源耗費能否在版本預期之中，快速演進規模範圍之內。
需求的價值排序，這是一整套的科學方法論，不過其中有幾個關鍵定義需要注意：
需求定義
- Must have：必須要有的，權重更高，其前提是可投入資源是可以達到的，60%-80%；
- Should have：我們應該去做的，用戶有非常大的預期，也是用戶想要的；
- Could have：可以根據版本規劃適當的排布；
- Won’t Have：是可以不做的，沒有多大價值，必須避免。
在這4個定義中，must have是權重最高的，必須要做的，達到了一個版本的60-80%，但並不是說should have和could have就不做。在技術變革和演進中，Should have和Could have也要預留一定的空間，保證產品不斷地更新換代，技術更新。
需求排序好後，接下來最重要的一個環節就是對於工作量的估算。目前，流行的兩種工作量的估算方法如下：
1.經驗估算法
經驗估算法一般是針對類似的功能以及功能的複雜度與歷史的經驗值對比，來推演出新的story的工作量估算，從而實現迭代容量和版本技術的排布。
經驗估工法的優點是簡便易行，工作量小，制定定額快，並有一定群眾基礎。缺點是單憑經驗，技術根據不足，受估工人員主觀因素的影響大，難免出現偏高或偏低等現象，因而定額的準確性較差。
2.Delphi法
Delphi法是最流行的專家評估技術，在沒有歷史數據的情況下，這種方式可以減輕估算的偏差。Delphi法鼓勵參加者就問題相互討論。這個技術要求有多種相關經驗人的參與，互相說服對方。
在一個敏捷團隊中，Scrum master不是一個專業的崗位，更多是充當敏捷教練和引導員的作用，講求的是共同承諾和集體管理，以及每個成員的效益最大化，提升成員的工作積極性。所以在一個敏捷團隊中，不要用計劃式的方式去硬性攤派工作，更多的是通過像DD交付方式，讓大家主動認領工作，實現承諾，所以我們更多采用Delphi法。
Delphi法是通過Scrum master做需求澄清，每個人通過投票的方式來評估開發這個功能需要多少開發量。從中抽出兩名人員（一個工作量最多的和一個工作量最少），分別講一下為什麼做這項工作需要這個工開發量，然後進行二次投票，達成共識後，推進投票的演進，不斷確定目標的一致性和科學性。當然，投票過程不是無休止循環下去，需要一個技術領袖進行仲裁，實現技術的驗收。
需求精益管理更多的是一種概念，理性地站在用戶的角度去思考用戶的痛點，分析用戶的需求，規劃產品的遠景。再通過敏捷迭代進行需求架構，對原先設計版本推演進行產品快速迭代和需求漸近，而在每個版本迭代中都要有回饋的過程，運用DevOps的方式去跟用戶認證需求的變化和需求的演變。
在整個過程中，通過精益需求管理決策的方式，就可以達到明確應對需求的瞬息萬變的目的，通過推進需求的快速開發達到契合用戶的真正需求，從而實現產品的成功。
“如何應對外包中的撕逼大戰”系列課程下期活動預告：
活動時間：6月6日晚20:00~21:00
課程主題：《如何避免項目交付後扯皮》；
主講：中軟國際解放號特邀講師白仕雲；
課程形式：在線直播
手機掃碼進入課程直播頁面
閱讀更多 解放號社區 的文章
