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

01 bug的產生

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

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

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

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

這種心理是有道理的。因為代碼的復雜度和產生bug的概率是成正比的，并且具有「邊際效用遞減」的效果。

這就意味著，做更多的驗證帶來的收益會越來越小。

所以測試的責任重大。

我?guī)F隊時候對測試說:你們要有底氣，你們就是正義女神：一手天平，一手執(zhí)劍，蒙著眼睛保持內心的公正。

那么怎么從根源降低bug？

表面看，bug出自程序員之手。但是這件事完整的步驟分為3步，就像蓋房子一樣，你一看就看出貓膩:

1. 與產品經理討論并確定功能（確定一個房子可以實現的設計圖紙）
2. 將每個單獨的元件抽象出來（確定施工方案）
3. 將相關的元件實現并進行組合，完成建設（帶上材料開始施工）

我們再來仔細看看這三步：第一步，“與產品經理討論并確定功能”主要是溝通，靠“看”和“理解”。溝通是相互的，這鍋只讓程序員背的話的確太委屈了點。

除非你說產品經理的PRD毫無破綻。

接下來更具體點，來看一個小小例子：

PRD中我們說update，但是實際上開發(fā)是采用的刪除后insert。這時候，產品經理會發(fā)現這條數據看起來是更新了，但是“創(chuàng)建時間”也變了。所以要防范，你起碼需要約定一下“更新時間”和“創(chuàng)建時間”的，避免開發(fā)的實現手法跑偏。

第二步，開發(fā)看prd，背后思考的是“將每個單獨的元件抽象出來”，這主要是一個人抽象能力的體現。

抽象是“透過現象看到本質”的能力。隨著你對相關信息的掌握越多，這個能力會越強，但永遠不會真正達到100%。

所以，當開發(fā)具備的信息沒那么多的時候，是不是就抽象的不是那么合理？

不合理雖然不會直接產生bug，但是會更容易產生bug。

——這就是為什么需求背景、場景窮舉那么重要。因為“背景”意味著“擴展和兼容”，窮舉以為這“邏輯和判斷”。

精通一項能力的背后都是踩著無數的bug過來的。要么在來這個公司之前已經踩過了，要么在這個公司里踩。因此，有經驗的薪資也比后者高。學費教的不一樣。

在這個層面上，產品和開發(fā)是需要共同成長的。途徑就是復盤，每一次事故，都要做到“四不放過”，其中一條就是干系人得到成長。

期待不要掉進同一個坑里兩次。

換一角度，如果過分苛求沒有bug，等于是在扼殺每個人成長的機會，并且在透支未來的可能性。人會變得非常保守、不敢嘗試新事物。

第三步，“將相關的元件實現并進行組合，完成建設”這就是實際的coding過程，而coding是一個主觀的，完全由人主觀掌控的事情。這就是為什么需要技術研討，專家論證。

因為連殺豬有人都是從屁股先下刀子的，同樣代碼的實現手法，不同老師教出來不同語言，加上后期自身修為不同，也不見得都能找到最佳實踐路徑。

比如下面視頻中的三類開發(fā)：

02 開發(fā)：你去看，知名大廠的代碼也爛

上月，公司招聘了兩個P6的后端開發(fā)。這個級別在團隊里相當“大熊貓”了。

然而一周后，倆人相繼離開：嫌原代碼太亂。

隨后，一個去了阿里，一個去了騰訊。

過一陣子再聊天，去騰訊的那個說：騰訊的代碼也沒好到哪里，巴拉巴拉。

雖然他這么說，但我們覺得那邊的代碼還是質量高些，就像國外的月亮。

這個故事，拋開平臺優(yōu)劣之外，還顯示一個常態(tài)：鐵打的代碼，流水的開發(fā)，誰家的后廚都一樣。

即使ORCAL這樣的公司，也出現程序員吐槽：“我永遠不會再為 Oracle 工作了 ！”

