针对上一篇还是有人在追杀B我就闲来无事重申一下问题点在哪里
很多人一直纠结于B有没有复测、B有没有去追这个Issue，我跟你说跨组合作不是这样搞
滴
首先要先搞懂这个Ownership的问题
原Po是Feature Owner
A是原Po组的写出有问题Code的Dev
QA在原Po组
B的开发建立在A的成果
再来搞懂开发流程的问题
A先开发
B开发需要A的change
B发现问题回开Ticket并把自己的Feature完成
重点来了，如果B的code 100%没问题，这里B已经完全不需要复测任何东西了，这个Issue
就是A组要解决，你QA测不出来锅也一起揹
举个最简单的例子（非当事）一样用AB来带入）
假设OS有个新API叫hundred()需要return 100
B要拿来用在feature上且在UT的时候假设这个API一定return 100所以UT 100%能测过，但
是上环境实测的时候发现有时候是99有时候是100，B开Ticket给A组说你这个API有时候是
99请解决一下，结果A组说他们怎么测都是return 100所以把Ticket关了且A组QA也说没问
题
讲到这，如果你还觉得B要去复测的话，那你应该叫B去把A组的Code也写完，因为B怎么知
道A组的Code竟然会跟环境有关或是跟环境有关但没有考虑到Corner Case(以原Po的例子
搞不好还不是Corner case，感觉是个Known Case)，要怎么知道你有没有重新commit过有
用的code才不能重现，要怎么知道Feature owner的code review没什么用抓不到问题，要
是B都知道这些的话那B应该才是feature owner不是个Principal就是准备升职的人还能让
你在这甩锅？

合理

因为这个社会需要和谐，所以不修饰言词的人，要背锅！

合理+1

没用 下面继续跳针

推

最初是说，A组认定是 corner case 所以才关掉的吧？

照你这种开发方式B根本不该测试实际接上去 也不该发Ticket因为他只要确保他那边对就没事了啊你自己开出来的ticket本来就要验证被关掉是否是真的解掉吧你怎么知道对方关掉是真的有理解并解掉你的问题

对方关掉还说你环境搞烂是一堆人无视还是怎样啊？都说你环境不可信了你在自己机器上再验fail能说明啥？没在客户那里炸开时A和QA认定他们环境才是好的，炸了后还要B来背锅这真是够扯…

你可能要回去看下原文，原po 是 application owner，B才是feature owner。B知道自己的feature有问题，是A的code造成的。A改过code后，他还是硬开出去，结果是B的feature 让客户爆炸。最后他说我的code部分是假设A code 没问题写的，我的部分没问题。但 feature有没有问题？我没再复测（至少表面上说没有）。这样当然会被惩处，B是 feature owner啊。A的code是改过再回来的，并不是跟前一次相同code。

A认为他复制不出来这个问题，肯定是B把自己环境搞砸了…这原po第一篇自己写的，当初A有这种心态就已经决定会在客户那里炸开的结果了，因为A当下已经认定这不是问题，而是B在乱！

B如果可以不用测，那专案里大家都各自开发各自的就好，同理，就算你不是用同事的code，而是引用任一个公开函式库。当函式库更版时，你可以说“我假定函式库都是正确的，只要我的call function code正确，我不须要重新测试。”吗？不管A/B关系多恶劣，B是feature owner，至少你要保证你交出去的东西在你local是run正常的。你都run不正常或没run就交，本来不是你的锅也变你的锅。

我看不懂的点是：为什么B开的ticket，A的人会有权限可以close。我用过的issue/ticket管理系统都没这种设计。

有点腻了，事主全都离职了，在继续检讨谁对谁错根本没有意义，每个人都有自己认为对的流程，谁都说服不了谁，反正自己能用就好。在网络上想讲到赢？D大你看不懂正常，有些公司IT权限是直接洒出去的，很扯对不对，但是就是有

A是以无法复制关闭问题，不是有改code来关闭问题啊，这部分我是对原po叙述有所怀疑啦，你有patch根本不用拿无法复制来关闭，直接请B测试patch才对不是吗？

