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

看板Soft_Job作者 (.....)時間9月前 (2023/07/27 11:27), 編輯推噓8(8推 0噓 47→)
留言55則, 9人參與, 9月前最新討論串9/17 (看更多)
※ 引述《pokkys (人很好那一個)》之銘言： : 我是原po，我來交代一些細節，供大家參考一下。 : 角色： : 我在這裡的角色是application owner，我要推一個應用給客戶去使用。 : 我這個application需要多個feature來組成，B是我其中一個feature owner。 : B這個feature需要多個kernel function整合才有辦法達成，當然B自己也要寫不少code。 : A是B負責的feature的kernel function owner，同時我也是A的主管。 : 我也有配到一組跟我對應的QA，而我要承擔最終的成敗。 : 這其中：BU1:{{A,我},QA} BU2:{B} : 一開始A接到bug試不出來，有去找B討論，但是B認為步驟寫在bug report上很完整了。 : 而且B有其他feature要開發，無法把機器+環境借給別人。 到這邊為止 A看起來有把問題反應給你 你的工作應該是跟B的主管協調,看能不能讓B優先處理這個issue吧 大部分職場都會把開發需求區分piority 如果這是個嚴重的issue, piority設高並且必須優先處理. 我會好奇為什麼不能要求B優先處理你們的問題 如果B真的無法處理,issue也是等到他有空能幫忙後才關閉吧. 會在客戶端爆炸的問題我認為piority應該要設高才對 @@ : 我問B：你是看到A/QA把bug close後，你又測了一次發現還是一樣，所以才打算commit上 : 去想要highlight他是嗎？ : B說：沒有，後來就沒有測。 : 我問：你沒有測，你怎麼會知道這個問題還在？ : B說：他就說can not reproduce啊，所以問題一定還在。 : 我說：這不一定吧？ : B的主管：所以你只是因為他沒有解，所以你認定問題還在，才想要highlight這個問題？ : B說：對，我只是想提醒大家問題沒有被解決。 : 我說：那你到底測過幾次？ : B想了一下說：1次 : 我說：可是你寫always耶！ : B說：我就想說測1次中一次就100%啊。 B的回答0分 但從B的角度看,他不是QA也不是負責人 回報問題 -> 被mark close -> commit上去後release 這個過程聽起來也沒什麼錯,bug都被close了為什麼不能release. 我個人在這種情況下都會複測一次確保沒問題 而主管的工作是要在這種情況下確定底下工程師有複測 原po作為管理者(app owener),該處理的問題是 1. 要求B優先處理這個issue 2. 確保B真的有複測,而且要能看到複測結果. (附一張截圖之類的) 管理者本來就要幫下屬爭取必要的資源 這樣看起來A算苦主,他就真的無法複測,也有向上反應, 但上面沒有提供足夠的資源 (要求B優先處理這件事情) QA也無法重現的情況下就應該抓B一起進來解問題... B的工作態度有問題,但可能對公司積怨已久或是失去工作熱情 看起來是原本就想跑了,跑之前放個火燒一下. 我好奇的是是否有要求B進來一起解bug,以及這件事情是否被拒絕 @@ : 後來B先被請出去了，我跟他主管談這件事。 : 我們最後的共識是相信B主管的總結：因為bug close當下，那段有問題的LAGG test code : 已經被修掉很久了。 B不太可能有真的機會複製出這個問題。 而且LAGG test code被修 : 掉這件事，也可以解釋為何我跟QA沒有辦法複製。 這個說法，大家都會有台階下。 : 所以最後我沒有去糾結為何他那麼明確知道bug還在這件事.....我接受B主管的說法了。 並不是有台階下就好,問題還是沒解決 而且這個台階是建立在A背了黑鍋的前提下... -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 36.229.148.16 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1690428479.A.072.html
→
07/27 11:34, 9月前 , 1F
最原始的發文就是這個bug不是100%重現，但feature不能開
07/27 11:34, 1F
→
07/27 11:38, 9月前 , 2F
但重現過的只有B，把他抓進來參與討論很正常吧
07/27 11:38, 2F
→
07/27 11:39, 9月前 , 3F
B說他沒辦法幫忙，就close bug，感覺問題點發生在這裡
07/27 11:39, 3F
推
07/27 12:07, 9月前 , 4F
從後續原po他們復現的情況來看B真的進來可能也沒用，因
07/27 12:07, 4F
→
07/27 12:07, 9月前 , 5F
為B後來一開始也無法復現，問題沒在客戶那邊炸開時看得
07/27 12:07, 5F
→
07/27 12:07, 9月前 , 6F
出來A部門對B的信任度相當低，才會有A認為他複製不出來
07/27 12:07, 6F
→
07/27 12:07, 9月前 , 7F
這個問題，肯定是B把自己環境搞砸了就可以關掉bug的情況
07/27 12:07, 7F
→
07/27 12:07, 9月前 , 8F
。否則不太可能輕率處理這種會造成資料損毀的嚴重問題
07/27 12:07, 8F
→
07/27 12:09, 9月前 , 9F
如果B也無法重現的話就真的沒輒了
07/27 12:09, 9F
→
07/27 12:10, 9月前 , 10F
但B沒被拉進來是別的問題@@
07/27 12:10, 10F
推
07/27 12:11, 9月前 , 11F
從B只測過一次這件事也是原po在事後檢討時問B才知道，那
07/27 12:11, 11F
→
07/27 12:11, 9月前 , 12F
當初A有沒有認真找B討論過這個bug可想而知
07/27 12:11, 12F
推
07/27 12:14, 9月前 , 13F
因為雙方沒有信任，A部門當然也不會拉B進來處理，可能還
07/27 12:14, 13F
→
07/27 12:14, 9月前 , 14F
覺得B根本在亂開bug
07/27 12:14, 14F
→
07/27 12:20, 9月前 , 15F
呃這個我覺得當事人才知道怎麼回事
07/27 12:20, 15F
→
07/27 12:20, 9月前 , 16F
但文內敘述是B在忙，無法提供設備做測試
07/27 12:20, 16F
推
07/27 12:23, 9月前 , 17F
這bug會造成資料損毀基本上算是非常嚴重的等級，如果A部
07/27 12:23, 17F
→
07/27 12:23, 9月前 , 18F
門真想要查清楚就不該關閉吧？看是要找B主管調整B的工作
07/27 12:23, 18F
→
07/27 12:23, 9月前 , 19F
還是等B忙完再來一起解
07/27 12:23, 19F
推
07/27 12:30, 9月前 , 20F
說實在應該一堆公司都有類似的問題，只是沒炸開而已
07/27 12:30, 20F
→
07/27 15:02, 9月前 , 21F
一堆公司？可否舉例？個人待過的公司超過6家了。從來沒有
07/27 15:02, 21F
→
07/27 15:02, 9月前 , 22F
一家 有bug，工程師可以隨意關。有問題的程式碼，開發者可
07/27 15:02, 22F
→
07/27 15:02, 9月前 , 23F
以隨意release到產品，不會有人審。出了事情，owner優先檢
07/27 15:02, 23F
→
07/27 15:02, 9月前 , 24F
討人說話態度不對的。
07/27 15:02, 24F
推
07/27 15:17, 9月前 , 25F
全台幾間公司，你也才待六間。D大你是神人沒遇過正常
07/27 15:17, 25F
→
07/27 15:33, 9月前 , 26F
A可以close bug應該是主管也同意 也就是原po 不關的話應該也
07/27 15:33, 26F
→
07/27 15:34, 9月前 , 27F
沒辦法按schedule推出產品
07/27 15:34, 27F
推
07/27 17:03, 9月前 , 28F
看一堆人想跟A當同事不想跟B 就知道有一堆公司認為說話
07/27 17:03, 28F
→
07/27 17:03, 9月前 , 29F
的態度比邏輯跟流程重要啊
07/27 17:03, 29F
→
07/27 17:04, 9月前 , 30F
今天B沒有運氣好打到規格外的bug，產品一樣會炸
07/27 17:04, 30F
→
07/27 17:06, 9月前 , 31F
但是B打到了之後沒有執意卡release卡到能復現為止，所以
07/27 17:06, 31F
→
07/27 17:06, 9月前 , 32F
會炸都是B害的，如果B心態積極善良產品就不會出包了
07/27 17:06, 32F
→
07/27 17:07, 9月前 , 33F
其他人輕忽資料毀損bug根因未解，都沒責任，因為態度良好
07/27 17:07, 33F
→
07/27 17:07, 9月前 , 34F
一堆人是這種想法
07/27 17:07, 34F
→
07/27 22:43, 9月前 , 35F
B懂個屁邏輯與流程 什麼叫作一樣會炸 B不commit會炸
07/27 22:43, 35F
→
07/27 22:44, 9月前 , 36F
嗎 也沒有人故意讓他說錯話 他自己曝露動機不能怪人
07/27 22:44, 36F
→
07/27 22:46, 9月前 , 37F
你要不要去看一下出bug的點 無法複現可以理解
07/27 22:46, 37F
→
07/27 22:48, 9月前 , 38F
在中小企業很隨意是很常見的 看來DrTech是都待在很好
07/27 22:48, 38F
→
07/27 22:48, 9月前 , 39F
的公司
07/27 22:48, 39F
→
07/27 22:53, 9月前 , 40F
就環境問題 這應該還要再開另外的issue B早就忙完
07/27 22:53, 40F
→
07/27 22:55, 9月前 , 41F
commit不是嗎 為何是A部門要主動？ 如果A部門有視野
07/27 22:55, 41F
→
07/27 22:55, 9月前 , 42F
那A部門理應主動 看不見的東西沒有目標還要主動...
07/27 22:55, 42F
→
07/28 03:20, 9月前 , 43F
嗯？你把B換成CDEF都有可能炸啊A的code就是有問題而且他
07/28 03:20, 43F
→
07/28 03:20, 9月前 , 44F
沒打算查啊因為他跟你的邏輯一樣啊，「雖然問題出在我的f
07/28 03:20, 44F
→
07/28 03:20, 9月前 , 45F
unction，但是我不用主動，因為我不能復現，看不到目標，
07/28 03:20, 45F
→
07/28 03:20, 9月前 , 46F
別人要幫我復現我再來查，不然我就關票，沒問題的」你把B
07/28 03:20, 46F
→
07/28 03:20, 9月前 , 47F
換成任何人都一樣會炸
07/28 03:20, 47F
→
07/28 09:08, 9月前 , 48F
所以應該是找B主管討論後拉B進來debug阿...
07/28 09:08, 48F
→
07/28 09:08, 9月前 , 49F
要是B進來後無法重現，那就真的沒輒
07/28 09:08, 49F
→
07/28 20:10, 9月前 , 50F
未知的情報你要怎麼讓A主動認為是己方問題？ 換任何
07/28 20:10, 50F
→
07/28 20:11, 9月前 , 51F
人都會炸然後呢？ B沒犯錯？ 硬找理由cover B
07/28 20:11, 51F
推
07/29 00:05, 9月前 , 52F
關bug 很奇怪+1 通常都是開著讓他變known issue 除非r
07/29 00:05, 52F
→
07/29 00:05, 9月前 , 53F
oot cause 找到，然後如果issue 夠嚴重，應該要請B的
07/29 00:05, 53F
→
07/29 00:05, 9月前 , 54F
主管壓著他壓到他重新復現並給出詳細步驟為止
07/29 00:05, 54F
→
07/29 09:08, 9月前 , 55F
關close理由都給你了有什麼好奇怪...
07/29 09:08, 55F
‣ 更多 hidog 的文章
文章代碼(AID): #1amUG_1o (Soft_Job)
討論串 (同標題文章)
本文引述了以下文章的的內容：
完整討論串 (本文為第 9 之 17 篇)：
排序： 最舊先 | 最新先 | 留言數
在新視窗開啟完整討論串 (共17篇)
‣ 更多 hidog 的文章
文章代碼(AID): #1amUG_1o (Soft_Job)