本節書摘來自華章計算機《需求設計：構建用戶想要和需要的產品》一書中的第1章，第1.1節,作者：[英]　克里斯·布里頓（Chris Britton） 更多章節內容可以訪問云棲社區“華章計算機”公眾號查看。

第1章 情境驅動設計入門

本書講的是如何設計IT應用程序。筆者寫這本書，是想建議大家采用與原來不同的辦法去做設計，尤其是想進行下列三項變革：

• 要使人意識到自己并不是在收集IT應用程序的需求，而是在設計它們。對應用程序所做的設計工作，正是建立在這樣一種認知之上。
• 要把程序的設計做得像工程學一樣，特別是要在實現之前先對設計進行分析，并尋找其中的缺陷。
• 要確保當前所開發的應用程序能夠與現有的或同時開發的其他應用程序協同運作，以創建出一套連貫的IT架構。

本書要談論如何思考應用程序的設計，以及如何對設計進行分析，而不會過多地涉及如何組織開發團隊、如何管理團隊，以及每隔多久就應該向終端用戶展示新版程序等問題。如果你遵循本書的理念，那么自然能夠找到很多種規劃并管理項目的辦法。沒有那種能夠適用于每個組織和每種項目的萬能辦法。
筆者首先要在1.1節講解上述第一項主張，也就是對需求進行設計。1.2節會給出一些準備知識，有了這些知識，我們就可以在1.3節中講解上述第二項主張。其后，會在1.4節講解上述第三項主張。

1.1　對需求進行設計

