想知道怎樣做方案才不會被技術吐槽？看看這篇文章就知道了。本篇文章適合0-2歲的產品經理，如果你是大神可以飄過吧！不是說本篇文章沒有價值，而是大神已經形成了做方案的標準。
在做產品方案前，首先得想清楚本次方案的目的是什麼，方案中要解決什麼問題，本次方案的價值是什麼。想清楚了這幾個問題然後才開始做。
文章中列舉的方案是用Axure做的，如果不會Axure的請先去學會在來看。
1.文檔說明
首先，方案分為2部分，左側為導航欄，右邊為內容區域：
導航欄中分為【文檔說明】，【產品說明】，【微信端】。文檔說明：記錄產品方案的迭代信息，和修改記錄。產品每迭代一次，產生一條記錄。修改記錄為產品在開發中，方案有修改時，記錄修改信息，方便技術人員查看。產品說明：主要說明當前版本的目的與價值，以及全局的一些規則，業務流程信息。微信端：主要是指前端，因為為們所做的產品都是基於微信生態。
在寫版本迭代記錄時，記錄下更新時間，版本號，作者，備註（版本主要內容）關鍵參數即可。
需要注意的是，左側導航欄的層級最好不要超過4個層級，如果超過了4個層級，產品經理就需要調整一下結構。且需要在每一個頁面打上編號（1,2,3）,這樣可以方便在做方案時，需要點擊一個按鈕進行跳轉頁面時，就可指明編號。這麼做的目的都是為了技術看方案時更加輕鬆。
2.產品說明
項目說明：項目中需要寫明，“項目目的（方案目的）”，“版本價值”，“5W2H”，功能範圍（本方案設計到哪些功能模塊）。如果不知道5W2H是什麼的話，自行百度吧！
5w2h分析方法
功能範圍
全局規則：主要對項目中的一些數據規則，交互規則，邏輯規則進行說明。例如，執行網絡請求時，需要“loading”層提示數據正確加載中，點贊時，異步執行請求，先改變點贊按鈕顏色狀態等。 當然只需把規則描述清楚就可以了。
主業務流程：通過流程圖的形式把產品主線邏輯繪製出來，讓技術一看這個流程圖就知道怎麼做。在與技術的打交道中，發現技術看產品方案是不需要經過大腦的，說白了就是一根筋。所以需要把流程描述的很清楚，規則定義的很明確，這樣可以減少溝通成本，提高技術工種效率。
業務流程
3.移動端
移動端主要是產品原型了。 此處我拿出一個頁面進行距離。頁面左側為原型，右側為註釋。通過編號把原型與註釋一一對應。寫註釋時，修改，新增進行明確標註，有頁面跳轉的，用文字描述跳轉至“8.設置”頁面，並加上跳轉鏈接，點擊就可跳轉到指定頁面。在做方案時，原型可以low點，但是右側的註釋，規則描述一定要清晰明瞭。我平時在做方案時，動態交互基本都不會做，用註釋的形式描述清楚就可以了。有時候做了交互，技術不一定知道按鈕是可點擊的，也就會漏掉一些功能。且做交互對於產品經理來說太耗時了。 只要交付給技術一份清晰明瞭的方案即可。
移動端方案詳情
4.PC後臺
後臺也是一樣的，頁面左側為原型，右側為註釋。
後臺方案詳情
我想每個公司的會有一套做方案的標準吧！這就是我們公司做產品方案的標準，更適合敏捷開發，效率也很高。如果是對外的產品這樣肯定是不行的，至少原型是高保真的，還需要擼一份PRD出來，這樣的話層本也會更高。我想說的是做方案的方法沒有最好，適合公司的業務與技術的方案才是最好的。
總結：本文旨在描述如何做出一份清晰明瞭的方案，做出一份不會讓技術吐槽的方案。如有不足之處歡迎指正。
如果你覺得對你有幫助，請點擊頁面右上角“關注”。如果需要完整方案或PRD資料，請私信我獲取（僅作為學習參考）。
閱讀更多 達州人交流會 的文章
