需求管理
需求管理是在產品、系統或專案的整個生命週期中,系統性地蒐集、記錄、驗證、排定優先順序並追蹤需求的流程。
需求管理始於需求蒐集:透過訪談、工作坊或直接觀察,了解客戶、使用者或內部利害關係人實際的需要。需求蒐集完成後,會加以記錄、檢查是否有矛盾之處,並區分為功能性需求(系統必須做到什麼)與非功能性需求(例如安全性、效能或易用性)。接著才會進行優先順序排定,常用的方法是MoSCoW法,將需求分為必須具備、應該具備、可以具備與不會具備四類。
文件通常包括記錄客戶想要達成目標的需求書(Lastenheft),以及描述供應商計畫如何實現該目標的相應規格書(Pflichtenheft)。需求追溯矩陣會將每一項需求連結到其來源、狀態,以及日後用來確認是否達成的測試案例。在敏捷專案中,產品待辦清單(Product Backlog)通常扮演這個角色,需求會以使用者故事(User Story)的形式記錄,並在每個Sprint中逐步細化與交付。
當專案進行中需求發生變更時,正式的變更管理流程便會啟動:每項變更都會被評估、權衡對成本與時程的影響,並且只有在正式核准後才會被採納。若省略這個步驟,就會出現範疇蔓延(scope creep),也就是交付內容逐漸擴大,卻沒有相應調整預算或時程。扎實的需求管理,正是讓報價務實、責任歸屬清楚、成果可驗證得以實現的基礎。
實用範例
一家中型包裝機械製造商正在規劃新的訂單處理軟體。作為需求管理的一環,專案團隊訪談了來自業務、生產與出貨部門的12名員工,共蒐集到84項個別需求。透過MoSCoW法排定優先順序後,第一版本保留了31項「必須具備」的需求,並記錄在一份18頁的需求文件中。開發進行到一半時,一項與開立發票相關的需求發生變更,變更管理流程將其記錄於需求追溯矩陣中,讓所有相關人員都能追溯回原始需求。
Leanshift 如何提供協助
需求管理與Kaizen背後的基本立場是一致的:在改善任何事物之前,必須先精確理解實際的需要是什麼。仔細蒐集需求並持續追蹤,能讓改善工作命中真正的目標,而不是在症狀上打轉。這種清晰度本身就是流程工作的一部分,它揭示了真正重要的事,也為其他人持續改善提供了扎實的基礎。
常見問題
需求管理與需求書(Lastenheft)之類的需求文件有什麼不同？
需求管理是一個持續進行的流程,而需求文件只是其中的一項產出。需求書記錄的是客戶想要達成的目標,而相對應的規格書則描述供應商將如何實現該目標。
需求管理應該在專案的什麼階段開始？
理想情況下,應在構思或提案階段、專案正式啟動之前就開始。若等到開發已經展開才釐清需求,將有可能導致代價高昂的返工與範疇蔓延。
在Scrum等敏捷專案中,需求管理是如何運作的？
它是透過產品待辦清單以迭代方式進行,而非依賴一次性的文件。需求會以使用者故事的形式記錄,持續排定優先順序,並在每個Sprint中逐步細化與交付。