这边经典 鸡同鸭讲

所以你开ticket出去之后 别人认为你在乱把它关掉 你就摸摸鼻子不管承认自己是来乱的?

依照原po叙述B是feature owner没错，但A与QA运作正常基本上已经帮他证明整合没有问题了，A还认定B搞烂环境，那B也不能再用自己的环境去验不是吗？

蛤？依赖有问题表示自己的feature的output也是错的。这样也能不确认就发布？

如原po说的，B还有别的feature在忙，连机器都没办法借了，难道B要放下其他开发工作来debug？B是RD不是QA啊…当初原po找B主管谈完也觉得自己有QA可以自己处理

以后自己测出的issue被关掉还要再三跟assignee确认是认真解完关还是乱关的是吗

原PO有和A改过一版重送，不管有没有修到Bug，B说他没测有新 code 送过来，B是feature owner 不管怎样都有义务要重测，因为你freatue的成果会受这段code影响。bug被关掉你可以不测那bug，但至少要测完你自己的feature在新版是不是正常吧。B先说他知道feature有问题，但硬送；后来改口说他根本没重测，不管哪种说法都有问题，轻重程度不同而已。说极端一点，就算A台面上说他改版只改了注解，B还是有义务要测。你自己feature output有问题了，即使你认定是A害的而且他摆烂，B就要想办法，因为“B是RD不是QA”啊，不是回退就好，feature owner负责feature成败，一如原 PO是application owner负责整个专案成败一样。

想请教一下，有没有通俗解释 features owner application owner 和 function owner 的差别和执掌

现在要变成QA跟RD大战了吗

如果你的工作环境接受开issue后再送一版，然后那个版本可以不管bug有没有修好的话，那我也只能尊重了

很明显权责不明，一边是整合却只own application，一边是专案owner却只own底层api一边要application包kernel的包，一边要api包feature的包

可见这世上多的是B

你举的例与原po的是不一样的 B确认就是100% A确认是0% 没有一下子多少一下子多少的状况B的复测与A的code是一点关系都没有 B身为整合的人也确实应该再续测 然而没有就commit

不多嘴的B其实很正常，因为多数人不喜欢乌鸦，你不是bugowner且无法确定问题怎么发生的这时候通常就是以bug owner判断为主，毕竟那里的code是A写的不是B，而且在A甚至QA的环境运作都正常，A还认定B搞砸环境，既然没有互信基础那就都照对方意思处理

所以没有互信产生的错本来就是要各自背 而不是推责任只是B在这事件十分严重

原po第三篇的推文中有提到"B的主管是认为我们要自己复制+QA帮忙，他的说法其实也合理"，从这里我认为原po部门已经打算接管整个问题了，所以后续A那些改动也没找B复测，原po自己在第二篇也说最后卡关的条件就是QA大规模测试无法复现，那出事后又要把B打成是故意commit这根本不合理

这只是事后想法 但就是没这么做阿 我是很不明白为何原PO要替人自圆其说还要替自己忿忿不平 B的问题就是

A后来的改动能通过自己与QA的测试基本上就是B已经把整合好的code提供给A与QA，否则A有任何改动都是要B来验证怎么会自己和QA就可以验？

身为整合者没续测就commit 事后供词证明是故意的 这合乎现实这就是原po被B主管唬烂到了 证明B主管也想推事情

原po第二篇谈到第二个错误这里讲的应该是原po与B主管谈完后自己部门处理bug的经过，很明显完全没有B的存在，甚至原po这时也不觉得B该存在…

你觉得他讲的第二个错误讲述无法复现是真的错误吗？那只是部门内续验找问题 当然与B无关综合推论就是原PO被B主管pua了

B故意commit也是他自己承认的，不是人家栽赃给他后来找问题当然不需要B，直接去爆掉的客户环境更准确原PO描述的权责应该很清楚，整个 application 的owner是他，这个appliction里有很多 feature，其中一个fea的owner是另个部门的B。B的feature需要call的kernal或 function owner是A。只是职位上原PO跟A是同部门。A code 自己UT没问题，但B 整合完自己UT有问题，怪A那就是A/B要合作找问题，A找不出问题直接影响的是B

