Re: [心得] 我在科技業遇到的鬼故事之一
再回一篇,先說我不是B但是這個細節出了更明顯不是B的問題了啊
這個Bug本來就是一個corner case只是好巧不巧在B開發的時候遇到一次,要是今天B剛好就沒遇到這個Bug,你們還不是一樣照常Release,客戶一樣爆掉,這樣B不就剛好衰幫你發現Bug而已?
你硬要說B的態度有問題,他也只是表達出他遇過且在你們根本沒修的情況本來就很可能再發生,很明顯原Po這組原本想甩鍋讓B一起揹,B可能只是無言搞你搞回去而已
B的視角比較像:你今天底層的Code出問題我上層測出問題開Ticket被你關了難道我還要幫你修?那我再打開你要不要修?還是說我開了這個Ticket你的Code得Rollback?你沒Rollback你找我上層的人幹麻?
今天開Ticket的人還只是個Dev開發都來不及了還要成天去Track別組的Bug?沒當你組是Blocker就不錯了
簡單來說這個鍋最負責任的作法就是Dev lead就是原Po一開始就得出來坦,我人在亞麻做過,這個COE(Correction Of Error)的主人絕對是原Po或是A絕對輪不到B,第一、你的QA test suite不夠完善沒辦法發現問題,第二、你的Dev寫Bug沒有完整的測試就關掉Ticket,第三、你根本沒管好你的feature就release
--
這個社會是需要演戲的 雖然我都不演
真的
B 最多就嘴臭而已
QA 都 close 了產品不 release 是要?
bug都關了,B不commit他的部分就變成這個feature還沒好
是卡在B的部分還沒上啊,A的部門這樣搞真是穩贏的XD
B技術上沒問題,人有問題XD
B就是做事不圓柔,不懂得和同事相處,本來20%責任,被
挖洞跳變80%責任
B如果真的負責再把ticket打開,我估計A就要大爆炸了
然後QA都過了如果B還在那邊GGYY不肯commit,肯定被釘飛
結合本篇與下篇說明整件事該負責的的確是原po
原po自己有說他被臨時調派,mindset沒做好導致於喪失了後面
推
升遷的機會,應該說原po的主管給他一次表現的機會但搞砸了~
推這篇,這與我的工作經驗與遇到的狀況比較接近
自己的錯,推給別人。然後別人不爽在鬧,把錯全推給別人說
話態度不對。
A自己的錯。推給別人B,然後B不爽了,在鬧情緒。於是把錯
推給鬧情緒的人。你可以說B的EQ是不好,但已經與此bug無關
了。
看第一篇那些推文說B問題或責任最大的我都懷疑這些人bug
是用嘴巴在管理而不是用系統在管理了
笑死。
技術上來說,B當然沒問題,但是處理事情上,B就有問題
這種事情,就是應該回報給上層,讓上層決定
很多時候,職場上該學的是如何處理事情,技術變成輔助
B不是有回報Bug了?沒回報在哪,難道回報bug 的系統不用主
管審?那也不是B的問題啊。程式碼Bug被關了,當然只能照公
司流程走下去。 B處理事情到底哪裡有問題。
你如果覺得沒問題那就沒問題,那有不少人覺得有問題,就
代表仍有待商確
我是不想跟B這種同事一起工作,有些人可能很喜歡吧
我比較不想和原po以及A共事,B說不上喜歡不過沒啥問題,
不過在那邊二分法也沒啥意義,職場上多的是不會多話的B
,自己實力不夠就是自己扛
我選擇跟B啊,起碼我的東西有問題會被他開出issue,跟A
那組做事自己沒發現不就默默炸掉
B的問題不是最大 但不代表B沒有問題啊......
其實最該學的是原po甩鍋的能力 被他一講大部人都覺得B有問題
A跟他同一部門又是他的下屬 講的好像沒犯什麼錯
A那組真的可怕,bug都關了還可以檢討B,你當初如果信任B
哪敢隨便關掉bug?今天如果不是在客戶那邊炸開,搞不好
到現在A那組都還認為B亂開bug
是也滿奇怪的 回報BUG不是要先確認重現步驟?
B大概還有錯在雞婆多管閒事吧,放給A team自己炸掉就好
,事後還可以說是機率性問題沒遇到跳脫
基本上這公司神奇的地方太多,連B只測過一次這種事都要
在客戶那邊炸開後檢討時才知道,步驟B認為他寫清楚在bug
上了,但後來檢討時B的環境其實也無法復現,所以我猜B也
只是矇到問題,但因為後來嘴砲而成為事主XD
我的推測是B矇到問題但也不敢確定,所以後來A說B搞砸環
境關掉bug時B也不敢堅持往上HL,照著流程下去最後就在客
戶那邊炸了,之後B自爆我猜就只是以為可以趁機一吐怨氣
沒想到被原po抓到變成事主
同意這篇觀點才是對的,以這個事件來看 leader 和 A
dev 在流程的問題才是最大問題,不然每次都在究責人
根本究責不完
鬼故事才是原作者,我猜他應該也沒資源跟人事權
鬼故事就原作者 leader埋頭苦幹弄不好 事後炸鍋還要推責
如果真的那麼盡心盡力早該在close前先跟B組溝通請B支援
如果B支援後還找不出來就是公司自己扛. 事後怪罪A跟B真
的鳥公司鳥主管
如果B有複驗過且沒問題,然後要上有先請示過,才會沒問
題
如果B開的bug只有B能關,才有資格要求B要複驗好嗎…B開
的bug隨便被其他人關掉是要B複驗什麼?
更別說這種沒改code,只是RD判斷環境因素就關掉的bug,
就算是專責的QA部門來處理,我看也是一堆直接關閉
B沒設定權限不就代表允許這麼做... 但公司理應限制
全域設定不能阿貓阿狗都能close
推這篇
推
為了HL人故意把已知炸彈引爆 讓客戶受害 說B沒問題…
檢討的時候B不嘴臭連鍋都沒得甩,呵呵
上面有人說得很好,多的是不吭聲的B,B敗只在嘴邱
這種公司就是早早離職就對了
爆
首Po講一個我在科技業遇到的鬼故事 這件事主要發生在兩個人身上: A:是我同部門的同事,主要開發kernel層以下的功能。 B:是隔壁整合部門的同事,主要是開始kernel層以上的功能。 有一天A開發了某一個功能,B整合完之後發現會導致資料損毀。於是B發了一個bug給A,13
難怪IC house要推當責Accountablity 提到的每個人都幾乎有責任啦 就跟空難和起司理論一樣 不是只有一個單純的原因造成 Product owner每天或每周都應該了解進度/severity72
這篇文最鬼的明明就是原PO,這個Feature在他的組開發然後有問題,自己組的人+QA竟然 測不出來,結果隔壁組的人竟然有權限把Feature打開,B就算說原本就知道有問題硬要搞 最後補一句「有可能是我自己環境有問題」也是能全身而退 說到底身為新Feature的lead管產品品質+QA都管不好,有問題的code還能進到release br anch,最後還能PO出來讓大家評論B,這才是我看過最鬼的鬼故事吧78
我是原po,我來交代一些細節,供大家參考一下。 角色: 我在這裡的角色是application owner,我要推一個應用給客戶去使用。 我這個application需要多個feature來組成,B是我其中一個feature owner。 B這個feature需要多個kernel function整合才有辦法達成,當然B自己也要寫不少code。8
→ pokkys: 所以B根本不需要講他是故意的話。 07/25 19:37 所以大部分的人都搞錯重點了 因為事情對或錯往往都不是重點 而是看哪個部門比較大聲 B大也可以裝傻 退一步假裝真的是當時誤以為自己搞砸環境4
不是mindset也不是制度問題吧 是你們所有人的環境為什麼都跟客戶不一樣? B只有一開始的環境類似於客戶 後來也不一樣了所以可能也做不出來 環境不一樣8
到這邊為止 A看起來有把問題反應給你 你的工作應該是跟B的主管協調,看能不能讓B優先處理這個issue吧 大部分職場都會把開發需求區分piority 如果這是個嚴重的issue, piority設高並且必須優先處理.24
第一篇文章推文: pokkys: 我的職位要扛feature成敗,所以我也因此卡到升遷。 pokkys: 沒有火B這件事我也是傻眼+不滿,所以我比B還早離職 XD 第二篇文章內文: 其他人的部分,我是極力不想對A究責,B的主管也是一樣的態度。最後我們兩個送上去給老闆的說法是這兩個人的責任,10分裡只有1分。27
大家好我是原po,大家討論那的激烈,我覺得我需要補充一下。 我認為有一個癥結點需要解釋一下,雖然有可能解釋完結果可能更糟 XD 因為中間有一段,完全是我的臆測,我也沒有絕對證據去證實我的論點。 如果各位要反駁我,我也完全接受。 我主要是要講一下,為何我會覺得B應該被火?
59
[閒聊] 建議不要升級Windows 11作為DEV版每個版本都有跟的人 建議不要這麼早升級WIN 11正式版 因為正式版的194就是Beta的194 (雜湊一樣) DEV已經過去好幾個版本了 有很多DEV的更新日誌已經解決的問題正式版還有14
Re: [討論] 新人問哪些問題會覺得他很專業認真回一下 Shared folder在哪?有共同編輯的wiki page嗎?有build code流程頁面嗎? 有用虛擬編譯環境嗎?是用docker 嗎? 我git push後是去哪裡開code review?有CICD嗎?有用gmock 寫unit test嗎?有做regression test嗎? Debug build command要怎麼下?有debug mode嗎?11
Re: [請益] 請問這樣的git使用方式是否是正確的?個人意見,僅供參考 不太確定常不常見,但看起來是合理的。 可以想到的好處和情況是 不同的service 可以分開Build,Build 之後的artifact 可以依照每個service 的開發進 度deploy 到不同的測試環境,利於不同進度的開發和整合。7
Re: [請益] bug「可遇不可求」,各位還會去debug它嗎?先講結論 修bug還要看影響程度 impact/severity 閃退是很嚴重的問題。 相當於app crash 除非你有權力決定/並扛結果,否則就是看上層要不要修。 或者能說服上層不修6
Re: [心得] Windows 11 測試版微軟在今天發布Build 22581。Dev和Beta都會更新到這個版本 微軟表示如果現在想從Dev和Beta之間互相轉換的請更新到22581,更新後就能離開Dev通道 降到Beta通道 想離開的Dev快把握這次機會啊,下次開放不知道是甚麼時候了2
Re: [心情] 工作的內容被放大檢視我怎麼覺得是在找麻煩, 不管是老鳥,還是主管,我就不相信有人可以 速度十分快又完全沒有任何bug,程式精簡到沒任何一絲一毫多餘的斷行 tab或空白或多 餘效率不好的code,或程式中有重覆使用的code(沒精簡包在fuction中) 沒任何bug代表寫完要不斷測試所有各種可能的case,這2
[原神] 原BUG玩法 工程師都不修的嗎看B站 有一個播主 叫覆雪O下 他介紹很多原神BUG 這些工程師會去修嗎