沙漏之喻
    軟件工程——其實是人們希望從工程領域中學習經驗、借鑒理論來幫助解決在復雜系統(tǒng)和軟件開發(fā)中遇到的問題。然而，隨著軟件工程的實踐，越來越多的人認識到軟件的生產和造橋鋪路等工程項目的最大不同就是在于開發(fā)過程中人的靈活性和創(chuàng)造性?，F在軟件工程的發(fā)展趨勢也重視和體現到這一點，既需要包含和鼓勵個體的靈活和創(chuàng)造，但同時也希望從工程的角度對活動進行規(guī)范，對創(chuàng)造的過程和結果進行很好的保存和展現。產品/ 項目研發(fā)中的需求活動貫穿整個生命周期，前期的市場部門的靈活溝通，廣泛收集的活動到后期研發(fā)團隊緊扣需求、巧妙分析、嚴格設計的過程不僅反映了工程的力量，也體現了“藝術”的技巧。但如何將客戶的凌亂的需求和最后的嚴謹的解決方案聯(lián)系起來，如何將人的活動和工程的工作平衡起來， 如何在更高的層次分析和分配需求都是系統(tǒng)工程的重點，也是實際工作的難點。
    上大學時非常喜歡哲學課，它能一個簡單的問題通過辯證復雜化，可把一個復雜的問題通過統(tǒng)一簡單化。這篇文章無意嘩眾取寵地追求哲學上的高度， 只是想通過以沙漏為模型，以需求為主線，除去細枝末節(jié)，更深刻地來認識此間的概念和問題。隨著討論的展開，我們可以看到需求活動的沙漏之喻是如何幫助解答實際工作中的困惑和問題。
從“問題”到“答案”
    沙漏是一種古代的計時工具，以它的式樣來刻畫需求的過程顯得非常恰當。圖1中沙漏的上端對應需求捕獲的過程，沙漏的下面是需求開發(fā)找到答案的過程。在需求捕獲的過程中，我們需要盡可能的擴展我們的思路，爭取能收集所有可能對最后系統(tǒng)或產品產生影響的信息。然而，當沙漏的口開得很大的時候，收集的信息是高度分散的、凌亂的和非結構化的，有些需要還可能是互相矛盾和沖突的。因此，我們需要沙漏的篩選：對要求解決的問題進行梳理，對系統(tǒng)的范圍做出決定，選擇那些合適的，現實的需求，需求就得到了精煉。這時候問題陳述就是對系統(tǒng)要解決問題的陳述，而不是所有問題的陳述。通過這樣一個漏斗的過程，漏下來的需求就是我們系統(tǒng)要滿足的需求，這個時候的需求是一個正式的結構化的信息以交付給開發(fā)團隊。在這個基礎上，就可以設計解決方案。
    怎么來做需求精煉和篩選，下文會有更詳細地討論。在這里，我想要談的是區(qū)分問題領域和解決方案領域，這也是Jeremy Dick 給我們的忠告之一。經常遇到這樣的情形，客戶抱怨花了錢沒有得到有用的產品，而開發(fā)團隊也會覺得很郁悶因為擁有這么多而好的功能的系統(tǒng)客戶卻不懂得“欣賞”，不愿接受。有用和既多且好的功能，這看似統(tǒng)一的表述在這里卻成了矛盾。什么對客戶來說是有用的?其實很簡單，能幫助他解決問題是有用的。而那些擁有很多強大功能的系統(tǒng)和產品如果做不到這一點，矛盾就不可避免。很多團隊負責需求收集的人員有著很強的技術背景，習慣將思考的出發(fā)點放在系統(tǒng)應該有什么樣的功能， 怎么實現這些功能。也就是說，他們往往在沒有深入理解客戶問題的情況下直接進入解決方案，而不是首先定義獨立于解決方案的全面而真實需求集合。
    那么，如何有效地區(qū)分問題領域和解決方案領域呢?其實，從需求的原始陳述開始，到最后的系統(tǒng)實現，整個過程是連續(xù)的：體現了從問題到解決方案的持續(xù)演化;同時也是離散的，各個階段的需求信息之間應有明顯的差異。最關鍵的區(qū)分在涉眾需求和系統(tǒng)需求之間。涉眾需求描述相關涉眾、用戶的想要解決的問題，期望達到的效果;而系統(tǒng)功能需求則是刻畫為了要解決提出的問題，相關的產品和系統(tǒng)應該具有怎樣的功能。通過下表的對比，我們可以清楚地看到兩者之間的差別，特別是在最后一項，兩者在文字描述的差異上更顯示出立足點的不同。
    由此可知，我們只有在充分理解用戶想解決的問題的基礎上，才能正確

    項目經理勝任力免費測評PMQ上線啦！快來測測你排多少名吧~

    http://opto-elec.com.cn/pmqhd/index.html