為什么要對需求進行設計？這么做合適嗎？就一般意義而言，需求確實用不著設計，但是對IT應用程序來說，這么做卻很有必要。原因非常簡單：沒有誰愿意平白無故地去開發一款商用的IT應用程序，之所以要開發這種程序，是為了給業務提供支持。因此，我們必須注重IT應用程序的設計，令其能夠反映出整個業務解決方案的設計情況。這正如蓋樓的時候必須把地基設計好，因為它會體現整幢房屋的設計。
本書的很多章節都在鼓勵大家改變原來那種為IT應用程序收集需求的消極做法，以一種更為積極的姿態，去對IT應用程序所要支持的業務解決方案進行設計。下面就來解釋這種設計工作為什么這么重要。
要對業務做出變革，是有一定困難的。其中某些變革，可以由公司管理層通過調配資金和資源等手段來強行推進，這屬于那種實現起來相對簡單的情況。此外還有一些變革，推動起來則不太容易，這些變革旨在降低業務運作過程之中的出錯概率、減少成本并提升其靈活度，換句話說，就是想使員工改變他們長久以來所習慣的那種工作方式并將他們移出“舒適區”。如果再把IT應用程序也考慮進去，那么這種情況就更為復雜了。IT應用程序如果推出得比較遲，那么會影響新工作方法的推廣進度，IT應用程序若是做得不夠好、不夠可靠或不夠高效，則會使員工對整個變革計劃產生抗拒情緒。當IT應用程序的功能與使用者的期望不相符時，他們會開始懷疑這個變革計劃是否行得通。
引發上述風險的根本原因在于，一旦將IT應用程序考慮進來，就必須把公司打算推進的業務變革精確地轉化成具體的要求，使員工依照這些要求來改變自己的工作方式。然而，不同的人即使在面對同一個目標時，也會提出不同的實現方式，每個人都認為自己的方式是最好的。如果再加上各部門之間的爭斗、業務環境的變化，以及各個地區在做法和習慣上的差別，那么大家在看法上面的沖突，自然就難以避免了。對于業務變革之中的某些環節（如培訓）來說，你可以不處理這些分歧，并把它們通通掩飾起來，可是一旦涉及新的IT應用程序，那你就必須面對這些分歧了，因為IT應用程序中的計算和編程工作，都必須精準地去完成。舉個非常簡單的例子。大家肯定都見過這樣一種網站：它要求你在輸入框里填寫一些數據，并且會用星號把剛剛輸入的字符遮住。為什么會有這樣的機制呢？或許是有人覺得這份數據相當重要（而且不太可能會遭到仿冒），因而規定客戶必須先把這個字段填好，然后才能繼續訪問該網站，盡管這么做比較麻煩，但他還是強迫訪問者必須輸入這份數據。那么，是不是公司里的每一個人都同意這項決定呢？這很難說。IT應用程序中到處都能遇到這種可疑的決策。是否要求訪問者填寫某個字段，這是個很容易就能修改的決策，然而還有一些決策，會對應用程序或業務的開展方式產生結構性的影響，這些決策修改起來可就不那么容易了。
再來看一個復雜的例子。筆者住在英國，也在那里工作，過去幾年，有些銀行因為違規銷售金融產品而遭到重罰，它們在客戶不知情或沒有獲得足夠信息的情況下，就賣出了一些很昂貴或者沒有必要購買的支付保護保險（Payment Protection Insurance，PPI），這種保險，本來是針對投保人有可能無法償還貸款而設立的。現在假設有一家銀行，想要設法避免這種違規銷售的情況。首先，必須知道問題出在哪里。銀行里面并沒有人會給員工下命令，讓他們去違規銷售產品。之所以會出現違規銷售，是因為銷售人員在銷售目標和獎金等指標上面，受到了銀行所施加的壓力，從而導致自己會瘋狂地向客戶兜售金融產品。這種壓力有可能是直接的，也有可能是間接的。比如，銀行可能把某些支行裝修得很漂亮，把它們打造成銷售金融產品的場所，或者曾經在培訓過程中告訴銷售人員，說每一筆貸款業務都和PPI有聯系。這家銀行以后還是會銷售金融產品，但是要銷售得更加明智。它必須更加理解客戶的想法。如果銀行只告訴員工“以后要好好做”，那么這些員工的工作方式是不可能有太大改觀的。銀行固然可以針對某些事項重新進行培訓，但員工只要看到下一次的獎金計劃，就很可能會把培訓時的內容丟在腦后；此外，如果銀行開始追求更高的業績，那么培訓時的那些話，也有可能等于白說了。于是問題就來了：銀行到底應該怎樣使員工領會這個意思呢？銀行最終采用的辦法是：命令員工在與客戶談話的過程中，向客戶提出一些關鍵問題，并把客戶的答復記錄下來，以便確認這次銷售是否合理。這些問題旨在探查客戶是否確實需要某一款金融產品。不久之后有人建議，應該把客戶對問題所給出的答復，放在新的數據庫里，以后萬一出了問題，可以從這個數據庫中查出對話的雙方以及他們當時所說的內容。又過了一小段時間，銀行發現客戶對這些問題所做的回答，其實是很有價值的營銷信息。緊接著，有人提出（這個人可能是和CEO一起打高爾夫的朋友，他碰巧在一家大型咨詢公司上班）：可以編寫一個應用程序，把客戶對種種問題所給出的回答，全都捕獲到數據庫之中，這樣的應用程序應該很快就能寫好，而且幾乎不需要額外的開銷。這些做法看起來似乎是比較合理的，但只要仔細想想，我們就會發現，其實還有很多事情需要解決，例如：

• 這套辦法針對的是哪些金融產品？所有的金融產品都要按照這套辦法來銷售嗎？
• 如果銷售人員是第二次向某位客戶推銷，那么他是不是還要把上次推銷時問過的那些問題再問一遍？這么做可能會使客戶感到厭煩。
• 除了銷售金融產品本身所需的時間，問這些問題要花費多長時間？銀行為此需要付出哪些成本？
• 應用程序需要把銀行現有的數據用作自己的輸入數據嗎？如果需要，那么具體需要哪些數據？所需的數據存放在什么地方？
• 如何對這些問題做出修改？誰有權修改它們？
• 如果有人修改了問題，那么會不會對數據分析的效果造成影響？（比如，某些分析所依據的數據，既有問題修改之前的數據，也有問題修改之后的數據。）
• 對于某些產品（如房屋貸款）來說，銷售人員在推銷該產品時已經問過很多問題了。那么，剛才構想的那些問題，是屬于一個新的系統，還是屬于對現有系統所做的擴展？如果是新的系統，那么怎樣避免銷售人員重復詢問原來問過的問題呢？
• 如果銀行察覺到客戶的狀況發生了變化（如換工作、移居、離婚等），那么是否需要對賣給客戶的產品重新進行評估？

