沙漏之喻
軟件工程——其實是人們希望從工程領域中學習經驗、借鑑理論 來幫助解決在複雜系統和軟件開發中遇到的問題。然而，隨着軟件工程的實踐，越來越多的人認識到軟件的生產和造橋鋪路等工程項目的最大不同就是在於開發過程 中人的靈活性和創造性。現在軟件工程的發展趨勢也重視和體現到這一點，既需要包含和鼓勵個體的靈活和創造，但同時也希望從工程的角度對活動進行規範，對創 造的過程和結果進行很好的保存和展現。產品/ 項目研發中的需求活動貫穿整個生命週期，前期的市場部門的靈活溝通，廣泛收集的活動到後期研發團隊緊扣需求、巧妙分析、嚴格設計的過程不僅反映了工程的力 量，也體現了“藝術”的技巧。但如何將客戶的凌亂的需求和最後的嚴謹的解決方案聯繫起來，如何將人的活動和工程的工作平衡起來， 如何在更高的層次分析和分配需求都是系統工程的重點，也是實際工作的難點。
上大學時非常喜歡哲學課，它能一個簡單的問題通過辯證複雜化，可把一個複雜的問題通過統一簡單化。這篇文章無意譁衆取寵地追求哲學上的高度， 只是想通過以沙漏爲模型，以需求爲主線，除去細枝末節，更深刻地來認識此間的概念和問題。隨着討論的展開，我們可以看到需求活動的沙漏之喻是如何幫助解答實際工作中的困惑和問題。
從“問題”到“答案”
沙 漏是一種古代的計時工具，以它的式樣來刻畫需求的過程顯得非常恰當。圖1中沙漏的上端對應需求捕獲的過程，沙漏的下面是需求開發找到答案的過程。在需求捕 獲的過程中，我們需要儘可能的擴展我們的思路，爭取能收集所有可能對最後系統或產品產生影響的信息。然而，當沙漏的口開得很大的時候，收集的信息是高度分 散的、凌亂的和非結構化的，有些需要還可能是互相矛盾和衝突的。因此，我們需要沙漏的篩選：對要求解決的問題進行梳理，對系統的範圍做出決定，選擇那些合 適的，現實的需求，需求就得到了精煉。這時候問題陳述就是對系統要解決問題的陳述，而不是所有問題的陳述。通過這樣一個漏斗的過程，漏下來的需求就是我們 系統要滿足的需求，這個時候的需求是一個正式的結構化的信息以交付給開發團隊。在這個基礎上，就可以設計解決方案。
怎 麼來做需求精煉和篩選，下文會有更詳細地討論。在這裏，我想要談的是區分問題領域和解決方案領域，這也是Jeremy Dick 給我們的忠告之一。經常遇到這樣的情形，客戶抱怨花了錢沒有得到有用的產品，而開發團隊也會覺得很鬱悶因爲擁有這麼多而好的功能的系統客戶卻不懂得“欣賞 ”，不願接受。有用和既多且好的功能，這看似統一的表述在這裏卻成了矛盾。什麼對客戶來說是有用的?其實很簡單，能幫助他解決問題是有用的。而那些擁有很 多強大功能的系統和產品如果做不到這一點，矛盾就不可避免。很多團隊負責需求收集的人員有着很強的技術背景，習慣將思考的出發點放在系統應該有什麼樣的功 能， 怎麼實現這些功能。也就是說，他們往往在沒有深入理解客戶問題的情況下直接進入解決方案，而不是首先定義獨立於解決方案的全面而真實需求集合。
那 麼，如何有效地區分問題領域和解決方案領域呢?其實，從需求的原始陳述開始，到最後的系統實現，整個過程是連續的：體現了從問題到解決方案的持續演化;同 時也是離散的，各個階段的需求信息之間應有明顯的差異。最關鍵的區分在涉衆需求和系統需求之間。涉衆需求描述相關涉衆、用戶的想要解決的問題，期望達到的 效果;而系統功能需求則是刻畫爲了要解決提出的問題，相關的產品和系統應該具有怎樣的功能。通過下表的對比，我們可以清楚地看到兩者之間的差別，特別是在 最後一項，兩者在文字描述的差異上更顯示出立足點的不同。
由此可知，我們只有在充分理解用戶想解決的問題的基礎 上，才能正確地分析出系統應該提供哪些功能。首先，研發團隊一定要注意對涉衆真實需求的收集和理解。更進一步看，在涉衆需求的收集和定義階段，風險主要存 在於定義了錯誤的需要解決的問題;相對去後續階段的設計而言，在定義系統需求階段，系統工程師應該只是抽象地描述解決方案，這個階段的風險存在於不必要地 帶入過多地設計約束，影響詳細方案的可能選擇。
可能有讀者會抱怨或懷疑這個思想是不是太理想了:用戶常常就告訴 開發團隊他關於解決方案的設計和想法，這時候怎麼辦?這就更要求我們的需求捕獲人員有清晰的思路，首先，“用戶可能自己也不知道自己需要什麼”，這是常常 發生的事情，我們需要適當地提出“爲什麼”來引導客戶;其次，假定客戶知道自己想要的，那麼客戶提出關於實現的想法也反映了他的潛在目標，也就成爲了我們 設計時的約束。
市場和研發的平衡
在 很多上了一定規模的公司中，有兩個團隊是一定存在且非常重要的：市場部和研發部。市場團隊主要和“人”打交道，進行市場的調研和需求的獲取，這處在圖2中 沙漏的上半部分。在沙漏的下半部分是工程領域，也就是開發隊伍工作的領域。對開發人員來說，他們很少有機會真正地面對客戶，他們工作的基礎就是需求。對一 個項目或產品的成功， 這兩個團隊必須緊密合作，扮演好自己的角色。一旦此間的平衡被打破，團隊就會遇到麻煩。很多公司裏市場部門“坐大”，爲了贏得客戶的定單，或不深入理解客 戶的要求，或是直接“指示”研發部門按照自己對系統實現的理解進行開發。這都違反了上文中提及的需求捕獲的關鍵原則。當另一方面，我也遇到這樣一些公司， 它們是由研發起家， 整個研發部門在公司中佔有比較多的“話語權”。會有這樣的開發經理或人員，可能是出於追求技術領先或完美的熱情， 在滿足用戶需求的同時，也會增加設計/ 實現其他“多餘”的功能點。這些功能點其實是“無源之水”，並沒有實際的市場和用戶需求與之相對應。
需 求將市場部和研發部緊密地聯繫起來，讓兩者之間的有效連接並維護平衡的角色就是團隊中的需求專家。市場部和直接的用戶，以及相關係統的投資方、監管方、維 護方等等進行交流，我們不能保證他們能夠提供準確的清晰的需求描述，因爲他們只是在提出他們的問題和對結果的期望，而且要求我們的客戶去學習什麼是好的需 求和如何提需求是不現實的。現實的是團隊中有這麼一些人，熟悉領域且受到過需求管理方面的指導和培訓，他們知道應該怎麼去收集、分析和總結需求。例如在西 門子， 負責捕獲客戶需求的工作主要由市場部人員去做，但並不是直接將這些需求轉給開發部。有一個需求管理小組，隸屬於研發中心，主要職責則相當於市場部和開發部 的一個接口。需求工程師對從市場部那裏獲取的零散和龐大的需求文檔進行整理和分類，然後提交給開發部。開發人員不需要和市場部爭論哪些事情做得到還是做不 到，而是由需求工程師來做。(具體參見《探索需求管理的三步曲》——《程序員》2005年9月刊) 這是一個很好的做法，需求工程師可以是一個職位，也可以是一個角色。單獨的職位可能在小的團隊中不太實際，但擁有這個角色的人自己必須很清楚自己的位置： 是處在市場和研發中間，需要維護好平衡，做好接口的工作。
產品線需求 vs 具體項目需求
研 發團隊的項目性質很大程度上決定了需求管理做到的深度和廣度。有項目經理問，我的項目週期常常只有幾個月半年的，還需要做需求管理嗎?誠然，若是一些沒有 專注業務領域的團隊，他們項目的時間短，而且沒有類似的後續項目，可以不必在需求管理上面投入太多的資源。而另一方面，如果這個項目是一個產品發展的某一 個階段，我們就要重新審視這個問題。就如一個做打印機的日本公司在上海的研發團隊，他們的項目週期也是半年左右，但是一個基本型號的打印機已經有二十年的 歷史。也就是說，現在的這款打印機是一個個小的項目的開發成果的累計。這時，該開發團隊就需要很好的需求管理，而且需求管理已經不再侷限在某個項目裏。
市場的激烈競爭，企業自身的發展，我們看到一個產品的需求往往會非常多。如果全部實現，那將是一個“完美”的結果。時間和資源的現實面前，決策層需要進行選擇：既要快速地將產品發佈面世， 同時新的版本中也需要有足夠地引起客戶購買慾望的需求實現。
這 裏需要決策。孫子兵法中的“勝兵，先勝而後求戰;敗兵，先戰而後求勝”早就闡述類似的道理：打勝仗的部隊是在有勝算時之後才投入戰鬥，打敗仗的部隊先投入 戰鬥，才尋求勝利的條件。需求工作的重要性是老生常談的事情了，不是本文的重點。我們關注的是如何做出正確的決策而佔得先機。
沙 漏的上半部分強調的是在產品和項目的規劃階段，我們需要將做出正確的決策以滿足現在市場的需要。這體現在收集和記錄正確的需求;對需求的重要程度做出準確 的刻畫;基於成本和效益來規劃產品的路線圖，將需求的實現分配到各個的項目中。在需求明確的前提，項目經理就可以帶領他的團隊開展工作，這個階段的重點就 是如何保證需求在每一個研發的每個階段都得到嚴格的滿足和測試，而切實保證需求驅動開發和保證需求驅動測試，是研發團隊將事情做正確的關鍵。
決 策的重要基礎是對需求的重要程度進行排序。但排序的基準在哪裏，且基準也會隨着個人的角度和時間的推移而變化?如果讀者參與產品和系統規劃的工作，嘗試着 回答下面的問題：所有來自A地區客戶的緊急程度爲高的且估算工作量在180 個人天以下的所有需求有哪些?他們現在的項目狀態如何?這是一個問題的簡單樣本，問題的實質在於決策者可能需要從多個角度去分析需求，並需要在衆多需求中 找出最重要的或者是當前最感興趣的需求的子集。在沒有方法的指導和工具的支持下，這個工作在競爭越來越激烈的現在是越來越難了，因爲決策者往往面對多個產 品， 多個市場，多個競爭對手，當然還有時間和成本的壓力。
“沙漏”的具體實踐
沙漏雖然是個比喻，但實際上有很多公司都在實踐這種思路。以Telelogic公司開發DOORS 這個產品爲例，該產品的信息架構也呈沙漏的形狀(爲了展現的方便，圖4 爲一個臥倒的沙漏)。在沙漏的前半部分，需求的來源主要分三大塊： 客戶反饋(Customer Feedback)、市場行銷部門反饋(Sales and Marketing Feedback) 和競爭對手分析(Competitive Analysis)。基於這些原始的需求信息，產品部門總結出DOORS 產品的用戶需求，而後是分析得到功能規格來滿足用戶的需求，再分模塊去詳細設計。
重點解釋一下在離散的原始需求和正式的用戶需求之間所發生的整合的動作。正如上文提及的，我們不能期望客戶的反饋是清晰的，是結構化的，但提交給開發部門的需求必須是清晰的、準確的、抽象的和可測試的。整合的動作就是進行信息的梳理和轉換。
重 要的是，開發部門使用工具將整合的過程和思路記錄下來。常常在一個項目中聽到這樣的抱怨：客戶(甲方)說不清楚原來提出的需求有沒有在開發中得到體現，或 者是直到見到產品了，才能確定需求是否體現，體現在哪裏;而開發團隊( 乙方)會抱怨客戶總是到項目後端變來變去，但能和客戶“討價還價”的依據又太少。在沙漏的模型中，最初的需求文檔可以是圖4中列出的，更可以是其他的貼近 客戶和市場的記錄形式，如Email，會議記錄等等。整合的過程中，我們需要將用戶需求中的某條需求將和上游的來源文檔中的需求描述部分聯繫起來，如利用 工具建立類似超鏈接的link。這樣對於需求來源方(客戶和市場部)可以清楚地知道自己的要求在正式的需求文檔中是否有提及， 如何被描述;而對於開發人員來說，也知道這條需求的提出者是誰，原始的描述圖4：一個“沙漏”的示例是如何的，方便地進行評審和確認。
整 合還將幫助發現重複的需求：可能一個需求被多方提出，但歸結到用戶需求中只有一條需求，但該條需求對應關聯到多個最初的需求來源。但這條需求得到滿足的時 候，多個涉衆都應該能夠通過關聯知曉自己的需求被滿足。此外，整合的意義還在於發現衝突的需求， 這時候就需要產品部門決策和平衡，必要時通知相關人員並做出解釋。沙漏中流淌的是細沙，而我們面對是需求。細沙漏過後直接就沉入瓶底了， 但經過整合後的需求才剛剛開始它的演化之路，用戶需求將被系統功能所對應滿足，系統進而被分解成模塊，同時測試的工作也將展開。這些信息之間的關聯就是反 映了需求在沙漏的下半部分被分解和驗證的過程。這樣，層層的關聯可以讓我們從沙漏的前方知曉後方的研發進度和狀態同時，也可以爲沙漏的後半部分中研發任務 追溯到需求的源泉。
