这篇文最鬼的明明就是原PO，这个Feature在他的组开发然后有问题，自己组的人+QA竟然
测不出来，结果隔壁组的人竟然有权限把Feature打开，B就算说原本就知道有问题硬要搞
最后补一句“有可能是我自己环境有问题”也是能全身而退
说到底身为新Feature的lead管产品品质+QA都管不好，有问题的code还能进到release br
anch，最后还能PO出来让大家评论B，这才是我看过最鬼的鬼故事吧

一个是制度有问题 一个是人有问题 这能比吗 哪个比较该死 不能留 大家心知肚明

你讲的是流程跟制度上有问题，但B已经是其它问题了，而且说一句“可能是我自己环境有问题”就能全身而退，在我看来是不可能啦

可怕的是bug 可以随便关，没人审核。Release可以让开发者自行决定随便开feature，没人审核吧。真的是组织制度设计的问题，最鬼的真的不是A或B。结果原文还误导大家问题在A与B。

都有问题啊,只是人的问题,可以靠制度规范,但不是所有组织都能一开始就有完善规定,这时候遇到独善其身的人只能死了

A乱关issue要其他人怎么审核？issue能关本来就一直都有信任成分在，要B负责也很怪，那之后B有权限去重开其他所有人的issue吗？

摆烂的人没啥，失言的该死XD

B不是QA，他有自己code整合进去才是成品，而那成品是有问题的，这不是只有信任上层code问题，而是他是把自己整合完确定还有问题的东西release出去而不是再通知没修好。

用炸客户的方式来highlight内部的人难道没问题吗？

B发现有问题时已经开了bug给A，后来是A关了bug，甚至原po也写了A认为他复制不出来这个问题，肯定是B把自己环境搞砸了，这种时候要求B一人对抗A和QA整个大部门吗？

A有错，但问题较单纯，可能用流程或制度可改善，但B的心态今天不炸你 改天也会炸你，没有职业道德。无论如何只想离B远远的

B没有往自己上面求援让自己安全下庄这倒是B自己的问题，不过以原po透漏的组织来看我是不觉得B有何能耐能让客户不被炸到，B撑著不上自己的code又无法帮A找到问题点，A这边可以说是B害这个feature延期啊

说炸客户有点偏颇 谁知道客户的环境是怎样 如果客户环境是A

B直接 Demo 出问题就可以验证了，哪来无能为力的问题

即使有bug也不会出事 A说没问题 B当然就相信他没问题

B是用A的东西做feature，看到A标无法复制而关issue，他身为第一线使用者不向上反应而且还恶意推送，说到底没人

所以一些人要B一定要挡下来我也不知道为什么，B开给A的b

换成客户和客服就比较清楚，客户回报有Bug有问题但不给任何资讯，客服和后端怎么测都很难找到问题点换成B也是一样，你明知有问题又不想给资讯，当然解不了

A的做法是把制度搞砸，不知道为什么这个版讲得像是日常一样，今天B要挡A close的issue，请问其他close的issue也要B挡吗

A的code影响你的code，你还能说没问题开出去，当然最后主责在你。kernal是A的，feature是B的，没挡那开出去feature有问题，还是你要扛

欸不是 ,B是A功能的第一线使用者耶，直接相关，没有其他人比B更了解实际情况，而且B是知道会炸他还故意让客户炸。

B不给资讯是脑补还是事实？而且整个bug放三个礼拜，A、原po和QA无法让一个B透漏资讯，B是多大咖的魔王吗？你一个客服不给完整资讯我RD不先找客服主管highlight就自己关掉bug？你是把RD当OP还是客服在做吗？

A和QA测不出来，代表code是符合Spec和测试项目的，Use

应该是QA要扛责任吧 怎么会是B 不然请QA来是干嘛的

Case出问题，也只能User提供讯息才能测。这不是B对抗人家，是B搞人家。

我觉得这问题换成A和B只能选一个，你宁愿和谁合作？就比较好选了

原文就有说B不愿意提供资讯，借口说要忙不理了。

Issue CLOSE就是解完了，全部流程就是继续往下跑，难道现在还有"类close"这状态吗？

B真的不提供资讯，我也没看到原po或A有找B的主管这个动作啊，那这所谓B不提供资讯的指控不就很奇怪？

Issue close是解完？A明明是标无法复制

B 有报bug，A找3礼拜，说B没提供环境? 那客户环境只B有?

全部流程哪可能继续往下跑？release前不用再复测一次?

