闲闲没事来回第三篇继续捍卫一下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的态度跟处理明明也是问题