閒閒沒事來回第三篇繼續捍衛一下B
我拿我自身經驗分享一下，我在亞麻在Amazon模改的Android OS底下開發過Android Appl
ication，雖然不完全一樣但是應該有點相似
首先是討論開Ticket關Ticket的問題，如果今天用新的OS版本炸掉過一次我開Ticket給OS
組，OS組回說不可能有問題然後我也剛好沒法在重現的話，肯定是讓Ticket關了，Reopen
的條件是我馬上能在Repro一次
原因很簡單：我不負責你組的Code我不可能去看你的Code然後再跟你說你哪邊有Risk，且
確實也有可能是我自己的錯誤（環境、我自己的Feature沒寫好等等），如果你拍胸脯保
證你的OS change沒問題能進版，我在app組有什麼能力去Block你？我最多也只會在會議
裡稍微提醒說要注意畢竟沒遇過第二次，那這個問題你們整組都知道了我想絕對不是一次
溝通而已
那你說B自爆說硬要highlight這個問題，我是覺得高機率是屁話或純粹跟你們吵架而已，
他自己肯定不可能100%Repro，如果會100%發生他要怎麼開發？搞不好你走到他機器旁邊
就遇到資料毀損呢，感覺是你們組太常搞被開Ticket不解決就關的問題，這次讓你們知道
嚴重性而已
希望你們在職場上永遠不要成為B，發現Bug還要被Bug Owner甩鍋責備發現過還不堅持到
底，謝謝大家

但是B最後的自我辯護不是無法repro，而是完全沒作。然後沒測就開出去了。如果真的測了但無法repro，其實他不需要說謊。只測一次是B自己講的，100% repro也是B自己講的，所以只測一次就失敗，回報後也不複測的B，還是開發完了還

其實B沒有義務repro並跟進這個bug那是A組的事

release出去，如果他不是故意才更恐怖吧，代表他都是閉著眼開發。

現在根本沒有B現身說法唄，是只重現出一次或沒有重現出來

照上篇說法，B至少要UT，所以第一次 UT 失敗開Bug。沒完成UT當然責無旁貸。除非他說第二次UT無法repro。但他是説第二次他沒UT。

這分兩部分，UT自清或者UT高光不論他UT自清做到百分之一百都不是老闆想知道的老闆要知道這個已經在客戶爆炸的bug的UT有沒有測究責的是UT高光有沒有跑徹底，至於自清沒做到那是延伸

他的UT工作跟自清或高光無關吧，本職上就是UT自己這關的東西確認沒問題才交下一關。

這種情境要回應老闆認為的UT，簡單來說就是回應沒有做到看了好久我看不懂你的意思，什麼是自己這一關

流程： A code (UT) -> B(UT)(整合)(UT) -> QA不管有沒有 Bug 都是這流程，所以B第一次回退後，A

你是要說B UT自清 還是整合UT高光

close後再送過來的東西，B還是要UT和整合完才下一步。

整合不也是UT，什麼叫作UT和整合

B無責：A code -> B UT無法復現 -> QAB重責：A code -> B UT復現，故意放過-> QAB輕責：A code -> B 沒UT -> QAUT（Unit Test）整合（integration）IT(integ. Test)

A掛理想B behavior driver UT PASS，B 掛理想A behaviordriver UT PASS退一萬步是整合UT沒測過

但B是說他第二次完全沒作UT。沒什麼「掛理想對方作過」，照上篇原PO提到公司流程，

前文沒有提到是指B掛真A的UT，或者B掛A BM的UT 阿

每個環節都要自己作UT。

每個環節都要，這不就是系統測試了我不是刁難，而是自己的每個環節都要UT，與整合後的每個環節的UT，這兩個落差很大

B的東西要用到A，所以B的UT一定會包含到A的code不是UT階段就是IT階段。

如果貴單位覺得合理，那我承認是我錯了

啊不是，不管A寫的code怎樣，B自己要交給QA的東西自己都說沒測過，怎麼樣都說不過去吧。

對對，太不禮貌了

大家不睡覺在聊工作的事也太辛苦了吧

