《需求設計：建構使用者想要和需要的産品》——2.2 情境設計

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

情境設計需要解釋it開發所面對的業務需求。情境設計之中的元素是任務、使用者組、資料表及任務之間的消息。本章用4個小節分别講述這4種元素，然後再用3個小節來講解任務之間的依賴關系、元素之間的綜合以及對情境設計所做的分析。

2.2.1　任務

筆者在前面說過，業務需要分割成多項任務。那麼，什麼是任務？

如果你在公司逛一圈，并且想象一下：當辦公室裡的人用it應用程式收發資訊時，有紅色光環從頭頂冒出來，那你就會發現，這些光環每次出現的時間很短。它們就好比任務。大多數任務的持續時間都很短，一般是幾分鐘甚至更少，而兩項任務之間的間隔時間，則比我們花在單項任務上面的時間要長。即便是像銀行櫃員這樣的工作，也依然如此。盡管會有很多人在排隊等候服務，但銀行櫃員使用it程式的時間卻很短，剩下的時間基本都用來點鈔、等候客戶填表或簽字，以及等某位客戶離開并接待下一位客戶。下面所列的這些事情，可以視為任務：

為顧客辦理酒店入住手續。

從atm取錢。

對傳遞情況進行記錄。

為警方出警安排車輛。

送出訂單。

現在筆者要更準确地解釋一下任務這個詞的定義。首先要澄清的是：在做業務模組化的時候，很少有人像筆者這樣，用任務（task）一詞來表達某種精确的含義。我之是以搬出來任務這個說法，是覺得它與活動（activity）、用例（use case）、事務（transaction）或動作（action）等詞相比，含義更加單純。如果業務流程分析師要表達與任務一詞相同的意思，那他們會采用“某人、某地、某時”的格式來解說。然而筆者覺得把地點（place）與其他兩項因素并立，會顯得有些奇怪，因為同一個人在同一時刻，隻能出現在一個地點，不是嗎？是以，筆者覺得應該把這個因素換成裝置（device），這樣我們就可以區分某人在某一時刻操作軟體時，到底是用計算機操作的，還是用手機操作的。我們還可以說得再嚴謹一些：由于web浏覽器能夠在同一時刻連接配接多個應用程式，是以可以考慮把裝置因素改稱為裝置/分頁（device/tab）。這樣，“某人、某地、某時”就變成“某人、某時、某裝置/某分頁”，現在應該不會太奇怪了吧？于是，筆者把這個概念稱作任務。

但為了給任務下一個更加正規的定義，我們還必須讨論原子性（atomicity）。對業務操作進行模組化的時候，必須确定一種最底層的工作單元。這種工作單元必須是原子的，也就是說，該單元要麼徹底完工，要麼根本就沒開工，而不會出現模棱兩可的狀态。原子性并不意味着本單元隻能産生一項結果。一個工作單元可以有多種執行結果，但這些結果必須可以定義，也就是說，我們必須能夠把這些結果全都羅列出來，并且要能夠針對每一種結果做出精确的定義。這些結果之中，可能包含着對資料庫所做的更新。綜上所述，我們可以把任務一詞更好地定義為：

某人于某時所完成的原子工作單元。

任務是具備原子性的，這意味着如果它在沒有給出結果之前就失敗了，那麼我們必須還原該任務的所有效果，使其看上去好像從來沒有執行過一樣。同一項任務之是以可能産生不同的結果，通常是因為使用者可能會做出不同的決策，然而做情境設計的人，還應該考慮到下面兩種狀況：

it應用程式發生故障（例如，伺服器斷電）。

使用者在任務尚未完工時就将其停止了（例如，使用者要去吃午飯、要急着回家）。

為了應對上述兩種狀況，情境設計師可以把已有的更新儲存在資料庫中，而不是把所有的工作全都複原。如果決定要這麼做，那就得定義兩項任務，一項任務描述的是x已經啟動并且有可能已經做完，而另一項任務描述的則是x已經徹底完工。之是以要将二者分開，是因為x有可能是在啟動很久之後，才最終完工的。

你或許覺得任務的原子性與資料庫事務的原子性，在概念上有些相似。大家可能知道，資料庫事務不僅具備原子性（atomicity），而且還具備一緻性（consistency）、隔離性（isolation）以及持久性（durability），這四項特征合起來稱為acid。那麼，除了a之外，c、i、d這三項特征，在任務之中是否有所展現呢？它們确實是有所展現的，隻不過展現得不像資料庫事務那麼突出罷了，本書第8章還會講到這個問題。接下來你可能會問，既然這四項特征都有所展現，那麼可不可以把任務與資料庫事務等價起來呢？這恐怕不行，因為任務通常還涉及使用者與it應用程式之間來回傳遞消息的問題，是以我們一般不能直接用資料庫的事務處理功能來實作它。但确實有一些任務完全依賴于資料庫的事務處理功能，例如，對資料庫進行更新的任務，就需要通過一個或多個資料庫事務來實作。