B再怎样也可以开会议或发mail HLA啊，怎可以故意炸客户

下层的code怎么会是B在上？

因为B...负责上层。最后给客户的东西是B整合的啊，当然是B在上。

A跟QA 测试没用客户环境测?

A自己上自己的code才对吧，现在是A有问题的code早就在上面了，B上的只是去call A的部分吧

我是无法理解B都恶意搞事了，还有人觉得他没错，今天他看A不爽就用公司信誉搞人，哪天会不会看谁不爽又这样做呢，防不胜防，谁敢和他合作

破坏公司信誉的原因不就是A没解就把bug关了

原文作者在怪B差点毁到自己的利益，光听他转述B说的话可能不会100%正确

当然不是怎会是A

B故然态度有问题，但是A和QA 不适任或是教育训练有问题

我觉得原文把B描述成恶意搞事是讨论的最大症结 我不觉得是这样 B事后承认就太蠢了 搞这种事就是要最后跳出来当英雄升官

我也觉得写个几句气话就能带到风向蛮神奇的

我看B也不觉得问题有这么大 A都说没问题了

没人会喜欢B，但B事后有没有垃圾话不影响客户炸掉，因为A关掉issue了，除非原po公司close不等同resolve

原文第一句就写A是kernal B是feature了A code 要在透过B整合完才会给客户用

就我使用JIRA的方式来看，resolved后要reporter确认没问题才能closed

不管有没有解，都是B要复测确认才能开出去啊。

你用git的话所谓整合也是各自上各自的code啊

A是kernal，B的工作是整合A，何来各自上各自code?A的Bug直接影响B的code

A是标无法复制关的issue,不是标解决吧，而且B不用测吗

A的function平常不会被call当然自己上没问题啊，现在是B的feature会去call，所以一开始有问题B开了bug，结果三周后A认为是B自己搞砸环境造成，那B为何不能上自己那部分没问题的code？A认为他复制不出来这个问题，肯定是B把自己环境搞砸了。A都这样说了，QA也测不出来，这样B要怎么证明自己的环境才是对的？

很简单啊，把A叫过去给他看demo啊

你平常写的程式 call的 library 有问题，你觉得你写的call function没问题，所以你觉得就可以开出去吗？

library的开发者认为是我的环境有问题，我无法证明谁的环境才对而出事他愿意负责那我当然上啊

所以，你其实就是B吧...希望不要遇到你

很好啊，摆烂的总是不愿意遇到想做事的人这没啥问题

A说环境搞砸close掉issue你要B拿什么去挑战，这样会变成B要去找A吵架来把关产品的品质，这样流程静电很不合理*流程变得

我是B的话当然先拉主管进来下车之后看A部门决定怎么做啊

对啊应该拉主管 而不是放出去啊

正常流程就是bug reporter覆核不过，除非流程里不要求覆核。

拉主管这点完全同意，但我想这边都是在讨论事后究责吧

从原文就是只说A关了bug啊，B看来不是争论输了就是根本没必要他同意

如果流程上有覆核，那主责任就在B身上。

RD居然可以随便关ticket，当QA塑胶的吗

看到现在总觉得原po有些事情没有讲，当故事来看就好

原po留言有说他扛责了呀 感觉他发这篇只是想臭b

一个bug 弄3个礼拜是正常的吗?一个feature 是有多大? 还是A部门有一大堆债?

反正这故事里面看起来也没人在review issue,所以RD可以随便关ticket也没什么吧

就是一锅粥，然后现在在那边互喷，呵呵

写出bug给其他部门测到谁没有过？但明知道有严重bug还出给客户 这我可从来没做过

讨论半天怎么没人讨论到QA 就算RD想乱搞 也要过QA这关吧

qa跟A同部门呗

原po推文自己有说B有开bug给QA也被关

原来开 issue，开发者可以随便关掉的喔。推文真的大开眼界。这种情况，谁还要解Issue，直接关掉就好。顺便报一下公司部门啊，听起来好爽的单位。另外，哪一套issue管理系统，别人/别部门提的issue，自己可以关？ 我也是从来没见过啦。

隔壁讨论串更猛 还有你的close不是close笑死

正常A搞不出来 主管要帮A看吧

一般是可以标记状态 但关不关掉权限不在RD所以这问题确实是制度很鬼 人人可开关 没人管为何

b的背景原作交代不清啦 我提出你的func有问题，结果你说没有问题，原作也没详述b到底有没有提供，a收到问题也没有向上呈报，跨部门处理，就这样当作没问题，怎么想都是a有问题啊，要死一起死 赞赞

