前言

tips：

好的團隊俺附，從關(guān)鍵業(yè)務(wù)指標(biāo)得到啟發(fā)，通過觀察用戶的痛點和分析用戶使用過程中產(chǎn)生的數(shù)據(jù)淀衣，不斷嘗試新技術(shù)解決現(xiàn)實問題。差的團隊召调，從銷售人員和用戶那里收集需求膨桥。

好的團隊蛮浑，理解誰是主要干系人，干系人所受的約束只嚣，承諾引入解決方案沮稚，方案對用戶和客戶有用，同時也滿足業(yè)務(wù)上的約束條件册舞。差的團隊蕴掏，只知道從干系人那里收集需求。

好的團隊调鲸，掌握大量的技術(shù)手段盛杰，這些技術(shù)手段可以快速驗證哪些產(chǎn)品創(chuàng)意是值得開發(fā)的。差的團隊藐石，召集會議來制定路標(biāo)和排列優(yōu)先級即供。

好的團隊，產(chǎn)品經(jīng)理于微、交互設(shè)計師和開發(fā)工程師坐在一起逗嫡，對功能、用戶體驗株依、技術(shù)可行性達成一致見解驱证。差的團隊，各自坐在小格子間里恋腕，沒有文檔和會議安排抹锄，就不會主動響應(yīng)其他人的請求。

好的團隊吗坚，保證開發(fā)工程師每天有時間參與產(chǎn)品原型的討論祈远，為做好產(chǎn)品獻計獻策。差的團隊商源，在迭代計劃會上展示原型车份，一心只為了估出工作量。

tips2

只有滿足顧客和用戶的需要牡彻，公司才能實現(xiàn)自己的訴求

第1~5章 用戶故事地圖概覽

用戶故事地圖：就是在講大故事的同時進行拆分

構(gòu)建故事地圖的最終目的：團隊成員需要能夠支出設(shè)計方案中的問題和改進點扫沼，并對需要投入多少開發(fā)時間進行估計

用戶故事地圖詳細說明

每一列頂層的卡片都是大故事。拆分的細節(jié)放在下方庄吼，在每個大故事上停一下缎除，然后提出以下問題：?

用戶在這一步具體要做什么事情？?

用戶在這一步還有其它選擇嗎总寻？?

如何才能使用戶覺得更酷炫器罐？?

出現(xiàn)問題了如何處理？?

tips:拆分大型輸出的秘密在于聚焦小的渐行、特定的成果轰坊。?

MVP：

1.MVP是為驗證假設(shè)而做的最小規(guī)模的實驗

2.MVP是指可以產(chǎn)生預(yù)期成果的最小產(chǎn)品發(fā)布

劃分MVP發(fā)布計劃

1.聚焦于成果铸董，即產(chǎn)品發(fā)布后用戶能使用和感知的東西，切分發(fā)布計劃應(yīng)該以成果為導(dǎo)向

2.聚焦于特定的目標(biāo)成果肴沫，這是排定開發(fā)工作優(yōu)先級的秘密

優(yōu)先級模型

差異化功能（顯著區(qū)分于其它競爭對手的功能）

攪局功能（針對競爭對手差異化功能）

降成本功能（降低組織運作成本的功能）

基礎(chǔ)功能（進入市場競爭所需的基礎(chǔ)功能）

需求驗證及原型設(shè)計

通過原型和用戶測試驗證產(chǎn)品方案是否真的有用粟害，有價值

下面兩點最重要：?

* 最大膽、風(fēng)險最大的假設(shè)是什么颤芬？哪些是最不確定的悲幅？?

* 為了消除假設(shè)或風(fēng)險，需要哪些真實的信息站蝠？?

估算與發(fā)布計劃

1.最靠譜的估算汰具，來自于真正理解自己在估算什么的工程師2.在開發(fā)過程中，我們也會對已經(jīng)投入的開發(fā)時間進行記錄沉衣，這個活動叫做度量郁副；度量越頻繁，估算會越接近實際值

用戶故事地圖三部分：

第一部分：跑通整個流程（團隊可以看到一個端到端可用的軟件豌习，通過加載數(shù)據(jù)來觀察軟件性能存谎，引入自動測試工具來檢驗穩(wěn)定性）

