沙漏之喻

　　軟件工程——其實是人們希望從工程領域中學習經(jīng)驗、借鑒理論來幫助解決在復雜系統(tǒng)和軟件開發(fā)中遇到的問題。然而，隨著軟件工程的實踐，越來越多的人認識到軟件的生產(chǎn)和造橋鋪路等工程項目的最大不同就是在于開發(fā)過程中人的靈活性和創(chuàng)造性?，F(xiàn)在軟件工程的發(fā)展趨勢也重視和體現(xiàn)到這一點，既需要包含和鼓勵個體的靈活和創(chuàng)造，但同時也希望從工程的角度對活動進行規(guī)范，對創(chuàng)造的過程和結(jié)果進行很好的保存和展現(xiàn)。產(chǎn)品/ 項目研發(fā)中的需求活動貫穿整個生命周期，前期的市場部門的靈活溝通，廣泛收集的活動到后期研發(fā)團隊緊扣需求、巧妙分析、嚴格設計的過程不僅反映了工程的力量，也體現(xiàn)了“藝術”的技巧。但如何將客戶的凌亂的需求和最后的嚴謹?shù)慕鉀Q方案聯(lián)系起來，如何將人的活動和工程的工作平衡起來， 如何在更高的層次分析和分配需求都是系統(tǒng)工程的重點，也是實際工作的難點。

　上大學時非常喜歡哲學課，它能一個簡單的問題通過辯證復雜化，可把一個復雜的問題通過統(tǒng)一簡單化。這篇文章無意嘩眾取寵地追求哲學上的高度， 只是想通過以沙漏為模型，以需求為主線，除去細枝末節(jié)，更深刻地來認識此間的概念和問題。隨著討論的展開，我們可以看到需求活動的沙漏之喻是如何幫助解答實際工作中的困惑和問題。
　　
　　從“問題”到“答案”

　　沙漏是一種古代的計時工具，以它的式樣來刻畫需求的過程顯得非常恰當。圖1中沙漏的上端對應需求捕獲的過程，沙漏的下面是需求開發(fā)找到答案的過程。在需求捕獲的過程中，我們需要盡可能的擴展我們的思路，爭取能收集所有可能對最后系統(tǒng)或產(chǎn)品產(chǎn)生影響的信息。然而，當沙漏的口開得很大的時候，收集的信息是高度分散的、凌亂的和非結(jié)構(gòu)化的，有些需要還可能是互相矛盾和沖突的。因此，我們需要沙漏的篩選：對要求解決的問題進行梳理，對系統(tǒng)的范圍做出決定，選擇那些合適的，現(xiàn)實的需求，需求就得到了精煉。這時候問題陳述就是對系統(tǒng)要解決問題的陳述，而不是所有問題的陳述。通過這樣一個漏斗的過程，漏下來的需求就是我們系統(tǒng)要滿足的需求，這個時候的需求是一個正式的結(jié)構(gòu)化的信息以交付給開發(fā)團隊。在這個基礎上，就可以設計解決方案。

　怎么來做需求精煉和篩選，下文會有更詳細地討論。在這里，我想要談的是區(qū)分問題領域和解決方案領域，這也是Jeremy Dick 給我們的忠告之一。經(jīng)常遇到這樣的情形，客戶抱怨花了錢沒有得到有用的產(chǎn)品，而開發(fā)團隊也會覺得很郁悶因為擁有這么多而好的功能的系統(tǒng)客戶卻不懂得“欣賞”，不愿接受。有用和既多且好的功能，這看似統(tǒng)一的表述在這里卻成了矛盾。什么對客戶來說是有用的？其實很簡單，能幫助他解決問題是有用的。而那些擁有很多強大功能的系統(tǒng)和產(chǎn)品如果做不到這一點，矛盾就不可避免。很多團隊負責需求收集的人員有著很強的技術背景，習慣將思考的出發(fā)點放在系統(tǒng)應該有什么樣的功能， 怎么實現(xiàn)這些功能。也就是說，他們往往在沒有深入理解客戶問題的情況下直接進入解決方案，而不是首先定義獨立于解決方案的全面而真實需求集合。