我也觉得原po的问题最大

只有一来一往阿 B回报问题A/Qa 找不到close B没再踢回去开issue开发者不能随便关那当初就不要给权限 楼主的公司肯定不是制度非常好的

严格说起来是A部门的bug,别的部门B帮忙测出来就该感谢了

这都不算太算bug 是feature 不支持该客户环境的feature 测出来暗杠,ㄏ话说其实只要技术上禁close就好权限划分

说B有问题是他自爆或是站在上帝视角

没有上帝视角B被小惩是这样 毕竟他是统整的人 他如果隐藏那会是更恐怖的人 但这事情没如果 你掘地三尺必然会更接近真相 你还在那边如果如果那这问题就变写故事而不是说故事

客户那边出事了 原来是这两个闹小脾气的搞事 谁在乎权限三小 通通下去

这是全部人的问题 这事件原po/A/B通通下去了 只是时间早晚

A自己能close bug 是公司流程有问题 A自己也不搞清楚不负责 B明知有问题A没解好就close了 故意让它出去来highlight A 这心态很有问题 而且这个feature是他的责任 底层没好他把feature一样丢出去 以为之后客户会回来highlight A 心态做法都错

真是蛮多人要B当上帝的样子XD，B遇到问题时开了bug，结果A认为是B把环境搞砸才有这个问题所以关了bug，不少人拿B后来的嘴砲咬定B知道一定会在客户那边炸开？这其实后来原po补充那篇就说明根本不是了，不然在客户那边炸开后怎么也无法在B的环境复现？

底层没好 feature就出去了是啥小 以为root cause不在己就没事? 对外面的人来说这个feature的问题就是B的问题 应该是B要把关 B要去追A请他改好 A坚持不改那就报上去 请QA或主管处理

文章要看清楚啊，底层到上层串接功能基本上是没有问题，他们release前QA还测过好吗…B遇到的是某个状况下会有资料损毁的状况，但这状况在A与QA的环境中都不会发生，所以要说什么没有整合好根本就不是这样啊，B的整合只是去call A的function，造成资料损毁是因为A function里的动作而不是B整合的问题啊所以B当初开了bug给A，而A认为B环境搞砸才会遇到，那本来就是A的问题啊，A不是把bug挂回B说是B没整好ok？还有从原po两片叙述来看A部门关闭bug也没有经过B同意，所以B到底该怎么挡？两篇*这里有这么多人不在意bug被关闭而在意B嘴巴说的实在让我觉得非常神奇，难道台湾多数公司的软件开发都还在用嘴巴管理bug吗？

那以后有要整合麻烦找j大啊，有几个module出包就请他扛责任几次，毕竟这是他整合的

优文

追踪平台就是方便你追踪 你要拿来当什么标准那就多了 很不可靠的东西拿来用还判断一些有的没有是环境问题阿 这不能全算A程式的问题 至于在意B所说是他不想帮就算了搞到全公司 影响范围很大 最好这不严重 就是非常严重B本来就应该推掉整合的角色 B可以踢回去这讲了好几次还有人在问"所以B到底该怎么挡?"

B自己就说了 明知道有问题要用这种方式highlight A是还要再辩什么? 这跟上帝不上帝有什么关系? 就知道有这个问题而且 也爆了 扯一堆环境不环境的

A认为他复制不出来这个问题，肯定是B把自己环境搞砸了，这第一篇自己说的B的说词是在客户那里炸了之后，而第二篇看他们release流程，release时QA也都验过，客户炸了之后用B环境也无法复现，所以后来才又发现是LAGG造成，整个看下来B也只是蒙到的啊…

A有没有问题关我屁事 之前就有说他有问题啊 QA也有问题 这个大家都知道 问题是事情爆开来你觉得公司只去会怪A吗? 应该是两个都怪吧 重点是B的心态跟做法而且他也得偿所愿 他高兴就好 反正就是要让大家highlight A 公司产品炸掉也没关系 他是明知故犯的

又一个思想犯该死的，算了…

wmt是不是没在看文 B哪有再测一次 B明明讲后来就没有再测 B是认定绝对有这bug 100%

B 就态度问题而已 装白痴平安度日不好吗？ a都把bug关了 没打算争取关注 就让事情放水流 炸了查事件 就是a的问题 别多嘴就好了

一个是制度有问题 一个是人有问题 这能比吗 哪个比较该死 不能留 大家心知肚明

