Bug在軟件工程中是不可避免的問題，所處環(huán)境存在一定程度職責(zé)界定不清晰的問題褐啡，稍不留神就從產(chǎn)品經(jīng)理變?yōu)楦鷅ug經(jīng)理了。

產(chǎn)品經(jīng)理跟bug的情形

產(chǎn)品經(jīng)理跟bug的問題在于，代碼不是產(chǎn)品經(jīng)理寫的停巷，產(chǎn)品經(jīng)理能做的是根據(jù)bug現(xiàn)象，如跟項(xiàng)目一樣跟進(jìn)bug解決榕栏，而定位問題跟進(jìn)bug畔勤，測(cè)試人員更專業(yè)。解bug本身并不能體現(xiàn)產(chǎn)品經(jīng)理的價(jià)值扒磁，產(chǎn)品經(jīng)理的價(jià)值更多體現(xiàn)在挖掘需求和輸出產(chǎn)品方案上庆揪，產(chǎn)品經(jīng)理也難以在跟bug過程中獲得產(chǎn)品感覺的提升。從專業(yè)性和職責(zé)定位兩方面來考慮妨托，產(chǎn)品經(jīng)理跟bug顯然是狗拿耗子缸榛。

從業(yè)半年多來检访，將產(chǎn)品經(jīng)理跟bug情形歸結(jié)為兩類：其一、bug影響用戶范圍較大仔掸，測(cè)試人員推動(dòng)不力脆贵；其二、公司上層政治需求起暮，容不得出bug卖氨，為加多一層保障，產(chǎn)品經(jīng)理跟bug负懦。

Bug爆發(fā)式增長

眾所周知筒捺，互聯(lián)網(wǎng)行業(yè)已經(jīng)從增量市場轉(zhuǎn)變?yōu)榇媪渴袌觯@取用戶的成本越來越高纸厉，如何留住用戶成為各個(gè)廠商最關(guān)心的問題系吭，推送對(duì)產(chǎn)品拉活和留存具有重大意義。

產(chǎn)品的推送模塊是樂帝負(fù)責(zé)的模塊之一颗品，但卻是最讓樂帝頭痛的模塊肯尺。為了提升推送達(dá)到率，產(chǎn)品接入了一些手機(jī)廠商提供的推送服務(wù)躯枢，第三方廠商一旦出問題则吟，就會(huì)出現(xiàn)溝通成本高、響應(yīng)不及時(shí)锄蹂、難以定位問題等一系列麻煩氓仲。同時(shí)為了公司內(nèi)部資源復(fù)用稚伍，推送服務(wù)作為通用服務(wù)蹲缠，提供給公司內(nèi)部多個(gè)部門使用，每個(gè)接入推送服務(wù)的產(chǎn)品幔荒，都需要負(fù)責(zé)接入和后續(xù)維護(hù)朝抖。負(fù)責(zé)推送服務(wù)服務(wù)端和客戶端的人員因?yàn)橄嗬^離職啥箭，半年以來已經(jīng)換到了第三波人，真是你方唱罷槽棍，我方登場捉蚤，好不熱鬧。

在推送服務(wù)復(fù)雜性高和人員流動(dòng)性高的情況下炼七，推送服務(wù)的bug終于集中爆發(fā)了缆巧。主要bug體現(xiàn)在以下方面：多個(gè)部門產(chǎn)品推送整體數(shù)據(jù)下降、部分用戶反饋推送過多豌拙、部分用戶反饋收不到推送陕悬、部分用戶反饋關(guān)掉推送開關(guān)仍收到推送、渠道反饋某渠道留存下降……樂帝作為推送業(yè)務(wù)的接口人按傅，從四面八方不斷接到推送服務(wù)bug捉超。

Bug的各個(gè)擊破策略

Bug的集中爆發(fā)一開始令樂帝有點(diǎn)懵逼胧卤。顯然這些bug已經(jīng)不是扔給測(cè)試人員提個(gè)bug就能解的問題。此時(shí)樂帝對(duì)bug采取了需求分析式的bug各個(gè)擊破策略：是不是推送問題拼岳、哪些問題不需要開發(fā)調(diào)整枝誊、哪些問題需要開發(fā)調(diào)整。

首先惜纸，解決了不是推送的問題叶撒。經(jīng)過分析對(duì)比某渠道留存半年下降數(shù)據(jù)和某手機(jī)廠商推送半年來總體趨勢(shì)，整體廠商推送數(shù)據(jù)穩(wěn)定耐版，而渠道留存卻一直降祠够。趨勢(shì)的不一致，至少可以得出結(jié)論粪牲，推送問題至少不是某渠道留存的主要導(dǎo)致因素古瓤。

其次，解決了不需要開發(fā)調(diào)整的推送問題腺阳。很多用戶集中反饋不知如何關(guān)掉推送落君，關(guān)推送的是實(shí)際問題的解決方案，這背后的動(dòng)因很可能是推送過多舌狗，對(duì)用戶造成了打擾叽奥。推送過多可能是兩個(gè)維度造成：推送總量過多、推送時(shí)間間隔過短痛侍。

