大家好我是原po，大家讨论那的激烈，我觉得我需要补充一下。
我认为有一个症结点需要解释一下，虽然有可能解释完结果可能更糟 XD
因为中间有一段，完全是我的臆测，我也没有绝对证据去证实我的论点。
如果各位要反驳我，我也完全接受。
我主要是要讲一下，为何我会觉得B应该被火？
这个流程我最一开始以为的版本(1)是：
A mark 无法复制 -> B 确认无法复制 -> commit -> QA无法复制 -> release
但是第一次bug review meeting后，因为B说的话，我跟QA的认知是版本(2):
A mark 无法复制 -> B 确认问题还在 -> commit -> QA无法复制 -> release
QA跑去跟老板告状后，老板把我跟B主管找过去，说如果调查是故意炸客户，要火。
我跟B主管把B叫过来调查这件事，B这时给的是版本(3):
A mark 无法复制 -> B 没有确认过 -> commit -> QA 无法复制 -> release
所以这时，B承认他没有确认过。因为我们公司的流程，各自有各自的UT。
必须通过了UT，才会到QA那边去打IT。但是B承认他没有过UT就commit。
所以故事最终B被处罚是因为他手上的feature没有经过自己UT测试就commit。
我对版本(3)有一些怀疑，由于过程中，我一直反复问他两个关键问题。
所以对话次序上我没有100%肯定我记忆中的顺序，敬请原谅。
我问B：你写always，表示你一次也没有pass过UT，为何你会commit?
B说：我只测过一次，A mark无法复制我就相信他，然后commit。
我问B：你只测过一次怎么会是always。
B说：测一次中一次，我就写always
我问B：你相信他无法复制，为什么后来会说你早就知道会fail，你是故意commit?
B说：他写无法复制，那肯定问题还在啊！
我说：这不一定吧？
B主管说：你是想说他无法复制肯定没有解，所以想提醒大家对不对？
大概是上面这串对话，我反复不断用不同的方式问了好几遍。
因为这过程中，B自己坦承吃下了两个低级错误：
1. 只试一次就说是always
2. 没有通过feature UT就commit code
但是我的理解是B这个资深工程师，不太可能犯这两个低级错误。
我内心的推测是：他最初的说法其实才是对的。
也就是：‘他反复测了好几次，都过不了(always)，于是发bug给A。
A mark 无法复制后，他也拿UT起来测试，结果fail了。
后面就是如他所说，他发现这问题根本没有解，一气之下commit上去要炸A。’
最后老板把我跟B主管叫过去说要处理B的时候，B主管跟B先套过招。
他们发现承认故意后果很严重，所以他们有有两种选择:
1. 不承认测过
2. 当时有测过结果是pass就commit了。
但是处理的当下，因为还不知道root cause，所有人都认为是always发生，包含B+客户
所以要骗说当下有测过，结果是pass的说法很可能会被打脸。
于是他们选择承认低级错误，规避‘故意’这件事情。
另外他说他只测一次，同样也可能是要规避always发生的bug，却没有复验这件事。
我觉得他们的说法没有说服我，但是我也真的没有证据，所以最后选择大家下台阶。
另外当下我忙着要去处理客户资料损毁的问题，没有心思去深究这件事情。
另外我的部分，我前面有说我去处理客户资料救援有成功。
客户部分也没有再追究这件事，最后整个产品是有顺利卖出去。
所以我的部分，其实公司是没有特别‘处理’我。 但是升迁当然就不用想了。
以上跟大家报告一下

Hi，鬼

供词都可以被他们乔 你也太软 我以前在ptt的回复也都

我觉得是你想太多了，如果B真的很懂也重复测过，怎么后来无法在B的环境复现？后来你们才发现是因为LAGG的问题？

这样 以为不得罪人 但后来就释怀了

B很神的前提是他知道客户和他的环境一样有LAGG而你们没有，这前提你觉得有可能吗？

wmt又在说什么...

应该说B故意炸的前提*

