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

※ 引述《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