讲一个我在科技业遇到的鬼故事
这件事主要发生在两个人身上：
A:是我同部门的同事，主要开发kernel层以下的功能。
B:是隔壁整合部门的同事，主要是开始kernel层以上的功能。
有一天A开发了某一个功能，B整合完之后发现会导致资料损毁。于是B发了一个bug给A，
但是A无论如何都复制不出来，这样来来回回弄了三个礼拜。
这期间B认为他把bug发出去了，解不解得掉是A的问题，这中间不愿意提供一些厘清环境
的协助，跑去忙其他功能去了。
而A认为他复制不出来这个问题，肯定是B把自己环境搞砸了，于是三个礼拜之后就把bug
mark成"无法复制"之后，关掉了。
接下来精彩的来了，B认为这个bug是A造成的，他都不想去解这问题摆烂，于是B把这个
feature打开了，并且release给客户。 QA也没有拦住这个问题的测项，于是最终在客户
端炸开了。
由于客户数据炸的很严重，我被抓去协调解决这一题。我分析了log后，我把A和B还有QA
找来讨论这一题。
结果B开场就说：这个bug我知道，就是A那边有问题。
然后A把他如何找问题的过程讲了一遍，意思就是他无法复制。
B就跳出来说：A都不认真去找问题，直接把bug关了，我就是为了highlight这个问题，所
以把这个feature打开commit上去。
我说：你的意思是说，你明知道这个feature打开之后会炸掉，你还commit上去？
B说：对啊，我就是要highlight这个问题，这个feature我有整合进度压力，但是A都不去
解root cause。
我说：你的意思是说，你明知道这个feature打开会让客户资料损毁，你还故意打开这个
feature要来highlight A？
B说：对啊！

这种八成是之前就有冤仇了啦....

干嘛不直接rollback a的code

那 QA 没测试到耶

B这样能开除加要求赔偿吗？

B 把 bug 先报给 QA 不就好了直接发布等于把自己信用赔进去

对，QA没有验出来，原本我跟QA都要提头去见老板了。B有把bug回报给QA，但是QA也没有试出来。

B也太神了 无论如何内部多不合 也不该release到客户吧直接害公司要赔偿客户 这神逻辑 就算A摆烂B也不该这样

怎么没有review机制

他没先从内部想办法处理 就用这种外部成本来HL到A??B想HL到A没想到HL到自己吧 喝

可以贴出哪一位吗 避免大家以后遇到

B把变红的机会直接变黑耶。

B没想过 A无法复制 QA又测不出来 难道不是B自己的问题?

我猜B就是想commit上去，让‘客户’证明不是自己的问题

客户能分辨出是谁的问题的话 干嘛不自己赚 傻

让客户炸掉无法证明不是B的问题呀

事后回想，其实B只要什么都不讲，就安全下庄了。

真的吗????那会变谁背锅? QA?

不可能吧呀，一定追得到。你都知道他commit 有bug的东西了。他是动机很有问题

最后是我揹锅，跑去客户那边想办法恢复资料。A/B 当年考绩炸裂，A先离职。B半年后因为一些小事被火B最后是因为请别人代打卡被火

你算救援吧。A、B考绩炸裂才是背锅吧我比较好奇当下怎么没有开除B

大B哥，厉害惹

我的职位要扛feature成败，所以我也因此卡到升迁。没有火B这件事我也是傻眼+不满，所以我比B还早离职 XD

B这心态，阿弥陀佛

其实原本我+A+QA都是主责，但是B一招神龙摆尾全扛了

这B头壳撞到吧？

真的是什么鬼故事都有

PC哥这篇之前是不是发过了 好像在哪看过

不对啊怎么说都是先火B吧

我在个人FB发过，今天想到贴来跟大家分享一下。

待打卡被火该不会是有上新闻的

代打卡那件事我是离职后听人转述的，我没发现什么新闻XD

再现不出来是验证的能力不足呗输入毒物也好状态操作也罢，一堆除错方法能当测试手段

所以最后找到的问题点在哪方？ 很糟糕的状况所以B先搞掉你们？

最后问题是A的code在某一种使用情境下有问题没考虑到。这种情境刚好B跟客户会遇到，A跟QA都没有假设过这种情境

这B真是极品，想弄A不管对整体产品信誉客户的影响，然后还大辣辣自爆，到底是聪明还是蠢....真是什么人都有

故意将有bug的东西commit上去，这样炸锅是全公司都死耶….

所以B当初也有扣押讯息不说的问题就是 看起来就很像人走光轻松了找人代打卡

觉得B最后做法是错的，但是他也有回报出问题，就A、QA跟最后把关的你的问题。假如你能看出问题点，这整件事情都不会发生。

B与客户知 QA都不知 就是讯息不对称搂B肯定当你们是敌人就是 统整的人刻意不提供完整讯息......

B这人有够雷 留着迟早出事

傻眼 傻子

不过很好奇哪间公司 B会不会出来讲呢？内部人员勾心斗角都不会心累...

就老害啊

某一种使用情境...重现方法没有附在bug上吗然后A复制不出来也没办法找B当场重现一次?

B要被五马分尸，笑死。

bug开着卡了feature三个礼拜 扛feature成败的人不应该等问题流到客户那里才知道吧? 这种有跨team争议不需要长官出来协调吗?

B挖个洞结果没发现是自己跳进去了

B就是脑残啊，这个留下，迟早再出另一个大包在怎么不爽，也要先跟主管说，怎么会爆给客户

B除了多话外好像没做错什么. Bug也不是他写的，也回报给a跟qa，甚至挡了3个礼拜同时还要做别的功能. 结果票被关掉说无法复制大概觉得同事程度都很差放弃叻. 要烂一起烂lol

qa干什么吃的 然后到底是不是a的问题 issuse关闭的检证机制也有问题b应该能力不错 但就是要一起烂

再说事关自己的升迁, 原po怎么好像事前一无所知. 心脏也是蛮大颗的

疑点大家都说了 我只能说这个团队关系很差

B根本没错 错在说错话 责任归属QA>A推文显示出台厂文化 先解决提出问题的人

如果我是A,然后bug一直重现不出来.我会委屈一点，到B那边，直接请他重现bug给我看.确认bug了，但还是在我自己的环境上重现不出来.我会商请主管征用B的电脑，请B去旁边玩沙...,让我直接在他环境上解bug, 以上

欸欸，我商科的，是不是意思是B知道A做出来的菜有毒还出给客人这样

总觉得事实应该不只这些，不过现在对原PO来说也已经不重要了

重点是出到客户那了吧qq

QA都验过毒了

这真的是鬼故事XD楼上有人是不是有点搞错原po的意思了？楼主有说这责任原本应该是他+A+QA的，但因为B为了证明不是自己的问题，所以直接release给客户，导致客户炸掉，让重点转到了B身上

B 也太猛了，这个事故绝对B占90%的责任，明知店里的菜有毒还端给客人吃…

B真的太多话了，他不说那几句就可以完全没事

楼楼上 A和QA说没毒啊。厨师自己都说没毒了

嗯...正常不是都应该要一起查问题吗

QA把关不到位 A程式品质差且态度消极 B错在选了最差的方式HL 最大问题是issue严重程度明显被低估就放行了 不过这个故事里缺了好几个该把关的角色(A,B主管) 也许还是看看就好

a跟b是人本身有问题跟科技业无关吧

B A两人是不会讲话沟通吗？只会用issue 选项沟通？但整件事情看起来，B是最糟糕的竟然让客户参与了debug 。他有不高兴不爽可以内部提出啊，这是什么沟通方式好可怕A复制不出来问题，B也不帮忙，从这一步开始B就错了，你在公司工作重点是产品本身，而非展现你很强别人很弱。

有问题的人比会不会写code还重要，这种根本不定时炸弹，雷暴

你也有问题啊 你都说你需要扛feature成败了 却让bug卡三礼拜不去协调 正常担责的是积极介入请A提供更多资讯给B

总觉得是两个个性不合的人，AB一直合作对冲，结果都产生硬干对方的想法，原po算虽小，QA就没尽责，该说这样的沟通合作问题主管其实要上点心吗？XD

明知有重大问题还出给客户是怎样 公司商誉都不用顾了？

B雷炸 只顾自己好?一堆人擦屎就饱了

B跟A都没有主管就对了？那家公司那么自在啊？

B事后自爆的做法也很奇怪吧正常人好歹说A重现不出来以为是误判才release

这两个都应该火掉但是B比较严重,拿客户做实验

B只要说他相信原po team有处理就没他的责任了，B太多嘴了 XD

XD 推文里面说“B如果怎样怎样说不就没事了吗”问题B就不是正常思维啊 XDDD 正常人一开始就不会这样乱搞

你可以跟A说好了啦，都是你最惨，不爽离职啊嘻嘻

B这种就是赌气硬搞阿，而且是明知道后果仍要做，根本超大雷这种才团队里面超可怕，啥时爆走都不知道

这哪叫鬼故事==

说B没错的是认真的吗？

这就人品问题

不是啊 就A跟QA都复制不出来啊 所以这问题到底有没有存在

问题确实存在，后来也找到复现方法，但当下就是环境不对

应该是一间没有制度的烂公司

再来一个B这样的家伙，我没信心挡得住他......

看起来推文可以排雷不少人B可以没问题的情况是他也不知道这Bug就Commit上去，出了事就是其他人的事他现在都回报Bug了，也没有解决仍然Commit上去，那就问题可大了不过这公司也很鬼，Bug卡三周还只有B、A处理，其他人在干嘛？

因为当时其他问题卡更久......

问题就是把issue关闭的那位啦

我觉得是你跟B的合作关系有问题，B应该认为“我提出的问题被无视，A跟QA都没问题，我看就有问题，你们觉得没问题好啊那就上啊”但是为什么B在出事之前没有试着找你这个负责人沟通就像B说的，他也有时间压力，A不去解，这整个专案运作的人跟进度都有问题，你被卡升迁也是刚好，专案顺利有得升，不顺利就没得升，才是正常的赏罚

这件事有一个背景，就是A是我的RD。没有B也不会发现这问题

如果你照样能升迁那就是小兵扛责长官收割的那种公司

没有B应该也是会出事，A也会全扛。只是有B之后变各50%本来就应该是我+QA+A要全扛没错，我也认为我应该扛最多 XD

照你这样说，B其实也满虽小的，A写了一个严重bug，他本来不在这个坑里，好心插手结果被无视最后还招一个骂名什么时候出续集XD

对，B错在最后不应该自己讲出来，他其有很多路可以甩锅。

这个在台湾常发生啦，简单说就是权责不分+公司制度导

为什么我考绩没有影响，那是因为最后客户资料我有救回来。

致，公司如果有bug回报系统之类的，公司主管也愿意花

最后有人认为我A+B各打50这件事是我在‘护短’B的老板也觉得我在甩锅给他们，所以B只影响考绩，没有PDCA

时间和组员开会讨论这些bug，说不定可以避免掉

如果每个问题好好review，或许可以避免这样的遭遇。故事最后，就是大家打迷糊仗的状态下辗过去了。

干好猛，我还以为只有银行端会有这种，我就烂，要死一起死

B故意再搞

团队应该有更严重的人际问题吧单方说词不太能判断

再怎样也不能影响到客户吧

我听到的鬼故事是印度佬为了推行自己的新东西，故意把错误的code commit上去让公司系统炸开. 事后跳出来说他这样是为了公司好blabla

B就豁出去了，要死大家一起死

无法接受损人不利己的事情。发现有B这样的同事我会尽最大努力远离他。

B在之前没用其他方法HL？ 像是给A主管？ 而且两部门间看起来关系也没很好，那真的要B协助Debug，应该找他主管，让他可以把其他工作往后推吧

应该都要处分吧 虽然结果也是都闪人 啊问题卡三周 原po没有要处理吗

A是不是只回B一句，“我无法复制”就把锅推回去。

B除了说真话有什么错吗 哈哈A验过 QA验过不就通过表面品质保证真的到客户出事那就是A再来解决囉

B没事就开天窗？ 怎么看都是得过且过的公司文化 B整的很度烂

虽然看起来很扯，但一堆公司都这样吧，重现不了就摆着KPI重要，怎么可能跟你在那边研究几个礼拜...

另外应该再描述一下你的公司文化，开发制度，这样可以更精准评价，既然你想讨论的话

的确，当时公司正处于一个新事业发展初期。新产品问题一堆能复制的问题都解不完，不能复制摆个一个月也很常见。

B已经仁至义尽了...他大可连有bug都不跟你们说帮你发现bug还被要求帮你复制问题 帮你厘清没几个人会想吞吧

B会回报bug是因为东西在他环境一跑就炸，根本整合不了。不过公司就是这样，B的KPI不是整天卡在帮别人复制bug上。

重现不了当然就切掉啊...所有公司都是这样

推文中有说B不是同一个team的，那就不是很意外

B的问题是他的心态，摆明了就是公司死是公司的事 不是我的事，或是为了赌气会拉着大家一起死的人文中A都搞了三个礼拜了(打个折当作他实际只弄一个礼拜)

所以整间公司都有问题 哈哈

有责任心一点就是CC给自己老板跟对方老板

组织状况：{{我,A} QA}, {B, B的主管}

老实说也差不多了 以前我在某几千人的IC设计公司 一个bug卡一个礼拜还是没办法重现的话也是直接切掉总要有个停损点 try不出来就去解别的bug没啥问题

楼上这就双标了呀 认为公司死不是他的事的人岂不是允许bug被关了的所有人吗?

bug卡X天就close这个本来就是一般公司的SOP啊 这是成本考量 任何一个公司都不可能放RD每天在那边研究try不出来的bug

B报给QA，QA试不出来，然后QA就决定不管了这样吗XDD

会导致重要资料毁损的bug,也不该由底下RD自行close...

那怎么对B就那么严格呢? 这bug甚至不是他弄出来的 他的feature被卡也要要有个停损点吧? 怎么就变不顾公司死活了

中间B的态度也很可议 bug发出去后就认为解不解得掉是A的问题 中间不愿意提供协助 这种就是完全没团队合作精神的例子

“B发现整合会造成资料损毁 但QA有过” 双方也不需要沟通吗

你是不是之前有投靠北工程师？好像看过一样的故事

QA也是未爆弹 原po要注意 喔烦沟通就快跑

即便B不多说话 版控记录还是他commit 鼓励甩锅？B仁至义尽？ 以楼主目前说出来的B问题非常大除非有什么其它内幕B无庸自疑是最接近客户端的 A不会知道客户的情况目前来看是B暗杠了讯息不说加上后来找人代打卡 人肯定有问题 楼上一些人是不是干过同样的事 事不关己大家都差不多 但最后问题出在使用情境 这部份除了B谁知...

说B没错的是不是在开玩笑或是反串

目前除非能证明A乱写 技术面分析B端的是通例 我们到目前为止还不知到什么bug而且程式我不相信只有A在搞

B的问题在明之有问题还擅自作主commit上去 应该至少经原po或B的上头的同意 如果有经上头同意 B就不用扛责

这题B错在太蠢，自以为聪明，我猜年资很浅。A把issue close了，不就代表没bug或已解，那B凭什么不开？B的职务看起来是整合，function owner A都担保没问题了，B只是把他份内工作处理好。至于什么A无法复现，要不到环境，说白了这是A的能力问题。A敢把issue close，就是得扛function没问题的责任，一句无法复现就敢结案真的满屌。

B的问题就是要冲康人还白痴到说出来

在这种情况下A确实无法复现 难道要A通灵？

那A要肯定是B的环境问题啊，这本来就是要自清。叫不动B，无法复制B环境，这些硬要划分都是A的责任。打出bug后funtion owner敢close，不就代表有十足把握？

不鼓励冲康人 你再会掩饰都会透风 有没有人去细查而已

好惨

function owner都讲不是bug了(issue close)，B身为一个整合者，当然就是相信A的判断阿。

叫不动B怎么会是A的问题...

因为function是A的，要怎样解都是他的职责。

我觉得要看b有没有像上反映啦 上面如果认同就这样close 不就也认为是b环境问题

同意MT6797的说法，B只要不自己承认，基本上没有他责任。鬼故事的点就在于，B竟然自己承认了......

B是蠢在他讲说自己知道有BUG还硬上...

B没义务帮你，他的工作内容我想不会有协助隔壁部门debug，他花时间帮自己schedule 爆掉算谁的？

他不承认也是他commit的 他不会不知道有这问题这个bug本身不是只有一方的问题 是在鼓励干坏事不留

整合者不知道function内容很常见...最了解function的owner A都挂保证没问题了，B正常情况不用去质疑这件事。

痕迹就是... 以楼主回应就不是纯A的问题

在我的认知上，敢issue close就是owner挂保证没问题。

这样就相信了那也不用QA 除非这东西是A从头写到尾

B不承认的话，我认为责任本来就是在A跟QA身上啊。

close理由说无法复现就不是纯A的问题

我文章看下来B是整合者啦，整合者把所有funtion验一遍我是没遇过这种神手。当然是A的问题，无法复现跟issue clsoe你敢画上等号？该举手求救、乔资源还什么的就应该做啊，找主管啊，结果直

不同职务当然B不需要知道 但B自己掌握的讯息没讲给人

接说这不是BUG... 够屌。

这肯定是bug 哪个人说不是？ 只是不是纯A问题的bug

肯定是bug... A还issue close... 这不是问题

我也好奇你提到 掌握讯息 这一个论点是哪里来的？

掌握客户端与测试端环境不同的讯息 你是不是没看楼主

鬼故事的点难道不是B主管神隐吗XD 不管是要推或扛至少站队自己底下的人吧 能够硬commit出事主管怎会无责

好奇哪家公司issue解不出来也可以close的？

楼主在推文有讲出问题的地方 所以你就是没看到楼主推

要整合者比function owner还了解function，还要帮验，也满屌的这个。

文 这个点A是不会知道的

A要去厘清啊= =

不是纯A的问题不假

负责function被打出时灵时不灵，因为我不知道为什么有时坏掉，那不是我责任。

无法复现卡三周不就是了 什么叫A要厘清 他拿什么厘清

从时间点来看B也不知道客户环境C啊，A B C三个环境恰好A的跟别人不一样

拿什么厘清？那是A自己得解决的啊= =A要是觉得B环境问题，找主管帮忙乔资源还什么就该去做。

