對程序員來說，最怕的就是出現(xiàn)bug，這也是產(chǎn)品經(jīng)理和程序員爭吵的最大原因。但很多程序員不愿意調(diào)整或者改變，這種情況下，產(chǎn)品經(jīng)理怎么做？這篇文章，作者給出了范本。

01 bug的產(chǎn)生

99.99%做開發(fā)的都會(huì)被問到或者被吐槽到：“你的程序怎么又出bug了！”

而此時(shí)只有開發(fā)自己明白：“老子犯的是高級錯(cuò)誤”。

但他又會(huì)覺得不好意思理直氣壯說出來。

最后只能在心中回蕩著海子的詩句：“你們一再嘲笑，須知，他跌倒在高于你們的上方。”

這種心理是有道理的。因?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步，就像蓋房子一樣，你一看就看出貓膩:

1. 與產(chǎn)品經(jīng)理討論并確定功能（確定一個(gè)房子可以實(shí)現(xiàn)的設(shè)計(jì)圖紙）
2. 將每個(gè)單獨(dú)的元件抽象出來（確定施工方案）
3. 將相關(guān)的元件實(shí)現(xiàn)并進(jìn)行組合，完成建設(shè)（帶上材料開始施工）

我們再來仔細(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ì)”的能力。隨著你對相關(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è)級別在團(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”的程序員對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)心的共識是：和一坨翔代碼共處的要領(lǐng)就是“千萬別深挖”。說不定把哪里挖塌了把你埋了。

扔一坨代碼到翔山上，達(dá)到自己目的，能跑就行了。后面的開發(fā)都是在上面修修補(bǔ)補(bǔ)，最終就導(dǎo)致整體代碼慘不忍睹。

縱向，一個(gè)公司如此，橫向，其他公司也相似。走進(jìn)一個(gè)后端代碼森林，就開啟一場驚悚的適應(yīng)之旅。

曾有開發(fā)如是說：

1. 入職3個(gè)月內(nèi)，噴，這么大的系統(tǒng)，上億pv的系統(tǒng)居然這么做的，這么做的，我提出那么做，那么做，你們都不鳥我，推翻我，哎你們都是傻逼。
2. 入職半年，咦，好像他們說的有道理啊，如果按我那么做，就會(huì)出現(xiàn)那些問題，那些問題。。。
3. 入職一年，哦，只能這么做，這么做，你一個(gè)新來的，知道個(gè)屁啊，還那么做那么做 。
4. 入職兩年，噢，這么做，這么做有好處，有壞處，可以在此基礎(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)理對代碼不能左右。為了團(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ì)走到淘汰地步，只能是升級。

每當(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ù)。“隨波逐流”亦或是“推波助瀾”，大量的需求源源不斷。

而產(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)目爭取資源，決策就顯得尤其要緊。

為此，可將需求分為五類，分別對應(yīng)不同的決策態(tài)度。

04 鐵打的需求，流水的策略

這五類需求，是筆者對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ī)齑鏋?也有曝光對需求場景；非零也有下架的場景。二者不等同。

這種情況下實(shí)際是“概念偷換”的錯(cuò)謬，無庫存=下架。

對這類需求，產(chǎn)品可以持保留態(tài)度，持續(xù)觀望，收集更多用戶的深層次數(shù)據(jù)反饋。但不能輕舉妄動(dòng)。

2. 老板的噱頭需求

這種很好理解，很多公司其實(shí)都是這么玩沒的。

比如：看到友商（競爭對手）有的功能，我們要有；友商無的，我們也要有。這樣可以吹。

或者是強(qiáng)行“組合創(chuàng)新”：一個(gè)做醫(yī)藥電商的，你讓他做直播帶貨，且不說是否合規(guī)，你能想象藥師在店里當(dāng)著店長的面做網(wǎng)紅嗎？

這種情況下實(shí)際是“感覺謬誤”。理論上，產(chǎn)品經(jīng)理需要拿數(shù)據(jù)，試圖說服上級，但是實(shí)際操作可能有局限性。

所以產(chǎn)品經(jīng)理能做的就是慢點(diǎn)做，保留資源。找機(jī)會(huì)慢慢把意見滲透到高層。試圖止損。

3. 隔壁的踢球需求

在多組織的團(tuán)隊(duì)中，這種踢來踢去丟需求的情況相當(dāng)普遍。

比如，對醫(yī)藥商品，配置一段免責(zé)聲明，展示在商城。

那么讓商品后臺(tái)在商品維度加字段并傳給前端，看似從后端到前端，且商品維度的，似乎沒錯(cuò)。但是沒必要的。

因?yàn)?，這是共性字段，商品維度幾乎不需要維護(hù)，也沒有操作差異性。

這類需求，產(chǎn)品經(jīng)理需要從分工、系統(tǒng)職能、收益考慮，將事情客觀表述出來，完成博弈。

4. 客服的過剩需求

這類需求，往往是客服傳達(dá)來自用戶的需求。通常目的很明確，但是對功能設(shè)計(jì)進(jìn)行了干涉，可能影響產(chǎn)品的分析。

比如，客服傳達(dá)某O2O用戶的需求：要在商品的實(shí)際銷售價(jià)旁邊，展示線下零售價(jià)格。

產(chǎn)品：然后呢？

客服：對比到差異，則修改線上價(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)理能夠騰出手來做一些真正正確的事情，往往能對全局帶來增益。

05 小結(jié)

面對開發(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)對點(diǎn)的甩手角色。

就像蘇杰說的，產(chǎn)品經(jīng)理要像“蕓香科”水果一樣，PRD也要支持多重兼容和任意雜交。