本文筆者梳理拆解了自己的產品策劃流程，並給出了自己對各流程的思考，希望能夠給你帶來一定的啟發。

記得剛開始做產品出需求方案的時候，上來就開始畫原型寫文檔，在寫的過程中發現某個交互沒想明白或者漏了一部分邏輯，然後回過頭來再修改或者補漏，這樣前前後後折騰好長時間，終於做完了一份完整的方案，等重新檢查的時候，發現又漏了某個地方流程有問題，於是又改，反覆折騰之後終於完成了初版。

然後等到需求評審的時候，面對技術爸爸們的各種疑問如坐針氈，發現又漏了好多的邏輯和細節，等到需求評審結束的時候，已經被需求折磨的死去活來。

出現這樣的問題，一是因為剛開始做產品方案設計，基礎產品交互規範的熟練度不夠。還有就是急於完成任務，對於需求或功能的整個沒有思考的很明白，太過於專註方案以及功能本身的實現。

後來做的需求多了（踩的坑多了），慢慢的修正自己過去在做產品方案的中一些問題，也跟身邊同事交流，整理了一套比較符合自己的產品設計流程，可能不適用所有的場景，是我目前用的比較多的一套流程。

一、“看”競品

說到看競品，很多人的第一反應是要抄么？我們一般剛開做需求方案的時候，常見的套路就是選幾個相關的競品或產品，對着某個功能抄一遍，然後形成自己最終的方案。

這時候我們的注意力還是方案或功能實現本身，並沒有深入的思考內在的邏輯以及背後的動機等等。就像上學的時候，交作業前拿過來同學的作業對着答案直接抄了上去，並不會再去想答案背後的演算流程。但是也有老師會說，同學們你們抄作業可以，但是你們一定要弄明白抄的答案為什麼是這樣。

看競品也是同樣的道理，在開始策劃一個需求方案的時候，我會找到競品功能或者相關的功能，深度的體驗相關的功能，弄明白整個功能的邏輯以及流程，體驗功能交互上手的感覺，對功能的效果有個初步的判斷。

同時要做好記錄，對於競品做的好的點以及關鍵點的實現邏輯做好收集記錄，然後對同一功能或模塊在不同平台的實現方式或者關鍵點的差異儘可能的收集資料，儘可能作出符合邏輯的思考和解釋。做完這一步對需求整體的實現邏輯以及流程有了初步的掌握，可以開始下一步。

舉個簡單的例子：策劃登錄註冊功能，同樣的登錄註冊功能可能在不同的產品上具體實現的業務邏輯或流程都會有不同，註冊門檻的差異、註冊流程的不同、註冊信息的、登錄場景的不同等等，都跟具體產品的需求場景和特性有關。

二、理思路

做完競品調研後，就可以着手開始自己需求的策劃。在對業務邏輯以及功能流程有一個大概把握的前提下，再結合自己產品當前的現狀以及實際場景從整體到局部開始進行（說到整體到局部的系統化思維，推薦一本很多人都看過的書《金字塔思維》）。

從需求背景、需求目的、功能流程、功能list、關聯需求等等，開始整體思路的梳理。功能list以及功能流程，在競品調研的基礎上是最容易出整體思路的模塊，也是產品功能設計本身，但是需要注意的是，產品功能本身只是需求策劃其中的一部分，不是需求全部。

我經常踩坑是，關注需求流程和實現本身，而忽略和需求相關聯的其他需求點和事項。比如，新的需求方案對於已有需求影響、新老版本兼容的問題、涉及的財務、運營等各個流程的變動問題、功能的推廣問題等等，以上都是需要根據需求的實際背景事先進行考慮以及規劃的。

還有經常被忽略的一點就是需求價值以及效果的衡量，我剛開始做產品經常有的問題就是埋頭於如何實現整個需求，對於需求的價值以及效果很少考慮，做了很多東西但是並沒有好好回顧其中的價值，對於工作的回顧和產品的認知是很不利的。

等梳理完框架以及流程之後就可以先跟boss或相關同事提前進行溝通，在大方向以及思路一致的情況下再開始擼需求文檔，如果在思路框架都沒有保持一致的情況下，就直接上手開始畫原型擼文檔，後面如果一旦思路或者框架需要調整，可以快速的進行修正。

接上面的例子：關於登錄註冊模塊需求的實現，做完競品調研，根據自身產品特性可以確定功能模塊以及流程，比如內容型產品，前期降低登錄門檻，可以直接使用第三方登錄，同時獲取用戶的基礎信息以及註冊賬號。

三、扣細節

框架流程有了，就可以開始第三步最終交互設計的完成和需求文檔的撰寫，在前面思路以及流程梳理清楚的基礎上，開始畫原型寫文檔，整個過程會相對順暢很多，避免走很多彎路。

交互設計以及需求文檔撰寫算是產品基本功，在框架流程完善的基礎上，再開始畫原型擼需求。可能很多人最開始做需求文檔的時候會糾結於用什麼畫原型、原型要不要高保真、文檔的格式是怎麼樣的？

在最開始擼需求文檔的時候，我也會糾結要用什麼原型工具，Axure用很多了，要不要嘗試一下墨刀？原型太丑了，是不是做的更好看一些？需求文檔應該怎麼輸出：直接在原型標註輸出還是輸出標準的文檔？也會網上搜各種類型的文檔進行借鑒模仿。

後來在不同的團隊輸出過各種樣式的需求文檔，不再糾結於原型以及文檔的格式。文檔只是用來承載你的思路和方案的載體，用來跟開發測試團隊溝通的媒介，還有很重要的一點就是留底（誰應該來背鍋）。至於輸出的格式以及文檔的風格，還是看團隊風格以及個人習慣，在符合團隊風格的基礎上，怎麼高效怎麼來。

需求文檔也是一個持續迭代優化的過程，就實際經驗來說，不可能一次性寫出一個完美的需求文檔，在需求推進的過程中，隨着需求評審、開發、測試，需要不斷的進行優化調整，要做及時好變更記錄，快速的同步相關的同事，以免因為信息不同步導致功能出現誤差。

到這裡你總算擼完了一套需求文檔，可以稍微鬆一口氣，開始進入進行需求PK環（撕逼環節），在撕逼和背鍋的路上開始狂奔。最後需求終於上線了，你想着可以鬆一口氣了，然而等着你的是更多的需求以及文檔……