《需求設計：建構使用者想要和需要的産品》——第1章 情境驅動設計入門1.1 對需求進行設計

本節書摘來自華章計算機《需求設計：建構使用者想要和需要的産品》一書中的第1章，第1.1節,作者：[英]　克裡斯·布裡頓（chris britton） 更多章節内容可以通路雲栖社群“華章計算機”公衆号檢視。

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

要使人意識到自己并不是在收集it應用程式的需求，而是在設計它們。對應用程式所做的設計工作，正是建立在這樣一種認知之上。

要把程式的設計做得像工程學一樣，特别是要在實作之前先對設計進行分析，并尋找其中的缺陷。

要確定目前所開發的應用程式能夠與現有的或同時開發的其他應用程式協同運作，以建立出一套連貫的it架構。

本書要談論如何思考應用程式的設計，以及如何對設計進行分析，而不會過多地涉及如何組織開發團隊、如何管理團隊，以及每隔多久就應該向終端使用者展示新版程式等問題。如果你遵循本書的理念，那麼自然能夠找到很多種規劃并管理項目的辦法。沒有那種能夠适用于每個組織和每種項目的萬能辦法。

筆者首先要在1.1節講解上述第一項主張，也就是對需求進行設計。1.2節會給出一些準備知識，有了這些知識，我們就可以在1.3節中講解上述第二項主張。其後，會在1.4節講解上述第三項主張。

為什麼要對需求進行設計？這麼做合适嗎？就一般意義而言，需求确實用不着設計，但是對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）。

本章開頭一共提出了三項主張，現在已經講解了第一項主張，而剩下的兩項（也就是要像工程學那樣去做設計，以及要使各程式對架構起到推動作用），則需要在我們讨論完一般意義上的設計之後，再進行講解。