沙漏之喻

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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