需求管理 101：您的逐步指南
摘要
現在是週五晚上，您準備要訂購披薩。 您一手拿著手機，另一手拿著朋友的點餐清單。 但首先，您需要整理每個人的偏好，並決定要訂購哪種類型的披薩。 義大利辣腸？ 起司披薩？ 素食？
點披薩開始讓人覺得很詭異，就像管理最新產品發佈的需求一樣。 就像上述情況一樣，需求管理的重點在於傾聽專案關係人的意見，並瞭解如何最好地滿足他們的需求。
什麼是需求管理？
需求管理是一種確保最終專案交付項目滿足客戶和內部專案關係人需求的方法。 在這種情況下，需求是專案關係人需要或想從您的產品中獲得的東西。 專案關係人可以是內部人員 (例如跨職能合作夥伴) 或外部人員 (例如顧客或客戶)。
需求管理最常用於開發軟體產品和功能的開發團隊，但也可以更廣泛地應用於專案管理。 例如，需求可以是使客戶能夠成功使用您的產品的功能，或是您的產品中有助於跨職能合作夥伴實現其Business 版目標的某個方面。
在開始開發產品之前，您需要就確切的需求達成一致，以便確保您為專案關係人提供他們所需的內容。 需求管理可協助您記錄和排定需求的優先順序、追蹤變更，並在整個專案生命週期中與專案關係人保持一致。 它還能幫助您管理不斷變化的需求，並確保您的專案保持在範圍內。
建立需求追蹤矩陣範本什麼是需求？
需求是您為了完成功能或產品而需要實施的組成部分。 換句話說，這是您的產品為滿足專案關係人的需求而必須具備或做的事情。 軟體產品可能有數百個需求。 但無論您的產品有多少要求，所有要求都應該是：
必要性：您需要此要求才能實現您的 Business 版或產品目標。
具體：需求詳細且目的明確。
可理解：需求的撰寫方式清晰易懂。
準確：需求包含有關挑戰或需求的足夠準確資訊。 這意味著，您不應該只是描述需要完成的工作，還應該闡明該要求為什麼很重要。
可行：您應該研究需求，確保您可以使用目前的技術堆疊和程式碼基礎架構來實施。
可測試：您應該能夠透過使用者測試、A/B 測試或其他方法來測試需求。
以下是一個範例。 假設您正在建立一個應用程式，其中一個需求是整個應用程式需要翻譯成英文、中文、日文和法文，因為這些語言與您的主要 Business 版市場相符。
為了在公司的主要市場中推出您的應用程式並實現 Business 版目標，這一要求是必要的。
這是具體的，因為您概述了您需要哪些語言，並且需要翻譯整個應用程式。
這是可以理解的，因為它不會涉及技術細節，而是以您的團隊成員和跨職能專案關係人可以理解的方式撰寫。
這是準確的，因為您已清楚說明了該要求為何重要，因為英文、中文、日文和法文與您公司的主要市場一致。
這是可行的，因為您已經建立了其他語言的原型和測試案例，因此您知道本地化是可能的，並且會按預期執行。
它是可測試的，因為您已經有一個系統來測試和確認每個翻譯版本的準確性。
為什麼需求管理很重要？
若要建立出色的產品，您需要進行需求管理。 以下是原因：
交付正確的功能。 需求管理流程透過瞭解使用者與產品的互動方式，幫助您定義使用者的需求。這有助於您將交付項目與客戶的基本需求保持一致。
與 Business 版目標保持一致。 在記錄和排定需求優先順序時，請確保每個需求都與您的整體 Business 版目標保持一致。 例如，將您的應用程式翻譯成 12 種語言的需求將支持擴展到國際市場的 Business 版目標。 如果某個需求無法支援 Business 版目標，則可能意味著您應該將資源投入其他地方，或有充分的理由說明該需求為何重要。
避免範疇潛變。 定義後的需求可作為專案範疇，它們設定了界線，並明確定義您將努力實現哪些目標和交付項目。 提前定義需求有助於您識別潛在的障礙，並在專案關係人試圖新增其他需求時進行回推。
避免障礙。 產品的建立是複雜的，其中包含軟體開發、設計和測試，更不用說複雜的程式碼堆疊和工程系統。 需求管理可協助您規劃如何在程式碼堆疊的限制範圍內開發產品，並追蹤您在產品開發流程的每個階段需要完成的內容。
誰負責需求管理？
需求管理的負責人員取決於您的個別專案或團隊。 也就是說，產品所有者或產品經理通常會管理開發團隊的需求。 這兩個角色相似，但產品所有者是Scrum 團隊中的標準角色，而產品經理則是更通用的角色，無論您的團隊是否使用敏捷方法。 如果您正在進行的是更一般的專案，而非開發產品，則由專案經理負責需求管理。
需求管理需要團隊和專案關係人之間的跨職能協作。 您需要收集專案關係人的回饋，與他們合作以瞭解每項需求，並協助您的團隊規劃如何滿足每項需求。 這意味著專案需求管理人員應具備強大的協作技能，並擅長跨職能溝通，因為他們將成為所有工作的中心。
閱讀：25 個成功所需的專案管理核心技能有哪些不同類型的需求？
主要有三種類型的需求：Business 版需求、使用者需求和系統需求。 在工作啟動之前，定義不同類型的需求非常重要，因為這通常會決定您需要與哪些專案關係人協作。
以下是不同類型需求的概述：
Business 版需求
Business 版需求是產品所服務的總體業務目標或指標。 它們不一定是產品需要做的事情，而是您的 Business 版需要做的事情，以滿足內部和外部專案關係人的需求。
例如，假設您在一家線上零售企業工作，而您的銷售團隊使用內容管理系統來建立和更新您網站上的產品頁面。 為了處理不斷增加的庫存，您的產品團隊正在改善 CMS 中的搜尋功能。
您的產品團隊的專案滿足以下 Business 版需求：在第一季度將產品庫存擴大 50%。 若要以單一、有組織的格式擷取此類需求，請嘗試使用Business 版需求文件範本。
閱讀：業務需求文件範本：7 個關鍵元素 (附範例)使用者需求
使用者需求定義了使用者對產品的需求以及他們將如何與產品互動。 它們描述了客戶想要達成的痛點或行動，以及產品應如何緩解該痛點或幫助客戶達成其期望的行動。
敏捷團隊通常會將使用者需求格式化為使用者故事，這是從終端使用者的角度撰寫的軟體功能的非正式說明。 使用者故事通常採取「身為〔角色〕，我想要〔軟體目標〕，以便獲得〔結果〕」的格式。
讓我們回到上述的 CMS 範例。 以下是從終端使用者的角度撰寫的使用者故事範例，在這個案例中，使用 CMS 履行其工作職責的是一位銷售人員。
「身為銷售人員，我想要在 CMS 中輕鬆搜尋和找到特定產品清單，以便更新和管理不斷增長的線上庫存。」
系統需求
系統需求定義了產品的功能。 可以這樣想：雖然使用者需求從使用者的角度概述了產品功能的「原因」和「內容」，但系統需求從工程團隊的角度定義了構建該功能的「方式」。
系統需求通常分為功能需求和非功能需求。 功能性需求定義產品將會做什麼，而非功能性需求則定義產品在執行其功能時的表現如何。 這意味著非功能性需求通常與安全性、效能和可靠性有關。
例如，工程團隊可能會將上述 CMS 使用者需求分解為系統需求，如下所示：
功能需求
每個產品清單都會儲存以下資訊：產品類型、建立日期、作者、網址和發佈狀態。
除非作者從下拉式功能表中選擇產品類型，否則無法建立新產品。
搜尋列包含一個選項，可套用以下其他篩選條件：產品類型、建立日期、作者、網址和發佈狀態。
一次可以選擇多個篩選條件。
非功能性需求
搜尋結果會在 5 秒內傳回。
搜尋結果 100% 準確。
需求管理流程的 7 個步驟
需求管理不必讓人感到不知所措。 如果您為團隊建立了標準化的流程，您每次都可以遵循相同的步驟，而不必擔心何時該與哪些專案關係人進行溝通。
為了幫助您入門，我們已將流程簡化為七個步驟。 然後，一旦您嘗試並了解哪些方法適合您的團隊，您就可以相應地調整您的需求管理流程。
步驟 1：制定需求管理計劃
建立需求管理計劃 (RMP) 以啟動您的專案。 此計劃是您在整個專案生命週期中處理需求的藍圖。 在您的 RMP 中，請定義：
誰將參與需求收集？
您將如何收集和記錄需求？
您追蹤需求變更的流程是什麼？
您將如何與目標保持一致，從而確保專案成功？
良好的 RMP 有助於您的專案團隊在整個開發生命週期中保持井然有序並保持一致。
步驟 2：探討和定義需求
探討涉及收集和定義您的專案要求。 這是與專案關係人和客戶建立聯繫以瞭解其端到端需求的重要步驟。
需求探討
與專案關係人互動：與專案關係人面對面會面或進行非同步溝通。 介紹您正在建立的產品、功能或計劃，並詢問他們需要什麼來幫助客戶或實現其 Business 版目標。
收集終端使用者需求：如有可能，請進行使用者測試。 至少請諮詢您的開發團隊，以獲得深入解析。
管理期望：說明並非所有請求的需求都必然會實施。 說明這是資訊收集階段。
需求定義
定義您的需求有助於概述開發團隊為完成計劃或產品而需要完成的所有組成部分。
根據收集到的資訊，撰寫清晰、具體的要求。
建立使用案例，以展示使用者將如何與最終產品進行互動。
確保每個需求都描述了一個特定的需求或功能。
您還可以為每個需求建立使用者故事，以闡明使用者的需求以及他們將如何與您的產品或功能進行互動。
然後，您可以將這些使用者需求分解為更具體的系統需求。 在此過程中，您可能需要從專案關係人那裡收集其他資訊，以確保您有足夠的背景資訊來完成每個需求。
請記住，在需求管理工作流程的這個階段，您正在收集潛在的需求和要求。 您的團隊將在需求管理流程的後期階段，優先考慮並選擇最重要的需求。
閱讀：專案成功的 6 步驟需求收集指南步驟 3：需求分析和驗證
現在是時候整理所有回饋，並決定哪些需求與您的產品和Business 版目標相符。 最終，每項需求都應有助於實現總體 Business 版目標，例如增加收入、拓展新市場或提高客戶滿意度。
需求驗證包括：
檢查所有技術需求是否必要、可行且彼此不矛盾。
確認技術要求與專案目標一致。
接著，與專案關係人一同驗證需求。 這意味著檢查需求是否真正反映了專案關係人的端到端需求。
步驟 4：建立需求基準
驗證需求後，請建立基準。 此階段的文件可提供所有已核准需求的快照，並提供：
需求管理解決方案的起點
未來決策和衡量變化的參考
記錄和追蹤需求並沒有一套固定的方法。 您的產品團隊過去可能使用過軟體需求規範(SRS)、產品需求文件(PRD) 或需求追蹤矩陣(RTM)。
但為了確保您的團隊能即時深入解析所有專案需求，請嘗試使用 Asana 這類的專案管理工具。 這意味著不再需要使用過時的試算表來審核需求，而是讓您的團隊和專案關係人都能看到每個需求的最新描述。 您還可以在處理專案時追蹤每個需求的狀態，甚至設定自動化，以便在取得進展時提醒專案關係人。
您還可以將 Asana 與更專業的應用程式和需求管理工具 (如Jira和GitHub)整合。 如果您與沒有權限存取開發人員工具的專案關係人合作，這尤其有用。
步驟 5：優先順序和相依性對應
現在您已經寫下了一組需求，請與您的團隊合作，確定優先順序並規劃如何解決這些問題。 這種優先順序可讓您先處理最重要的任務，特別是當這些任務阻礙了後續的任何其他任務時。
在此步驟中，確定需求之間的相互關係。 此流程通常稱為可追溯性，涉及：
連結相關需求
將需求與其他專案元素 (例如設計文件和測試案例) 連結起來
如果您的團隊使用敏捷式開發，請將需求新增至產品待辦項目，然後舉辦衝刺規劃會議，以決定下一次衝刺中要包含哪些任務。 如果您不使用衝刺，也沒關係，您可以建立專案時間軸，以便規劃每個需求應該何時已完成，以及是否存在任何相依性。
步驟 6：變更管理、版本控制和影響分析
需求管理不僅僅是專案啟動前的需求規劃，還包括專案過程中需求變更的應對。 這意味著您應該規劃如何納入會影響專案範疇的其他任務。
隨著專案的進展，需求可能會發生變化。 透過以下方式管理這些變更：
設定提交和審查變更請求的流程
分析每個提議的變更可能如何影響其他需求和專案元素
若變更獲得核准，請更新您的基準
使用您的相依性圖表進行影響分析。 這有助於您在決定實施變更之前，瞭解變更的全部影響。
另一個選項是建立變更管控流程。 這為專案關係人提供了一種提交新要求的方式，這些要求將影響您的專案範疇，並規定誰應該核准或拒絕這些請求。
定義完善的變更管理流程可幫助您瞭解如何有效管理需求，同時追蹤變更。
步驟 7：系統驗證和確認
在最後一個步驟中，請檢查您的成品是否符合所有技術要求：
驗證：測試每個功能，確保其按需求中指定的方式運作。
驗證：與專案關係人確認產品是否滿足其需求和期望。
此步驟可協助您在最終確定產品之前發現任何問題，從而減少後續對昂貴返工的需求。
在此過程中，請考慮使用 Asana 這類需求管理軟體。 它可以作為單一事實來源，幫助您管理需求、追蹤變更，並產生報告和儀表板，以更好地監督專案。
簡化需求管理的工具
需求管理有很多變動部分，但不必感到失控。 藉助正確的工具，您可以設定一個可重複的流程，確切地說明與誰交談、何時進行，以及如何在整個專案生命週期中記錄和組織需求。
如果您在Asana中追蹤需求，您可以建立一個標準化的範本，幫助您管理每個專案的需求。 這意味著您不必每次都從頭開始，而是可以重複使用預先定義的工作流程，而且您可以放心，因為您不會忘記任何關鍵部分。
建立需求追蹤矩陣範本常見問答：需求管理
何謂需求管理？ 需求管理是一種在整個開發生命週期中定義、追蹤和控制專案需求的流程。 它確保所有專案關係人都能瞭解並同意專案需求。
什麼是需求管理計劃？ 需求管理計劃概述了在專案期間如何收集、追蹤和管理需求。 它可作為處理變更、文件和溝通的指南。
需求管理流程的關鍵功能是什麼？ 需求管理流程的關鍵功能包括收集需求、分析和驗證需求、追蹤變更，以及確保最終產品符合商定的需求。
好的需求是什麼樣子？ 好的需求是清晰、具體且可衡量的。 它應該易於理解、可測試，並與專案的整體目標保持一致。
