筆者從寫小說、設計故事的思路出發，類比了如何用這一思路做需求分析。

故事的起點

平時我會寫一些超短篇的小小說來練練筆，因此如何通過設計故事情節來突出我想要表達的思想是我在每次寫小說以前必做的事情。我自己的經驗是首先定義好核心思想，然后在這個核心基礎上根據自身的生活或是所知所得設計一個主線故事，然后再通過主線故事穿插設計一些支線故事來凸顯人物性格、提升故事感情等作用。

當我的工作從一個單純的執行者過渡到一個策劃者與執行者的時候，我開始需要去構思一個產品框架，同時為一個從0到1的產品去定義好各階段要做的事，分清輕重緩急，這也是每一個產品設計人員要做的事了。

需求設計、需求分析與需求管理是一個產品必做且常做的事。我所說的需求，可能是來自上級們的想法，可能是來自用戶的反饋，可能是通過自己的思考而得出的想法，此時會有很多很多的想法想要融入到產品中。

那么問題來了：

1. 我應該先實現哪些想法？
2. 需要實現的想法我應該如何劃分優先級？

關于這兩個問題，都有直接可學習參考的方法論可以使用。不過我在這里并不是想要和你討論這些方法論的定義和如何做，每個人的工作內容與面臨的背景都不一樣，在已有方法論的基礎上基于我的情況，我是如何做的，是我想要分享給你的。

那么現在歡迎來到我的故事。

怎么設計一個故事

（一）小說主線故事與產品核心功能

在文初我提到，我有時會去寫一些很短篇的小說，那么就讓我把我所負責設計的產品比喻為一部小說。每部小說都有一個主線故事概要，那么每個產品也有一個故事概要，便是這款產品為誰解決了什么問題。以下我便以國民APP微信舉例。

微信的故事概要就是解決了全年齡層用戶即時通訊與社交的問題。當我用一句話描述了我的產品，就好似我用一句話概括了我的小說核心。那么現在我要介紹我的小說故事，此時我會告訴你一個主線故事梗概，這個故事會有多個模塊組成，通過這些模塊中的各個小故事充分的去體現我的思想。產品的主線故事梗概，便是為了滿足故事概要所設計的各個核心功能。例如微信的即時語音文字通訊，通訊錄管理以及朋友圈等社交功能。

現在我介紹了一本小說的概要，描述了主線故事梗概，讓你大致了解了這是一個什么故事。

我說明了一個產品為誰解決了什么問題，描述了為解決這個問題所提供的方案的組成功能內容。

接下去的內容其實你也能想到了。在閱讀小說時，你了解了故事的大致內容以后，就會去探索小說中具體發生了什么故事，這一個個小故事組成了一個完整的主線故事，便構成了一部小說。

在使用產品時，你了解了我的產品可以幫助你解決什么問題，接著就去探索產品中是通過哪些核心功能幫助你解決問題，在使用這些核心功能時，你體驗到了組成這些核心功能的一個個小功能，從而了解了這款產品。

在此做一個總結，我將一個產品分成了一個四級樹狀結構，具體如下：

1. 產品是什么，為誰解決了什么問題。
2. 主線故事提供了具體的解決方案。
3. 各個功能模塊組成了核心功能，進而提供了完整的解決方案
4. 每個功能模塊都由眾多小功能組成。

（二）精彩的主線故事與充滿魅力的支線故事

在我們閱讀一部小說，或是閱讀一個故事時，不僅會關注發生在主角身上主線的故事，同時也會去了解與主角相關，但是并不一定與主線相關的支線故事。

主線故事幫助我們了解貫穿整個作品全局的內容，而支線故事更多時候是幫助完善主線故事，豐富因主線故事內容不足造成的角色性格薄弱的問題。有時一個好的支線故事，在回歸到主線或是和主線產生關系以后成功讓故事得以升華，讓人念念不忘。

不妨通過我喜歡的幾個故事體會一下主線與支線故事配合的魅力，大家如有興趣可以詳細了解以下幾個故事里的支線故事。

火影忍者卡卡西外傳

在作品中卡卡西一直是一個慵懶且充滿故事的角色，通過卡卡西外傳講述了卡卡西父親的死因以及帶土的死因，從而完整的塑造了卡卡西的性格以及角色。這些支線故事和后期忍界大戰帶土作為BOSS出現產生了聯系，讓人不勝唏噓，伏筆的回收讓故事得以提升一個臺階。