　那么，如何有效地區(qū)分問題領域和解決方案領域呢？其實，從需求的原始陳述開始，到最后的系統(tǒng)實現(xiàn)，整個過程是連續(xù)的：體現(xiàn)了從問題到解決方案的持續(xù)演化；同時也是離散的，各個階段的需求信息之間應有明顯的差異。最關鍵的區(qū)分在涉眾需求和系統(tǒng)需求之間。涉眾需求描述相關涉眾、用戶的想要解決的問題，期望達到的效果；而系統(tǒng)功能需求則是刻畫為了要解決提出的問題，相關的產(chǎn)品和系統(tǒng)應該具有怎樣的功能。通過下表的對比，我們可以清楚地看到兩者之間的差別，特別是在最后一項，兩者在文字描述的差異上更顯示出立足點的不同。

　由此可知，我們只有在充分理解用戶想解決的問題的基礎上，才能正確地分析出系統(tǒng)應該提供哪些功能。首先，研發(fā)團隊一定要注意對涉眾真實需求的收集和理解。更進一步看，在涉眾需求的收集和定義階段，風險主要存在于定義了錯誤的需要解決的問題；相對去后續(xù)階段的設計而言，在定義系統(tǒng)需求階段，系統(tǒng)工程師應該只是抽象地描述解決方案，這個階段的風險存在于不必要地帶入過多地設計約束，影響詳細方案的可能選擇。

　可能有讀者會抱怨或懷疑這個思想是不是太理想了:用戶常常就告訴開發(fā)團隊他關于解決方案的設計和想法，這時候怎么辦？這就更要求我們的需求捕獲人員有清晰的思路，首先，“用戶可能自己也不知道自己需要什么”，這是常常發(fā)生的事情，我們需要適當?shù)靥岢觥盀槭裁础眮硪龑Э蛻簦黄浯?，假定客戶知道自己想要的，那么客戶提出關于實現(xiàn)的想法也反映了他的潛在目標，也就成為了我們設計時的約束。

　 市場和研發(fā)的平衡

　　在很多上了一定規(guī)模的公司中，有兩個團隊是一定存在且非常重要的：市場部和研發(fā)部。市場團隊主要和“人”打交道，進行市場的調(diào)研和需求的獲取，這處在圖2中沙漏的上半部分。在沙漏的下半部分是工程領域，也就是開發(fā)隊伍工作的領域。對開發(fā)人員來說，他們很少有機會真正地面對客戶，他們工作的基礎就是需求。對一個項目或產(chǎn)品的成功， 這兩個團隊必須緊密合作，扮演好自己的角色。一旦此間的平衡被打破，團隊就會遇到麻煩。很多公司里市場部門“坐大”，為了贏得客戶的定單，或不深入理解客戶的要求，或是直接“指示”研發(fā)部門按照自己對系統(tǒng)實現(xiàn)的理解進行開發(fā)。這都違反了上文中提及的需求捕獲的關鍵原則。當另一方面，我也遇到這樣一些公司，它們是由研發(fā)起家， 整個研發(fā)部門在公司中占有比較多的“話語權”。會有這樣的開發(fā)經(jīng)理或人員，可能是出于追求技術領先或完美的熱情， 在滿足用戶需求的同時，也會增加設計/ 實現(xiàn)其他“多余”的功能點。這些功能點其實是“無源之水”，并沒有實際的市場和用戶需求與之相對應。