其实我们有发现B team工程师不一定会更新test code的习惯他们只关注自己开发的地方，test code没有很频繁去update但是B的环境是不是一直都是有问题的LAGG，我也没有证据。所以B主管也有说LAGG test code修正了，这样大家都解套。

你不如说说为什么A在被你review过issue确认可以close以后还被惩处吧 你有坦住你下面的RD吗? 尤其他还是你身为PL却没把客户需求厘清的第一受害者检讨B的纪律问题跟你们project出bug真的有关?

A的部分，我有极力去担，但是我承认我没有手段可以扛住。所以A走掉，也是我战力损失。B的问题是老板认为故意的话要火但是feature owner没确认就commit，的确是有责任的。

所以B不是被认定这个事故该负责的人嘛

你用一大段臆测指控B和其主管，A和QA都你的人你好意思

B被处理不是自爆的部分，而是没有确认这件事。

如果关闭bug有经过B同意，B确实有责任，但要说B是故意炸客户我觉得太脑补了点

所以你没保住A但保了B?...

p大和s大你们两个说的feature owner是不同人呗

对，所以我自己脑补的部分我一直没说。但是我没有因为脑补结果去处理B

所以B鬼的点在哪? 没有纪律自业自得 但你是不是该学学B主管怎么维护自己的战力?

B故意炸A 客户只是被牵连

你没说但你一直在提醒大家B是故意的啊XD

因为他自己说他是故意的啊XD

原来还花这么多无谓时间在究责

我是认为实务上，B不会犯这么低级的错误，如此而已。

到底是去当国中生搞小团体的还是去工作解决问题的啊

就有供词 但B主管想保B翻供

低级的错误才是最容易犯的好吗…因为随手就可以成功

我其实只能去评价A，B的部分我其实没有权限去作任何事。wmtsung你要这样理解也是合理，这也就是为何我没有去深究

谁说B炸客户... 他要炸人是真的 客户只是工具 讲第二次了

有可能就只是一连串的低级错误加上嘴贱而已。

连带大家鸡飞狗跳而已

不觉得你们的module会不会造成资料毁损全公司只有你们team最懂吗？是期待别人帮你测出问题，最好还能帮忙找到root cause？最后再来全力检讨问题的问题，下次B换成不会乱自爆的C你们还不是要继续炸？

你看你又来了 保错了人不说 现在还要替别人自圆其说

所以A被处理是因为炸资料，B被处理是因为他没UT。

奉劝原po别再纠结B心态如何 A被提报出bug时你身为最初埋炸弹的人是否出来坦坦承这是你的错误导致的?

错误我们一直都有承认，最后也有受到处罚，这部份没问题。我觉得分两个路线，一个是写出bug，一个是没过UT。

重点在A没有做错

而且B只测过一次是在事后你问B才知道，那A当初到底怎么和B讨论这个bug也是很神…我自己测不出来一定是叫发bug再重测看看

只测一次写always 被火刚好

前面有提到B是拒绝帮忙，他认为bug report足够。

如果当初B对A说谎导致后续，你拿这个来打B还比较实在

A属于RD写出bug，我认为不应该去重责，所以我只认定1/10

那在B拒绝时你应该先找B的主管啊

一气之下就炸客户无法接受。

B的主管是认为我们要自己复制+QA帮忙，他的说法其实也合理毕竟我手上有QA, B主管没有。

你认为他为什么会写出没考虑到LAGG的bug? 是不是你提供他的spec跟测项没有? 那这bug是谁的责任?

两边都在推托串资源义务，仿佛在当兵敌不动我不动

我上面有提到，其实是我应该要负责让QA有LAGG项目。

好 那么A的1/10是不是该算你这?

是我也会赞成处里B啦，但这只是出气打不长眼，真正要改善流程还是要从A和QA明明有收到资料毁损的issue明明什么都没动还不喊停

A的code没有考虑到packet order问题，LAGG只是其中一个我跟A都有能力把这bug拦下来，但是我们两个都miss了。

那说实在的，B也只是来支援，你们部门当时都无法复现也只能自己担，应该说客户炸了之后你们还是可以解决，那只是在当下你们轻忽没有全力去找原因而已