仙劍奇俠傳4懷朔

懷朔是慕容紫英的師侄，對自己的師妹璇璣十分好。在故事中期，聽說璇璣想要夏鳴蟲，便去幫她抓。懷朔后來為保護慕容紫英，被同門殺死。故事后期瓊華派為飛升提升門派至半空中，致使部分修為低的弟子死去，璇璣便是其中。最終決戰中主角團發現了在懷朔房間前的璇璣尸體與夏鳴蟲，不由得再次讓人回憶起懷朔，讓整個悲劇的氛圍更加濃烈與感染人。雖然這是一個可以不觸發的支線故事，但是有了這個故事讓主角的所作所為更合理，同時情感的渲染更強力。

《家》

巴金先生的《家》這部作品描寫了高家三個孩子的故事，其中大哥高覺新的故事充分的說明了那個時代家庭的無奈，他與妻子的一切都在家人的安排中，他從無反抗。而可以跟隨自己所想而去生活的小弟高覺慧讓他羨慕不已。大哥高覺新的支線故事充分的透露了時代的無奈，對比下更加凸顯了追逐自由中心思想與作者想要表達的內容。

以上只是我自己比較喜歡的三個故事，你可以帶入你自己喜歡的故事去思考。前文我談到小說與產品的聯系，那么通過這個聯系我把支線劇情理解為組成產品核心功能但有時并不是那么重要甚至可以沒有的功能，而有了這些功能可以為產品錦上添花，提升用戶的喜愛程度。

不妨做這么一個類比：

即時通訊、朋友圈、支付與公眾號等功能模塊組成了微信的核心功能，但是微信還提供了方便的消息記錄轉移功能，這個功能許多時候用不上，不過微信依然提供了一個使用體驗很好的方式幫助用戶實現了消息記錄備份轉移的功能，進一步鞏固了這個溝通與社交軟件的核心功能。

就好像故事里的支線如果可以回歸到主線或是與主線有聯系可以幫助讀者更加陷入故事中一樣，好的支線功能可以幫助用戶更加舒適的體驗產品，解決更多的問題。那么如何定義產品的主線故事和支線故事呢？以下是我的理解。

1. 主線故事：滿足為目標用戶解決問題提供的具體功能。
2. 支線故事：大多時候未必與核心功能直接相關，但是可以幫助完善、鞏固核心功能的次要功能。

其實主線與支線并非固定不變，例如微信剛加入公眾號功能時，未必就是一個主線故事，公眾號并沒有直接滿足溝通以及社交的需求，但是卻有效的拓展了微信的局限，成功將微信拓展為一個更加全面的社交工具，從而在后來發展為主線故事。

（三）做個小結

基于故事和產品的聯系，以及主線故事和支線故事的關系，我便把產品的功能分成了四個等級，其中頂級的產品是我們的最終目標，而二到四級則是我們要去完成的事，便是——需求設計、需求分析與需求管理。

如何評估好故事設計中各個故事的重要程度與優先級

（一）先確定你是否需要這個故事

我每一次構思一個故事的時候，總會先想一個問題，我要把之前想到的一個情節加入進去嗎？同樣在設計產品功能的時候，我也會去思考一個問題，這個功能是一個需求，我要將其加入到產品中嗎？

這個問題換一句話說，就是需求分析了。

關于需求分析，雖然有不少方法論可以參考，但是面對不同產品、不同團隊、不同背景的情況下，強行代入方法論往往并不能得到有效的結論。其實從每一個功能確認落地到需求，大致可以分為兩類。

從無到有，增加功能

這個分類是最為頭痛的。在沒有數據驗證的情況下，誰都無法保證新增的功能一定是滿足用戶需求的，此時便陷入了惡性循環：無法確認功能是否可行——不敢第一時間開發——無法滿足用戶——繼續思考功能。最可怕的就是找不到解決問題的方法。

已有功能，完善功能

這是一個容錯率較高的需求分類，就算未達預期，因為前提的功能已經滿足了用戶，那么可以之后繼續優化。

第一個分類可以總結為為用戶提供了一個待確認的解決方案。這個解決方案可能幫助用戶解決了新問題，或者是鞏固完善了之前問題的解決方案，我稱之為決定性問題。新功能一般承載著拓展產品局限，提升用戶好感的重任，如果用戶反饋不佳則可視為新功能未達預期，則有可能在之后的迭代中被弱化，以至于成為支線故事。