也是碰過有一派會說他自己寫完不用測整套,直接給QA去驗merge起來的

關鍵在於該公司的UT，是在開發者電腦上自測的而且沒有記錄。這種體制，有沒有UT其實不重要了，UT 淪為自由心證。該公司根本沒有正常有經驗的管理者。當然淪為情緒與政治之爭。如果UT是在第三方測試電腦上，B只要能成功執行Bug一次，其他人自然也容易復現Bug，也沒那麼多問題了。有沒有UT，竟然是靠嘴巴說出來的，而且大家還採信，真是奇葩公司啊。

B的UT就只是確保B自己code沒問題就好了吧 B做事類似開發UI把A的function給使用者點 至於點下去不會爆炸 那是A的UT要做的事

沒有模擬環境的測試，UT再多也是另一回事阿

這裡有個點是我覺得A這邊最該負責的，那個A要關掉bug時已經說是B把環境搞砸，那這時候B要UT什麼？B真的UT且fail那也符合A說的B搞砸環境啊B這時候無法證明自己環境沒問題也只能用在A和QA的環境下跑沒問題的結果當UT不是嗎？當然最正常的情況應該像DrTech講的，不然在被A判斷為環境搞砸時，B即使在自己機器上複驗fail也已經沒有意義

OS修好 B是feature owner總是要測過一遍吧? 這邊的問題是B自己說他知道還是會炸 不是你說的剛好沒辦法重現

B說還是會炸其實沒啥問題，因為A已經說B搞砸環境了，那就算B的環境一直fail也符合A認為可以關掉bug的條件啊

最上層 或者最接近customer端的本來就最衰 底層出了問題如果死不承認 大家還是會去追UI面 變成你要去證明是底層的問題

B有部分責任我是沒意見，但要說B故意炸客戶或是主責我認為完全沒道理

B一開始就自己說要故意炸客戶來HL啊，之後調查B主管才提出追加解釋。所以原PO才說，如果B講的真話而不是氣話那就非常嚴重。

檢討B的心境到底有什麼魔力？看到不少人包含原po很愛討論這個，正常公司就是去檢討A那端為何攔不了，盡力去補強最原始的漏洞，檢討B真的有助於公司的流程改善嗎

說B不敢交，但他就真的交了，不管是因為(1)他自己說沒測，或(2)他測了沒過還是硬交，現實就是他交了。除非是(3)他測了，沒法復現，所以安心交了。但他自己否認了這條路...檢討B很重要，就像B知道輪胎有問題，還故意組裝到車上害死人後，他不能說「輪胎又不是我作的，跟我無關。」B主管也知道不能這樣講，所以才改成「B組裝完沒再試開過，所以他只是猜測輪胎有問題，不是故意。」

B發現的問題被A說是B搞砸環境啊，你A先扣人家這樣一個大帽子再來說人家沒複測？我就問B複測fail的話不是符合A講的B環境有問題嗎？還是B要自證環境沒問題？那A說B環境有問題前有先提供證明嗎？

B是嚴重懷疑輪胎有問題，原廠回信說你搞錯了，是測試方法有問題，B鼻子摸摸把輪胎裝上去結果出事死人，那請問誰該被優先檢討呢

在A說B搞砸環境後B複測兩種結果基本上都是自己有問題啊，pass就是當初自己步驟有問題，fail就是A說的環境搞砸不可信，在那個當下A部門就穩贏的，現在還在意那個複測？

事後調查輪框上有一顆螺絲規格不合(LAGG)

今天B還可能要裝5種輪胎，B也只能看看每個輪胎外觀是否有明顯毀損，真正該知道問題並且有能力把問題修復的也只有原廠，事後出事B就在mur mur，那個我早就知道會出事了啦，請問這個系統我們該優先檢討誰呢

B不裝輪胎還會被上面的老闆罵 原廠都跟你說沒問題了 還不裝

現在就是B自己說他第二次連外觀都沒看就放行了這兩次code不一樣喔，B不管這Bug有沒有修，都要重測吧

