軟件需求管理一大工具

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

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

引言

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

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

什么是用戶故事？

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

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

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

卡片（Card）

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

對(duì)話（Conversation）

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

確認(rèn)（Confirmation）

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

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

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

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

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

-在哪里？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

創(chuàng)建用戶故事地圖的目標(biāo)很簡(jiǎn)單，搞清楚用戶到底是誰(shuí)，他們要達(dá)成什么樣的目標(biāo)，如何達(dá)成目標(biāo)。

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

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

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

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

結(jié)語(yǔ)

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

參考文獻(xiàn)：

[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）.

作者簡(jiǎn)介：

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