我是原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%全责