敏捷需求管理原則與實踐

楊俊

項目需求管理的痛點

需求管理是項目管理的一個痛點，主要表現在以下4個方面。一是在項目早期客戶沒有明確的需求，只能提出大致的想法，但期望項目團隊能夠精準地交付成果。二是在項目管理過程中，客戶可能不斷地提出新需求，越到項目后期變更越頻繁。通常情況下，在項目初期，客戶等關鍵相關方并沒有積極參與項目，到驗收階段才真正重視起來，導致需求頻繁變更，從而造成項目團隊前松后緊的工作狀態。三是項目相關方眾多，尤其是相關方意見不一致導致需求混亂，讓項目團隊無所適從。四是項目團隊花費大量資源和時間交付最終產品，然而很多產品功能用戶使用的頻率很低。根據以往對軟件產品的調查發現，45%的產品功能用戶幾乎從未使用過，而用戶經常使用的產品功能僅占所有功能的20%左右。這說明在產品研發過程中，客戶雖然提出了很多需求，但實際上大部分需求并沒有價值，浪費了項目團隊的資源和時間。

敏捷需求管理的原則

針對需求管理的痛點，從實踐中歸納提煉出敏捷方法，敏捷方法秉持了一個基本原則，即“不是看怎么做，而是看為什么做”。敏捷需求管理的探索與實現路徑，如圖1所示。

通過理解“為什么”，打開工作思路

通常情況下，面對客戶提出的新需求，項目團隊為了提升客戶滿意度，快速響應，第一時間思考“怎么做”并討論實施方案，安排相關資源快速完成。然而，即使任務順利完成，可能之前存在的問題仍然沒有得到解決。同時，客戶的需求是多變的，往往項目團隊剛實現一個需求，客戶又提出新的需求，如此往復，項目團隊疲于應對。這種變更可能會持續到項目驗收階段，也可能讓項目無法順利驗收。

敏捷需求管理規避了上述情況的發生，通過理解“為什么”，打開工作思路。當客戶提出需求時，項目團隊并不是馬上思考如何實現，而是研究為什么要實現這樣的需求，因為客戶給出的需求可能并不是真正的需求，而是解決方案。客戶基于自身的理解設計了一套解決方案讓項目團隊實現，而這個解決方案能否真正解決問題不得而知。

例如，在某控制系統軟件項目中，客戶提出這樣的需求：如果數據傳送失敗，應該在產品屏幕上顯示一條閃爍信息。這可能不是客戶的真正需求，真正需求可能是客戶希望系統出故障時能夠及時提醒維修人員快速響應。了解客戶的真正需求后，項目團隊的工作思路被打開，產品屏幕提示信息也許不是最有效的解決方案，播放報警聲音、緊急情況下的語音通知等做法可能效果更好。

又如，某項目團隊需要開發一套地鐵售票系統，客戶提出該售票系統需要支持觸摸屏設備。然而，支持觸摸屏設備只是解決方案，客戶的真正需求也許是給用戶提供方便快捷的購票方式，因為傳統的鍵盤打字方式效率低下。了解客戶的真正需求，要想快速購票，有沒有更好的辦法呢？可以直接設置固定票額的實體按鈕，如“2元按鈕”“3元按鈕”等，用戶無須選擇起點和終點，直接按下按鈕就可以快速購票。同時，實體按鈕比觸摸屏按鈕可操作性強，還能解決觸摸屏定位不準的問題。

項目經理需要建立專業能力

通過以上兩個例子，項目經理需要從 “做什么”到 “為什么做”，打開工作思路，才能走向更好的“做什么”，以滿足客戶的需求。完成這個過程對項目經理的核心能力提出了更高的要求。什么是項目經理的核心能力？優秀的項目經理應該具備多種能力，其中溝通能力經常被認為是項目經理的核心能力，因為項目經理的大部分時間都花在溝通上。然而，做好項目溝通必須依托項目經理自身的專業能力，如果自身專業能力不足，對行業和產品理解不深入，和客戶溝通時就會信心不足，難以取得客戶的信任，今后與客戶溝通的難度可想而知。反之，與客戶溝通前項目經理做足了功課，充分了解客戶的痛點，結合自身的專業知識，能夠給出專業的建議，才有可能與客戶建立真正的信任關系。因此，項目經理的核心能力是專業能力，而專業能力中知道“為什么做，值不值得做”比知道“怎么做”更重要。如果不值得做，功能再簡單也不做；如果值得做，要優先做。這就是敏捷方法面對需求變更的態度。

相關方持續參與是項目成功的關鍵因素

由圖1可知，在了解客戶的真正需求、明確有針對性的解決方案之后，項目團隊接下來會研究實現方法，即“怎么做”。然而，敏捷方法更加注重人的參與。再好的解決方案、技術手段，離開了人的積極參與和支持，項目也可能最終流產。

在需求探索和實現的過程中，敏捷方法特別關注兩類人的參與：一類是客戶、高級管理層等項目團隊外部重要相關方；另一類是項目內部團隊成員。

針對項目團隊外部相關方，在項目啟動之初就要明確真正的客戶。真正的客戶有時并不是項目經理經常打交道的客戶對接人，而是項目進展到中后期突然出現的重要相關方，他可能否決之前達成的需求共識，導致項目返工，驗收困難。

