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

關(guān)鍵詞：用戶故事地圖;需求管理

引言

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

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

什么是用戶故事？

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

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

用戶故事的三個關(guān)鍵點：

卡片（Card）

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

對話（Conversation）

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

確認（Confirmation）

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

創(chuàng)建用戶故事地圖的方法

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

-是什么？比如做一個App？網(wǎng)站？還是小程序等等;

-為了什么？解決什么問題？比如供應(yīng)鏈管理，客戶關(guān)系管理等等;

-在哪里？

-誰？對象是讀者？學(xué)生等等;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

統(tǒng)計匯總出來的任務(wù)組也包括發(fā)布內(nèi)容，共享內(nèi)容，評論內(nèi)容，搜索內(nèi)容，推送內(nèi)容。需要注意，此時的需求并沒有講到我們需要怎么樣的數(shù)據(jù)結(jié)構(gòu)來建立數(shù)據(jù)庫這類更專業(yè)性的需求描述，而是更商業(yè)化的需求描述語言。

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

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

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

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

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

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

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

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

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

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

利用用戶故事地圖的優(yōu)勢

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

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

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

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

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

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

結(jié)語

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

參考文獻：

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

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

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

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

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

作者簡介：

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