你在AWS也是像B一样吗

笑死，管你跨组合作怎么搞，现实就是炸掉啊。

后来找问题当然不需要B，然后问题关闭是B环境搞砸，因为A和QA没问题，那B commit是故意了什么？你当下A部门根本没给B不要commit的选择好吗…前面B无法配合时原po找B主管碰了软钉子，但原po也认同自己有QA可以自己处理，结果A部门处理了三个礼拜后关掉bug原因是无法复制，B继续卡著不上那才叫故意好吗…然后呢？两部门打一场决定该不该上吗？

因为B不相信A/QA没问题还commit 你是怎么得出B相信B妥协的？ 不管最后有没有测 B都是清楚还有问题 没测

你要拿B承认故意来嘴也先看看B当时有没有卡著不上的选择好吗，环境被A说搞砸，那他复测fail能代表什么？拿这理由继续卡A部门会同意？

测就commit很有问题 B测了不管是否有测出但B曝露意图了就是有问题B是有卡著不上的选项阿 怎么会没有 这事件哪个人逼他上？他没有复测不是吗整合的人节奏在他 他决定先不上有理由别人也会先放著

撇开一般公司里bug根本不该由A来关闭，A部门如果不想feature release最简单就是bug先不关继续查，当时真认为B知道问题，B在忙别的开发看是要等还是HL到大老板去，现在看我只觉得当时A部门对这个bug根本不太在意，对自己部门debug能力信心爆棚，甚至最后觉得B乱开就关了bug，是客户炸了后又被B嘴贱火到才回头怀疑B搞你，主责可以搞到一堆人来骂B，原po目的也已达成

信心爆膨的是B A是有信心环境问题 确实也是环境问题

还有，bug owner不是固定的，A认为他无法复制没有事情可以做了不是只能关闭bug，而是应该把owner转回B请B复测或提供更详细步骤，但A是把bug关闭，原因就是A肯定是B搞砸环境

A就没讯息找不到是要从哪生出原因... B除了一开始开issue在意过什么时侯在意过这bug...从文内没看出来对debug信心爆膨 信心爆膨应该在close时写没这问题 无法复现不是没问题B就不是嘴贱 是掏心掏肺当然这部份被原po cover掉 后来原po越想越不对劲不爽A/QA都测不出当然有其它因素 卡三周B都没提供详细资料是要怎么继续...文内无法证明B嘴贱的 这是你们的自由心证

原PO就说Bug关闭和B要验测要当成两件事分开究责，bug关闭但是 A code 更新的，B就是要验测。B现在是明知自己code会跟着一起爆炸，不管他有没有真的测过，他的责任就没尽到了。

他code 能跑吧 唯一一次不能跑不也是误打误撞

根据他自己的说法，他第一版只测一次就爆了第二版完全没测就放行。根据原PO怀疑他自己承认的实情可能是，他第一版测多次(正常工作流程)100%爆掉，第二版也是测多次(正常工作流程)确认没修，但刻意commit要HL A(本人说法)不管你相信B哪种说法，他都是故意放过code了，免不了责而且这个测试不是对A code UT，而是自己的 feature UT

不能跑怎么能merge跟过度QA那关 神奇只是说干话吧 自动测试也会跑整个flow

流程上来说qa验能过的话，b有没有复测不应该是问题的焦点吧，尤其是被认为说自己环境搞砸，又只是个支援仔的情境下

同段code在B local会fail，在A/QA 环境会过啊

我自己收到的单子没有请开单的人测试ok根本关不掉，应该说就只有开单的人可以关，A这个可以自己关单的动作才是整个流程上最失败的点吧

B现在被惩处不是没复测code，是自承feature UT没作