我看了五天下来，完全不知道order有关

技术细节我没有提太多，LAGG环境下，packet会out of orderB不是来支援，B owner一个feature，A才是支援他。我owne application, 所以B是支援我。

ok 那么issue close时A提供的解方也还是没有涵盖到这 你是review的人 A还是要担这1/10?

按照工作流程，不是code被review，出事就是reviwer全责。

B是来串接的 支援？...

你是leader, review这个点是可以用来保护A的你知道吗?

我是以组织来看啦，至少这个案子应该是你们部门为主吧？不然不会只有B在这里啊

我认为就是因为有review，才敢喊A只有1/10案子其实以我为主，但是我的team大部分都是support其他人

跟我想得差不多 只是原来还有翻供

B是owner一个feaure，工作就是把好几个function串起来

题外话 嗑瓜观众可以读Lamport的The Part-Time Parliament

我觉得不能说是翻供，只是在原本说法上作最大程度的解释只是这个解释，很让我无法相信。

现代分布式系统的理论发轫点

就是供词蓄意然后不能这样讲给老板听不然老板会抓狂火B 这怎么不是翻供...

就我没有他们翻供的决定性证据。就跟侦探剧结局一样：你这么说只是你的臆测，有证据吗？如果这真的是翻供，我觉得B的主管很神！B的主管不管是技术还是政治上，都强我好几个档次。

不管怎样,老板是心有定见啦,没有相信你们报上去的A和B的

技术我不知 因为没资讯 但政治我已经嗅出来了

因为版友是第三者，对你的说法只能看“发生了哪些事”，对你的主观说法(包括对话转述)以及猜测(包含这篇的许多内容)都不能尽信，你可以试试用这样的观点去看整件事。另外，居然没有在客户的模拟环境做sanity test，我看你们是很猛喔

sanity test是啥

不就是蓄意改成低级错误方向解释 是翻供无疑

tsairay大讲的有道理耶，我解惑了。

老板心里根本不相信A和B责任有限,只是给两位主管一个台阶下,不拆穿而已,实际上老板心里就是认定A和B有责任才会砍考绩和分红

代刷门禁这种事就可大可小啊 XDD 的确有可能藉题砍他但也有可能对于某些特别注重诚信的老板来说是禁忌

主要是B不是A 强调要调查B是否蓄意 虽然制度差但这老板显然不是傻子我都有从老板行为反推论

这件事没有处理好，心理一直有一个疙瘩。我会po上来，我觉得也是一种寻求慰藉跟疗愈。大家的分析后，我突然懂了。老板其实什么都知道。我跟B主管就是还在帮他赚钱接案子，他不会给我们难看。尤其是门禁这件事，我原本觉得莫名其妙，现在整个都通了XD

其实能当到老板的..都不笨啦,不会盲信下属报上来的主观

我觉得我心种某一个执念可以生天成佛了 XD

意见,他们也会自己从各种客观条件得出自己的结论

辛苦啦，其实不用跟乡民太认真。谁对谁错又岂是我们这些局外人可以判断的

我觉得最大的问题是横向沟通有问题,,再次发生也不意外

最终结果走了3个战力 如果这样可以视为老板排毒成功 我也没啥好说了 就祝福原po及其部属

我刚刚想通一件事，老板其实最相信的不是我或B主管而是QA,因为QA是老板直属部队，暂时借给我指挥而已。事情可能是QA跟老板告状的时候，老板就明白了。后面都是我们在演猴戏而已.....T T感谢各位给我的指教，真的获益良多。QA的feedback就是我们横向沟通要加强没错。

是 但Qa惩处一点都没有很难说的过去

QA就是去被PDCA这件事，感觉好像有处罚，实际上是没有。

PR owner要负最大责任

