軟件需求管理一大工具

摘要：當前傳統瀑布式項目管理方法中的需求管理模式針對軟件類項目存在著一定的弊端導致項目失敗的風險增大。如何利用用戶故事地圖的方法來有效的避免傳統需求管理中的疏漏，對用戶故事地圖進行了簡介，總結了用戶故事地圖的優勢以及關鍵點。

關鍵詞：用戶故事地圖;需求管理

引言

通常在一個瀑布模型的項目管理過程中，會產生如（圖1）所述的項目工作流。在項目運行初期，用戶會面臨一個問題，他們只會參與到撰寫需求以及最終測試的這兩個階段中。但是在需求文檔制作完成之后直到最后的測試階段之前，用戶一般不會了解整個項目的運作情況和實施進度。無疑這將會在軟件開發工程項目中增加了項目（如用戶需求的演進變更史，項目經理的統籌協調，開發工作者對用戶需求的實際理解程度不一等等）不成功的風險。

而在設計思維一整套方法論體系中，利用用戶故事地圖工具能較大程度優化項目進展階段中碰到的問題，規避安全隱患，加強協作體系中可靠性，從而顯著提升各工作環節的進度及完成質量。

什么是用戶故事？

用戶故事地圖是設計思維的其中一個實用工具。在20世紀90年代末，Kent Beck先生在開發軟件的過程中發現，最大的困擾就是如何使用文檔來精確的記錄客戶想要的東西。傳統行業中有很多人采取在需求文檔上各自簽字的方式來證明互相已經達成了共識，然而同樣一份文檔，閱讀的人不同，各自得到的信息可能并不一致。

心理學家Jerome Bruner發現，用講故事的方式來陳述事實，給人留下的印象在深刻程度上高出單獨陳述事實的22倍。用戶故事的核心思想即是用一種非正式的文檔記錄方式，最自然易懂的語言來描述實際想要實現的功能或要求。以客戶或者用戶的觀點撰寫下有價值的功能和框架等來幫助項目中不同各方對需求更好的理解。在這個基礎上，可以更好的利用用戶故事地圖對項目進行評估籌算，制定發布計劃，最終推動整個項目順利交付。

用戶故事的三個關鍵點：

卡片（Card）

用戶在一堆card上寫下對產品的期望功能和特性。card上的內容只需要讓多數人一看即懂得描述的是什么（也就是自然語言而非技術性語言），易于識別需求。還可以備注一些該card所需要消耗的人力，優先級，項目成本等信息。

對話（Conversation）

用戶故事的重點就是從文檔轉移到對話形的溝通。盡量聚集開發團隊和用戶一起對需要的產品進行深入討論。多交流不同的觀點、想法和感受。在對話的過程中，說的人和聽的人通過反反復復的提問以及回答來修正對事情的理解，從而最終達成一致。

確認（Confirmation）

對驗收條件進行分段確認。發布計劃時包含了每一階段的驗收測試的標準，當故事被開發完成時，程序開發團隊向客戶按照驗收標準進行產品功能展示或按場景進行系統試運行來確認用戶所提出的需求。在完成工作成果并按階段完成客戶的需求后方能開展并執行下一階段故事的開發工作，其中確認環節是生命周期不斷循環的關鍵。

創建用戶故事地圖的方法

在創建用戶故事地圖之前，首先必須確定項目的最終目標。采取最簡單的填空的方法組織成盡量簡單的一段話。這樣可以更好的幫助清晰的認識目標，量化目標結果的實際價值以及達成目標前所需的準備工作。我們把這句話稱之為“問題零”，是設計思維方法論體系中的一部分。這句話可以涵蓋以下問題，但并不要求每一項都要囊括進去。

-是什么？比如做一個App？網站？還是小程序等等;

-為了什么？解決什么問題？比如供應鏈管理，客戶關系管理等等;

-在哪里？

-誰？對象是讀者？學生等等;

-用什么方法？例如Java？或者Phython等等;

接下來，為了明確需求，我們正式開始創建用戶故事地圖。

