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

看板Soft_Job作者 (人很好那一個)時間9月前 (2023/07/25 18:59), 9月前編輯推噓78(85推 7噓 491→)
留言583則, 57人參與, 9月前最新討論串5/17 (看更多)
我是原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要開發，無法把機器+環境借給別人。 然後我想可能是概率問題，去找QA幫忙，QA也有在他們各種環境下增加這個測項。 最後A/QA都試不出來，於是A把bug mark成無法複製。 QA也確認無法複製之後就close了 B發現被mark無法複製之後，B就把feature 打開commit上去。(我當時不知道他是故意) 根據我們release流程，他的change被QA挑進mouthly release中，通過測試release。 最後客戶拿到就炸掉了，如上一篇文章所講。 這個過程中，其實我犯了幾個錯誤。 B的report是寫發生率100%，但是包含B在內的RD都很習慣把(實驗一次:發生一次)=100% 所以我誤判這個問題並非100%，才有後面請QA幫忙大範圍測試。 事後分析，B的確也只遇過一次。當下能複製的環境，在最後檢討的時候也不見了。 最後釐清完反推才知道，原來在錯的環境下，就是100%複製沒錯。 第二個錯誤，我跟A其實有作code review。A也有找到幾個疑點，會導致bug描述的現象。 於是他也預防性的做了一些修正，但是因為無法複製問題，所以無法確認是否正解。 我手上一堆『無法複製』的問題，我最後卡關的條件就是QA大規模測試無法復現，加上 code review有正面反饋，我就給過了。因為也不是正解，我之前描述就沒講到這段。 第三個錯誤，我當時對QA team花的時間太少。客戶的使用情境，我們原本應該是要能夠 造出對應的測項去把關。 在PM跟我們(RD+QA)解釋完客戶的情境之後，我就單方面認為 『情境QA都知道了，QA都是老鳥應該是知道怎麼造測項吧？』 如同前面的敘述，我本身是RD leader，在臨危受命去協調這個applicaiton時， 我的mindset還是覺得我就是RD leader，而不是要扛成敗的人。 我覺得這個mindset 才是整個事件的主因。最後我也因為這樣失去一些升遷，但是我也覺得這超出我能力。 最後我分享上面這一些事情，其實都是各位工程師們的日常。 原本也沒有什麼特別好講的，我只是覺得最後B跳出來自爆這件事很扯。 所以我認為鬼故事的點，是B竟然會自爆。太不可思議了。 就如同我在上一篇文章裡面留言的，我一開始就知道我一定是全責。 也並沒有要把責任推給任何同事的意思（事實上也不可能推得掉XD）。 這件事的後續是，我跟QA留下來作PDCA，結論就是最後這關一定要弄清楚客戶環境。 客戶的部分，我負責了客戶資料救援，最後也是有救回來，可能是這樣所以考績沒影響。 其他人的部分，我是極力不想對A究責，B的主管也是一樣的態度。 最後我們兩個送上去給老闆的說法是這兩個人的責任，10分裡只有1分。 但是老闆還是砍了他們分紅，我們打上去的考績也是被打折。 A因為這件事，有點不爽的離職了。 我因為這件事，有點心灰意冷.....覺得自己不勝任，後來也是離職了。 B的部分，我不知道他心理怎麼想，我只知道他最後因為請人代刷門禁被火。 下面是技術細節，可略過。 B的環境，其實是因為他在測A的功能之前，先跑了網路相關測試。 在網路的測試中，有一個Link Aggregation的測試中，跑完忘記把LAGG拆掉。 導致B測A的code時，因為有LAGG所以A的code 才跑出不預期的行為。 而B其實也沒有描述他前一天他的機器有跑什麼測試(這也合理)。 之後有人發現網路測試中，LAGG沒有拆掉，導致後面一堆測試錯亂，所以『修正』了。 所以後面我們大規模測試也沒有測出這問題。 客戶環境，就是使用LAGG。而QA也有測LAGG，也有測A的功能，就是沒有兩個一起測過。 關於B的處理，補充一段後續。 會議當下我聽到B自爆，我正在想要怎麼處理，要去找B的主管。 結果QA直接report給老 闆這件事，我們就不得不處理。 我/B/B的主管，三個人在會議室。 我問B：你是看到A/QA把bug close後，你又測了一次發現還是一樣，所以才打算commit上 去想要highlight他是嗎？ B說：沒有，後來就沒有測。 我問：你沒有測，你怎麼會知道這個問題還在？ B說：他就說can not reproduce啊，所以問題一定還在。 我說：這不一定吧？ B的主管：所以你只是因為他沒有解，所以你認定問題還在，才想要highlight這個問題？ B說：對，我只是想提醒大家問題沒有被解決。 我說：那你到底測過幾次？ B想了一下說：1次 我說：可是你寫always耶！ B說：我就想說測1次中一次就100%啊。 後來B先被請出去了，我跟他主管談這件事。 我們最後的共識是相信B主管的總結：因為bug close當下，那段有問題的LAGG test code 已經被修掉很久了。 B不太可能有真的機會複製出這個問題。 而且LAGG test code被修 掉這件事，也可以解釋為何我跟QA沒有辦法複製。 這個說法，大家都會有台階下。 所以最後我沒有去糾結為何他那麼明確知道bug還在這件事.....我接受B主管的說法了。 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 122.116.74.78 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1690282742.A.167.html ※ 編輯: pokkys (122.116.74.78 臺灣), 07/25/2023 19:01:23
→
07/25 19:02, 9月前 , 1F
B只有遇到一次,且無法複製,那就是Once,不是Always
07/25 19:02, 1F
推
07/25 19:07, 9月前 , 2F
別的不說 B的個性人品道德應該是有問題的
07/25 19:07, 2F
推
07/25 19:08, 9月前 , 3F
有些大環境的管理方式真的是很打擊前線人員士氣
07/25 19:08, 3F
推
07/25 19:20, 9月前 , 4F
B只出現一次 那把功能打開不是正常嗎 A和QA都確認過了
07/25 19:20, 4F
→
07/25 19:35, 9月前 , 5F
的確只有一次，他不是QA，也不好要求多測幾次。總之我是
07/25 19:35, 5F
→
07/25 19:35, 9月前 , 6F
接受。
07/25 19:35, 6F
→
07/25 19:37, 9月前 , 7F
所以B根本不需要講他是故意的話。
07/25 19:37, 7F
→
07/25 20:23, 9月前 , 8F
自爆的場合是跟你一對一閒聊？
07/25 20:23, 8F
→
07/25 20:23, 9月前 , 9F
QA建完測項沒跟PM/leader核對過需求嗎? 這補述B根本該0
07/25 20:23, 9F
→
07/25 20:23, 9月前 , 10F
責 真的做出release到客戶端的是QA呀 你們這流程B當時的
07/25 20:23, 10F
→
07/25 20:23, 9月前 , 11F
確就該commit了
07/25 20:23, 11F
推
07/25 20:24, 9月前 , 12F
推四樓
07/25 20:24, 12F
→
07/25 20:25, 9月前 , 13F
B不講但是B commit了 頂多責任比較少才算公正
07/25 20:25, 13F
→
07/25 20:26, 9月前 , 14F
測試沒有做整合測試也是恐怖？
07/25 20:26, 14F
→
07/25 20:29, 9月前 , 15F
這不是純一個人的問題 不可能零責的
07/25 20:29, 15F
→
07/25 20:29, 9月前 , 16F
沒錯原本以為B是無責，在我bug review找他進來幫忙時自爆
07/25 20:29, 16F
→
07/25 20:29, 9月前 , 17F
，我都不知道他是哪裡搞錯。 我猜他沒有意識到現在是在討
07/25 20:29, 17F
→
07/25 20:29, 9月前 , 18F
論炸在客戶的問題。 他當下也不是故意commit的，因為他只
07/25 20:29, 18F
→
07/25 20:29, 9月前 , 19F
測過一次。 A mark 無法複製後，他是沒有複驗的。 我猜
07/25 20:29, 19F
→
07/25 20:29, 9月前 , 20F
測他只是聽到A的bug 被客戶打出來之後想要嘴一波。
07/25 20:29, 20F
推
07/25 20:34, 9月前 , 21F
你說"原本以為" 那現在回看呢? B作業上的疏失在哪?
07/25 20:34, 21F
→
07/25 20:41, 9月前 , 22F
如果B是明知道code 有問題，但是他故意不擋，那就有責任
07/25 20:41, 22F
→
07/25 20:41, 9月前 , 23F
了。 但是他不自白，沒人會知道他是故意的。 就算我事後
07/25 20:41, 23F
→
07/25 20:41, 9月前 , 24F
覺得他可能只是嘴秋，但是會議上留紀錄了啊。
07/25 20:41, 24F
→
07/25 20:45, 9月前 , 25F
不講責任小 講了責任大
07/25 20:45, 25F
→
07/25 20:46, 9月前 , 26F
他是統整的人還是會有小小的責任
07/25 20:46, 26F
推
07/25 20:53, 9月前 , 27F
推mindset
07/25 20:53, 27F
推
07/25 20:54, 9月前 , 28F
怎麼覺得 B 會被究責原因的在心態(用客戶HL)，不然
07/25 20:54, 28F
→
07/25 20:54, 9月前 , 29F
處理的方法很合理阿。owner + QA 都說沒問題，憑甚
07/25 20:54, 29F
→
07/25 20:54, 9月前 , 30F
麼要求 B 說要擋。再退一步，不管 B 心態有沒有問題
07/25 20:54, 30F
→
07/25 20:54, 9月前 , 31F
，就算是他故意這樣做，不是都有A +QA 背書嗎，根因
07/25 20:54, 31F
→
07/25 20:54, 9月前 , 32F
還是 A + QA 把關失誤。不過話說回來，用客戶 HL 是
07/25 20:54, 32F
→
07/25 20:54, 9月前 , 33F
真的蠻猛的，自己也是會怕這樣的同事就是了XD
07/25 20:54, 33F
→
07/25 20:56, 9月前 , 34F
那再問你們這制度B該怎麼擋? 是要他承擔QA責任?
07/25 20:56, 34F
推
07/25 21:07, 9月前 , 35F
這篇問題二就說了 該issue身為項目負責人的原po是給關的
07/25 21:07, 35F
→
07/25 21:07, 9月前 , 36F
B真要HL是要越級申訴到大老闆嗎?
07/25 21:07, 36F
→
07/25 21:07, 9月前 , 37F
B可以向上反映 A要把什麼關...寫一個可以預知所有情
07/25 21:07, 37F
推
07/25 21:07, 9月前 , 38F
B的問題一直都不是在流程上，是個人道德問題，不管是知
07/25 21:07, 38F
→
07/25 21:07, 9月前 , 39F
道還推並自白，或是知道也推但裝死，這個人格真的不行
07/25 21:07, 39F
還有 504 則推文
還有 1 段內文
→
07/27 08:30, 9月前 , 544F
其實第一篇與這篇差不多 藉由第一篇分析就差不多 只
07/27 08:30, 544F
→
07/27 08:31, 9月前 , 545F
樓上一定是注重技術的人，認同。但工作的流程也非常重要。
07/27 08:31, 545F
→
07/27 08:31, 9月前 , 546F
一個開發者，可以任意開feature，不用owner審核，出了事情
07/27 08:31, 546F
→
07/27 08:31, 9月前 , 547F
owner卻去怪開發者。這種流程，人會跑光的。
07/27 08:31, 547F
→
07/27 08:31, 9月前 , 548F
是這篇確認而已 本來第一篇就可以得到大家都有過失的
07/27 08:31, 548F
→
07/27 08:32, 9月前 , 549F
結論 前面沒歪樓 後面歪了
07/27 08:32, 549F
→
07/27 08:34, 9月前 , 550F
兩個都是開發者 只是不同元件 開還是關feature?
07/27 08:34, 550F
推
07/27 08:40, 9月前 , 551F
QA不可能測spec以外的情況 測不完 跟沒有spec是一樣的 就是
07/27 08:40, 551F
→
07/27 08:40, 9月前 , 552F
不管什麼情況都要能動 這是不可能的 QA A B都沒錯 雖然B有發
07/27 08:40, 552F
→
07/27 08:40, 9月前 , 553F
現問題 但是那是B的環境有問題不符合spec A跟QA可以不理 B也
07/27 08:40, 553F
→
07/27 08:40, 9月前 , 554F
可以上feature 有問題的是spec開錯
07/27 08:40, 554F
→
07/27 08:51, 9月前 , 555F
B曝露意圖了阿 所以B更嚴重 基本上我不相信PM都有技
07/27 08:51, 555F
→
07/27 08:52, 9月前 , 556F
術底 沒有的話開不好spec他也可以
07/27 08:52, 556F
→
07/27 08:52, 9月前 , 557F
推
07/27 08:52, 557F
推
07/27 09:06, 9月前 , 558F
B再怎麼嚴重都沒有owner嚴重。不然怎麼叫 owner。owner不
07/27 09:06, 558F
→
07/27 09:06, 9月前 , 559F
用管規格Spec.不用審核產品feature上了那些，只需要領功勞
07/27 09:06, 559F
→
07/27 09:06, 9月前 , 560F
與究責？ 出錯了問題全丟給工程師？ 底下的人絕對跑光光
07/27 09:06, 560F
→
07/27 09:07, 9月前 , 561F
大家對於owner或PM的職責定義一定不同，才會有那麼多分歧
07/27 09:07, 561F
→
07/27 09:07, 9月前 , 562F
。
07/27 09:07, 562F
推
07/27 09:16, 9月前 , 563F
推DrTech，原po說自己全責，結果還想找證據弄B
07/27 09:16, 563F
→
07/27 09:17, 9月前 , 564F
搞不好原本就是a跟原po的team常弄b被搞到不爽才變這樣
07/27 09:17, 564F
推
07/27 12:22, 9月前 , 565F
最厲害的還是QA吧，安全下庄XD
07/27 12:22, 565F
推
07/27 15:29, 9月前 , 566F
推DrTech 這怎樣都不會怪到QA吧..
07/27 15:29, 566F
→
07/27 15:35, 9月前 , 567F
又不是ptt怪不怪QA的問題，是管理層眼中的下庄...
07/27 15:35, 567F
→
07/27 18:29, 9月前 , 568F
是嚴重性... 你要究責當然是樓主gg B的非常嚴重
07/27 18:29, 568F
→
07/27 18:30, 9月前 , 569F
你看了文你會覺得樓主想要A扛嗎？
07/27 18:30, 569F
→
07/27 18:32, 9月前 , 570F
這證據是有所本的 至於平常有沒有搞到B不爽這個沒證
07/27 18:32, 570F
→
07/27 18:32, 9月前 , 571F
據不用猜想...
07/27 18:32, 571F
推
07/28 00:38, 9月前 , 572F
B就敗在講太多了，不然A有種close ticket，他把featur
07/28 00:38, 572F
→
07/28 00:38, 9月前 , 573F
打開有啥問題?
07/28 00:38, 573F
→
07/28 00:38, 9月前 , 574F
但是B這種個性也很煩人，現實中AB跟原PO你大概都不會
07/28 00:38, 574F
→
07/28 00:38, 9月前 , 575F
想要碰到
07/28 00:38, 575F
推
07/28 01:33, 9月前 , 576F
你說QA直接report給老闆，是說QA跟老闆說有人故意破壞
07/28 01:33, 576F
→
07/28 01:33, 9月前 , 577F
的意思嗎?
07/28 01:33, 577F
→
07/28 01:34, 9月前 , 578F
這篇看的話B的確沒責任，但相關人士或老闆知道他可能
07/28 01:34, 578F
→
07/28 01:34, 9月前 , 579F
是"故意"的話，以後不被信任或被處理就很正常
07/28 01:34, 579F
推
07/28 01:36, 9月前 , 580F
請人代打卡就被火掉 我看公司也是早就想火他了啦
07/28 01:36, 580F
噓
07/28 09:19, 9月前 , 581F
原po問題也不會少到那，只想把整件事情推向b是故意
07/28 09:19, 581F
→
07/28 09:19, 9月前 , 582F
心態
07/28 09:19, 582F
→
07/28 10:34, 9月前 , 583F
我覺得最屌的就是B自己用什麼環境，他其實沒搞清楚
07/28 10:34, 583F
‣ 更多 pokkys 的文章
文章代碼(AID): #1alwhs5d (Soft_Job)
討論串 (同標題文章)
以下文章回應了本文 (最舊先)：
完整討論串 (本文為第 5 之 17 篇)：
排序： 最舊先 | 最新先 | 留言數
在新視窗開啟完整討論串 (共17篇)
‣ 更多 pokkys 的文章
文章代碼(AID): #1alwhs5d (Soft_Job)