第二部分：團隊進一步對產(chǎn)品進行完善，使其接近可發(fā)布的標(biāo)準(zhǔn)肥隆，在這個過程中既荚，會學(xué)習(xí)到此前無法預(yù)計的許多東西，比如可能在原型階段忽視一些有用的特性栋艳，或者發(fā)現(xiàn)現(xiàn)有系統(tǒng)無法滿足性能上的需求而需要額外的投入來解決問題恰聘，這些稱為"可以預(yù)計的不可預(yù)計因素"

第三部分：打磨產(chǎn)品特性，使其接近完美吸占，這個階段也會加入此前沒有預(yù)計到的一些東西

管理研發(fā)預(yù)算

當(dāng)可能延期時的方法

* 項目外協(xié)調(diào)更多的人力

* 砍掉對用戶沒有明確收益的功能

* 在問題發(fā)生的時候想辦法改變用戶的預(yù)期

在拆分的過程中晴叨，團隊逐漸識別處可能導(dǎo)致預(yù)算管理失控功能的因素，這些因素就是風(fēng)險矾屯，整個團隊一起討論兼蕊，對識別風(fēng)險很有幫助

其它解決方案：在用戶故事地圖中加入風(fēng)險故事

迭代與增量

運用迭代的思持續(xù)評估和打磨作品，則意味著評估和改變

運用增量的思維做加法

開局中局與末局

開局

聚焦于必備功能或者用戶步驟件蚕，重點關(guān)注技術(shù)挑戰(zhàn)或風(fēng)險孙技，暫且跳過哦用戶主流程之外的步驟，也先不管可能導(dǎo)致問題復(fù)雜化的商業(yè)規(guī)則排作。所有開發(fā)只要滿足跑通主流程就好

中局

補充周邊功能牵啦，用戶主流程之外的可選流程一級復(fù)雜的商業(yè)規(guī)則。如果開局階段做得不錯妄痪，在中居可以開始測試產(chǎn)品的非功能需求哈雏，比如性能、可擴展性和可用性。這些更多是質(zhì)量方面的考量裳瘪，要認識到這些方面的工作并持續(xù)進行測試

末局

打磨發(fā)布履因，使其更搶眼，使用起來更高效盹愚。此時，已經(jīng)可以在生產(chǎn)環(huán)境使用真實數(shù)據(jù)站故，此時能識別出的改進點是原型階段無法識別出來的皆怕。同時，也可以從真實用戶那里聽取他們對產(chǎn)品的反饋西篓。

一旦確定第一個對用戶可行的發(fā)布愈腾，就和團隊成員一起把發(fā)布計劃分成開局、中局和末局岂津。

故事地圖六步法

1.厘清問題虱黄。用戶是誰，帶來什么價值吮成？

2.構(gòu)建全景圖橱乱。廣度有限，而非深度粱甫。嘗試用故事地圖描述所有內(nèi)容泳叠，包括用戶的痛苦和喜悅

3.探索。? 向深度拓展茶宵，討論其它類型的用戶危纫，這些人又要做什么？哪些環(huán)節(jié)會出現(xiàn)問題

4.指定發(fā)布策略? 過段砍掉無助于取悅用戶和幫助公司達成目標(biāo)最小方案的東西

5.制定學(xué)習(xí)策略? 幫助自己發(fā)現(xiàn)有哪些最大的風(fēng)險乌庶。為用戶群的子集切分更小的MVP實驗种蝶，不斷學(xué)習(xí)真正對用戶有價值的東西6.指定開發(fā)策略，在去掉所有不必要的東西之后瞒大，留下的就需要投入開發(fā)螃征。早期先聚焦于關(guān)鍵技術(shù)問題和開發(fā)風(fēng)險

第6-12章 深入理解用戶故事

簡介：用戶故事背后的故事、工作原理糠赦，如何在敏捷和精益項目中更好地使用用戶故事会傲。

最佳的解決方案來自于需要解決問題的人和有能力解決這些問題的人彼此協(xié)作

用戶故事模板：

作為【一個用戶】

我想要【某個產(chǎn)品特性】

這樣我就可以【獲得某種收益】

提升討論效果的檢查單：

1.討論用戶角色（who）

2.討論要做的功能（what）

不要忘記那些用戶關(guān)注這些功能以及要解決什么問題

