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

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

然后等到需求評審的時候，面對技術(shù)爸爸們的各種疑問如坐針氈，發(fā)現(xiàn)又漏了好多的邏輯和細節(jié)，等到需求評審結(jié)束的時候，已經(jīng)被需求折磨的死去活來。

出現(xiàn)這樣的問題，一是因為剛開始做產(chǎn)品方案設(shè)計，基礎(chǔ)產(chǎn)品交互規(guī)范的熟練度不夠。還有就是急于完成任務(wù)，對于需求或功能的整個沒有思考的很明白，太過于專注方案以及功能本身的實現(xiàn)。

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

一、“看”競品

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

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

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

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

舉個簡單的例子：策劃登錄注冊功能，同樣的登錄注冊功能可能在不同的產(chǎn)品上具體實現(xiàn)的業(yè)務(wù)邏輯或流程都會有不同，注冊門檻的差異、注冊流程的不同、注冊信息的、登錄場景的不同等等，都跟具體產(chǎn)品的需求場景和特性有關(guān)。

二、理思路

做完競品調(diào)研后，就可以著手開始自己需求的策劃。在對業(yè)務(wù)邏輯以及功能流程有一個大概把握的前提下，再結(jié)合自己產(chǎn)品當(dāng)前的現(xiàn)狀以及實際場景從整體到局部開始進行（說到整體到局部的系統(tǒng)化思維，推薦一本很多人都看過的書《金字塔思維》）。

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

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

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

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

接上面的例子：關(guān)于登錄注冊模塊需求的實現(xiàn)，做完競品調(diào)研，根據(jù)自身產(chǎn)品特性可以確定功能模塊以及流程，比如內(nèi)容型產(chǎn)品，前期降低登錄門檻，可以直接使用第三方登錄，同時獲取用戶的基礎(chǔ)信息以及注冊賬號。

三、扣細節(jié)

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

交互設(shè)計以及需求文檔撰寫算是產(chǎn)品基本功，在框架流程完善的基礎(chǔ)上，再開始畫原型擼需求?？赡芎芏嗳俗铋_始做需求文檔的時候會糾結(jié)于用什么畫原型、原型要不要高保真、文檔的格式是怎么樣的？

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

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

需求文檔也是一個持續(xù)迭代優(yōu)化的過程，就實際經(jīng)驗來說，不可能一次性寫出一個完美的需求文檔，在需求推進的過程中，隨著需求評審、開發(fā)、測試，需要不斷的進行優(yōu)化調(diào)整，要做及時好變更記錄，快速的同步相關(guān)的同事，以免因為信息不同步導(dǎo)致功能出現(xiàn)誤差。

到這里你總算擼完了一套需求文檔，可以稍微松一口氣，開始進入進行需求PK環(huán)（撕逼環(huán)節(jié)），在撕逼和背鍋的路上開始狂奔。最后需求終于上線了，你想著可以松一口氣了，然而等著你的是更多的需求以及文檔……

作者：Ronie，個人微信公號：qinfengrec

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

題圖來自 unsplash ，基于 CC0 協(xié)議