第二個分類可以總結為為用戶提供了提升解決方案效率的方案。這個方案幫助用戶可以更加舒適的使用已有的功能更快、更好的解決自己遇到的問題，我稱之為效率性問題。效率性問題具象化程度更高，且更容易把握，例如用戶界面的優化、操作流程的優化或是加入其他提升用戶體驗的功能。這一類需求大多在產品步入正軌以后成為產品需求的主力，即從框架建設進入細節雕琢的階段。

那么我要如何分析提出的功能是否為需求呢？

依然以微信為例。微信的定位是社交通訊工具，那么這個產品的核心則在于社交、通訊這兩點。在未加入支付功能之前，微信的定位是十分清晰的，就是一個移動社交通訊工具，而遠非現在的工具平臺。那么當時的微信加入包含收支的支付功能是否算是一個需求呢？

作為社交通訊工具，加入支付功能其實從表象上與社交與通訊主線故事的關聯并不大。因為支付功能無法幫助直接促進社交氛圍更好以及提升通訊功能效率。那么為什么依然要加入支付功能呢?

如果微信僅有即時通訊、朋友圈這些常見的通訊、社交功能，那么這個產品依然無法提升差異化程度，容易陷入同質化中。畢竟從當時的情況來看飛信以及米聊也可以加入類似的功能進行競爭。而支付功能除了拓展了工具功能以外，對于微信而言更重要的一點在于加入了收發紅包功能。

源于我國特色的紅包傳統與社交行為相關，而紅包的錢從何而來呢？此時支付功能便提供了最佳助力。因此當尚無法定義功能是否未需求之時，可以分析這個功能是否可以回歸到主線，有些人會將其稱之為閉環思維。

通過以上的分析可以得出結論，加入支付功能是一個可能提升微信社交品質的需求，那么接下去就可以通過灰度測試等功能進行驗證了。

增加功能充滿了許多的未知性，所以這一點才會讓我們望而卻步。這些從無到有的功能需要設計者有足夠的判斷力、經驗以及分析能力，但是依然無法完全保證可行性，所以在及時驗證通過后方可確認為是一個需求，是否可以列為未來可優化的需求。

針對這類需求的分析，建議如下：

1. 當下需要新增的功能，是否可以回歸到主線。如果可以，這個功能對主線的貢獻是否顯著，若無法確認則可以小范圍測試進行驗證，切勿盲目大范圍開發上線試錯，為自己預留調整的空間。
2. 任何人提出的功能需要再次抽象，即問自己兩個問題，他為什么需要這個功能，解決了什么問題。因為不同角色總會從當下遇到的情況出發提出一個表象的解決方案來解決當下遇到的問題。而產品設計者需要在這個基礎上在提升一下自己的思考維度，發現這個方案之后遇到的問題是什么，比如說當時微信加入支付功能時最佳的輔助對象是發送紅包提升社交功能競爭力，而不是建設金融平臺。

對于功能完善類的需求，由于已有前提功能鋪墊，所以這類需求問題分析起來都會更有把握，試錯成本也更低，在此便不多贅述了。

簡單的做一個總結，其實以上思路靈感來源于我自己了解了KANO模型后的一些嘗試。經常有人對我說，要把問題量化。但是我覺得量化容易讓自己陷入一個桎梏，盲目相信數值，忽略使用者的感受，畢竟我們打交道的是人。所以基于KANO模型，對于需求的定義，我整理為以下幾個準則：

1. 加入的功能是否能讓用戶眼前一亮并為他們解決決定性問題。如果是，那么這樣的功能需要優先系統性的思考并盡早完善為需求。
2. 加入的功能是否只是幫助用戶錦上添花的解決了問題，并未提升效率。如果是，那么這可能并非是需求，只是遇到了一個問題后的感受。如果否，則這是一個較為重要的需求，有效解決效率性問題是產品設計工作中內容占比十分大且重要的內容。
3. 針對不同角色來思考，每次的需求滿足范圍如何，如果只是解決了極少數人的問題，有必要重新回顧自己的分析歷程。

（二）確認每個情節的重要程度與優先級

記得我曾經構思了一個劍俠的故事，我為其構思了精彩的前傳，但是前傳對于主線而言意義并不大，算是一個補充閱讀。后來我便將這個小故事放在了我主線故事之后作為一個補充章節。

不論是產品戰略與功能架構設計者，還是以執行為主的執行人員，確認重要等級與優先級是必須要面對的問題。解決這個問題有一個十分有效的方法，就是根據重要程度與緊急程度分為四象限，想必這個方法大家都不陌生了。

