提需求的正確姿勢是什么?
開發(fā)大哥,我代碼寫的少,你可別騙我……
在論壇、知乎上經(jīng)??吹揭恍改贻p的」產(chǎn)品經(jīng)理發(fā)的引戰(zhàn)帖,大意是:「開發(fā)大哥,我代碼寫的少,你可別騙我,這么簡單的需求,明明一下午可以搞定,你跟我說一個星期?如果讓我來的話,巴拉巴拉巴拉…」。看到這種論調(diào),一些沒耐心的程序員就會一笑了之,甩下一句「You can you up,no can no bb」,或者「你這么屌,你咋不上天咧」之類的回復(fù)瀟灑走人,但是作為一名愛管閑事的程序員,我怎么能放過這個絕佳的「站在制高點上俯瞰眾生」的機會呢?
先來反駁一下這位「年輕的」產(chǎn)品經(jīng)理。寫代碼是一個典型的「紙上得來終覺淺,絕知此事要躬行」的事情,往往一些看似很簡單的需求,實際上會遇到很多坑。你看過「人在囧途」吧?一段很簡單的回家路,誰知道會有那么多的坎坷。就是這種感覺。
舉個例子,你要實現(xiàn)一個「視頻播放的時候,用戶可以設(shè)置屏幕亮度」的功能。實際上系統(tǒng)提供了「設(shè)置屏幕亮度」的程序接口,你只需要去調(diào)用就可以了,核心代碼可能就一兩行,夠簡單吧?但是,一運行你就會發(fā)現(xiàn)各種問題。如果用戶在我的APP里提高了屏幕亮度,退出之后要不要給人家還原呢?如果用戶只是暫時離開了我的APP,退出又回來,我是不是要給人恢復(fù)成原來設(shè)置的亮度呢?這些都是產(chǎn)品邏輯問題,你們溝通之后很快就解決了。但是后來測試發(fā)現(xiàn),「設(shè)置屏幕亮度」的接口是一個很耗時的接口,可能會造成整個APP的卡頓,這時候你就得考慮用多線程來解決。引入多線程之后,線程之間的資源共享問題如何解決,誰先誰后的問題如何解決,等等…
「年輕的」產(chǎn)品經(jīng)理不會想這么多,自己爽完提上褲子就跑了,留給程序員一堆爛攤子,程序員能開心的幫你干活嗎?還有就是,程序員寫代碼可不光是完成功能那么簡單,代碼寫的規(guī)范不規(guī)范,魯棒不魯棒,擴展性怎么樣,都是需要事先下功夫去設(shè)計的。我一開始寫代碼的時候,就喜歡那種實現(xiàn)一個功能的快感,迫不及待的要秀給別人看,后來體會到并不是那么回事。寫代碼就像談戀愛,一開始轟轟烈烈,海誓山盟,談的久了,你會發(fā)現(xiàn)往往一些簡單的小事,要完全負起責(zé)任,才是最難的。
說了這么多,就是想讓你理解程序員寫一行代碼,究竟要「熬過多少患難,濕了多少眼眶」。這是動之以情。接下來我們談?wù)勅绾握_的提需求,就是要曉之以理了。
提需求要有節(jié)奏感
不要誤會,這個節(jié)奏感不是啪啪啪的節(jié)奏感,而是說你提的需求,要跟著項目的版本周期走。一般一個不是太拖沓的互聯(lián)網(wǎng)產(chǎn)品,每個版本會經(jīng)過功能開發(fā)、單元測試、集成測試、beta驗證、上線幾個階段,我們分別來看一下。
功能開發(fā)階段,簡直是程序員的美好時光。下午懶散的陽光打在臉上,泡一杯濃香的卡布奇諾加一點點糖,戴上女朋友送的Beats大耳機循環(huán)一首輕音樂,手指在機械鍵盤上跳來跳去,噼里啪啦的,就像腦海中忽閃忽閃的靈感,根本停不下來,對對,就是這樣的感覺。
這期間程序員要么做產(chǎn)品經(jīng)理提的需求,要么悶頭做一些技術(shù)需求。這是產(chǎn)品經(jīng)理提需求的最佳時期,程序員剛剛結(jié)束了上一個版本緊張的發(fā)布期,急需要一些新鮮的需求來壓壓驚。技術(shù)需求是一些性能優(yōu)化、代碼重構(gòu)之類的事情,這個雖然是程序員自己給自己提的需求,但是你一定要給他時間去做,不然程序員每天總覺得自己寫的代碼亂糟糟的,沒有安全感。
單元測試是一個功能模塊的需求做完之后,提給測試同學(xué)去找bug。集成測試時所有模塊的需求都單元測試完成之后,整體來一輪測試。這時候程序員天天在改bug,你奇思妙想來一個新需求,他可能要象征性的反抗一下,但是大多數(shù)會乖乖去做。
到了beta和發(fā)布階段,大家都繃緊了神經(jīng),天天盯著用戶反饋和線上的各種指標(biāo)。這時候你突然被一塊石頭砸中,有了一個絕妙的需求,請hold一下,一定要hold住,因為你提任何需求都是會拉仇恨的。
先自己嘗試評估一下需求難度
這個就有一點技術(shù)含量了。有些需求天生是很難的,比如智能推薦、智能識別、搜索引擎這種,需要很強的技術(shù)能力。還有些需求,需要前后端聯(lián)調(diào),后端開接口,商量協(xié)議,這些時間算上去總時間要翻倍。除了這些,剩下的就是相對的了,取決于是否有現(xiàn)成的輪子。程序員常說,「不要重復(fù)發(fā)明輪子」,就是說如果有現(xiàn)成的代碼,就直接用不要自己再花時間寫了?,F(xiàn)成輪子可以來自開源社區(qū)、自己項目的積累、還有系統(tǒng)平臺提供的支持。如果某個需求有現(xiàn)成輪子可用,那它的難度應(yīng)該至少要減半。
你想知道開源社區(qū)都是有哪些輪子,可以平時多看一些別人整理的技術(shù)博客,你可能并不需要知道里面技術(shù)上是如何實現(xiàn)的,你只需要記下,這個功能是有輪子可以用的,就夠了。你想知道自己項目積累了哪些輪子,去問你們的開發(fā)吧,找他們抽支煙、吃個飯,很容易就套出來了。有些項目比較成熟,像推送、埋點上報、自動更新這些都有輪子可以用,但一些年輕的項目則不然,建立這一套東西也要花不少時間。你想知道系統(tǒng)平臺提供了哪些輪子,就買一本介紹你們產(chǎn)品平臺的技術(shù)書,比如《瘋狂Android講義》、《iOS Programming》,大體翻一下就行了,主要是了解一下這個平臺到底可以做哪些事情。
沒有輪子可以用的需求怎么評估呢?少俠,你眼光不錯哦,每天進來看看,你就知道答案啦。
下點功夫做準(zhǔn)備
這是個普遍的道理,你讓別人給你辦事,吩咐半天講不清楚,別人肯定不耐煩。如果你的需求是抄的別人的,可以拿別人做好的效果演示一下,這是最直接了當(dāng)?shù)?。你的需求是業(yè)界首創(chuàng)的,可以簡單畫個流程圖,如果這時候你能用上一兩個技術(shù)上的術(shù)語,程序員肯定覺得你碉堡了。需求講清楚了也要順便讓人理解為什么。這時候不要留情,把程序員帶到你的產(chǎn)品世界里,用你豐富的經(jīng)驗打敗他,他就會乖乖的跟你走了。
還有一點很重要,產(chǎn)品經(jīng)理要給開發(fā)協(xié)調(diào)一些其他資源,像設(shè)計、測試這些,如果能提前準(zhǔn)備好,那么即使是beta甚至上線階段加需求,程序員也會十分感動然后再拒絕你的。
最后忍不住吐個槽。有些產(chǎn)品經(jīng)理動不動就拉老大來給程序員施壓,我覺得這種是最low的,連文章開頭那些「年輕的」產(chǎn)品經(jīng)理,水平都比他們高到不知道哪里去了。就好比兩個小朋友打架,你打不過人家,喊的不是「放學(xué)你等著,有種操場見」,而是「我要告老師,看他怎么收拾你」。哎我說,不要慫啊親。
PS:以上建議只是我自己的胡思亂想,是一家之言。你千萬別有「快來看啊,這家伙又在裝逼教我們做人啦」這樣的想法。如果你覺得我傷害了你,我希望你分享出去讓更多人受到傷害。如果你覺得我說的好像是那么回事兒,我也希望你分享出去讓更多人來聽我叨逼叨。
#專欄作家#
給產(chǎn)品經(jīng)理講技術(shù),微信公眾號(pm_teacher),人人都是產(chǎn)品經(jīng)理專欄作家。資深程序猿,專注客戶端開發(fā)若干年,對前端、后臺技術(shù)略懂,熱衷于對新的科技領(lǐng)域的探索。
本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載。
題圖來自PEXELS,基于CC0協(xié)議
冒昧問一下,您是《給產(chǎn)品經(jīng)理講技術(shù)》這本書的作者之一嗎?您發(fā)的這篇文章很熟悉,好像在這本書里見過
自己想辦法來做我的隊友,太喜歡如此幽默感十足的程序猿了
哈哈哈
哈哈 你寫的文章很有意思 身為一個「年輕的」產(chǎn)品經(jīng)理受教了
666666
程序員也會十分感動然后再拒絕你的。哈哈哈哈好喜歡筆者的文風(fēng) ??
做產(chǎn)品先學(xué)開發(fā) 要不深入困難
受用了!順別。。。催更→_→ 果果你公眾號好久不更新了
那對于那種比較懶的開發(fā)怎么辦?無論什么時候提,提什么他永遠不想做。 ??
心碎點贊 ??
用你的愛感化他,加油 ??
哈哈哈 說的很贊