為了更好地了解上面這個意思，你可以這樣想：業務是以任務為步驟而推進的。

有些讀者可能會懷疑：“為什麼不把它叫做用例，而要說成任務呢？”用例确實也可以用來描述任務，但麻煩的是，用例這個詞，還可以用來指代其他很多事情。第3章會詳細讨論這個問題。

還有一些讀者可能會問：“任務難道不是業務流程之中的活動嗎？”（也就是說，他們認為任務應該像業務流程圖之中的活動一樣，表示成方框。）筆者覺得，一項活動可以拆解成多個任務。例如，在路上挖洞，可以視為一項活動，該活動之中可以有兩個任務，一個任務發生在活動開始的時候，此時領隊者指令團隊開始挖掘，另一個任務出現在活動結束的時候，此時團隊已經完成了挖掘。本書第5章會讨論這個話題。

以前的人在尋找新的技術詞彙時，會從拉丁語和古希臘語裡面取材。筆者在想，it界是不是也應該這麼做。

2.2.2　使用者組

使用者界面設計者所要知道的另外一種資訊，是使用者的分組情況。使用者組（user group）是對使用者所做的分類，如銷售人員、倉庫經理、安全人員等。需要注意的是，同一名員工可能會屬于多個使用者組，例如，某人可以同時屬于銷售人員、銷售經理、雇員與經理這四個組。（作為銷售人員，他要送出訂單，作為銷售經理，他要檢視銷售報告，作為雇員，他要送出報帳單，作為經理，他要進行人事評審。）不同的使用者組對應用程式有着不同的通路權，某一個使用者組的成員所能看到的資料，可能與其他使用者組有所差別，而且其成員所應完成的任務，也與其他使用者組有所不同（盡管這些任務之間可能有某種重疊）。使用者界面的設計者需要決定：是給每個使用者組提供不同的界面，還是給所有的使用者組都提供同一套界面，并根據目前使用者所在的組，對該界面進行定制。

筆者之是以說使用者組而不說角色或使用者角色，是因為角色（role）這個詞，可能會使某些人一下子就想到實作層面，而且我也不願意用actor（行動者）這個詞，因為使用者并不是行動者。

2.2.3　資料表

業務型的應用程式，其主要目标通常是存儲資料以供稍後使用。如果對資料沒有概念，那就不太可能把應用程式描述出來。銀行業會有記入貸方賬戶這個說法，那麼什麼是賬戶呢？賬戶就是一種資料。做生意的時候，我們要談到訂單處理，那麼什麼是訂單呢？它也是一種資料。我們描述it業務程式的時候，經常用名詞來指代某種資料，是以，在對應用程式進行業務層面的描述時，我們所談論的基本上就是該程式要對資料執行哪些任務。正因為如此，是以我們才要在做情境設計的時候，對資料有所了解。但同時，我們又不想在情境設計之中摻入太多與資料庫模式有關的細節，因為在思考情境設計的時候，我們可能還不确定自己到底需要多少個資料庫。

在做情境設計的時候，筆者用資料表（data table）來指代一組資料對象（data object），這種資料對象，用來存放與賬戶、産品或客戶有關的資料。資料對象的結構此時還沒有确定下來，我們隻是知道應用程式會用到這份資料，于是，就先給它起個名字，并指出建立、讀取、更新或删除該資料的那些任務，僅此而已。隻有當我們為了給任務制定規則，而必須使用資料的某個屬性時，我們才會給表格中的資料對象定義這個屬性。等到以後定義資料庫模式時，我們不僅要給資料表指定某些屬性，而且可能還要把情境設計階段之中的資料表，分割成很多個資料庫表格。

2.2.4　任務之間的消息

任務之間除了會共享資料，還有可能傳遞消息。

筆者發現，在情境設計階段，很少有人去指定任務之間的消息傳遞情況，因為這通常是實作層面的問題。在實作階段，我們可能會通過網絡來調用某項服務（也就是某段應用程式代碼），而這種實作細節，不需要出現在功能描述之中（情境設計也是一種功能描述）。

還有一個原因在于：如果某任務需要向其他任務傳遞資料，那麼更好的設計方案，應該是把這份資料放到資料表裡面。假如用消息去發送資料，那就需要針對資料的提供者和消費者，分别去制定相關的任務。而且我們通常還發現，同一份資料可能有多個消費者要使用，是以，還是把它放在資料表裡面比較好。這樣做使得消費者能夠以一種與提供者不同的順序來讀取這些資料。

