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