我是原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主管的說法了。

B只有遇到一次,且無法複製,那就是Once,不是Always

別的不說 B的個性人品道德應該是有問題的

有些大環境的管理方式真的是很打擊前線人員士氣

B只出現一次 那把功能打開不是正常嗎 A和QA都確認過了

的確只有一次，他不是QA，也不好要求多測幾次。總之我是接受。所以B根本不需要講他是故意的話。

自爆的場合是跟你一對一閒聊？

QA建完測項沒跟PM/leader核對過需求嗎? 這補述B根本該0責 真的做出release到客戶端的是QA呀 你們這流程B當時的確就該commit了

推四樓

B不講但是B commit了 頂多責任比較少才算公正

測試沒有做整合測試也是恐怖？

這不是純一個人的問題 不可能零責的

沒錯原本以為B是無責，在我bug review找他進來幫忙時自爆，我都不知道他是哪裡搞錯。 我猜他沒有意識到現在是在討論炸在客戶的問題。 他當下也不是故意commit的，因為他只測過一次。 A mark 無法複製後，他是沒有複驗的。 我猜測他只是聽到A的bug 被客戶打出來之後想要嘴一波。

你說"原本以為" 那現在回看呢? B作業上的疏失在哪?

如果B是明知道code 有問題，但是他故意不擋，那就有責任了。 但是他不自白，沒人會知道他是故意的。 就算我事後覺得他可能只是嘴秋，但是會議上留紀錄了啊。

不講責任小 講了責任大他是統整的人還是會有小小的責任

推mindset

怎麼覺得 B 會被究責原因的在心態(用客戶HL)，不然處理的方法很合理阿。owner + QA 都說沒問題，憑甚麼要求 B 說要擋。再退一步，不管 B 心態有沒有問題，就算是他故意這樣做，不是都有A +QA 背書嗎，根因還是 A + QA 把關失誤。不過話說回來，用客戶 HL 是真的蠻猛的，自己也是會怕這樣的同事就是了XD

那再問你們這制度B該怎麼擋? 是要他承擔QA責任?這篇問題二就說了 該issue身為項目負責人的原po是給關的B真要HL是要越級申訴到大老闆嗎?

B可以向上反映 A要把什麼關...寫一個可以預知所有情

B的問題一直都不是在流程上，是個人道德問題，不管是知道還推並自白，或是知道也推但裝死，這個人格真的不行

況的程式嗎 想想也知道不可能

更何況"HL到客戶"云云更像是氣話 實際上pick commit去release的也是QA

制度設計本來就是一層一層卡關，無法要求RD不出bug, 也無法由於要求QA cover 100%。 所以最後有一個人要扛責就是我。 如果中間有人「故意」，就只能乞求後面有一關擋下來。 我講的這就是沒擋下的例子。

這就像一些常見的爭議案件，往往都是查無不法，然後一堆人就開始罵法官罵政客，但事實就是法律(過程)的角度無觸法，就算結果來說很明顯有問題也是一樣

我是認為很多推文有被原po單方說詞誤導為道德瑕疵 其實B更像是被抓住話柄被往上報的冤大頭

你可以說B工作職責上沒有問題，但他個人有沒有問題就真的不好說

故意一說 也可能是會議上被話語究責擠出來的

B 擋還要承受你又不是QA + 你又不是 func 開發者的壓力，上頭也會感到問號吧，覺得 B 你誰有權擋。阿如果客戶環境剛好跟 A 同，且有 C 也用 A func 沒事，B 擋之後還不是要被上頭 review。你可以說 B 心態差，但責任不該是他吧，又不是他亂 call A func 導致客戶環境下壞掉

這都是一樣的 每個人都會被釘 除非能夠無視於環境差

結果B也沒重現bug 感覺只是想嘴臭一下而已 其實不是故意的

異 否則A控不了 糞code也都是沒辦法的原因QA用的環境也都是共用的我不相信 你說他說那種話不是故意的 他自己都說自己故意的

這要看怎麼問 技巧性的釣話也可問你"你是故意commit的嗎?" 當你明知道bug不是你出的時候有誰會說"我code是不小心commit的"

用公司內的沒問題 環境錯了100%錯 沒人知 ㄚ他怎麼測...

調查中真正該問的是"有疑慮怎不提出來" 而不是"你是不是故意進code?"

對啊，不能把關，不能預知所有狀況，對於A B QA 甚至原po都一樣，不要求A B 原po 擋，那為何能要求B要擋，根據他的心態究責呢。免不了重複， B 心態讓人害怕，是我也怕跟他共事，但抓他的心態要扛主責，我也只能想出可能是用客戶HL ，這個對公司方蠻危險的心態吧，不然他的作為自己還無法理解不合理之處

以原文是故意的 除非他不講 不講就責任少

但主持會議的就是給issue過的原po 球員兼裁判當然不會把火往自己身上引

沒說B要擋 我覺得懲罰算公正 只是覺得B非常嚴重所以沒訊息可以分析 這不就跟有人假設他沒講一樣ㄚ

我在文章後面補了一段處理B的過程，有興趣可以卷回去看。

樓主出來了沒見到B 你不信 覺得是球員兼裁判那也沒辦法

最大的鬼故事是貴公司產品有不少跟機率性資料毀損同等級的issue，還敢直接release到客戶的production環境吧

話說 重大異常點沒有埋log嗎 可以聚焦可能的問題點

有埋log,但是出問題的地方是IO, 多到爆炸無法全log出來

B看起來很像是普通的白目吧

補的其實說的與原文差不多 最後有無測不影響關鍵

補充的B處理不正是說明B沒有"release bug到客戶"的意圖嗎? 他是要凸顯問題還在 看能不能被後來QA release前抓到呀

最荒唐的是feature也好A的功能也罷，都是測項而不是環境

我是不懂原po為什麼會因為氣B沒有被火而離職啦(前篇1:30原po推文推文)

退一萬步來說A的功能就是環境，那打死就是覆蓋率太少了

還是說其實這件事是要體現說話和詢問的技巧（x

我調解完後，我覺得B跟B主管有串過，想逃一些責任。想規避明明測過還release這件事，但是我苦無證據 XD

他的意圖就是要highlight 客戶端只是工具 誰管你是否

我會氣是因為，我最終也在老闆那邊幫他們講話。但是他們在老闆那邊是在婊A，我覺得大家沒有互相。

要炸客戶 炸了公司倒是真的肯定沒有要搞客戶 搞公司是真 只是順帶搞到客戶當然沒有搞客戶的意圖

挑commit release明明是QA幹的 把沒測出來都責任往B身上丟上 這卸責手腕我給100舉報B的是QA

我覺得QA也是想脫身.......XD

B真雖

B就把feature commit上去 這commit本來就很關鍵沒有人要付全責 指的是B特別嚴重 你反應不用那麼大我沒說這件事B要全扛 倒是看到有人說A要全扛

真要說根因我會認為需求根本沒釐清 從上到下LAGG都不在團隊視線範圍內 B也是意外才打到這個測項沒有的情境

以結果來說 產品出現大失誤每個人都有責任。以軟體工程角度來看 功能的測試情景會缺 表示需求到捕捉需求的測試不到位

LAGG修掉了 結果在客戶那邊炸開? 想也知道就是B在搞鬼

打到 fail case 的 B，直接變事主。沒要你擋，但你心態不行，所以責任最大，不知道我理解對不對

只要A的BUG比LAGG修正早一步Release出去 就是炸

B沒講原po不會知道 但樓主是被搞到不爽吧 心態問題其次

B是唯一測到BUG的, 後面說詞也顯示出B知BUG未解然後B還commit下去 這已經違反專業道德了

回giacch, B最後是不承認他release前有測過，所以就.....

如果心態是其次，那會認為特別嚴重的主因是什麼？我還以為是因為他有要用客戶HL 的奇葩想法才會究責，不然照上面說的，沒要他擋，那他不就只能把整好的code 傳上去，還是說你要說他可以選擇不開啊XD

對啊就不要開啊，也許想到又有bug又不會出錯的方法commit這樣就能兩全其美了

如果B跟主管真有套過 那還真沒套好 commit前沒測過這點是可以抓著鞭的 他們該套的說詞是"有測過,但因為LGAA測項修好沒測出來所以commit" 保證責任一乾二淨

有測過也沒辦法釐清為什麼他會確定沒有解掉 XD有一個時間序沒有講清楚，我跟他主管達成共識不是會議上

套過那句就不會出現了

