對崖瞭，這一期要說BUG，跟我讀“八-阿-哥”撑毛。
BUG的定義：本意是臭蟲书聚、缺陷、損壞藻雌、犯貧雌续、竊聽器、小蟲等意思】韬迹現(xiàn)在人們將在電腦系統(tǒng)或程序中驯杜，隱藏著的一些未被發(fā)現(xiàn)的缺陷或問題統(tǒng)稱為bug（漏洞）。
在實際的產(chǎn)品設計工作過程中做个，總會遇到大量的bug鸽心，有些可以解有些不能，不能的那部分很可能就流轉(zhuǎn)到了產(chǎn)品人員手中去評估叁温。
目前我們的流程是：
1. QA發(fā)現(xiàn)bug-》RD調(diào)研bug-》能解的bug解決了-》QA驗證是否修復完成再悼，未完成則打回。
2. QA發(fā)現(xiàn)bug-》RD調(diào)研bug-》不能解的bug進行多方評估（多方至少包含PD膝但、QA冲九、RD，如果和OP跟束、UE相關則要一起評估）-》評估下個版本修復特铝、推動外部修復還是影響不大直接降級埂软，如果又要修復、又有較多工作量（如超過了1人天會影響排期），則要看是否加班境蜕、延期等方式解決乳愉。
對于是否要修復掉房，從以下幾個點去判斷茫陆，數(shù)值可以自己摸索、調(diào)整：
1. 嚴重程度：崩潰逃延、內(nèi)容缺失览妖、功能不可用是最嚴重的，只要必現(xiàn)就一定修復揽祥；低概率復現(xiàn)且低頻率使用在灰度階段可放行讽膏，正式上線還是要修復；上線除非是不可修復拄丰，其他情況下還是要修復掉府树。
2. 復現(xiàn)概率：高復現(xiàn)概率的都是好bug俐末，能夠比較穩(wěn)定找到問題原因；穩(wěn)定復現(xiàn)則是高概率奄侠，不穩(wěn)定復現(xiàn)卓箫，如10%的復現(xiàn)概率以下，則是低概率遭铺。
3. 使用頻率：如果一個功能低于了1%用戶使用丽柿，可以認為是低頻使用的。如果是核心功能魂挂、本期主打功能，自動認定為高使用頻率馁筐。
通過這三點涂召，個人的判斷就成為（&&代表且、||代表或關系）：
1. 嚴重&&（高復現(xiàn)||高使用）敏沉，一定灰度前修復果正。
2. 嚴重&&低復現(xiàn)&&低使用，可灰度測試盟迟，正式上線前一定修復秋泳。
3. 不嚴重&&（高復現(xiàn)||高使用），灰度前修復攒菠。
4. 不嚴重&&低復現(xiàn)&&低使用迫皱，可盡量修復，無時間或者有外部依賴辖众，流轉(zhuǎn)版本或者降級不修復卓起。
簡單來說，嚴重的發(fā)版前一定修復凹炸，高復現(xiàn)或高使用的一定灰度前修復戏阅。我們的判斷應該是基于嚴重程度、戰(zhàn)略目標啤它、用戶影響面來進行的奕筐。
BUG與feature
實際的工作中，BUG和feature的界限其實沒那么清晰变骡，可以自己建立一套標準离赫。涉及到新的功能開發(fā)、之前需求文檔未能描述的部分锣光，都定義為feature笆怠，而BUG是之前按照文檔的預期應當如何卻未能如何。所以我們要求PD寫清楚分支邏輯后誊爹，與其他角色討論蹬刷，由QA完成test case的編寫瓢捉。
也可以唯心的說，PD在設計需求時候办成，在和RD泡态、QA溝通后未能考慮到的邏輯分支、視覺樣式迂卢，導致了嚴重的功能異常某弦，是屬于大家的經(jīng)驗不足，這種算bug而克；而需求設計時靶壮，PD和RD、QA溝通不足導致了功能異常员萍，需要增加更改腾降，則屬于PD的責任，這種需要新增加需求解決掉的碎绎，就是feature了螃壤。
比較常見的情況，更多是PD筋帖、UE的思考不足奸晴，在產(chǎn)品review的階段發(fā)現(xiàn)不符合預期，以bug的名義加了feature日麸，這種情況其實不利于團隊和諧寄啼。
出現(xiàn)了紕漏應該用于承認，并承認后果赘淮，自己挖的坑是要自己填上辕录，而非扔個bug就讓人家加班去改了，這是明顯在給自己減分的行為梢卸。由于PD自己的問題產(chǎn)生的需求變更走诞、feature增加，都應該主動承擔蛤高，找解決方案蚣旱，例如協(xié)調(diào)QA人力、延長排期或者加班解決戴陡，在不同階段的解決方式不同塞绿，開發(fā)前期協(xié)調(diào)即可，如果排期不死而工作量大就應該延長排期恤批，如果排期已經(jīng)明確只能陪伴跟隨解決异吻，請RD、QA吃雞翅跪舔吧。