这个问题会发生应该是因为一开始就没确认好环境问题，测试机跟客户的环境不完全一样，再来就是A拿到的单他可以自己关....你要说B也是个点我不反对，但我觉得以B的角色没有能力挡住这个问题的话他就不该担责，b开给a的问题单能被a自己关掉我自己可以想像b的心态会有多炸裂，不复测是个点但严重性没有比上面两个高，毕竟后面还有qa背书话说我之前回过superpandal一大串，跟他说A卡三周的时间里是是A要负责找B乔环境，现在看来他还是认为B是那个要负责的角色lol

A部门要对整个专案成败进行负责，会认为专业分工下B部门本来就要调查清楚未知问题且完整揭露讯息。可是B部门要有A部门的才有的东西根本拿不出来，情况就僵在那了A部门的二元矛盾是做之下的api也做整合之上的专案领导

B不会没有能力挡住 是整合的人 B也不是只是支援 卡三周本来就一来一往没下文后来close 一来是B发现有bug开issue 一往是A测了发现没问题 QA测了也没问题 后来B因为其它事情将这需求暂缓 三周没下文 当然是延续上B要找A 怎么会变成A要找B... A部门也不是天神知道一有这问题...你讲因为A拖三周就不是事实 是A发现没反馈三个礼拜之后close 后来B也没有要继续的意思 直接让它爆炸

楼上大哥您要不要直接回一篇？

A发现B回馈不是找qa找B主管而是直接关掉issue你觉得没问题喔....成败是A的部门负责却要B死硬尽责的卡住feature，要B顶住压力硬卡他根本不知道实作细节的东西，要是真的是B的环境搞烂之后B以后怎么在这公司工作，直接被贴一个能力差又固执机掰的标签

B不主动反馈也没问题吗 为何A还要为了B不反馈而主动扛责的是原po 不是整个A部门 以懒惰程度来说是原po大于B大于A B根本不需要处理A的repo 提供自己的所知和确认自己写的没问题就可以 这篇没有看出来哪些人能力差 只是有这可能 这个问题A就未知他是要怎么确认这问题真实存在 A觉得是环境问题不就可以说明了 确实也是环境因素没纳入考量

这个问题A接收到了，A有"责任"去“主动”厘清B的环境相关问题，并不是B不合作就可以直接close，如果要做到你认为的B责任大于A，那么A在close的时候就必须有B的点头或qa的点头懂吗

B能够继续在公司你没在看 因为原po保住了B 让A与B惩罚相同

原po保住的是A吧，自己收到issue自己关，公务员收到公文可以自己盖章吗lol

开发不是这样的 A主动去问那是A超级认真连不是他必须要做的都做了 回报bug原本就要主动提供测试讯息你就是没在追原po后来说的 原po保的是B 因为从刻意爆炸往低级错误判 当然是保了B A没人保阿 close不close本来就不是爆炸点B是因为统整的人外加他利用盲区整人牵连全部人我认为严重的多 当然究责楼主gg

B只知道A的程式码有bug，根本不知道是哪边有问题不是吗，为什么你讲的好像B提交bug的时候就知道是Lagg什么的的因素结果隐瞒不说，出问题的是a的程式码，bug也提交给a了，然后你说要主动的人不会是是a....？

我上面不是讲过了 你到底有没有在看 B根本不需要管A的code 提供测试讯息就好 最后也证明是环境问题我讲这个已经从第一篇讲到现在你还在状况外...A都写无法复现外加B自白想要highlight 当然是没解决

状况外的是你吧，b要怎么给整个环境讯息，你以为b在公司测试机上coding喔...

B测试到了提供他自己的测试资讯很难吗

况且b就是“故意”不给讯息，a也不能close阿....这很难懂吗

提供他自己电脑上配置资讯就可以 你讲这个真的好笑

你的意思该不会是b测试到bug之后，不优先认为是a的code有问题而是自己环境跟a不一样，所以自己先测试环境因素，然后找到是lagg这个再搞，再提供给a吧....

你没限制close 外加有写原因 A与B都知道问题没解决我可没这样认为 而是测到bug 提供测试资讯本来就是应