是在找到LAGG是主因的會議上，所以第二個會議還不知主因

直覺吧，若issue狀態是close則是解掉，沒有則是別的狀態

mouthly release

第一個/跟處理B的會議時間是同一天。找到主因是另外一天

…我怎麼覺得現在像在玩海龜湯

撲朔迷離 XD, 其實我覺得有一部分真相我都沒搞懂。

餅乾盒子比較經典

想問一下，如果遇到 B 的狀況 484 最好的處理方式是：測到就舉手說有。然後 A 沒解 close後再測一次，如果有，就繼續卡住並向上報，卡到 B 的主管來找原po 說話，如果測出沒有，那就串沒問題。阿如果沒機會再測一次，就說沒再測，反正 A 說無法復現，大概是我環境問題吧

我總覺得A/B之間的恩怨，還有B/B主管的說法。我是有懷疑的

要看你是誰，下游user還是上游kernel

提出一個問題，結果要花一堆時間被人問，最後還要扛責

不是 B看起來就沒有要解決的意思啊...他要讓這件事爆也不是用客戶highlight吧 不知輕重耶

所以b要怎麼做，繼續卡feature幾個月？還是要自己跳下來幫a找bug在哪

jira的cannot reproduce這個tag感覺也有問題，有出現過問題就代表系統一定有個狀態會是有問題狀態，但cannotreproduce一般的確是可以把issue close掉的，這樣會誤導issue追蹤

要說是highlight但不是典型的算帳highlight而是'你看看你'這種的highlight

還是每個close的都要再檢查一次？

真的想知道 B 的最佳解是什麼，不要說是下來解決 bug XD

跟民主選舉一樣吧，定期輪換function owner避免沉淪腐敗好的制度下，不會有人能擺爛的

最佳解應該是練習回答，他們是用b的回答定罪吧

如果這樣的話真的變相鼓勵大家測到問題不要說，不然卡會被自己主管說話，不卡出問題要被究責，還不如裝沒事直接串看來真的要練習說話了XD

B就確認自己的測試情境,把自己遇到的情況上報,給主管決定就好

所以我覺得是制度有問題，或是主管要幫扛吧

上層的主管/PM Owner都同意無法複現,風險可承擔,就沒他責任如果後來還是炸了,頂多檢討一下當初review怎麼沒考慮到這case但不至於弄到黑掉...

聽起來B除了神經接錯線自爆外，好像沒什麼問題吧

另外如果要討論PM遇到這種情況,該怎麼決定放行還是block那又是需要更多公司文化的資訊了...

沒有拿 monthly release 來做最終測試?

喔對,第三篇ryancho推文的做法就是合理(但非積極處理)的做法

下場是被摘得一乾二淨哪裡是合理解要配合公司文化，大公司可以小公司不行

他好像意思是後來爆了,但沒他責任的意思?

文章有提到 通過測試release 看來SOP該改了

ryancho的做法前提是記得你發的bug沒有真的解耶

怎麼大多都在討論責任 不覺得搞定問題比較有成就感嗎?

B怎麼做...就提供測試基準資料和保證自己寫的沒問題

你覺得搞定問題有成就感,有的人覺得準時下班有成就感啊..

r大的做法感覺要有充分自信才敢說的出來 XD

就好...

問題不是早就搞定了嗎，剩討論人或制度？

問題印象中原 po 最後有找到原因了吧，忘記哪裡提到了

反正我覺得整個故事裡面槽點很多.. 然後一堆人討論超久 XD

是蠻多怪怪的地方，但看不同觀點討論還蠻好玩的 XD

問題是炸了 不是搞定 感謝善後 好人一個 替客戶感謝原PO

我有點小疑問(先承認我不清楚LAGG是啥XD)你說所謂的「錯的環境」是怎麼定義的，既然客戶的環境跟B的環境一樣，這樣還算是錯的環境嗎?

我猜(雖然也不懂LAGG)這邊的錯的環境指的應該是當時界定需求的環境。而從上面貌似客戶環境沒被納入當時界定範圍，所以才會說所謂錯的環境吧錯的環境:界定需求的環境之外，剛少打最後的之外

如果是要release給特定用戶的 (而且這客戶的環境也裝了這個LAGG) 那不是應該認定有LAGG的才是「正確的環境」嗎XD

對啊，所以後面才會有原 po 說當時如果當初有界定好環境，可能可以避免資料遺失發生至少 QA 甚至更前面就能發現問題

原始那篇"A認為他複製不出來這個問題，肯定是B把自己環境搞砸"這段來看A的心態就很有問題啊，不然你們公司大可以去跟客戶說他們把自己環境搞砸不是？當A這樣認定你們部門還讓A把bug關閉，那這個功能你們部門決定要上的意圖不就很明顯了？B想卡變成要自己去證明他的環境沒有問題嗎？再來B要不要考慮如果他真的堅持己見往上呈報後你們還是硬上，結果在客戶端和你們QA結果一樣沒問題時，B是不是反而變成個沒事找事的麻煩製造者？

這個上面有提到，覺得 B 沒那個理由也沒權力擋，所以我很好奇B 要怎麼做才行。剛剛看下來大概就是 x大說的，向上呈報由主管和pm 決定風險可控放行這樣

B就錯在他那句「我就是要highlight他啊」 XD

真的 說那句真的奇葩 XD

不是不該講出心裡的話 而是不該有這種想法還付諸行動然後還誠實到講出來 XDD

推樓上推錯~推wmtsung

同意 我的意思的確也是不該這樣想，想用這樣方式 HL(但當然講了才會知道)

B確實敗在那張嘴，不過要講成都是B在搞或是B責任最大我是覺得也太過

嗯，我也是認為 B 不應是責任最大的。不過有些會覺得拿客戶炸這心態要看最重，能理解但不認同XD

認真問，這樣多一台B的機器跟環境成本很高嗎？

應該不是成本問題吧 主要還是沒考慮到要設置跟客戶一樣的

為了單一無法再現的bug再生一台機器不符比例 歸根結底問題還是在需求沒弄清楚 甚至可以說B測出有問題時的環境不符合RD收到的需求

前面有講b沒機器可以借，後來才沒法靠b的機器復現，所以是什麼問題讓b的環境不能複製？不是反過來先說不能復現然後成本很高ㄋ= =

我認為原文的B release feature給客戶讓一些人以為是B把成品直接出給客戶吧？B只是上了自己那部分沒問題的code，bug都關了B還不上code，那feature還不能動的責任就會變成B的部分還沒完成…從組織來看只有B和大家不同bu，B就只是來支援A部門這個案子，怎麼可能B能自己release給客戶？真要說炸客戶的不是B而是A的bu啊

其實整個看下來也是滿多奇怪的地方啦...B是上層feature的開發者 要用到A開發的kernel function然後B只try了一次就炸=100%這點我先不吐槽但說起來就是B完全沒call成功過A的function這樣為啥會認為自己的東西做完了然後就放心的commit XDD

照原文來看是有call成功，只是會造成資料損毀，而這個資料損毀的情況在A與QA那邊不會發生上層所謂的feature有時候可能只是做個簡單的UI、流程或開關而已

XD原文不是說只測1次 然後1次就爆炸=100%撞bug

高壓下面一堆怪人

只測一次確實也蠻瞎的，我猜也是因為這樣B不敢往上HL，既然A認定是環境問題那就當作是了

整件事情以流程來看當然幾乎是原po跟A還有QA的責任為主，但是我認同原po說的鬼故事點，應該是說前提是這些沒有被誇大，只不過這都不能算是B陷害誰，因為按照流程沒抓到問題還是會release。我覺得最有問題的是B的心態跟想法，不確定是不是那種個人英雄主義作祟的人，基本上本來就是原po那個BU幾乎要負全責啦，所以在公司層面的檢討的確重點也應該放在怎麼再避免bug reproduce不精確的問題，而B就是把本來單純就事論事的事情變成了對人不對事情的鬥爭，B的這些嗆聲操作完全不能解決問題還會影響士氣並且模糊焦點，基本上如果對B的描述屬實，那這樣子的人的確不該是任何公司需要有的員工，他真的是最糟的那個，會讓問題都複雜化淪為無意義鬥爭

B只是嘴控制不住吧，bug也發report了，也不在他的code裡，QA和PL也說不能重現，他不commit留著等被你們催？他只是知道這問題沒人改一定會爆，但不知道何時會爆阿

原PO沒有魔改的話，B就是故意要讓他在客戶端爆。並不是控制不住嘴巴...