这事背景越补越多XD 可以最困难的永不是技术问题而是政治手腕。常理来我是支持原PO版本2的想法，如果我开的bug，我看到修正了不太可能忍住不复测。如果环境复测不出来，事后就会说复测不出来，不会嘴砲说要用客户HL问题。所以真相大概就是复测过真的有问题，然后丢去客户那看爆炸。老经验主管得知后，再帮忙想理由避责。（这种事其实我工作上一年都要碰上几次，作多了自然知长官喜欢听哪些理由来解释灵异事件。）

不要叫整合的当你们的QA好吗 你们都关了还要人家帮你把关必要时A跟B跟他们的老板要抓过来一起war room debug才是

一下说事后发现LAGG拔掉所以才会打不出来，一下说你觉得B出去前有测过fail故意炸客户，啊LAGG都拔了B还打得出来？好了啦，你就是想公审B结果翻车，可以下去了一点担当都没有只会搞政治的主管假设B从没参与这次开发，就从头到尾没人会戳到这个bug，你们一样会炸客户，还在扯B有多少责任，笑死你不如说说是哪家产品这么雷好让大家避开以免资料被毁毕竟这家公司不是因为被B恶搞才会炸到客户喔，是RD有机会造出一个没人测到的bug把资料删光花一堆时间在究责，想办法说服大家B的态度有多差，却没检讨过自己负责的产品为什么会造出这种bug还放出去你身为PL知道这个issue存在，知道A搞了三周无法复现就相信这个bug会自己消失？其实客户资料会被删光就是你跟A造成的，你没有要求A把根因找出来现在眼看风向不对开始出来补充说B没过UT就commit，阿你的产品你的流程怎么会让人没过UT就能release啊？谁知道你说的B没过UT就commit是真的还是开始编故事为了带风向啊？搞半天责任是在B没有做好UT是吗？都是B的错就对了

资料删光这个issue是可以随便关的吗= =还有A测3个礼拜测不出来没有call help吗？照理说是要找Ateam的人来挖bug吧？大家都在干嘛= =？A的环境测不出来，身为leader不是第一步就是跟客户确认环境吗？如果客户环境跟A一样就没事，不一样就弄成一样啊，三个礼拜都没人确认喔= =？

原PO其中一篇说测不出来，后来跟A一起review把可能有问题的地方修改之后就close（通灵debug)，直到客户炸开才回头调查发现原来是LAGG会引发问题，若早一开始就认真看待去把环境确认好怎么会炸到客户那边？这个bug也不是说，有机率闪退这种小事

别带着情绪做事吧。B该不该被火，不是你这个职级与角色该决定的。而且前一篇说B没什么责任，这一篇又说责任在B。你连当个owner的角色该做什么都有点混乱了吧。而且喔，太多都是你"自己"无证据默认立场推测出来的结论。何必把自己搞那么累。最后，正常有点品质的软件公司或管理流程，UT都是跑在开发者以外的电脑，而且会自动记录。有没有UT，以及Log根本没机会造假。

简单的说，你就是没做好把关，让bug出去客户端了嘛，推那么多责任做啥，结果B自爆让你找到一个宣泄甚至卸责的出口，顶多说B职业操守有争议，但你事实上就是Owner，你自己也说你扛责辞职了，那感觉还要上来批斗B，分享什么鬼故事做啥

确实，你要感谢B嘴邱，不然你连锅都没得甩

如果关issue后要commit前B没再试一次或是试过还是炸了却commit 我觉得B确实要扛责任不过我比较好奇不管B有没有自爆 你们在review的时候最终还是会找到B那边吧 一定会问B最后有没有再试一次吧

always = 只测一次，B这个人说的话，没有可信度

刚刚想到，第一篇原po讲的A认为B搞砸环境，那B即使在自己机器上复测fail也没有意义了不是吗？

原PO可以多学习沟通协调力+政治敏感度，跨部门有冲突难免，如何在不同部门"合理"调动资源，协调力很重要，可能主管也认为原PO处理还没有很好，所以升迁就先庭住

其心可议 一开始讲鬼故事的时候怎么不好好描述 想引导B是鬼

原PO就被卡升迁7pupu，现在还放不下，不然原PO、A、B都离职了，还要拿出来鞭尸

