注：本篇主要描述一個需求的成長史，不是一群需求們的血淚史，也就是說需求們的管理不在具體討論中。

之前寫了一篇有關(guān)于需求分析中可能遇到的坑《你做“需求分析”，踩過這幾個坑嗎？》，but從理解的角度，應(yīng)該先了解需求分析到底是一個怎么樣的過程才對，so，我終于來“補坑”惹。

一般來說，一個具體需求的分析的整體流程為：

確認需求->具體分析->交付設(shè)計／開發(fā)->驗收->上線

一、確認需求：［明確自己“有”了－>決定是不是要生下］

1、確認需求的本意

為什么會提這點呢？因為需求的來源會比較多，可能有以下來源：

1. 產(chǎn)品經(jīng)理自己；
2. 其他相關(guān)的產(chǎn)品經(jīng)理；（老板、你的leader等）
3. 其他相關(guān)的部門；（運營、銷售、廣告、編輯等）
4. 直接的用戶；

不同的來源，導(dǎo)致需求“被經(jīng)手”的程度不同，從而容易導(dǎo)致理解的意思不同。

①這種情況，不太會存在需求理解偏差，除非你當(dāng)時“精分”了。但是②③④就非常有可能理解錯誤、理解不到位、理解不深入。而造成②③④這種理解錯誤的原因，又有可能分成以下幾種：

a.對方在跟你表述需求的時候，直接表述了自己認為的解決方法，而跳過了表述真正的需求的階段；

這種情況下，如果你不多問幾個為什么，可能就被他給帶走，按照對方的解決方案做了。但實際上，最終多問幾個why的結(jié)果可能就是加一個字段的事情，而不多問的結(jié)果可能是新做一個功能；

b.對方在跟你表述需求的時候，自己都沒有清楚自己要干嘛；

這種情況下，還是多問幾個為什么，幫助他整理自己想怎么樣，為什么要這樣，最終發(fā)現(xiàn)他的真正需求或者說最終不需要做需求；

2、確認該需求是否有必要

原因可能出現(xiàn)在以下幾個地方：

①產(chǎn)品經(jīng)理自己YY需求或者僅從某一類用戶的角度考慮問題，具體在《你做“需求分析”，踩過這幾個坑嗎？》中提到過。這需要產(chǎn)品經(jīng)理自己進行慢慢糾正。

②其他人YY需求；

a.和產(chǎn)品經(jīng)理一樣，其他人也可能容易站在自己也是其中一種類型的用戶立場，或者自己對某個功能更專業(yè)的角度，去提絕大部分用戶不會用或者“太高級”的功能。

b.也有可能出現(xiàn)在以數(shù)據(jù)為導(dǎo)向的工作方上。舉個例子：同事A發(fā)現(xiàn)下載量特別差，可能就會認為是下載頁的整體文案/頁面風(fēng)格太不吸引人，可能就會希望能夠把下載頁進行重新調(diào)整。但實際上，可能并不是文案太差，而是下載按鈕并不明顯。

針對其他人的YY需求，產(chǎn)品經(jīng)理要會判別和求證。

3、確認該需求的優(yōu)先級

這個確實會涉及到該需求和其他需求之間的整體關(guān)系，這里不多說，以后再單獨寫一個需求與需求之間的優(yōu)先級管理。

但是舉個例子好了：假設(shè)乃們的產(chǎn)品規(guī)劃是先把主打的亮點部分給優(yōu)化好，再去做基礎(chǔ)性同類產(chǎn)品都有的功能?，F(xiàn)在有個需求是基礎(chǔ)性功能的優(yōu)化，那么就可以先排在后面，不著急做。

二、具體分析：［既然決定生，那就乖乖十月懷胎］

在第一階段中，已經(jīng)把很多“不合格”的需求給排除掉了，到了第二階段，就開始進入到需求的具體分析階段，該階段具體如下：

1、分析該需求的做法

①確認該需求影響到的范圍。

例如：同家公司的兩個產(chǎn)品可能共用某塊后臺功能，如果產(chǎn)品A因為需求而想要修改共用的那塊部分，那么就需要考慮到是否會影響產(chǎn)品B的數(shù)據(jù)獲取、信息展示等，之后的測試也都要帶上產(chǎn)品B。

②確認該需求的做法。

a.確認方案，主要是無爭議的相對最優(yōu)方案

例如：現(xiàn)在每個app都有節(jié)日時的特殊局部UI功能，這個功能如何做才能不需要上新版本就闊以靈活變更UI，這是需要確認的。當(dāng)然，你也可以說，我每需要更改局部UI的時候，我就上一個新版本。（簡單的需求要復(fù)雜做，那我也只能攤手）

b.兩種方案取優(yōu)，這區(qū)別于上述a的情況，而是兩種方案各有優(yōu)劣，針對不同需求不同情況可能會得到不同的結(jié)果

例如：同樣一個頁面，可以做app原生頁，也可以做內(nèi)嵌web頁，耗時、優(yōu)劣各有不同，需要根據(jù)具體的需求去做具體的選擇。

不同方法會導(dǎo)致需要不同的資源、人力和配合程度，需要在確認做法階段想清楚，以盡可能避免浪費、返工的情況。

2、分析該需求的業(yè)務(wù)流程、邏輯判斷

這個考驗產(chǎn)品經(jīng)理對業(yè)務(wù)的理解、邏輯思考的能力以及細心程度。這個在《你做“需求分析”，踩過這幾個坑嗎？》中”具體的需求分析階段“中進行過一部分的反向描述，啊哈。

