咖友提問：接到需求后，應該考慮哪些？思路是怎樣？

接到需求后，如果直接畫圖，就成了畫圖的了，應該如何考慮才能全面呢？生怕有遺漏的地方。

---

▍jory?環島 推車手

各人有各人的工作習慣，各個團隊之間也有各個團隊的配合習慣，就這個問題我覺得是沒有唯一性答案的，只有適用性答案的，適合你的才是最好的。

在這里分享一下我的工作流程，大家一起探討一下。

第一步，與需求方進行溝通，主要是復述你接收到的需求，確保需求接收正確沒有存在理解偏差。

第二步，我把它叫做清洗需求池，把接收到的需求進行清洗，分類出那些是已有替代功能完成了的，哪些是在之后的版本中有規劃的了，哪些是與公司戰略及產品目標不符合的需求，哪些是可以在這個版本加入的需求，同時評估需求的可行性、優先級、難易度。

第三步，將上述第二步的結果形成文檔，并提交需求方，最好是自己親自講解，獲取需求方的同意。

第四步，需求的具體分析，梳理邏輯關系，業務流程。

第五步，原型設計，輸出PRD

第六步，開原型評審會，與UI、RD一同溝通需求及PRD，對會上的東西進行及時的補充和改進。

第七步，跟進UI設計稿，確認設計稿

第八步，協助RD開發，開始編輯測試文檔（如果有測試，就協助測試完成，如果沒有，就自行完成）

第九步，測試，驗收產品

第十步，上線，交付產品

▍建君?味庫 產品經理

我個人最怕的就是拿到需求立刻就開始流程和原型設計的，不經過思考的產出都是對產品的不負責任。簡單描述我的工作流程：

1、需求確認

需求確認是非常重要的一個環節。這里的確認不是簡單的明確或者理解了需求方提出的需求，而是要深入挖掘到他需求背后真正的“訴求”是什么。因為很多時候需求方提需求都是拍腦袋提出的，或者經過了自己的一次轉化。

所以，我習慣讓需求提出方用最簡單粗暴的方式描述需求，不要經過修飾和轉換。

2、需求分析

當你了解到需求方真實的需求后，那么輪到你開始對這些需求進行分析了。這些需求的意義、對現有功能的影響、實現的成本、優先級等等。

最后產出一個需求的列表，來作為和需求方溝通的一個指導，最后確定需求。

3、需求轉化

確定了所有要做的需求后，才真正開始進入需求轉化的階段。畫場景圖、畫用例圖、畫流程圖、畫原型圖、寫PRD等等，都是為了把需求轉化成技術人員可讀可理解的內容。然后交付給技術部門去實現。

4、需求實現

這部分的工作更偏向“項目管理”的工作，目的就是確保開發的進度和方向沒有偏差，并正確的能夠滿足業務部門的需求。

前兩步“思考層”是我對產品經理們要求最高的地方，后面兩步“執行層”反而有制度和流程控制容易一些。所以，產品經理應該把更多的精力和投入放到前兩步。個人淺見，供參考。

▍寧白衣?有間道觀 觀主

說下我對問題的理解吧，lz應該問的是接到需求后，如何高效、優質的從“想”進入到“做”？

我總結了七步：

一、要做什么——確保你理解需求本身，無關對錯。

二、做給誰用——確保你理解假象用戶，無關對錯。

三、會有用嗎——自我辨證假想需求和用戶到對錯。

四、精確需求——根據辨證結果去完善或調整需求。

五、自我否定——否定已確認需求，考慮最壞結果。

六、確定思路——八字真言:“輕重緩急快慢益損”。

（輕重：產品結構上的輕重；緩急：需求層面優先級；快慢：開發耗時長短；益損：燒錢得體驗，還是損體驗拿錢。要學會去判斷這個功能對用戶的重要性，才能更好的去設計和定位。我不否定體驗和盈利共存，但是要賺錢，體驗必然會受損，摸錢出去時，心情總是差的。。。）

七：細化需求——根據確定的思路，細化成功能點。

至于說對行業摸底啊，了解市場這些的，不都是產品經理的日常修養嗎？

---

點擊?閱讀原文，即可收聽由喜馬拉雅電臺提供的精彩音頻。

總結

以上是生活随笔為你收集整理的接到需求之后，产品经理如何高效的从“想”到“做”？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。