原来是这样

不管B最后到底有没有测 结果是不变的 因为B确实commit了 A/QA/原PO因为盲区而有的过错与B原来的过错是两回事 都说了N次 不要拿前者的过错来cover B的过错 整天洗B没错 B很严重是事实 这本来就不是一个人导致的你也只能相信原po说的 除非你找到其他当事人加入战局原PO说B没什么责任的前提是B确定不是故意要highlight事情已经结束原PO是分享故事 要卸什么责？ 如果你是原PO在这种公司并遇到这种事情你会怎么做？ 我敢说几乎所有主管都没那么认真 很多主管为了省心不会主动追踪或技术难点确认完毕部门内再检查的结果不就是无法复现搂

你才在整天洗B很严重…之前还要说别人洗地，自己的行为最像在洗地

B很严重有理有据 太多拿自己经验以及脑补想法臆测的不是洗地是什么 本来就是根据内文找线索推论而出 在你眼里就变成洗地... 你们讲的一堆东西都无法验证 什么B只是嘴臭况且我也没有说其他人都没问题 没帮其他人洗地你的洗地概念跟其他人很不一样... 但知道你的意思

事实上，他们公司的处置已经告诉我们，B就算自爆，责任也只跟差不多

你跟A以及QA都知道B提出过有问题 也清楚A跟QA没复制出来当你们关闭该问题时 就是在背书该问题可以忽视你跟A跟QA都知道 那问题没有真正被处理 可能有未爆弹release前你们不清楚哪些功能有上线? B只错在嘴臭而已

处置A与B同是因为原po保了B 以低级错误论处close没有可以忽略的说法 那只是你的经验 开源专案与公司内开关都是有的事情

推

Hi，鬼

供词都可以被他们乔 你也太软 我以前在ptt的回复也都

我觉得是你想太多了，如果B真的很懂也重复测过，怎么后来无法在B的环境复现？后来你们才发现是因为LAGG的问题？

这样 以为不得罪人 但后来就释怀了

B很神的前提是他知道客户和他的环境一样有LAGG而你们没有，这前提你觉得有可能吗？

wmt又在说什么...

应该说B故意炸的前提*

其实我们有发现B team工程师不一定会更新test code的习惯他们只关注自己开发的地方，test code没有很频繁去update但是B的环境是不是一直都是有问题的LAGG，我也没有证据。所以B主管也有说LAGG test code修正了，这样大家都解套。

你不如说说为什么A在被你review过issue确认可以close以后还被惩处吧 你有坦住你下面的RD吗? 尤其他还是你身为PL却没把客户需求厘清的第一受害者检讨B的纪律问题跟你们project出bug真的有关?

A的部分，我有极力去担，但是我承认我没有手段可以扛住。所以A走掉，也是我战力损失。B的问题是老板认为故意的话要火但是feature owner没确认就commit，的确是有责任的。

所以B不是被认定这个事故该负责的人嘛

你用一大段臆测指控B和其主管，A和QA都你的人你好意思

B被处理不是自爆的部分，而是没有确认这件事。

如果关闭bug有经过B同意，B确实有责任，但要说B是故意炸客户我觉得太脑补了点

所以你没保住A但保了B?...

p大和s大你们两个说的feature owner是不同人呗

对，所以我自己脑补的部分我一直没说。但是我没有因为脑补结果去处理B

所以B鬼的点在哪? 没有纪律自业自得 但你是不是该学学B主管怎么维护自己的战力?

B故意炸A 客户只是被牵连

你没说但你一直在提醒大家B是故意的啊XD

因为他自己说他是故意的啊XD

原来还花这么多无谓时间在究责

我是认为实务上，B不会犯这么低级的错误，如此而已。

到底是去当国中生搞小团体的还是去工作解决问题的啊

就有供词 但B主管想保B翻供

低级的错误才是最容易犯的好吗…因为随手就可以成功

我其实只能去评价A，B的部分我其实没有权限去作任何事。wmtsung你要这样理解也是合理，这也就是为何我没有去深究