甚至退一萬步說我真的覺得B就是可以讓東西上線並且沒有什麼責任，問題出在他要在旁邊靜靜看事情，而不是用很像是炫耀的方式去說出這些事情，重點是講出來後，就會變成是浮上檯面的鬥爭，那公司氣氛怎麼不會被搞爛？

簡單說，一開始就認真來測這項，不會無法復現，畢竟你們最後還是成功復現了。不要隨便當作他是機率問題，畢竟是資料全毀的bug。客戶炸掉前說做了什麼什麼都無法復現，客戶炸掉後認真查能復現，就一開始太草率了。以前也遇過主管跟我說某個race condition機率很低吧，不用處理，不用把code寫到這麼複雜，我也是笑笑

老實說啦 正常來看B應該是0責但他自己嘴賤 但說真的嘴賤如果有責任那就有點思想審查的味道了這件事其實該原PO全責的

B的責任不會是在這個功能的成敗，而是他破壞了公司的文化，不是什麼皇城的和氣而是他直接表達我就是要鬥爭，公司不處理這種人一定會有離職潮

我感覺貴公司最大問題是部門內鬥B用客戶端搞同事 QA用B說法搞B這種公司我是建議塊逃

認同wmtsung 是你們部門擅自認為這個bug沒什麼的，B被你們這樣講之後根本沒有立場卡release，還有關於老闆面前婊A的事情，A就是最該死的那個哪有婊不婊的問題，A寫了一個有機率炸掉資料的function，那種處理態度是怎樣，怎不去跟客戶說你們環境有問題啊？

B 不開口沒事,後續開口說我就是要讓客戶知道A寫爛CODE. 站在A那邊的都要用客戶爆掉的代價HL. 無論是不是故意或著只是中二魂爆發.這人我是覺得有更適合他的地方.

QA 直接 先 report 老闆，這心態很可議.....B 是明明就很好推掉的事情，就自己自爆掉

看完以後，真的覺得原PO才是最鬼的。還敢上網來公審A與B原Po就是職場上最鬼故事的主管啊。不願意扛責，專門事後第一件事情先檢討別人。分析root cause後，根源在哪？完全不在A與B吧。不是檢討root cause，而是引導風向檢討別人說話態度不對，難怪科技業老人文化被人看不起。

放這麼多技術細節上來，是等不及想讓B知道你在論壇上公審他？這 EQ 我覺得不行

我看起來是A在雷啦 但不否認B的處理方式太衝

其實你是想檢討B吧 不過B的確是不行應該是回報完後 放者讓主管橋 自己不是主管 就別管那麼多

B回報的BUG無法重現, 不就是BUG的責任? 風向好亂 XD

B就一條腸子通屁眼的人，但鍋讓他背，那我會覺得是政治化了

同樓上。這個Bug與客戶損失，是B亂說話造成的嗎？明明就不是。還在扯B亂說話。

發現問題的是B, 知道問題沒解決就啟用且commit下去這就是炸客戶的主因, 如果不啟用, 或不commit, 都不會炸只要炸彈還在手上, 還是可以想辦法解, 結果B丟出去不是嗎?

不 真正啟用的是QA 我認為B在那個時點commit是應當的他的失誤是沒有在commit前再run一次 但從事後反推可以得知 就算他run了 因為LGAA已解他也是打不到bug的

QA測不出來就是第二順位啦說LAGG早就解掉, 卻還能踩到? 根本就是有鬼

B發現被mark無法複製之後，B就把feature 打開commit上去。(我當時不知道他是故意)…我是認為原po這裡不用講什麼

第一順位也不是B呀 注意身為PL的原PO看過issue是同意關

又來輪迴 B 發現問題，那是誰寫那份 code 的（A)，誰測保證沒問題出 code 的(QA)，難不成 B 還要幫 A把 bug 解掉，還是要卡讓東西不動，更何況在這情境下，B 的環境才不符合這算法使用場域 （當初界定範圍沒有考慮到客戶情境） A QA 原 po 都給過，B 不就只能摸摸鼻子傳上去，最後客戶環境資料壞掉，然後反過了來因為 B 的心態究主責。可以說 B 心態會影響團隊士氣，所以懲處，這邊可以理解，但他的作為，要說B 要為客戶環境炸掉扛責，也是蠻神秘的，只能說 AQA 甚至原 po 說話挺聰明的

to sir 功能是B啟用的

pick commit+release都是QA

B應該不要啟用這個功能, 因為有資料毀損的風險

啟用功能內部測試才更有可能測出問題不是嗎?

這裡特地寫B故意我是不知道有沒有什麼特別的意圖，只是B在那個時候有等你們bu把這個bug重啟解完再上的選項嗎？

若還在內部測試不會到release吧 應該在beta或test

沒有 因為bug close不會有人去解的QA pick commit表示至少還要再build一版 正常來說這裡會測過以後再release 如果測出問題就不會用有問題的commit了

若B能協助A重現BUG A就會去解, 但沒有 A無能為力對, release測了沒問題, 到客戶那邊變有問題, 所以QA該死

本來就QA的問題 還有code review的人也放掉這個問題

哈哈 QA有問題的其實也不是這個時點 而是更早建立測項的時候就沒有cover需求(不確定是PM或是PL的鍋, 也可能是客戶真的沒講清楚 這就開發日常)

很多人討論事情的時候在用上帝視角看這件事 只有B看到這個bug所以B應該怎樣怎樣 但實際上在開發的時候有解不完的bug 只能挑重要的先解 剩下的時間夠看可不可以清完 如果有上帝視角 那軟體就不會有bug

聽你的說法，我也會覺得bug一定還會在而且一次就中 覺得100% 也是很正常的所以客人不就遇到了嗎?因為時間的關係，沒有找出為什麼複製不出來 才是重點

原PO想表達，只要有bug就不會commit進去的意思嗎？

即使你今天有1000個Issue。會毀損資料的 Bug 會被列為不重要，可隨意關？主管或owner還可以 讓工程師Merge到 release版本？ 最後出事了再來檢討工程師。真是爛公司耶。

問因此才發出這一串故事文 有問題固然會出事 但這不是原po想講的

工作量多少，跟此事件無關。工作量多就可以放bug進release？ 正常公司怎麼可能。

又拿close說嘴了 close不能掩蓋B知情 而且之前回覆你顯然沒在看 真正好的公司那你就應該限制別人close 而不是給人可以任意close 這事件不是只有B是工程師 A都

這樣想想當 A 好賺，寫出爛 code，有 QA 幫忙把關，還有 B 要幫忙擋，不然就是你明知有問題還 commit，甚至還有原 po 協助"釐清"事情，怎樣都不是 A 寫爛的問題 XD 這樣還可以不爽到離職

是工程師 Qa都是測試工程師 你說的沒錯這是個不是很好的公司 但不能替B的惡意解脫除非你能找到技術細節 不然你要如何得出A寫得很爛的結論 沒講A沒問題 只是B問題更大 懲伐兩個人是一樣的會離職就是A對這件事的態度 但誰知道A因為什麼理由離職？ 當然用你們替B開脫的說詞解讀A肯定會得出A好懲罰

嘿我有不同見解 這件事根源是在需求就沒搞清楚 請問這是A或B的鍋嗎?再來對於issue close, PL都下來看過issue也同意解法給過那麼責任就已經是在PL這裡了接下來B沒run過就commit可以算他一筆 但就結果來說(LAGG已解 run也打不出bug) 他這個過失根本不影響最後會爆在客戶那 整件事故的究責不該燒到他甚至嚴格點說 LAGG就不在最初RD收到的spec裡 B報這個bug反而還不符合需求環境咧我認為A真正不爽的對象會是他的主管也就是原PO,責任明明該在PL頭上最後受罰的卻是底下RD

原po都背鍋了... 早就被懲處了 而且不知道原po 職位是否有涉及需求...

你一直很糾結B的惡意，但很多人看到的是萬一今天是換成更聰明的的人從頭到尾都沒透漏這問題，軟體還是會因為issue close release出去，客戶還是要炸掉，這樣有沒有B的垃圾話有差嗎

不用假設 假設情況早就推論出來了 B懲罰會小 這是說故事不是寫故事要劇情走向分析

super你看下這篇原po提到的錯誤三 基本上客戶端需求他跟QA應該是可以弄清楚的 但這點沒做好

從 sir 大的分析好像能大概理解 A 會不爽的原因了