你讲的是流程跟制度上有问题，但B已经是其它问题了，而且说一句“可能是我自己环境有问题”就能全身而退，在我看来是不可能啦

可怕的是bug 可以随便关，没人审核。Release可以让开发者自行决定随便开feature，没人审核吧。真的是组织制度设计的问题，最鬼的真的不是A或B。结果原文还误导大家问题在A与B。

都有问题啊,只是人的问题,可以靠制度规范,但不是所有组织都能一开始就有完善规定,这时候遇到独善其身的人只能死了

A乱关issue要其他人怎么审核？issue能关本来就一直都有信任成分在，要B负责也很怪，那之后B有权限去重开其他所有人的issue吗？

摆烂的人没啥，失言的该死XD从原po讲的组织来看，A与原po同部门，原po可能是主管或资深人员，因为他扛feature成败，QA与他们是同一个大部门，只有B是另一个大部门的人，B的主管看来也没有进到这个案子处理，现有资讯看起来原po的大部门应该是这功能甚至整个案子的主导部门吧？那原po所谓的B release feature指的是什么？把他上层没问题的code进到release branch吗？这有什么问题？有问题的是A的code，这部份是A自己已经上了才会被B开bug不是吗？结果一堆人因为原po最后两段可能是B的气话觉得B很雷？我只觉得有心人比鬼还可怕…

B不是QA，他有自己code整合进去才是成品，而那成品是有问题的，这不是只有信任上层code问题，而是他是把自己整合完确定还有问题的东西release出去而不是再通知没修好。

用炸客户的方式来highlight内部的人难道没问题吗？

B发现有问题时已经开了bug给A，后来是A关了bug，甚至原po也写了A认为他复制不出来这个问题，肯定是B把自己环境搞砸了，这种时候要求B一人对抗A和QA整个大部门吗？

A有错，但问题较单纯，可能用流程或制度可改善，但B的心态今天不炸你 改天也会炸你，没有职业道德。无论如何只想离B远远的

B没有往自己上面求援让自己安全下庄这倒是B自己的问题，不过以原po透漏的组织来看我是不觉得B有何能耐能让客户不被炸到，B撑著不上自己的code又无法帮A找到问题点，A这边可以说是B害这个feature延期啊

说炸客户有点偏颇 谁知道客户的环境是怎样 如果客户环境是A

B直接 Demo 出问题就可以验证了，哪来无能为力的问题

即使有bug也不会出事 A说没问题 B当然就相信他没问题

B是用A的东西做feature，看到A标无法复制而关issue，他身为第一线使用者不向上反应而且还恶意推送，说到底没人

所以一些人要B一定要挡下来我也不知道为什么，B开给A的b

换成客户和客服就比较清楚，客户回报有Bug有问题但不给任何资讯，客服和后端怎么测都很难找到问题点换成B也是一样，你明知有问题又不想给资讯，当然解不了

A的做法是把制度搞砸，不知道为什么这个版讲得像是日常一样，今天B要挡A close的issue，请问其他close的issue也要B挡吗

A的code影响你的code，你还能说没问题开出去，当然最后主责在你。kernal是A的，feature是B的，没挡那开出去feature有问题，还是你要扛

欸不是 ,B是A功能的第一线使用者耶，直接相关，没有其他人比B更了解实际情况，而且B是知道会炸他还故意让客户炸。

B不给资讯是脑补还是事实？而且整个bug放三个礼拜，A、原po和QA无法让一个B透漏资讯，B是多大咖的魔王吗？你一个客服不给完整资讯我RD不先找客服主管highlight就自己关掉bug？你是把RD当OP还是客服在做吗？

A和QA测不出来，代表code是符合Spec和测试项目的，Use

应该是QA要扛责任吧 怎么会是B 不然请QA来是干嘛的

Case出问题，也只能User提供讯息才能测。这不是B对抗人家，是B搞人家。

我觉得这问题换成A和B只能选一个，你宁愿和谁合作？就比较好选了

原文就有说B不愿意提供资讯，借口说要忙不理了。

Issue CLOSE就是解完了，全部流程就是继续往下跑，难道现在还有"类close"这状态吗？

B真的不提供资讯，我也没看到原po或A有找B的主管这个动作啊，那这所谓B不提供资讯的指控不就很奇怪？

Issue close是解完？A明明是标无法复制

B 有报bug，A找3礼拜，说B没提供环境? 那客户环境只B有?