①梳理業(yè)務(wù)流程：主要是用來確認涉及到的角色類型、角色的屬性、角色的動作、角色之間的關(guān)系。

舉個例子就好了：“發(fā)文章并展示”這個需求，至少存在幾種不同的流程：（不做好壞評價）

a.用戶發(fā)布文章后，都需要該網(wǎng)站編輯進行審核、格式整理，配上封面圖再發(fā)布到主頁內(nèi)容流（所謂的精選）以及細分分類頻道，例如人人都是產(chǎn)品經(jīng)理；

b.用戶發(fā)布文章后，可以直接顯示在某個細分分類頻道中，但是如果要發(fā)布到主頁內(nèi)容流（所謂的精選），需要該網(wǎng)站編輯審核，但不會幫你進行格式整理，會進行封面配圖，例如人人都是產(chǎn)品經(jīng)理；

c.用戶發(fā)布文章后，需要投稿到某個頻道（精選也是分類的一種），還需要對應(yīng)頻道管理員審核，也不會幫你進行格式整理，也沒有封面配圖，通過后顯示在該頻道中，例如簡書；

②確定流程中的邏輯判斷

確定了業(yè)務(wù)流程之后，根據(jù)流程列出過程中的判斷邏輯判斷條件以及邊界條件。延續(xù)上面的“發(fā)文章并展示”中b的情況：

a.審核通過的標準是什么：每個編輯大人自己定義？還是編輯團隊有統(tǒng)一規(guī)則？還是依靠瀏覽量、點贊量、收藏量這種相對客觀數(shù)據(jù)；是單一因素影響還是多因素綜合影響，綜合的話是否有分別的不同影響權(quán)重…

b.審核后是否會導(dǎo)致文章狀態(tài)不同？

c.審核后如何展示：展示在哪里、如何排序；

…..

3、根據(jù)具體分析的結(jié)果畫原型圖

原型圖主要是用來：

1. 讓猿猿們更直觀了解需求；
2. 設(shè)計師大人更加直觀了解需求，同時了解頁面需要表現(xiàn)的內(nèi)容以及重要性程度；
3. 讓所有相關(guān)的人們都根準備預(yù)估工時；

那么根據(jù)原型圖的作用，在制作原型圖的時候，就要明確：

1. 頁面上展示的內(nèi)容框架；
2. 內(nèi)容的優(yōu)先級；

另外，強烈建議未確定前都畫手稿，最終確定不改之后，再畫電子稿，具體原因可查看《做“需求分析”，有木有踩過這幾個坑？》中的“制作原型圖階段”

三、交付設(shè)計／開發(fā)：［既然帶到了這個世界，一定要做個三觀正的蕩蕩少年］

準備好需求分析的前提下，盡可能早的和設(shè)計大大溝通。準備好需求分析＋原型圖的前提下，闊以跟程序猿GG們溝通惹。

把需求分析和原型稿交付給設(shè)計師，并且明確以下內(nèi)容：

1. 設(shè)計大大了解細致的需求是啥；
2. 設(shè)計大大了解頁面上需要的內(nèi)容以及重要性差別；
3. 設(shè)計大大了解你想要的感覺是啥（一般來說，大大都有自己的想法）；

把需求分析和原型稿交付給程序猿GG們，并且明確：

1. GG們了解細致的需求是啥；
2. GG們了解需求的業(yè)務(wù)流程、邏輯關(guān)系以及邊界條件等；
3. GG們了解做這個需求需要哪些方面的支持（是否需要后端、是否需要第三合作方等等）；

四、驗收：［三觀不正？你不好，快去掰回來］

承接第三點，分別進行以下的驗收：

1、驗收設(shè)計大大的設(shè)計稿

如果有不合適的地方，盡快進行修改，盡量在程序猿GG們沒寫頁面之前修改完畢再交付給開發(fā)，避免開發(fā)不斷的跟著設(shè)計稿改而改。

（我有罪！猿猿們請原諒我！）

2、驗收需求

程序猿GG們開發(fā)完需求之后，先由測試大人進行功能測試驗收，然后修bug，再驗收，再修二次bug等。如果這個版本的需求都開發(fā)完成，那么產(chǎn)品汪們就需要進行驗收，盡可能早的進行第一次驗收，這樣出現(xiàn)業(yè)務(wù)相關(guān)的bug就比較容易被發(fā)現(xiàn)。

不要到最后時刻才做驗收！不要到最后時刻才做驗收！不要到最后時刻才做驗收！

五、上線［ 既然該獨立，就去放縱不羈愛自由吧］

需求上線后，理論上從本期的功能層面上來說就完成使命鳥～

but，如果有以下情況的話，產(chǎn)品狗你給我回來，不要跑：

1、該需求被拆分成了n次實現(xiàn)。

有些需求可能第一版本先上個簡單的，之后再繼續(xù)去做優(yōu)化，那么這個就需要被跟進數(shù)據(jù)，再去決定要不要去做優(yōu)化；

2、該需求是“測試性需求”。

有些需求，一開始就是為了測試用戶反應(yīng)，那么同樣需要被跟進具體的數(shù)據(jù)情況，再去決定要不要取消這個需求或者要不要繼續(xù)升級這個需求；

至于需求上線之后的運營的事兒，就不在本文討論范圍啦～如果有遺漏或者描述的不對的地方，請指正喲～

#專欄作家#

killifer，微信公眾號：killifer。華爾街見聞產(chǎn)品經(jīng)理，人人都是產(chǎn)品經(jīng)理專欄作家。腦洞大、笑點低、間歇性“有毛病”的理工科實力逗比少女。

本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，不得轉(zhuǎn)載。