愛盈利（aiyingli.com）移動互聯(lián)網(wǎng)最具影響力的盈利指導網(wǎng)站。定位于服務移動互聯(lián)網(wǎng)創(chuàng)業(yè)者，移動盈利指導。我們的目標是讓盈利目標清晰可見！降低門檻，讓缺乏經(jīng)驗、資金有限的個人和團隊獲得經(jīng)驗和機會，提高熱情，激發(fā)產(chǎn)品。
當老板提出了“一句話需求”時，作為PM的你是否懵逼過？面對這樣的需求該如何下手呢？
“一句話需求”也許大家多多少少都碰到過，通常就是老板/上司的一句話：“我想在產(chǎn)品上做一個XX功能，你來負責吧”，至于為什么要做？做了能給用戶帶來什么好處？怎么做？等這些問題，都需要產(chǎn)品經(jīng)理自己來消化，自己說服自己。
我所接觸過的需求源
在我的工作經(jīng)歷中，所負責與設計過的產(chǎn)品功能，其需求來源大可分為以下三類：
- 產(chǎn)品經(jīng)理/總監(jiān)，結合產(chǎn)品定位與用戶價值，自己所構想的產(chǎn)品需求。
- 其他部門所提出的需求，如運營部、運維部、財務部等。
- 老板或決策管理層，提出的需求。
對于1和2這類需求，大部分都是有明確且較詳細的“說明”的，產(chǎn)品經(jīng)理在思考“為什么要做？”和“怎么做？”這一過程是相對較短的，自己的需求肯定比誰都想的透徹，其他部門的需求，也肯定會有人來告訴你需求的描述。
對于第3種類型的需求，前不久剛好做過這類“一句話需求”，稍微復盤了一下，分享給大家。
準備工作
接到任務的時候，確確實實就是一句話“我們打算在產(chǎn)品上實現(xiàn)XXX功能，你來負責”，之后直到上線，都沒有再和老總溝通過關于“XXX功能”的事情。
然后我對即將要展開的工作，做了如下梳理：
對于程序員來講，改一個Bug所花的時間，80%在用來找原因，20%的時間才是敲代碼。
對于產(chǎn)品經(jīng)理來講，可能做一個功能所花的時間中，驗證功能可行性所耗費的時間絕對不低于50%，其中包括對產(chǎn)品/用戶價值、產(chǎn)品方向、實現(xiàn)方式、技術難度、業(yè)務匹配等的驗證，所以很多老PM們都建議新人們，別糾結于用Axure做交互，做效果，前面沒想好，做再炫酷的動效都等于零！
了解什么是XXX功能
- 公司為什么想做這個功能？
- 做了能滿足用戶/平臺的什么需求？
- 能為用戶/平臺解決什么問題？
這是我首先展開思考的三個問題，為什么要這樣做呢？ 因為在開始做之前，至少我要把自己說服，只有在我開始對這件事情感興趣以后，主觀能動性大于行政命令而產(chǎn)生的被動做事狀態(tài)，才能把它做好。
其次，在思考的過程中，也許能發(fā)現(xiàn)老總沒注意到的問題，如風險或更好的替代方案。
最后，是最基本的行為準則，作為產(chǎn)品經(jīng)理，對自己所負責的產(chǎn)品與功能，應該要做到在全公司，“沒有第二個人比自己更了解”的這種狀態(tài)與信心才行，無論誰來問你，需要你回答關于你負責的內(nèi)容，你都能講的面面俱到，否則被問到啞口無言，那給人的感覺就是不專業(yè)，不負責，沒想好。
設計方案
看似是一個步驟，但在這個階段耗時是最多的，可以再細分為如下步驟：
1.確定功能范圍
首先我要考慮的是，這個功能的使用范圍是怎樣的，抽象一點講就是從深度與寬度兩個層面考慮。
拿“我想做一個聊天功能”舉例，從“單對單”的聊天到“多對多”的聊天，從“文字聊天”到“語音、視頻”聊天…
同時還需要考慮到技術難度，開發(fā)周期，功能價值等因素，綜合來決定這個功能的開發(fā)范圍。
2.選取第三方服務商
這個步驟，并非所有功能都會有的，只是恰好本次功能需要使用第三方平臺。
因為行業(yè)的特殊性，導致在我們這個細分領域下的第三方平臺，都處于剛起步的狀態(tài)，有些公司甚至連開發(fā)文檔都沒寫好，就大膽的在官網(wǎng)上表示“我們已經(jīng)可以提供技術支持了！”這類含義的內(nèi)容。
因此需要詳細且深入的溝通，對接，以驗證對方是否有能力支持我們的產(chǎn)品，以及雙方的系統(tǒng)，是否能成功對接。如果市面上都沒有合適的服務商，來提供技術支持，那么這種非人為可改變的環(huán)境下，就不能開發(fā)公司希望的“XXX功能”。
3.驗證方案可行性
把以上做的事情，匯總為一份文檔后，初步形成一個“功能概念”文檔，在這里我的做法是，分別去找與該功能有聯(lián)系的部門，人員，一個接一個的溝通，有問題就立即修改，沒問題就換下一位，直到所有人員都私下過了一遍方案后，那么就可以召集這些人以及老板，一起來開需求評審會了。
在會議上，我會描述本次方案的內(nèi)容，因為在開會前，已經(jīng)分別找了關鍵人溝通，因此在需求評審會的時候，雜音會很少或幾乎沒有。因此開會的目的，實質上就是告訴大家，我們在某個版本，會正式啟動這一塊功能的開發(fā)，產(chǎn)品部會做什么，研發(fā)部需要準備什么，運營部需要準備什么…等等。
之前所做的，所有的工作的目的，都是為了低成本的試錯，這點很重要，只有明確、有價值、能實現(xiàn)的東西，才能讓公司調動資源投入。
產(chǎn)品設計
1.思維導圖
我使用思維導圖的目的，通常是記錄設計中的注意事項，包括某些邏輯、規(guī)則、方法的記錄，這個其實是因人而異，通常會畫一個產(chǎn)品信息架構吐，但對于我來講，這些內(nèi)容全在腦子里，而如果真的記不住的話，還是輸出一個產(chǎn)品信息架構圖好一些。
2.流程圖
產(chǎn)品流程圖應該是設計過程中，最重要的一個環(huán)節(jié)。
產(chǎn)品如果是一棵樹的話，那么流程圖就是主干，線框圖、原型圖只能算是豐富主干樹枝樹葉。
如果一張圖不能當前功能的業(yè)務邏輯，那就使用兩張圖，三張圖，對于流程不復雜的不需要更多商議的功能，我通產(chǎn)選擇直接在Axure搭配頁面遷移圖就做了，也能表現(xiàn)出功能流程。
3.線框圖
現(xiàn)在很多人把“線框圖”與“原型圖”的含義弄得有些混淆，我自己的定義是，前者為“低保證原型圖”，后者為“高保真原型圖”，高保真原型圖更多的目的在于，演示給客戶、投資人、老板..看，因為這些用戶希望看到一個最貼近產(chǎn)品的結果。
而我個人傾向于，對于演示給開發(fā)人員看，低保真的線框圖就完全足夠了，只要開發(fā)人員能最快理解產(chǎn)品經(jīng)理的意思就達到目的，且線框圖輸出速度快，試錯成本低。
一句話就能讓開發(fā)人員明白的事情，就完全沒必要畫1個小時去畫出來。
線框圖
以上，就是在我遇到“一句話需求”時的做事流程，以及處理方式，拋磚引玉，分享給大家。
本文由 @Palowlto 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉載。
題圖來自PEXELS，基于CC0協(xié)議
愛盈利-運營小咖秀 始終堅持研究分享移動互聯(lián)網(wǎng)App運營推廣經(jīng)驗、策略、全案、渠道等純干貨知識內(nèi)容；是廣大App運營從業(yè)者的知識啟蒙、成長指導、進階學習的集聚平臺；
【轉載說明】 若上述素材出現(xiàn)侵權，請及時聯(lián)系我們刪除及進行處理：[email protected]