你問我就是B, 因為B反應問題卻不協助處理, 要A自己通靈

而且B說的不是「我早知有問題」而是「我早知有問題但是

原廠是說無法重現B說的狀況, 不是說沒這回事

今天很多人糾結B沒有再測一次，那請問輪胎師父收到原廠回覆沒問題的回信後，請問輪胎師父要繼續跟原廠說，你的輪胎就是有問題，找出問題再回我一次，這樣更不合理吧

原廠送來第二顆輪胎了喔，不是原本那顆。

就說A沒保證沒問題, 是說測不出資料毀損的狀況, 中文不好?

原PO和A有改過code重新commit。

在當下B在自己電腦上測已經沒任何意義了啊，環境被判定搞砸，那用A和QA的環境來測試當結果有啥問題？

那是只是用猜測問題點來改(就是在通靈啦), 並非針對問題點

正常流程也是要找出B環境的問題，萬一客戶跟B同環境呢?

A認為他複製不出來這個問題，肯定是B把自己環境搞砸了…這首篇原po自己寫的，誰中文不好？

A懷疑B環境有問題是A要證明還是B

關鍵的LAGG是誰的, 有沒有問題, 就原PO文章我看不出來

A和B要一起查，這沒法靠單邊找出來問題。所以說兩邊不願意合作就要叫主管。

還是我們這邊請主管說有沒有讓 A B合作找問題 XD

要找出B環境問題完全同意，但我自己認為這是在A被開issue這段時間該做；就像原廠收到輪胎問題不能確定，起碼跟輪胎師父說先緩緩不要裝，而不是回信說是你環境有問題

A只寫無法復現吧，系統上通常不會白目去標是B有問題。

如果去車行換輪胎, 結果輪胎脫落, 是找車行還是原廠

找車行，然後師父裝的按照流程，就會找原廠 我猜啦

然後車行發現原廠胎有瑕疵, 之前也有發現鎖不緊的情況

對啊 但原廠說沒問題不是嗎 還是師父比原廠懂輪胎

車行有跟原廠反應, 但原廠說經測試無論胎脫落的情況

先找車行找出問題，但假設是原廠說沒問題的輪子出包，所有因輪胎脫落造成的損害要跟原廠求償

所以車行照常交車給客戶, 害客戶出車禍後續文章資料就不齊全了 => 後來車行發現同時安裝LAGG會後來車行發現同時安裝LAGG會導致輪胎脫落這邊LAGG是不是原廠, 有沒有瑕疵, 文章都看不出來

按照原文 LAGG 是客戶車上有的歐，不是師父另外裝的吧

問題就是B自己說他確信輪子會出包，故意裝上去要HL原廠

只知道不要同時安裝LAGG(或LAGG已修正? 修掉?) 就沒事對 就是剛好LAGG客戶的車上有, 所以就出車禍了

LAGG是客戶原本有，但原廠沒想到，所以這是原廠的鍋車行剛好有LAGG的車子，但是也沒想到是這問題，只想釘原廠，就變事故了。

而且這LAGG應該也是車行裝的? 那要怎麼究責呢?

別忘記B有拿到原廠的回覆信，而且最終也只有輪胎廠能修復這問題，輪胎師父能做的就是被客人罵而已

等等 LAGG 什麼時時候變成車行裝的

好修正一下 LAGG不知道怎麼來的 我只是猜測是車行(B)裝的

LAGG是客戶環境標配，不在開發案本身裏。但應該在開發前要調查清楚。

車行有沒有是未知的，只是客戶有且裝了穩定出bug

但B有踩到LAGG, 所以我是猜LAGG是公司做的功能

時間上LAGG是亡羊補牢發現，或者發覺到上新code還是錯的至於誰有誰沒有，兩邊互推串資源義務無益釐清事實

LAGG -> Link Aggregation? 所以是在講NAS喔 XD

1.是，但不是只有NAS會用。

若是分享器更新完弄壞資料, 廠商會跑來救資料也是很神奇