一位昵稱“oraguy”的程序員對Oracle數據庫代碼的吐槽。大意是：

Oracle 數據庫12.2版有近 2500萬行C代碼。

無法在不破壞成千上萬個現有測試的情況下更改單行代碼。

好幾代程序員在有限的期限內編寫了這些代碼，其中充斥著大量的垃圾代碼。

非常復雜的邏輯、內存管理、上下文切換等，這些都用數千個flag連接起來。

整個代碼充斥著神秘的宏命令，甚至可能需要一兩天才能真正理解某個宏命令的作用。

有時你需要理順20個不同flag的值和效果來預測代碼在不同情況下的行為方式，有時多達數百個flag！

這個產品仍然存活仍然可用的唯一原因是數百萬次的測試！

結尾是：開發(fā)一個小功能需要6個月到1年的時間（如果是添加一種新的身份驗證模式，比如支持 AD 身份驗證，可能需要2年）。

后端開發(fā)內心的共識是：和一坨翔代碼共處的要領就是“千萬別深挖”。說不定把哪里挖塌了把你埋了。

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

縱向，一個公司如此，橫向，其他公司也相似。走進一個后端代碼森林，就開啟一場驚悚的適應之旅。

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

1. 入職3個月內，噴，這么大的系統，上億pv的系統居然這么做的，這么做的，我提出那么做，那么做，你們都不鳥我，推翻我，哎你們都是傻逼。
2. 入職半年，咦，好像他們說的有道理啊，如果按我那么做，就會出現那些問題，那些問題。。。
3. 入職一年，哦，只能這么做，這么做，你一個新來的，知道個屁啊，還那么做那么做 。
4. 入職兩年，噢，這么做，這么做有好處，有壞處，可以在此基礎上那么做那么做。

存在都是有道理的，所以要懂得后端開發(fā)的深沉，不是裝出來的！

后端開發(fā)的這種深沉的內核，配以抽煙或嚼檳榔的外延，同時也會影響著產品經理。

當小鮮肉產品經理還在炫耀酷炫交互、辯論用戶體驗、說道人性靈感的時候，后端產品經理在思考的是：兼容、業(yè)務、邏輯、架構、性能……

羅振宇說的：“少廢話，只要一個界面和全世界交流，沒有機會解釋”。

說的完全正確，但是往往是就不適合后端產品的生態(tài)。

默默的，后端產品經理和技術走的較近，心靈互動的頻調也較協調。

雙方一起發(fā)現漏洞，規(guī)避風險，這份默契油然而生。

產品經理對代碼不能左右。為了團隊不掉坑里、少做返工，避免整個產品或者團隊翻船，就只能在需求的來源上做改善。

03 別把我的需求搞出bug

曾經有開發(fā)調侃說：不能把代碼寫太完美，不然沒事做的時候就被開除了。

然而多慮了。從經驗來看，中后臺產品的需求是層出不窮的。

一個后端系統使用一年之后，需求就像河水，沖刷著產品經理不得不做調整。

在產品的生命周期中，只要業(yè)務還在，減本增效的需求就在。系統就不會走到淘汰地步，只能是升級。

每當我們通過抽象用戶故事、找出角色、事件，輸出用例圖、狀態(tài)機的時候，新的業(yè)務也在同步滋生。

況且一個功能本身，往往只是形成了業(yè)務的小場景的閉環(huán)，是需求持續(xù)迭代。

持續(xù)迭代的具體原因舉例：

• 不確定性：需要繼續(xù)觀察積累用戶偏好。缺少用戶行為數據的支撐依據，
• 分步完成：工期較長，以增量方式迭代；
• 方案沒想好：沒設計出來。
• 過度狀態(tài)：用戶業(yè)務方式或場景不成熟
• 思路局限：沒考慮到。
• 集需求：集中起來一起搞個大動作。
• 資源局限性：人員或硬件資源局限。
• 其他：略。