谁说B炸客户... 他要炸人是真的 客户只是工具 讲第二次了

有可能就只是一连串的低级错误加上嘴贱而已。

连带大家鸡飞狗跳而已

不觉得你们的module会不会造成资料毁损全公司只有你们team最懂吗？是期待别人帮你测出问题，最好还能帮忙找到root cause？最后再来全力检讨问题的问题，下次B换成不会乱自爆的C你们还不是要继续炸？

你看你又来了 保错了人不说 现在还要替别人自圆其说

所以A被处理是因为炸资料，B被处理是因为他没UT。

奉劝原po别再纠结B心态如何 A被提报出bug时你身为最初埋炸弹的人是否出来坦坦承这是你的错误导致的?

错误我们一直都有承认，最后也有受到处罚，这部份没问题。我觉得分两个路线，一个是写出bug，一个是没过UT。

重点在A没有做错

而且B只测过一次是在事后你问B才知道，那A当初到底怎么和B讨论这个bug也是很神…我自己测不出来一定是叫发bug再重测看看

只测一次写always 被火刚好

前面有提到B是拒绝帮忙，他认为bug report足够。

如果当初B对A说谎导致后续，你拿这个来打B还比较实在

A属于RD写出bug，我认为不应该去重责，所以我只认定1/10

那在B拒绝时你应该先找B的主管啊

一气之下就炸客户无法接受。

B的主管是认为我们要自己复制+QA帮忙，他的说法其实也合理毕竟我手上有QA, B主管没有。

你认为他为什么会写出没考虑到LAGG的bug? 是不是你提供他的spec跟测项没有? 那这bug是谁的责任?

两边都在推托串资源义务，仿佛在当兵敌不动我不动

我上面有提到，其实是我应该要负责让QA有LAGG项目。

好 那么A的1/10是不是该算你这?

是我也会赞成处里B啦，但这只是出气打不长眼，真正要改善流程还是要从A和QA明明有收到资料毁损的issue明明什么都没动还不喊停

A的code没有考虑到packet order问题，LAGG只是其中一个我跟A都有能力把这bug拦下来，但是我们两个都miss了。

那说实在的，B也只是来支援，你们部门当时都无法复现也只能自己担，应该说客户炸了之后你们还是可以解决，那只是在当下你们轻忽没有全力去找原因而已

我看了五天下来，完全不知道order有关

技术细节我没有提太多，LAGG环境下，packet会out of orderB不是来支援，B owner一个feature，A才是支援他。我owne application, 所以B是支援我。

ok 那么issue close时A提供的解方也还是没有涵盖到这 你是review的人 A还是要担这1/10?

按照工作流程，不是code被review，出事就是reviwer全责。

B是来串接的 支援？...

你是leader, review这个点是可以用来保护A的你知道吗?

我是以组织来看啦，至少这个案子应该是你们部门为主吧？不然不会只有B在这里啊

我认为就是因为有review，才敢喊A只有1/10案子其实以我为主，但是我的team大部分都是support其他人

跟我想得差不多 只是原来还有翻供

B是owner一个feaure，工作就是把好几个function串起来

题外话 嗑瓜观众可以读Lamport的The Part-Time Parliament

我觉得不能说是翻供，只是在原本说法上作最大程度的解释只是这个解释，很让我无法相信。

现代分布式系统的理论发轫点

就是供词蓄意然后不能这样讲给老板听不然老板会抓狂火B 这怎么不是翻供...

就我没有他们翻供的决定性证据。就跟侦探剧结局一样：你这么说只是你的臆测，有证据吗？如果这真的是翻供，我觉得B的主管很神！B的主管不管是技术还是政治上，都强我好几个档次。

不管怎样,老板是心有定见啦,没有相信你们报上去的A和B的

技术我不知 因为没资讯 但政治我已经嗅出来了

因为版友是第三者，对你的说法只能看“发生了哪些事”，对你的主观说法(包括对话转述)以及猜测(包含这篇的许多内容)都不能尽信，你可以试试用这样的观点去看整件事。另外，居然没有在客户的模拟环境做sanity test，我看你们是很猛喔

