需求管理如此重要,如何管理(下篇)
編輯導語:需求管理對于項目來說十分重要,前兩篇文章分別介紹了需求管理的基本定義、分類方式、重要意義和一些常見的項目失敗原因。通過前文的介紹,想必大家對于需求管理的基礎概念都已經有了新的認識。那么,讓我們進入到最核心的部分,同時也是需求管理系列文章的最終篇:需求管理體系的搭建。
一、標準化的需求管理
需求管理通常包括以下階段:
- 需求規劃
- 需求處理
- 需求驗證
- 需求變更管理
以上環節又可以拆分為:
規劃需求、收集需求、定義需求、精煉需求、組織需求、記錄需求、測試需求,驗證產品是否滿足需求以及跟蹤和控制需求的變更情況等詳細步驟和環節。
P1: 需求規劃
需求規劃包括需求管理計劃的制訂、評審和批準環節。需求管理計劃必須經過所有利益相關方/干系人(包括客戶、用戶、研發/設計團隊領導/經理) 的評審,并且經過項目發起人和關鍵干系人批準。
「凡事預則立,不預則廢」,就需求管理而言,在需求的整個生命周期中,需求規劃階段充當著最核心的作用,可以說需求規劃的完善程度幾乎決定了后續項目的成果與否。
現在有很多種需求規劃模型和方法可供選擇,我個人比較喜歡 Google 的 GIST 管理方法:
GIST = Goals + Ideas + Steps + Tasks
基于 GIST 方法,我們需要完成以下四個環節:
- 管理層基于前景分析,競爭分析,戰略分析等一系列商業和戰略分析結果,制訂業務目標
- 產品管理人員將業務目標初步分解為業務想法 (往往等價于產品需求) ,并分配給產品經理
- 產品經理將業務想法進一步拆分,依次得到需要設計和開發的業務環節 (等價于功能點)
- 項目經理、產品經理和相關人員基于具體的業務環節進行更進一步的分析和研究,依次得到各人員需要完成的具體任務,并相應進行分配。
具體任務是需求規劃階段的最小單位,不可再分。
P2: 需求處理
完成對于產品需求的整體規劃之后,就應該進入需求處理階段了。需求處理階段可以細分為需求收集&需求探索、需求分析和需求定義環節。
結合 P1 所介紹的 GIST 方法,我們很容易發現需求的業務環節和任務分解過程和需求的收集、定義和分析過程是相關關聯的。
換言之,需求的具體規劃過程和需求處理過程往往是同步進行的。
Step1: 收集和探索
用戶的某些需求可能被人熟知,而另外有一些需求可能無人知曉,但是前者不一定比后者更重要。
需求收集的目標是收集盡可能多的需求,最小化未知需求。需求收集的過程非常關鍵卻又相當困難:盡管從用戶反饋記錄和相關文檔中收集信息看起來毫不費力,但是獲得準確無誤而且組織有序的需求卻并不容易。
這些信息可能通過多種方式 (例如,電子郵件,面對面訪談,電話留言,會議記錄等) 收集,并以不同的形式 (例如,文本文檔,電子表格或存儲在數據庫中) 呈現。對這些需求信息進行必要的梳理和組織,并確定需求優先級可能是一件相當耗時,繁瑣到令人生畏的任務。
需求探索是基于已收集需求進行發散性的討論,的目的是確認項目不同的利益相關方的需求和限制因素。該過程的結果是:最終在項目干系人間達成了對于用戶所表達需求的共同認識。
Step2: 需求定義
需求定義是組織、記錄、定義和優化需求的過程。需求定義文檔 (Requirements Definition Documentation, RDD) 有時稱為需求規約,也就是我們日常所指的產品需求文檔。
經過批準的RDD ( 也稱為需求基線) 是商定產品范圍的文檔。它被認為是業務用戶 (有時由產品發起人代表) 和產品開發人員之間對于即將開發產品功能的具體規范。
與任何規范一樣,RDD 必須記錄詳細,具體而微,并且必須由合適的項目干系人認可和一直遵守。盡管我們期望這些需求非常詳細且被利益相關者充分理解,但這些需求必須仔細定義用戶的實際需要,也就是用戶預期產品擁有怎樣的功能特性,而不是新產品將如何滿足用戶的現有需求。
開發人員需要充分地了解需求(用戶的問題是什么) ,才可以設計出好的解決方案 (何修復用戶的問題)
需求文檔的標準模板需要充分定義功能型需求和非功能需求,功能約束和基本假設,這種模板是記錄和報告需求的有力臂助。市場上有很多可商用的系統和軟件可以用于需求的組織、優先級排序和報告。
工作分解結構 (Work Break-out Structure, WBS) 是標識所有產品可交付成果的常用工具。
WBS 對工作可交付成果的定義足夠詳細,便于輕松管理 (在成本、質量和進度方面) 可交付成果的每個部分。IEEE 標準 803-1998 軟件需求規約的推薦實踐(IEEE 1998) 有時也被用作軟件項目中需求規約的模板。許多組織選擇行業中常用的模板作為基準,并按照自身的實際需求對這些模板進行裁剪定制。
Step3:需求分析
需求分析與需求收集和需求探索緊密相關。需求分析的目的在于發現未知需求,然后將未知需求轉化為已知需求。那些在需求收集和需求探索階段,用戶未提及的需求往往可以通過需求分析挖掘出來。如果在項目早期就可以找到這些未知或者遺失的用戶需求,對項目大有裨益,這幫助項目將需求變更所產生的成本影響最小化。
需求收集和探索的常用方法包括:
客戶體驗地圖、頭腦風暴、商業折紙、脈絡設計、卡諾分析等
P3:需求驗證
需求驗證是指確保所有已提及需求都被充分滿足地過程。需求驗證流程通常在項目的需求階段執行,它包括對于在開發計劃中如何滿足需求的具體分析,以及用戶驗收測試 (User Acceptance Testing, UAT) 和有效性驗證。
需求驗證包括以下常用方法:
參與式行動研究(PAR)、時間感知研究、可用性報告、可用性測試、價值機會分析等
P4:需求變更管理
需求變更管理 (Requirement Changes Management, RCM) 包含需求變更控制系統的具體實施、與前者相一致的集成項目變更控制系統以及變更(被批準的變更請求) 的實際實施機制。
需求變更管理常常和需求處理和需求驗證同步進行,是需求管理的必要組件。
該環節的輸入信息是需求管理計劃,同時必須仔細定義 RCM 系統的關鍵部分:
- 首先是需求變更管理系統;
- 其次是作為控制和決策的主體的變更管理委員會;他們需求要處理變更請求;
- RCM 流程的任何例外和限制;
- 以及任何可允許的其他偏差。
所有的變更請求,無論大小,不管由誰發起,都應當通過變更管委會。
二、各階段的交付物
項目管理從業者慣于遵循那些擁有充分定義的輸入信息和輸出信息的業務流程。在將流程和模板實施到輸出信息之前,他們傾向于尋找有效的輸入信息和其他可以用于產出流程可交付物的工具和技術。流程的可交付成果應當得到充分的定義。
需求規劃階段的可交付成果是需求管理計劃,由項目發起人和關鍵干系人評審和批準。
需求處理階段的可交付成果是所有項目干系人對于需求的共識,RDD 是其共識的記錄規范。
一份編寫良好的 RDD 只有在它代表了關鍵項目干系人(包括項目發起人/用戶和研發團隊) 對于需求的共識時,才足夠有效。而需求分析充當著極為關鍵的角色,要充分發揮需求分析的作用,需求分析師(或者產品經理) 必須精于收集信息,擅于探索需求,長于優先級排序和組織整理信息。
需求驗證階段的可交付成果是用戶對于所有需求都得以滿足的正式認可。
對于用戶端場景,我們需要邀請具有代表性的用戶參與測試和驗證,并獲取其使用反饋。
對于商業端場景,商業客戶參與產品評審、測試和驗證是需求驗證成功的最佳保證。關鍵因素包括在需求流程中用戶的盡早參與和充分協作。
需求變更管理的可交付成果是對所有人需求變更請求的妥善處理以及對于已批準需求的實施。
在項目一開始就識別出所有需求是相當罕見的,大多情況下都會存在需求變更請求。項目團隊需要準備好處理突發的需求變更。一個廣泛使用的變更控制系統和一個預先安排的擁有適當控制和決策權力的變更控制委員會對于有效的變更管理流程而言都是必要的。
三、高效的需求管理體系
如上所述,任何有效的需求管理流程必須包含四個必要環節:需求規劃、需求處理、需求驗證和需求變更管理。
其中任何一個環節都是必須的,需求管理系統幫助產品從業者確保相關項目干系人充分理解需求,在項目早期收集完整,在研發階段得以處理,并在最終產品中得到滿足。
我們前文已經列舉了需求管理各階段所涉及到的一些模型和方法,市場上有相當多的工具和技術可供選擇:
- 用于組織和記錄需求的系統/軟件工具;
- 用于定義和梳理需求的模型和文檔模板;
- 用戶收集和探索需求的框架和模型;
- 用于需求測試和驗證的方法和工具;
- 用于需求變更控制方法和工具;
對公司和組織而言,在構建標準化需求管理流程中,所使用的相關技術和工具,只要能滿足相應階段的需求管理目標,就可以視為高效需求管理體系的最佳實踐。
如果沒有采用標準化的需求管理體系,而僅僅其部分環節作為需求管理獲得執行,同樣有助于提升項目的效率,但是無助于充分解決項目中的所有需求問題。如上所述,需求管理體系的各環節是緊密關聯的,如果缺失部分環節將會極大地影響其他環節的實際效果。
需求收集通常是一件極為耗時的活動,在很多項目中,需求收集往往占據 25% 的項目時間。然而,如果沒有產出完整而準確的客戶需求列表,前期的收集活動就變得徒勞無功。
即使如此,很多組織仍然只是將需求收集視為一項獨立的活動,而非標準化的組織流程。為了提高效率,需求收集活動必須在有客戶協助和與其他需要客戶參與的需求活動,如需求探索和需求驗證,相關聯的背景下進行設計和執行。
綜上所述,一個卓有成效的需求管理流程必須包含上述的四個需求管理環節,需求規劃、需求處理、需求驗證和需求變更管理,而且每個環節都需要關聯具體的框架模型、工具方法、任務流和文檔規范。
本系列至此完結,后續我會分享一些常見的需求管理框架和方法,感謝大家的關注。
#相關閱讀#
本文由 @遍歷分形 原創發布于人人都是產品經理,未經許可,禁止轉載
題圖來自 Pexels,基于 CC0 協議
太空泛了,沒有什么實際意義
什么也沒看到~
工作看困了
寫的很空泛,實際意義不大
……食之無味
寫論文呢
后續會分享各種項目管理類型和基于項目管理工具的搭建實例,理論為道,方法為術,工具為器,共勉之。
基本都是理論和概念性的內容,期待的干貨部分都被一筆帶過了!