3.討論為什么（why）

討論為什么特定的用戶會關(guān)注這些功能。多問幾個為什么拙泽，可以發(fā)現(xiàn)隱藏在背后的真正原因

4.討論軟件之外的東西

討論用戶會在何時何地使用產(chǎn)品淌山，使用的頻度如何，在使用過程匯總用戶身邊是否還有其它人

5.討論異常情況

肯呢個會出現(xiàn)哪些異常情況顾瞻？系統(tǒng)宕機會引發(fā)什么問題泼疑？用戶還有沒有其它完成任務(wù)的手段？

6.討論問題和假設(shè)

你會發(fā)現(xiàn)有許多未知的事情阻礙了討論的繼續(xù)進行荷荤，把這些問題識別出來退渗，討論它們的重要性

你真的了解用戶嗎移稳？這是用戶真正想要的嗎？這些問題真的是用戶痛點嗎会油？用戶會接受這個方案嗎个粱？

技術(shù)-我們需要依賴哪些底層系統(tǒng)？我們是否已經(jīng)正確理解了這些系統(tǒng)的工作原理翻翩？還有哪些需要關(guān)注的技術(shù)風(fēng)險

7.討論更好的解決方案

討論要對為什么做都许、做成什么樣一級如何實現(xiàn)這三個問題進行優(yōu)化

8.討論開發(fā)周期

故事卡片

1.簡短的標(biāo)題

2.描述信息who、what嫂冻、why

3.故事序號

4.估算胶征、規(guī)模或預(yù)算

5.優(yōu)先級

6.度量給故事指定度量標(biāo)準(zhǔn)桨仿，根據(jù)數(shù)據(jù)判斷是成功還是失敗

7.依賴該故事依賴或者需要一起發(fā)布的其他故事

8.狀態(tài)計劃到哪個發(fā)布中睛低？啟動了么？進行中服傍？已完成钱雷？

9.日期

檢視產(chǎn)出

-用戶體驗質(zhì)量

從目標(biāo)用戶角度來審視產(chǎn)品。簡單易用嗎吹零？使用過程中是否能體驗到樂趣急波？看起來還讓人覺得舒服嗎？和品牌訴求及其他功能之間的一致性保持得怎樣瘪校？

-功能質(zhì)量

功能正確嗎澄暮？是否還有遺留的bug或者錯誤？測試人員和團隊其它成員可能已經(jīng)完成測試和bug修復(fù)阱扬。好的測試人員會告訴你產(chǎn)品中還隱藏著更多bug,也可能會告訴你產(chǎn)品的質(zhì)量堅如磐石

-代碼質(zhì)量

代碼質(zhì)量高嗎泣懊？符合編碼規(guī)范嗎？這些代碼會在系統(tǒng)中留存一段時間麻惶，因此最好搞清楚它們是一u擴展和維護還是堆砌了遲早要還的技術(shù)債

如果一個故事沒有進行三次錘煉馍刮，那么這個過程就不能稱之為一個學(xué)習(xí)過程

拆分

對技術(shù)來說-將故事拆分成可以在兩三天時間內(nèi)完成開發(fā)和測試的模塊，是一個非常好的經(jīng)驗法則

對話是拆分故事最好的工具之一

探索最小可行方案

*你認為哪些用戶和客戶會使用你的方案窃蹋？

*沒有你的方案時卡啰，他們?nèi)绾螡M足自己的需求？

*有了你的方案警没，他們的世界會法傷怎樣的變化匈辱？

*你的方案看起來怎樣？ 它是如何發(fā)揮作用的杀迹？

*你的方案要花長時間開發(fā)亡脸？

在開發(fā)過程中保持日常對話

不管多么努力，即便是故事工作坊也不能預(yù)測處開發(fā)啟動之后會遇到的各種情況，為每天進行頻繁的非正式故事對話做好準(zhǔn)備浅碾。在每天的站會踢出討論的需求

開發(fā)過程中的反思：計劃如期達成了嗎大州？延期了？或提前了垂谢？和預(yù)期的產(chǎn)出一致嗎厦画？適時對工作方式進行微調(diào)和改變，力求獲得質(zhì)量更高滥朱，更符合預(yù)期的產(chǎn)出

經(jīng)常反思產(chǎn)品質(zhì)量苛白、工作計劃及工作方式