sanity test是啥

不就是蓄意改成低级错误方向解释 是翻供无疑

tsairay大讲的有道理耶，我解惑了。

老板心里根本不相信A和B责任有限,只是给两位主管一个台阶下,不拆穿而已,实际上老板心里就是认定A和B有责任才会砍考绩和分红

代刷门禁这种事就可大可小啊 XDD 的确有可能藉题砍他但也有可能对于某些特别注重诚信的老板来说是禁忌

主要是B不是A 强调要调查B是否蓄意 虽然制度差但这老板显然不是傻子我都有从老板行为反推论

这件事没有处理好，心理一直有一个疙瘩。我会po上来，我觉得也是一种寻求慰藉跟疗愈。大家的分析后，我突然懂了。老板其实什么都知道。我跟B主管就是还在帮他赚钱接案子，他不会给我们难看。尤其是门禁这件事，我原本觉得莫名其妙，现在整个都通了XD

其实能当到老板的..都不笨啦,不会盲信下属报上来的主观

我觉得我心种某一个执念可以生天成佛了 XD

意见,他们也会自己从各种客观条件得出自己的结论

辛苦啦，其实不用跟乡民太认真。谁对谁错又岂是我们这些局外人可以判断的

我觉得最大的问题是横向沟通有问题,,再次发生也不意外

最终结果走了3个战力 如果这样可以视为老板排毒成功 我也没啥好说了 就祝福原po及其部属

我刚刚想通一件事，老板其实最相信的不是我或B主管而是QA,因为QA是老板直属部队，暂时借给我指挥而已。事情可能是QA跟老板告状的时候，老板就明白了。后面都是我们在演猴戏而已.....T T感谢各位给我的指教，真的获益良多。QA的feedback就是我们横向沟通要加强没错。

是 但Qa惩处一点都没有很难说的过去

QA就是去被PDCA这件事，感觉好像有处罚，实际上是没有。

PR owner要负最大责任

这事背景越补越多XD 可以最困难的永不是技术问题而是政治手腕。常理来我是支持原PO版本2的想法，如果我开的bug，我看到修正了不太可能忍住不复测。如果环境复测不出来，事后就会说复测不出来，不会嘴砲说要用客户HL问题。所以真相大概就是复测过真的有问题，然后丢去客户那看爆炸。老经验主管得知后，再帮忙想理由避责。（这种事其实我工作上一年都要碰上几次，作多了自然知长官喜欢听哪些理由来解释灵异事件。）

不要叫整合的当你们的QA好吗 你们都关了还要人家帮你把关必要时A跟B跟他们的老板要抓过来一起war room debug才是

一下说事后发现LAGG拔掉所以才会打不出来，一下说你觉得B出去前有测过fail故意炸客户，啊LAGG都拔了B还打得出来？好了啦，你就是想公审B结果翻车，可以下去了一点担当都没有只会搞政治的主管假设B从没参与这次开发，就从头到尾没人会戳到这个bug，你们一样会炸客户，还在扯B有多少责任，笑死你不如说说是哪家产品这么雷好让大家避开以免资料被毁毕竟这家公司不是因为被B恶搞才会炸到客户喔，是RD有机会造出一个没人测到的bug把资料删光花一堆时间在究责，想办法说服大家B的态度有多差，却没检讨过自己负责的产品为什么会造出这种bug还放出去你身为PL知道这个issue存在，知道A搞了三周无法复现就相信这个bug会自己消失？其实客户资料会被删光就是你跟A造成的，你没有要求A把根因找出来现在眼看风向不对开始出来补充说B没过UT就commit，阿你的产品你的流程怎么会让人没过UT就能release啊？谁知道你说的B没过UT就commit是真的还是开始编故事为了带风向啊？搞半天责任是在B没有做好UT是吗？都是B的错就对了