通過定位部分用戶的推送歷史，發(fā)現(xiàn)自家產(chǎn)品魔市，在單日推送總量上基本與競品齊平主届。但發(fā)現(xiàn)每天某個(gè)時(shí)間段的半小時(shí)內(nèi)通常用戶會(huì)接到3條推送，基于數(shù)據(jù)分析基本能判定是推送時(shí)間間隔太短待德，打擾到了用戶君丁，導(dǎo)致用戶抱怨并希望關(guān)掉推送開關(guān)。拿著用戶反饋和數(shù)據(jù)這樣的鐵證将宪，去驅(qū)動(dòng)內(nèi)容發(fā)送方就順理成章了绘闷。對(duì)方調(diào)整后，用戶抱怨希望關(guān)掉push開關(guān)的問題基本沒有了较坛。

最后印蔗，解決那些問題需要開發(fā)調(diào)整的問題。在實(shí)際推動(dòng)解決需要開發(fā)調(diào)整的推送問題中丑勤，遇到了推不動(dòng)沒進(jìn)度的問題华嘹。分析推不動(dòng)原因主要在于，樂帝推動(dòng)的開發(fā)人員屬于最底層執(zhí)行的工程師法竞，底層執(zhí)行工程師與leader差異在于耙厚，底層工程師更著眼于執(zhí)行强挫，不善于從全局角度考慮與溝通表達(dá)問題；另外薛躬，由于其需求方來源較多俯渤，并不一定把推送bug問題排在較高的優(yōu)先級(jí)來處理。

針對(duì)以上分析型宝，樂帝從暴露問題和推動(dòng)問題方式方法上做了優(yōu)化調(diào)整八匠。

首先，以用戶反饋和相關(guān)數(shù)據(jù)變化作為推動(dòng)依據(jù)诡曙，將問題以郵件方式發(fā)送給執(zhí)行工程師的leader臀叙，并抄送相關(guān)領(lǐng)導(dǎo)。將問題影響范圍和嚴(yán)重程度暴露給對(duì)應(yīng)leader价卤，借其leader力來推動(dòng)工程師重視并解決問題劝萤。

其次，鑒于存在解決推送bug沒有進(jìn)度的問題慎璧，采取車輪戰(zhàn)的方式床嫌，將待解決問題進(jìn)行匯總，再加入目前進(jìn)展和下一步工作兩個(gè)維度胸私，將推送bug以項(xiàng)目日?qǐng)?bào)形式進(jìn)行發(fā)送厌处，將進(jìn)度的狀態(tài)進(jìn)行全方位的暴露，切實(shí)解決沒有進(jìn)度的問題岁疼。

后bug時(shí)代

采取以上各個(gè)擊破的策略阔涉，推送問題反饋明顯減少了。但同時(shí)鐵血推進(jìn)也著實(shí)給部分人員帶來了壓力捷绒。

后來領(lǐng)導(dǎo)跟樂帝表達(dá)了兩點(diǎn)：其一瑰排，bug問題非產(chǎn)品能推動(dòng)，推送bug日?qǐng)?bào)可暫停發(fā)送暖侨，產(chǎn)品關(guān)注點(diǎn)應(yīng)該放在方案上椭住；其二，bug需要確定影響范圍字逗，如果屬于疑難雜癥就沒必要占用開發(fā)精力京郑，投入產(chǎn)出比不太合理。

從領(lǐng)導(dǎo)和bug處理反饋來看葫掉，樂帝執(zhí)行的策略切實(shí)的解決了部分問題些举，也引起了上層領(lǐng)導(dǎo)關(guān)注與思考關(guān)于產(chǎn)品經(jīng)理跟bug合理性的問題。最初暴露問題和解決bug挖息，以穩(wěn)定推送模塊局面的初衷金拒，基本得以實(shí)現(xiàn)。

同時(shí)領(lǐng)導(dǎo)考慮問題的格局顯然更高，更多從資源投入產(chǎn)出是否合理角度來思考绪抛，也有助于樂帝精進(jìn)思考资铡。Bug出現(xiàn)的不確定性，決定了確定影響范圍較為困難幢码。但仍可以從用戶反饋和數(shù)據(jù)兩個(gè)維度來進(jìn)行界定笤休，比如用戶持續(xù)反饋，或數(shù)據(jù)有明顯影響症副，都可以定義為影響范圍大店雅，仍需要高優(yōu)先級(jí)處理。至于推送日?qǐng)?bào)還是需要發(fā)贞铣，只是沒必要天天發(fā)闹啦，可以每周發(fā)。

畢竟辕坝，產(chǎn)品經(jīng)理的精力窍奋，需要放在需求挖掘和產(chǎn)品方案上。

歡迎關(guān)注微信公眾號(hào)：產(chǎn)品經(jīng)理讀書會(huì)

關(guān)于產(chǎn)品經(jīng)理讀書會(huì)

專注于為愛讀書的產(chǎn)品人提供書籍推薦酱畅、讀書交流琳袄、以書會(huì)友的環(huán)境，歡迎愛讀書的產(chǎn)品人分享讀書感悟纺酸、找尋改變世界之路窖逗。