那是原po自我檢討 比較認真的主管會這麼做 不認真就純PM的規劃大家說經驗 那我的經驗就是沒看過主管很認真的

我個人會定調這就是個事故 而且最後客戶資料也有救回來實質上的損傷是很小的 如果公司真的無法承受那該改進的是更嚴謹的流程 若還要下懲處那還是快逃吧 (除了B該因為上code紀律問題扣點考績)

老闆不覺得小事故阿...

樓主都解釋成這樣…樓上還在各篇文跳針

樓主只是客氣 不要事情都歸咎B 哪裡跳針你倒是說說回應不到整天說人跳針邏輯差 證據呢

不就你自己也覺得可以close 有主管擔當就跟B主管喬人力把B調來幫忙 拉不下臉就你自己要扛B開bug你沒任何改動哪可能就問題憑空消失 膝蓋想也知道

原po已經負責 B是真的誇張 原po會懷疑不是沒道理

B就單純講話機掰而已 就沒再雞婆找B主管說A team亂close

網路加儲存設備加os 普安？

都蓄意而為還單純機掰 洗地也不要洗成這樣

s大開的bug被別人close掉的每個都有去追嗎不要意見不合就說別人洗地好嗎，另一邊角度你才在洗地

bug不會是我開 我會跟人講這有bug 然後別人開給我的我會去解 會延續一段時間沒什麼問題會close掉 A遇到的我沒遇到過 但有類似我都是踢回去 並不是意見不合說別人洗地 是依照原po所說B是罪證很明顯了 原po即便管理不怎麼好都不是B亂搞的理由 因為這是各自的過錯拿樓主去洗白B的洗地 就是這個意思亂洗說B沒錯更是把過錯替B推的一乾二凈

我同意B沒有run過就commit是有問題的 但我想爭執的點不在這假設今天B實際上在commit前run過 且從原po事後回推我們可以得知 當時LAGG的測項問題已經解掉 所以A的bug不會被他打到 但若你身為B確信該bug並沒有解掉 你會如何行動?

當然暫緩把該feature更上去 雖然都不會是我推的 畢竟我一直都在底層

只是卡著不上code? project leader來催你呢?

B畢竟角色是整合的人 不然A的repo干他屁事把可以上的先上 B中途跑去其它功能這是個非常好的理由

我們單講這個project就好 你認為這邊B不能上的理由在哪?B的心證嗎?

他們急著上就叫他們自己commit不能上的理由就是驗證時間過短

要等多久驗證才夠?

以B來講是可以複現的 但這需時不一定 因為誰知道這技技術細節是什麼

沒有 以B來講已經無法復現了 因為LAGG測項已經修掉了如同這篇B主管跟原達成的結論

其實「之後有人發現網路測試中，LAGG沒有拆掉，導致後後面一堆測試錯亂，所以『修正』了。」這件事本身就是警訊，但是除了Manager外大家都會覺得跟我無關。Manager/Owner又不是一線測試人，可能事後調查才知道。就悲劇了，我是覺得表面上再理想的制度都會有執行面的問題。這Bug如果不放過，不管是A/B/QA再測幾年都無法復現。

你不會一點記憶都沒有 只是要回想

也是有辦法啦，所以測試都全程側錄，我知道有單位用過但是太耗時間和資源反而造成開發延宕。

如果在個人電腦突然消失你不會覺得很奇怪嗎

當然，但是「理論上能想起來」實際上是很少有人想起來

所以我可以理解為 super願意把自己整合的code交給別人commit 是吧?

開發時就是要相信自己 我相信B都是這樣 只是他沒續測

我只會負責自己的repo 因為未知就災難

我還以為只是對fail fast見解不同 原來連合作模式都不一樣 好喔

計算機的世界早就變得很複雜了 所以我喜歡簡單的東西容易掌握 也會對複雜的東西嗤之以鼻 就是要簡單實現一樣的功能或用簡單的東西

B為什麼會自爆？因為他當初是故意的，所以他才一定要讓你知道他的故意，不然他的故意就只有他一個人知道。

看完這是你們A team有問題啊B比較像是講氣話

沒紀律沒溝通 出事找基層扛 也沒檢討自己 有一就會有二一樣的情境下次還會發生你難道看不出來嗎?

不要再戴有色眼鏡了，公司會招聘新人，訓練新人成整合者然後整合者需要一一確認已經close的issue並且親力驗證直到不想幹換下一位新人當整合者的這是公司文化差異，工作模式差別沒有對錯

看完整串我只覺得這QA有夠廢

都承認是蓄意的怎麼會是講氣話？ 首先你要事情還未發生說的才是氣話 事後講的你不就是在解讀這事件只有QA與B主管沒在懲處名單 其它都在 包函樓主包含所以不是有事基層扛 考績爛不會爛永遠 B都有考慮這點當然有公司內部佈局很不好 看了這事件會覺得這公司很好的應該很少應該講好的沒幾間 要是我我都待不久 會拒絕很多東西

QA只作測項沒問題，除非這公司要QA作到自創需求和Spec

原PO有自我檢討？看看第一篇那種口吻吧。先戰AB，結果輩鄉民戰翻了，才發第二篇解釋，而且不是針對根本問題處理與調整心態，還在大談別人的錯。

因為樓主一直覺得有人在搞他 也確實有這可能 而他覺得是B 我目前也覺得是B 但B主管訊息不知 ㄒ很可能是藏鏡人 那些錯誤點樓主不深入調查也不會知道的技術細節很重要 不然怎麼知道媒介或坑到底是什麼...其實第一篇與這篇差不多 藉由第一篇分析就差不多 只

樓上一定是注重技術的人，認同。但工作的流程也非常重要。一個開發者，可以任意開feature，不用owner審核，出了事情owner卻去怪開發者。這種流程，人會跑光的。

是這篇確認而已 本來第一篇就可以得到大家都有過失的結論 前面沒歪樓 後面歪了兩個都是開發者 只是不同元件 開還是關feature?

QA不可能測spec以外的情況 測不完 跟沒有spec是一樣的 就是不管什麼情況都要能動 這是不可能的 QA A B都沒錯 雖然B有發現問題 但是那是B的環境有問題不符合spec A跟QA可以不理 B也可以上feature 有問題的是spec開錯

B曝露意圖了阿 所以B更嚴重 基本上我不相信PM都有技術底 沒有的話開不好spec他也可以推

B再怎麼嚴重都沒有owner嚴重。不然怎麼叫 owner。owner不用管規格Spec.不用審核產品feature上了那些，只需要領功勞與究責？ 出錯了問題全丟給工程師？ 底下的人絕對跑光光大家對於owner或PM的職責定義一定不同，才會有那麼多分歧。

推DrTech，原po說自己全責，結果還想找證據弄B搞不好原本就是a跟原po的team常弄b被搞到不爽才變這樣

最厲害的還是QA吧，安全下庄XD

推DrTech 這怎樣都不會怪到QA吧..

又不是ptt怪不怪QA的問題，是管理層眼中的下庄...

是嚴重性... 你要究責當然是樓主gg B的非常嚴重你看了文你會覺得樓主想要A扛嗎？這證據是有所本的 至於平常有沒有搞到B不爽這個沒證據不用猜想...

B就敗在講太多了，不然A有種close ticket，他把featur打開有啥問題?但是B這種個性也很煩人，現實中AB跟原PO你大概都不會想要碰到

你說QA直接report給老闆，是說QA跟老闆說有人故意破壞的意思嗎?這篇看的話B的確沒責任，但相關人士或老闆知道他可能是"故意"的話，以後不被信任或被處理就很正常

請人代打卡就被火掉 我看公司也是早就想火他了啦

原po問題也不會少到那，只想把整件事情推向b是故意心態

我覺得最屌的就是B自己用什麼環境，他其實沒搞清楚

我自己如果是A，複製不出來如果要改status應該是退給B不會轉給QA，就算真的轉到QA複製不出來也會跟A+B討論吧

覺得三方都蠻衰的，複合情境難免漏測，但讓你們心累認為是鬼故事的應該是B的態度

呵呵呵 講了這麼多，出問題那段code誰寫的？A 100%全責

B只有遇到一次,且無法複製,那就是Once,不是Always

別的不說 B的個性人品道德應該是有問題的

有些大環境的管理方式真的是很打擊前線人員士氣

B只出現一次 那把功能打開不是正常嗎 A和QA都確認過了

的確只有一次，他不是QA，也不好要求多測幾次。總之我是接受。所以B根本不需要講他是故意的話。