没事的话，就只是B在叫叫叫而已

B的环境与客户的是同的 ㄊ他不了解谁相信 楼主提供的讯息来看就是这样 A客户端都不了解要怎么解决？

那也许B要串资源，但是串不动A是B的责任这样

我认为情况是反过来，A需要串资源，串不动是他的责任。

而且到底B环境跟客户C环境哪里一样，A不是怀疑B环境坏的吗

B是客户端环境，那A环境不对还敢close? 怎解决？找B解决啊

他敢怀疑B环境坏的，难道敢还疑客户C环境坏的，不会吧

这需求不会是一方的问题 所以不是纯A问题至于更详细情况只有楼主知道 目前来看B很有问题

今天如果真的是B环境问题，A怎没花个半天一天去帮忙处理好吗？

环境不是坏 是不同

A不去串资源解问题，而且还敢close骗人这才是大问题吧XDB单纯是蠢在自爆。

这不是A的义务 就如同上面有人所说 彼此关系不好

也是，A只要说B无法说服A和其他人就可以打回了

我觉得B只是太直白啦 不过他大概也在想一堆杂鱼同事没兴趣跟你们演戏了

A尽力找原因 没找到无法复现close本来就不是过错

function被打出bug然后不是owner责任... 天哪。

环境不是坏的没人知道，但是有可能B把自己环境搞砸

A有尽力吗？找自己主管、找对方主管去谈这件事严重性？

所以function owner反过来要求整合者举证环境是好的

A找不到不就是要换B找原因 现在来看B没找

A当然也会有责任 但不是只有A有责任所以最后处置没错

客户打出问题，卖家尽力解不掉，客户也有责任要自己解决？

两边都不认是自己的bug，那就是要找有能力乔资源的来解决，A敢关B还能怎样

我觉得你应该是不清楚所谓function owne跟整合者的分工型态。

feature owner是B, A是该function owner，所以最后A+B都要

这是公司内问题干客户什么事 不要乱比好吗

要整合者扛底下所有funtion的责任这太幽默。

扛的原因是这样，而我是负责一狗票feature的leader

A解决不了可以pending 啊，摆在那急的是B又不是你

那好，A证明function没问题，B证明环境没问题

B当然不负责A的code 这是废话 A找不到原因环境有坑也

B与其说是整合，更像他实作feature时需要用到A的function

A就把issue关了，B解读成已解，这根本没问题。

不能全怪A 最后处置A与B考绩炸裂没问题

B是蠢在他明知道A没解只是假关，还真的弄上去爆客户。A的问题很大，解不出来也不找人求救串资源，甚至直接关。

那不是已解的意思 B知道有问题看issue没更怎么会解读成已解 ?

issue close不是已解的意思？

corner case处置啊，只要未来没有客户撞到就不会再开了

其实最终责任本来应该是我要扛，B的出现就跟救世主一样 XD

你怎么知道A没找人？ 楼主没讲 就算A没找B也不该如此

例外处理也是一种解法啊。

你啥都没做，既没解root cause也没证明是false alarm，就

举个例子B是camera feature owner, A是AI function owner

你不看close原因只看close状态来解读当然会觉得是A的

camera feature owner一定会被问：难道你feature没测过？

close要啥原因？那又未必是B的责任。找出close的原因是A的责任好吗= =

不过因为A是我的人，我这样说一定会被人家说‘护短’

A就标注close了 不然想要B怎样?

说close就相信close 草率至极

底下function一多，最好是有可能把每个onwer抓来盘问一番你的pass、close是真是假。

这需求是两个人配合的 A找不到问题换B找是对的 什么

两边的clos本不一样呗，一边是解issue的另一边是corner的

close不能相信 那自动化系统可以废掉了 pass假的

你说B找那是小公司才允许这样干，高度分工只会要A串资源

可能要串B帮忙解我认同啊，但close三小啊XD

你程式码弄的好那可以差不多close是解决 但不是所有

私下讲好或者A哄一哄B也许就搓好汤圆了

那只是代表你公司自动化系统只是填好玩的？

要能自东化首先你数据就要是对的

数据要对，那也是能自动化对答案啊，又不是肉眼对数据

自动化通常也只是测试 上线不确认崩很正常

是要确认啥？把每个owner抓来review一次所有验证？包含你pass/close有没有手残按错？review一次不够吧？至少三次比较安全，怕前两次不严谨。那你家自动化系统可以废了XD

说个笑话 人眼一一校对自动化 double check

当然要肉眼自动化就没意义 但上线都自动化太托大了

我觉得就算你要回一个error code 0当成close，也不能奢望

你现在不就要B人肉自动化？谁知道他手上多少工作，又发多

少BUG出去等别人解通，然后要串自己的feature？

你都开issue了当然是确认该issue没问题 手动测要花多

我的作法是只有一个error code 0才是真正的close，你用非0

B的确测不过 但是A直接close QA也测过了，一般情况还真的是B环境问题机率比较大，B如果认为自己环境没错，有找人没人理他，我是觉得他已经把他分内事情做好了啦

对啊，我就说小公司可以那样搞

部检讨一遍，上次检讨pass这次也未必pass... 这才叫诡辩XD

原因是无法复现 我上面已经讲了 你只看close状态当然

你不信任close那干脆就废掉issue tracking系统啊XD

觉得是A的问题 这样判断也很草率

各位是逻辑有问题吗 A和QA说没问题 客户炸了

我想法同MT6797 觉得B有问题的就是标准解决问题的方法就是解决发现问题的人他就错在太老实 说错话

B顶多是草率，A那根本是造假，在我待过的公司。

B早就说有问题 然后大家怪B?

issue随时会reopen 只看status不是好标准

不信任issue tracking系统那干脆废掉，而且会毁掉同事间合

所以楼主老板处理方式才会没有火B只是B能拿战功的 说错话变黑人

A没有条件可以发现问题点啊 他也没说问题解决 说的是

可能实际执行好吗。

无法复现 不代表问题真的解决

没解决在close三小

你issue可以reopen啊，那是新开发又有相同的issue

维护了哪来issue让人开开关关的，什么都没变当成默认close

大公司issue都会reopen 开源专案都是如此 repo不会那

你现在的论点就是听到pass不等于真的pass，全部要仔细检查

么整齐

，实际面上几乎不可能这样搞。

reopen是解了 新的code又出现老bug不是他妈的没解close掉被发现了再reopen

不是一厢情愿，是合作效率，以及彼此的信任。

Reopen条件是啥 owner自己都签名close了

好奇哪家大公司维护旧code会reopen issue的

有什么开源专案会reopen的，丢出来瞧瞧

造就pass就是送owner pdca pip 关B什么事

你所说的效率不存在 所以才会有屎山

提大公司更好笑了 大公司直接CICD谁跟你人工测

最好是不存在，不完美不等于没有效果好吗= =一个一个ip、function都验完整，owner画押，一路叠床架屋

有人没看过开源专案是不是 未能复现本来就是很平常的

往上开feature、scenario、system。

我之前待的 随便一个merge要跑80个环境pass每个环境破1000个test

都是建立在信任底下的owner给出来的pass report。

你人眼扫给我看

不会有行云流水的状态出现 有的话请举例哪间公司

简单来说B发现一个问题，开发者A说没有这回事并关掉issue。没有未解bug就release给客户用，想不到后来真的炸开，B有提出了他之前有反应但被close。最后就是B被人在网络上偷臭，真的是科技业鬼故事。

会有，有些改动幅度小的案子真的就很顺。

那是瀑布开发吧，越大的组织分工越细，随便都可能堵塞小公司才有那种横冲直撞任我行，出包也可以转个弯绕过去

底下牵涉到的ip、function几百上千，绝对不可能一个一个抓来盘问你的pass是不是造假还什么。

你最后手动一次这不是很过份 不然要QA 做什么 本文或

若有人造假也真的被打出问题，造假那位通常死很惨。

许Qa 用自动化说过 但看不见的Qa 也不会看见

手动是善意不是义务啊

既然你提到QA，QA也没验出来啊，这怪B就更奇怪了。

人眼再扫一遍也没用啊 当初A就签名closeQA没打到 谁可以通灵reopen bug?

不然以后大家便宜行事，看到pass还需要人眼反复监测没问题

你说的改小的之前history也不会如此自动化与本文是两件事 他们扯到自动化 回应而已

讲个最简单的 照你逻辑 那QA测不出来要你QA干嘛

找不到原因是close 等到找到就reopen了

你的肉眼全盘点不现实啊，你要哪家CEO去检查底下每位员工

那换个说法，有一个scenario是从来没测过的，你希望人眼

反正台厂水准就这样 直接解决发现问题的人M大应该是MTK的 处理方式已经很标准了 少数有完整制度的公司了

所以我就问 QA测不出来要这个职位干嘛?

我好像知道观点差异关键了，superpandal家的close不是其他家的close意思...

这事件所有人都不是万能 但B没有想要找详细原因 以楼

解不出来我接触过的公司通常是suspend甚至亮红灯通知主管

主透露的讯息B问题很大 没偷臭

其实我觉得这件事主管或公司制度有问题啦 一个bug a不认b不认 就算要这样close也要有人去处理好b的环境吧不然他接下来要怎开发

无法复现close issue很正常的事要看close原因 要说多少次...

真心要互相体谅，在superpandal公司corner是close是自然的

我不认同很正常，可能我见识浅薄。你无法复现不等于别人无法复现，你应该先搞清楚差异在哪，

并不是我认为close绝对不是真的close

那是owner的责任。因为自己无法复现就close甚至认为没有，

评论别人的时候要留意是否是戴上有色眼镜而造成偏颇

所以无法复现close又要怪B了？

