研發團隊的項目性質很大程度上決定了需求管理做到的深度和廣度。有項目經理問，我的項目周期常常只有幾個月半年的，還需要做需求管理嗎?誠然，若是一些沒有專注業務領域的團隊，他們項目的時間短，而且沒有類似的后續項目，可以不必在需求管理上面投入太多的資源。而另一方面，如果這個項目是一個產品發展的某一個階段，我們就要重新審視這個問題。就如一個做打印機的日本公司在上海的研發團隊，他們的項目周期也是半年左右，但是一個基本型號的打印機已經有二十年的歷史。也就是說，現在的這款打印機是一個個小的項目的開發成果的累計。這時，該開發團隊就需要很好的需求管理，而且需求管理已經不再局限在某個項目里。
市場的激烈競爭，企業自身的發展，我們看到一個產品的需求往往會非常多。如果全部實現，那將是一個“完美”的結果。時間和資源的現實面前，決策層需要進行選擇：既要快速地將產品發布面世， 同時新的版本中也需要有足夠地引起客戶購買欲望的需求實現。
這里需要決策。孫子兵法中的“勝兵，先勝而后求戰;敗兵，先戰而后求勝”早就闡述類似的道理：打勝仗的部隊是在有勝算時之后才投入戰斗，打敗仗的部隊先投入戰斗，才尋求勝利的條件。需求工作的重要性是老生常談的事情了，不是本文的重點。我們關注的是如何做出正確的決策而占得先機。
沙漏的上半部分強調的是在產品和項目的規劃階段，我們需要將做出正確的決策以滿足現在市場的需要。這體現在收集和記錄正確的需求;對需求的重要程度做出準確的刻畫;基于成本和效益來規劃產品的路線圖，將需求的實現分配到各個的項目中。在需求明確的前提，項目經理就可以帶領他的團隊開展工作，這個階段的重點就是如何保證需求在每一個研發的每個階段都得到嚴格的滿足和測試，而切實保證需求驅動開發和保證需求驅動測試，是研發團隊將事情做正確的關鍵。
決策的重要基礎是對需求的重要程度進行排序。但排序的基準在哪里，且基準也會隨著個人的角度和時間的推移而變化?如果讀者參與產品和系統規劃的工作，嘗試著回答下面的問題：所有來自A地區客戶的緊急程度為高的且估算工作量在180 個人天以下的所有需求有哪些?他們現在的項目狀態如何?這是一個問題的簡單樣本，問題的實質在于決策者可能需要從多個角度去分析需求，并需要在眾多需求中找出最重要的或者是當前最感興趣的需求的子集。在沒有方法的指導和工具的支持下，這個工作在競爭越來越激烈的現在是越來越難了，因為決策者往往面對多個產品， 多個市場，多個競爭對手，當然還有時間和成本的壓力。
“沙漏”的具體實踐
沙漏雖然是個比喻，但實際上有很多公司都在實踐這種思路。以Telelogic公司開發DOORS 這個產品為例，該產品的信息架構也呈沙漏的形狀(為了展現的方便，圖4 為一個臥倒的沙漏)。在沙漏的前半部分，需求的來源主要分三大塊： 客戶反饋(Customer Feedback)、市場行銷部門反饋(Sales and Marketing Feedback) 和競爭對手分析(Competitive Analysis)�；谶@些原始的需求信息，產品部門總結出DOORS 產品的用戶需求，而后是分析得到功能規格來滿足用戶的需求，再分模塊去詳細設計。
重點解釋一下在離散的原始需求和正式的用戶需求之間所發生的整合的動作。正如上文提及的，我們不能期望客戶的反饋是清晰的，是結構化的，但提交給開發部門的需求必須是清晰的、準確的、抽象的和可測試的。整合的動作就是進行信息的梳理和轉換。
重要的是，開發部門使用工具將整合的過程和思路記錄下來。常常在一個項目中聽到這樣的抱怨：客戶(甲方)說不清楚原來提出的需求有沒有在開發中得到體現，或者是直到見到產品了，才能確定需求是否體現，體現在哪里;而開發團隊( 乙方)會抱怨客戶總是到項目后端變來變去，但能和客戶“討價還價”的依據又太少。在沙漏的模型中，最初的需求文檔可以是圖4中列出的，更可以是其他的貼近客戶和市場的記錄形式，如Email，會議記錄等等。整合的過程中，我們需要將用戶需求中的某條需求將和上游的來源文檔中的需求描述部分聯系起來，如利用工具建立類似超鏈接的link。這樣對于需求來源方(客戶和市場部)可以清楚地知道自己的要求在正式的需求文檔中是否有提及， 如何被描述;而對于開發人員來說，也知道這條需求的提出者是誰，原始的描述圖4：一個“沙漏”的示例是如何的，方便地進行評審和確認。
整合還將幫助發現重復的需求：可能一個需求被多方提出，但歸結到用戶需求中只有一條需求，但該條需求對應關聯到多個最初的需求來源。但這條需求得到滿足的時候，多個涉眾都應該能夠通過關聯知曉自己的需求被滿足。此外，整合的意義還在于發現沖突的需求， 這時候就需要產品部門決策和平衡，必要時通知相關人員并做出解釋。沙漏中流淌的是細沙，而我們面對是需求。細沙漏過后直接就沉入瓶底了， 但經過整合后的需求才剛剛開始它的演化之路，用戶需求將被系統功能所對應滿足，系統進而被分解成模塊，同時測試的工作也將展開。這些信息之間的關聯就是反映了需求在沙漏的下半部分被分解和驗證的過程。這樣，層層的關聯可以讓我們從沙漏的前方知曉后方的研發進度和狀態同時，也可以為沙漏的后半部分中研發任務追溯到需求的源泉
文章來源于領測軟件測試網 http://www.kjueaiud.com/