自爆的場合是跟你一對一閒聊？

QA建完測項沒跟PM/leader核對過需求嗎? 這補述B根本該0責 真的做出release到客戶端的是QA呀 你們這流程B當時的確就該commit了

推四樓

B不講但是B commit了 頂多責任比較少才算公正

測試沒有做整合測試也是恐怖？

這不是純一個人的問題 不可能零責的

沒錯原本以為B是無責，在我bug review找他進來幫忙時自爆，我都不知道他是哪裡搞錯。 我猜他沒有意識到現在是在討論炸在客戶的問題。 他當下也不是故意commit的，因為他只測過一次。 A mark 無法複製後，他是沒有複驗的。 我猜測他只是聽到A的bug 被客戶打出來之後想要嘴一波。

你說"原本以為" 那現在回看呢? B作業上的疏失在哪?

如果B是明知道code 有問題，但是他故意不擋，那就有責任了。 但是他不自白，沒人會知道他是故意的。 就算我事後覺得他可能只是嘴秋，但是會議上留紀錄了啊。

不講責任小 講了責任大他是統整的人還是會有小小的責任

推mindset

怎麼覺得 B 會被究責原因的在心態(用客戶HL)，不然處理的方法很合理阿。owner + QA 都說沒問題，憑甚麼要求 B 說要擋。再退一步，不管 B 心態有沒有問題，就算是他故意這樣做，不是都有A +QA 背書嗎，根因還是 A + QA 把關失誤。不過話說回來，用客戶 HL 是真的蠻猛的，自己也是會怕這樣的同事就是了XD

那再問你們這制度B該怎麼擋? 是要他承擔QA責任?這篇問題二就說了 該issue身為項目負責人的原po是給關的B真要HL是要越級申訴到大老闆嗎?

B可以向上反映 A要把什麼關...寫一個可以預知所有情

B的問題一直都不是在流程上，是個人道德問題，不管是知道還推並自白，或是知道也推但裝死，這個人格真的不行

況的程式嗎 想想也知道不可能

更何況"HL到客戶"云云更像是氣話 實際上pick commit去release的也是QA

制度設計本來就是一層一層卡關，無法要求RD不出bug, 也無法由於要求QA cover 100%。 所以最後有一個人要扛責就是我。 如果中間有人「故意」，就只能乞求後面有一關擋下來。 我講的這就是沒擋下的例子。

這就像一些常見的爭議案件，往往都是查無不法，然後一堆人就開始罵法官罵政客，但事實就是法律(過程)的角度無觸法，就算結果來說很明顯有問題也是一樣

我是認為很多推文有被原po單方說詞誤導為道德瑕疵 其實B更像是被抓住話柄被往上報的冤大頭

你可以說B工作職責上沒有問題，但他個人有沒有問題就真的不好說

故意一說 也可能是會議上被話語究責擠出來的

B 擋還要承受你又不是QA + 你又不是 func 開發者的壓力，上頭也會感到問號吧，覺得 B 你誰有權擋。阿如果客戶環境剛好跟 A 同，且有 C 也用 A func 沒事，B 擋之後還不是要被上頭 review。你可以說 B 心態差，但責任不該是他吧，又不是他亂 call A func 導致客戶環境下壞掉

這都是一樣的 每個人都會被釘 除非能夠無視於環境差

結果B也沒重現bug 感覺只是想嘴臭一下而已 其實不是故意的

異 否則A控不了 糞code也都是沒辦法的原因QA用的環境也都是共用的我不相信 你說他說那種話不是故意的 他自己都說自己故意的

這要看怎麼問 技巧性的釣話也可問你"你是故意commit的嗎?" 當你明知道bug不是你出的時候有誰會說"我code是不小心commit的"

用公司內的沒問題 環境錯了100%錯 沒人知 ㄚ他怎麼測...

調查中真正該問的是"有疑慮怎不提出來" 而不是"你是不是故意進code?"

對啊，不能把關，不能預知所有狀況，對於A B QA 甚至原po都一樣，不要求A B 原po 擋，那為何能要求B要擋，根據他的心態究責呢。免不了重複， B 心態讓人害怕，是我也怕跟他共事，但抓他的心態要扛主責，我也只能想出可能是用客戶HL ，這個對公司方蠻危險的心態吧，不然他的作為自己還無法理解不合理之處

以原文是故意的 除非他不講 不講就責任少

但主持會議的就是給issue過的原po 球員兼裁判當然不會把火往自己身上引

沒說B要擋 我覺得懲罰算公正 只是覺得B非常嚴重所以沒訊息可以分析 這不就跟有人假設他沒講一樣ㄚ

我在文章後面補了一段處理B的過程，有興趣可以卷回去看。

樓主出來了沒見到B 你不信 覺得是球員兼裁判那也沒辦法

最大的鬼故事是貴公司產品有不少跟機率性資料毀損同等級的issue，還敢直接release到客戶的production環境吧

話說 重大異常點沒有埋log嗎 可以聚焦可能的問題點

有埋log,但是出問題的地方是IO, 多到爆炸無法全log出來

B看起來很像是普通的白目吧

補的其實說的與原文差不多 最後有無測不影響關鍵

補充的B處理不正是說明B沒有"release bug到客戶"的意圖嗎? 他是要凸顯問題還在 看能不能被後來QA release前抓到呀

最荒唐的是feature也好A的功能也罷，都是測項而不是環境

我是不懂原po為什麼會因為氣B沒有被火而離職啦(前篇1:30原po推文推文)

退一萬步來說A的功能就是環境，那打死就是覆蓋率太少了

還是說其實這件事是要體現說話和詢問的技巧（x

我調解完後，我覺得B跟B主管有串過，想逃一些責任。想規避明明測過還release這件事，但是我苦無證據 XD

他的意圖就是要highlight 客戶端只是工具 誰管你是否

我會氣是因為，我最終也在老闆那邊幫他們講話。但是他們在老闆那邊是在婊A，我覺得大家沒有互相。

要炸客戶 炸了公司倒是真的肯定沒有要搞客戶 搞公司是真 只是順帶搞到客戶當然沒有搞客戶的意圖

挑commit release明明是QA幹的 把沒測出來都責任往B身上丟上 這卸責手腕我給100舉報B的是QA

我覺得QA也是想脫身.......XD

B真雖

B就把feature commit上去 這commit本來就很關鍵沒有人要付全責 指的是B特別嚴重 你反應不用那麼大我沒說這件事B要全扛 倒是看到有人說A要全扛

真要說根因我會認為需求根本沒釐清 從上到下LAGG都不在團隊視線範圍內 B也是意外才打到這個測項沒有的情境

以結果來說 產品出現大失誤每個人都有責任。以軟體工程角度來看 功能的測試情景會缺 表示需求到捕捉需求的測試不到位

LAGG修掉了 結果在客戶那邊炸開? 想也知道就是B在搞鬼

打到 fail case 的 B，直接變事主。沒要你擋，但你心態不行，所以責任最大，不知道我理解對不對

只要A的BUG比LAGG修正早一步Release出去 就是炸

B沒講原po不會知道 但樓主是被搞到不爽吧 心態問題其次

B是唯一測到BUG的, 後面說詞也顯示出B知BUG未解然後B還commit下去 這已經違反專業道德了

回giacch, B最後是不承認他release前有測過，所以就.....

如果心態是其次，那會認為特別嚴重的主因是什麼？我還以為是因為他有要用客戶HL 的奇葩想法才會究責，不然照上面說的，沒要他擋，那他不就只能把整好的code 傳上去，還是說你要說他可以選擇不開啊XD

對啊就不要開啊，也許想到又有bug又不會出錯的方法commit這樣就能兩全其美了

如果B跟主管真有套過 那還真沒套好 commit前沒測過這點是可以抓著鞭的 他們該套的說詞是"有測過,但因為LGAA測項修好沒測出來所以commit" 保證責任一乾二淨

有測過也沒辦法釐清為什麼他會確定沒有解掉 XD有一個時間序沒有講清楚，我跟他主管達成共識不是會議上

套過那句就不會出現了

是在找到LAGG是主因的會議上，所以第二個會議還不知主因

直覺吧，若issue狀態是close則是解掉，沒有則是別的狀態

mouthly release

第一個/跟處理B的會議時間是同一天。找到主因是另外一天

…我怎麼覺得現在像在玩海龜湯

撲朔迷離 XD, 其實我覺得有一部分真相我都沒搞懂。