但是問題就在于，該如何定義重要程度與緊急程度呢？運營在使用后臺時告訴我，現在的編輯器太難用了，影響了她的工作效率，需要盡快解決。用戶在使用APP的時候告訴我，為什么APP還不支持信息檢索功能，導致她每次搜素通訊錄十分費勁。每個人都覺得自己的問題很嚴重，很緊急，這該如何是好呢？

讓我們回到前文的四級故事架構，即需求架構。

重要程度的判斷

對于產品的定位與核心功能，設計者肯定是十分清晰明了的，主線故事要做什么大家也是知道的，主線故事的各個組成部分大家也是明了的，那么基于這個結構如何定義重要等級呢？

這里的重要程度劃分是這樣的，主線優于支線，一級故事優于二級故事。

我將支線故事劃分在了二級故事，則自然支線故事下的各故事重要程度要放在主線故事的一級故事之后。例如產品的用戶界面優化，這個事情非常重要，但是如果同時有其他不論是新增還是完善的一級故事需要設計，都放在其之后。因為一般的支線故事更多的作用的是提升效率、提升體驗，并沒有幫助產品拓展局限與解決新的核心決定性問題。比如常見的在APP中加入用戶反饋功能、提升用戶界面的視覺效果以及其他效率性問題，他們很重要，但是并不需要每次都很重要。但是如果某個支線故事的二級故事有助于主線，那么此時需要酌情將其重要等級提升，比如之前提到的微信加入支付功能，對于社交通訊而言支付不重要，但是對于發送紅包這個核心社交行為而言，支付的收支功能決定了核心的社交體驗是否能夠提升。

支線故事的重要等級判斷是很清晰的，那么主線故事的重要等級判斷就不是那么明顯了。組成主線故事的內容很多，但是每個模塊對于核心功能的刺激作用是不一樣的。例如微信發現功能中的朋友圈與游戲兩個功能，都屬于社交功能。朋友圈定位的是所有用戶，游戲更多的偏向于年輕且喜歡游戲的人，此時在重要等級的劃分上自然是朋友圈優于游戲。所以對主線故事刺激作用的顯著程度是判斷重要等級的衡量標準，刺激作用的顯著程度，判斷依據如下：

• 商業價值的體現。商業價值是需要優先考慮的要素，這點想必無需多言。在朋友圈還是游戲中加廣告，自然是優先考慮在朋友圈加廣告了。
• 受眾人群的多少。理論上能盡可能多的滿足目標用戶的需求重要等級要高于滿足盡可能多的一般用戶，盡可能滿足多的用戶要優于滿足了部分用戶。

緊急程度的判斷

緊急程度的判斷相對來說更加簡單一些。具體如下：

• 目標用戶期望的需求優于一般用戶的需求
• 數量多的用戶需求優于數量少的用戶需求
• 新出現的主線故事決定性需求優于其他主線故事的效率性需求
• 影響到到主線故事的決定性需求優于一切需求

至于說BUG之類的自然是需要優先解決的，這個不屬于需求的討論范圍，在此也補充說明一下。

通過以上重要與緊急程度劃分，再帶入到四象限法中就會更加自然了。同時我也想再補充說明一下，任何問題都有時效性以及需要結合當時背景，對于問題的判斷也需要充分考慮各方面因素。盡可能全面的考慮問題得出的結論，比依賴于量化問題、套路化的方案更具參考性。

最后的碎碎念

行文下來，回憶起我不堪的小小說創作，還是要笑一下自己的稚嫩，不過能為我的日常生活提供一些靈感，那些故事也不算白寫，希望日后能夠早日寫出自己欣賞的故事。

洋洋灑灑數千字下來，想來讀者們或嗤之以鼻，或略有所得。我始終堅信一點，產品策劃設計的工作沒有絕對的套路，每個人的經驗、性格、知識、思維不同，導致不同的方法使用后的結果也不盡相同。所以我自己喜歡吸收優秀者的思維，結合自己的情況再來實踐。

從聽命于上級的低級執行者，到開始主動思考提出看法的執行者，再到委以任務的功能結構設計者，到未來可能會成為的戰略制定者，不論是從0到1，還是從1開始拓展，以上總結的思維我一直幫助我自己去突破。也希望我的些許淺薄領悟能夠幫助到你。

本文由 @問夢孤獨 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自 Unsplash，基于 CC0 協議