評估

*拿有意義的工作軟件模塊去測試客戶和用戶，從中學(xué)習(xí)

*利用評審會議向利益干系人展示產(chǎn)品

發(fā)布

發(fā)布

指足以給這些客戶和用戶以得到我們想要的結(jié)果焚虱。一旦天平兩段達到平衡，就可以開始發(fā)布

學(xué)習(xí)的主要目標(biāo)懂版，就還需要使用度量來了解人們是否使用以及如何使用產(chǎn)品

運用度量和直接接觸用戶來真正了解是否達到預(yù)期

身為產(chǎn)品負責(zé)人鹃栽，要兼顧其它干系人的想法，扮演制作人的角色躯畴，幫助他們獲得成功民鼓。

第13-15章 用戶故事地圖的整個聲明周期

探討機會

團隊可能沒有足夠的信息做出通過還是不通過的決定。如果是這種蓬抄，列出還需要了解哪些信息丰嘉，然后一起尋求答案。

如果仍然無法做出通過還是不通過的結(jié)論嚷缭，可以將這個機會放回機會待辦列表饮亏，供日后討論。這叫推遲決策阅爽。

事實上路幸，我們不應(yīng)該將所有這些聰明的想法都變成軟件，不管踢出想法的人究竟是什么頭銜

通過探索來建立共識

探索的4個核心步驟：

1.從業(yè)務(wù)角度來組織想法

2.理解客服和用戶付翁，搞清楚怎樣才能幫到他們

3.把自己的解決方案呈現(xiàn)出來

4.簡化并計劃招到最小化的可行方案及具體開發(fā)方式

一起建立輕量級的用戶畫像简肴，力求在團隊中建立共識和同理心

如果保留下來的想法超出扔掉不用的想法，就說明你的探索工作可能沒有作對

一個可行的產(chǎn)品意味著對特定商業(yè)策略百侧、目標(biāo)客戶和用戶都是成功的

制作優(yōu)先級的秘訣：

具體的業(yè)務(wù)結(jié)果可以驅(qū)使我們聚焦于特定的用戶砰识，他們的目標(biāo)及其使用活動。對這些活動的關(guān)注驅(qū)使我們聚焦于用戶需要哪些具體的特性和功能

特定的業(yè)務(wù)目標(biāo)佣渴，客戶和用戶確定優(yōu)先級辫狼，然后再為他們的目標(biāo)確立優(yōu)先級。最后才是功能

探索的目的是建立共識

驗證性學(xué)習(xí)

設(shè)計思維的第一個步驟是同理

直接與客戶和用戶交談辛润。親身體驗?zāi)阆霂椭麄兘鉀Q的困難予借。

下一步是形成想法

制作簡單的原型進行探索，得出最好的解決方案。制作一定保真度的原型灵迫，讓用戶和哭胡可以評價解決方案是否真的惡意解決他們的問題

最后一步是測試

得到一個你認為可以解決自己所關(guān)注問題的原型之后秦叛，再把它拿給潛在用戶看。

將解決方案拿給可能購買或使用產(chǎn)品的人看瀑粥。不要期望它們一開始就能去的吃那個工搞挣。不斷加以迭代和完善

以下幾種方式注定可以把設(shè)計過程搞砸

*沒有對業(yè)務(wù)需求和目標(biāo)客戶進行慎密思考就盲目開始。這會使我們難以確定誰才是最值得關(guān)注的人以及是否找到了好的解決方案

*花大量時間進行全面研究并理解已經(jīng)了解的東西谁撼。世界那么大裕坊，總有你不了解的東西，為什么不及時停止呢修噪？

*不花時間與用戶或客戶交談查库，不從他們那里學(xué)習(xí)。畢竟黄琼，有很多數(shù)據(jù)是現(xiàn)成的樊销，而且我們已經(jīng)想好了很好的解決方案。現(xiàn)在只需要著手設(shè)計就行了

*無法聚焦于具體的問題脏款，而是一心想著要為普羅大眾廣泛解決許多問題围苫。解決的問題越多越好，對嗎撤师？ 此外剂府，大問題通常會導(dǎo)致大的解決方案。想為有沖突需求的人解決問題剃盾，最終可能導(dǎo)致沒有人會喜歡你的解決方案腺占，

