最近看了一本書《群體智慧驅動的需求工程》。
個人覺得這本書雖然學術性比較強，但是可以嘗試在實際項目中使用其中的一些方法，特別是多個業務干系人的情況下，這種方法有利于幫助理清用戶想要什么。
在需求捕獲的時候，我們通常的做法是逐一進行調研訪談。
我們會在對這個用戶訪談的時候將設計好的問題都交流完成，再對另外一個用戶進行訪談。
每次訪談會涉及到很多的故事，而有比較大風險的是，我們并不確定是否有所遺漏，或者對方說的就是他們真實的業務場景。
不要懷疑，一般來說，用戶會把他們認為正確的講述給我們聽，而他們目前是否真的按照“程序”執行？你通過一次訪談很難知道。
更別說，如果發現兩個用戶在描述同一個場景不一致的情況，還可能會需要額外的時間和精力去研究去設計。
換句話說，我們通常的做法不是針對業務故事、業務場景，而是針對用戶，針對人的。
從這個用戶這里獲取到“足夠”的信息，再轉換到下一個用戶。
而群體智慧驅動的需求工程是從另外一個角度來進行需求獲取的。
它是針對一個主題進行故事講述和需求獲取。
這樣就有效避免了故事的遺漏和故事的矛盾情況的發生。
具體的實施方法并不復雜，我簡單介紹一下。
第一步：群組講故事
由主持人組織講故事者和業務建模師一起參加，用來捕捉知識、期望和經歷。
講故事者主要由客戶、用戶或者是領域專家構成。
這項活動的輸出是文本型的故事。
第二步：創建抽象
大家一起來理解上一步得到的故事，并進行標注：這個故事中有哪些參與者，有什么事件被提及，是否有什么外部的資源（比如文檔）參與了這個故事……
然后將這些標注出來的元素進行抽取，并且構建敘事網絡模型。
最終這個步驟輸出的是業務過程元素（也就是你標注出來的元素）和敘事網絡模型。
第三步：構建規范化陳述
這個步驟主要由業務建模師，也就是BA主導，通過上一步得到的輸出創建需求的規范化描述，比如UML等業務過程模型。
貫穿步驟：對話游戲
貫穿在每個步驟中間的還有一個：對話游戲。
對話游戲主要用于在每個步驟結束前各個角色通過對話的方式對規則、信息等進行澄清、精化。
比如，在第一步中，BA發現用戶在講故事中提到了一種業務場景，但是沒有描述清楚該場景會在什么時候發生，于是可以在對話游戲中提出問題。
這個時候，講故事者將提供更精確的信息以補充并澄清這個故事的相關元素。
甚至說，由于兩個不同的講故事者的角色不同，關注點不同，講述了兩個邏輯相悖的故事，那么這個時候BA也可以提出問題。
從我的角度看來，這本書介紹的這個方法也有局限性。
比較難組織
所有的人要在同一個地方，面對面的對話才能獲取比較好的效果。
雖然書上說可以通過Wiki來解決地域差異的問題，但是我始終覺得面對面的溝通是最好的方式。
就算大家可以在同一個地點，你還需要找出大家都有空的半天甚至一整天的時間。
經歷過需求討論的小伙伴都知道，如果同時訪談或者討論的人多了的話，時長會成倍增加，效果也不大好。
所以，人數、地點、時間是組織上的困難。
記錄和整理量很大
你需要記錄下來故事講述者的所有故事。
人的語速是很快的，但并不是所有的講述信息都是有用的。
如果你在記錄的同時還要識別哪些是有效，那肯定記不全。
但是如果不識別，那肯定來不及記。
為了下一步的抽象做準備，你還需要對記錄下來的信息進行整理。
記錄和整理的工作量非常大。
抽象難度比較大
并不是每個人講話都是符合標準規范語法的，畢竟每個人說話方式不一樣。
有些人講故事的時候是這樣說的：首先XXX會去填一個申請單，然后交給直屬領導審批，如果領導同意了接著給人事會簽。
但是有的人不這么說，他會說：XXX填張單子給領導，領導批了交人事。
像后面這樣的描述是非結構化的，你在抽象的時候會花比較大的力氣。
我的一些設想
現在隨著語音識別技術和數據分析技術的發展，我在想是不是有這樣一種可能：
我們用語音識別軟件將講故事的過程錄制并識別，然后運用工具和定義好的一些算法規則來完成元素抽象的工作。
利用機器來完成抽象的工作，這樣可能會有一些我們自己沒有注意到的信息被挖掘出來。
目前我們可以嘗試的
我建議大家可以根據自己項目和產品的實際情況來嘗試一下剛才提到一兩個步驟。
比如在多干系人的情況下，使用群體講故事，嘗試挖掘所有的業務場景。
比如嘗試結構化的需求編寫方式，看看會不會對現有的工作有什么改進。
這些都是我們可以去嘗試的內容。
或者你有些其他新的想法？
歡迎留言討論。
小婧是一名行走在實踐路上的資深業務分析師（BA），如果想與我同行，就請關注我吧！