實際工作中所遇到的消息發送或消息接收，基本上都是為了和情境設計之外的其他應用程式傳遞消息。然而有的時候，也可以考慮在同一個程式内部傳遞消息，例如，我們可以給某個任務發送一條警示消息，以便告訴其使用者，系統之中發生了一件重要的事情。

請注意：某些任務可能完全是由輸入的消息來驅動的，這些用來處理消息的任務，可能并沒有相應的使用者。批處理任務也是如此，有些任務會在每天、每晚、每周、每月或每年的固定時間執行，如銀行賬戶産生利息，就屬于一種批次任務。

2.2.5　任務之間的依賴關系

任務這種形式，能夠很好地把程式所要做的事情指定出來，但它們并不能完全孤立地運作。為了對情境設計的完備性和一緻性進行分析，我們需要把握住其中的各項任務，而要想把握住這些任務，則必須了解它們之間的依賴關系。

在用任務來實作業務流程中的活動時，我們可能就會遇到任務之間的依賴關系問題。流程，談的是多項活動之間怎樣協作，換句話說，流程會産生結果。之是以要對流程進行分析，就是為了了解這種結果是如何産生的。例如，為了報帳費用，某人會提出報帳申請，這算是一項活動，然後，會有人來審批這個申請，這算是另外一項活動，此外，還會有一個自動運作的活動，該活動有可能每個月會支付一次報帳的費用。這個例子之中的三項活動，是按照簡單的先後順序來執行的，整個流程的輸出結果，就是對報帳費用的支付。如果經理認為某筆費用應該由别的組來報帳，那麼他會把報帳申請轉給另外一位經理去審批。在這種情況下，整個流程就不再像原來那麼簡單了，因為它現在并不是由三個按照先後順序發生的活動所組成的，若是另外那位經理反對報帳，那麼流程還會更加複雜。一般來說，如果一切照常，那麼整個流程之中的各項活動，會按照簡單的先後順序來執行，但如果需要傳回早前的活動以解決某些問題，那麼這些活動就會形成一個複雜的網絡。在繪制任務層面的視圖時，應該把任務之間的資料分享及消息傳遞情況畫出來，這通常有助于我們更好地了解該流程。

任務之間的依賴關系不僅僅是流程而引發的。如果需要配置設定資源（如要指定送貨用的車輛），那麼也需要指定一系列任務，以處理車輛的指派、遞交、購買及維護等事宜，這些任務可以令車輛的狀态變為可用或不可用。有很多任務都是因為要管理同一種資源，而産生了依賴關系。

在上面這兩個例子中，各項任務因為流程或資源的配置設定而發生了依賴，這種任務之間的依賴，通常可以轉化為對資料表的依賴。例如，可以通過表示訂單的那個資料對象，來得知該訂單在處理流程之中的進度；也可以通過表示貨車的那個資料對象，來得知該車輛目前所處的狀态。于是，這就促使我們思考一個問題：怎樣才能確定資料庫所描述的狀态，與該資源的實際狀态相符？為了回答此問題，我們必須要考慮與資源發生互動的人員，以及互動的地點和時機，同時還要想一想，如果資源的真實狀态與資料庫所記錄的狀态不符，那麼會發生什麼現象。

有些資料并不是用來管理流程或資源的，這些資料本身自成一體，而且會在多項任務之間共用。例如，與産品有關的資料，就會在下單、制造、存儲、銷售、營銷以及計費等多個任務之間使用。

2.2.6　把所有元素統合起來

在一家規模中等的企業裡面，可能有上百種不同的任務需要執行，是以，我們應該對其分組。筆者把這種分組稱為共同目标群（common purpose group）。我們當然希望某個目标群内的任務，盡可能不要與其他目标群内的任務之間發生依賴關系，但實際上，還是有可能出現這樣的情況。本書第6章會讨論這個問題。

業務功能是由下列5個方面來描述的：

任務。

使用者組。

資料表。

任務之間的消息。

任務之間的依賴。

其中的前三項元素，畫在了圖2-4之中。

圖中最上面那一行，畫的是使用者組。（請記住，同一個人有可能屬于多個使用者組。）

中間那一行畫的是各項任務，這些任務都帶有描述文本。我們會在第6章詳細講解任務。筆者并沒有把消息發送情況繪制出來，如果任務之間要發送消息，用一個箭頭來表示就可以了。

最下面那一行畫的是資料表，不是資料庫。