*考慮的解決方案多，但只局限于征詢設(shè)計師對解決方案的想法痒谴，因為他們才是唯一受過專業(yè)想法訓(xùn)練的人

*不花時間多考慮幾個解決方案湾笛，因為現(xiàn)有的想法已經(jīng)很好了

*做的原型看起來很逼真，但等客戶和用戶真正使用時并沒有很好地發(fā)揮作用闰歪。盡管如此嚎研，遇到這種情況還是會言不由衷地客套一下『看起來很漂亮』

*說服自己和其他人，這個經(jīng)過充分研究和專業(yè)設(shè)計的解決方案是可以發(fā)揮作用的库倘。畢竟临扮，遵循的是一個嚴謹?shù)脑O(shè)計過程。哪里會有什么差錯呢教翩？

*不擔(dān)心開發(fā)成本杆勇。這個方案是正確的，因而任何開發(fā)成本都是合理的

*將解決方案拿到客戶和用戶面前饱亿，并不關(guān)注是否達到自己預(yù)期的結(jié)果蚜退，而是關(guān)注整個過程中出錯的環(huán)節(jié)闰靴，出現(xiàn)問題，一味指責(zé)別人

第16-18章 深入介紹如何在持續(xù)迭代中使用用戶故事

以下集中情況故事工作坊的效果會變得不那么好

* 沒有人積極參與钻注，一言堂蚂且，只有一個人在描述需要什么，其他人都只是聽

* 只關(guān)心驗收標(biāo)準(zhǔn)幅恋，不講3W的故事

* 不能從功能的角度和技術(shù)的角度來考慮各種方案

每一個故事討論和分解階段杏死，都要一心想著目標(biāo)

1.對于機會，要討論它們究竟針對誰捆交，它們要解決什么問題淑翼，它們是否與你的商業(yè)策略想匹配

2.在探索階段，要詳細討論誰會用品追，為什么要用以及怎樣使用你的產(chǎn)品玄括。團隊的目標(biāo)是構(gòu)思一個有價值、有用肉瓦、可行的產(chǎn)品遭京。這時，要做許多碎尸的工作风宁。幸運的是，你只需要將最少數(shù)量的故事推入發(fā)布待辦列表中蛹疯，這些列表描述了一個最小可行產(chǎn)品版本

3.規(guī)劃開發(fā)策略戒财，要討論有哪些風(fēng)險：用戶是否喜歡和接受的風(fēng)險，技術(shù)可行性的風(fēng)險捺弦。要以學(xué)習(xí)的心態(tài)展開碎石行動饮寞，首先開發(fā)原型和做技術(shù)穿刺，力求從中充分了解到信息

4.規(guī)劃下一步開發(fā)周期時列吼，要進行最后一次最佳討論幽崩，明確做出開發(fā)決策并就驗收標(biāo)準(zhǔn)達成一致意見。這些一致一件中的每一條都提供一個可以進一步分解的故事的計劃寞钥，每個故事滿足一條一致意見就可以了

產(chǎn)品回顧會

與團隊成員回顧

回顧三個要素：產(chǎn)品慌申、計劃和過程

產(chǎn)品

從已經(jīng)完成開發(fā)的、以故事結(jié)果的軟件產(chǎn)品開始討論理郑。確保把它投影在屏幕在屏幕上蹄溉，并且有機會試用。

團隊對質(zhì)量的主管評級：

*討論用戶體驗的質(zhì)量您炉。不只是UI看起來怎樣柒爵，還包括它的具體使用體驗，它有逾期的那樣好嗎赚爵？在5點量表上自己做評級棉胀，5是最好

*討論功能上的質(zhì)量法瑟。測試過程還流暢嗎？ 是不是還有許多bug'? 測試人員認為測試更多或有更多時間愛你測試可以發(fā)現(xiàn)更多bug嗎唁奢？ 在5點量表上自己做評級霎挟，5是最好

*討論代碼的質(zhì)量。 寫的代碼容易維護和拓展嗎驮瞧？還是只是寫了新的一批遺留代碼氓扛？?

計劃

如果此時正處于一個有著時間盒約束的迭代或sprint,可以考慮先制定計劃和預(yù)估可以完成多少任務(wù)。

