關閉

產品經理必備技能——正確的提需求姿勢

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

Round 1

產品:開發個富文本編輯器,讓用戶能自由發言!

開發:滾!

Round 2

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

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

Round 3

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

開發:做不了

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


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


01
需求要有目的

  • 首先,確定你不是瞎B提需求

  • 然后,再確認一遍1

  • 最后,再確認一遍2

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

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

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

02
需求要有優先級

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

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

03
需求要完整

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

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

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

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

-end

4條評論 添加新討論

01月14日評論

學習到精髓了

回復
  1. 4天前評論 回復
2020年11月30日評論

被最后一張圖逗樂了:真就跪著提需求?

回復
  1. 4天前評論 回復
登錄后參與討論
Ctrl+Enter 發表