-
1 # 揚睿公關
-
2 # Z木本
Bug分誰寫的吧？要是自己寫的，肯定是甩不了了，除非辭職不幹。但是要是是別人寫的，第一時間轉給當事人。作為程式設計師，一般對自己寫的bug都沒啥脾氣，而且在改的時候還會偷偷自責為啥粗心大意吧。不知道別人咋樣，我就是這樣子的。
-
3 # 劉劉584
是自己的問題你跑不了，不是自己的可以協助查下原因。只有合作好，專案交付才順利，獎金才能到手。 如果遇到問題，只想著推卸責任，那你就沒有一點責任心，肯定不會被重用，甚至會被辭退。
-
4 # SunnyZhang的IT世界
Bug甩鍋要甩的合情合理，主要包括如下幾步：
1） 界定問題，首先要快速判斷是否是自己的問題，別烏龍了；
2） 如果不是自己的問題，寫出一二三來，然後找相關人員定位；
-
5 # 店小二精選
我覺得應該是這樣的，沒有一個軟體敢說自己沒有bug 有bug很正常，問題在於怎麼樣去對待bug,如果是的確是因為自己的專業技術或者粗心導致的，那就要敢於面對，這不僅是一種負責的體現，更是積累技術很好的機會，同樣的問題 或許下一次就不會再犯了。另外打鐵還需自身硬，持續學習，不斷提升自身競爭力，才是正確的姿勢。
-
6 # 夜伴小烏鴉
首先還是要定位bug原因再想辦法“甩鍋”，當然不管怎麼說，“甩鍋”這件事終究是極不講究的，所以，只是考慮到職場的相處之道，有時候不得得做出恰當的選擇。
⑴ 需求不明導致的bug需求分析是個非常講究個人能力與經驗的工作，需求分析工作的結果直接承接了使用者的原始需求，以及管理和開發團隊的後續工作。若是需求分析的任何環節出了問題，都會導致不同程度的問題，而且不只是bug那麼簡單。
⒈業務模型梳理有誤導致設計錯誤⒉使用者的期待分析有誤導致的誤會⒊客戶的約束考慮欠缺引發的異常⑵ 設計不利導致的bug軟體設計是指導開發和測試的關鍵環節，設計模式也直接影響著開發流程和管理模式。尤其是設計的細節，對編碼的指引異常關鍵，設計有錯，編碼必然會出問題。
⒈設計漏洞引發的編碼錯誤⒉設計冗餘導致的編碼冗餘⒊過度設計連累了編碼不足⑶ 合作不良導致的bug開發團隊往往會根據實際專案規模劃分為若干個子模組，或者若干個子團隊。程式設計師或者團隊之間由於溝通障礙、模組劃分有誤等原因，都會引發問題。
⒈溝通不良導致介面定義有誤⒉模組劃分不明導致邏輯遺漏⒊編碼能力不濟導致互相影響⑷ 測試不細導致的bug軟體測試往往是看守品質大關的最後一道屏障，若是需求方面梳理無誤，開發方面恪守流程，那麼，如果真的出現了流出到客戶的bug，那麼測試肯定無法獨善其身。
⒈測試分析漏掉了關鍵邏輯⒉測試設計疏漏了功能細節⒊測試執行疏忽了測試步驟但是，俗話說“一榮俱榮，一損俱損”，所以甩鍋是一回事，真正避免團隊再發生此類問題才是關鍵。
-
7 # 百小杜
個人做事個人當 甩鍋的想法不可取 我認為是自己的問題自己就要承擔 只有在不同的錯誤中改進自己才能讓自己更優秀 才能讓自己印象更深 甩鍋萬萬不可取
-
8 # 1116海岸線
我老公就是做程式的，目前是技術總監，他手底下的一女的，畢業不久，做出來的東西總是有很多bug，我老公經常要加班加點的幫她改，罵也罵了，教也教了，但是技術還是沒太長進，就是有一點好，無論我老公罵的多兇，事後都沒事，還罵哭過多次！
我老公說下次一定不招女程式設計師了，說女程式設計師做出來的東西思維邏輯還是不行。
反正沒有一天正常下過班！哎……我一人帶倆孩子，有時候真的感覺像喪偶式帶娃一樣！
-
9 # 這裡有顆樹cr
甩鍋？最多隻能往產品甩，其他方面的就不要想了。說得越多，還不如好好檢查程式碼質量，一個團隊裡誰的質量好，一對比就出了。
bug出來了，必然是存在問題，定責的時候當然得分清。然後就是修問題了，發現了問題迅速解決掉，在團隊中也是更容易得分的人。
不要忘了產出是團隊的，誰做得好誰做得不好，大家心裡都有數，所以出bug是太稀鬆不過的了，就看怎麼對待。
-
10 # 偷學攝影
重點一，看業務需求，確定是否是bug;
重點二，bug是獨立功能，還是和其他人聯調導致，如果是獨立，無可厚非，自己的坑自己填，如果是聯調導致，這個要具體看到底是誰的問題；
回覆列表
1、這個使用者有毒，換個使用者試試；
2、操作方法不對，換個測試員試試；
3、版本問題，換個新版本；
4、換個環境試試；
5、重啟試試
6、再不行換個姿勢試試。