全部流程哪可能继续往下跑？release前不用再复测一次?

B再怎样也可以开会议或发mail HLA啊，怎可以故意炸客户

下层的code怎么会是B在上？

因为B...负责上层。最后给客户的东西是B整合的啊，当然是B在上。

A跟QA 测试没用客户环境测?

A自己上自己的code才对吧，现在是A有问题的code早就在上面了，B上的只是去call A的部分吧

我是无法理解B都恶意搞事了，还有人觉得他没错，今天他看A不爽就用公司信誉搞人，哪天会不会看谁不爽又这样做呢，防不胜防，谁敢和他合作

破坏公司信誉的原因不就是A没解就把bug关了

原文作者在怪B差点毁到自己的利益，光听他转述B说的话可能不会100%正确

当然不是怎会是A

B故然态度有问题，但是A和QA 不适任或是教育训练有问题

我觉得原文把B描述成恶意搞事是讨论的最大症结 我不觉得是这样 B事后承认就太蠢了 搞这种事就是要最后跳出来当英雄升官

我也觉得写个几句气话就能带到风向蛮神奇的

我看B也不觉得问题有这么大 A都说没问题了

没人会喜欢B，但B事后有没有垃圾话不影响客户炸掉，因为A关掉issue了，除非原po公司close不等同resolve

原文第一句就写A是kernal B是feature了A code 要在透过B整合完才会给客户用

就我使用JIRA的方式来看，resolved后要reporter确认没问题才能closed

不管有没有解，都是B要复测确认才能开出去啊。

你用git的话所谓整合也是各自上各自的code啊

A是kernal，B的工作是整合A，何来各自上各自code?A的Bug直接影响B的code

A是标无法复制关的issue,不是标解决吧，而且B不用测吗

A的function平常不会被call当然自己上没问题啊，现在是B的feature会去call，所以一开始有问题B开了bug，结果三周后A认为是B自己搞砸环境造成，那B为何不能上自己那部分没问题的code？A认为他复制不出来这个问题，肯定是B把自己环境搞砸了。A都这样说了，QA也测不出来，这样B要怎么证明自己的环境才是对的？

很简单啊，把A叫过去给他看demo啊

你平常写的程式 call的 library 有问题，你觉得你写的call function没问题，所以你觉得就可以开出去吗？

library的开发者认为是我的环境有问题，我无法证明谁的环境才对而出事他愿意负责那我当然上啊

所以，你其实就是B吧...希望不要遇到你

很好啊，摆烂的总是不愿意遇到想做事的人这没啥问题

A说环境搞砸close掉issue你要B拿什么去挑战，这样会变成B要去找A吵架来把关产品的品质，这样流程静电很不合理*流程变得

我是B的话当然先拉主管进来下车之后看A部门决定怎么做啊

对啊应该拉主管 而不是放出去啊

正常流程就是bug reporter覆核不过，除非流程里不要求覆核。

拉主管这点完全同意，但我想这边都是在讨论事后究责吧

从原文就是只说A关了bug啊，B看来不是争论输了就是根本没必要他同意

如果流程上有覆核，那主责任就在B身上。

RD居然可以随便关ticket，当QA塑胶的吗

看到现在总觉得原po有些事情没有讲，当故事来看就好

原po留言有说他扛责了呀 感觉他发这篇只是想臭b

一个bug 弄3个礼拜是正常的吗?一个feature 是有多大? 还是A部门有一大堆债?

反正这故事里面看起来也没人在review issue,所以RD可以随便关ticket也没什么吧

就是一锅粥，然后现在在那边互喷，呵呵

写出bug给其他部门测到谁没有过？但明知道有严重bug还出给客户 这我可从来没做过

讨论半天怎么没人讨论到QA 就算RD想乱搞 也要过QA这关吧

qa跟A同部门呗

原po推文自己有说B有开bug给QA也被关

原来开 issue，开发者可以随便关掉的喔。推文真的大开眼界。这种情况，谁还要解Issue，直接关掉就好。顺便报一下公司部门啊，听起来好爽的单位。另外，哪一套issue管理系统，别人/别部门提的issue，自己可以关？ 我也是从来没见过啦。

隔壁讨论串更猛 还有你的close不是close笑死

正常A搞不出来 主管要帮A看吧

一般是可以标记状态 但关不关掉权限不在RD所以这问题确实是制度很鬼 人人可开关 没人管为何

