Re: [心得] 我在科技業遇到的鬼故事之一

看板Soft_Job作者 (NickLin)時間9月前 (2023/07/27 11:15), 編輯推噓25(27推 2噓 48→)
留言77則, 23人參與, 9月前最新討論串8/17 (看更多)
再回一篇，先說我不是B但是這個細節出了更明顯不是B的問題了啊 這個Bug本來就是一個corner case只是好巧不巧在B開發的時候遇到一次，要是今天B剛好 就沒遇到這個Bug，你們還不是一樣照常Release，客戶一樣爆掉，這樣B不就剛好衰幫你 發現Bug而已？ 你硬要說B的態度有問題，他也只是表達出他遇過且在你們根本沒修的情況本來就很可能 再發生，很明顯原Po這組原本想甩鍋讓B一起揹，B可能只是無言搞你搞回去而已 B的視角比較像：你今天底層的Code出問題我上層測出問題開Ticket被你關了難道我還要 幫你修？那我再打開你要不要修？還是說我開了這個Ticket你的Code得Rollback？你沒Ro llback你找我上層的人幹麻？ 今天開Ticket的人還只是個Dev開發都來不及了還要成天去Track別組的Bug？沒當你組是B locker就不錯了 簡單來說這個鍋最負責任的作法就是Dev lead就是原Po一開始就得出來坦，我人在亞麻做 過，這個COE(Correction Of Error)的主人絕對是原Po或是A絕對輪不到B，第一、你的QA test suite不夠完善沒辦法發現問題，第二、你的Dev寫Bug沒有完整的測試就關掉Ticke t，第三、你根本沒管好你的feature就release -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 172.58.208.51 (美國) ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1690427730.A.FFF.html
→
07/27 11:27, 9月前 , 1F
這個社會是需要演戲的 雖然我都不演
07/27 11:27, 1F
推
07/27 11:47, 9月前 , 2F
真的
07/27 11:47, 2F
→
07/27 11:47, 9月前 , 3F
B 最多就嘴臭而已
07/27 11:47, 3F
→
07/27 11:47, 9月前 , 4F
QA 都 close 了產品不 release 是要？
07/27 11:47, 4F
推
07/27 11:49, 9月前 , 5F
bug都關了，B不commit他的部分就變成這個feature還沒好
07/27 11:49, 5F
→
07/27 11:49, 9月前 , 6F
是卡在B的部分還沒上啊，A的部門這樣搞真是穩贏的XD
07/27 11:49, 6F
推
07/27 12:17, 9月前 , 7F
B技術上沒問題，人有問題XD
07/27 12:17, 7F
推
07/27 12:52, 9月前 , 8F
B就是做事不圓柔，不懂得和同事相處，本來20%責任，被
07/27 12:52, 8F
→
07/27 12:52, 9月前 , 9F
挖洞跳變80%責任
07/27 12:52, 9F
推
07/27 13:51, 9月前 , 10F
B如果真的負責再把ticket打開,我估計A就要大爆炸了
07/27 13:51, 10F
→
07/27 13:53, 9月前 , 11F
然後QA都過了如果B還在那邊GGYY不肯commit,肯定被釘飛
07/27 13:53, 11F
推
07/27 13:58, 9月前 , 12F
結合本篇與下篇說明整件事該負責的的確是原po
07/27 13:58, 12F
→
07/27 13:59, 9月前 , 13F
原po自己有說他被臨時調派,mindset沒做好導致於喪失了後面
07/27 13:59, 13F
推
07/27 13:59, 9月前 , 14F
推
07/27 13:59, 14F
→
07/27 13:59, 9月前 , 15F
升遷的機會,應該說原po的主管給他一次表現的機會但搞砸了~
07/27 13:59, 15F
推
07/27 14:14, 9月前 , 16F
推這篇，這與我的工作經驗與遇到的狀況比較接近
07/27 14:14, 16F
推
07/27 14:17, 9月前 , 17F
自己的錯，推給別人。然後別人不爽在鬧，把錯全推給別人說
07/27 14:17, 17F
→
07/27 14:17, 9月前 , 18F
話態度不對。
07/27 14:17, 18F
→
07/27 14:20, 9月前 , 19F
A自己的錯。推給別人B，然後B不爽了，在鬧情緒。於是把錯
07/27 14:20, 19F
→
07/27 14:20, 9月前 , 20F
推給鬧情緒的人。你可以說B的EQ是不好，但已經與此bug無關
07/27 14:20, 20F
→
07/27 14:20, 9月前 , 21F
了。
07/27 14:20, 21F
推
07/27 14:24, 9月前 , 22F
看第一篇那些推文說B問題或責任最大的我都懷疑這些人bug
07/27 14:24, 22F
→
07/27 14:24, 9月前 , 23F
是用嘴巴在管理而不是用系統在管理了
07/27 14:24, 23F
噓
07/27 14:54, 9月前 , 24F
笑死。
07/27 14:54, 24F
噓
07/27 14:59, 9月前 , 25F
技術上來說，B當然沒問題，但是處理事情上，B就有問題
07/27 14:59, 25F
→
07/27 15:00, 9月前 , 26F
這種事情，就是應該回報給上層，讓上層決定
07/27 15:00, 26F
推
07/27 15:04, 9月前 , 27F
很多時候，職場上該學的是如何處理事情，技術變成輔助
07/27 15:04, 27F
→
07/27 15:15, 9月前 , 28F
B不是有回報Bug了？沒回報在哪，難道回報bug 的系統不用主
07/27 15:15, 28F
→
07/27 15:15, 9月前 , 29F
管審？那也不是B的問題啊。程式碼Bug被關了，當然只能照公
07/27 15:15, 29F
→
07/27 15:15, 9月前 , 30F
司流程走下去。 B處理事情到底哪裡有問題。
07/27 15:15, 30F
→
07/27 15:20, 9月前 , 31F
你如果覺得沒問題那就沒問題，那有不少人覺得有問題，就
07/27 15:20, 31F
→
07/27 15:21, 9月前 , 32F
代表仍有待商確
07/27 15:21, 32F
推
07/27 15:32, 9月前 , 33F
我是不想跟B這種同事一起工作，有些人可能很喜歡吧
07/27 15:32, 33F
推
07/27 15:41, 9月前 , 34F
我比較不想和原po以及A共事，B說不上喜歡不過沒啥問題，
07/27 15:41, 34F
→
07/27 15:41, 9月前 , 35F
不過在那邊二分法也沒啥意義，職場上多的是不會多話的B
07/27 15:41, 35F
→
07/27 15:41, 9月前 , 36F
，自己實力不夠就是自己扛
07/27 15:41, 36F
推
07/27 15:46, 9月前 , 37F
我選擇跟B啊，起碼我的東西有問題會被他開出issue，跟A
07/27 15:46, 37F
→
07/27 15:46, 9月前 , 38F
那組做事自己沒發現不就默默炸掉
07/27 15:46, 38F
推
07/27 15:48, 9月前 , 39F
B的問題不是最大 但不代表B沒有問題啊......
07/27 15:48, 39F
推
07/27 15:48, 9月前 , 40F
其實最該學的是原po甩鍋的能力 被他一講大部人都覺得B有問題
07/27 15:48, 40F
→
07/27 15:49, 9月前 , 41F
A跟他同一部門又是他的下屬 講的好像沒犯什麼錯
07/27 15:49, 41F
推
07/27 15:51, 9月前 , 42F
A那組真的可怕，bug都關了還可以檢討B，你當初如果信任B
07/27 15:51, 42F
→
07/27 15:51, 9月前 , 43F
哪敢隨便關掉bug？今天如果不是在客戶那邊炸開，搞不好
07/27 15:51, 43F
→
07/27 15:51, 9月前 , 44F
到現在A那組都還認為B亂開bug
07/27 15:51, 44F
→
07/27 16:10, 9月前 , 45F
是也滿奇怪的 回報BUG不是要先確認重現步驟?
07/27 16:10, 45F
推
07/27 16:26, 9月前 , 46F
B大概還有錯在雞婆多管閒事吧，放給A team自己炸掉就好
07/27 16:26, 46F
→
07/27 16:26, 9月前 , 47F
，事後還可以說是機率性問題沒遇到跳脫
07/27 16:26, 47F
推
07/27 16:26, 9月前 , 48F
基本上這公司神奇的地方太多，連B只測過一次這種事都要
07/27 16:26, 48F
→
07/27 16:26, 9月前 , 49F
在客戶那邊炸開後檢討時才知道，步驟B認為他寫清楚在bug
07/27 16:26, 49F
→
07/27 16:26, 9月前 , 50F
上了，但後來檢討時B的環境其實也無法復現，所以我猜B也
07/27 16:26, 50F
→
07/27 16:26, 9月前 , 51F
只是矇到問題，但因為後來嘴砲而成為事主XD
07/27 16:26, 51F
推
07/27 16:32, 9月前 , 52F
我的推測是B矇到問題但也不敢確定，所以後來A說B搞砸環
07/27 16:32, 52F
→
07/27 16:32, 9月前 , 53F
境關掉bug時B也不敢堅持往上HL，照著流程下去最後就在客
07/27 16:32, 53F
→
07/27 16:32, 9月前 , 54F
戶那邊炸了，之後B自爆我猜就只是以為可以趁機一吐怨氣
07/27 16:32, 54F
→
07/27 16:32, 9月前 , 55F
沒想到被原po抓到變成事主
07/27 16:32, 55F
推
07/27 17:39, 9月前 , 56F
同意這篇觀點才是對的，以這個事件來看 leader 和 A
07/27 17:39, 56F
→
07/27 17:39, 9月前 , 57F
dev 在流程的問題才是最大問題，不然每次都在究責人
07/27 17:39, 57F
→
07/27 17:39, 9月前 , 58F
根本究責不完
07/27 17:39, 58F
→
07/27 17:56, 9月前 , 59F
鬼故事才是原作者，我猜他應該也沒資源跟人事權
07/27 17:56, 59F
→
07/27 18:15, 9月前 , 60F
鬼故事就原作者 leader埋頭苦幹弄不好 事後炸鍋還要推責
07/27 18:15, 60F
→
07/27 18:19, 9月前 , 61F
如果真的那麼盡心盡力早該在close前先跟B組溝通請B支援
07/27 18:19, 61F
→
07/27 18:24, 9月前 , 62F
如果B支援後還找不出來就是公司自己扛. 事後怪罪A跟B真
07/27 18:24, 62F
→
07/27 18:25, 9月前 , 63F
的鳥公司鳥主管
07/27 18:25, 63F
推
07/27 18:36, 9月前 , 64F
如果B有複驗過且沒問題，然後要上有先請示過，才會沒問
07/27 18:36, 64F
→
07/27 18:36, 9月前 , 65F
題
07/27 18:36, 65F
推
07/27 19:09, 9月前 , 66F
如果B開的bug只有B能關，才有資格要求B要複驗好嗎…B開
07/27 19:09, 66F
→
07/27 19:09, 9月前 , 67F
的bug隨便被其他人關掉是要B複驗什麼？
07/27 19:09, 67F
→
07/27 19:20, 9月前 , 68F
更別說這種沒改code，只是RD判斷環境因素就關掉的bug，
07/27 19:20, 68F
→
07/27 19:20, 9月前 , 69F
就算是專責的QA部門來處理，我看也是一堆直接關閉
07/27 19:20, 69F
→
07/27 19:26, 9月前 , 70F
B沒設定權限不就代表允許這麼做... 但公司理應限制
07/27 19:26, 70F
→
07/27 19:27, 9月前 , 71F
全域設定不能阿貓阿狗都能close
07/27 19:27, 71F
推
07/27 20:19, 9月前 , 72F
推這篇
07/27 20:19, 72F
推
07/27 21:37, 9月前 , 73F
推
07/27 21:37, 73F
→
07/27 22:20, 9月前 , 74F
為了HL人故意把已知炸彈引爆 讓客戶受害 說B沒問題…
07/27 22:20, 74F
推
07/28 00:35, 9月前 , 75F
檢討的時候B不嘴臭連鍋都沒得甩，呵呵
07/28 00:35, 75F
→
07/28 00:35, 9月前 , 76F
上面有人說得很好，多的是不吭聲的B，B敗只在嘴邱
07/28 00:35, 76F
推
07/29 11:38, 9月前 , 77F
這種公司就是早早離職就對了
07/29 11:38, 77F
‣ 更多 handsomeLin 的文章
文章代碼(AID): #1amU5I__ (Soft_Job)
討論串 (同標題文章)
完整討論串 (本文為第 8 之 17 篇)：
排序： 最舊先 | 最新先 | 留言數
在新視窗開啟完整討論串 (共17篇)
‣ 更多 handsomeLin 的文章
文章代碼(AID): #1amU5I__ (Soft_Job)