摘要:當(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ā)有限公司。