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