阿...所以测试讯息要提供到什么程度，你说电脑上的配置资讯...大到os，小到使用套件，怎么给...我自己是觉得给到套件就差不多了啦...而且，就算b没提供测试讯息，也是a要串资源去弄到阿...还是你的逻辑是bug发现者不提供测试讯息，比bug处理者自己关掉bug严重

lagg阿 这部份B没提供不是吗 包含在你说的在内 系统只要提供粗略的就可以 A不知道客户用laggb没提供讯息最好是能准确验证这bug真假 你这是在假设A神通广大不提供讯息基准不劳严重多了 close本来对于专案就是小事

大哥...我说的是a有责任串资源去找b厘清好环境，怎么变成我说a应该要神通广大了....

a没这责任阿不是吗 ㄕ上面已经解释你下面又在讲 A与qa都测不出B不应该反思一下问题点]?

你对a没这责任的解释是，bug的close本身对专案来说是件小事..!!？？ 抱歉我没法站在你观点下思考了..

A与QA测没有球就已经踢回B了 B不看看环境有什么不同

我觉得b本来就没办法完整提供整个环境，包含使用到lagg这个东西...所以不能说b不提供，整个环境本来就是要慢慢盘，阿b没时间不想屌，a如果重视的话就应该call更上面的层级，但是既然你说close对专案来说不重要，那a直接close也很合理...大概...哈哈哈

还要A去问他？

我意思就是a要去问他啊zzclose不重要的话，a当然也不用主动去问了，毕竟直接关掉多省事

我说的责任不是你说的 你这没看懂就归纳球就已经踢回B了 B没自觉就算了还要A主动？ 这不是B要再续查的责任 怎么会是A...不就是B要续查B不想屌都过三周A close很正常 谁知道是什么原因

我不认为a跟qa测过没问题，责任就回到b身上欸，如果是我是a，我就是直接叫qa或更上面的人帮我乔，反正我就是要弄到b的环境，我不会自己close....要close也要qa点头，那责任就跑到qa身上，a就无责

不然呢 B发的Bug后来别人验不出你说这责任不是回到B?b是已读不回 那是认真的A会做的事情 以这事件来讲A不

你这个逻辑不就变成被提出来的问题解决不了责任就回到提出问题的人身上了吗...

做这事不算错B说有Bug A与Qa都说没有不就B要再确认b要再确认是否有这问题和测试资料提供close就没得到回应才close附上原因很难理解吗

正常的流程没得到回应也不会close，就是一直摆在那，直到他解决....

你说的正常流程不会是通则 这还是以经验套入的结论

所以你的经验才是通则囉，因为你能把责任推到b身上关键就是close并不是一个多大的问题，但显然我跟其他很多推文并不这么认为

两个状况都不是通则 这你看懂了吗 我讲的当然也不是

你认为你的经验也不是通则的话，你为什么要用一堆推文究责b啊，因为我是认为issue处理的人不能自己close是通则我才花时间跟你讨论欸，如果基本认知就不一样难怪责任厘清的方向差这么多 ㄎㄎ

通则是指close这件事 其它的我是推论出来的 我早讲过除非有其它当事人跑出来否则就是这个结论不能自己close是合理的并且B应该先限制但不是通则这也是我当初讲的照理说就应该限制人close你以为我爱乱讲B错很大 就是因为种种迹象推论表明B真的错很大我才这样说

楼上大哥您要不要直接回一篇文

楼楼上自己发一篇吧 每篇都在跟人家吵一大串

我蛮好奇如果是一般user跟rd说 我刚刚一连串的操作有出现奇怪的讯息，你们要不要检查一下，然后rd会请user完整记录过程吗？会请user多方测试吗？虽然我个人都会说你先重开机看看…颗颗

我才不要 0发文记录非常好楼上讲的是很通常的应对 不少人都会这么做

air:会，而且是一定会。不厘清问题状态很难盲追问题。你开case到所有系统原厂，对方客服默认回信就是跟你确任环境和描述问题。

那user事后测不出来，或者没环境（测试资料）测，也没看清楚当时奇怪讯息（可能是是稍纵即逝的画面），请问rd就算了吗？

