大廠也Bug,產(chǎn)品經(jīng)理這么干,漂亮!
對(duì)程序員來說,最怕的就是出現(xiàn)bug,這也是產(chǎn)品經(jīng)理和程序員爭吵的最大原因。但很多程序員不愿意調(diào)整或者改變,這種情況下,產(chǎn)品經(jīng)理怎么做?這篇文章,作者給出了范本。
01 bug的產(chǎn)生
99.99%做開發(fā)的都會(huì)被問到或者被吐槽到:“你的程序怎么又出bug了!”
而此時(shí)只有開發(fā)自己明白:“老子犯的是高級(jí)錯(cuò)誤”。
但他又會(huì)覺得不好意思理直氣壯說出來。
最后只能在心中回蕩著海子的詩句:“你們一再嘲笑,須知,他跌倒在高于你們的上方?!?/p>
這種心理是有道理的。因?yàn)榇a的復(fù)雜度和產(chǎn)生bug的概率是成正比的,并且具有「邊際效用遞減」的效果。
這就意味著,做更多的驗(yàn)證帶來的收益會(huì)越來越小。
所以測試的責(zé)任重大。
我?guī)F(tuán)隊(duì)時(shí)候?qū)y試說:你們要有底氣,你們就是正義女神:一手天平,一手執(zhí)劍,蒙著眼睛保持內(nèi)心的公正。
那么怎么從根源降低bug?
表面看,bug出自程序員之手。但是這件事完整的步驟分為3步,就像蓋房子一樣,你一看就看出貓膩:
- 與產(chǎn)品經(jīng)理討論并確定功能(確定一個(gè)房子可以實(shí)現(xiàn)的設(shè)計(jì)圖紙)
- 將每個(gè)單獨(dú)的元件抽象出來(確定施工方案)
- 將相關(guān)的元件實(shí)現(xiàn)并進(jìn)行組合,完成建設(shè)(帶上材料開始施工)
我們?cè)賮碜屑?xì)看看這三步:第一步,“與產(chǎn)品經(jīng)理討論并確定功能”主要是溝通,靠“看”和“理解”。溝通是相互的,這鍋只讓程序員背的話的確太委屈了點(diǎn)。
除非你說產(chǎn)品經(jīng)理的PRD毫無破綻。
接下來更具體點(diǎn),來看一個(gè)小小例子:
PRD中我們說update,但是實(shí)際上開發(fā)是采用的刪除后insert。這時(shí)候,產(chǎn)品經(jīng)理會(huì)發(fā)現(xiàn)這條數(shù)據(jù)看起來是更新了,但是“創(chuàng)建時(shí)間”也變了。所以要防范,你起碼需要約定一下“更新時(shí)間”和“創(chuàng)建時(shí)間”的,避免開發(fā)的實(shí)現(xiàn)手法跑偏。
第二步,開發(fā)看prd,背后思考的是“將每個(gè)單獨(dú)的元件抽象出來”,這主要是一個(gè)人抽象能力的體現(xiàn)。
抽象是“透過現(xiàn)象看到本質(zhì)”的能力。隨著你對(duì)相關(guān)信息的掌握越多,這個(gè)能力會(huì)越強(qiáng),但永遠(yuǎn)不會(huì)真正達(dá)到100%。
所以,當(dāng)開發(fā)具備的信息沒那么多的時(shí)候,是不是就抽象的不是那么合理?
不合理雖然不會(huì)直接產(chǎn)生bug,但是會(huì)更容易產(chǎn)生bug。
——這就是為什么需求背景、場景窮舉那么重要。因?yàn)椤氨尘啊币馕吨皵U(kuò)展和兼容”,窮舉以為這“邏輯和判斷”。
精通一項(xiàng)能力的背后都是踩著無數(shù)的bug過來的。要么在來這個(gè)公司之前已經(jīng)踩過了,要么在這個(gè)公司里踩。因此,有經(jīng)驗(yàn)的薪資也比后者高。學(xué)費(fèi)教的不一樣。
在這個(gè)層面上,產(chǎn)品和開發(fā)是需要共同成長的。途徑就是復(fù)盤,每一次事故,都要做到“四不放過”,其中一條就是干系人得到成長。
期待不要掉進(jìn)同一個(gè)坑里兩次。
換一角度,如果過分苛求沒有bug,等于是在扼殺每個(gè)人成長的機(jī)會(huì),并且在透支未來的可能性。人會(huì)變得非常保守、不敢嘗試新事物。
第三步,“將相關(guān)的元件實(shí)現(xiàn)并進(jìn)行組合,完成建設(shè)”這就是實(shí)際的coding過程,而coding是一個(gè)主觀的,完全由人主觀掌控的事情。這就是為什么需要技術(shù)研討,專家論證。
因?yàn)檫B殺豬有人都是從屁股先下刀子的,同樣代碼的實(shí)現(xiàn)手法,不同老師教出來不同語言,加上后期自身修為不同,也不見得都能找到最佳實(shí)踐路徑。
比如下面視頻中的三類開發(fā):
02 開發(fā):你去看,知名大廠的代碼也爛
上月,公司招聘了兩個(gè)P6的后端開發(fā)。這個(gè)級(jí)別在團(tuán)隊(duì)里相當(dāng)“大熊貓”了。
然而一周后,倆人相繼離開:嫌原代碼太亂。
隨后,一個(gè)去了阿里,一個(gè)去了騰訊。
過一陣子再聊天,去騰訊的那個(gè)說:騰訊的代碼也沒好到哪里,巴拉巴拉。
雖然他這么說,但我們覺得那邊的代碼還是質(zhì)量高些,就像國外的月亮。
這個(gè)故事,拋開平臺(tái)優(yōu)劣之外,還顯示一個(gè)常態(tài):鐵打的代碼,流水的開發(fā),誰家的后廚都一樣。
即使ORCAL這樣的公司,也出現(xiàn)程序員吐槽:“我永遠(yuǎn)不會(huì)再為 Oracle 工作了 !”
一位昵稱“oraguy”的程序員對(duì)Oracle數(shù)據(jù)庫代碼的吐槽。大意是: Oracle 數(shù)據(jù)庫12.2版有近 2500萬行C代碼。
無法在不破壞成千上萬個(gè)現(xiàn)有測試的情況下更改單行代碼。
好幾代程序員在有限的期限內(nèi)編寫了這些代碼,其中充斥著大量的垃圾代碼。
非常復(fù)雜的邏輯、內(nèi)存管理、上下文切換等,這些都用數(shù)千個(gè)flag連接起來。
整個(gè)代碼充斥著神秘的宏命令,甚至可能需要一兩天才能真正理解某個(gè)宏命令的作用。
有時(shí)你需要理順20個(gè)不同flag的值和效果來預(yù)測代碼在不同情況下的行為方式,有時(shí)多達(dá)數(shù)百個(gè)flag!
這個(gè)產(chǎn)品仍然存活仍然可用的唯一原因是數(shù)百萬次的測試!
結(jié)尾是:開發(fā)一個(gè)小功能需要6個(gè)月到1年的時(shí)間(如果是添加一種新的身份驗(yàn)證模式,比如支持 AD 身份驗(yàn)證,可能需要2年)。
后端開發(fā)內(nèi)心的共識(shí)是:和一坨翔代碼共處的要領(lǐng)就是“千萬別深挖”。說不定把哪里挖塌了把你埋了。
扔一坨代碼到翔山上,達(dá)到自己目的,能跑就行了。后面的開發(fā)都是在上面修修補(bǔ)補(bǔ),最終就導(dǎo)致整體代碼慘不忍睹。
縱向,一個(gè)公司如此,橫向,其他公司也相似。走進(jìn)一個(gè)后端代碼森林,就開啟一場驚悚的適應(yīng)之旅。
曾有開發(fā)如是說:
- 入職3個(gè)月內(nèi),噴,這么大的系統(tǒng),上億pv的系統(tǒng)居然這么做的,這么做的,我提出那么做,那么做,你們都不鳥我,推翻我,哎你們都是傻逼。
- 入職半年,咦,好像他們說的有道理啊,如果按我那么做,就會(huì)出現(xiàn)那些問題,那些問題。。。
- 入職一年,哦,只能這么做,這么做,你一個(gè)新來的,知道個(gè)屁啊,還那么做那么做 。
- 入職兩年,噢,這么做,這么做有好處,有壞處,可以在此基礎(chǔ)上那么做那么做。
存在都是有道理的,所以要懂得后端開發(fā)的深沉,不是裝出來的!
后端開發(fā)的這種深沉的內(nèi)核,配以抽煙或嚼檳榔的外延,同時(shí)也會(huì)影響著產(chǎn)品經(jīng)理。
當(dāng)小鮮肉產(chǎn)品經(jīng)理還在炫耀酷炫交互、辯論用戶體驗(yàn)、說道人性靈感的時(shí)候,后端產(chǎn)品經(jīng)理在思考的是:兼容、業(yè)務(wù)、邏輯、架構(gòu)、性能……
羅振宇說的:“少廢話,只要一個(gè)界面和全世界交流,沒有機(jī)會(huì)解釋”。
說的完全正確,但是往往是就不適合后端產(chǎn)品的生態(tài)。
默默的,后端產(chǎn)品經(jīng)理和技術(shù)走的較近,心靈互動(dòng)的頻調(diào)也較協(xié)調(diào)。
雙方一起發(fā)現(xiàn)漏洞,規(guī)避風(fēng)險(xiǎn),這份默契油然而生。
產(chǎn)品經(jīng)理對(duì)代碼不能左右。為了團(tuán)隊(duì)不掉坑里、少做返工,避免整個(gè)產(chǎn)品或者團(tuán)隊(duì)翻船,就只能在需求的來源上做改善。
03 別把我的需求搞出bug
曾經(jīng)有開發(fā)調(diào)侃說:不能把代碼寫太完美,不然沒事做的時(shí)候就被開除了。
然而多慮了。從經(jīng)驗(yàn)來看,中后臺(tái)產(chǎn)品的需求是層出不窮的。
一個(gè)后端系統(tǒng)使用一年之后,需求就像河水,沖刷著產(chǎn)品經(jīng)理不得不做調(diào)整。
在產(chǎn)品的生命周期中,只要業(yè)務(wù)還在,減本增效的需求就在。系統(tǒng)就不會(huì)走到淘汰地步,只能是升級(jí)。
每當(dāng)我們通過抽象用戶故事、找出角色、事件,輸出用例圖、狀態(tài)機(jī)的時(shí)候,新的業(yè)務(wù)也在同步滋生。
況且一個(gè)功能本身,往往只是形成了業(yè)務(wù)的小場景的閉環(huán),是需求持續(xù)迭代。
持續(xù)迭代的具體原因舉例:
- 不確定性:需要繼續(xù)觀察積累用戶偏好。缺少用戶行為數(shù)據(jù)的支撐依據(jù),
- 分步完成:工期較長,以增量方式迭代;
- 方案沒想好:沒設(shè)計(jì)出來。
- 過度狀態(tài):用戶業(yè)務(wù)方式或場景不成熟
- 思路局限:沒考慮到。
- 集需求:集中起來一起搞個(gè)大動(dòng)作。
- 資源局限性:人員或硬件資源局限。
- 其他:略。
于是縱向、橫向都要繼續(xù)?!半S波逐流”亦或是“推波助瀾”,大量的需求源源不斷。
而產(chǎn)品經(jīng)理想要獨(dú)立自主地優(yōu)化架構(gòu)、統(tǒng)一功能等,在時(shí)間和資源都被擠占變少。
曾經(jīng)有公司的解決辦法,是加強(qiáng)需求的過來口徑。大致做法是:
- 凡是沒有收益的需求,一律不做,除非技術(shù)總監(jiān)拍板的(甩鍋);
- 有收益的需求,按收益大小排序,每周只做前5個(gè)。
- 成立項(xiàng)目組,進(jìn)行收益較大的需求的抽離和獨(dú)立完成。
其實(shí)本質(zhì)上就是抽出一部分資源,進(jìn)行自主優(yōu)化,統(tǒng)籌規(guī)劃和重構(gòu)。
重構(gòu)的好處是利在千秋,但是重構(gòu)的壓力來自瑣碎需求的羈絆。
當(dāng)資源、時(shí)間、質(zhì)量三者匯聚的時(shí)候,想辦法為高性價(jià)比項(xiàng)目爭取資源,決策就顯得尤其要緊。
為此,可將需求分為五類,分別對(duì)應(yīng)不同的決策態(tài)度。
04 鐵打的需求,流水的策略
這五類需求,是筆者對(duì)B端或泛后臺(tái)產(chǎn)品需求的一個(gè)定性劃分:淺薄需求、噱頭需求、踢球需求、過剩需求、建設(shè)性需求。
1. 用戶的淺薄需求
這類需求,不經(jīng)大腦,不考慮系統(tǒng)的兼容性和業(yè)務(wù)兼容性的。
比如:電商場景中,要求:若價(jià)格為0,則果斷給予下架;價(jià)格變?yōu)榉?,果斷自動(dòng)上架。
這種強(qiáng)制是存在風(fēng)向的,并且?guī)齑鏋?也有曝光對(duì)需求場景;非零也有下架的場景。二者不等同。
這種情況下實(shí)際是“概念偷換”的錯(cuò)謬,無庫存=下架。
對(duì)這類需求,產(chǎn)品可以持保留態(tài)度,持續(xù)觀望,收集更多用戶的深層次數(shù)據(jù)反饋。但不能輕舉妄動(dòng)。
2. 老板的噱頭需求
這種很好理解,很多公司其實(shí)都是這么玩沒的。
比如:看到友商(競爭對(duì)手)有的功能,我們要有;友商無的,我們也要有。這樣可以吹。
或者是強(qiáng)行“組合創(chuàng)新”:一個(gè)做醫(yī)藥電商的,你讓他做直播帶貨,且不說是否合規(guī),你能想象藥師在店里當(dāng)著店長的面做網(wǎng)紅嗎?
這種情況下實(shí)際是“感覺謬誤”。理論上,產(chǎn)品經(jīng)理需要拿數(shù)據(jù),試圖說服上級(jí),但是實(shí)際操作可能有局限性。
所以產(chǎn)品經(jīng)理能做的就是慢點(diǎn)做,保留資源。找機(jī)會(huì)慢慢把意見滲透到高層。試圖止損。
3. 隔壁的踢球需求
在多組織的團(tuán)隊(duì)中,這種踢來踢去丟需求的情況相當(dāng)普遍。
比如,對(duì)醫(yī)藥商品,配置一段免責(zé)聲明,展示在商城。
那么讓商品后臺(tái)在商品維度加字段并傳給前端,看似從后端到前端,且商品維度的,似乎沒錯(cuò)。但是沒必要的。
因?yàn)椋@是共性字段,商品維度幾乎不需要維護(hù),也沒有操作差異性。
這類需求,產(chǎn)品經(jīng)理需要從分工、系統(tǒng)職能、收益考慮,將事情客觀表述出來,完成博弈。
4. 客服的過剩需求
這類需求,往往是客服傳達(dá)來自用戶的需求。通常目的很明確,但是對(duì)功能設(shè)計(jì)進(jìn)行了干涉,可能影響產(chǎn)品的分析。
比如,客服傳達(dá)某O2O用戶的需求:要在商品的實(shí)際銷售價(jià)旁邊,展示線下零售價(jià)格。
產(chǎn)品:然后呢?
客服:對(duì)比到差異,則修改線上價(jià)?
產(chǎn)品:怎么修改?
客服:在線下零售價(jià)的基礎(chǔ)上按公式計(jì)算,比如上漲1%,得出線上零售價(jià),然后逐個(gè)編輯。
產(chǎn)品:是否可以理解為,目的是讓線上價(jià)格,按自己期望的賣,不取線下零售價(jià)?
客服:是
產(chǎn)品:那么為什么不在根源處理呢:創(chuàng)建一組用于線上銷售的價(jià)格,直接引用不就可以了嗎?
這類問題,一定是要挖掘到用戶的場景的,從用戶的場景下尋求同理心,不受制于現(xiàn)有功能的設(shè)定。
只有這樣才能不受局限,找到用戶的初心。以解決問題為標(biāo)準(zhǔn)。
5. 產(chǎn)品的建設(shè)需求
所謂建設(shè)性需求,可能是每個(gè)產(chǎn)品經(jīng)理心中都有的夙愿。前提是,產(chǎn)品經(jīng)理的腦子是正常的。
比如:自主優(yōu)化產(chǎn)品模型,拆分微服務(wù),界面統(tǒng)一等,統(tǒng)籌規(guī)劃和重構(gòu)的類的內(nèi)容。
若前四類需求過多,將會(huì)擠壓產(chǎn)品的建設(shè)性需求。
產(chǎn)品經(jīng)理能夠騰出手來做一些真正正確的事情,往往能對(duì)全局帶來增益。
05 小結(jié)
面對(duì)開發(fā)的困境、代碼的劣質(zhì)、用戶的迷霧、資源的協(xié)搭等,都需要產(chǎn)品經(jīng)理統(tǒng)籌策略,指路明燈。
多走一步,把滲透的交界處,融合到PRD中!
需要了解開發(fā)的動(dòng)向、意見,代碼的質(zhì)量漏洞、需求的來源、價(jià)值,緊迫性,老板的意圖,市場的玩法等等,都裝進(jìn)產(chǎn)品經(jīng)理的思維生態(tài)中。
恰如產(chǎn)品有體系,產(chǎn)業(yè)有生態(tài),產(chǎn)品經(jīng)理的世界,也是全生態(tài)化的。而不是點(diǎn)對(duì)點(diǎn)的甩手角色。
就像蘇杰說的,產(chǎn)品經(jīng)理要像“蕓香科”水果一樣,PRD也要支持多重兼容和任意雜交。
專欄作家
產(chǎn)品參趙,公眾號(hào):產(chǎn)品參趙,人人都是產(chǎn)品經(jīng)理專欄作家,2019年年度作者?!逗蠖水a(chǎn)品經(jīng)理寶典》作者,藥學(xué)碩士轉(zhuǎn)行互聯(lián)網(wǎng)產(chǎn)品多年;熟悉跨境電商業(yè)務(wù),醫(yī)藥領(lǐng)域;擅長大型后臺(tái)體系,社交APP。
本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理,未經(jīng)作者許可,禁止轉(zhuǎn)載
題圖來自Unsplash,基于CC0協(xié)議。
該文觀點(diǎn)僅代表作者本人,人人都是產(chǎn)品經(jīng)理平臺(tái)僅提供信息存儲(chǔ)空間服務(wù)。
寫的太好了,非常貼近我的工作哈哈哈