需求改來改去,高手和菜鳥究竟有什么不同?
在產(chǎn)品和開發(fā)日常的工作中,需求改來改去是常有的事,但總有一些人能夠化解這種惱人的事,這就是高手。那么相比產(chǎn)品的菜鳥,高手究竟在哪些方面表現(xiàn)得更為突出呢?
最近開發(fā)吐槽說,很多的時候,能不能一開始想好了,需求不要改來改去的。
感覺每隔一段的時間,都需要配合改改改,這個真的非常浪費(fèi)效率。
我當(dāng)時立刻想起:
某次跟老板在屋子里面對需求文檔。
“哎呀,你這個寫得太復(fù)雜了,一開始不需要這么復(fù)雜的呀,這些這些,還有這些都砍掉?!?/p>
某次在會議室里面跟開發(fā)拆業(yè)務(wù)需求。
告訴開發(fā)同學(xué)們,這個地方,先務(wù)必使用這個結(jié)構(gòu),將來方便改,為后續(xù)的迭代留好可能性
而我們當(dāng)前的業(yè)務(wù)結(jié)構(gòu)不需要這么復(fù)雜。那個開發(fā)同學(xué)立刻說
“那你就跟我講這個版本要做什么就好了,為什么要跟我說那么多,我本來就事情非常多?!?/p>
有的時候被其他人催需求。
“一個案子為什么那么難寫,大方向不是會議上都訂好了么?你都想了這么久了,快點(diǎn)結(jié)束,然后把需求提過去,方便開發(fā)干活?!?/p>
工作中真的這種事情大量發(fā)生。
真想有的時候想懟回去,可是那樣還會引起什么別的東西;很多的時候真的是不想解釋,因?yàn)檎娴暮芾?;有那個解釋的時間,還不如自己悶頭做點(diǎn)有價值的事情。
吐槽當(dāng)然很爽了,但是本文的目的絕對不是吐槽,當(dāng)然得說說“如何看出一個人的專業(yè)度”。
需求文檔的水平,就決定了一個人在理解業(yè)務(wù)時候的專業(yè)度。
本文中心思想:
一開始就想明白,然后設(shè)計(jì)出框架感,以方便未來迭代。
相比:
想到一點(diǎn)是一點(diǎn),然后根據(jù)需求去添加迭代。
在專業(yè)上,根本就是兩個境界。
一、從兩個案例說起
舉兩個例子吧(不喜歡例子的可以跳過):
1. 游戲行業(yè)的禮包碼案例
我職業(yè)生涯里面寫得第一個需求是“禮包碼”的需求文檔。非常簡單,人人都見過。
用戶拿到一個幾位數(shù)的字符串,比如:da3f4ggu6u232f,然后進(jìn)入到游戲里面,找到一個兌換界面,輸入后點(diǎn)擊確認(rèn),驗(yàn)證通過后,即可拿到事先配置好的游戲道具禮包。
除去兌換成功外,還要考慮多少兌換失敗的反饋呢(反正很多的人只考慮正常情況,從來不考慮多少異常情況)?
禮包碼就只有一種用法么?
來看看,還有多少種業(yè)務(wù)場景:
- 發(fā)布會的場景,希望現(xiàn)場的5000個用戶使用一個禮包,用到5000就作廢,如何處理?
- 當(dāng)我們使用用戶召回行為的時候,是否可以限制注冊時間僅允許老用戶參與?
- 當(dāng)我們想給新用戶發(fā)福利的時候,是否可以限制注冊時間僅允許新用戶參與?
- 當(dāng)我們跟渠道通過游戲禮包換資源,是否可以做到僅僅A渠道參與,B渠道無法參與?
這僅僅是點(diǎn)擊兌換回復(fù)這一個小的點(diǎn),這個業(yè)務(wù)的復(fù)雜性,在運(yùn)營層面也許更多:
- 用戶需要輸入的禮包碼要不要區(qū)分大小寫?
- 要不要去掉數(shù)字1和0,字母L和O(為什么要去掉呢,用過的都懂吧)
- 用戶用手輸入的禮包碼的位數(shù)支持多少種排列組合?
- 如果禮包碼的位數(shù)過多,能不能想到一種方式不用手動填寫?
- 用戶拿到禮包碼之后,能不能準(zhǔn)確找到對應(yīng)的兌換入口?
- 禮包批次激活查詢,和客服的單個禮包的查詢后臺如何構(gòu)建業(yè)務(wù)查詢字段以及邏輯?
- 如果有人的禮包碼被盜異常丟失,被人掛在淘寶上賣,能不能把某個批次的禮包作廢掉?
……
后面的問題我還可以提出20多個。
2. 互聯(lián)網(wǎng)行業(yè)的優(yōu)惠券案例
這個業(yè)務(wù)更好理解了。
比如說我們在使用美團(tuán)的時候,經(jīng)常會收到各種各樣的優(yōu)惠券;在支付的時候,優(yōu)惠券會自動抵扣一些金額。
僅僅說創(chuàng)建階段,有多少可以設(shè)計(jì)的呢?
上面的圖片,僅僅是配置優(yōu)惠券的一個功能設(shè)計(jì)——怎么投放,怎么使用,怎么查詢,怎么管理,每個模塊都有不同的細(xì)節(jié)。
這兩個例子,做得好,被認(rèn)為是理所當(dāng)然;做的不好,業(yè)務(wù)能力需要拓展,就只能發(fā)起需求,改來改去咯。
想到一點(diǎn)點(diǎn)自然是非常簡單,但是每個業(yè)務(wù)上,實(shí)際的顆粒度,是需要考慮得非常細(xì)節(jié)的。
所以:
“一開始就想明白,然后設(shè)計(jì)出框架感,以方便未來迭代?!?/strong>
相比
“想到一點(diǎn)是一點(diǎn),然后根據(jù)需求去添加迭代?!?/strong>
在專業(yè)上,根本就是兩個境界。
二、但是,世界上識貨的人有多少呢?
如果識貨,需要我跟你費(fèi)力巴拉解釋么?
你要是懂,有些問題和話術(shù)就不會表達(dá)。
你一張嘴,我就知道你的業(yè)務(wù)段位。
此時此刻來看看本文開始的三段文字。
- “哎呀,你這個寫得太復(fù)雜了,一開始不需要這么復(fù)雜的呀,這些這些,還有這些都砍掉。”
- “那你就跟我講這個版本要做什么就好了,為什么要跟我說那么多,我本來就事情非常多。”
- “一個案子為什么那么難寫,大方向不是會議上都訂好了么?你都想了這么久了,快點(diǎn)結(jié)束,然后把需求提過去,方便開發(fā)干活?!?/li>
很多時候,產(chǎn)品們受迫于時間的壓力,被強(qiáng)行出那種粗糙的需求文檔給開發(fā)。
這種產(chǎn)品,可以拿互聯(lián)網(wǎng)的金句“快速迭代,小步快跑”來安慰自己,可以拿“MVP(最小化可實(shí)施方案)”來安慰自己——其實(shí)就是自己想得非常粗糙。
好了,祭出我的又一個發(fā)明的業(yè)務(wù)清單:
這張清單,方便各位團(tuán)隊(duì)管理者能夠看出自己是一個什么水平,能夠看出自己的團(tuán)隊(duì)是一個什么水平:
上面的這張表格,花費(fèi)的時間,真的非常多非常多,不過在開發(fā)的眼里,甚至在很多不識貨的老板眼里,或者在很多不明真相的吃瓜群眾眼里,甚至本質(zhì)上,整個開發(fā)團(tuán)隊(duì)的行為也還是:
第一周,某某功能,產(chǎn)品寫文檔,開發(fā)寫寫寫
第二周,還是某某功能,產(chǎn)品寫文檔,開發(fā)改改改
第三周,依舊還是某某功能,產(chǎn)品寫文檔,開發(fā)改改改
……
可能一個月過去了,也還是改來改去的。
上面的描述,真的僅僅是表象;但是在實(shí)際的業(yè)務(wù)中,產(chǎn)品的境界天差地別。
要知道:高手的改來改去和菜鳥的改來改去終究是不一樣的。
一個是事先聲明,全盤控制(有些拿不準(zhǔn)的,事先聲明自己拿不準(zhǔn)),但是上線后,可以通過數(shù)據(jù)論證,收集到足夠多的條件,最后做出修訂決策。
而另外一個人是在某些領(lǐng)導(dǎo)的壓力下,先交付一個版本再說,發(fā)現(xiàn)業(yè)務(wù)表現(xiàn)不行,然后慌不擇路,發(fā)出亡羊補(bǔ)牢式的需求迭代。
真正的了解到業(yè)務(wù)細(xì)節(jié),才能夠判斷出誰是高手,誰是菜鳥。
作者:飯大官人,微信公眾號:fanfan19860403,《游戲運(yùn)營:高手進(jìn)階之路》一書作者。熟悉AI-NLP-創(chuàng)業(yè)公司產(chǎn)品負(fù)責(zé)人
本文由 @飯大官人 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理,未經(jīng)許可,禁止轉(zhuǎn)載
題圖來自 Unsplash,基于 CC0 協(xié)議
最后那個產(chǎn)品水平的表格,值得深思 ??