後來發現LAGG會造成問題的不是車行是原廠，車行的環境在客戶炸了之後原廠拿去測也無法復現，最後原廠才知道師父在測到問題前一天做過網路測試所以有LAGG

是啊 不知道LAGG是什麼也可以討論客戶車上有LAGG、LAGG是不是原廠，討論半天..在有LAGG的環境會炸掉A的能力就是很弱，不知道有什麼好說，原原Po還想要講A是RD不想讓他揹這個bug的責任我寫一個database driver給你用，在cluster環境會把資料炸掉，但是我只有在單機環境測過都沒問題啊，一定是你環境有問題，看誰聽得下去「誰叫你們不說你們有用到cluster，沒說是要我通靈解bug？」A就這態度

原PO有提到LAGG技術有不照原本順序的特性所以車行原本是編號順序裝螺絲, 結果用了LAGG技術導致導致螺絲裝錯位置, 所以輪胎就脫落了 XD

照樓上說法公司該去跟客戶說你們搞砸環境啊…

不是好嗎你在亂比喻什麼

沒有給A LAGG環境是原PO的錯, A應該只是照需求做

就事論事如果你想要比喻就拿完全可類比的範例，不要已經是不可類比的領域還硬要繼續用這個範例

不好意思 讓你困惑了 哈哈哈

我覺得B講那些話只是意氣用事，他肯定沒有能力repro如果能的話以B個性不可能不嘴一頓A/QA，然後公司面究責要以local UT的狀況當依據更是沒道理，你不能因為一個人講話機歪就說他責任最大，我還是傾向與其看一個人說了什麼，不如看他做了什麼，事實就是B已經做了他職責內能做的所有事，但A以及QA都沒有把他當一回事

我認為B不該沒驗證通過就把功能啟用 that's all

樓上，同理，那QA的職責呢？

QA失能 應該整組換掉 -> 後來看原PO說QA是老闆的人 XD

現在是B沒過QA卻過了？結果是整個開發流程有問題，這樣還算不算B的問題？

這部分就我說的，A認為B環境不可信，所以B以QA結果當驗證你也不能說他故意搞事

事實上B測第二次爆第二次也只會被A說你就環境有問題

QA過了 就扯到原PO了 沒提LAGG環境

阿如果他堅持不啟用，理由是我的local沒測過，然後delay客戶不爽跑掉，是不是又要說B責任最大應該要檢討的是CICD有沒有跑UT，跑integration test

你我看法不同 如此而已

我就說當下A部門怎樣都贏，但在客戶那裡炸了還回來找B究責真是可怕…