资料删光这个issue是可以随便关的吗= =还有A测3个礼拜测不出来没有call help吗？照理说是要找Ateam的人来挖bug吧？大家都在干嘛= =？A的环境测不出来，身为leader不是第一步就是跟客户确认环境吗？如果客户环境跟A一样就没事，不一样就弄成一样啊，三个礼拜都没人确认喔= =？

原PO其中一篇说测不出来，后来跟A一起review把可能有问题的地方修改之后就close（通灵debug)，直到客户炸开才回头调查发现原来是LAGG会引发问题，若早一开始就认真看待去把环境确认好怎么会炸到客户那边？这个bug也不是说，有机率闪退这种小事

别带着情绪做事吧。B该不该被火，不是你这个职级与角色该决定的。而且前一篇说B没什么责任，这一篇又说责任在B。你连当个owner的角色该做什么都有点混乱了吧。而且喔，太多都是你"自己"无证据默认立场推测出来的结论。何必把自己搞那么累。最后，正常有点品质的软件公司或管理流程，UT都是跑在开发者以外的电脑，而且会自动记录。有没有UT，以及Log根本没机会造假。原PO有机会可以去了解正常CI流程，以后遇到同样的事情，或许会有不同想法。

简单的说，你就是没做好把关，让bug出去客户端了嘛，推那么多责任做啥，结果B自爆让你找到一个宣泄甚至卸责的出口，顶多说B职业操守有争议，但你事实上就是Owner，你自己也说你扛责辞职了，那感觉还要上来批斗B，分享什么鬼故事做啥

确实，你要感谢B嘴邱，不然你连锅都没得甩

如果关issue后要commit前B没再试一次或是试过还是炸了却commit 我觉得B确实要扛责任不过我比较好奇不管B有没有自爆 你们在review的时候最终还是会找到B那边吧 一定会问B最后有没有再试一次吧

always = 只测一次，B这个人说的话，没有可信度

刚刚想到，第一篇原po讲的A认为B搞砸环境，那B即使在自己机器上复测fail也没有意义了不是吗？

原PO可以多学习沟通协调力+政治敏感度，跨部门有冲突难免，如何在不同部门"合理"调动资源，协调力很重要，可能主管也认为原PO处理还没有很好，所以升迁就先庭住

其心可议 一开始讲鬼故事的时候怎么不好好描述 想引导B是鬼

原PO就被卡升迁7pupu，现在还放不下，不然原PO、A、B都离职了，还要拿出来鞭尸

原来是这样

不管B最后到底有没有测 结果是不变的 因为B确实commit了 A/QA/原PO因为盲区而有的过错与B原来的过错是两回事 都说了N次 不要拿前者的过错来cover B的过错 整天洗B没错 B很严重是事实 这本来就不是一个人导致的你也只能相信原po说的 除非你找到其他当事人加入战局原PO说B没什么责任的前提是B确定不是故意要highlight事情已经结束原PO是分享故事 要卸什么责？ 如果你是原PO在这种公司并遇到这种事情你会怎么做？ 我敢说几乎所有主管都没那么认真 很多主管为了省心不会主动追踪或技术难点确认完毕部门内再检查的结果不就是无法复现搂

你才在整天洗B很严重…之前还要说别人洗地，自己的行为最像在洗地

B很严重有理有据 太多拿自己经验以及脑补想法臆测的不是洗地是什么 本来就是根据内文找线索推论而出 在你眼里就变成洗地... 你们讲的一堆东西都无法验证 什么B只是嘴臭况且我也没有说其他人都没问题 没帮其他人洗地你的洗地概念跟其他人很不一样... 但知道你的意思

事实上，他们公司的处置已经告诉我们，B就算自爆，责任也只跟差不多

你跟A以及QA都知道B提出过有问题 也清楚A跟QA没复制出来当你们关闭该问题时 就是在背书该问题可以忽视你跟A跟QA都知道 那问题没有真正被处理 可能有未爆弹release前你们不清楚哪些功能有上线? B只错在嘴臭而已

处置A与B同是因为原po保了B 以低级错误论处close没有可以忽略的说法 那只是你的经验 开源专案与公司内开关都是有的事情

推