又見樹木，又見森林——需求設計
之前說到最近在看幾本書，基本上都是用來解決「只見樹木，不見森林」的問題的。
今天和大家分享第二本《需求設計》。如果說《用戶故事地圖》可以解決大部分PO以及BA在需求分析時可以「又見樹木，又見森林」的話，《需求設計》其實主要是寫給BA和SA的。如果運用得當的話，我們可以使用用戶故事地圖來進行需求的收集和整理，用需求設計提到的情境驅動設計來進行構思和設計。之前我曾經接觸過一些設計師，非軟體的。
大家知道汽車或者飛機是怎麼設計出來的嗎？
一般來說，客戶方會給出需求，比如我要求車子要能運送1噸以內的貨物，滿載時車子的速度可以達到80碼，油氣混合動力，其他滿足國家標準……接下來會由總體設計師對其需求進行分析，也就是進行指標的分解。比如，要能運送1噸以內的貨物，可能會對車體設計、動力設計等都有相應的需求。而整個設計部門會按照功能進行劃分，會有車體結構設計部門，動力設計部門，電子設備設計部門。一條客戶需求可能會涉及到多個設計部門，同樣的多個需求可能會對同一個設計部門的一個指標有影響。
比如，結構設計部門發現如果要載重1噸的貨物，必須要有一定的強度支撐，這會增加車身重量。但是，增加的車身重量就會影響到車速。紛繁複雜，理不清。曾幾何時，各個設計部門也是各自為政，只關心自己的指標，不考慮對其他設計的影響。
最終在物理機外場聯試聯調的時候就會出現各種各樣的問題，造成非常大的損失。
嗯，你可以想像一下，一架飛機在進入風洞實驗的時候，才發現問題。。。。這個損失後面大概有幾個零？我是數不清楚的……這都是因為「只見樹木，不見森林」導致的。
而隨著技術的發展和觀唸的更新，在工程設計過程中，會採取總體牽頭先進行需求的分析和設計，再由各個設計部門去進行設計。並且因為計算機技術的發展，越來越多的測試和調試不是實物的，不是物理機的調試了，而是採用大量的模擬、模擬手段進行測試。保證在早期將大量的問題消除，避免不可挽回的數不清的零的損失。《需求設計》提出的我們的軟體設計可以借鑒工程設計的部分。
作者提出了六框設計模型。
而與我們今天想要解決問題關係比較密切的是第一層，情境設計。
回憶一下前文，汽車的需求時怎麼提出的呢？
用戶提需求的時候大部分是情境化的。在這種情況下，我們是怎麼處理的。在那種情況下，我們有怎樣的流程。對了，我們還有一些特殊的情況。對於如此多的紛繁複雜的信息，在進行需求的分析的時候難免會迷失方向。
我們需要避免幾個常見的問題，需求的遺失以及需求的衝突。需求的遺失
需求的遺失，往往因為我們在進行需求收集的時候，自我假設了一番：
- 用戶一定會將所有的需求非常明確的告訴我。
- 用戶說的東西是一致的不存在矛盾的。
- 我能夠聯繫到所有的幹係人，並且獲得信息。
- 最終我設計的方案會由客戶方進行評審，並且對於其中的問題，他們都能明確的指出。
呵呵噠……
我相信做過年把的BA不會如此單純了，因為這些假設而產生的坑和鍋多的數都數不清了。曾經在UAT的時候，用戶說，不對啊，我們還有這樣的場景……你們這樣交付，我們沒辦法簽字的。
你會很委屈，因為你覺得客戶之前調研的時候根本沒有提過這樣的需求。而整個團隊可能都會責怪你，責怪你沒有「認真」的收集並和客戶做確認。這是收集和確認的問題嗎？
很多情況下，並不是。需求的遺漏，有可能是你沒有做需求驗證導致的。
前兩天我在BABOK中分享了關於Requirement Validation的相關內容。其實需求驗證也是提前對需求進行測試的工作，保證需求的完整性。那具體怎麼進行需求驗證呢？
《需求設計》的作者提出了一個方法，就是情境設計。
通過對任務、用戶組、數據表以及任務間消息的設計，來減少需求驗證。任務
首先，可以通過情境分析出涉及到的任務，最好是能拆分到原子任務。
對於BA來說，你可以將任務理解為活動。但是對於SA來說，任務可能或者說，應該是比活動更細的元素。比如，在地上挖洞，這是BA眼中的任務。而SA會將其拆分成領隊者命令團隊開始挖洞，以及挖洞結束兩個任務。請BA細細品味一下這兩者的不同。這也是BA和SA在思維上不同的地方。用戶組
對於用戶組，我們需要進行界定。
這個比較簡單，我們在繪製泳道圖或者用例圖的時候，本就會涉及到用戶組的識別。而其實我們之前在識別任務的時候就可以識別出相關的用戶組了。並且將哪些用戶歸在一組，很大程度上與任務相關。一般情況下，我們會把執行同類型的任務，甚至是相同任務的用戶歸在一個用戶組裡面。數據表
我不知道有多少BA在設計的過程中會考慮數據表的問題。
但是SA或者DBA肯定會考慮這個問題。作為BA需要清楚的是，你這個任務中使用到的對象屬性，可能會在其他什麼任務中使用到。是否有數據之間的傳遞等等。業務設計資料庫不是你的職責，但是你有責任清晰的表明數據的關係。任務之間的消息
在BA理解，任務之間的關係無非是一個用戶在執行一個觸發了什麼機關，導致了另外的一個任務的變化。
而對於SA來說，範圍要廣的多。在我粗略的閱讀了Activitii的相關書籍後，發現單就工作流來說，消息是無處不在的。但是無一例外，消息的產生都是基於情境的。即在一種什麼樣的情況下會由誰發消息給誰，產生什麼結果。說到這裡，我們可以知道，基於情境進行需求設計，主要是將任務、用戶組、數據表、任務之間的消息這4個元素進行相互驗證，以保證需求的完整性，減少遺漏。
如果我們在需求分析和設計的初期就這麼去做，能夠識別出相當多之前遺漏的部分。如果有機會大家可以嘗試一下。矛盾的需求
有兩種情況可能會有需求矛盾的狀況。
同一個用戶，他在描述一個流程的時候，使用規則A，比如快遞敲門的時候，要在關閉水龍頭之後，才能去開門。而當他在描述另外一個流程的時候，可能時隔數月，使用規則B，比如女朋友敲門的時候，要先去開門，再去關閉水龍頭。
如果你簡單的設計為先關水龍頭再開門，或者先開門再關水龍頭，都不妥當。此時你需要做的應該是分析這兩種情境，找出矛盾點和解決方案選項。不同的用戶，他們在描述同一個流程的時候，有矛盾。
這個可以理解，因為每個人的角色不同，看待一件事情的角度也就不一樣，很可能會有矛盾的規則出現。此時，你必然需要找出產生這樣問題的原因，並且根據項目或者產品的目標進行引導，以達成一致。OK，問題來了。
我們怎麼發現需求是矛盾呢？如果需求是一份清單，或者是一個長長的Backlog，必然很難發現。
而如果使用情境設計中的四個元素是很容易分析出來的。我們在識別出任務後，對用戶組以及任務間的消息分析可以很快得出，因為參與的用戶組不同，而導致了任務間的消息觸發機制不同。
這其實也相應的可以識別出備選的解決方案。全局性
而我們在提到「只見樹木，不見森林」的時候，不得不提到需求的全局性的問題。
在工程設計中，有個部門叫做「總體部」，主要職責是統籌各個專業設計部門對於需求的分析、設計和實現、測試。
他們會接收到來自於客戶的情景化的需求，進行分析和總體設計後，將需求拆分成為各個設計指標，下發給各個專業設計部門。比如，結構設計部門，你這邊強度要求是多少多少。動力設計部門，你這邊要求要支持多少多少。很顯然，總體在分析這些需求的時候，會從全局上看，因為有些指標是相互牽制的。比如，你強度要是很大，那麼可能自重會很重，對動力的要求也會高。借鑒這樣的想法，在使用情境設計的時候，也需要考慮這樣的全局性。
在進行需求分析及設計的時候，一定要時不時的退後一步，看一下四層的關係，全局的目標。以保證不會偏離航線。《需求設計》這本書，我會推薦給偏向後臺設計的BA閱讀。
特別是抱怨和程序猿溝通不能的BA進行閱讀。我也不止一次的被程序猿提醒：「你這樣的方案和客戶對接，當然沒問題。但是我們在設計的過程中需要考慮更多的細節。」我們如果可以在需求分析和設計的前期，通過情境設計的方式，對需求進行驗證，進而保證解決方案的整體效果，是解決「只見樹木，不見森林」的方法之一。小婧是一名行走在實踐路上的資深業務分析師（BA），如果想與我同行，就請關注我唄！
推薦閱讀：