餅乾盒子比較經典

想問一下，如果遇到 B 的狀況 484 最好的處理方式是：測到就舉手說有。然後 A 沒解 close後再測一次，如果有，就繼續卡住並向上報，卡到 B 的主管來找原po 說話，如果測出沒有，那就串沒問題。阿如果沒機會再測一次，就說沒再測，反正 A 說無法復現，大概是我環境問題吧

我總覺得A/B之間的恩怨，還有B/B主管的說法。我是有懷疑的

要看你是誰，下游user還是上游kernel

提出一個問題，結果要花一堆時間被人問，最後還要扛責

不是 B看起來就沒有要解決的意思啊...他要讓這件事爆也不是用客戶highlight吧 不知輕重耶

所以b要怎麼做，繼續卡feature幾個月？還是要自己跳下來幫a找bug在哪

jira的cannot reproduce這個tag感覺也有問題，有出現過問題就代表系統一定有個狀態會是有問題狀態，但cannotreproduce一般的確是可以把issue close掉的，這樣會誤導issue追蹤

要說是highlight但不是典型的算帳highlight而是'你看看你'這種的highlight

還是每個close的都要再檢查一次？

真的想知道 B 的最佳解是什麼，不要說是下來解決 bug XD

跟民主選舉一樣吧，定期輪換function owner避免沉淪腐敗好的制度下，不會有人能擺爛的

最佳解應該是練習回答，他們是用b的回答定罪吧

如果這樣的話真的變相鼓勵大家測到問題不要說，不然卡會被自己主管說話，不卡出問題要被究責，還不如裝沒事直接串看來真的要練習說話了XD

B就確認自己的測試情境,把自己遇到的情況上報,給主管決定就好

所以我覺得是制度有問題，或是主管要幫扛吧

上層的主管/PM Owner都同意無法複現,風險可承擔,就沒他責任如果後來還是炸了,頂多檢討一下當初review怎麼沒考慮到這case但不至於弄到黑掉...

聽起來B除了神經接錯線自爆外，好像沒什麼問題吧

另外如果要討論PM遇到這種情況,該怎麼決定放行還是block那又是需要更多公司文化的資訊了...

沒有拿 monthly release 來做最終測試?

喔對,第三篇ryancho推文的做法就是合理(但非積極處理)的做法

下場是被摘得一乾二淨哪裡是合理解要配合公司文化，大公司可以小公司不行

他好像意思是後來爆了,但沒他責任的意思?

文章有提到 通過測試release 看來SOP該改了

ryancho的做法前提是記得你發的bug沒有真的解耶

怎麼大多都在討論責任 不覺得搞定問題比較有成就感嗎?

B怎麼做...就提供測試基準資料和保證自己寫的沒問題

你覺得搞定問題有成就感,有的人覺得準時下班有成就感啊..

r大的做法感覺要有充分自信才敢說的出來 XD

就好...

問題不是早就搞定了嗎，剩討論人或制度？

問題印象中原 po 最後有找到原因了吧，忘記哪裡提到了

反正我覺得整個故事裡面槽點很多.. 然後一堆人討論超久 XD

是蠻多怪怪的地方，但看不同觀點討論還蠻好玩的 XD

問題是炸了 不是搞定 感謝善後 好人一個 替客戶感謝原PO

我有點小疑問(先承認我不清楚LAGG是啥XD)你說所謂的「錯的環境」是怎麼定義的，既然客戶的環境跟B的環境一樣，這樣還算是錯的環境嗎?

我猜(雖然也不懂LAGG)這邊的錯的環境指的應該是當時界定需求的環境。而從上面貌似客戶環境沒被納入當時界定範圍，所以才會說所謂錯的環境吧錯的環境:界定需求的環境之外，剛少打最後的之外

如果是要release給特定用戶的 (而且這客戶的環境也裝了這個LAGG) 那不是應該認定有LAGG的才是「正確的環境」嗎XD

對啊，所以後面才會有原 po 說當時如果當初有界定好環境，可能可以避免資料遺失發生至少 QA 甚至更前面就能發現問題

原始那篇"A認為他複製不出來這個問題，肯定是B把自己環境搞砸"這段來看A的心態就很有問題啊，不然你們公司大可以去跟客戶說他們把自己環境搞砸不是？當A這樣認定你們部門還讓A把bug關閉，那這個功能你們部門決定要上的意圖不就很明顯了？B想卡變成要自己去證明他的環境沒有問題嗎？再來B要不要考慮如果他真的堅持己見往上呈報後你們還是硬上，結果在客戶端和你們QA結果一樣沒問題時，B是不是反而變成個沒事找事的麻煩製造者？

這個上面有提到，覺得 B 沒那個理由也沒權力擋，所以我很好奇B 要怎麼做才行。剛剛看下來大概就是 x大說的，向上呈報由主管和pm 決定風險可控放行這樣

B就錯在他那句「我就是要highlight他啊」 XD

真的 說那句真的奇葩 XD

不是不該講出心裡的話 而是不該有這種想法還付諸行動然後還誠實到講出來 XDD

推樓上推錯~推wmtsung

同意 我的意思的確也是不該這樣想，想用這樣方式 HL(但當然講了才會知道)

B確實敗在那張嘴，不過要講成都是B在搞或是B責任最大我是覺得也太過

嗯，我也是認為 B 不應是責任最大的。不過有些會覺得拿客戶炸這心態要看最重，能理解但不認同XD

認真問，這樣多一台B的機器跟環境成本很高嗎？

應該不是成本問題吧 主要還是沒考慮到要設置跟客戶一樣的

為了單一無法再現的bug再生一台機器不符比例 歸根結底問題還是在需求沒弄清楚 甚至可以說B測出有問題時的環境不符合RD收到的需求

前面有講b沒機器可以借，後來才沒法靠b的機器復現，所以是什麼問題讓b的環境不能複製？不是反過來先說不能復現然後成本很高ㄋ= =啊，我看到有補充說A也少考量，不過我覺得還是兩碼子事，只能說案情不單純，顆顆

我認為原文的B release feature給客戶讓一些人以為是B把成品直接出給客戶吧？B只是上了自己那部分沒問題的code，bug都關了B還不上code，那feature還不能動的責任就會變成B的部分還沒完成…從組織來看只有B和大家不同bu，B就只是來支援A部門這個案子，怎麼可能B能自己release給客戶？真要說炸客戶的不是B而是A的bu啊

其實整個看下來也是滿多奇怪的地方啦...B是上層feature的開發者 要用到A開發的kernel function然後B只try了一次就炸=100%這點我先不吐槽但說起來就是B完全沒call成功過A的function這樣為啥會認為自己的東西做完了然後就放心的commit XDD

照原文來看是有call成功，只是會造成資料損毀，而這個資料損毀的情況在A與QA那邊不會發生上層所謂的feature有時候可能只是做個簡單的UI、流程或開關而已

XD原文不是說只測1次 然後1次就爆炸=100%撞bug

高壓下面一堆怪人

只測一次確實也蠻瞎的，我猜也是因為這樣B不敢往上HL，既然A認定是環境問題那就當作是了

整件事情以流程來看當然幾乎是原po跟A還有QA的責任為主，但是我認同原po說的鬼故事點，應該是說前提是這些沒有被誇大，只不過這都不能算是B陷害誰，因為按照流程沒抓到問題還是會release。我覺得最有問題的是B的心態跟想法，不確定是不是那種個人英雄主義作祟的人，基本上本來就是原po那個BU幾乎要負全責啦，所以在公司層面的檢討的確重點也應該放在怎麼再避免bug reproduce不精確的問題，而B就是把本來單純就事論事的事情變成了對人不對事情的鬥爭，B的這些嗆聲操作完全不能解決問題還會影響士氣並且模糊焦點，基本上如果對B的描述屬實，那這樣子的人的確不該是任何公司需要有的員工，他真的是最糟的那個，會讓問題都複雜化淪為無意義鬥爭

B只是嘴控制不住吧，bug也發report了，也不在他的code裡，QA和PL也說不能重現，他不commit留著等被你們催？他只是知道這問題沒人改一定會爆，但不知道何時會爆阿

原PO沒有魔改的話，B就是故意要讓他在客戶端爆。並不是控制不住嘴巴...

甚至退一萬步說我真的覺得B就是可以讓東西上線並且沒有什麼責任，問題出在他要在旁邊靜靜看事情，而不是用很像是炫耀的方式去說出這些事情，重點是講出來後，就會變成是浮上檯面的鬥爭，那公司氣氛怎麼不會被搞爛？