針對項目內部團隊成員，他們的參與也是至關重要的：一方面，雖然項目經理了解項目目標和需求，但由于溝通不足，團隊成員可能并不了解項目目標和具體要求，他們會按照自己的理解去解讀需求，使最終產品達不到預期；另一方面，由于團隊成員來自各個職能部門，他們重點關注分配到本職能的工作，缺乏項目全局觀，使項目各環節銜接不暢導致項目進度不如預期。

基于以上兩點，項目經理要順利地完成項目需求管理，必須盡早地多關注人，在項目團隊外部重要相關方和項目內部團隊成員之間統一目標，邀請其共同制訂項目計劃，這樣才能更好地推進項目需求管理工作。

敏捷需求管理實踐

敏捷需求管理引入了多種工具和實踐，如用戶故事、產品待辦事項列表、價值優先級排序等。本文主要討論眾多實踐背后的邏輯，即“試錯、快速試錯、低成本快速試錯”的工作理念。

需求管理的“線性思維”違背了項目實際

關于“線性思維”可參考預測型需求管理方法的邏輯模型，如圖2所示。

由圖2可知，模型的縱軸代表與客戶互動的程度，分為高與低兩類；模型的橫軸代表項目周期，假設項目周期分為需求收集、方案設計、產品開發、內部測試和外部驗收5個階段。從傳統的項目管理角度看，前期的需求收集階段和后期的外部驗收階段通常與客戶互動程度較高，其他階段互動程度較低。那么，這個模型是否符合真實的項目環境呢？答案是否定的。因為此模型違背了一個常識，即客戶在項目生命周期的早期很難明確自己的需求，隨著項目工作推進，獲得了更多的信息，看到了產品雛型，甚至進行試用后才能逐漸明確需求。根據這個模型，在項目前期規劃一個需求收集階段，項目團隊收集大量需求，在項目后續各階段圍繞前期需求收集開展工作，但前期需求文件中會存在大量的偽需求。這就導致了項目越到后期變更越多、矛盾越突出，想要控制變更越難。因此，有項目經理把這種需求管理模型稱為“坑”，其本質就是項目管理的“線性思維”。

敏捷實踐推崇“試錯”與“快速失敗”的理念

敏捷方法建議將項目周期劃分為若干個迭代，每個迭代約2～4周，具體時長取決于項目特點，如圖3所示。

在每個迭代的早期澄清并確認客戶的需求，客戶可能會提出很多需求，也可能說不清需求，導致需求非常籠統。不管哪種情況，項目經理首先要和客戶一起探討在接下來的一段時間內的工作重點，以期解決目前最關鍵的痛點。這個階段，項目經理不求大而全，要聚焦小而精。項目團隊在短時間內產出的部分成果，在迭代結束時邀請客戶進行評審，有條件的可通過實際使用給出反饋，以驗證迭代假設。初次迭代的產出成果可能并沒有解決客戶的問題。不過這時項目團隊不用擔心，因為工作才剛開始，試錯成本并不高，船小好調頭。不像“線性思維”方式，團隊埋頭工作了很長時間，才發現方向錯了，這是項目最大的風險。“快速失敗”降低了項目風險，更為重要的是，客戶在迭代結束后看到了部分產品功能，給出的實際使用反饋有可能是真正的需求，而在會議室中憑空談出來的需求不見得是真正的需求。在接下來的迭代中，根據客戶反饋聚焦關鍵需求，再進行實際使用評審，收集反饋，如此循環往復，真正做到與客戶共同探索需求，始終踐行“低成本快速試錯”的理念。

“線性思維”與“試錯思維”孰優孰劣

采用“線性思維”方式管理需求和采用“試錯思維”方式管理需求孰優孰劣？這兩種管理方式不存在好壞之說，關鍵要看是否適應項目特點和項目運行環境。如果項目產品比較成熟，需求能夠在項目早期得到明確，項目管理過程中不易變更，可采用“線性思維”方式。例如，某些傳統建筑類項目，在項目前期可收集到足夠詳細的需求，產品成型后糾錯成本極高，那么項目團隊應該在項目早期充分了解項目需求，進行詳細的分析和記錄，在項目執行過程中嚴格遵循變更管理流程，確保最終產品符合需求。反之，如果產品創新性高，外部運行環境變化快，則應該采用“試錯思維”方式，進行“試錯、快速試錯、低成本快速試錯”，擁抱變更，始終聚焦項目價值。眾所周知，當前越來越多的項目處于快速變化的外部環境中，因此，除了IT類行業，敏捷方法也逐漸被更多行業所接受。

結語

從源頭看，項目工作起源于需求評估與分析，需求管理的有效性直接影響項目成敗。在對各類企業的培訓中，我們發現需求管理是眾多企業項目管理的痛點。其根本原因在于項目外部環境變化快，固守傳統的需求管理模式難以提供真正有價值的項目成果。另外，未經管理的需求變更會演化為盲目的需求蔓延，打亂項目團隊正常工作秩序，產出大量的無價值輸出。敏捷方法通過詢問“為什么”，聚焦客戶價值，采用“試錯、快速試錯、低成本快速試錯”的實踐方法提供了一整套需求管理的工作思路。知易行難，期待項目管理從業人員共同努力，在實踐中進一步完善敏捷需求管理理論和方法，提高項目管理效率，提升項目價值。P