你会拿到release之外的debug二进制位元档，或者cli下带参数开关-v或--verbose，然后请开发人员分析结果

管你谁的错 你东西没好 就release给客户 最好是这样OK再怎么推卸责任也没有用 就算今天真的是A有问题 你是B也不能用这种方式highlight问题你要不是动用政治关系去乔 不然就是写报告说这全是A的问题所以时程要delay请客户等 等不了上头来问就说是A的问题再怎么样 处理方式也不会是把东西直接release给客户我打个比方啦 你开一家餐厅 进了原料 原料被污染 你做好试吃 觉得有怪味 问厨师 厨师说是原料商的问题 但原料商不认所以厨师还是把料理出给客人 客人吃了食物中毒死掉了你他X的餐厅还要开 你今天做的软件 刚好也不是什么会影响生命安全的 你去试试看医疗系统或飞行系统你这样搞看看乱七八糟胡说八道 混过亚麻还这种程度 可悲到一个不行上面那厨师跟你说 啊我就是要highlight这问题所以直接给客人吃啊有什么不对 你看你餐厅还要不要开啦出事只知道甩锅 可悲

你这个举例就有问题，这是餐厅出一道汤料理，你做汤底我做内容物，结果你汤底有问题我提出但你说没问题，然后你的好朋友厨师也说没问题，最后迳自出餐被退货，我说一句我就觉得有问题，你最多说我马后炮而已我责任在哪？今天我可以连汤都不喝只管我内容物没问题呢。而且一直纠结于B让release放行，就很跳针，一个Dev能一个人决定让Code release?笑死难道A,QA,原Po不同意放行？那今天开飞行系统医疗系统写烂code发现不了的A在干麻？让release过的QA原Po在干麻？退一百万步来讲，假设他认真是知道有问题还放行也可能是他就不是做医疗系统飞行系统阿，类比的乱七八糟还想战...

你要自行脑补故事请便 软工板变小说板 B是亲自出餐的那个出事后还自己承认我知道有问题我就是故意让客人吃有问题的东西来highlight问题 这你觉得OK喔 我的老天B今天死不出餐 或出餐吃死人之后装无辜 都没他的事喇自己承认自己专业判断上这东西有问题还故意出 这才是问题认真知道有问题还放行不是问题 认真知道有问题放行出问题还承认自己本来就知道有问题 故意放让飞机掉下来highlight问题 你看看你有没有责任啦重点是 东西是“你出的” 你要是不知哪来的三方也就算了然后你自己仔细看 我从来没说A跟原PO没任何责任我说的是 你根本还是完全搞不懂B的“问题”出在哪 XDDD今天B装死或打死不发 最后其它人发了 爆了 就是个寻常的A出bug QA没抓到 原PO团队疏失放有问题的东西给客户 啊这个大如微软苹果的OS 小到某个三方套件都马稀松平常 笑死人但B是自己发 爆了 还承认知道有问题我就故意炸客户 这图的是什么？牺牲客户 来证明你的论点没错吗？这情商跟三岁小孩差不多今天公司要是B开的 那随便你阿 但你B是老板吗？做这种牺牲公司利益成全自己的事 你觉得你能活吗 笑死耶被杀头刚好而已啦 甚至我觉得老板是可以提告的 但今天没出人命也就算了历史这种专业人士判断母汤 但公司硬上的案例满街都是好吗之前泰坦号工程师不也是专业判断潜水艇迟早出事 啊老板说没问题 那工程师做了啥？就离职阿不然勒 难道他会留在团队等泰坦号内爆死一堆人 然后出来对记者说 看吧我早知有问题啊我就是故意放老板去搞 让他出事 highlight问题 哈哈哈有这么低能的 世间也是少见

这个举例就... 首先该客户吃法就要很特殊 而这个只有少数人知道 例如煮面的刚好知道了 觉得煮汤的要解决这问题 以免被客户嫌难吃 然而煮汤的测了半天还是没发现问题出在哪 明明就很好吃 刚好该客户是某大人物

这个跨组合作的定义就是问题 知道有问题还出给客户叫HL？叫挖洞吧？