2
按：作者killifer，華爾街見聞產品經理。
之前寫了一篇有關于需求分析中可能遇到的坑《你做“需求分析”，踩過這幾個坑嗎？》，but從理解的角度，應該先了解需求分析到底是一個怎么樣的過程才對，so，我終于來“補坑”惹。
一般來說，一個具體需求的分析的整體流程為：
確認需求->具體分析->交付設計／開發(fā)->驗收->上線
1、確認需求的本意
為什么會提這點呢？因為需求的來源會比較多，可能有以下來源：
產品經理自己；
其他相關的產品經理；（老板、你的leader等）
其他相關的部門；（運營、銷售、廣告、編輯等）
直接的用戶；
不同的來源，導致需求“被經手”的程度不同，從而容易導致理解的意思不同。
①這種情況，不太會存在需求理解偏差，除非你當時“精分”了。但是②③④就非常有可能理解錯誤、理解不到位、理解不深入。而造成②③④這種理解錯誤的原因，又有可能分成以下幾種：
a. 對方在跟你表述需求的時候，直接表述了自己認為的解決方法，而跳過了表述真正的需求的階段；
這種情況下，如果你不多問幾個為什么，可能就被他給帶走，按照對方的解決方案做了。但實際上，最終多問幾個why的結果可能就是加一個字段的事情，而不多問的結果可能是新做一個功能；
b. 對方在跟你表述需求的時候，自己都沒有清楚自己要干嘛；
這種情況下，還是多問幾個為什么，幫助他整理自己想怎么樣，為什么要這樣，最終發(fā)現(xiàn)他的真正需求或者說最終不需要做需求；
2、確認該需求是否有必要
原因可能出現(xiàn)在以下幾個地方：
①產品經理自己YY需求或者僅從某一類用戶的角度考慮問題，具體在《你做“需求分析”，踩過這幾個坑嗎？》中提到過。這需要產品經理自己進行慢慢糾正。
②其他人YY需求；
a.和產品經理一樣，其他人也可能容易站在自己也是其中一種類型的用戶立場，或者自己對某個功能更專業(yè)的角度，去提絕大部分用戶不會用或者“太高級”的功能。
b.也有可能出現(xiàn)在以數(shù)據(jù)為導向的工作方上。舉個例子：同事A發(fā)現(xiàn)下載量特別差，可能就會認為是下載頁的整體文案/頁面風格太不吸引人，可能就會希望能夠把下載頁進行重新調整。但實際上，可能并不是文案太差，而是下載按鈕并不明顯。
針對其他人的YY需求，產品經理要會判別和求證。
3、確認該需求的優(yōu)先級
這個確實會涉及到該需求和其他需求之間的整體關系，這里不多說，以后再單獨寫一個需求與需求之間的優(yōu)先級管理。
但是舉個例子好了：假設乃們的產品規(guī)劃是先把主打的亮點部分給優(yōu)化好，再去做基礎性同類產品都有的功能?，F(xiàn)在有個需求是基礎性功能的優(yōu)化，那么就可以先排在后面，不著急做。
在第一階段中，已經把很多“不合格”的需求給排除掉了，到了第二階段，就開始進入到需求的具體分析階段，該階段具體如下：
1、分析該需求的做法
①確認該需求影響到的范圍。
例如：同家公司的兩個產品可能共用某塊后臺功能，如果產品A因為需求而想要修改共用的那塊部分，那么就需要考慮到是否會影響產品B的數(shù)據(jù)獲取、信息展示等，之后的測試也都要帶上產品B。
②確認該需求的做法。
a.確認方案，主要是無爭議的相對最優(yōu)方案
例如：現(xiàn)在每個app都有節(jié)日時的特殊局部UI功能，這個功能如何做才能不需要上新版本就闊以靈活變更UI，這是需要確認的。當然，你也可以說，我每需要更改局部UI的時候，我就上一個新版本。（簡單的需求要復雜做，那我也只能攤手）
b.兩種方案取優(yōu)，這區(qū)別于上述a的情況，而是兩種方案各有優(yōu)劣，針對不同需求不同情況可能會得到不同的結果
例如：同樣一個頁面，可以做app原生頁，也可以做內嵌web頁，耗時、優(yōu)劣各有不同，需要根據(jù)具體的需求去做具體的選擇。
不同方法會導致需要不同的資源、人力和配合程度，需要在確認做法階段想清楚，以盡可能避免浪費、返工的情況。
2、分析該需求的業(yè)務流程、邏輯判斷
這個考驗產品經理對業(yè)務的理解、邏輯思考的能力以及細心程度。（這個在《你做“需求分析”，踩過這幾個坑嗎？》中”具體的需求分析階段“中進行過一部分的反向描述，啊哈）
①梳理業(yè)務流程：主要是用來確認涉及到的角色類型、角色的屬性、角色的動作、角色之間的關系。
舉個例子就好了：“發(fā)文章并展示”這個需求，至少存在幾種不同的流程：（不做好壞評價）
a.用戶發(fā)布文章后，都需要該網站編輯進行審核、格式整理，配上封面圖再發(fā)布到主頁內容流（所謂的精選）以及細分分類頻道，例如人人都是產品經理；
b.用戶發(fā)布文章后，可以直接顯示在某個細分分類頻道中，但是如果要發(fā)布到主頁內容流（所謂的精選），需要該網站編輯審核，但不會幫你進行格式整理，會進行封面配圖，例如pmcaff；
c.用戶發(fā)布文章后，需要投稿到某個頻道（精選也是分類的一種），還需要對應頻道管理員審核，也不會幫你進行格式整理，也沒有封面配圖，通過后顯示在該頻道中，例如簡書；
②確定流程中的邏輯判斷
確定了業(yè)務流程之后，根據(jù)流程列出過程中的判斷邏輯判斷條件以及邊界條件。延續(xù)上面的“發(fā)文章并展示”中b的情況：
a.審核通過的標準是什么：每個編輯大人自己定義？還是編輯團隊有統(tǒng)一規(guī)則？還是依靠瀏覽量、點贊量、收藏量這種相對客觀數(shù)據(jù)；是單一因素影響還是多因素綜合影響，綜合的話是否有分別的不同影響權重...
b.審核后是否會導致文章狀態(tài)不同？
c.審核后如何展示：展示在哪里、如何排序；
…..
3、根據(jù)具體分析的結果畫原型圖
原型圖主要是用來：
讓猿猿們更直觀了解需求；
設計師大人更加直觀了解需求，同時了解頁面需要表現(xiàn)的內容以及重要性程度；
讓所有相關的人們都根準備預估工時；
那么根據(jù)原型圖的作用，在制作原型圖的時候，就要明確：
頁面上展示的內容框架；
內容的優(yōu)先級；
另外，強烈建議未確定前都畫手稿，最終確定不改之后，再畫電子稿，具體原因可查看《做“需求分析”，有木有踩過這幾個坑？》中的“制作原型圖階段”
準備好需求分析的前提下，盡可能早的和設計大大溝通。準備好需求分析＋原型圖的前提下，闊以跟程序猿GG們溝通惹。
把需求分析和原型稿交付給設計師，并且明確以下內容：
設計大大了解細致的需求是啥；
設計大大了解頁面上需要的內容以及重要性差別；
設計大大了解你想要的感覺是啥（一般來說，大大都有自己的想法）；
把需求分析和原型稿交付給程序猿GG們，并且明確：
GG們了解細致的需求是啥；
GG們了解需求的業(yè)務流程、邏輯關系以及邊界條件等；
GG們了解做這個需求需要哪些方面的支持（是否需要后端、是否需要第三合作方等等）；
承接第三點，分別進行以下的驗收：
1、驗收設計大大的設計稿
如果有不合適的地方，盡快進行修改，盡量在程序猿GG們沒寫頁面之前修改完畢再交付給開發(fā)，避免開發(fā)不斷的跟著設計稿改而改。
（我有罪！猿猿們請原諒我?。?/p>
2、驗收需求
程序猿GG們開發(fā)完需求之后，先由測試大人進行功能測試驗收，然后修bug，再驗收，再修二次bug等。如果這個版本的需求都開發(fā)完成，那么產品汪們就需要進行驗收，盡可能早的進行第一次驗收，這樣出現(xiàn)業(yè)務相關的bug就比較容易被發(fā)現(xiàn)。
不要到最后時刻才做驗收！不要到最后時刻才做驗收！不要到最后時刻才做驗收！
需求上線后，理論上從本期的功能層面上來說就完成使命鳥～
but，如果有以下情況的話，產品狗你給我回來，不要跑：
1、該需求被拆分成了n次實現(xiàn)。
有些需求可能第一版本先上個簡單的，之后再繼續(xù)去做優(yōu)化，那么這個就需要被跟進數(shù)據(jù)，再去決定要不要去做優(yōu)化；
2、該需求是“測試性需求”。
有些需求，一開始就是為了測試用戶反應，那么同樣需要被跟進具體的數(shù)據(jù)情況，再去決定要不要取消這個需求或者要不要繼續(xù)升級這個需求。
注：《你做“需求分析”，踩過這幾個坑嗎？》（點擊閱讀）
【作者介紹】killifer，微信公號：killifer。華爾街見聞產品經理，人人都是產品經理專欄作家。腦洞大、笑點低、間歇性“有毛病”的理工科實力逗比少女。
雷峰網原創(chuàng)文章，未經授權禁止轉載。詳情見轉載須知。