*確定哪個故事已完成论笔，哪個沒有完成采郎。討論這個問題可以幫助團隊建立驗收標(biāo)準(zhǔn)的共同定義。"完成"意味著有自動化測試狂魔？意味著所有手工測試完成蒜埋？還是意味著負責(zé)人和UI設(shè)計師評估過產(chǎn)品？

*統(tǒng)計你們?nèi)宋囊呀?jīng)完成的故事數(shù)量最楷。這是你的進度

*統(tǒng)計已經(jīng)開始和沒有完成的故事整份，如果還有很多，就表明還需要繼續(xù)規(guī)劃

*討論探索工作預(yù)算的時間量籽孙。充分利用這些時間了嗎烈评？ 用的時間是否超出了預(yù)期?沒有準(zhǔn)備充分就開始開發(fā)自己覺得有信心的東西，化的時間太少犯建，其后果你很快就能體會讲冠。花的時間太多又不利于準(zhǔn)時交付

*討論希望下一個周期中做的改變适瓦。不要過度承諾竿开。最好是小改變一次性改變太多就好比一次承擔(dān)太多的工作。你最后肯定會失望的玻熙。

與干系人評估回顧

評估探索性工作

*簡要討論每一個已經(jīng)開始處理的機會否彩；為誰，為什么嗦随，如果成功列荔，又期望得到什么結(jié)果

*討論并展示為理解問題和解決方案而做過的所有工作

*討論并展示前面所做的原型和實驗。討論客戶和用戶對解決方案的看法

評估交付工作

*評估方案的目標(biāo)客戶枚尼、用戶以及預(yù)期結(jié)果肌毅。記住做這個方案的動機一級成功的意義，這樣做總是極好的

*討論并展示為每個方案構(gòu)建的故事成果姑原。干系人會為此提供反饋悬而，值得欣慰的是，如果有機會在探索工作時就得到他們的反饋锭汛，那么反饋一般是『看起來還不錯』

*從整體上討論故事笨奠，如果采取蒙娜麗莎這樣的方法袭蝗，就需要向他么解釋為什么軟件在此之后看起來不完整。

每次已發(fā)布般婆，團隊都要討論如何完成度量或觀察用戶到腥，借此來了解是否真正取得了預(yù)期結(jié)果

*為產(chǎn)品建立度量指標(biāo)，追蹤新功能的使用情況

*在用戶使用新產(chǎn)品時安排時間對他們進行觀察

實際實施

作為一個產(chǎn)品不得不說蔚袍，關(guān)于用戶故事地圖這本書乡范，我學(xué)到了太多。

1.從對產(chǎn)品的規(guī)劃上來說啤咽，我會以迭代的成果為依據(jù)晋辆，來判斷每次迭代的功能需要哪些

2.在對故事的拆分上，每次的正式迭代上線計劃宇整，都是以完成這次目的所需的最小功能來做工呢個能規(guī)劃瓶佳。不是必須要上的功能就先砍掉。來整個迭代能以最快速度得到自己需要的觀測結(jié)果

3.在原型設(shè)計上鳞青，會在一開始考慮到哪些是大膽的假設(shè)霸饲，盡量得去得到消除假設(shè)

4，與開發(fā)及其相關(guān)成員的溝通上臂拓，始終讓他們了解用戶厚脉、了解目的。參與到產(chǎn)品設(shè)計中胶惰，共同得到大家認為的最優(yōu)解傻工。讓他們明白自己做的東西是為了什么，最后得到了一些什么成果童番。共同與整個產(chǎn)品學(xué)習(xí)成長精钮。

5.時刻記得所做的一切都是為了更好的學(xué)習(xí) 在產(chǎn)品迭代完成后威鹿，與所有相關(guān)成員一起好好聊聊回顧剃斧，如何能更好地學(xué)習(xí)進步。在產(chǎn)品發(fā)版后忽你，去度量觀察用戶幼东，了解是否達到預(yù)期結(jié)果，得到了哪些之前并未知曉的信息

6.對重要的是與用戶對話科雳，了解用戶的需求是什么根蟹。真正幫助到了用戶，產(chǎn)品才能成功糟秘，公司也才能實現(xiàn)自己的訴求

本文首發(fā)于公眾號『里柳的產(chǎn)品之路』（ID:pmliliu）