針對上一篇還是有人在追殺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？叫挖洞吧？