現在講都事後諸葛，回到release前看，QA測沒事，A測沒事CICD(不知道有沒有）有過，就B的local有問題，那怎算？

w0說的並沒發生 因為往不同方向發展了 是要討論別的案子嗎就B原本是救世主, 但不知為何後來裝沒看到, 微笑插刀

w0說的就是原原PO描述的release前的事實啊

A部門一開始真把B當救世主就不會在客戶那裡炸了不要人當初都被你們殺了，事後需要時再來封聖好嗎

我是指w0講delay客戶跑掉那段

B的local沒測過就是把環境和repro證明錄下來證明就好了只要有人環境沒測過就是要找環境或code哪有問題你能復現就不會是你問題，現在是B除了一開始說有問題後就不管了，也不提供驗證方法，最後也不複測。不然就是你復現不了，那也不會有你責任。

檢討B根本沒用 來個CDEF還不是一樣 該討論的是怎麼擋好啦 就讓B被火 然後CDEF還是一樣 你天天都在管人而已每天問底下所有員工是不是有不爽就好啦 事情都不用做

就算客戶沒跑，feature因為一個RD自己也無法重現的localtest fail而delay，你覺得他不會被HL更嚴重？B堅持不開feature，大家就覺得在無理取鬧而已，根本沒用

講真的 主管只是遷怒B而已 有問題的是A跟QA

他是指環境如果錯了100%復現 環境對了0%復現他也只測一次就肯定問題還是有 不然也不用說要highlight什麼很多人會把B說詞往亂講話的方向解讀 可是沒有足夠的證據 都是各位的自由心證

要明說客戶是錯的就直說唄，不用繞圈子講明白表示客戶用錯，所以資料蒸發了也是客戶要take care

這事件誰去責怪客戶？ 不要打迷糊仗 認為B有問題不代表認為客戶有問題 兩個綁在一起是在詭辯是嗎?

B的問題不是他的環境，是他自己own的程式爆了還放過的作為。

B這種心態也有人挺，真的笑死。

整個團隊就是各個組自己爽，沒人敢跨部門要，職場這樣正常啦

大家有發現我們知道的B，只是由他人轉述來的

不好意思 關鍵就在他「直接講要highrlight這問題」你管不到別人家的東西測不出來 就要裝無辜裝死到底OK？這一點人情世故都不懂

Amazon LP 第一點就是 Customer Obsession，敢在 A 這樣搞一定被 fire 吧

但是B最後的自我辯護不是無法repro，而是完全沒作。然後沒測就開出去了。如果真的測了但無法repro，其實他不需要說謊。只測一次是B自己講的，100% repro也是B自己講的，所以只測一次就失敗，回報後也不複測的B，還是開發完了還

其實B沒有義務repro並跟進這個bug那是A組的事

release出去，如果他不是故意才更恐怖吧，代表他都是閉著眼開發。

現在根本沒有B現身說法唄，是只重現出一次或沒有重現出來

照上篇說法，B至少要UT，所以第一次 UT 失敗開Bug。沒完成UT當然責無旁貸。除非他說第二次UT無法repro。但他是説第二次他沒UT。

這分兩部分，UT自清或者UT高光不論他UT自清做到百分之一百都不是老闆想知道的老闆要知道這個已經在客戶爆炸的bug的UT有沒有測究責的是UT高光有沒有跑徹底，至於自清沒做到那是延伸

他的UT工作跟自清或高光無關吧，本職上就是UT自己這關的東西確認沒問題才交下一關。

這種情境要回應老闆認為的UT，簡單來說就是回應沒有做到看了好久我看不懂你的意思，什麼是自己這一關

流程： A code (UT) -> B(UT)(整合)(UT) -> QA不管有沒有 Bug 都是這流程，所以B第一次回退後，A

你是要說B UT自清 還是整合UT高光

close後再送過來的東西，B還是要UT和整合完才下一步。

整合不也是UT，什麼叫作UT和整合

A掛理想B behavior driver UT PASS，B 掛理想A behaviordriver UT PASS退一萬步是整合UT沒測過

前文沒有提到是指B掛真A的UT，或者B掛A BM的UT 阿

每個環節都要自己作UT。

每個環節都要，這不就是系統測試了我不是刁難，而是自己的每個環節都要UT，與整合後的每個環節的UT，這兩個落差很大

B的東西要用到A，所以B的UT一定會包含到A的code不是UT階段就是IT階段。

如果貴單位覺得合理，那我承認是我錯了

啊不是，不管A寫的code怎樣，B自己要交給QA的東西自己都說沒測過，怎麼樣都說不過去吧。

對對，太不禮貌了

大家不睡覺在聊工作的事也太辛苦了吧

也是碰過有一派會說他自己寫完不用測整套,直接給QA去驗merge起來的

關鍵在於該公司的UT，是在開發者電腦上自測的而且沒有記錄。這種體制，有沒有UT其實不重要了，UT 淪為自由心證。該公司根本沒有正常有經驗的管理者。當然淪為情緒與政治之爭。如果UT是在第三方測試電腦上，B只要能成功執行Bug一次，其他人自然也容易復現Bug，也沒那麼多問題了。有沒有UT，竟然是靠嘴巴說出來的，而且大家還採信，真是奇葩公司啊。

B的UT就只是確保B自己code沒問題就好了吧 B做事類似開發UI把A的function給使用者點 至於點下去不會爆炸 那是A的UT要做的事

沒有模擬環境的測試，UT再多也是另一回事阿

這裡有個點是我覺得A這邊最該負責的，那個A要關掉bug時已經說是B把環境搞砸，那這時候B要UT什麼？B真的UT且fail那也符合A說的B搞砸環境啊B這時候無法證明自己環境沒問題也只能用在A和QA的環境下跑沒問題的結果當UT不是嗎？當然最正常的情況應該像DrTech講的，不然在被A判斷為環境搞砸時，B即使在自己機器上複驗fail也已經沒有意義

OS修好 B是feature owner總是要測過一遍吧? 這邊的問題是B自己說他知道還是會炸 不是你說的剛好沒辦法重現

B說還是會炸其實沒啥問題，因為A已經說B搞砸環境了，那就算B的環境一直fail也符合A認為可以關掉bug的條件啊

最上層 或者最接近customer端的本來就最衰 底層出了問題如果死不承認 大家還是會去追UI面 變成你要去證明是底層的問題

B有部分責任我是沒意見，但要說B故意炸客戶或是主責我認為完全沒道理

B一開始就自己說要故意炸客戶來HL啊，之後調查B主管才提出追加解釋。所以原PO才說，如果B講的真話而不是氣話那就非常嚴重。

檢討B的心境到底有什麼魔力？看到不少人包含原po很愛討論這個，正常公司就是去檢討A那端為何攔不了，盡力去補強最原始的漏洞，檢討B真的有助於公司的流程改善嗎

說B不敢交，但他就真的交了，不管是因為(1)他自己說沒測，或(2)他測了沒過還是硬交，現實就是他交了。除非是(3)他測了，沒法復現，所以安心交了。但他自己否認了這條路...檢討B很重要，就像B知道輪胎有問題，還故意組裝到車上害死人後，他不能說「輪胎又不是我作的，跟我無關。」B主管也知道不能這樣講，所以才改成「B組裝完沒再試開過，所以他只是猜測輪胎有問題，不是故意。」

B發現的問題被A說是B搞砸環境啊，你A先扣人家這樣一個大帽子再來說人家沒複測？我就問B複測fail的話不是符合A講的B環境有問題嗎？還是B要自證環境沒問題？那A說B環境有問題前有先提供證明嗎？

B是嚴重懷疑輪胎有問題，原廠回信說你搞錯了，是測試方法有問題，B鼻子摸摸把輪胎裝上去結果出事死人，那請問誰該被優先檢討呢

在A說B搞砸環境後B複測兩種結果基本上都是自己有問題啊，pass就是當初自己步驟有問題，fail就是A說的環境搞砸不可信，在那個當下A部門就穩贏的，現在還在意那個複測？

事後調查輪框上有一顆螺絲規格不合(LAGG)

今天B還可能要裝5種輪胎，B也只能看看每個輪胎外觀是否有明顯毀損，真正該知道問題並且有能力把問題修復的也只有原廠，事後出事B就在mur mur，那個我早就知道會出事了啦，請問這個系統我們該優先檢討誰呢

B不裝輪胎還會被上面的老闆罵 原廠都跟你說沒問題了 還不裝

現在就是B自己說他第二次連外觀都沒看就放行了這兩次code不一樣喔，B不管這Bug有沒有修，都要重測吧

你問我就是B, 因為B反應問題卻不協助處理, 要A自己通靈

而且B說的不是「我早知有問題」而是「我早知有問題但是

原廠是說無法重現B說的狀況, 不是說沒這回事

今天很多人糾結B沒有再測一次，那請問輪胎師父收到原廠回覆沒問題的回信後，請問輪胎師父要繼續跟原廠說，你的輪胎就是有問題，找出問題再回我一次，這樣更不合理吧

原廠送來第二顆輪胎了喔，不是原本那顆。

就說A沒保證沒問題, 是說測不出資料毀損的狀況, 中文不好?

原PO和A有改過code重新commit。

在當下B在自己電腦上測已經沒任何意義了啊，環境被判定搞砸，那用A和QA的環境來測試當結果有啥問題？

那是只是用猜測問題點來改(就是在通靈啦), 並非針對問題點

正常流程也是要找出B環境的問題，萬一客戶跟B同環境呢?

A認為他複製不出來這個問題，肯定是B把自己環境搞砸了…這首篇原po自己寫的，誰中文不好？

後來證明也是。

A懷疑B環境有問題是A要證明還是B

關鍵的LAGG是誰的, 有沒有問題, 就原PO文章我看不出來

A和B要一起查，這沒法靠單邊找出來問題。所以說兩邊不願意合作就要叫主管。

還是我們這邊請主管說有沒有讓 A B合作找問題 XD

要找出B環境問題完全同意，但我自己認為這是在A被開issue這段時間該做；就像原廠收到輪胎問題不能確定，起碼跟輪胎師父說先緩緩不要裝，而不是回信說是你環境有問題

A只寫無法復現吧，系統上通常不會白目去標是B有問題。

如果去車行換輪胎, 結果輪胎脫落, 是找車行還是原廠

找車行，然後師父裝的按照流程，就會找原廠 我猜啦

然後車行發現原廠胎有瑕疵, 之前也有發現鎖不緊的情況

對啊 但原廠說沒問題不是嗎 還是師父比原廠懂輪胎

車行有跟原廠反應, 但原廠說經測試無論胎脫落的情況

先找車行找出問題，但假設是原廠說沒問題的輪子出包，所有因輪胎脫落造成的損害要跟原廠求償

所以車行照常交車給客戶, 害客戶出車禍後續文章資料就不齊全了 => 後來車行發現同時安裝LAGG會後來車行發現同時安裝LAGG會導致輪胎脫落這邊LAGG是不是原廠, 有沒有瑕疵, 文章都看不出來

按照原文 LAGG 是客戶車上有的歐，不是師父另外裝的吧

問題就是B自己說他確信輪子會出包，故意裝上去要HL原廠

只知道不要同時安裝LAGG(或LAGG已修正? 修掉?) 就沒事對 就是剛好LAGG客戶的車上有, 所以就出車禍了

LAGG是客戶原本有，但原廠沒想到，所以這是原廠的鍋車行剛好有LAGG的車子，但是也沒想到是這問題，只想釘原廠，就變事故了。

而且這LAGG應該也是車行裝的? 那要怎麼究責呢?

別忘記B有拿到原廠的回覆信，而且最終也只有輪胎廠能修復這問題，輪胎師父能做的就是被客人罵而已

等等 LAGG 什麼時時候變成車行裝的

好修正一下 LAGG不知道怎麼來的 我只是猜測是車行(B)裝的

LAGG是客戶環境標配，不在開發案本身裏。但應該在開發前要調查清楚。

車行有沒有是未知的，只是客戶有且裝了穩定出bug

但B有踩到LAGG, 所以我是猜LAGG是公司做的功能

時間上LAGG是亡羊補牢發現，或者發覺到上新code還是錯的至於誰有誰沒有，兩邊互推串資源義務無益釐清事實

LAGG -> Link Aggregation? 所以是在講NAS喔 XD

1.是，但不是只有NAS會用。

若是分享器更新完弄壞資料, 廠商會跑來救資料也是很神奇

後來發現LAGG會造成問題的不是車行是原廠，車行的環境在客戶炸了之後原廠拿去測也無法復現，最後原廠才知道師父在測到問題前一天做過網路測試所以有LAGG

是啊 不知道LAGG是什麼也可以討論客戶車上有LAGG、LAGG是不是原廠，討論半天..在有LAGG的環境會炸掉A的能力就是很弱，不知道有什麼好說，原原Po還想要講A是RD不想讓他揹這個bug的責任我寫一個database driver給你用，在cluster環境會把資料炸掉，但是我只有在單機環境測過都沒問題啊，一定是你環境有問題，看誰聽得下去「誰叫你們不說你們有用到cluster，沒說是要我通靈解bug？」A就這態度

原PO有提到LAGG技術有不照原本順序的特性所以車行原本是編號順序裝螺絲, 結果用了LAGG技術導致導致螺絲裝錯位置, 所以輪胎就脫落了 XD

照樓上說法公司該去跟客戶說你們搞砸環境啊…

不是好嗎你在亂比喻什麼

沒有給A LAGG環境是原PO的錯, A應該只是照需求做

就事論事如果你想要比喻就拿完全可類比的範例，不要已經是不可類比的領域還硬要繼續用這個範例

不好意思 讓你困惑了 哈哈哈

我覺得B講那些話只是意氣用事，他肯定沒有能力repro如果能的話以B個性不可能不嘴一頓A/QA，然後公司面究責要以local UT的狀況當依據更是沒道理，你不能因為一個人講話機歪就說他責任最大，我還是傾向與其看一個人說了什麼，不如看他做了什麼，事實就是B已經做了他職責內能做的所有事，但A以及QA都沒有把他當一回事

我認為B不該沒驗證通過就把功能啟用 that's all

樓上，同理，那QA的職責呢？

QA失能 應該整組換掉 -> 後來看原PO說QA是老闆的人 XD

現在是B沒過QA卻過了？結果是整個開發流程有問題，這樣還算不算B的問題？

這部分就我說的，A認為B環境不可信，所以B以QA結果當驗證你也不能說他故意搞事

事實上B測第二次爆第二次也只會被A說你就環境有問題

QA過了 就扯到原PO了 沒提LAGG環境

阿如果他堅持不啟用，理由是我的local沒測過，然後delay客戶不爽跑掉，是不是又要說B責任最大應該要檢討的是CICD有沒有跑UT，跑integration test

你我看法不同 如此而已

我就說當下A部門怎樣都贏，但在客戶那裡炸了還回來找B究責真是可怕…

現在講都事後諸葛，回到release前看，QA測沒事，A測沒事CICD(不知道有沒有）有過，就B的local有問題，那怎算？

w0說的並沒發生 因為往不同方向發展了 是要討論別的案子嗎就B原本是救世主, 但不知為何後來裝沒看到, 微笑插刀

w0說的就是原原PO描述的release前的事實啊

A部門一開始真把B當救世主就不會在客戶那裡炸了不要人當初都被你們殺了，事後需要時再來封聖好嗎

我是指w0講delay客戶跑掉那段

B的local沒測過就是把環境和repro證明錄下來證明就好了只要有人環境沒測過就是要找環境或code哪有問題你能復現就不會是你問題，現在是B除了一開始說有問題後就不管了，也不提供驗證方法，最後也不複測。不然就是你復現不了，那也不會有你責任。

檢討B根本沒用 來個CDEF還不是一樣 該討論的是怎麼擋好啦 就讓B被火 然後CDEF還是一樣 你天天都在管人而已每天問底下所有員工是不是有不爽就好啦 事情都不用做

就算客戶沒跑，feature因為一個RD自己也無法重現的localtest fail而delay，你覺得他不會被HL更嚴重？B堅持不開feature，大家就覺得在無理取鬧而已，根本沒用

講真的 主管只是遷怒B而已 有問題的是A跟QA

他是指環境如果錯了100%復現 環境對了0%復現他也只測一次就肯定問題還是有 不然也不用說要highlight什麼很多人會把B說詞往亂講話的方向解讀 可是沒有足夠的證據 都是各位的自由心證

要明說客戶是錯的就直說唄，不用繞圈子講明白表示客戶用錯，所以資料蒸發了也是客戶要take care

這事件誰去責怪客戶？ 不要打迷糊仗 認為B有問題不代表認為客戶有問題 兩個綁在一起是在詭辯是嗎?

B的問題不是他的環境，是他自己own的程式爆了還放過的作為。

B這種心態也有人挺，真的笑死。

整個團隊就是各個組自己爽，沒人敢跨部門要，職場這樣正常啦

大家有發現我們知道的B，只是由他人轉述來的

不好意思 關鍵就在他「直接講要highrlight這問題」你管不到別人家的東西測不出來 就要裝無辜裝死到底OK？這一點人情世故都不懂

Amazon LP 第一點就是 Customer Obsession，敢在 A 這樣搞一定被 fire 吧

真的典型的先解決提出問題的人

B的態度跟處理明明也是問題