于是縱向、橫向都要繼續(xù)?！半S波逐流”亦或是“推波助瀾”，大量的需求源源不斷。

而產品經理想要獨立自主地優(yōu)化架構、統一功能等，在時間和資源都被擠占變少。

曾經有公司的解決辦法，是加強需求的過來口徑。大致做法是：

• 凡是沒有收益的需求，一律不做，除非技術總監(jiān)拍板的（甩鍋）；
• 有收益的需求，按收益大小排序，每周只做前5個。
• 成立項目組，進行收益較大的需求的抽離和獨立完成。

其實本質上就是抽出一部分資源，進行自主優(yōu)化，統籌規(guī)劃和重構。

重構的好處是利在千秋，但是重構的壓力來自瑣碎需求的羈絆。

當資源、時間、質量三者匯聚的時候，想辦法為高性價比項目爭取資源，決策就顯得尤其要緊。

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

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

這五類需求，是筆者對B端或泛后臺產品需求的一個定性劃分：淺薄需求、噱頭需求、踢球需求、過剩需求、建設性需求。

1. 用戶的淺薄需求

這類需求，不經大腦，不考慮系統的兼容性和業(yè)務兼容性的。

比如：電商場景中，要求：若價格為0，則果斷給予下架；價格變?yōu)榉?，果斷自動上架。

這種強制是存在風向的，并且?guī)齑鏋?也有曝光對需求場景；非零也有下架的場景。二者不等同。

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

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

2. 老板的噱頭需求

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

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

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

這種情況下實際是“感覺謬誤”。理論上，產品經理需要拿數據，試圖說服上級，但是實際操作可能有局限性。

所以產品經理能做的就是慢點做，保留資源。找機會慢慢把意見滲透到高層。試圖止損。

3. 隔壁的踢球需求

在多組織的團隊中，這種踢來踢去丟需求的情況相當普遍。

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

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

因為，這是共性字段，商品維度幾乎不需要維護，也沒有操作差異性。

這類需求，產品經理需要從分工、系統職能、收益考慮，將事情客觀表述出來，完成博弈。

4. 客服的過剩需求

這類需求，往往是客服傳達來自用戶的需求。通常目的很明確，但是對功能設計進行了干涉，可能影響產品的分析。

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

產品：然后呢？

客服：對比到差異，則修改線上價？

產品：怎么修改？

客服：在線下零售價的基礎上按公式計算，比如上漲1%，得出線上零售價，然后逐個編輯。

產品：是否可以理解為，目的是讓線上價格，按自己期望的賣，不取線下零售價？

客服：是

產品：那么為什么不在根源處理呢：創(chuàng)建一組用于線上銷售的價格，直接引用不就可以了嗎？

這類問題，一定是要挖掘到用戶的場景的，從用戶的場景下尋求同理心，不受制于現有功能的設定。

只有這樣才能不受局限，找到用戶的初心。以解決問題為標準。

5. 產品的建設需求

所謂建設性需求，可能是每個產品經理心中都有的夙愿。前提是，產品經理的腦子是正常的。

比如：自主優(yōu)化產品模型，拆分微服務，界面統一等，統籌規(guī)劃和重構的類的內容。

若前四類需求過多，將會擠壓產品的建設性需求。

產品經理能夠騰出手來做一些真正正確的事情，往往能對全局帶來增益。

05 小結

面對開發(fā)的困境、代碼的劣質、用戶的迷霧、資源的協搭等，都需要產品經理統籌策略，指路明燈。

多走一步，把滲透的交界處，融合到PRD中！

需要了解開發(fā)的動向、意見，代碼的質量漏洞、需求的來源、價值，緊迫性，老板的意圖，市場的玩法等等，都裝進產品經理的思維生態(tài)中。

恰如產品有體系，產業(yè)有生態(tài)，產品經理的世界，也是全生態(tài)化的。而不是點對點的甩手角色。

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