b的背景原作交代不清啦 我提出你的func有问题，结果你说没有问题，原作也没详述b到底有没有提供，a收到问题也没有向上呈报，跨部门处理，就这样当作没问题，怎么想都是a有问题啊，要死一起死 赞赞

我也觉得原po的问题最大

只有一来一往阿 B回报问题A/Qa 找不到close B没再踢回去开issue开发者不能随便关那当初就不要给权限 楼主的公司肯定不是制度非常好的

严格说起来是A部门的bug,别的部门B帮忙测出来就该感谢了

这都不算太算bug 是feature 不支持该客户环境的feature 测出来暗杠,ㄏ话说其实只要技术上禁close就好权限划分

说B有问题是他自爆或是站在上帝视角

没有上帝视角B被小惩是这样 毕竟他是统整的人 他如果隐藏那会是更恐怖的人 但这事情没如果 你掘地三尺必然会更接近真相 你还在那边如果如果那这问题就变写故事而不是说故事

客户那边出事了 原来是这两个闹小脾气的搞事 谁在乎权限三小 通通下去

这是全部人的问题 这事件原po/A/B通通下去了 只是时间早晚

A自己能close bug 是公司流程有问题 A自己也不搞清楚不负责 B明知有问题A没解好就close了 故意让它出去来highlight A 这心态很有问题 而且这个feature是他的责任 底层没好他把feature一样丢出去 以为之后客户会回来highlight A 心态做法都错

真是蛮多人要B当上帝的样子XD，B遇到问题时开了bug，结果A认为是B把环境搞砸才有这个问题所以关了bug，不少人拿B后来的嘴砲咬定B知道一定会在客户那边炸开？这其实后来原po补充那篇就说明根本不是了，不然在客户那边炸开后怎么也无法在B的环境复现？

底层没好 feature就出去了是啥小 以为root cause不在己就没事? 对外面的人来说这个feature的问题就是B的问题 应该是B要把关 B要去追A请他改好 A坚持不改那就报上去 请QA或主管处理

文章要看清楚啊，底层到上层串接功能基本上是没有问题，他们release前QA还测过好吗…B遇到的是某个状况下会有资料损毁的状况，但这状况在A与QA的环境中都不会发生，所以要说什么没有整合好根本就不是这样啊，B的整合只是去call A的function，造成资料损毁是因为A function里的动作而不是B整合的问题啊所以B当初开了bug给A，而A认为B环境搞砸才会遇到，那本来就是A的问题啊，A不是把bug挂回B说是B没整好ok？还有从原po两片叙述来看A部门关闭bug也没有经过B同意，所以B到底该怎么挡？两篇*这里有这么多人不在意bug被关闭而在意B嘴巴说的实在让我觉得非常神奇，难道台湾多数公司的软件开发都还在用嘴巴管理bug吗？

那以后有要整合麻烦找j大啊，有几个module出包就请他扛责任几次，毕竟这是他整合的

优文

追踪平台就是方便你追踪 你要拿来当什么标准那就多了 很不可靠的东西拿来用还判断一些有的没有是环境问题阿 这不能全算A程式的问题 至于在意B所说是他不想帮就算了搞到全公司 影响范围很大 最好这不严重 就是非常严重B本来就应该推掉整合的角色 B可以踢回去这讲了好几次还有人在问"所以B到底该怎么挡?"

B自己就说了 明知道有问题要用这种方式highlight A是还要再辩什么? 这跟上帝不上帝有什么关系? 就知道有这个问题而且 也爆了 扯一堆环境不环境的

A认为他复制不出来这个问题，肯定是B把自己环境搞砸了，这第一篇自己说的B的说词是在客户那里炸了之后，而第二篇看他们release流程，release时QA也都验过，客户炸了之后用B环境也无法复现，所以后来才又发现是LAGG造成，整个看下来B也只是蒙到的啊…

A有没有问题关我屁事 之前就有说他有问题啊 QA也有问题 这个大家都知道 问题是事情爆开来你觉得公司只去会怪A吗? 应该是两个都怪吧 重点是B的心态跟做法而且他也得偿所愿 他高兴就好 反正就是要让大家highlight A 公司产品炸掉也没关系 他是明知故犯的

又一个思想犯该死的，算了…

wmt是不是没在看文 B哪有再测一次 B明明讲后来就没有再测 B是认定绝对有这bug 100%

B 就态度问题而已 装白痴平安度日不好吗？ a都把bug关了 没打算争取关注 就让事情放水流 炸了查事件 就是a的问题 别多嘴就好了