Round 1

產品：開發個富文本編輯器，讓用戶能自由發言！

開發：滾！

Round 2

產品：在下有一個需求不知當提不當提...

開發：在下有一句MMP不知當講不當講...

Round 3

產品：……需求就是這個樣子

開發：做不了

產品汪最寂寞的事，就是需求評審會變成技術討論會；產品汪最悲催的事，莫過于需求評審會開到最后開成了需求被砍會，不是技術實現不了了，就是性價比太低。砍來砍去，只剩下幾個簡單的小需求。本是同根生，相煎何太急啊，一周做辣么點需求，真的能寫滿周報嗎？？你們的良心不會痛嗎？？

額，與其譴責程序猿的良心（還有這種東西？），倒不如自己搞清楚正確的提需求姿勢！老K根據自己多年的提需求經驗（被砍過的需求連起來能繞地球一圈兒），經過長達半個月的總結（是的，我之所以半個月沒更新不是懶，是在總結），終于寫出了這本葵花寶典之正確的提需求姿勢——不用自宮也能練！

如果你不知道什么叫瞎B提需求，請參考有哪些PM認為很簡單，卻讓開發懵逼的功能？

所謂需求，就是滿足用戶的需求所要做的功能。由于產品汪們一直自詡是代表用戶，站在用戶的立場說話，所以通常叫做“需求”。好的需求會有明確的目的，要么是滿足用戶的某種需求，要么是實現公司的某種目的。這個目的，不只是需求的出發點，也是方向。當有圍繞需求展開的細節難以確認是，都可以以目的為導向，做出判斷。

在需求評審會上，開發問為什么做這個需求，如果你能結合用戶需求以及公司目的闡述充分的理由，需求被砍的幾率就會大大降低。

這個比較容易理解，所有的需求都可以按照緊急度、重要度來排序。通常需要一個需求池來管理所有需求。

接下來就是簡單的套路了：比如某期版本迭代要做需求A/B/C,老K通常會排上A/B/C/D4個需求，然后在需求評審會上忍痛（敲黑板，跟我念：忍痛！）放棄需求D，讓程序猿們開開心心的去做ABC，最后在心中默念：笑年郎，還是圖樣啊。

最后這點，能看出一個產品經理是否專業。比如一個比較簡單的注冊登錄功能，非專業的產品經理可能就畫三五張界面圖扔給開發了，這就是不完整的需求。看似簡單的注冊登錄功能，稍微想想，其實很復雜：是否支持第三方登錄？是否必須要手機號注冊？手機號規則判定、過程中斷網的各種提示以及跳轉、不同入口進入登錄或注冊的出口是否不同？等等...

一個完整的需求，最基礎也要具備：流程圖、原型圖和文字注釋。最完美的效果是，給程序猿講過一遍需求之后，他們在開發過程中再也無需問你，所有的疑問都能從需求文檔中得到解答。要達到這種境界，單純聽老K在這BB是不可能的，需要各位在工作中不斷地總結、優化以及迭代。

常言道：懂得了很多道理卻依舊過不好這一生。學習了很多拳法，實戰中不依舊是王八拳？讀完老K的文章，了解了正確的提需求姿勢，真正運用起來了，其實并不見得每次都有效。

想要立竿見影，那就得使出絕招：真正的正確的提需求姿勢：

-end

關注公眾號：產品經理日記（ID：p_m_diary）回復“PRD”，獲取鵝廠內部需求文檔模板！