客户那边不就复现问题了(笑

你家的系统允许未解issue按close，我家无法QQ

复现不了在客户爆 责任归属如我之前留的QA>A

A 与 Qa都没发现问题 当然找B 不然呢 deadline以经到了

deadline到了，A跟QA都说PASS，还要质疑什么XD

最后问题点也确实与B脱不了关系

是是，最好是准备个测谎仪将B所有隐瞒讯息催供出来

A没说PASS，B硬上的话那我认同就是B的问题。

要不然就甜蜜蜜好感情一起搓汤圆

B早就说有问了 测谎仪是要测什么XDDDD

B有够惨 整合code其他人有问题的都要他负责

那个问题点A和Qa不会知道的

Owner签名没问题的也要他负责

B隐藏关键讯息啊

这件事全都有问题 但B的特严重

A是kernel层以下的 B上层好吗你API给我我call了有问题还要帮你debug?

我的经验是造假的A最严重，B有道德瑕疵，不过每间公司对于造假的认定不太一样，我觉得这是讨论的分歧点啦。

环境是开发者视线盲区 又不是全端

一个app去system call OS系统的function出包，就这样子啊

如果纯脆是A的问题可以不用管 但不是

你怎么知道不是？

楼主都说A+QA主责了 B说错话直接被拉下水

先厘清环境问题，这也是A本身责任啊。

对阿B不是全端只是上层 下层A功能确实有问题干B屁事

不是说明明与自己有关还推 A与QA都说没问题都不细思

谁知道客户端环境，可能C1 C2 C3千百种的

一下 如果只是A一个人说没问题那有待商确

从结果来看确实是A的环境有问题，他却没想办法解决跟B环境差异，然后造假PASS。

你这就是把环境推A身上 测试环境如何不会是A确定的

讲这么多屁话现实就是客户炸了 B上层早就说了

修正一下，A应该是有想，只是没想出有用办法。

因为function owner是A阿，他就该知道在不同环境下的可能影响，B也可能是false alarm好吗= =

不要脑补好吗 依据楼主讲的为准 除非有新的证据或当事人加入战局

你去看一下原文 一个kernel以上 一个kernel以下不知道在哪的话 含作者标题第10, 11行

A是RD 不是OP

不懂什么是kernel以上和kernel以下差别的话去念计概

要嘛function正常，B乱搞，实际false alarm：要嘛function

环境不会是他布的

有人很懂 两个都是开发 不然呢如果环境单纯那你说的合理 A会最清楚 没有人神通广大到视野盲区都了如指掌

没要A神通广大阿，但他应该想办法解决，因为他是owner。

环境单纯? 你假设全世界用户跟你用同一颗cpu?

bug就在那，你能力不够就举手求救，要串资源就找主管帮忙

我跟的liver正在毕业直播，无法理解的无法理解，浪费时间

如我以前所说 未知是造成灾难的来源

未知三小 B就他妈跟你说有问题了

B是统整的人才有义务做这件事B说有问题 两方测出没问题不应该再反查吗

B说有问题，可是A说没问题...又绕回来了，你要B负责整还要帮验底下所有function XD

就说了B是kernel以下 A是kernel以下

这就不是正常的分工模式。

是反查与B有关的 A有关是A付责

整合的人要帮验底下所有function，甚至要比owner还懂，怎

一个caller一个callee很难理解?

不干脆逼他自杀。

A更底层没错 但不是环境 废话

上层发现你function有问题 还要帮你解是什么笑话?

贵家的function owner感觉很爽，求内推。

重点A也不会知道盲区外的 B如果环境与客户同 又是统整的人 分享一下讯息不用debug

A要去厘清function在盲区的状况啊，不是只确认非盲区安全就是pass，因为bug就己经打出来了。

最后结果是环境因素 A要通灵？

不找问题close三小? 有问题是要找到不是算了耶

A测无结果你怎么会觉得是一样

s是不是没有跟别人合作debug经验 看发言 傻眼…

A有找 QA 有验 但B没讲讯息是真

B就highligh了阿你是想怎样

B又不是这funtion的onwer，哪知道什么要给什么不用，要怎么让B帮你就是A的责任啊，看是要找主管还是怎样。

废话当然有 不然我怎么debug... 这笔帐不能纯算A没错

highlight就不是反找问题点 这件事大家都有问题 但b的严重很多 A要管什么环境...

欸不是，function owner是A欸，你怪B没找问题点...

真的有环境他就自己测了

A的问题很大，他没去厘清盲区因素就认定是B的问题。

A跟B问题都很大 这有什么好争的

通常这种分工，B会对接一堆function owner，你不想办法串

那B身为统整的人环境又与客户同你发现问题不考虑环境

? 你不是应该把测试环境列出？测试列出环境很平常不过的事

呃，不是应该A去看环境因素吗@@

你家的A真爽 饭要帮忙送到嘴巴门口

看来你们的环境与我的很不同 A如果就是环境 那A解bug根本不用吹灰之力 讲的环境肯定是不同的环境

那你家制度很有问题 发现问题的人要处理问题 而不是发给正确的人

一个是owner一个是user，user确实有可能乱搞弄错，但user

都不要抓bug就好啦 发现问题就处理发现问题的人

还分B与客户同 A与Qa同做什么

user反馈bug 如果无法复现都是close

user要负责解，这个owner真的爽缺欸。user都反馈了哪里无法复现？是owner不去厘清复现问题啊。

user 提供讯息不完整 多数owner也不会去解的

那是owner要想办法串user进来帮忙，而不是造假pass。

B就多话把自己有推进自己挖的坑

在哪debug都是这样

讯息不完整还要主动询问 A又不是统整的人

你又知道没提供完整 A自己都签名close了

两方测都没有不是应该想想哪些漏掉的讯息 这很搞人

本来就要主动询问啊，因为类似情况也有可能是B错误操作。那A得厘清这是false alarm，并告诉B正确用法。

A和B的主管问题比较大吧 都没问他们进度

s的做法就标准台厂陋习M大提供大公司的做法 还诡辩

A是主要负责人？ 说瞎话吧 A是负责一半专案不假 但不是负责人

负责人就楼主啊 都没看内文喔

你说哪里辩？ 说正统很好笑 A就只是个开发跑去沟通B

我说的负责人是function ownwer意思。A就只是个开发，所以就该确保开发品质。

才是台厂陋习 负责人某M说的你可以喷他

当然跑去沟通B啊，推不动的话再往上找大人帮忙推。

B能打出BUG，A打不出，负责人是A，A还不去厘清差异在哪？不用挑语病，我的意思就是那个funciton的负责人。

制度不明确才整天跨部沟通

看下来A不只是owner，还有某种上位管理职，不是单纯领薪水

这就是制度 你的制度是什么？

function疑似有bug，owner就该负责处理，user/test不配合

做开发的，难怪呈现的态度很像是比统整更上一级的感觉

或推不动什么的那都是owner要想办法解决的，解决办法很多，但绝不是造假pass。

我没有不信制度 close与否决定是否真的close楼主都没

制度明确是分工模式，并不是不跨部就代表制度明确= =

function出事就是该owner进场处理当主要负责人，而不是要user这种不是owner的人背锅。最后发现是false alarm，user搞笑，那也是种厘清解题。

真的"明确"不会随意让人跨部沟通

跟那无关，跨部与否只是不同公司分工体系。

A要主动沟通不是份内的 真的很明确

嘴炮的那么厉害应该是总经理等级的

分工体系就是种制度 不用再凹

那只是不同公司文化，没在坳啊= =你这就跟几个人配一个主管，是否代表制度明确一样，根本无关好吗... 只是反映公司文化。

有色眼镜

分公体系什么时侯不是制度内的？

两种公司我都待过，有些一个小部门内每人工作完全不同，上

下游都在部门内；也有些一个小部门内每人工作非常类似，同时滚好几个案子，但上下游合作得串隔壁部门。这是不同风格体系，并不是谁明确谁不明确。

就是有些制度很明确 有些不明确 这样说有问题吗？

哪个明确，哪个不明确？明明只是文化和风格不同，怎么可以坳成明确不明确。

你都不讲到底是找上级还是直接跨部？就是不明确阿

好，那我告诉你，上面的举例，第一个例子不用跨部沟通的，我的体感是制度不明确，很多流程都很杂乱，想说都在同部门就无所谓，一直不改善。找上级还是直接沟通有差吗？找上级的意义是推力更强啊，当

有制度就是有一定的准则 没有准则是风格也是没制度

然有些人会因此反感，但哪种方法，目的都是串对方进来帮忙

function A写的 但责任不是A扛这个公司赞喔

不管找上级还是直接横向沟通，都是跨部啊。

我们的制度就是没制度或少制度？

我不会知道你前公司哪个 话不合理才是重点

但你故意偏题想扯这些嘻嘻XD

笑死 自己不合理说人家不合理

A有找 找一天也可以说有找然后close一句有找问题就可以放著不管close做事情这种态度也是蛮work-life-balance

扯什么跨部沟通等于制度不明确真的难看了啦。

你是不是不知道问题是要解决而不是放著?

没提供讯息就不能解啊 解不得被要求付责的是A?

应该是A弄不到讯息，那这就是A的责任啊。

谁不提供谁不配合，那都是A要去想办法处理的，自己处理不

你怎么知道他只解一天？ 就算解一天有足够的依据也是

可以 这不是一人专案

你的足够依据=客户炸了 是要笑死谁?如果事情是这样 就足以证明能力不足那就是A废物找不到问题

你说的就是假扁平化的公司会做的 怎么会A负责?

你现在要扯A的主管也要负责这样？这应该是共识吧，有什么好扯XD

这件事的确是B故意用来凸显A能力 所以客户那炸了与B无关？ 再说什么鬼话 只有A 要负责...

B就highlight issue是A close掉

应该没有人说"只有A"吧...

你要看close理由 看不清楚不就也能怪B眼残

你们说的很坚定 A是主要负责人 哪没说？

owner造假pass，出事了user要负责，惨...主要跟只有是一样吗@@我认为主要是他没错啊，解不了bug还造假，这太扯。

owner哪里造假 close加理由不够说明？

加什么理由，你有看到？加说这个close不是真的close？那干嘛不继续open XD

https://i.imgur.com/13sxjYW.png AI都比你懂程式

我说白了，从头到尾根本就不应该close，上层整合的人工作繁忙下没有仔细review是很正常的事情。

你是不是没看文 mark 无法复制 看清楚了吗

不会用ptt的话教你 按/ 打"关掉"

目前无法复现根本就不是造假pass的理由啊，欸不是有给理由

没看清楚文就随便讲 你是想当反方训练辩论技能？XD

就可以合理造假耶。

mark之后关掉了　如果你不知道关掉的中文可以google关掉英文是close不是open/resolve也不是suspend

请依据楼主提供的资料 要扯什么其它的要有证据

第20行 mark成"无法复制"之后，关掉了看不懂中文?

close是楼主讲的啊@@

看不懂 帮你补中一下中国国学"之后"表示后面行动

不用扯了 ㄨ无条件信任那是没有的事情 说的若有其事

但不可能无条件不信任。这样是不可能执行多人分工。

mark后close就是我说的有说明 你是误解什么？

close issue会导致客户遇到bug谁close谁负责很难吗?

很多bug解题基本上都是尊重owner意见，因为owner才是专家，owner说是false alarm，原则上就先配合他要求调整。

AI都比你懂 要不要考虑让AI取代你

owner都说close了，死不信反而奇怪，除非你比他更懂。可以当比user还废的owner就真的过很爽，求贵家内推XD

劣币驱逐良币... 经典范例!

B 通知 A ，如果 A 不解，往上报让上层处理或许比较好？毕竟隔壁部门的人不是自己管的动的

某s应该是总经理 他要罚谁他爽 管他和合不合理 吞不吞的下去

如果你的客户直接从你的repo抓那很屌 内部管理真强而且我不一定是回应你 因为同时有两三个以上讲话 我又用手机 打的慢会断线过久直接close很常见 你这样解释那是你 ㄖ总经理这么大的官绝对不是我 如果是我就弄掉B没办嫉恶如仇 如果文内是真的没办法我

我的经历上造假close很罕见，但这个人际遇不同也没什么好吵，我觉得这是最大分歧点。A这个人我偏向不敢用，我无法信任他以后给出来的东西真假；B这个人我会提防他桶刀我，能不用当然也不用。

好啊 你弄掉B搞到全公司没人敢帮人家抓bug谁抓bug谁就扛责

如果他什么都没讲 那我今天就会改喷A 无法复现一听就

我只能说B是捅一个人，A是破坏整个制度；我隔壁部门有个同

首先要先确认制度 看下来是没制度 自然也没办法破坏

是有制度的，验证正确性和后续追踪。

b捅一个人破坏和平 破坏公司工作氛围公司内统来捅去我不相信做的好 除非重要的在少数人手

这倒不一定，顶多是氛围不好，内部竞争有其优点。

里 剩下的都是可有可无的人 这情况下也跟小丑没两样

A不签名 他能捅？

这不叫竞争 你有两个team做一样事情才是

内部竞争有时就会带来互捅啊。是啊，A不close的话这题正常就是一路烧上去，再不想配合也会被高层压着配合，不太可能直接炸到客户那。

这就是抓小辫子思维 今天没有这个事 ㄧ以后有其它事

很奇怪，到底出了什么问题。B可能没给够资讯，但A竟然就草草结案也不去跟B问问看

要捅人的绝对会守株待兔

老实说啦你不造假谁捅得到你XDB人品道德有瑕疵我绝对认同，至于A我是根本不敢用。

要竞争首先双方路线就要雷同 明明是合作搞成竞争哪能做好事情 本例就是你也是抓小辫子思维

又在讲大道理 果真是总经理

总比造假思维好啊XD

原因就写在那哪来造假 没看清楚就没看清楚

有看清楚啊，又不是有理由就可以合法造假XD

A不是真正元凶

close假在哪 不是finish好吗

有人下来压着A、B或更多人进来处理。

堆上去的才是

你这就在坳pass不是perfect一样...

不推上去自然不会炸

finish与perfect 不同等级好吗

那只是在玩文字游戏。你想讲的不就是写close不代表没bug了，是有人乱解读。但正常issue tracking系统不会让人这样误解。

A即便给你close 你上线总要验功能 不验或验一样还给

写上close通常就是这题已解，已经不是issue。

pass也如同close

close就是close 不是finish 不知道你说的是哪里来的

，然后就是相信A跟QA的验证，这完全是很合理的开发流程。嗯其实我没在issue tracking系统上看过finish。open、suspend、stall、close。

惯例 不能复现A还会推code上去？ 如果复现率不高，

finish或complete比较常在milestone tracking表上。

对啊以前就这样，然后呢？你想坳说以前就这样就不是bug吗XD

请问suspend、stall差别是？

高层可以喊suspend，先转移人力去解比较急的XD

这不就是mulestone XD

不是啊，milestone是project执行时间点。

不是 我是说如果现在复现率不高 以前复现率也不高

milestone和issue tracking不一样呗

一直有看啊你到底为何在意淫别人不看XD

是就是，不是就不是。runtime concurrency bug谁没遇过这种racing conditon没有解就是open著啦

它专案有很多新功能不是吗我是在解释不是你说的意思

如果有很多新功能，那更不能怪B了啊，整合者都忙死了谁晓

当然觉得你没看 ㄕ上下文还可以解释偏颇

这也不是理由 而且B认了不是你说的情况

一直跳针就不用跟他讨论了 牛鬼蛇神呀…傻眼

你说复现率 我回应了 ㄋ你对回应解释偏颇

不是啊我解释得很清楚，没有偏颇。偏颇不是先喊先赢欸XD从整个制度体系看，没有close，就不太可能量产给客户，更不会炸到客户。你先搞清楚根因在哪。

没有凹说以前的不是bug

还是贵司产品有bug也不解就直接出货？这个我也好羡慕QQ

MT用大企业思维的有色眼镜看待小公司惯例做法，有欠公允

我有解释了 ㄋ你解释这样是偏颇

你issue全清，我issue全清，我们都一样呗。辟啦。

我是说如果上线时测试复现率低 那A都没改 复现率一样不是你指的要凹以前没bug

重点是s都不用思考一下人家说的 自己讲自己的

你可以跟M说这句 我都有看 ㄉ但我无法用手机一次回应多人

我一直都有看啊，所以有些我也懒得回，际遇不同，我们没体验过彼此公司的文化，很难理解对方制度体系的认定差异。某程度上我满羡慕你说真的QQ只要出bug，owner自清是基本责任，再一路叠床架屋往上开发复杂feature、system。我也好希望我出bug时是上层的人要帮我解掉，我不用负责。

你可以不用再讲废话 看了都重复 还延伸一堆无关的所以我针对你随意解释那句说偏颇是真 你还反问哪里偏颇 没看就没看

虾，我有看啊，我那句是疑问你怎么解读。重复没办法啊，就我觉得满基本的道理你无法体会。

他根本没理解你说的 自己讲自己的

无问号有“吗”字 但你这就是任意解读 还放XD 有成见不用装

改扯成见了吗XD

我的回答就是复现率一样 你以前怎么测现在就怎么测

然后呢？这样就可以close吗？我觉得不行，你觉得可以，就认知差异啊XD

你们公司客户能接受你的说词是一回事，别家公司客户可不啊

那你说说不是成见 你那句有多少疑问成份在 不用装了

很大疑问啊，因为我觉得我们工作文化差很多。

真的是鬼故事

复现率是从B再测试延伸 不是当初close

原则上客户没有复现机率的概念，遇到就是一，没遇到就是零想多学学

所以又回到B的责任了，唉A的BUG，A说close，B的责任。

如何说服客户接受非零复现率的close issue

打开feature在close之后复现率不是0

今天没有B，送到客户一样会死，根因一直都是A的BUG...

你先听他说，feature只要不打开的复现率总是零

今天没有B A会更接近客户

但打开feature了

今天B没有放入feature，A跟客户会相近，没有BUG发生

又在乱辩了

feature是B之前就有了，之前复现率非零已知复现率非零，所以feature默认关闭，轮到B才打开可是只要feature存在，就会有可能造成BUG

会送feature关闭的load给客户吗@@？

复现率非0 关掉就没feature 是0

其实从制度上，A不要乱close，我的经验这题就会烧到上层，

所以关闭feature，issue可以close掉。叹为观之。

B更接近客户无庸自疑

人下来解这题，什么B不配合就都是假议题。

开发、客户、主管都同意关闭feature是吗？

还是是要求B workaround出一个既关闭feature又能运作的app只要A之外的人能有零复现率的workaround，是不是就解决了

A与QA都没发现问题 所以题目当然回到B B不续证那B脱不了关系 一来一回没下文说A是主谋 过了

复现率非零不就是问题吗？为何feature非打开不可

这东西哪有什么主谋不主谋啊，整天意淫欸XD

说B打开feature所以B有责任，关闭feature整合不了是谁责任

探究责任归属，不等于捅bug的人蓄意谋害好吗= =你搞错了，A有发现问题，但没能力解，这才是关键。

所以他一直想处理掉发现bug的人啊 逻辑一直绕

他知道有BUG，但自己无力解决，连复现都做不到，却选择造假close。

你们在说A主谋的 要翻上去看吗 什么A要负责都有说

主谋跟负责是同件事吗... 你当真？

让事情爆发不是A 是B 他自己也承认

我还是认为A责任比较重啊，他毁了整个制度系统的可信性。

那B是你口中的主谋，把B处理掉之后feature要怎么处置？

feature关闭，还是feature开启，二选一

除非你很肯定不开这个feature，但会卖不开feature的版本吗其实出BUG、炸到客户，我真的觉得还好。会让我怕的是造假文化，彼此之间合作失去信任。现在大型案子都要大量人力合

不是主谋负责什么？ 这件事B严重多了

作开发，不可能层层之间都全部review检查，需要靠qualitycheck画押后一路往下开发。A是最严重的，这种造假文化会完全破坏大型案子分工模式。

这件事B是主谋没错 犯最大错

A犯最大错，BUG在他身上却不解。

确实

另外A、B我都不会用主谋这个词。

不用扯造假 不仔细看 而且B承认了 得证

你要扛成败，但是这些事你都状况外，难道你都没问题?

问题就是造假啊为何不敢面对@@你不造假，B能上什么？

不用美化用词 你们说的就是主谋

A不造假，BUG烧到高层，B怎么可能硬上去炸客户？你要玩文字游戏我也不阻止，只是很low...

不会是A扛 B是整合的人

今天若A没造假，B无视issue open硬上去炸客户，那绝对B错整合的人又不是function owner...是function owner画押说没问题的耶，user只是照用啊。

你只是因为close一词认定造假 高层傻那高层也Gg 楼主也gg了

炸开前楼主好像不知道这件事？然后楼主的确也被连带责任了不是吗？底下的人没盯好。

整天拿你以前公司惯例不能说明什么

那你又能说明什么吗@@

重点就B有测到 A做不到还关掉很瞎吧

我遇到的都是你close 我不相信你

原po不出来说该公司制度到底怎样允许bug close的话 也无

那同样的，整天拿你以前公司惯例能说明什么？

不相信close那这套系统有啥用…各自表述更乱啊

那用我的经验惯例说明不就说明A是主要责任人。你的公司就是圣经，别人公司就是没制度，好大的官威啊XD

逻辑死亡就开始玩文字游戏

sir 的确说的没错 我目前 B主谋论是建立在看的到的证据你也是从文字判断 文字游戏？

B哪有没验过 验过发issue给A被close啦你的论点就是解决问题就是解决发现问题的人台厂陋习

个人觉得原po故事并不完整 例如都没有B主管的说法 还是当成故事听听就好囉

文字游戏不是指从文字判断。

A和QA都验过 找不到 B对mark和close没回应

所以楼主的老板是清楚的没有火B 这篇文就是想臭B白目而已

A对BUG还存在也没反应啊XD

从找的到证据开始 弄一些不算证据的脑补是错的

是B相信owner的画押比较扯，还是A造假画押比较扯？我职涯经验是后者比较严重，前者大概偏向不够仔细之类。

A也没被火 ㄋ你又不是老板肚里的蛔虫

我这边没验过是指bug close之后 要commit feature之前再验一次 我若是B的话在这情况下发现原本问题还在 要嘛reo

所以B不讲话 就没证据囉？责任变谁的？

B没有相信 他自己都承认

那我修正成，B接受owner的画押。

好了喔多隆

我与sir同 上线前总是要验

相不相信无所谓啦，我常常也不相信人，但你敢画押你就要扛

B是什么低能儿，不提供环境协助还搞破坏

系统内部管理用 说画押就重了

哈哈都你在讲

所以我很上面就提了，把这种事情视同儿戏，是主要观点分歧

B不讲我会认定A/B两个人八字不合

，在大型案子开发上，很多时候仰赖追踪系统来确认进度，没

issue开开关关本来就正常 都我说？ 我不是随口我说说

空成百上千issue每个都要检查好几轮，这不现实。追踪系统的有效性又很依赖员工的诚信。开开关关...其实不太正常。

我都用了追只踪系统了 ㄏ还不是开开关关 划押？...

一直冒出新的很正常，同个issue开开关关很恐怖。

那你应该改善架构 人不可尽信

前几次的关到底是造假、运气还是纯粹太废没找到root cause不可尽信不等于完全不可信。

本文也才一次close...

你讲的那些要层层review现实上大型案子是不可能的。这就是问题，你不严肃看待issue开关，觉得close没意义，但我不同，开开关关对我来说很恐怖，所以看到关掉应该是owner确定已解。

没有要层层review 测试看结果不是基本的吗

是基本的啊，owner请确定结果正确。

本文也没有层层review 架构好不怎么需要review

上层开发者不可能帮底下owner完全测过一轮，不可能。你之前说不可信啊，要层层review XD没有要层层review，那你怎么能怪上层开者没检查到。

不可尽信是针对issue 测试就会有些结果，

这倒不一定，有时owner说pass也给出报告，上层不一定会从头测一轮。

我没怪上层开发者没检查到 而是检查到没提供详细讯息

你确定他知道哪些是详细讯息？这应该是owner要去弄到，但没弄到啊，谁的问题？你要B的环境，你推不动，不会找你主管或他主管？

提供B所能知到的 不用管A写的如何 ㄓ

这你想太多了，user哪可能比owner懂，而且user要对接的窗

口这么多，不见得有空专门服务一个。A不去要当然就没有啊。

楼主都讲了除非还有其它证据

认同M说的各自owner需要确保自己的test coverage 但整合测试也是必须的 回到本例B的情况是他在整合阶段就已经发现问题了 他的测试不可能不包run到kernel那段function这边就该是个release blocker了 除非他主管也认同这样可以出…XD"

已经A与Qa测不到 那B是该反查 想想哪些自己负责的有

A测不到就是最大问题，这owner太废了吧

owner竟然不知道怎么查，要user帮你解...

B知那就是搞人

B是user，不清楚function细节并不会太夸张，我整过约百个

只提供讯息 不是B负责不用解

当验出bug时，是function owner要推我给出复现环境，不可能是我抓着他们= =

现在又变说B不用解了

owner要确认自己quality，到底是上层误用还是真有问题，而不是要上层帮你解，饭送到口边。要怎么推动上层协助你debug，那是owner的事，我管你用什么方法，推不动解不出来这绝对不是借口。

不提供丢一句没过很不负责 ㄅ本文owner已经确认过

他没确认，文中看来他没有弄到B的环境，弄不到就是他能力问题，连基本的举手找主管都不会。

我什么时侯说B要去解A的东西....你是没看吧自己的东西确认可以 提供一些资讯不就好了

对方多机掰、多不配合那些都不是理由，是owner就要想办法解决。

没错 A能力明显不足 但B故意戳真的没半点好处 要嘛跑要嘛帮他成长 不然就是看自己考绩被拖累…

谁知道要提供什么，user又不是owner的蛔虫。

这专案不是一人的 所以你说的oWner应该是两个人 各自东西 B.有测过大哥 提供测过的就好

我也觉得很简单啊，但结果来看A就是弄不到，很神奇。

可能本来就八字不合 不想去要 我理解

那这不就是A的问题了吗，谁叫他挂function owner。

八字不合不是理由呀XD 在商言商

挂owner，仅因为不想，就不去找解bug的方法，呵呵。

而且通常user都会给资料

给的资料不够，无法复现，就继续要啊。

当然公司内不能这样 ㄉ但这只是个假设

你要user第一次就给到完美版，干脆叫他自己解算了。公司内不能这样，但这篇文就是公司内啊= =A遇上bug没有身为owner的自觉，推不动B根本不是理由，最糟

我是说公司内不能不合就不做事 只是可能 ㄨ无法代表A

的是issue close，这可能让用系统制度卡release的机会都没了，直接让BUG一路打穿出去。我说了不想管到底什么原因、用什么方法，从结果看A没解出

B都是owner 不是A是owner

来还close，这就是核心问题。B机掰不好合作那些都是借口，

不是只有A

哇厉害了 A的bug issue变b own

核心没提供讯息然后明知有问题让它爆

那当初close issue是不是要b一起签

owner没去要讯息。

B做事能力就足了吗 最后还不是环境不同

那不重要，B不足不等于A足。

b就承认了 请搞清楚状况

func A own, feature B own 上游有问题终端出货前该卡不

A就是需要去搞清楚环境差异和怎么解BUG，因为他是owner。

回答我前面的问题啊B没说话 责任变谁的

这不冲突 但如何我们旁观者不知道你现在假设晚了 不会有这状况解bug要先有资讯

梨厉害了总经理 真的都是你说了算

不是我说的算 我看证据

其实解bug第一点是看心态，想逃避的人就不会去要资讯。A的问题是在这，他没有自觉，可能只等著饭送到嘴边。

你以为我傻傻不去分析 随口乱讲话吗

有一次别人的BUG好像会牵扯到我，还没打出来我就去找上层要环境和实验，这是基本的自觉。

你自己前面说如果　B不讲话就会怪A现在又变来变去

然后呢 B也不主动阿 除了在追踪系统发issue 然后A 在

互相矛盾嘛

自觉也决定了一部分个人能力 A现在就是不足 然后主管也没有察觉放任他摆烂 我是觉得B真的不幸遇到啦 但应对方法真的太糟

追踪系统close issue

B不是function owner，这还真的难怪他不够积极。B我一开始就讲主要是人品道德，合作应该会很痛苦。

我更倾向于未知被A碰到被抓小辫子

这个就是没证据的意淫了。

抓啥小辫子 发issue给A处理完close了

B这种工作要对接的窗口可能有十几人到几十人，无暇去狂追其中一位并不是多不合理。A身为owner要靠别人追才愿意解负责的function bug，缺乏自觉。

close就是是小辫子 没看就没看硬插嘴

自己签名ok叫小辫子喔 哪家公司的系统完全没有信用欸

这就是B可以搞讯息差的原因 讯息差不是能力可以弥补的

这种会破坏资料的重大bug，不该是一句无法重现就跳掉吧

原来追踪系统close就是签名 XD

造假不是小辫子而已... 唉，你把这种事严重性当儿戏。

什么叫造假 都写原因了造假？ ㄕ

有能力搞讯息差的是A，因为他是function owner，B不可能比A懂function，如果比A还懂那A可以滚了。

通篇看下来 真正的鬼故事在推文 笑死

这就是你当儿戏的点，并非有写理由就可以造假。

最后出事在环境 这A不会知道的 这就是B可以搞的讯息

有没听过解不了的bug就当spec？凭什么当spec？owner说了算

B如果不是故意的话，他的部份不算有错

A怎么不会知道？BUG都发出来了，弄不到B环境那是A废。而且A不只该验B环境，应该重新思考是否原本验法有盲点。

你们就自慰算了 笑死 B不知道吗 B知道 无讯息差

甚至客户环境未必等于B环境，只搞定B环境未必全解，但A只专注在没有BUG的环境继续验，这根本没意义啊。看来是语无伦次到崩溃惹QQ

以楼主说的结果来看A不知道 不然楼主怎么会评语环境

A不去解当然不知道啊。

因素 你比楼主还懂楼主？ 还是你B？

owner关issue/QA pass B当自己眼睛业障重情理之中吧

BUG解不出来，不知道是理由吗？

争执的点是issue close造假? s说A是"照实"写他做不出来M说issue只有解了掉或证明不存在才能close 我这样理解对

自己逻辑打结的人 还说人家自慰

A很有问题啊，敢issue close 就要负责，被火了活该

我对issue的认知是你讲得这样没错。

连A不去解都可以脑补起来 厉害 A知道问题点都炸了

结果论是A没去解啊，不然怎会炸到客户？

无法复制确实是理由吧 毕竟选项都放在那边了

环境要不到这种借口想骗谁啊，就是自己能力问题啊。B机掰，你不会比他更机掰？直接highlight所有主管说都是他

你倒是讲哪里逻辑打结？ 脑补幻想假设就不要拿出来讲

字面上来说都没错啦 但我会想把重点放在面对这样的情况两人做了什么(A摆烂不追环境问题 B接受A摆烂直接硬上)

卡你测试环境啊，拜托，都不是小孩了，要想办法解决问题。

了好吗 一直脑补我有讲过的话 手机打字无法一一回应

我问你一堆答不出来 还反问我怎没问你勒 装没看到喔

issue继续开着，甚至直接提到release blocker，最好是不会

我一个人手机回三四人 而且你那么会脑补自己讲过的干

饭没送到我口边我不吃，user要帮owner解，这真的太幽默。

话为什么不自己脑补？

Issue一直开着 主管就会压两边来解啦自己签名close 还要把责任推到发现问题的人 这样对吗

押人那是出事以后了 B透露讯息 A被押著

不是，他是讲正确处理方法。你issue挂在那迟早会烧到上面，高层会押人来帮忙解，自做

A mark的是无法复现 这你都可以解释成推责任

什么叫出事以后…懒得吐槽了 睡觉去

主张没清bug还close，要扛责是很正常的。至少在很多公司是这样认定。

A的责任在 面对B这样不愿提供环境资讯者 没有想办法拉高层级来解B的责任在 面对A这样摆烂直接把问题拉高层级到客户

无法复现跟close根本两回事，我知道你不在意诚信。

我在回应你不是回应他 懂？

但很多公司做事不是这样...

ㄨ我不在意诚信？ 你们两个脑补真的很多 我只是不觉得close这种事可以无限上纲

没有无限上纲啊，我认为这是很严重的问题，他要扛责任。喔因为我记得上面讨论你说反正再开开关关就好没差，我觉得简直儿戏，完全无视这类系统的有效性。

话都你在讲 那你说说看close的意思啊 脸书按赞吗？

如果close不等于close，那open是不是也不等于open？上面的issue还有看得必要吗？反正都在乱写啊。

关闭issue 不是完成

关闭问题一般会解读成已解或已排除...唉，又绕回来了啦，一直鬼打墙。

你觉得楼主比较怨A还是怨B? 开开关关不是要频繁开关

楼主怨谁那是他的事情，我没兴趣。

同个issue好吗

你的工作环境不重视issue tracking，也不认为这画押的严重

那你脑补那么多做什么 看证据B事情比较大条

这边我倒不觉得not reproducible 不能是issue close的理

我没脑补啊，我根本没说过楼主怨谁欸= =

由 因为如果issue真的不存在或是已经因为其他人进的code刚好解掉都是有可能发生的. 有问题的地方在A去要环境资料而不得 这时不该直接以不能重现关掉

你讲的这个厘清也是已解啊。

那你告诉我这有法律依据吗 可以改来改去的你拿来当准

确认不会再现，false alarm都是解决的可能。

则

那就对了 那你以划押比喻做什么？ 就内部管理用会改的东西而已

就一个比喻说法而已啊。要用法律依据去否定一些文化，我是觉得挺可悲啦。摆烂装死其实都没有无反法律依据，唉... 但我很不赞同。

引喻失义 当然你都可以觉得这小问题

不，我觉得那些是大问题，是你觉得是小问题。

我是指你讲“就一个比喻说法”

哦那现在要偏题到说文解字了吗XD嗯我承认用词不当，不过大家懂意思就好。

引喻失义你不觉得很严重？ 我只是表达这意思 没有要

我不觉得有失义，就是法律面的用词没那么严谨而已。

你说文解字

"A很诚实的把自己的摆烂呈现在issue的close reason字段

去争论画押这词我觉得很无聊就是。上面有其他人用签名，意思也差不多，谁签谁负责意思啊。

这种东西法庭上当证据都不可以 完全可改的要可信度..

当证据可以啦 改了会有纪录

你确定要继续谈什么上法院认证？

我也只是说画押这词太重

很多东西不是法律可以规定的，你要摆烂什么无法可管。

所以现在改谈用词太重？画押这词本来就有点玩笑性质，怎么可能压身家财产，不过就是一种自觉和道德规劝，部分也带点施压自己的责任感。没有法律效力？废话。但也不是说这是儿戏，随便乱讲不用当

这我前面就讲了 当然要前后呼应 不要言论发散

真，无脑乱画押会让人觉得这种人靠不住、不能用。我是不理解扯什么法律效力干嘛。

有人会觉得跳针只是因为我不想脱离主题太多而已

扯法律真的跳针太大了= =

你都说画押这很重的词 我不能说法律 也不是我先开头

这就只是我职场上的习惯用语，反正交付品质保证的意思。我不觉得你不懂这用词啦，只是想偏题吧。

喔喔 要回来讨论"都不escalate" vs "直接escalate到客户" 哪个比较严重了吗?

明明针对楼主说的提出看法就好 还扩大到一些很奇怪的东西 什么都可以讲 拉回主题又说跳针

扯法律的是你欸= =上面还扯过什么跨部门沟通等于制度不完善，一直乱扯一堆怪东西。

你扯画押我不能扯法律 上面还扯一堆什么追踪status

我讲画押的意思是交付品质保证这件事...

是有人讲要A直接与B讲 ㄅ不是跨部是什么

你说的很严重 法律不严重吗

制度不完善根本扯不上关系，然后上面你抬杠了一堆XD你确定要继续谈法律问题= =？

你看你又来 上面讲一轮又来了 制度本来就函盖方方面

这个我不奉陪，因为真的太鸟蛋了，已经是在说文解字，很像

原po都说因为B自爆(态度问题)他才比较没事. 事后还是有人觉得原po护短. 其实这个故事的鬼是原po的team啊.

讲画押就只是交付品质保证的意思，我解释第三次，没有说是要上法院负责的意思啦，会用这词纯粹待过的公司很常用。完蛋我觉得你会跟我卢保证的法律效力... 干...

你不只画押这词很重 数落A close(画押） 都很重

因为我认为确实很严重。我也讲了，这个我懒得争，你待的环境不重视这种诚信，那是

谁要扯一堆？ 你们不来扯东西我就不用回应那些扯东扯

你的环境，不等于其他环境这样也很好。扯法律真的很好笑啊XD

平常工作很多用词都嘛开开玩笑，意思到就好，不是严格意义，然后你现在跟我扯法律问题XD

环境？什么环境？ 说你扯你还不相信 说法律当然是应

扯法律的话我真的要睡了，那部分我觉得你只是在抬杠。

对的内容 给我观感像法律

你想太多，我没那意思。

证据力不足硬要讲 脑补假设一堆 偏离主题 你的经历又不能套在楼主身上

你证据力就很足？你的经历就能套在楼主身上？

都不觉得这样会有误差

工作上bug没解还说没了本来就很有争议，好啦你又要说close不代表什么，开开关关也很正常。我认为有误差啊，我只能从现有证据去评论。

稍为理性一点吧 我前面都还在范围内你们扯到外太空

扯什么跨部门沟通等于制度不完善，要有法院效力的不是你吗？谁在扯什么外太空啊。

楼主都讲A不知的吗 都讲好几次了 然后一堆人扩大解释

我讲的论点一直是A处理的很有问题，甚至可能破坏制度面，然后画押这词被你抓着要我解释法院效力XD

半夜三点，抬杠停不下来。是爱吧？ 嗯，是爱。

我上班再回好了，真的是...

什么A是主要负责人 A才最严重 都觉得这里是不是有B或与B是同类的人 A处理有问题 但B 出大事

A是function owner啊这你不会不知道吧= =B出大事但我觉得根因在A，只怪替死鬼不太公平。真的是浪费时间扯什么法院效力QQ

谁重谁轻分不清楚... 意思就不是法律说的很严重像法律 废话当然知 他是一半专案的owner 都讲好几次 都当别人不知 爆出的是B 不是AB 真的要反映那反映主管就好 直接毁天灭地就是搞人这种做法是动不动就想教训人的特质

B没什么问题，有问题的是A和QA居然复制不出问题，人家都反映大bug给你，你们还找不到，找不到就要认命一点去找B一起讨论啊，我看A和QA都没亲自去找B详细讨论怎么复制问题吧，拉下脸也要去找B好吗，直接close是？？

复制不出问题要看问题点在哪 两个不同部门的都测不出B也没什么反应 至于拉下脸那很可能是B要的效果

在大家都不知道B是故意的情况下，不会认定B有错

这圆不了 B就算没说白 明明知道却还是让它上 代表就是没续验 免不了还是有责任 我看他是笃定他能留到最后 后面开始飘了 大头症B默认结果不会更好 这样老板会觉得下面联手坑他 这应该是计算过的

B如果没自己自爆责任就是在楼主跟A啊，很难懂吗lol，B要整合，要call A的function结果function有问题，A自己三个礼拜无法复现就直接close我是B我也是龟览趴火，状况就是明明有问题但是问题根源A不屌B，楼主qa重现不出来也不屌B，所以大家就一起下去不然B就变成那个卡大家绩效的机掰人，要不是真的客户端有问题我看B就被贴上一个能力差又难搞的标签，虽然最后还是得被楼主po在网络上嘴砲哈哈，真的是鬼故事至少看起来楼主的前老板还知道这件事的最大负责人是谁直接火了，笑死就算B想要的是A拉下脸去他那边看B的环境慢慢查找，A就得去，最应该积极解决这个问题的是A，直接close就是罪该万死，B只是做人机掰，跟我一样，虽然我是没机掰到敢让问题在客户那边爆炸就是了

都五点了居然还在吵... XD

别忘了是B commit B如果不commit事情不会发生 即便B找个好的理由替自己commit解脱 责任还是跑不掉 依照经验 有做事都不是升迁保证 你的做事是搞爆全部人说老板因为这样留他 A也有留只是后来肯定还有发生事情先走 B到最后也走了 所以你怎么说？

你说B的责任在B commit，但是B会commit是因为A close了啊lol，如果A close但是B 坚持操守不给commit，问题会从function有问题变成B在搞大家欸，B自己这个issue都因为A白白拖三个礼拜了，机掰如我只要function owner没问题，qa没问题，我自己也是commit上去啊，管它的哩

最后结果A/B考绩都是炸

那是因为B自爆啊，不然单论制度上来说B根本安全下庄当着qa的面说我就是想恶心A，那也无法

B除了commit还有其它选择 上面说了 就是搞人用的 B向上反映球就踢回去了

其他选择，如果你是说要拉下脸跨部门沟通，那是A要做的事喔，B唯一应该要做的事就只有回报A function的问题以及后面再配合A，A不来找他就不干他的事

你不讲那么多 总是会被问commut理由 你没发现别人最后最好是不会对你能力起疑

B的向上反应不就是楼主qa吗，看起来是有反应到阿，qa重现不出来是然后qa说没问题，B就不能再巴著这个问题不放了commit理由也很简单啊，qa说没问题就可以commit了不是吗....？

你哪里看的到B的主管是Qa?向上反映不同部门？.......

我没说B的主管是楼主，我是说这个issue应该是楼主负责，b反应给楼主就够了，如果b再反应给自己主管的话，最后如果真的是b自己环境问题，b是不是直接死去，为什么要为了一个卡了3个礼拜被owner close、qa说没问题的issue赌上自己在公司的评价，B又不是圣人

吃饱太闲，晚上8点吵到早上5点

说圣人好像不太对，应该说又不是傻子，不过最后自爆...好像说傻子也不为过XD

楼主怎么会知情...都后知后觉了还知情？

B就只有一个问题，在怎么不爽，知情之下，也不能故意让问题在客户那边炸掉，其他B其实没什么问题

搞错人了lol，我以为楼主是qa，我还是去睡觉好了

反映给B主管也是个好的选择 重点是B知道会爆又想搞人B知情会爆然后commit commit最致命 不commit搞不到人

你如果站在B的角度就会是，A把issue closed然后说无法重现，言下之意就是你自己环境有问题，然后qa也是一样结论，并且这个issue已经卡了三个礼拜，这个情况下你还要反应给主管继续卡，那是真的很惨

commit会被问原因 你找个好的理由都是过失

为什么你会绕回来这个所谓的 commit的理由再好都是过失，楼主都表明了B自己不自爆根本不会有事不是吗

这是双方摆烂 B等三个礼拜也很有问题楼主是这么想 ㄉ但谁知道他老板怎么想基本上我不信B是这么傻的人 明知道这样做自己也gg

双方沟通摆烂我认同，但是责任归属在A身上，没有一方要拉下脸合作的话，A必须去谁知道B有多傻，会自爆又找人代打卡丢工作lol

我觉得是向上反映上面的安排你不摸清楚规率你敢找人代打卡？ 只是最后抓包人生都有意外 我倾向于B是聪明的机掰人 活最久七伤拳使的好

哈哈哈 人的问题/官僚化/大家一起踢皮球囉!

B的问题比较偏向人格跟道德问题，但这种的才可怕

整串就一个人逻辑在异世界 你们居然也能吵这么久==

https://i.imgur.com/13sxjYW.png工程师连这么基本的东西都分不出来可以自尽了正常的任务管理系统close就是解决的意思除此之外就是不正常的公司 异常的人总以为自己正常

楼上你的close有法院认证吗？没有的话某人的公司不认的XD现实就是有那种做错但死不认，一直嘴我没犯法那种皮皮的。

不管上面吵了些什么,拿ChatGPT的回复当正确答案也怪怪的吧

人工智能与工人智慧

以前还遇过只有uat测试环境，每次都只能开发端测试完直上uat，然后就发现因为测试环境不一样有些东西还要微调。要个上uat前的sit环境来测试也没，老板反而叫工程师自己搞个测试环境。

拜托你们是一个Team耶，B那什么全天下都对不起我的脑袋你发现问题后，别人无法重现你不帮，ticket关掉你重开不通知，还选择直接release给客户？想跟所有人同归于烬吗

A也蛮雷的

A写的bug搞了整个团队，也是个奇才

怪A的code也不对，谁写code没有bug，不然要QA干麻？A错就错在没确认B的复制手法也无法复现，就擅自将issue close掉

虽然B太老实很白痴但如果仔细想想真的完全是A跟QA的锅B顶多只能算是使用者使用者回报了然后1.开放者A说没问题2.测试QA说没问题那你要B怎么办…?

大B哥 真牛 没解决直接close

是function owner画押说没问题的耶，user只是照用啊。

A全责+1，issue close不能release其他issue也要比照办理吗？

A能力差 QA能力差加不负责任 B心态差加不负责任加反社会人格

有些需要特殊环境才能复制，甚至是机率性，A做法虽说不对，但是B更不应该，B如果有feature压力，应该跟pm说清楚把issue重新highlight

B是HL哥~

两个都是雷包，内部的恩怨搞到拖公司信誉去赔，客户没求偿？

鬼是你巴

B主要的问题是不愿意提供厘清环境的协助 release出去这件事反而是正常的

B太不懂人心了，这个就说“啊A关ticket，QA也验过，我想说可能我不懂或用环境设错吧”那这锅A跟原po就扛好扛满了。

推楼上，确实是如此

某K讲的就是基本概念 然后呢？ 假设别人不懂别人懂所以？ 容易忽略然后呢？ 假设大家都很规矩根本不可能

产线很多啊

A开始搞的 close问题才比较小 不要扯什么自动化与信任 无法保证的东西 自动化应该在容易自动化的地方MT就在扯嘛 什么法院认证？ 我都解释了那是对你画押的看法 到底谁逻辑不好？ 不要老是脑补别人没做的没说的

画押一词我解释了只是用语习惯，是你一直咬着要有法律效力，否则没意义。我只能说很多事不是只看法律面。

B老实？ 是不是没有看文 故意的老实？我不是解释了你说的很严重像法律 也只是个形容

我是觉得讨论职场的事情，你在那扯法院认证才有效真的很好笑。在我待过的公司造假close的确很严重。喔你又要说有mark造假没关系，鬼打墙啊。

所以你没看懂是吧 我的意思是没那么严重 你自己比喻不准别人比喻 排场真大 然后自动脑补别人没讲的

我也说了啊，你的际遇和环境，不觉得这种事情很严重，这是观点分歧原因。至于我工作环境，这种牵涉到诚信的行为很危险，也看过类

低端公司才会有低端流程 何必浪费时间吵

似案例造假验证pass，炸开后害一两百人被地毯式review，增加一堆工作量。

所以重点就是我没有要扯什么法院认证 看懂了吗 还整天拿这个说嘴 只是个比喻你怎么知道他真的造假？ 专案很多也很容易误点这种开发者可以自行修改的本来就很没保证 拿来自动化非追踪的更是可笑 你说你自动化追踪issue那可以 布

这B大概跟A有仇，而且可能也没想继续干了

署就多了 自动化另外一个人说的

那为何提highlight A替自己的这种行为合理化？

B很蠢，把有问题的程式release给客户。要highlight 有那么多方法，结果选一个最烂的

B大概跟A有仇

B很聪明 只是纯highlight 确实不需需要这么大费周章但他想搞人

B连环境厘清都不愿意提供又加上将很严重的bug 直接release 不管怎么看都超有问题吧A就真的复制不出来才觉得环境设定有问题结果连这资讯也不鸟A

如果今天B很负责很能沟通地把bug解了，公司会特别表扬他吗？

我不同，开开关关对我来说很恐怖，所以看到关掉应该是owner确定已解。

也许不会 但能减低自己被他人摆烂造成的专案失败而拖累的可能性 毕竟当下身为B也无从换掉上游的A

可能a太废 b来救火 但本文没有详述 另外b解了bug 应该也是a team收割成果

说B明知有bug还上 当然事后来看确实有bug 但那个当下公司里有两个人说没问题 B能肯定真的有bug而不是他搞错? 当然是其他人说没问题我就出了

B的环境就是能够重现问题，哪有什么搞错了？遇到这种情况，B应该把球抛回去，跟A反应：东西在我这边就是会有问题，请你过来这边看一下。而不是摆出一副反正他有提出问题了，东西炸了也不干他的事的态度。对客户而言，无论A或B或甚至QA，都是同样一个团队，他们才不想管到底是谁那边出了问题

A的问题，所有BUG都可能会没处理就关闭

你要B的环境，你推不动，不会找你主管或他主管？

B也可能设了不该设的环境变量造成问题 实际上并不是问题

看完整串只觉得MT大真的很有耐心...深感佩服

我只知道鬼故事是坐我对面两个破百的死胖子上班睡觉打呼很吵

A有回应无法复制才关掉欸 中间A和B来来回回三周是在回什么？

B这种人才有问题,小事搞大,A就算废了点也没那么糟

这可以转joke吧？

讲什么逻辑...ptt是没有根据某几行回应的 讯息不够乱脑补 还是不严谨的脑补同类人很不爽 被看穿意图 三四人跑过来想抓我错误 说要体谅B 怎么不体谅别人ptt用手机然后你们抓到了吗你们这些人路数都是一样的 无法占理就在那边延伸乱七八糟的脑补 延伸可能的攻击面 不然就是说一句就跑

MT说得没错啊 close不是*close不是小事但大概能懂你觉得B搞人远大于close

都已经说了反查还在那边B不是A专案的owner 脑补别人觉得是但这种东西很不可靠 尤其他们说的自动化部署 Mt自己都遇到问题

不 有耐心的是MT

请证明他有耐心一直脑补我才要被烦死我还要解释才行 然后抓错重点还要我讲 真的一堆唐三藏 我说XXXXX 你问我XXXXX请证明 不要空口无凭西游降魔篇 孙悟空：从南天门砍到蓬莱东路 砍了三天三夜 眼睛都没眨一下 唐三藏：你眼睛不干吗？ 孙悟空：我说我杀人不眨眼 你问我眼睛干不干？

最后是哪写出问题 求解

你看一下楼主在下面的推文 但这篇讯息过少 楼上一堆脑补的 ㄅ不然就是我的经验如何如何楼主说的错误只是个方向 不详细无法推理

B这种人随便一抓一把, 跟公司文化有关

不会想和B当同事的原因不正是因为实话总是很难听吗？不然当个表面上什么都不知道的乖宝宝就好了，没人知道你的心里到底在想什么如果公司文化鼓励解决出问题的人，那B这种心态的人一定一堆

B会有这种心态与表现，不就是因为环境太烂，A太烂，A的主管太烂。导致于B只能用这种方式发泄。结果大家只检讨B。

A遇上bug没有身为owner的自觉，推不动B根本不是理由，最糟

没有验证team?另外分红太少才敢这样搞吧

那QA是失能了吗B就是话太多自爆

不是啊 XD 公司烂你就离职换更好的工作不就好了“只能用这种方式发泄”是哪招 谁会在project上发泄?报复社会喔? XD

前面讲B的发泄指的是后面的言语吧，B对整个案子哪能发泄什么？我认为是原文叙述的问题啦，B都跟其他人不同bu了，什么feature owner、release feature给客人，讲得好像没有B就不会在客人那边炸开一样，问题是原po后面那篇补充看起来根本不是这样啊在A把bug关了之后，B不上自己上层的commits一样会被A部门追着上啊，而且给客人的release看后面那篇也是A部门的工作，更是经过QA验证没问题才给客人，根本没必要一直在B搞事这种脑补里面打转

B只是做他该做的事 A跟QA说没问题 B不上他的feature 不管谁来看都是B没做他的工作 B只是讲了蠢话

B这智障..

没有B确实结果不同 B最接近客户端是没看懂吗 肯定比A他们还容易发现问题 因为开发思考方式就不同 要体谅B为何不体谅A与楼主？ 所以借此评断A他们是否烂是很不公平的事情 你怎么知道不commit会被追着commit?看前后文没看出这种趋势和必然性B直接上报就是讲实话了 没有这种恶搞还要说自己好老实 一堆人说蠢只是觉得B不说就pass而且还可以搞到人人品差还要以老实为他解脱 这老实并没有掩盖住B的恶意

反正不是我的BUG 有回报qa就好了这三小 国小生喔XD

照楼上说法 很多大公司里面的Sop都是国小生

反正按照sop了 知道问题放给他爆 如果大公司一堆人这样想那的确很多国小生

这可能真的是黑暗兵法，但自己讲出来简直自爆

负责的function bug，缺乏自觉。

B把大家认为没有Bug的code，release出来，错在哪？ 是整个问题的根原吗？ 错在他说的话原PO不爱听而已。B的所有行为只是照公司规定做事，错在哪？如果今天讨论重点是B不会说话，我也同意。讨论B是整件事情的错误点，看起来不像。

错在理直气状的炸人 是 B的部分很关键 这样搞不只是楼主收不了场 从上到下除了神隐的都收不了场

bug 复制不出来要帮忙厘清吧，怎么会觉得 B 没问题

重点你不知道公司规定是什么只能借由惩罚推论B的目地就是爆炸 不隐藏会说话都没用会隐藏就是更恐怖的人 怎么一堆人觉得B自爆是不会说.不会说话B就是当事人全炸含老板都炸了只为了一点想法自曝了动机无关B到底会不会说话 因为不会说话所以B乱说的不能作数？ 看叙述楼主也没有刻意引导话题

会把客户资料给扬了bug怎么会觉得close很正常？

我觉得可以办个投票,看看觉得B没错又愿意跟B当同事的有多少人比较有意思,比起各执己见,投票身体才会是诚实的

我觉得B是黑掉了，管他流程到底有没有问题...

B问题很大 bug就算是A的或其他人的 在解好之前这个功能要先关掉不能出去 明知道有问题还开启这个feature就是以为这个bug不是我的 不关我的事 这心态很糟客户才不会管是谁的bug 都是你们公司的问题

B算不算利用职务之便企图毁损客户资料?

B的行为根本就没有照公司的规定做事 哪个公司会让明知道有问题的东西放出去炸客户 不管是哪个人造成的问题

A把bug关了，是有多少人bug是用嘴巴在讲而不是用系统在管理的啊？还在那边B有问题，我都快怀疑这版有多少人真的在开发软件了

哪个公司会说不是你的问题你就不用管其他人一直出就好 这是自私自利单兵作战 公司就是一个整体 客户会去管是谁的问题吗?

A把bug关了，你公司不是用系统在管理bug而是靠谁说有问题在管理bug吗？对于公司来说，A部门给A把bug关了就表示这问题已经不是问题了，B这时候有什么理由不上他的部分？

B没讲，当然就变成QA的问题

我上面已经说了 这系统本身就不可靠 有人给我示范了救出问题阿 你还要用该系统做什么基准？ wmt真的没在看 如果要使用我觉得限制close才更好怎么会让一个人就决定一个issue是否close...至于A有没有实力问题？ 其实没 未知数不知道怎么会是有实力问题？ 你行你来

…B太蠢了 最糟糕的解决办法

如果没有后面代打卡事件我会觉得B不聪明 但有代打卡所以B不是蠢人 蠢人是没办法找人代打卡的

那就不好说了 蠢人大集合也是有的

现在这个社会你说有很蠢又让人占便宜的人有多少？ 蠢人大集合 代打卡总是有人帮

bug issue应有分等级吧? 这看起来像fatal error的居然没列管 还让人说锁就锁说开就开 果然很鬼

B是行为不好，A和QA是能力太差，都很雷吧

有盲区就不用评论能力 因为每个人每件事都会有盲区拿这个来评论能力高低是很夸张的 B的行为很不好是真

人一多，必然会出现有着奇异的人XD*有着奇异思维的人

B的问题就是杨修 不打勤不打懒专打不长眼 要嘛要点出来那就要解决问题争取组织关注 要嘛就直接装白痴 相信原本相关人员的处理 炸了再表现很认真的“协助”

说真的 连鬼的边都算不上一堆没逻辑就是看你不爽搞你的才勉强算而且一搞十年以上

觉得B某面心思细腻，可能有点亚斯伯格不太圆融处事

B 上报主管不就无事脱身了 …

绝对200%是A问题。 A认为没问题但实际有问题。技术不足技不如人。真的要认真追问题怎么不跑去B的座位直接问？B不配合叫B的主管来压他逼他复制啊，明显A自己验一验觉得没问题就关闭了。直接查code到底哪段code把资料搞烂的 ？分明是A搞砸一切。写烂code别人说有问题又不追根究底验证，还直接close把A跟QA都开除吧，一个写烂code一个不认真验。

这种八成是之前就有冤仇了啦....

干嘛不直接rollback a的code

那 QA 没测试到耶

B这样能开除加要求赔偿吗？

B 把 bug 先报给 QA 不就好了直接发布等于把自己信用赔进去

对，QA没有验出来，原本我跟QA都要提头去见老板了。B有把bug回报给QA，但是QA也没有试出来。

B也太神了 无论如何内部多不合 也不该release到客户吧直接害公司要赔偿客户 这神逻辑 就算A摆烂B也不该这样

怎么没有review机制

他没先从内部想办法处理 就用这种外部成本来HL到A??B想HL到A没想到HL到自己吧 喝

可以贴出哪一位吗 避免大家以后遇到

B把变红的机会直接变黑耶。

B没想过 A无法复制 QA又测不出来 难道不是B自己的问题?

我猜B就是想commit上去，让‘客户’证明不是自己的问题

客户能分辨出是谁的问题的话 干嘛不自己赚 傻

让客户炸掉无法证明不是B的问题呀

事后回想，其实B只要什么都不讲，就安全下庄了。

真的吗????那会变谁背锅? QA?

不可能吧呀，一定追得到。你都知道他commit 有bug的东西了。他是动机很有问题

最后是我揹锅，跑去客户那边想办法恢复资料。A/B 当年考绩炸裂，A先离职。B半年后因为一些小事被火B最后是因为请别人代打卡被火

你算救援吧。A、B考绩炸裂才是背锅吧我比较好奇当下怎么没有开除B

大B哥，厉害惹

我的职位要扛feature成败，所以我也因此卡到升迁。没有火B这件事我也是傻眼+不满，所以我比B还早离职 XD

B这心态，阿弥陀佛

其实原本我+A+QA都是主责，但是B一招神龙摆尾全扛了

这B头壳撞到吧？

真的是什么鬼故事都有

PC哥这篇之前是不是发过了 好像在哪看过

不对啊怎么说都是先火B吧

我在个人FB发过，今天想到贴来跟大家分享一下。

待打卡被火该不会是有上新闻的

代打卡那件事我是离职后听人转述的，我没发现什么新闻XD

再现不出来是验证的能力不足呗输入毒物也好状态操作也罢，一堆除错方法能当测试手段

所以最后找到的问题点在哪方？ 很糟糕的状况所以B先搞掉你们？

最后问题是A的code在某一种使用情境下有问题没考虑到。这种情境刚好B跟客户会遇到，A跟QA都没有假设过这种情境

这B真是极品，想弄A不管对整体产品信誉客户的影响，然后还大辣辣自爆，到底是聪明还是蠢....真是什么人都有

故意将有bug的东西commit上去，这样炸锅是全公司都死耶….

所以B当初也有扣押讯息不说的问题就是 看起来就很像人走光轻松了找人代打卡

觉得B最后做法是错的，但是他也有回报出问题，就A、QA跟最后把关的你的问题。假如你能看出问题点，这整件事情都不会发生。

B与客户知 QA都不知 就是讯息不对称搂B肯定当你们是敌人就是 统整的人刻意不提供完整讯息......

傻眼 傻子

不过很好奇哪间公司 B会不会出来讲呢？内部人员勾心斗角都不会心累...

就老害啊

某一种使用情境...重现方法没有附在bug上吗然后A复制不出来也没办法找B当场重现一次?

B要被五马分尸，笑死。

bug开着卡了feature三个礼拜 扛feature成败的人不应该等问题流到客户那里才知道吧? 这种有跨team争议不需要长官出来协调吗?

B挖个洞结果没发现是自己跳进去了

B就是脑残啊，这个留下，迟早再出另一个大包在怎么不爽，也要先跟主管说，怎么会爆给客户

B除了多话外好像没做错什么. Bug也不是他写的，也回报给a跟qa，甚至挡了3个礼拜同时还要做别的功能. 结果票被关掉说无法复制大概觉得同事程度都很差放弃叻. 要烂一起烂lol

qa干什么吃的 然后到底是不是a的问题 issuse关闭的检证机制也有问题b应该能力不错 但就是要一起烂

再说事关自己的升迁, 原po怎么好像事前一无所知. 心脏也是蛮大颗的

疑点大家都说了 我只能说这个团队关系很差

B根本没错 错在说错话 责任归属QA>A推文显示出台厂文化 先解决提出问题的人

如果我是A,然后bug一直重现不出来.我会委屈一点，到B那边，直接请他重现bug给我看.确认bug了，但还是在我自己的环境上重现不出来.我会商请主管征用B的电脑，请B去旁边玩沙...,让我直接在他环境上解bug, 以上

欸欸，我商科的，是不是意思是B知道A做出来的菜有毒还出给客人这样

总觉得事实应该不只这些，不过现在对原PO来说也已经不重要了

重点是出到客户那了吧qq

QA都验过毒了

这真的是鬼故事XD楼上有人是不是有点搞错原po的意思了？楼主有说这责任原本应该是他+A+QA的，但因为B为了证明不是自己的问题，所以直接release给客户，导致客户炸掉，让重点转到了B身上

B 也太猛了，这个事故绝对B占90%的责任，明知店里的菜有毒还端给客人吃…

B真的太多话了，他不说那几句就可以完全没事

楼楼上 A和QA说没毒啊。厨师自己都说没毒了

嗯...正常不是都应该要一起查问题吗

QA把关不到位 A程式品质差且态度消极 B错在选了最差的方式HL 最大问题是issue严重程度明显被低估就放行了 不过这个故事里缺了好几个该把关的角色(A,B主管) 也许还是看看就好

a跟b是人本身有问题跟科技业无关吧

B A两人是不会讲话沟通吗？只会用issue 选项沟通？但整件事情看起来，B是最糟糕的竟然让客户参与了debug 。他有不高兴不爽可以内部提出啊，这是什么沟通方式好可怕A复制不出来问题，B也不帮忙，从这一步开始B就错了，你在公司工作重点是产品本身，而非展现你很强别人很弱。

有问题的人比会不会写code还重要，这种根本不定时炸弹，雷暴

你也有问题啊 你都说你需要扛feature成败了 却让bug卡三礼拜不去协调 正常担责的是积极介入请A提供更多资讯给B

总觉得是两个个性不合的人，AB一直合作对冲，结果都产生硬干对方的想法，原po算虽小，QA就没尽责，该说这样的沟通合作问题主管其实要上点心吗？XD

明知有重大问题还出给客户是怎样 公司商誉都不用顾了？

B雷炸 只顾自己好?一堆人擦屎就饱了

B跟A都没有主管就对了？那家公司那么自在啊？

B事后自爆的做法也很奇怪吧正常人好歹说A重现不出来以为是误判才release

这两个都应该火掉但是B比较严重,拿客户做实验

B只要说他相信原po team有处理就没他的责任了，B太多嘴了 XD

XD 推文里面说“B如果怎样怎样说不就没事了吗”问题B就不是正常思维啊 XDDD 正常人一开始就不会这样乱搞

你可以跟A说好了啦，都是你最惨，不爽离职啊嘻嘻

B这种就是赌气硬搞阿，而且是明知道后果仍要做，根本超大雷这种才团队里面超可怕，啥时爆走都不知道

这哪叫鬼故事==

说B没错的是认真的吗？

这就人品问题

不是啊 就A跟QA都复制不出来啊 所以这问题到底有没有存在

问题确实存在，后来也找到复现方法，但当下就是环境不对

应该是一间没有制度的烂公司

再来一个B这样的家伙，我没信心挡得住他......

看起来推文可以排雷不少人B可以没问题的情况是他也不知道这Bug就Commit上去，出了事就是其他人的事他现在都回报Bug了，也没有解决仍然Commit上去，那就问题可大了不过这公司也很鬼，Bug卡三周还只有B、A处理，其他人在干嘛？

因为当时其他问题卡更久......

问题就是把issue关闭的那位啦

我觉得是你跟B的合作关系有问题，B应该认为“我提出的问题被无视，A跟QA都没问题，我看就有问题，你们觉得没问题好啊那就上啊”但是为什么B在出事之前没有试着找你这个负责人沟通就像B说的，他也有时间压力，A不去解，这整个专案运作的人跟进度都有问题，你被卡升迁也是刚好，专案顺利有得升，不顺利就没得升，才是正常的赏罚

这件事有一个背景，就是A是我的RD。没有B也不会发现这问题

如果你照样能升迁那就是小兵扛责长官收割的那种公司

没有B应该也是会出事，A也会全扛。只是有B之后变各50%本来就应该是我+QA+A要全扛没错，我也认为我应该扛最多 XD

照你这样说，B其实也满虽小的，A写了一个严重bug，他本来不在这个坑里，好心插手结果被无视最后还招一个骂名什么时候出续集XD

对，B错在最后不应该自己讲出来，他其有很多路可以甩锅。

这个在台湾常发生啦，简单说就是权责不分+公司制度导

为什么我考绩没有影响，那是因为最后客户资料我有救回来。

致，公司如果有bug回报系统之类的，公司主管也愿意花

最后有人认为我A+B各打50这件事是我在‘护短’B的老板也觉得我在甩锅给他们，所以B只影响考绩，没有PDCA

时间和组员开会讨论这些bug，说不定可以避免掉

如果每个问题好好review，或许可以避免这样的遭遇。故事最后，就是大家打迷糊仗的状态下辗过去了。

干好猛，我还以为只有银行端会有这种，我就烂，要死一起死

B故意再搞

团队应该有更严重的人际问题吧单方说词不太能判断

再怎样也不能影响到客户吧

我听到的鬼故事是印度佬为了推行自己的新东西，故意把错误的code commit上去让公司系统炸开. 事后跳出来说他这样是为了公司好blabla

B就豁出去了，要死大家一起死

无法接受损人不利己的事情。发现有B这样的同事我会尽最大努力远离他。

B在之前没用其他方法HL？ 像是给A主管？ 而且两部门间看起来关系也没很好，那真的要B协助Debug，应该找他主管，让他可以把其他工作往后推吧

应该都要处分吧 虽然结果也是都闪人 啊问题卡三周 原po没有要处理吗

A是不是只回B一句，“我无法复制”就把锅推回去。

B除了说真话有什么错吗 哈哈A验过 QA验过不就通过表面品质保证真的到客户出事那就是A再来解决囉

B没事就开天窗？ 怎么看都是得过且过的公司文化 B整的很度烂

虽然看起来很扯，但一堆公司都这样吧，重现不了就摆着KPI重要，怎么可能跟你在那边研究几个礼拜...

另外应该再描述一下你的公司文化，开发制度，这样可以更精准评价，既然你想讨论的话

的确，当时公司正处于一个新事业发展初期。新产品问题一堆能复制的问题都解不完，不能复制摆个一个月也很常见。

B已经仁至义尽了...他大可连有bug都不跟你们说帮你发现bug还被要求帮你复制问题 帮你厘清没几个人会想吞吧

B会回报bug是因为东西在他环境一跑就炸，根本整合不了。不过公司就是这样，B的KPI不是整天卡在帮别人复制bug上。

重现不了当然就切掉啊...所有公司都是这样

推文中有说B不是同一个team的，那就不是很意外

B的问题是他的心态，摆明了就是公司死是公司的事 不是我的事，或是为了赌气会拉着大家一起死的人文中A都搞了三个礼拜了(打个折当作他实际只弄一个礼拜)

所以整间公司都有问题 哈哈

有责任心一点就是CC给自己老板跟对方老板

组织状况：{{我,A} QA}, {B, B的主管}

老实说也差不多了 以前我在某几千人的IC设计公司 一个bug卡一个礼拜还是没办法重现的话也是直接切掉总要有个停损点 try不出来就去解别的bug没啥问题

楼上这就双标了呀 认为公司死不是他的事的人岂不是允许bug被关了的所有人吗?

bug卡X天就close这个本来就是一般公司的SOP啊 这是成本考量 任何一个公司都不可能放RD每天在那边研究try不出来的bug

B报给QA，QA试不出来，然后QA就决定不管了这样吗XDD

会导致重要资料毁损的bug,也不该由底下RD自行close...

那怎么对B就那么严格呢? 这bug甚至不是他弄出来的 他的feature被卡也要要有个停损点吧? 怎么就变不顾公司死活了

中间B的态度也很可议 bug发出去后就认为解不解得掉是A的问题 中间不愿意提供协助 这种就是完全没团队合作精神的例子

“B发现整合会造成资料损毁 但QA有过” 双方也不需要沟通吗

你是不是之前有投靠北工程师？好像看过一样的故事

QA也是未爆弹 原po要注意 喔烦沟通就快跑

即便B不多说话 版控记录还是他commit 鼓励甩锅？B仁至义尽？ 以楼主目前说出来的B问题非常大除非有什么其它内幕B无庸自疑是最接近客户端的 A不会知道客户的情况目前来看是B暗杠了讯息不说加上后来找人代打卡 人肯定有问题 楼上一些人是不是干过同样的事 事不关己大家都差不多 但最后问题出在使用情境 这部份除了B谁知...

说B没错的是不是在开玩笑或是反串

目前除非能证明A乱写 技术面分析B端的是通例 我们到目前为止还不知到什么bug而且程式我不相信只有A在搞

B的问题在明之有问题还擅自作主commit上去 应该至少经原po或B的上头的同意 如果有经上头同意 B就不用扛责

B的问题就是要冲康人还白痴到说出来

在这种情况下A确实无法复现 难道要A通灵？

那A要肯定是B的环境问题啊，这本来就是要自清。叫不动B，无法复制B环境，这些硬要划分都是A的责任。打出bug后funtion owner敢close，不就代表有十足把握？

不鼓励冲康人 你再会掩饰都会透风 有没有人去细查而已

好惨

function owner都讲不是bug了(issue close)，B身为一个整合者，当然就是相信A的判断阿。

叫不动B怎么会是A的问题...

因为function是A的，要怎样解都是他的职责。

我觉得要看b有没有像上反映啦 上面如果认同就这样close 不就也认为是b环境问题

同意MT6797的说法，B只要不自己承认，基本上没有他责任。鬼故事的点就在于，B竟然自己承认了......

B是蠢在他讲说自己知道有BUG还硬上...

B没义务帮你，他的工作内容我想不会有协助隔壁部门debug，他花时间帮自己schedule 爆掉算谁的？

他不承认也是他commit的 他不会不知道有这问题这个bug本身不是只有一方的问题 是在鼓励干坏事不留

整合者不知道function内容很常见...最了解function的owner A都挂保证没问题了，B正常情况不用去质疑这件事。

痕迹就是... 以楼主回应就不是纯A的问题

在我的认知上，敢issue close就是owner挂保证没问题。

这样就相信了那也不用QA 除非这东西是A从头写到尾

B不承认的话，我认为责任本来就是在A跟QA身上啊。

close理由说无法复现就不是纯A的问题

我文章看下来B是整合者啦，整合者把所有funtion验一遍我是没遇过这种神手。当然是A的问题，无法复现跟issue clsoe你敢画上等号？该举手求救、乔资源还什么的就应该做啊，找主管啊，结果直

不同职务当然B不需要知道 但B自己掌握的讯息没讲给人

接说这不是BUG... 够屌。

这肯定是bug 哪个人说不是？ 只是不是纯A问题的bug

肯定是bug... A还issue close... 这不是问题

我也好奇你提到 掌握讯息 这一个论点是哪里来的？

掌握客户端与测试端环境不同的讯息 你是不是没看楼主

鬼故事的点难道不是B主管神隐吗XD 不管是要推或扛至少站队自己底下的人吧 能够硬commit出事主管怎会无责

好奇哪家公司issue解不出来也可以close的？

楼主在推文有讲出问题的地方 所以你就是没看到楼主推

要整合者比function owner还了解function，还要帮验，也满屌的这个。

文 这个点A是不会知道的

A要去厘清啊= =

不是纯A的问题不假

负责function被打出时灵时不灵，因为我不知道为什么有时坏掉，那不是我责任。

无法复现卡三周不就是了 什么叫A要厘清 他拿什么厘清

从时间点来看B也不知道客户环境C啊，A B C三个环境恰好A的跟别人不一样

拿什么厘清？那是A自己得解决的啊= =A要是觉得B环境问题，找主管帮忙乔资源还什么就该去做。

没事的话，就只是B在叫叫叫而已

B的环境与客户的是同的 ㄊ他不了解谁相信 楼主提供的讯息来看就是这样 A客户端都不了解要怎么解决？

那也许B要串资源，但是串不动A是B的责任这样

我认为情况是反过来，A需要串资源，串不动是他的责任。

而且到底B环境跟客户C环境哪里一样，A不是怀疑B环境坏的吗

B是客户端环境，那A环境不对还敢close? 怎解决？找B解决啊

他敢怀疑B环境坏的，难道敢还疑客户C环境坏的，不会吧

这需求不会是一方的问题 所以不是纯A问题至于更详细情况只有楼主知道 目前来看B很有问题

今天如果真的是B环境问题，A怎没花个半天一天去帮忙处理好吗？

环境不是坏 是不同

A不去串资源解问题，而且还敢close骗人这才是大问题吧XDB单纯是蠢在自爆。

这不是A的义务 就如同上面有人所说 彼此关系不好

也是，A只要说B无法说服A和其他人就可以打回了

我觉得B只是太直白啦 不过他大概也在想一堆杂鱼同事没兴趣跟你们演戏了

A尽力找原因 没找到无法复现close本来就不是过错

function被打出bug然后不是owner责任... 天哪。

环境不是坏的没人知道，但是有可能B把自己环境搞砸

A有尽力吗？找自己主管、找对方主管去谈这件事严重性？

所以function owner反过来要求整合者举证环境是好的

A当然也会有责任 但不是只有A有责任所以最后处置没错

客户打出问题，卖家尽力解不掉，客户也有责任要自己解决？

两边都不认是自己的bug，那就是要找有能力乔资源的来解决，A敢关B还能怎样

我觉得你应该是不清楚所谓function owne跟整合者的分工型态。

feature owner是B, A是该function owner，所以最后A+B都要

这是公司内问题干客户什么事 不要乱比好吗

要整合者扛底下所有funtion的责任这太幽默。

扛的原因是这样，而我是负责一狗票feature的leader

A解决不了可以pending 啊，摆在那急的是B又不是你

那好，A证明function没问题，B证明环境没问题

B当然不负责A的code 这是废话 A找不到原因环境有坑也

B与其说是整合，更像他实作feature时需要用到A的function

A就把issue关了，B解读成已解，这根本没问题。

不能全怪A 最后处置A与B考绩炸裂没问题

B是蠢在他明知道A没解只是假关，还真的弄上去爆客户。A的问题很大，解不出来也不找人求救串资源，甚至直接关。

那不是已解的意思 B知道有问题看issue没更怎么会解读成已解 ?

issue close不是已解的意思？

corner case处置啊，只要未来没有客户撞到就不会再开了

其实最终责任本来应该是我要扛，B的出现就跟救世主一样 XD

你怎么知道A没找人？ 楼主没讲 就算A没找B也不该如此

例外处理也是一种解法啊。

你啥都没做，既没解root cause也没证明是false alarm，就

举个例子B是camera feature owner, A是AI function owner

你不看close原因只看close状态来解读当然会觉得是A的

camera feature owner一定会被问：难道你feature没测过？

close要啥原因？那又未必是B的责任。找出close的原因是A的责任好吗= =

不过因为A是我的人，我这样说一定会被人家说‘护短’

A就标注close了 不然想要B怎样?

说close就相信close 草率至极

底下function一多，最好是有可能把每个onwer抓来盘问一番你的pass、close是真是假。

这需求是两个人配合的 A找不到问题换B找是对的 什么

两边的clos本不一样呗，一边是解issue的另一边是corner的

close不能相信 那自动化系统可以废掉了 pass假的

你说B找那是小公司才允许这样干，高度分工只会要A串资源

可能要串B帮忙解我认同啊，但close三小啊XD

你程式码弄的好那可以差不多close是解决 但不是所有

私下讲好或者A哄一哄B也许就搓好汤圆了

那只是代表你公司自动化系统只是填好玩的？

要能自东化首先你数据就要是对的

数据要对，那也是能自动化对答案啊，又不是肉眼对数据

自动化通常也只是测试 上线不确认崩很正常

是要确认啥？把每个owner抓来review一次所有验证？包含你pass/close有没有手残按错？review一次不够吧？至少三次比较安全，怕前两次不严谨。那你家自动化系统可以废了XD

说个笑话 人眼一一校对自动化 double check

当然要肉眼自动化就没意义 但上线都自动化太托大了

我觉得就算你要回一个error code 0当成close，也不能奢望

你现在不就要B人肉自动化？谁知道他手上多少工作，又发多

少BUG出去等别人解通，然后要串自己的feature？

你都开issue了当然是确认该issue没问题 手动测要花多

我的作法是只有一个error code 0才是真正的close，你用非0

B的确测不过 但是A直接close QA也测过了，一般情况还真的是B环境问题机率比较大，B如果认为自己环境没错，有找人没人理他，我是觉得他已经把他分内事情做好了啦

对啊，我就说小公司可以那样搞

部检讨一遍，上次检讨pass这次也未必pass... 这才叫诡辩XD

原因是无法复现 我上面已经讲了 你只看close状态当然

你不信任close那干脆就废掉issue tracking系统啊XD

觉得是A的问题 这样判断也很草率

各位是逻辑有问题吗 A和QA说没问题 客户炸了

我想法同MT6797 觉得B有问题的就是标准解决问题的方法就是解决发现问题的人他就错在太老实 说错话

B顶多是草率，A那根本是造假，在我待过的公司。

B早就说有问题 然后大家怪B?

issue随时会reopen 只看status不是好标准

不信任issue tracking系统那干脆废掉，而且会毁掉同事间合

所以楼主老板处理方式才会没有火B只是B能拿战功的 说错话变黑人

A没有条件可以发现问题点啊 他也没说问题解决 说的是

可能实际执行好吗。

无法复现 不代表问题真的解决

没解决在close三小

你issue可以reopen啊，那是新开发又有相同的issue

维护了哪来issue让人开开关关的，什么都没变当成默认close

大公司issue都会reopen 开源专案都是如此 repo不会那

你现在的论点就是听到pass不等于真的pass，全部要仔细检查

么整齐

，实际面上几乎不可能这样搞。

reopen是解了 新的code又出现老bug不是他妈的没解close掉被发现了再reopen

不是一厢情愿，是合作效率，以及彼此的信任。

Reopen条件是啥 owner自己都签名close了

好奇哪家大公司维护旧code会reopen issue的

有什么开源专案会reopen的，丢出来瞧瞧

造就pass就是送owner pdca pip 关B什么事

你所说的效率不存在 所以才会有屎山

提大公司更好笑了 大公司直接CICD谁跟你人工测

最好是不存在，不完美不等于没有效果好吗= =一个一个ip、function都验完整，owner画押，一路叠床架屋

有人没看过开源专案是不是 未能复现本来就是很平常的

往上开feature、scenario、system。

我之前待的 随便一个merge要跑80个环境pass每个环境破1000个test

都是建立在信任底下的owner给出来的pass report。

你人眼扫给我看

不会有行云流水的状态出现 有的话请举例哪间公司

简单来说B发现一个问题，开发者A说没有这回事并关掉issue。没有未解bug就release给客户用，想不到后来真的炸开，B有提出了他之前有反应但被close。最后就是B被人在网络上偷臭，真的是科技业鬼故事。

会有，有些改动幅度小的案子真的就很顺。

那是瀑布开发吧，越大的组织分工越细，随便都可能堵塞小公司才有那种横冲直撞任我行，出包也可以转个弯绕过去

底下牵涉到的ip、function几百上千，绝对不可能一个一个抓来盘问你的pass是不是造假还什么。

你最后手动一次这不是很过份 不然要QA 做什么 本文或

若有人造假也真的被打出问题，造假那位通常死很惨。

许Qa 用自动化说过 但看不见的Qa 也不会看见

手动是善意不是义务啊

既然你提到QA，QA也没验出来啊，这怪B就更奇怪了。

人眼再扫一遍也没用啊 当初A就签名closeQA没打到 谁可以通灵reopen bug?

不然以后大家便宜行事，看到pass还需要人眼反复监测没问题

你说的改小的之前history也不会如此自动化与本文是两件事 他们扯到自动化 回应而已

讲个最简单的 照你逻辑 那QA测不出来要你QA干嘛

找不到原因是close 等到找到就reopen了

你的肉眼全盘点不现实啊，你要哪家CEO去检查底下每位员工

那换个说法，有一个scenario是从来没测过的，你希望人眼

反正台厂水准就这样 直接解决发现问题的人M大应该是MTK的 处理方式已经很标准了 少数有完整制度的公司了

所以我就问 QA测不出来要这个职位干嘛?

我好像知道观点差异关键了，superpandal家的close不是其他家的close意思...

这事件所有人都不是万能 但B没有想要找详细原因 以楼

解不出来我接触过的公司通常是suspend甚至亮红灯通知主管

主透露的讯息B问题很大 没偷臭

其实我觉得这件事主管或公司制度有问题啦 一个bug a不认b不认 就算要这样close也要有人去处理好b的环境吧不然他接下来要怎开发

无法复现close issue很正常的事要看close原因 要说多少次...

真心要互相体谅，在superpandal公司corner是close是自然的

我不认同很正常，可能我见识浅薄。你无法复现不等于别人无法复现，你应该先搞清楚差异在哪，

并不是我认为close绝对不是真的close

那是owner的责任。因为自己无法复现就close甚至认为没有，

评论别人的时候要留意是否是戴上有色眼镜而造成偏颇

所以无法复现close又要怪B了？

客户那边不就复现问题了(笑

你家的系统允许未解issue按close，我家无法QQ

复现不了在客户爆 责任归属如我之前留的QA>A

A 与 Qa都没发现问题 当然找B 不然呢 deadline以经到了

deadline到了，A跟QA都说PASS，还要质疑什么XD

最后问题点也确实与B脱不了关系

是是，最好是准备个测谎仪将B所有隐瞒讯息催供出来

A没说PASS，B硬上的话那我认同就是B的问题。

要不然就甜蜜蜜好感情一起搓汤圆

B早就说有问了 测谎仪是要测什么XDDDD

B有够惨 整合code其他人有问题的都要他负责

那个问题点A和Qa不会知道的

Owner签名没问题的也要他负责

B隐藏关键讯息啊

这件事全都有问题 但B的特严重

A是kernel层以下的 B上层好吗你API给我我call了有问题还要帮你debug?

我的经验是造假的A最严重，B有道德瑕疵，不过每间公司对于造假的认定不太一样，我觉得这是讨论的分歧点啦。

环境是开发者视线盲区 又不是全端

一个app去system call OS系统的function出包，就这样子啊

如果纯脆是A的问题可以不用管 但不是

你怎么知道不是？

楼主都说A+QA主责了 B说错话直接被拉下水

先厘清环境问题，这也是A本身责任啊。

对阿B不是全端只是上层 下层A功能确实有问题干B屁事

不是说明明与自己有关还推 A与QA都说没问题都不细思

谁知道客户端环境，可能C1 C2 C3千百种的

一下 如果只是A一个人说没问题那有待商确

从结果来看确实是A的环境有问题，他却没想办法解决跟B环境差异，然后造假PASS。

你这就是把环境推A身上 测试环境如何不会是A确定的

讲这么多屁话现实就是客户炸了 B上层早就说了

修正一下，A应该是有想，只是没想出有用办法。

因为function owner是A阿，他就该知道在不同环境下的可能影响，B也可能是false alarm好吗= =

不要脑补好吗 依据楼主讲的为准 除非有新的证据或当事人加入战局

你去看一下原文 一个kernel以上 一个kernel以下不知道在哪的话 含作者标题第10, 11行

A是RD 不是OP

不懂什么是kernel以上和kernel以下差别的话去念计概

要嘛function正常，B乱搞，实际false alarm：要嘛function

环境不会是他布的

有人很懂 两个都是开发 不然呢如果环境单纯那你说的合理 A会最清楚 没有人神通广大到视野盲区都了如指掌

没要A神通广大阿，但他应该想办法解决，因为他是owner。

环境单纯? 你假设全世界用户跟你用同一颗cpu?

bug就在那，你能力不够就举手求救，要串资源就找主管帮忙

我跟的liver正在毕业直播，无法理解的无法理解，浪费时间

如我以前所说 未知是造成灾难的来源

未知三小 B就他妈跟你说有问题了

B是统整的人才有义务做这件事B说有问题 两方测出没问题不应该再反查吗

B说有问题，可是A说没问题...又绕回来了，你要B负责整还要帮验底下所有function XD

就说了B是kernel以下 A是kernel以下

这就不是正常的分工模式。

是反查与B有关的 A有关是A付责

整合的人要帮验底下所有function，甚至要比owner还懂，怎

一个caller一个callee很难理解?

不干脆逼他自杀。

A更底层没错 但不是环境 废话

上层发现你function有问题 还要帮你解是什么笑话?

贵家的function owner感觉很爽，求内推。

重点A也不会知道盲区外的 B如果环境与客户同 又是统整的人 分享一下讯息不用debug

A要去厘清function在盲区的状况啊，不是只确认非盲区安全就是pass，因为bug就己经打出来了。

不找问题close三小? 有问题是要找到不是算了耶

A测无结果你怎么会觉得是一样

s是不是没有跟别人合作debug经验 看发言 傻眼…

A有找 QA 有验 但B没讲讯息是真

B就highligh了阿你是想怎样

B又不是这funtion的onwer，哪知道什么要给什么不用，要怎么让B帮你就是A的责任啊，看是要找主管还是怎样。

废话当然有 不然我怎么debug... 这笔帐不能纯算A没错

highlight就不是反找问题点 这件事大家都有问题 但b的严重很多 A要管什么环境...

欸不是，function owner是A欸，你怪B没找问题点...

真的有环境他就自己测了

A的问题很大，他没去厘清盲区因素就认定是B的问题。

A跟B问题都很大 这有什么好争的

通常这种分工，B会对接一堆function owner，你不想办法串

那B身为统整的人环境又与客户同你发现问题不考虑环境

? 你不是应该把测试环境列出？测试列出环境很平常不过的事

呃，不是应该A去看环境因素吗@@

你家的A真爽 饭要帮忙送到嘴巴门口

看来你们的环境与我的很不同 A如果就是环境 那A解bug根本不用吹灰之力 讲的环境肯定是不同的环境

那你家制度很有问题 发现问题的人要处理问题 而不是发给正确的人

一个是owner一个是user，user确实有可能乱搞弄错，但user

都不要抓bug就好啦 发现问题就处理发现问题的人

还分B与客户同 A与Qa同做什么

user要负责解，这个owner真的爽缺欸。user都反馈了哪里无法复现？是owner不去厘清复现问题啊。

user 提供讯息不完整 多数owner也不会去解的

那是owner要想办法串user进来帮忙，而不是造假pass。

B就多话把自己有推进自己挖的坑

在哪debug都是这样

讯息不完整还要主动询问 A又不是统整的人

你又知道没提供完整 A自己都签名close了

本来就要主动询问啊，因为类似情况也有可能是B错误操作。那A得厘清这是false alarm，并告诉B正确用法。

A和B的主管问题比较大吧 都没问他们进度

s的做法就标准台厂陋习M大提供大公司的做法 还诡辩

A是主要负责人？ 说瞎话吧 A是负责一半专案不假 但不是负责人

负责人就楼主啊 都没看内文喔

你说哪里辩？ 说正统很好笑 A就只是个开发跑去沟通B

我说的负责人是function ownwer意思。A就只是个开发，所以就该确保开发品质。

才是台厂陋习 负责人某M说的你可以喷他

当然跑去沟通B啊，推不动的话再往上找大人帮忙推。

B能打出BUG，A打不出，负责人是A，A还不去厘清差异在哪？不用挑语病，我的意思就是那个funciton的负责人。

制度不明确才整天跨部沟通

看下来A不只是owner，还有某种上位管理职，不是单纯领薪水

这就是制度 你的制度是什么？

function疑似有bug，owner就该负责处理，user/test不配合

做开发的，难怪呈现的态度很像是比统整更上一级的感觉

或推不动什么的那都是owner要想办法解决的，解决办法很多，但绝不是造假pass。

我没有不信制度 close与否决定是否真的close楼主都没

制度明确是分工模式，并不是不跨部就代表制度明确= =

function出事就是该owner进场处理当主要负责人，而不是要user这种不是owner的人背锅。最后发现是false alarm，user搞笑，那也是种厘清解题。

真的"明确"不会随意让人跨部沟通

跟那无关，跨部与否只是不同公司分工体系。

A要主动沟通不是份内的 真的很明确

嘴炮的那么厉害应该是总经理等级的

那只是不同公司文化，没在坳啊= =你这就跟几个人配一个主管，是否代表制度明确一样，根本无关好吗... 只是反映公司文化。

有色眼镜

分公体系什么时侯不是制度内的？

两种公司我都待过，有些一个小部门内每人工作完全不同，上

下游都在部门内；也有些一个小部门内每人工作非常类似，同时滚好几个案子，但上下游合作得串隔壁部门。这是不同风格体系，并不是谁明确谁不明确。

哪个明确，哪个不明确？明明只是文化和风格不同，怎么可以坳成明确不明确。

你都不讲到底是找上级还是直接跨部？就是不明确阿

好，那我告诉你，上面的举例，第一个例子不用跨部沟通的，我的体感是制度不明确，很多流程都很杂乱，想说都在同部门就无所谓，一直不改善。找上级还是直接沟通有差吗？找上级的意义是推力更强啊，当

然有些人会因此反感，但哪种方法，目的都是串对方进来帮忙

function A写的 但责任不是A扛这个公司赞喔

不管找上级还是直接横向沟通，都是跨部啊。

我们的制度就是没制度或少制度？

我不会知道你前公司哪个 话不合理才是重点

但你故意偏题想扯这些嘻嘻XD

笑死 自己不合理说人家不合理

A有找 找一天也可以说有找然后close一句有找问题就可以放著不管close做事情这种态度也是蛮work-life-balance

扯什么跨部沟通等于制度不明确真的难看了啦。

你是不是不知道问题是要解决而不是放著?

没提供讯息就不能解啊 解不得被要求付责的是A?

应该是A弄不到讯息，那这就是A的责任啊。

谁不提供谁不配合，那都是A要去想办法处理的，自己处理不

你怎么知道他只解一天？ 就算解一天有足够的依据也是

可以 这不是一人专案

你的足够依据=客户炸了 是要笑死谁?如果事情是这样 就足以证明能力不足那就是A废物找不到问题

你现在要扯A的主管也要负责这样？这应该是共识吧，有什么好扯XD

这件事的确是B故意用来凸显A能力 所以客户那炸了与B无关？ 再说什么鬼话 只有A 要负责...

B就highlight issue是A close掉

应该没有人说"只有A"吧...

你要看close理由 看不清楚不就也能怪B眼残

你们说的很坚定 A是主要负责人 哪没说？

owner造假pass，出事了user要负责，惨...主要跟只有是一样吗@@我认为主要是他没错啊，解不了bug还造假，这太扯。

owner哪里造假 close加理由不够说明？

加什么理由，你有看到？加说这个close不是真的close？那干嘛不继续open XD

https://i.imgur.com/13sxjYW.png AI都比你懂程式

我说白了，从头到尾根本就不应该close，上层整合的人工作繁忙下没有仔细review是很正常的事情。

你是不是没看文 mark 无法复制 看清楚了吗

不会用ptt的话教你 按/ 打"关掉"

目前无法复现根本就不是造假pass的理由啊，欸不是有给理由

没看清楚文就随便讲 你是想当反方训练辩论技能？XD

就可以合理造假耶。

mark之后关掉了　如果你不知道关掉的中文可以google关掉英文是close不是open/resolve也不是suspend

请依据楼主提供的资料 要扯什么其它的要有证据

第20行 mark成"无法复制"之后，关掉了看不懂中文?

close是楼主讲的啊@@

看不懂 帮你补中一下中国国学"之后"表示后面行动

不用扯了 ㄨ无条件信任那是没有的事情 说的若有其事

但不可能无条件不信任。这样是不可能执行多人分工。

mark后close就是我说的有说明 你是误解什么？

close issue会导致客户遇到bug谁close谁负责很难吗?

很多bug解题基本上都是尊重owner意见，因为owner才是专家，owner说是false alarm，原则上就先配合他要求调整。

AI都比你懂 要不要考虑让AI取代你

owner都说close了，死不信反而奇怪，除非你比他更懂。可以当比user还废的owner就真的过很爽，求贵家内推XD

劣币驱逐良币... 经典范例!

B 通知 A ，如果 A 不解，往上报让上层处理或许比较好？毕竟隔壁部门的人不是自己管的动的

某s应该是总经理 他要罚谁他爽 管他和合不合理 吞不吞的下去

如果你的客户直接从你的repo抓那很屌 内部管理真强而且我不一定是回应你 因为同时有两三个以上讲话 我又用手机 打的慢会断线过久直接close很常见 你这样解释那是你 ㄖ总经理这么大的官绝对不是我 如果是我就弄掉B没办嫉恶如仇 如果文内是真的没办法我

我的经历上造假close很罕见，但这个人际遇不同也没什么好吵，我觉得这是最大分歧点。A这个人我偏向不敢用，我无法信任他以后给出来的东西真假；B这个人我会提防他桶刀我，能不用当然也不用。

好啊 你弄掉B搞到全公司没人敢帮人家抓bug谁抓bug谁就扛责

如果他什么都没讲 那我今天就会改喷A 无法复现一听就

我只能说B是捅一个人，A是破坏整个制度；我隔壁部门有个同

首先要先确认制度 看下来是没制度 自然也没办法破坏

是有制度的，验证正确性和后续追踪。

b捅一个人破坏和平 破坏公司工作氛围公司内统来捅去我不相信做的好 除非重要的在少数人手

这倒不一定，顶多是氛围不好，内部竞争有其优点。

里 剩下的都是可有可无的人 这情况下也跟小丑没两样

A不签名 他能捅？

这不叫竞争 你有两个team做一样事情才是

内部竞争有时就会带来互捅啊。是啊，A不close的话这题正常就是一路烧上去，再不想配合也会被高层压着配合，不太可能直接炸到客户那。

这就是抓小辫子思维 今天没有这个事 ㄧ以后有其它事

很奇怪，到底出了什么问题。B可能没给够资讯，但A竟然就草草结案也不去跟B问问看

要捅人的绝对会守株待兔

老实说啦你不造假谁捅得到你XDB人品道德有瑕疵我绝对认同，至于A我是根本不敢用。

要竞争首先双方路线就要雷同 明明是合作搞成竞争哪能做好事情 本例就是你也是抓小辫子思维

又在讲大道理 果真是总经理

总比造假思维好啊XD

原因就写在那哪来造假 没看清楚就没看清楚

有看清楚啊，又不是有理由就可以合法造假XD

A不是真正元凶

close假在哪 不是finish好吗

有人下来压着A、B或更多人进来处理。

堆上去的才是

你这就在坳pass不是perfect一样...

不推上去自然不会炸

finish与perfect 不同等级好吗

那只是在玩文字游戏。你想讲的不就是写close不代表没bug了，是有人乱解读。但正常issue tracking系统不会让人这样误解。

A即便给你close 你上线总要验功能 不验或验一样还给

写上close通常就是这题已解，已经不是issue。

pass也如同close

close就是close 不是finish 不知道你说的是哪里来的

，然后就是相信A跟QA的验证，这完全是很合理的开发流程。嗯其实我没在issue tracking系统上看过finish。open、suspend、stall、close。

惯例 不能复现A还会推code上去？ 如果复现率不高，

finish或complete比较常在milestone tracking表上。

对啊以前就这样，然后呢？你想坳说以前就这样就不是bug吗XD

请问suspend、stall差别是？

高层可以喊suspend，先转移人力去解比较急的XD

这不就是mulestone XD

不是啊，milestone是project执行时间点。

不是 我是说如果现在复现率不高 以前复现率也不高

milestone和issue tracking不一样呗

一直有看啊你到底为何在意淫别人不看XD

是就是，不是就不是。runtime concurrency bug谁没遇过这种racing conditon没有解就是open著啦

它专案有很多新功能不是吗我是在解释不是你说的意思

如果有很多新功能，那更不能怪B了啊，整合者都忙死了谁晓

当然觉得你没看 ㄕ上下文还可以解释偏颇

这也不是理由 而且B认了不是你说的情况

一直跳针就不用跟他讨论了 牛鬼蛇神呀…傻眼

你说复现率 我回应了 ㄋ你对回应解释偏颇

不是啊我解释得很清楚，没有偏颇。偏颇不是先喊先赢欸XD从整个制度体系看，没有close，就不太可能量产给客户，更不会炸到客户。你先搞清楚根因在哪。

没有凹说以前的不是bug

还是贵司产品有bug也不解就直接出货？这个我也好羡慕QQ

MT用大企业思维的有色眼镜看待小公司惯例做法，有欠公允

我有解释了 ㄋ你解释这样是偏颇

你issue全清，我issue全清，我们都一样呗。辟啦。

我是说如果上线时测试复现率低 那A都没改 复现率一样不是你指的要凹以前没bug

重点是s都不用思考一下人家说的 自己讲自己的

你可以跟M说这句 我都有看 ㄉ但我无法用手机一次回应多人

我一直都有看啊，所以有些我也懒得回，际遇不同，我们没体验过彼此公司的文化，很难理解对方制度体系的认定差异。某程度上我满羡慕你说真的QQ只要出bug，owner自清是基本责任，再一路叠床架屋往上开发复杂feature、system。我也好希望我出bug时是上层的人要帮我解掉，我不用负责。

你可以不用再讲废话 看了都重复 还延伸一堆无关的所以我针对你随意解释那句说偏颇是真 你还反问哪里偏颇 没看就没看

虾，我有看啊，我那句是疑问你怎么解读。重复没办法啊，就我觉得满基本的道理你无法体会。

他根本没理解你说的 自己讲自己的

无问号有“吗”字 但你这就是任意解读 还放XD 有成见不用装

改扯成见了吗XD

我的回答就是复现率一样 你以前怎么测现在就怎么测

然后呢？这样就可以close吗？我觉得不行，你觉得可以，就认知差异啊XD

你们公司客户能接受你的说词是一回事，别家公司客户可不啊

那你说说不是成见 你那句有多少疑问成份在 不用装了

很大疑问啊，因为我觉得我们工作文化差很多。

真的是鬼故事

复现率是从B再测试延伸 不是当初close

原则上客户没有复现机率的概念，遇到就是一，没遇到就是零想多学学

所以又回到B的责任了，唉A的BUG，A说close，B的责任。

如何说服客户接受非零复现率的close issue

打开feature在close之后复现率不是0

今天没有B，送到客户一样会死，根因一直都是A的BUG...

你先听他说，feature只要不打开的复现率总是零

今天没有B A会更接近客户

但打开feature了

今天B没有放入feature，A跟客户会相近，没有BUG发生

又在乱辩了

feature是B之前就有了，之前复现率非零已知复现率非零，所以feature默认关闭，轮到B才打开可是只要feature存在，就会有可能造成BUG

会送feature关闭的load给客户吗@@？

复现率非0 关掉就没feature 是0

其实从制度上，A不要乱close，我的经验这题就会烧到上层，

所以关闭feature，issue可以close掉。叹为观之。

B更接近客户无庸自疑

人下来解这题，什么B不配合就都是假议题。

开发、客户、主管都同意关闭feature是吗？

还是是要求B workaround出一个既关闭feature又能运作的app只要A之外的人能有零复现率的workaround，是不是就解决了

A与QA都没发现问题 所以题目当然回到B B不续证那B脱不了关系 一来一回没下文说A是主谋 过了

复现率非零不就是问题吗？为何feature非打开不可

这东西哪有什么主谋不主谋啊，整天意淫欸XD

说B打开feature所以B有责任，关闭feature整合不了是谁责任

探究责任归属，不等于捅bug的人蓄意谋害好吗= =你搞错了，A有发现问题，但没能力解，这才是关键。

所以他一直想处理掉发现bug的人啊 逻辑一直绕

他知道有BUG，但自己无力解决，连复现都做不到，却选择造假close。

你们在说A主谋的 要翻上去看吗 什么A要负责都有说

主谋跟负责是同件事吗... 你当真？

让事情爆发不是A 是B 他自己也承认

我还是认为A责任比较重啊，他毁了整个制度系统的可信性。

那B是你口中的主谋，把B处理掉之后feature要怎么处置？

feature关闭，还是feature开启，二选一

除非你很肯定不开这个feature，但会卖不开feature的版本吗其实出BUG、炸到客户，我真的觉得还好。会让我怕的是造假文化，彼此之间合作失去信任。现在大型案子都要大量人力合

不是主谋负责什么？ 这件事B严重多了

作开发，不可能层层之间都全部review检查，需要靠qualitycheck画押后一路往下开发。A是最严重的，这种造假文化会完全破坏大型案子分工模式。

这件事B是主谋没错 犯最大错

A犯最大错，BUG在他身上却不解。

确实

另外A、B我都不会用主谋这个词。

不用扯造假 不仔细看 而且B承认了 得证

主张没清bug还close，要扛责是很正常的。至少在很多公司是这样认定。

A的责任在 面对B这样不愿提供环境资讯者 没有想办法拉高层级来解B的责任在 面对A这样摆烂直接把问题拉高层级到客户

无法复现跟close根本两回事，我知道你不在意诚信。

我在回应你不是回应他 懂？

但很多公司做事不是这样...我一再强调，A这行为很危险，会破坏整个制度。issue没解就是没解，没什么mark就算有解这种事。

ㄨ我不在意诚信？ 你们两个脑补真的很多 我只是不觉得close这种事可以无限上纲

没有无限上纲啊，我认为这是很严重的问题，他要扛责任。喔因为我记得上面讨论你说反正再开开关关就好没差，我觉得简直儿戏，完全无视这类系统的有效性。

话都你在讲 那你说说看close的意思啊 脸书按赞吗？

如果close不等于close，那open是不是也不等于open？上面的issue还有看得必要吗？反正都在乱写啊。

关闭issue 不是完成

关闭问题一般会解读成已解或已排除...唉，又绕回来了啦，一直鬼打墙。

你觉得楼主比较怨A还是怨B? 开开关关不是要频繁开关

楼主怨谁那是他的事情，我没兴趣。

同个issue好吗

你的工作环境不重视issue tracking，也不认为这画押的严重

那你脑补那么多做什么 看证据B事情比较大条

这边我倒不觉得not reproducible 不能是issue close的理

我没脑补啊，我根本没说过楼主怨谁欸= =

由 因为如果issue真的不存在或是已经因为其他人进的code刚好解掉都是有可能发生的. 有问题的地方在A去要环境资料而不得 这时不该直接以不能重现关掉

你讲的这个厘清也是已解啊。

那你告诉我这有法律依据吗 可以改来改去的你拿来当准

确认不会再现，false alarm都是解决的可能。

则

那就对了 那你以划押比喻做什么？ 就内部管理用会改的东西而已

就一个比喻说法而已啊。要用法律依据去否定一些文化，我是觉得挺可悲啦。摆烂装死其实都没有无反法律依据，唉... 但我很不赞同。

引喻失义 当然你都可以觉得这小问题

不，我觉得那些是大问题，是你觉得是小问题。

我是指你讲“就一个比喻说法”

哦那现在要偏题到说文解字了吗XD嗯我承认用词不当，不过大家懂意思就好。

引喻失义你不觉得很严重？ 我只是表达这意思 没有要

我不觉得有失义，就是法律面的用词没那么严谨而已。

你说文解字

"A很诚实的把自己的摆烂呈现在issue的close reason字段

去争论画押这词我觉得很无聊就是。上面有其他人用签名，意思也差不多，谁签谁负责意思啊。

这种东西法庭上当证据都不可以 完全可改的要可信度..

当证据可以啦 改了会有纪录

你确定要继续谈什么上法院认证？

我也只是说画押这词太重

很多东西不是法律可以规定的，你要摆烂什么无法可管。

所以现在改谈用词太重？画押这词本来就有点玩笑性质，怎么可能压身家财产，不过就是一种自觉和道德规劝，部分也带点施压自己的责任感。没有法律效力？废话。但也不是说这是儿戏，随便乱讲不用当

这我前面就讲了 当然要前后呼应 不要言论发散

真，无脑乱画押会让人觉得这种人靠不住、不能用。我是不理解扯什么法律效力干嘛。

有人会觉得跳针只是因为我不想脱离主题太多而已

扯法律真的跳针太大了= =

你都说画押这很重的词 我不能说法律 也不是我先开头

这就只是我职场上的习惯用语，反正交付品质保证的意思。我不觉得你不懂这用词啦，只是想偏题吧。

喔喔 要回来讨论"都不escalate" vs "直接escalate到客户" 哪个比较严重了吗?

明明针对楼主说的提出看法就好 还扩大到一些很奇怪的东西 什么都可以讲 拉回主题又说跳针

扯法律的是你欸= =上面还扯过什么跨部门沟通等于制度不完善，一直乱扯一堆怪东西。

你扯画押我不能扯法律 上面还扯一堆什么追踪status

我讲画押的意思是交付品质保证这件事...

是有人讲要A直接与B讲 ㄅ不是跨部是什么

你说的很严重 法律不严重吗

制度不完善根本扯不上关系，然后上面你抬杠了一堆XD你确定要继续谈法律问题= =？

你看你又来 上面讲一轮又来了 制度本来就函盖方方面

这个我不奉陪，因为真的太鸟蛋了，已经是在说文解字，很像

原po都说因为B自爆(态度问题)他才比较没事. 事后还是有人觉得原po护短. 其实这个故事的鬼是原po的team啊.

讲画押就只是交付品质保证的意思，我解释第三次，没有说是要上法院负责的意思啦，会用这词纯粹待过的公司很常用。完蛋我觉得你会跟我卢保证的法律效力... 干...

你不只画押这词很重 数落A close(画押） 都很重

因为我认为确实很严重。我也讲了，这个我懒得争，你待的环境不重视这种诚信，那是

谁要扯一堆？ 你们不来扯东西我就不用回应那些扯东扯

你的环境，不等于其他环境这样也很好。扯法律真的很好笑啊XD

平常工作很多用词都嘛开开玩笑，意思到就好，不是严格意义，然后你现在跟我扯法律问题XD

环境？什么环境？ 说你扯你还不相信 说法律当然是应

扯法律的话我真的要睡了，那部分我觉得你只是在抬杠。

对的内容 给我观感像法律

你想太多，我没那意思。

证据力不足硬要讲 脑补假设一堆 偏离主题 你的经历又不能套在楼主身上

你证据力就很足？你的经历就能套在楼主身上？

都不觉得这样会有误差

工作上bug没解还说没了本来就很有争议，好啦你又要说close不代表什么，开开关关也很正常。我认为有误差啊，我只能从现有证据去评论。

稍为理性一点吧 我前面都还在范围内你们扯到外太空

扯什么跨部门沟通等于制度不完善，要有法院效力的不是你吗？谁在扯什么外太空啊。

楼主都讲A不知的吗 都讲好几次了 然后一堆人扩大解释

我讲的论点一直是A处理的很有问题，甚至可能破坏制度面，然后画押这词被你抓着要我解释法院效力XD

半夜三点，抬杠停不下来。是爱吧？ 嗯，是爱。

我上班再回好了，真的是...

什么A是主要负责人 A才最严重 都觉得这里是不是有B或与B是同类的人 A处理有问题 但B 出大事

A是function owner啊这你不会不知道吧= =B出大事但我觉得根因在A，只怪替死鬼不太公平。真的是浪费时间扯什么法院效力QQ

谁重谁轻分不清楚... 意思就不是法律说的很严重像法律 废话当然知 他是一半专案的owner 都讲好几次 都当别人不知 爆出的是B 不是AB 真的要反映那反映主管就好 直接毁天灭地就是搞人这种做法是动不动就想教训人的特质

B没什么问题，有问题的是A和QA居然复制不出问题，人家都反映大bug给你，你们还找不到，找不到就要认命一点去找B一起讨论啊，我看A和QA都没亲自去找B详细讨论怎么复制问题吧，拉下脸也要去找B好吗，直接close是？？

复制不出问题要看问题点在哪 两个不同部门的都测不出B也没什么反应 至于拉下脸那很可能是B要的效果

在大家都不知道B是故意的情况下，不会认定B有错

这圆不了 B就算没说白 明明知道却还是让它上 代表就是没续验 免不了还是有责任 我看他是笃定他能留到最后 后面开始飘了 大头症B默认结果不会更好 这样老板会觉得下面联手坑他 这应该是计算过的最后楼主背锅 不是A不是B不是QA B主管好像神隐了...或者认为下面的都是废物

B如果没自己自爆责任就是在楼主跟A啊，很难懂吗lol，B要整合，要call A的function结果function有问题，A自己三个礼拜无法复现就直接close我是B我也是龟览趴火，状况就是明明有问题但是问题根源A不屌B，楼主qa重现不出来也不屌B，所以大家就一起下去不然B就变成那个卡大家绩效的机掰人，要不是真的客户端有问题我看B就被贴上一个能力差又难搞的标签，虽然最后还是得被楼主po在网络上嘴砲哈哈，真的是鬼故事至少看起来楼主的前老板还知道这件事的最大负责人是谁直接火了，笑死就算B想要的是A拉下脸去他那边看B的环境慢慢查找，A就得去，最应该积极解决这个问题的是A，直接close就是罪该万死，B只是做人机掰，跟我一样，虽然我是没机掰到敢让问题在客户那边爆炸就是了

都五点了居然还在吵... XD

别忘了是B commit B如果不commit事情不会发生 即便B找个好的理由替自己commit解脱 责任还是跑不掉 依照经验 有做事都不是升迁保证 你的做事是搞爆全部人说老板因为这样留他 A也有留只是后来肯定还有发生事情先走 B到最后也走了 所以你怎么说？

你说B的责任在B commit，但是B会commit是因为A close了啊lol，如果A close但是B 坚持操守不给commit，问题会从function有问题变成B在搞大家欸，B自己这个issue都因为A白白拖三个礼拜了，机掰如我只要function owner没问题，qa没问题，我自己也是commit上去啊，管它的哩

最后结果A/B考绩都是炸

那是因为B自爆啊，不然单论制度上来说B根本安全下庄当着qa的面说我就是想恶心A，那也无法

B除了commit还有其它选择 上面说了 就是搞人用的 B向上反映球就踢回去了

其他选择，如果你是说要拉下脸跨部门沟通，那是A要做的事喔，B唯一应该要做的事就只有回报A function的问题以及后面再配合A，A不来找他就不干他的事

你不讲那么多 总是会被问commut理由 你没发现别人最后最好是不会对你能力起疑

B的向上反应不就是楼主qa吗，看起来是有反应到阿，qa重现不出来是然后qa说没问题，B就不能再巴著这个问题不放了commit理由也很简单啊，qa说没问题就可以commit了不是吗....？

你哪里看的到B的主管是Qa?向上反映不同部门？.......

我没说B的主管是楼主，我是说这个issue应该是楼主负责，b反应给楼主就够了，如果b再反应给自己主管的话，最后如果真的是b自己环境问题，b是不是直接死去，为什么要为了一个卡了3个礼拜被owner close、qa说没问题的issue赌上自己在公司的评价，B又不是圣人

吃饱太闲，晚上8点吵到早上5点

说圣人好像不太对，应该说又不是傻子，不过最后自爆...好像说傻子也不为过XD

楼主怎么会知情...都后知后觉了还知情？

B就只有一个问题，在怎么不爽，知情之下，也不能故意让问题在客户那边炸掉，其他B其实没什么问题

搞错人了lol，我以为楼主是qa，我还是去睡觉好了

反映给B主管也是个好的选择 重点是B知道会爆又想搞人B知情会爆然后commit commit最致命 不commit搞不到人

你如果站在B的角度就会是，A把issue closed然后说无法重现，言下之意就是你自己环境有问题，然后qa也是一样结论，并且这个issue已经卡了三个礼拜，这个情况下你还要反应给主管继续卡，那是真的很惨

commit会被问原因 你找个好的理由都是过失

为什么你会绕回来这个所谓的 commit的理由再好都是过失，楼主都表明了B自己不自爆根本不会有事不是吗

这是双方摆烂 B等三个礼拜也很有问题楼主是这么想 ㄉ但谁知道他老板怎么想基本上我不信B是这么傻的人 明知道这样做自己也gg

双方沟通摆烂我认同，但是责任归属在A身上，没有一方要拉下脸合作的话，A必须去谁知道B有多傻，会自爆又找人代打卡丢工作lol

我觉得是向上反映上面的安排你不摸清楚规率你敢找人代打卡？ 只是最后抓包人生都有意外 我倾向于B是聪明的机掰人 活最久七伤拳使的好规律

哈哈哈 人的问题/官僚化/大家一起踢皮球囉!

B的问题比较偏向人格跟道德问题，但这种的才可怕

整串就一个人逻辑在异世界 你们居然也能吵这么久==

https://i.imgur.com/13sxjYW.png工程师连这么基本的东西都分不出来可以自尽了正常的任务管理系统close就是解决的意思除此之外就是不正常的公司 异常的人总以为自己正常

楼上你的close有法院认证吗？没有的话某人的公司不认的XD现实就是有那种做错但死不认，一直嘴我没犯法那种皮皮的。

不管上面吵了些什么,拿ChatGPT的回复当正确答案也怪怪的吧

人工智能与工人智慧

以前还遇过只有uat测试环境，每次都只能开发端测试完直上uat，然后就发现因为测试环境不一样有些东西还要微调。要个上uat前的sit环境来测试也没，老板反而叫工程师自己搞个测试环境。

拜托你们是一个Team耶，B那什么全天下都对不起我的脑袋你发现问题后，别人无法重现你不帮，ticket关掉你重开不通知，还选择直接release给客户？想跟所有人同归于烬吗

A也蛮雷的

A写的bug搞了整个团队，也是个奇才

怪A的code也不对，谁写code没有bug，不然要QA干麻？A错就错在没确认B的复制手法也无法复现，就擅自将issue close掉

虽然B太老实很白痴但如果仔细想想真的完全是A跟QA的锅B顶多只能算是使用者使用者回报了然后1.开放者A说没问题2.测试QA说没问题那你要B怎么办…?

大B哥 真牛 没解决直接close

A全责+1，issue close不能release其他issue也要比照办理吗？

A能力差 QA能力差加不负责任 B心态差加不负责任加反社会人格

有些需要特殊环境才能复制，甚至是机率性，A做法虽说不对，但是B更不应该，B如果有feature压力，应该跟pm说清楚把issue重新highlight

B是HL哥~

两个都是雷包，内部的恩怨搞到拖公司信誉去赔，客户没求偿？

鬼是你巴

B主要的问题是不愿意提供厘清环境的协助 release出去这件事反而是正常的

B太不懂人心了，这个就说“啊A关ticket，QA也验过，我想说可能我不懂或用环境设错吧”那这锅A跟原po就扛好扛满了。

推楼上，确实是如此

某K讲的就是基本概念 然后呢？ 假设别人不懂别人懂所以？ 容易忽略然后呢？ 假设大家都很规矩根本不可能拜托 一次三四个人在讲干话 我又用手机上ptt是能有多快 逻辑问题请你讲出来 那些讲干话的一堆逻辑问题你怎么不说？不愿意提供环境参数怎么会是小问题？ 这份code不会是

产线很多啊

A开始搞的 close问题才比较小 不要扯什么自动化与信任 无法保证的东西 自动化应该在容易自动化的地方MT就在扯嘛 什么法院认证？ 我都解释了那是对你画押的看法 到底谁逻辑不好？ 不要老是脑补别人没做的没说的

画押一词我解释了只是用语习惯，是你一直咬着要有法律效力，否则没意义。我只能说很多事不是只看法律面。

B老实？ 是不是没有看文 故意的老实？我不是解释了你说的很严重像法律 也只是个形容

我是觉得讨论职场的事情，你在那扯法院认证才有效真的很好笑。在我待过的公司造假close的确很严重。喔你又要说有mark造假没关系，鬼打墙啊。

所以你没看懂是吧 我的意思是没那么严重 你自己比喻不准别人比喻 排场真大 然后自动脑补别人没讲的

我也说了啊，你的际遇和环境，不觉得这种事情很严重，这是观点分歧原因。至于我工作环境，这种牵涉到诚信的行为很危险，也看过类

低端公司才会有低端流程 何必浪费时间吵

似案例造假验证pass，炸开后害一两百人被地毯式review，增加一堆工作量。

所以重点就是我没有要扯什么法院认证 看懂了吗 还整天拿这个说嘴 只是个比喻你怎么知道他真的造假？ 专案很多也很容易误点这种开发者可以自行修改的本来就很没保证 拿来自动化非追踪的更是可笑 你说你自动化追踪issue那可以 布

这B大概跟A有仇，而且可能也没想继续干了

署就多了 自动化另外一个人说的