如果有必要，我們應該用單獨的圖表來繪制依賴關系，例如，繪制同一個業務流程中的各項任務之間所形成的依賴關系。這些依賴關系，都應該用文檔記錄下來，以便我們了解對設計進行修改所引發的後果，此外，我們在分析情境設計的時候，也會用到這些資訊。筆者喜歡把每種依賴關系都至少繪制在一張圖表裡面，因為我要根據這些圖表來進行審閱。

https://yqfile.alicdn.com/1c7ac2b33246eb18558d8ae8bb43afa59029b343.png" >

此外，我們還可以用表格來記錄依賴關系，這種表格的各列與各行，寫有相應的任務名稱，如果兩項任務之間有依賴關系，那我們就在行列交彙處的單元格裡打勾，若能用字母來标出這條依賴關系的性質，那就更好了。此外，任務與資料表的依賴關系，以及任務與使用者組的依賴關系，同樣可以用表格來表示。表格便于查詢，但對于評審來說，則不太友善。用圖來進行評審，會更加便捷一些。

請注意，我們通過流程圖等圖表，在任務之間所找尋到的絕大多數依賴關系，最後都可以化為任務與資料之間的依賴，或是化為任務之間所傳遞的消息。是以，對于實作者來說，這些屬于可以知道的資訊，而不是必須知道的資訊。

你可能覺得把這些任務确定下來，是一件很簡單的事情，而且你可能認為業務經理應該已經把這件事做好了。沒錯，有些情況下，任務确實是顯而易見的，而且有些任務簡單到根本沒必要畫圖表示。但是，在另外一些情況下，任務則沒有那麼簡單。例如，即便是像圖2-4這樣看上去相當直覺的圖，也依然會引發一些問題。例如：

揀貨與打包是合起來算作一項任務，還是分開算作兩項任務？

揀貨員如果發現産品缺貨，那麼應該怎麼辦？我們還需要一項任務，使得應用程式能夠把這一情況回報給客戶。

如果未能完成投遞，那應該怎麼辦？

早前我們也說過，如果流程之中發生了錯誤，那麼情況就會變得複雜起來。

2.2.7　對情境設計做分析

我們可以就情境設計方案提出下列問題：

對于每張資料表來說，有沒有哪些任務會在表格中建立資料？有沒有哪些任務會使用其中的資料？有沒有哪些任務會删除其中的資料？

如果某份資料用于追蹤現實世界中的實體（例如，某份資料是用來表示顧客的），那麼該資料準确嗎？若是現實發生了變化（例如，客戶修改了名稱或位址），那麼會怎樣？如果資料不準确，會不會帶來什麼問題？

每項任務是否都擁有完成其工作所需的資訊？

任務與資料是否能很好地支援業務流程？例如，在處理訂單的過程中，有一條規則：發票是針對投遞給客戶的産品而開具的，不是針對客戶所下訂單之中的産品而開具的。我們在做分析的時候，要看看這條規則是否得到了遵守。

it應用程式若發生故障，會對業務流程造成什麼影響？

使用者是否承擔了過多的資料收集工作？

如果有人看到這些資料，那麼會不會産生安全方面（甚至是法律方面）的影響？

從這些問題裡面，我們可以發現，情境設計是可以進行分析的，這進而意味着，我們可以通過這種分析，來為工程化的設計提供支援。這種分析并不是單純地進行計算，它更多地是對資料流與依賴關系進行研究。即便隻做簡單的分析，也依然可以幫你避免犯一些代價很高的錯誤。

有些公司并沒有對情境設計之類的方案做分析，但它們似乎運作得還不錯，你應該見過這種公司吧？既然如此，那筆者為什麼還要強調分析的重要性呢？實際上，就我自身的經曆來看，幾乎沒有哪個公司在研發情境模型的時候會做通透的分析。這樣它們為了實作某些業務功能，就會把情境設計做成許多散布在模糊海洋之中的小島，并且要艱難地維護其一緻性，于是，公司隻能靠手工的流程與猜測，來把這些小島粘連起來。正因為如此，是以：

我們不得不給同一個公司反複發送同一份資料。

兩位乘客會買到寫有同一個座位号的機票。

某些公司會把已經停産的産品賣給你。

某個公共事業公司會把鄰家的賬單一直往我女兒家寄，直到明白這個錯誤之後才停止。

早前我們說過，有計劃的設計與工程化的設計相比，其中一項缺陷就是設計者會因為怕失敗而陷入過度設計的境地，這對于it應用程式來說也是如此。由于應用程式沒辦法保證資料庫裡的資訊一定準确，是以它必須再次檢查資料，或是強迫使用者必須再輸入一遍。此外，由于應用程式并不知道有誰會需要資料，是以它會把資料發給每一個人。在大多數情況下，這并不會造成人身傷害，頂多就是效率低一些罷了，可我們最好還是不要做出這樣的設計來。