把需求拿到手，經過前面說的分析之后，上線似乎一蹴而就，但事實并非如此，特別是對剛入門的產品人來說，這當中有許多的坑還需要一步一步踩。今天結合我自己的工作經驗和之前學過的課程，給大家介紹一下需求在原型階段要做什么。
需求從小中大主要分為三種：功能點（單個頁面）、完整功能（模塊）和復雜流程（多個模塊、完整產品、功能多端），區分主要依據包括涉及的流程頁面、開發上線難度和測試時出現bug的概率（大功能bug就比較多一些）三個維度來判斷。所以我們這篇也從把每一步拆分成“小、中、大”三種需求類型去介紹，在介紹之前要重點解釋兩點：一、每一個步驟都基本會用到，但可以僅停留在思考層面，大家在工作中需要根據情況隨機應變，切忌死記硬背；二、部分步驟沒有區分三種需求類型的，就是三種都需要用到的，下面就不一一解釋了。（這兩點就是需求文檔里的全局變量。）
一、需求
我們在完成一個需求時分為以下幾個步驟：
1、明確背景和目的。在之前的文章中說過，我們拿到需求的時候，都需要首先考慮的第一點就是要先明確這個需求的背景和目的，因為需求背景和目的是整個需求的指南針，導向標，也就是明確需求來源方和涉及場景，明確需求的形態，千萬別后期自行腦補，不然很有可能要返廠，浪費人力物力。在工作過程中，特別是相對較大的需求時，經常會出現“因為走了太久，而忘了為什么出發”的情況，這時候再回頭看一下背景和目的，很多糾結的地方往往會會引刃而解。一般到手的需求可以分為“小、中、大”三個方向去思考用戶與需求的關系：
（1）若是已有部分小功能優化。
1) 進行用戶分類，看哪些用戶出了什么問題；
2) 找到出現這些問題的原因是什么，這里要求需求負責人對該功能的業務流程熟悉。如，產品路徑深、入口設置不明顯、文案提示錯誤等；
3) 數據區分各類型用戶受影響分布情況。找到核心用戶和問題之后，要找到數據支撐去讓你說服你同事和你一起做優化
（2）完整功能調整。看這個功能能夠給哪一層面的對象提供幫助，包括三個層面：
1) 用戶。用戶類的專注于提升體驗，這里要看對哪類用戶有好處、受影響的用戶有哪些。包括以下幾種：增加內容，提升數據準確性（添加用戶標簽）；減少操作，提升用戶便利性（增加部分頁面入口）；補充功能，提升用戶體驗（滴滴上增加開發票功能）。
2) 平臺。平臺類的我們專注于提升效率，這里主要看是否有提升操作人效率。包括以下幾種：增加渠道，引入新用戶（新增微信登錄功能）；減少重復性操作，縮短轉化路徑；數據分層，提升用戶數據化維度（千人千面大數據分析）。
3) 商業。商業類的我們專注于轉化，這里主要看是否有提高收入，是否有提高轉化率。分別有：拉動付費轉化率（折扣、分享免單）；新增收入點（新增會員收費模式）。
（3）復雜流程。復雜流程說的就是大于一個版本迭代的工作量，這個主要從產品當前所處的時期和希望讓用戶解決什么樣的核心需求出發所決定，和版本規劃、產品調性以及產品目標有關。由于情況多種多樣，不同產品也不同，在這里就不做詳細分析了。具體方法和第二點類似。
2、明確需求的基本邏輯。這是做需求的基礎，如果業務都不熟悉，那連修改功能點的資格都沒有。要求產品人要熟悉用戶的操作過程和數據流向。操作過程好理解，那為什么一定要關注數據呢？因為數據流向能夠指引我們快速找到需求的核心頁，而核心頁是解決用戶問題的根本。
3、產品調研。如果功能比較大，并且對于的競爭對手已有該功能，有必要做產品調研，產品調研可是判斷產品人評估該產品是否要做和它優先級排序的重要指標，具體方法之前講過，有興趣的可以找回之前的文章看一下。
4、制定方案。在明確需求的背景、目的和基本邏輯之后，就可以制定方案了，制定方案的時候還要考慮上線后如何評估功能效果，是用戶訪談的方式還是埋點收集數據。給個建議給新人，在做方案的時候別只做一套，要多做幾套，做老大的都喜歡選擇題不喜歡判斷+簡答題。當然，也別什么方案都拿出來，根據開發難度、效果、用戶場景以及需求目的，從一堆方案中挑選出2個以上的方案讓老大去選（之前似乎有說過，啰嗦了啰嗦了hhh）。方案不用太復雜，一般用手繪和思維導圖的方式即可，主要是為了方向上不要出錯，然后根據優先級去選出幾個切合實際的方案。
5、流程圖。工作中基本能滿足的兩種流程圖——業務流程圖和頁面流程圖：
（1）業務流程圖。之前在產品論壇看過，有很多剛入職的產品人有在吐槽上一任產品的問題，主要原因是由于缺少資料，無法理解產品這么做的初衷，只能推倒重來。其實這個問題的根本就是缺少業務流程圖，無法深入理解產品設計的初衷和過程。所以作為一名合格的產品經理，即使離開公司，也要讓下一任同行能夠清晰地理解你之前的項目，這雖然不是硬性要求，但是職業素養的問題（就跟玩狼人殺天黑就閉眼是一樣的道理）。同時，業務流程圖有利于幫助我們梳理邏輯和設置考核指標。這里不講該怎么畫流程圖，大家直接百度一下就能找到很多可的方法，我在這里就介紹一下畫業務流程時需要思考什么。
從需求大小上來說，包括已有功能優化、獨立功能、復雜需求（包括獨立產品、涉及多端的功能和大版本迭代）。
功能優化主要找到核心頁面，在核心頁面上，不一定需要業務流程圖；
獨立功能要考慮用戶和信息流向的關系，一般使用單通道流程圖；
復雜需求同樣要考慮用戶和信息流向的關系，一般使用泳道圖，泳道圖要關注以下幾點：
分析功能邏輯。考慮什么人參與到功能中（用戶）、這些人分別扮演什么角色（不同用戶的使用場景）、要完成什么任務，順序是怎么樣的（信息流向）。例如，美團外賣下單投訴整個流程——用戶下單之后，商家要怎么操作接受訂單，外賣小哥怎么樣獲取訂單并送給用戶，用戶在用餐之后投訴商家，客服要怎么處理。我們的要考慮用戶除了點外賣的用戶之外，還有商家、外賣小哥和客服；用戶下單、商家接單、外賣小哥送餐、客服接收投訴就是不同用戶的使用場景，而他們根據不同的場景，在平臺上的操作順序就是信息流向。
明確用戶與任務。這里我們還是用外賣平臺舉例。首先要明確用戶與系統的關系，怎么操作，怎么進入app的；然后梳理參與者之間的關系，即商家怎么發布菜單信息，用戶是怎么評估哪家店是我要點的；最后明確參與者的最終目標，即商家要盡可能的吸引用戶來店里點外賣，而用戶要找到適合自己的店和菜并下單。這步和“a”步的著力點不同，“a”主要是功能邏輯上，是為了區分泳道，而這一步是為了填充泳道里面的內容，并且保證各泳道之間的關聯性。
要盡可能保證只有一個開始和結束。起點和終點明確，制作人流程不容易出錯，也方便看的人理解。
最后優化調整。就是把異常流程加進去，從頭梳理一遍，相當于考試結束之后的檢查。
其實總的來說核心關注點就四個：用戶、解決需求的場景、數據流向和異常流程。只要考慮到了這四個，再百度一下畫的方法，就可以畫好業務流程圖。
??
（2）頁面流程圖。我們畫完業務流程圖之后，還需要畫頁面流程圖，頁面流程圖可以更直觀地表達出這個需求在各個頁面上的跳轉流程，也能更好地幫助程序員去理解需求。頁面流程圖是從業務流程圖中剝離出來的，如下圖（把大象關進冰箱）的頁面流程圖，僅供參考，不懂再自行百度 。最后啰嗦一句，參考為輔，練習為主。
??
6、原型交互設計。這一節是基本功，是考察一個人工作能力和工作態度的重要因素，也是豆奶當年剛入門時最自信，但也最容易犯錯的部分。
很多新人在求職時，簡歷上寫“能夠熟練使用Axure、墨刀等原型繪圖工具”并且把這一點作為基本功能專門上課去學。
豆奶認為，工具只是工具，你會用Axure畫原型就等于你會用筷子吃飯是一樣的道理，你會用筷子還是勺子甚至是手什么的根本不重要，重要的是你得會吃飯。豆奶公司之前有個測試轉產品，不會用Axure，但是老大又直接甩給她一個需求讓她一周內做完，她照著我們之前在需求池里的文檔，硬是用ppt畫出了整個需求，完成了工作。所以呀，真正的牛人是不會糾結于工具怎么樣的，工具只是術，而理解用戶場景需求才是產品人應該關注的部分。
所以我建議初版需求先別上工具，直接手繪。手繪可以節省很多時間成本，而且也很容易修改，初版的目的就是為了用最快的方法去解釋清楚需求，不論是跟老大還是跟研發去確認需求，都比較快。我一般是所有場景都考慮清楚了，老大點頭同意了，研發沒有其他問題了，也就是所謂的需求封閉了，再上Axure等工具，把具體流程落到圖上。
有幾個工作習慣的問題需要注意下：
不管什么時候的修改，都要記錄日期和修改內容。方便以后的工作交接和日后回頭看需求時，有理有據（鍋要分清楚該給誰背，吃啞巴虧的事，咱不能干）；
原型要分版本保存。原型千萬千萬不能修改后就直接覆蓋，否則如果突然某一天說還是之前的某一般比較好，要做那一版，可你又找不到時，只能重做了；
需求文檔要考慮極端情況。特別是數據上，有些地方數據最多的時候，是怎么呈現的，沒有數據時，頁面又是怎么呈現的，這些情況要講清楚；
寫原型時產品邏輯要解釋。比如O2O平臺顯示所有商家時，排列順序是根據評分從高到低排列還是下單量從高到低。這些邏輯要說清楚，不能遺漏；
異常情況別忘了。很多時候異常情況沒有考慮到，導致開發時出現bug，或者缺少部分頁面，工作效率降低了，這個鍋，又是你頭上的了。
7、需求考核指標。是后續產品迭代的重要指向標，要注意以下幾點：
首先是埋點。埋點怎么埋？從業務流程中而來，給大家分享一個常用的方法：業務流程中有判斷的地方就需要埋點。但一般的公司都會有自己的數據團隊，有數據團隊就只需要把需要的數據整理出來告訴他們要的時間點即可，如果沒有數據團隊的小公司，可能就稍微比較麻煩一點，建議去找個第三方的數據公司，還可能需要跟研發一起合作，把需要的數據整理出來再手動篩選，豆奶剛入行的那家公司，甚至要求我們要學習代碼自己手動去數據庫爬數據。
定期回收數據。根據產品的不同，要的數據也有區別，但總的來說關注活躍度、轉化率、各個頁面的流失率。還需要關注產品潛在bug的發生比例。
分析+總結+需求管理=產品迭代的方向。
通報各部人員產品上線情況。
二、評審會
在歷經千辛萬苦畫完了原型，寫完了文檔，產品內部評審順利通過之后，就來到聞者傷心，見者流淚，人見人怕，鬼見鬼愁，讓無數產品人都聞風喪膽的大（xian）型（chang）需（da）求（lian）評審會了。你或許會問，豆奶哥，不對啊！在寫文檔之前我已經跟老大、研發、UI都通過氣了，為什么還會遇到千人懟的情況呢？別急，且聽我細細道來。
評審會的目的是什么呢？就是為了在產品進入開發階段之前，給團隊中涉及這個需求的工作人員一個同步信息的機會，同時也為了避免在開發階段出現某些問題，需要重做，從而浪費人力物力。畢竟三個臭皮匠，頂過諸葛亮，大家在同一頻道，同一場景下思考的廣度和深度都可能遠超你一個人想的情況，而且我們一直思考一個需求，很可能陷入思考瓶頸，有些很低級的問題完全沒有想到。
我見過一些新人，在評審會上被懟之后需要調整一段時間才能恢復，我覺得是沒有必要的。既然是出于為產品好的初衷，我們即使評審會上被懟了，也沒關系，大家都是為了更好的工作嘛。再說了，還沒進入開發階段，這樣的問題是完全可以原諒的。千萬別有太大負面的壓力。
再說回來，在需求評審時，很多人一上來就直接講需求是怎么怎么做的，它包含哪些頁面哪些端。這樣很多研發在不明白需求的情況下，聽得云里霧里，不懟你懟誰。在需求之前，我們首先要把需求文檔公布給參與評審會的人，讓他們先了解基本需求。在評審會時要遵循以下幾步：
首先講需求的背景和目的，讓聽評審會的人了解需求；
用用戶故事來講用戶、需求、場景以及沒有使用我們產品之前的解決方案；
用用戶數據去解釋這個需求存在的必要性；
要簡述需求的決策過程和解決方案，讓參加評審會的人獲取的信息和我們是一致的。
描述需求功能列表。這里最好用信息構架圖，即每個頁面需要新增哪些內容，讓團隊內的人直觀地了解產品所包含的內容，再從用戶流向、內容流向和信息交叉這三個層面去解釋核心頁面。
版本規劃。功能優化的不需要這一步，其實小功能優化可能連評審會都不需要開，直接內部一致同意之后就可以投入開發了。大需求就需要版本規劃了，主要簡述根據數據可能出現情況去預估版本可能的迭代周期，而獲得數據則需要把時間反饋節點和所需要的數據內容提前告知研發或數據團隊。
三、需求池
最后，豆奶再講一下需求池。每一個產品都有自己的需求池，產品迭代的過程就是把需求從需求池里釋放出來的過程。由于產品的版本規劃不同，需求的優先級也不一樣，所以研發要結合自己的時間成本去迭代產品，需求相對滯后的產品則存在需求池里，這就是需求池存在的意義。那要如何管理需求池呢？步驟如下：
我們前面有講過，獲取需求之后首先要找到需求來源方還原受影響的用戶場景，然后按照上面講的內容進行原型和文檔的撰寫、需求評審，最后把需求放進需求池里；
把需求放進需求池之后要進行需求整理。在需求整理時首先要區分改進和bug，然后是評估優先級，我們可以根據重要緊急四象限來評估。bug的優先級是最重要最緊急，特別是影響產品正常使用的bug，要立刻讓研發去修復；
??
需求反饋。在釋放需求，功能上線后，需要跟需求來源方說需求已經上線了、并且自定義時間（XX日后）獲得反饋數據等情況。