通過上面這些事項，我們可以看到，如果員工向客戶提出的問題過多，那么這套辦法就將變成一套重復而僵化的流程，客戶與銷售人員都會覺得很煩。
剛才提出的那些事項，主要針對的是銷售流程，而在IT應用程序的開發方面，也有很多因素需要考慮，例如：

• 新程序與現有程序或數據庫之間的集成度應該有多高？
• 這個程序應該怎樣與現有的安全系統相集成？
• 如何防止銷售人員隨意查看客戶的詳細財務信息？
• 有沒有現成的工具可以用來分析數據？

除了上面這4項，還有很多IT方面的事務也有待考慮。
當前的IT應用程序開發，在需求收集方面有兩種辦法。一種辦法是派一個人或一個團隊，以書面或口頭的方式，向利益相關者詢問一些問題，并通過頭腦風暴（brainstorming）或其他手段來提出業務構想。然后，團隊會把這些想法寫成文檔，并在其中指出客戶的需求。這份需求文檔經過審批和簽字之后，會交給公司的IT開發部門來實現。另外一種辦法，是把需求用簡短的文句寫成一份清單，程序員直接根據這張清單來開發程序。軟件每次會推進一小步，推進之前，程序員會與業務代表把這次迭代將要實現的詳細需求確定下來。如果采用這種辦法，那么軟件只要有了進展，就會盡快提供給客戶使用，并且會從客戶那里持續獲得反饋，開發者可以根據這些反饋來擴充早前的那份需求清單。
上面說的這兩種需求收集辦法，都建立在一系列的假設之上，如果這些假設不成立，那么軟件項目就很有可能會失敗。
第一個假設，是認為業務經理總是能夠清晰地回答每一個問題。以早前講過的銀行為例。當我們正準備收集IT應用程序的需求時，很多經理其實根本還沒有開始考慮這些問題。更糟糕的是，有些人會用一些模糊而曖昧的話來回答問題，他們想通過一種過于樂觀和浮夸的語調，來把這些困難的問題通通掩飾過去。只要稍微收集一下需求，你就會發現，需要厘清的細節實在是太多了。然而很多業務經理都是那種不關心細節的人，你如果必須要這些細節問題，他們就會覺得不太舒服。
此外還有一些人，他們要求所有的需求都必須能夠量化，這在一部分程度上是為了防止管理人員給出模糊的答案。例如，他們不喜歡“應用程序必須足夠簡單，以便于公眾使用”這樣的說法，而是要把話說成“用戶必須能夠在5分鐘之內完成操作，用戶的退出率必須小于5%”。其實量化的指標是很難確定的。用5%的退出率來衡量程序的易用性，這是否合適？為什么不用1%或10%呢？而且用戶退出應用程序，或許還有其他一些原因，未必全都是因為該程序很難用。因此，這項指標的意義是不夠明確的。這種指標還有一個缺點，就是會增加項目的開發成本。為了滿足這些指標，必須有人在應用程序中編寫一些代碼，來捕獲原始的數據，而且還必須有人來分析這些數據，以判斷應用程序是否合格。如果應用程序沒有達到預定的指標，那么項目就會延期，因為我們必須試著去修正這個問題。萬一用戶的退出率是6%怎么辦？難道要取消這個開發項目嗎？有的時候，我們應該把這些指標當成一項需求來收集，并且最好是能夠將其變成推進項目的動力，而不要使其成為干擾項目的阻力。但要想做到這一點，首先必須有人真的愿意去關注并處理些指標。很少有哪位業務經理能夠明確地把這些指標講給你聽，對于易用程度這種模糊的概念來說更是如此。即便有人說出了明確的指標，也很有可能是錯誤的，他們不是把指標定得太寬，就是把指標定得太嚴。于是在這個時候，就需要借助一些專業的知識了，也就是說，收集需求的人應該明白怎樣的指標才算合理，并且應該幫助回答問題的人去提出合理的指標。
第二個假設是認為所有的利益相關者都會給出一致的回答。這顯然不成立。經理與經理之間的意見不同，經理與工人之間的意見不同，總部與分支機構或部門經理之間的意見也不同。對于銀行這個例子來說，經理之間很可能在“誰有權確定這些問題”這件事情上面有所分歧。銷售人員的主管可能認為銷售經理可以按照當地的實際情況來修改已經定好的問題，而營銷主管或許完全不同意這樣做。
第三個假設，是認為每一位重要的利益相關者都能夠找得到。實際上，收集需求的人有時可能會漏掉某些重要的利益相關者，尤其是可能漏掉那些位于國外的利益相關者。而且有的時候，可能是有人故意要求他們忽略某些重要的相關方。對于銀行這個例子來說，總部的管理層可能早就料到分行的人會有所抱怨，會說自己總要花時間向用戶問一些他們不想回答的問題，于是，管理層就想提前把這條需求確定下來，以造成一種既成的事實，而不想去和分行的人正面討論這個話題。
文化差異也是個值得考慮的問題。筆者曾經聽到一位日本的業務經理，把西方的業務人員比作槍手，說他們“拔槍很快，但打出去的子彈太慢”。這句話的意思是說，他們可以把產品迅速推向市場，但卻沒有考慮諸多的細節問題，而且沒有提供該產品成功所需的必要支援。此外，公司總是會把某一個人捧成英雄或打成替罪羊，而其他的人則在旁邊看熱鬧，沒有誰愿意站出來給人以支持。這對于IT應用程序的開發來說，是個很嚴重的問題，有的時候，我們明明應該與很多位利益相關者進行溝通，但實際上卻只找了其中的一兩個人來談話。（另外，在很多非西方的文化之中，也有一個對需求收集不利的因素，那就是：當經理出錯時，沒有人愿意指出他的錯誤。）
收集需求的人員或團隊會有一種傾向，他們總是自己來回答這些需求問題。他們很容易就會在不經意間過度地詮釋自己所聽到的話，或是自己內心先設立一種觀點，然后再去聽別人說話。如果你自己已經確信項目就是應該朝這個方向走，那么你只會愿意傾聽那些與自己相符的觀點。心理學家把這叫做認知偏誤（confirmation bias）。
于是，我們就要談到第四條假設，也就是認為高層和業務經理總是會閱讀并理解需求規范文件（requirements specification），并且總是能夠給出明智且周全的反饋意見。有一些項目會把軟件成品的早期樣品拿給業務經理去看，并希望從中得到反饋，對于這樣的項目來說，認知偏誤會以一種相反的形式表現出來，也就是說，經理會提前認定：這個產品已經能夠滿足早前所提出的需求，即便他們當前并沒有發現這些功能，也依然會以為相關的功能位于該應用程序的其他部分，或是認為自己還沒有了解該應用程序的工作原理。
任何一個商業項目，都必須估算開發成本和開發時間，并且要在這兩者與項目所能產生的收益之間進行權衡，這就涉及第五條假設，也就是認為需求團隊能夠很好地估算應用程序的開發時間及運作成本，并且認為高層管理者對應用程序所應具備的功能有足夠的了解，從而可以在各項決策之間做出良好的權衡。
筆者要談的最后一條假設，與IT部門有關。現在我們所要開發的很多應用程序都面臨著與其他IT應用程序之間的集成度問題，而且剛才所舉的那個銀行案例，更是個相當典型的例子。有的時候，要想打造出更高的集成度，就必須在項目前期投入更多的成本，這樣做的好處通常會在項目后期體現出來，因為以后所要開發的內容，可以復用早前已經實現好的某些特性。以銀行那個例子來說，我們可以選擇很多種集成方案，比如，在各程序之間共用同一套單點登錄（single sign-on）機制，以確保安全，或是把新程序所要用到的數據集成到數據庫中現有的客戶表里。如果采用后者，那么設計人員可能就需要決定：到底應該和數據庫里的哪些客戶表進行集成。比如，賬戶數據庫、貸款數據庫和保險數據庫里面，都存放著包含客戶數據的表，那么應該和其中的哪些表相集成呢？（大多數銀行的客戶表實際上都應該不止這三種吧？）于是，這就引出了最后一條假設，也就是認為業務經理能夠明確地看到集成度的問題，以及各種集成方案的優點和缺點，從而可以做出周全的決策。
如果要做的項目很小，涉及的利益相關者很少，他們之間配合得比較好，而且要開發的IT應用程序也不太需要同其他程序進行集成，那么上述的6條假設就有可能是成立的。但如果項目的規模變大，而且應用程序之間的集成變得較為重要，那么上述6條假設則很難成立。這導致的主要結果就是IT應用程序無法滿足業務需求。我們經常看到有些人在項目做到一半的時候去修改需求，這是因為他發覺項目不能具備自己想要的能力。這種做法可能導致項目延期或預算超支。（筆者在前言中說過：很多人以為需求發生變化的常見原因在于業務改變得很快，但筆者卻認為，最常見的原因應該是，利益相關者發現項目正朝著自己當初從來沒有想過的方向發展。）有的時候，收集需求的人自己也發現當初所擬定的假設是不成立的，于是，他們就開始堆砌各種需求，想要把每一種做法都囊括到項目里面。
本書將會提出另外一種與利益相關者進行接觸的方式，使得我們可以構建出合適的需求。筆者所要講的這種方式，建立在一個簡單的道理之上，那就是：IT應用程序的需求，應該是設計流程所輸出的成果。換句話說，我們不能像從樹上摘蘋果那樣，僅僅去“收集”IT應用程序的需求，而是應該設計一套能夠解決業務問題的方案，IT應用程序則是該方案之中的一部分。
銀行的例子可以證實上述觀點。銀行的宏觀需求，是在法律范圍內銷售產品，如果超出了這個邊界，那就會令銀行的信譽受損，而且還會令其遭受罰款。我們當然還可以用成本等方面的標準來擴充這條表述，但其核心的意思依然是要在法律范圍內銷售產品。實際上，許多公司的宏觀標準都可以歸結成像這樣一句很簡單的話。把公司想要做的事情說出來并不會太過復雜，真正有些復雜的，在于要把做這件事的辦法也同時指出來。在本例中，實現該需求的辦法，是設計一套業務解決方案，該方案會對現有的多個銷售流程做出改動，并且會增加某些管理流程及營銷流程。（管理流程是為了監測客戶所給出的答復，營銷流程用來設定銷售人員提給客戶的問題，并對收集到的數據進行分析。）為了給這套業務方案提供支持，我們需要設計一款新的IT應用程序，該應用程序對本方案起著至關重要的作用。
對于解決業務問題來說，設計這個詞聽起來可能有點虛。之所以會有這種感覺，部分原因可能在于：很多業務經理都喜歡更加自由隨興的辦法，也就是先試試某個方案，然后在嘗試的過程中再去修改它。筆者要說的是，用這種辦法來探索通用的設計方案是完全可行的，我們會在1.2.1節中談到這一點。但是，對于IT應用程序，尤其是大型的IT應用程序來說，這種辦法卻不太適合。因為IT應用程序是一種容易僵化而且容易出錯的東西，筆者要告訴你怎樣才能把它做得靈活一些，使其能夠適應變化。也就是說，你只能在一定程度上把它做得柔韌一些。有一款知名的軟件產品，以“靈活而又堅固”來描述它自己，意思是說：我們在塑造它的過程中，可以把該軟件捏成任意的形狀，然而一旦成形，它就會穩定下來。很多IT應用程序也應該達到這種地步。
現在我們就來看看，應該怎樣把“收集需求”轉變成“設計業務解決方案”，以便使我們接下來所要列出的那幾條假設能夠成立。任何一項設計工作之中，都有一個關鍵的階段，筆者將其稱為“設計猜想”（design hypothesis），這些猜想，是我們對該方案所提出的基本想法。銀行那個例子的設計猜想是：在銷售過程中，銷售者向客戶提問，并記錄客戶所給出的答復。設計流程中最花時間的部分，應該是對設計所做的細化，也就是要厘清它的實際內容及各種細節。設計的方式與“只顧收集需求”的方式相比，有一個顯著的區別，那就是，它不會讓人花很多時間去填表，而是會用相當多的時間去展示候選方案并傾聽反饋意見。評價一件事物，要比創建一件事物容易得多。如果你直接詢問他們的需求，他們可能很難把所有的需求全都列出來，但你如果把一兩個備選方案拿給他們，那他們很快能就看出還有哪些需求有待實現，并且能夠指出方案中的錯誤、問題及難點。此外，請各位利益相關者去審閱同一份設計，可以迅速地展現他們之間的觀點分歧。設計提供了一套框架，使我們可以在該框架中找尋折中的辦法。下面列出我們所要確立的幾條假設：