簡單說，一開始就認真來測這項，不會無法復現，畢竟你們最後還是成功復現了。不要隨便當作他是機率問題，畢竟是資料全毀的bug。客戶炸掉前說做了什麼什麼都無法復現，客戶炸掉後認真查能復現，就一開始太草率了。以前也遇過主管跟我說某個race condition機率很低吧，不用處理，不用把code寫到這麼複雜，我也是笑笑

老實說啦 正常來看B應該是0責但他自己嘴賤 但說真的嘴賤如果有責任那就有點思想審查的味道了這件事其實該原PO全責的

B的責任不會是在這個功能的成敗，而是他破壞了公司的文化，不是什麼皇城的和氣而是他直接表達我就是要鬥爭，公司不處理這種人一定會有離職潮

我感覺貴公司最大問題是部門內鬥B用客戶端搞同事 QA用B說法搞B這種公司我是建議塊逃

認同wmtsung 是你們部門擅自認為這個bug沒什麼的，B被你們這樣講之後根本沒有立場卡release，還有關於老闆面前婊A的事情，A就是最該死的那個哪有婊不婊的問題，A寫了一個有機率炸掉資料的function，那種處理態度是怎樣，怎不去跟客戶說你們環境有問題啊？

B 不開口沒事,後續開口說我就是要讓客戶知道A寫爛CODE. 站在A那邊的都要用客戶爆掉的代價HL. 無論是不是故意或著只是中二魂爆發.這人我是覺得有更適合他的地方.

QA 直接 先 report 老闆，這心態很可議.....B 是明明就很好推掉的事情，就自己自爆掉

看完以後，真的覺得原PO才是最鬼的。還敢上網來公審A與B原Po就是職場上最鬼故事的主管啊。不願意扛責，專門事後第一件事情先檢討別人。分析root cause後，根源在哪？完全不在A與B吧。不是檢討root cause，而是引導風向檢討別人說話態度不對，難怪科技業老人文化被人看不起。

放這麼多技術細節上來，是等不及想讓B知道你在論壇上公審他？這 EQ 我覺得不行

我看起來是A在雷啦 但不否認B的處理方式太衝

其實你是想檢討B吧 不過B的確是不行應該是回報完後 放者讓主管橋 自己不是主管 就別管那麼多

B回報的BUG無法重現, 不就是BUG的責任? 風向好亂 XD

B就一條腸子通屁眼的人，但鍋讓他背，那我會覺得是政治化了

同樓上。這個Bug與客戶損失，是B亂說話造成的嗎？明明就不是。還在扯B亂說話。把責任與鬼故事丟給B亂說話。根本不是正常職場生態。而且B為什麼要那麼嗆，根源不就是A產生Bug，身為A的主管不負責。人家氣到不想好好說話了。B當然不夠成熟，但不到鬼故事等級吧。真的鬼故事是：自己做錯了，模糊焦點，把錯誤推給不會說話的老實工程師。這種主管喔，難怪底下的人也先走了。

發現問題的是B, 知道問題沒解決就啟用且commit下去這就是炸客戶的主因, 如果不啟用, 或不commit, 都不會炸只要炸彈還在手上, 還是可以想辦法解, 結果B丟出去不是嗎?

不 真正啟用的是QA 我認為B在那個時點commit是應當的他的失誤是沒有在commit前再run一次 但從事後反推可以得知 就算他run了 因為LGAA已解他也是打不到bug的

QA測不出來就是第二順位啦說LAGG早就解掉, 卻還能踩到? 根本就是有鬼

B發現被mark無法複製之後，B就把feature 打開commit上去。(我當時不知道他是故意)…我是認為原po這裡不用講什麼

第一順位也不是B呀 注意身為PL的原PO看過issue是同意關

又來輪迴 B 發現問題，那是誰寫那份 code 的（A)，誰測保證沒問題出 code 的(QA)，難不成 B 還要幫 A把 bug 解掉，還是要卡讓東西不動，更何況在這情境下，B 的環境才不符合這算法使用場域 （當初界定範圍沒有考慮到客戶情境） A QA 原 po 都給過，B 不就只能摸摸鼻子傳上去，最後客戶環境資料壞掉，然後反過了來因為 B 的心態究主責。可以說 B 心態會影響團隊士氣，所以懲處，這邊可以理解，但他的作為，要說B 要為客戶環境炸掉扛責，也是蠻神秘的，只能說 AQA 甚至原 po 說話挺聰明的

to sir 功能是B啟用的

pick commit+release都是QA

B應該不要啟用這個功能, 因為有資料毀損的風險

啟用功能內部測試才更有可能測出問題不是嗎?

這裡特地寫B故意我是不知道有沒有什麼特別的意圖，只是B在那個時候有等你們bu把這個bug重啟解完再上的選項嗎？

若還在內部測試不會到release吧 應該在beta或test

沒有 因為bug close不會有人去解的QA pick commit表示至少還要再build一版 正常來說這裡會測過以後再release 如果測出問題就不會用有問題的commit了

若B能協助A重現BUG A就會去解, 但沒有 A無能為力對, release測了沒問題, 到客戶那邊變有問題, 所以QA該死

本來就QA的問題 還有code review的人也放掉這個問題

哈哈 QA有問題的其實也不是這個時點 而是更早建立測項的時候就沒有cover需求(不確定是PM或是PL的鍋, 也可能是客戶真的沒講清楚 這就開發日常)

很多人討論事情的時候在用上帝視角看這件事 只有B看到這個bug所以B應該怎樣怎樣 但實際上在開發的時候有解不完的bug 只能挑重要的先解 剩下的時間夠看可不可以清完 如果有上帝視角 那軟體就不會有bug

聽你的說法，我也會覺得bug一定還會在而且一次就中 覺得100% 也是很正常的所以客人不就遇到了嗎?因為時間的關係，沒有找出為什麼複製不出來 才是重點

原PO想表達，只要有bug就不會commit進去的意思嗎？

即使你今天有1000個Issue。會毀損資料的 Bug 會被列為不重要，可隨意關？主管或owner還可以 讓工程師Merge到 release版本？ 最後出事了再來檢討工程師。真是爛公司耶。

問因此才發出這一串故事文 有問題固然會出事 但這不是原po想講的

工作量多少，跟此事件無關。工作量多就可以放bug進release？ 正常公司怎麼可能。

又拿close說嘴了 close不能掩蓋B知情 而且之前回覆你顯然沒在看 真正好的公司那你就應該限制別人close 而不是給人可以任意close 這事件不是只有B是工程師 A都

這樣想想當 A 好賺，寫出爛 code，有 QA 幫忙把關，還有 B 要幫忙擋，不然就是你明知有問題還 commit，甚至還有原 po 協助"釐清"事情，怎樣都不是 A 寫爛的問題 XD 這樣還可以不爽到離職

是工程師 Qa都是測試工程師 你說的沒錯這是個不是很好的公司 但不能替B的惡意解脫除非你能找到技術細節 不然你要如何得出A寫得很爛的結論 沒講A沒問題 只是B問題更大 懲伐兩個人是一樣的會離職就是A對這件事的態度 但誰知道A因為什麼理由離職？ 當然用你們替B開脫的說詞解讀A肯定會得出A好懲罰

嘿我有不同見解 這件事根源是在需求就沒搞清楚 請問這是A或B的鍋嗎?再來對於issue close, PL都下來看過issue也同意解法給過那麼責任就已經是在PL這裡了接下來B沒run過就commit可以算他一筆 但就結果來說(LAGG已解 run也打不出bug) 他這個過失根本不影響最後會爆在客戶那 整件事故的究責不該燒到他甚至嚴格點說 LAGG就不在最初RD收到的spec裡 B報這個bug反而還不符合需求環境咧我認為A真正不爽的對象會是他的主管也就是原PO,責任明明該在PL頭上最後受罰的卻是底下RD

原po都背鍋了... 早就被懲處了 而且不知道原po 職位是否有涉及需求...

你一直很糾結B的惡意，但很多人看到的是萬一今天是換成更聰明的的人從頭到尾都沒透漏這問題，軟體還是會因為issue close release出去，客戶還是要炸掉，這樣有沒有B的垃圾話有差嗎

不用假設 假設情況早就推論出來了 B懲罰會小 這是說故事不是寫故事要劇情走向分析