1.聚集具備項目背景技能或行業背景相關的不同崗位的人員，帶著“問題零”讓大家圍繞之進行頭腦風暴;

2.對目標用戶進行用戶特征的歸納以及歸類，討論設定用戶畫像;

3.用卡片記錄下零散的可以想到的不同用戶需要執行的不同任務，通俗說法就是用戶需要執行的操作或者動作;

4.接著就是對所有碎片的任務卡片進行分類匯總，然后給每一組命名;

5.然后對分好組的卡片以組為單位按照動作執行的先后順序排序（當然其中可能存在平行時間執行的任務）;

6.對于整理完的所有任務進行一個整體的回顧，以故事敘述的形式來檢查是否存在疏漏，并對發現的疏漏或者矛盾處進行補充修改;

7.最后綜合討論每一個任務開發所需要完成的單位時間，這個過程需要取得項目中不同參與人員的一致認同或綜合平均，并不一定要做到精準。

至此，一個完整的用戶故事一句完成了。并可以以此為依據結合討論各個任務的優先級，開始定制項目的發布計劃，此時可以用到甘特圖來制作發布計劃。

某公司的信息部門準備為全球的IT相關內部人員建立一套全新的知識管理系統KMS。項目經理決定用設計思維的思路，基于注重用戶體驗的原則，采用用戶故事地圖的方法來搜集用戶的真正需求。

首先，項目團隊內部定義了“問題零”。項目的目的是創建一個知識分享平臺解決公司內部各信息部門間信息不對等，傳遞速度慢的問題。使得所有信息工作者可以更快的在平臺內找到最準確的信息幫助其工作。

項目團隊召集了信息部門代表不同role的關鍵用戶代表，召開了一場頭腦風暴，所有與會者從自身出發列出平時工作中需要KMS幫助到他的內容，并寫在了便簽紙上。這些人包括技術支持人員，開發人員（非本項目組），內部宣傳人員，IT管理人員，其他利用信息知識的項目管理人員，以及此項目組的相關人員等。很快就得到了滿墻的小便簽。

然而此時得到的所有標簽都是零散的。比如IT服務熱線的一線接線員希望搜索關鍵字就出現按照熱門程度排序的解決方案。而內部產品管理團隊希望可以在知識庫內容有更新的時候無效的信息自動下架。服務器維護團隊則希望可以把第一手的故障信息以及影響的范圍發布到可以讓所有內部IT人員馬上看到的平臺上。整個團隊不斷對這些零散需求的歸類，得到一張任務組的清單，以及一些特定用戶的形象描述。

統計匯總出來的任務組也包括發布內容，共享內容，評論內容，搜索內容，推送內容。需要注意，此時的需求并沒有講到我們需要怎么樣的數據結構來建立數據庫這類更專業性的需求描述，而是更商業化的需求描述語言。

接下來，團隊模擬三個典型性用戶使用KMS的過程，回顧他們作為用戶對該系統的每個touch point，看看是否有遺漏的內容或者去掉不是特別必要的card。到這個階段，用戶故事差不多已經說完了。

在可以制定發布項目計劃前，項目組還需要對完成這些card功能開發的工作量來進行估算。參與到估算討論的有項目開發人員，項目管理人員以及關鍵用戶。每個card的估算工作量都需要得到與會者的一致認同。比如對同一個動作需要的開發，有的人可能會覺得要測試這個，我們需要建一個模擬庫對象需要1天，而且還不確定標準算法是否能用，可能需要重編一個占用內存更少的算法。這樣就需要花更多的時間。而同時另一個人認為我只需要把信息存在一個XML文件中，就比數據庫簡單許多。這兩個人的估算值肯定不會一致。如果存在疑議，大家把自己的理解說出來之后進行簡短的討論，一般在進行過2輪討論后都會達成一致的估值。

自此，我們已經對需要完成所有的任務需要花費多少的人天有了一個大概的概念，項目經理便可以在根據這個估值以及各個功能的優先級來編輯發布計劃。

簡單而言，用戶故事地圖就是把設定的目標拆分成可執行的動作，經過歸類之后形成任務組，再經過排序做成故事的一個過程。