• 假設一：清晰。我們并不指望他人能夠給出清晰的需求，而是要求自己能夠將解決方案的準確圖景清晰地呈現給他人。
• 假設二：歧見能夠消除。如果你把一份備選方案展示出來，那么別人就可以對這份方案進行評判，從而更有可能提出一些替代方案，這樣做使得利益相關者可以在不直接批評同事的情況下，表達出自己的意見。把分歧擺在明處，這樣解決起來更容易。
• 假設三：能夠找到每一位利益相關者。在注重反饋的開放氛圍之下，我們可以把設計方案的電子文檔發給他人，從而更加容易地找到所有的利益相關者。
• 假設四：可以獲得清晰的反饋信息。我們會請利益相關者精確地指出解決方案中的錯誤，這要比請他們來描述解決方案更容易一些。
• 假設五：能夠將成本估算及權衡納入設計流程。實際上，單從業務設計中是很難估算出成本的，你必須進一步把技術解決方案也設計出來，然后才能夠做出精確的估量。第3章將會詳細討論此話題。所幸這一步所花費的時間，與項目的總時間相比并不算多，因而我們可以很快地拿出一些備選的業務解決方案及技術設計方案，使得公司能夠據此做出明智的決策，挑選出時間和預算均不超標的方案。（比如，這些技術設計方案在可用性這一指標方面設置有不同的目標。）
• 假設六：業務經理能夠充分理解各種集成選項，從而可以在這一領域內給出指導意見。大家稍后將會看到，我們在進行設計的過程中，能夠給業務經理呈現出一些集成選項，這些可供選擇的集成方式，都是從數據訪問和信息傳遞的角度來描述的，而不會包含過多的技術詞匯。

筆者把需求設計所產生的結果稱為情境設計（context design），因為它給IT設計提供了情境。正如早前所說的那樣，這種情境設計，一定要能夠向業務經理呈現一幅清晰的圖景，使他們明白當前要構建的這個IT應用程序到底是用來做什么的。
筆者所提出的這一整套設計辦法，可以稱為情境驅動設計（context-driven design）。
本章開頭一共提出了三項主張，現在已經講解了第一項主張，而剩下的兩項（也就是要像工程學那樣去做設計，以及要使各程序對架構起到推動作用），則需要在我們討論完一般意義上的設計之后，再進行講解。

總結

以上是生活随笔為你收集整理的《需求设计：构建用户想要和需要的产品》——第1章 情境驱动设计入门1.1　对需求进行设计...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。