　需求將市場部和研發(fā)部緊密地聯(lián)系起來，讓兩者之間的有效連接并維護平衡的角色就是團隊中的需求專家。市場部和直接的用戶，以及相關系統(tǒng)的投資方、監(jiān)管方、維護方等等進行交流，我們不能保證他們能夠提供準確的清晰的需求描述，因為他們只是在提出他們的問題和對結(jié)果的期望，而且要求我們的客戶去學習什么是好的需求和如何提需求是不現(xiàn)實的。現(xiàn)實的是團隊中有這么一些人，熟悉領域且受到過需求管理方面的指導和培訓，他們知道應該怎么去收集、分析和總結(jié)需求。例如在西門子， 負責捕獲客戶需求的工作主要由市場部人員去做，但并不是直接將這些需求轉(zhuǎn)給開發(fā)部。有一個需求管理小組，隸屬于研發(fā)中心，主要職責則相當于市場部和開發(fā)部的一個接口。需求工程師對從市場部那里獲取的零散和龐大的需求文檔進行整理和分類，然后提交給開發(fā)部。開發(fā)人員不需要和市場部爭論哪些事情做得到還是做不到，而是由需求工程師來做。（具體參見《探索需求管理的三步曲》——《程序員》2005年9月刊） 這是一個很好的做法，需求工程師可以是一個職位，也可以是一個角色。單獨的職位可能在小的團隊中不太實際，但擁有這個角色的人自己必須很清楚自己的位置：是處在市場和研發(fā)中間，需要維護好平衡，做好接口的工作。

　 產(chǎn)品線需求 vs 具體項目需求

　　研發(fā)團隊的項目性質(zhì)很大程度上決定了需求管理做到的深度和廣度。有項目經(jīng)理問，我的項目周期常常只有幾個月半年的，還需要做需求管理嗎？誠然，若是一些沒有專注業(yè)務領域的團隊，他們項目的時間短，而且沒有類似的后續(xù)項目，可以不必在需求管理上面投入太多的資源。而另一方面，如果這個項目是一個產(chǎn)品發(fā)展的某一個階段，我們就要重新審視這個問題。就如一個做打印機的日本公司在上海的研發(fā)團隊，他們的項目周期也是半年左右，但是一個基本型號的打印機已經(jīng)有二十年的歷史。也就是說，現(xiàn)在的這款打印機是一個個小的項目的開發(fā)成果的累計。這時，該開發(fā)團隊就需要很好的需求管理，而且需求管理已經(jīng)不再局限在某個項目里。

　市場的激烈競爭，企業(yè)自身的發(fā)展，我們看到一個產(chǎn)品的需求往往會非常多。如果全部實現(xiàn)，那將是一個“完美”的結(jié)果。時間和資源的現(xiàn)實面前，決策層需要進行選擇：既要快速地將產(chǎn)品發(fā)布面世， 同時新的版本中也需要有足夠地引起客戶購買欲望的需求實現(xiàn)。

　這里需要決策。孫子兵法中的“勝兵，先勝而后求戰(zhàn)；敗兵，先戰(zhàn)而后求勝”早就闡述類似的道理：打勝仗的部隊是在有勝算時之后才投入戰(zhàn)斗，打敗仗的部隊先投入戰(zhàn)斗，才尋求勝利的條件。需求工作的重要性是老生常談的事情了，不是本文的重點。我們關注的是如何做出正確的決策而占得先機。

　沙漏的上半部分強調(diào)的是在產(chǎn)品和項目的規(guī)劃階段，我們需要將做出正確的決策以滿足現(xiàn)在市場的需要。這體現(xiàn)在收集和記錄正確的需求；對需求的重要程度做出準確的刻畫；基于成本和效益來規(guī)劃產(chǎn)品的路線圖，將需求的實現(xiàn)分配到各個的項目中。在需求明確的前提，項目經(jīng)理就可以帶領他的團隊開展工作，這個階段的重點就是如何保證需求在每一個研發(fā)的每個階段都得到嚴格的滿足和測試，而切實保證需求驅(qū)動開發(fā)和保證需求驅(qū)動測試，是研發(fā)團隊將事情做正確的關鍵。