在項目進行的過程中，card優先級可以在每一輪迭代開始前重新排序，并可以隨著項目的進行增加新的或者去除不再有意義的一些card。也可以對完成開發每個任務所需要花費的時間以及人力成本估算進行調整。用戶故事不是一個一旦定下便很難做修改的需求定義書。制作用戶故事地圖時需要注意以下幾個問題：

-盡量使用更為實踐性質的商業語言而不是技術語言，避免編寫出針對開發人員更有價值的用戶故事;

-盡量避免分散的故事與故事之間相互關聯，如必要，就嘗試合并相互關聯的故事，或者換一個角度去拆分故事從而切斷依賴;

-零散太小的故事可以合并不分類;

-盡量避免過早涉及對用戶界面的描述;

-需要針對card編寫測試從而確保系統沒有違反約束，由于代碼變化很快，盡量做到自動化測試率大于99%從而增加測試效率。

利用用戶故事地圖的優勢

用戶故事地圖被用在項目準備階段，用來更好的幫助項目團隊梳理零碎細散的用戶需求，方便看到一個概況。從而可以便于篩選和制定不同任務的優先級，幫助項目經理做出決策，框定整體項目范圍。其中很重要的一點，在制作用戶故事地圖的過程中，可以更好的幫助項目團隊中處于不同角色的成員都對項目的整體需求和概況有一個一致的理解。

創建用戶故事地圖的目標很簡單，搞清楚用戶到底是誰，他們要達成什么樣的目標，如何達成目標。

相較于傳統的需求管理，使用用戶故事的項目會有不同的感覺和節奏。不使用傳統需求文檔而是通過用戶故事card來整理的一個很大的特點就是客戶需要參與項目的整個過程。需求文檔的語言存在不準確性，不同角色的人閱讀同一篇需求文檔會產生不同程度理解上的偏差，導致真正的需求極易被誤解。而故事驅動的需求管理能很好的避免不同項目參與者對需求理解的偏差，大家對需求的認識都在統一戰線上。

另外由于用戶故事的靈活性隨著項目的開展是很容易添加或者刪去某一些內容的，也就是當開發團隊把軟件的早期版本展現到用戶面前的時候，用戶其實會對自己所需要點產品有新的認識并產生新的想法。這種變化在軟件項目中非常常見，而且利用傳統需求管理模式應對這些變化來說顯得有些吃力。

利用用戶故事管理需求還有一個特點，那就是下決策的時間。相較于傳統需求管理，利用用戶故事地圖的方法，決策不在項目的初始階段，而是分散在整個項目過程中離散的狀態。傳統需求管理文檔一旦簽訂拿到雙方的認可后便根據其下決策了。然而故事驅動的方法并不具有契約的性質，最終達成的協議是以結果為導向，以測試結果為準。

簡單對比利用用戶故事地圖來獲取需求的方法和傳統需求文檔管理的區別如表1。

結語

由于用戶故事本身并不具有契約性質，使得其在項目中運用起來更為靈活，在針對軟件類型的項目中可以很好的應對多變的需求從而對項目計劃進行調整。若結合敏捷迭代的管理后更容易在每個迭代間在初始用戶故事基礎上更多的與客戶對話從而細化明確化最終的需求，避免越走越偏最終導致項目失敗。

參考文獻：

[1] Jeff Patton. 用戶故事地圖 []. 清華大學出版社，2016.

[2] Mike Cohn. 用戶故事與敏捷方法. 清華大學出版社，2010.

[3] Michael G. Luchs. Design Thinking New Product Development Essentials from the PDMA. 電子工業出版社，2018.

[4]Karl Wiegers， Joy Beatty. 軟件需求（第3版）. 清華大學出版社，2016.

[5]李俊煒. 軟件開發中的需求分析及變更管理研究，無線互聯科技，2017（5）.

作者簡介：

周盛（1988年1月—），籍貫：江蘇如皋，職稱：無，性別：女，民族：漢，學歷：本科，研究方向：IT項目管理，工作單位：上海藥明康德新藥開發有限公司。