super你看下這篇原po提到的錯誤三 基本上客戶端需求他跟QA應該是可以弄清楚的 但這點沒做好

從 sir 大的分析好像能大概理解 A 會不爽的原因了

那是原po自我檢討 比較認真的主管會這麼做 不認真就純PM的規劃大家說經驗 那我的經驗就是沒看過主管很認真的

我個人會定調這就是個事故 而且最後客戶資料也有救回來實質上的損傷是很小的 如果公司真的無法承受那該改進的是更嚴謹的流程 若還要下懲處那還是快逃吧 (除了B該因為上code紀律問題扣點考績)

老闆不覺得小事故阿...

樓主都解釋成這樣…樓上還在各篇文跳針

樓主只是客氣 不要事情都歸咎B 哪裡跳針你倒是說說回應不到整天說人跳針邏輯差 證據呢

不就你自己也覺得可以close 有主管擔當就跟B主管喬人力把B調來幫忙 拉不下臉就你自己要扛B開bug你沒任何改動哪可能就問題憑空消失 膝蓋想也知道

原po已經負責 B是真的誇張 原po會懷疑不是沒道理

B就單純講話機掰而已 就沒再雞婆找B主管說A team亂close

網路加儲存設備加os 普安？

都蓄意而為還單純機掰 洗地也不要洗成這樣

s大開的bug被別人close掉的每個都有去追嗎不要意見不合就說別人洗地好嗎，另一邊角度你才在洗地

bug不會是我開 我會跟人講這有bug 然後別人開給我的我會去解 會延續一段時間沒什麼問題會close掉 A遇到的我沒遇到過 但有類似我都是踢回去 並不是意見不合說別人洗地 是依照原po所說B是罪證很明顯了 原po即便管理不怎麼好都不是B亂搞的理由 因為這是各自的過錯拿樓主去洗白B的洗地 就是這個意思亂洗說B沒錯更是把過錯替B推的一乾二凈

我同意B沒有run過就commit是有問題的 但我想爭執的點不在這假設今天B實際上在commit前run過 且從原po事後回推我們可以得知 當時LAGG的測項問題已經解掉 所以A的bug不會被他打到 但若你身為B確信該bug並沒有解掉 你會如何行動?

當然暫緩把該feature更上去 雖然都不會是我推的 畢竟我一直都在底層

只是卡著不上code? project leader來催你呢?

B畢竟角色是整合的人 不然A的repo干他屁事把可以上的先上 B中途跑去其它功能這是個非常好的理由

我們單講這個project就好 你認為這邊B不能上的理由在哪?B的心證嗎?

他們急著上就叫他們自己commit不能上的理由就是驗證時間過短

要等多久驗證才夠?

以B來講是可以複現的 但這需時不一定 因為誰知道這技技術細節是什麼

沒有 以B來講已經無法復現了 因為LAGG測項已經修掉了如同這篇B主管跟原達成的結論

其實「之後有人發現網路測試中，LAGG沒有拆掉，導致後後面一堆測試錯亂，所以『修正』了。」這件事本身就是警訊，但是除了Manager外大家都會覺得跟我無關。Manager/Owner又不是一線測試人，可能事後調查才知道。就悲劇了，我是覺得表面上再理想的制度都會有執行面的問題。這Bug如果不放過，不管是A/B/QA再測幾年都無法復現。

你不會一點記憶都沒有 只是要回想

也是有辦法啦，所以測試都全程側錄，我知道有單位用過但是太耗時間和資源反而造成開發延宕。

如果在個人電腦突然消失你不會覺得很奇怪嗎

當然，但是「理論上能想起來」實際上是很少有人想起來

所以我可以理解為 super願意把自己整合的code交給別人commit 是吧?

開發時就是要相信自己 我相信B都是這樣 只是他沒續測

我只會負責自己的repo 因為未知就災難

我還以為只是對fail fast見解不同 原來連合作模式都不一樣 好喔

計算機的世界早就變得很複雜了 所以我喜歡簡單的東西容易掌握 也會對複雜的東西嗤之以鼻 就是要簡單實現一樣的功能或用簡單的東西

B為什麼會自爆？因為他當初是故意的，所以他才一定要讓你知道他的故意，不然他的故意就只有他一個人知道。

看完這是你們A team有問題啊B比較像是講氣話

沒紀律沒溝通 出事找基層扛 也沒檢討自己 有一就會有二一樣的情境下次還會發生你難道看不出來嗎?

不要再戴有色眼鏡了，公司會招聘新人，訓練新人成整合者然後整合者需要一一確認已經close的issue並且親力驗證直到不想幹換下一位新人當整合者的這是公司文化差異，工作模式差別沒有對錯

看完整串我只覺得這QA有夠廢

都承認是蓄意的怎麼會是講氣話？ 首先你要事情還未發生說的才是氣話 事後講的你不就是在解讀這事件只有QA與B主管沒在懲處名單 其它都在 包函樓主包含所以不是有事基層扛 考績爛不會爛永遠 B都有考慮這點當然有公司內部佈局很不好 看了這事件會覺得這公司很好的應該很少應該講好的沒幾間 要是我我都待不久 會拒絕很多東西

QA只作測項沒問題，除非這公司要QA作到自創需求和Spec

原PO有自我檢討？看看第一篇那種口吻吧。先戰AB，結果輩鄉民戰翻了，才發第二篇解釋，而且不是針對根本問題處理與調整心態，還在大談別人的錯。問題不在技術細節，還在大談技術細節。如果是第一篇就說明清楚，整個過程大家都有疏失，而不是只針對AB，爭議與分歧就沒那麼大了。

因為樓主一直覺得有人在搞他 也確實有這可能 而他覺得是B 我目前也覺得是B 但B主管訊息不知 ㄒ很可能是藏鏡人 那些錯誤點樓主不深入調查也不會知道的技術細節很重要 不然怎麼知道媒介或坑到底是什麼...其實第一篇與這篇差不多 藉由第一篇分析就差不多 只

樓上一定是注重技術的人，認同。但工作的流程也非常重要。一個開發者，可以任意開feature，不用owner審核，出了事情owner卻去怪開發者。這種流程，人會跑光的。

是這篇確認而已 本來第一篇就可以得到大家都有過失的結論 前面沒歪樓 後面歪了兩個都是開發者 只是不同元件 開還是關feature?

QA不可能測spec以外的情況 測不完 跟沒有spec是一樣的 就是不管什麼情況都要能動 這是不可能的 QA A B都沒錯 雖然B有發現問題 但是那是B的環境有問題不符合spec A跟QA可以不理 B也可以上feature 有問題的是spec開錯

B曝露意圖了阿 所以B更嚴重 基本上我不相信PM都有技術底 沒有的話開不好spec他也可以推

B再怎麼嚴重都沒有owner嚴重。不然怎麼叫 owner。owner不用管規格Spec.不用審核產品feature上了那些，只需要領功勞與究責？ 出錯了問題全丟給工程師？ 底下的人絕對跑光光大家對於owner或PM的職責定義一定不同，才會有那麼多分歧。

推DrTech，原po說自己全責，結果還想找證據弄B搞不好原本就是a跟原po的team常弄b被搞到不爽才變這樣

最厲害的還是QA吧，安全下庄XD

推DrTech 這怎樣都不會怪到QA吧..

又不是ptt怪不怪QA的問題，是管理層眼中的下庄...

是嚴重性... 你要究責當然是樓主gg B的非常嚴重你看了文你會覺得樓主想要A扛嗎？這證據是有所本的 至於平常有沒有搞到B不爽這個沒證據不用猜想...

B就敗在講太多了，不然A有種close ticket，他把featur打開有啥問題?但是B這種個性也很煩人，現實中AB跟原PO你大概都不會想要碰到

你說QA直接report給老闆，是說QA跟老闆說有人故意破壞的意思嗎?這篇看的話B的確沒責任，但相關人士或老闆知道他可能是"故意"的話，以後不被信任或被處理就很正常

請人代打卡就被火掉 我看公司也是早就想火他了啦

原po問題也不會少到那，只想把整件事情推向b是故意心態

我覺得最屌的就是B自己用什麼環境，他其實沒搞清楚

我自己如果是A，複製不出來如果要改status應該是退給B不會轉給QA，就算真的轉到QA複製不出來也會跟A+B討論吧

覺得三方都蠻衰的，複合情境難免漏測，但讓你們心累認為是鬼故事的應該是B的態度

呵呵呵 講了這麼多，出問題那段code誰寫的？A 100%全責