　決策的重要基礎是對需求的重要程度進行排序。但排序的基準在哪里，且基準也會隨著個人的角度和時間的推移而變化？如果讀者參與產(chǎn)品和系統(tǒng)規(guī)劃的工作，嘗試著回答下面的問題：所有來自A地區(qū)客戶的緊急程度為高的且估算工作量在180 個人天以下的所有需求有哪些？他們現(xiàn)在的項目狀態(tài)如何？這是一個問題的簡單樣本，問題的實質(zhì)在于決策者可能需要從多個角度去分析需求，并需要在眾多需求中找出最重要的或者是當前最感興趣的需求的子集。在沒有方法的指導和工具的支持下，這個工作在競爭越來越激烈的現(xiàn)在是越來越難了，因為決策者往往面對多個產(chǎn)品， 多個市場，多個競爭對手，當然還有時間和成本的壓力。
　　
　 “沙漏”的具體實踐

　　沙漏雖然是個比喻，但實際上有很多公司都在實踐這種思路。以Telelogic公司開發(fā)DOORS 這個產(chǎn)品為例，該產(chǎn)品的信息架構(gòu)也呈沙漏的形狀（為了展現(xiàn)的方便，圖4 為一個臥倒的沙漏）。在沙漏的前半部分，需求的來源主要分三大塊： 客戶反饋（Customer Feedback）、市場行銷部門反饋（Sales and Marketing Feedback） 和競爭對手分析（Competitive Analysis）?；谶@些原始的需求信息，產(chǎn)品部門總結(jié)出DOORS 產(chǎn)品的用戶需求，而后是分析得到功能規(guī)格來滿足用戶的需求，再分模塊去詳細設計。

　重點解釋一下在離散的原始需求和正式的用戶需求之間所發(fā)生的整合的動作。正如上文提及的，我們不能期望客戶的反饋是清晰的，是結(jié)構(gòu)化的，但提交給開發(fā)部門的需求必須是清晰的、準確的、抽象的和可測試的。整合的動作就是進行信息的梳理和轉(zhuǎn)換。

　重要的是，開發(fā)部門使用工具將整合的過程和思路記錄下來。常常在一個項目中聽到這樣的抱怨：客戶（甲方）說不清楚原來提出的需求有沒有在開發(fā)中得到體現(xiàn)，或者是直到見到產(chǎn)品了，才能確定需求是否體現(xiàn)，體現(xiàn)在哪里；而開發(fā)團隊（ 乙方）會抱怨客戶總是到項目后端變來變?nèi)ィ芎涂蛻簟坝憙r還價”的依據(jù)又太少。在沙漏的模型中，最初的需求文檔可以是圖4中列出的，更可以是其他的貼近客戶和市場的記錄形式，如Email，會議記錄等等。整合的過程中，我們需要將用戶需求中的某條需求將和上游的來源文檔中的需求描述部分聯(lián)系起來，如利用工具建立類似超鏈接的link。這樣對于需求來源方（客戶和市場部）可以清楚地知道自己的要求在正式的需求文檔中是否有提及， 如何被描述；而對于開發(fā)人員來說，也知道這條需求的提出者是誰，原始的描述圖4：一個“沙漏”的示例是如何的，方便地進行評審和確認。

　整合還將幫助發(fā)現(xiàn)重復的需求：可能一個需求被多方提出，但歸結(jié)到用戶需求中只有一條需求，但該條需求對應關聯(lián)到多個最初的需求來源。但這條需求得到滿足的時候，多個涉眾都應該能夠通過關聯(lián)知曉自己的需求被滿足。此外，整合的意義還在于發(fā)現(xiàn)沖突的需求， 這時候就需要產(chǎn)品部門決策和平衡，必要時通知相關人員并做出解釋。沙漏中流淌的是細沙，而我們面對是需求。細沙漏過后直接就沉入瓶底了， 但經(jīng)過整合后的需求才剛剛開始它的演化之路，用戶需求將被系統(tǒng)功能所對應滿足，系統(tǒng)進而被分解成模塊，同時測試的工作也將展開。這些信息之間的關聯(lián)就是反映了需求在沙漏的下半部分被分解和驗證的過程。這樣，層層的關聯(lián)可以讓我們從沙漏的前方知曉后方的研發(fā)進度和狀態(tài)同時，也可以為沙漏的后半部分中研發(fā)任務追溯到需求的源泉。

【?發(fā)表評論?0條?】