看板 Soft_Job作者 handsomeLin (NickLin)標題 Re: [心得] 我在科技業遇到的鬼故事之一時間 Fri Jul 28 15:12:59 2023
針對上一篇還是有人在追殺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就是準備升職的人還能讓
你在這甩鍋？
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 172.58.88.43 (美國)
※ 作者: handsomeLin 2023-07-28 15:12:59
※ 文章代碼(AID): #1amsf-VX (Soft_Job)
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1690528382.A.7E1.html
※ 同主題文章:
… ×10
Re: [心得] 我在科技業遇到的鬼故事之一
07-28 15:12 handsomeLin
→ airtsubasa: 因為這個社會需要和諧，所以不修飾言詞的人，要背鍋！2F 07/28 15:47
→ antpro: 最初是說，A組認定是 corner case 所以才關掉的吧？6F 07/28 17:02
噓 lylu: 照你這種開發方式B根本不該測試實際接上去 也不該發Ticket因為他只要確保他那邊對就沒事了啊
你自己開出來的ticket本來就要驗證被關掉是否是真的解掉吧你怎麼知道對方關掉是真的有理解並解掉你的問題7F 07/28 17:03
推 wmtsung: 對方關掉還說你環境搞爛是一堆人無視還是怎樣啊？都說你環境不可信了你在自己機器上再驗fail能說明啥？沒在客戶那裡炸開時A和QA認定他們環境才是好的，炸了後還要B來背鍋這真是夠扯…11F 07/28 17:13
推 luciferii: 你可能要回去看下原文，原po 是 application owner，B才是feature owner。B知道自己的feature有問題，是
A的code造成的。A改過code後，他還是硬開出去，結果
是B的feature 讓客戶爆炸。
最後他說我的code部分是假設A code 沒問題寫的，我的部分沒問題。但 feature有沒有問題？我沒再複測（至少表面上說沒有）。這樣當然會被懲處，B是 feature owner啊。A的code是改過再回來的，並不是跟前一次相同code。15F 07/28 17:22
推 wmtsung: A認為他複製不出來這個問題，肯定是B把自己環境搞砸了…這原po第一篇自己寫的，當初A有這種心態就已經決定會在客戶那裡炸開的結果了，因為A當下已經認定這不是問題，而是B在亂！23F 07/28 17:24
→ luciferii: B如果可以不用測，那專案裏大家都各自開發各自的就好，同理，就算你不是用同事的code，而是引用任一個公開函式庫。當函式庫更版時，你可以說「我假定函式庫都是正確的，只要我的call function code正確，我不須要重新測試。」嗎？
不管A/B關係多惡劣，B是feature owner，至少你要保證你交出去的東西在你local是run正常的。你都run不正常或沒run就交，本來不是你的鍋也變你的鍋。27F 07/28 17:25
→ DrTech: 我看不懂的點是：為什麼B開的ticket，A的人會有權限可以close。我用過的issue/ticket管理系統都沒這種設計。35F 07/28 17:27
→ Lhmstu: 有點膩了，事主全都離職了，在繼續檢討誰對誰錯根本沒有意義，每個人都有自己認為對的流程，誰都說服不了誰，反正自己能用就好。在網路上想講到贏？
D大你看不懂正常，有些公司IT權限是直接灑出去的，很扯對不對，但是就是有37F 07/28 17:28
推 wmtsung: A是以無法複製關閉問題，不是有改code來關閉問題啊，這部分我是對原po敘述有所懷疑啦，你有patch根本不用拿無法複製來關閉，直接請B測試patch才對不是嗎？42F 07/28 17:38
推 giacch: 這邊經典 雞同鴨講45F 07/28 17:38
→ lylu: 所以你開ticket出去之後 別人認為你在亂把它關掉 你就摸摸鼻子不管承認自己是來亂的?46F 07/28 17:43
推 wmtsung: 依照原po敘述B是feature owner沒錯，但A與QA運作正常基本上已經幫他證明整合沒有問題了，A還認定B搞爛環境，那B也不能再用自己的環境去驗不是嗎？48F 07/28 17:46
噓 s06yji3: 蛤？依賴有問題表示自己的feature的output也是錯的。這樣也能不確認就發佈？51F 07/28 17:49
推 wmtsung: 如原po說的，B還有別的feature在忙，連機器都沒辦法借了，難道B要放下其他開發工作來debug？B是RD不是QA啊…當初原po找B主管談完也覺得自己有QA可以自己處理53F 07/28 17:49
推 q253upng: 以後自己測出的issue被關掉還要再三跟assignee確認是認真解完關還是亂關的是嗎56F 07/28 17:59
推 luciferii: 原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負責整個專案成敗一樣。58F 07/28 18:34
→ justfortest: 想請教一下，有沒有通俗解釋 features owner application owner 和 function owner 的差別和執掌71F 07/28 19:26
推 q253upng: 如果你的工作環境接受開issue後再送一版，然後那個版本可以不管bug有沒有修好的話，那我也只能尊重了74F 07/28 19:50
→ labbat: 很明顯權責不明，一邊是整合卻只own application，一邊是專案owner卻只own底層api
一邊要application包kernel的包，一邊要api包feature的包76F 07/28 19:54
→ superpandal: 你舉的例與原po的是不一樣的 B確認就是100% A確認是0% 沒有一下子多少一下子多少的狀況
B的複測與A的code是一點關係都沒有 B身為整合的人也確實應該再續測 然而沒有就commit80F 07/28 20:21
推 wmtsung: 不多嘴的B其實很正常，因為多數人不喜歡烏鴉，你不是bug owner且無法確定問題怎麼發生的這時候通常就是以bug owner判斷為主，畢竟那裡的code是A寫的不是B，而且在A甚至QA的環境運作都正常，A還認定B搞砸環境，既然沒有互信基礎那就都照對方意思處理84F 07/28 20:24
→ superpandal: 所以沒有互信產生的錯本來就是要各自背 而不是推責任只是B在這事件十分嚴重89F 07/28 20:31
推 wmtsung: 原po第三篇的推文中有提到"B的主管是認為我們要自己複製+QA幫忙，他的說法其實也合理"，從這裡我認為原po部門已經打算接管整個問題了，所以後續A那些改動也沒找B複測，原po自己在第二篇也說最後卡關的條件就是QA大規模測試無法復現，那出事後又要把B打成是故意commit這根本不合理91F 07/28 20:36
→ superpandal: 這只是事後想法 但就是沒這麼做阿 我是很不明白為何原PO要替人自圓其說還要替自己忿忿不平 B的問題就是96F 07/28 20:39
推 wmtsung: A後來的改動能通過自己與QA的測試基本上就是B已經把整合好的code提供給A與QA，否則A有任何改動都是要B來驗證怎麼會自己和QA就可以驗？98F 07/28 20:40
→ superpandal: 身為整合者沒續測就commit 事後供詞證明是故意的 這合乎現實
這就是原po被B主管唬爛到了 證明B主管也想推事情101F 07/28 20:41
推 wmtsung: 原po第二篇談到第二個錯誤這裡講的應該是原po與B主管談完後自己部門處理bug的經過，很明顯完全沒有B的存在，甚至原po這時也不覺得B該存在…104F 07/28 20:48
→ superpandal: 你覺得他講的第二個錯誤講述無法復現是真的錯誤嗎？那只是部門內續驗找問題 當然與B無關
綜合推論就是原PO被B主管pua了107F 07/28 20:50
推 luciferii: 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找不出問題直接影響的是B110F 07/28 21:04
→ bitcch: 你在AWS也是像B一樣嗎118F 07/28 21:47
→ darkMood: 笑死，管你跨組合作怎麼搞，現實就是炸掉啊。119F 07/29 05:49
推 wmtsung: 後來找問題當然不需要B，然後問題關閉是B環境搞砸，因為A和QA沒問題，那B commit是故意了什麼？你當下A部門根本沒給B不要commit的選擇好嗎…
前面B無法配合時原po找B主管碰了軟釘子，但原po也認同自己有QA可以自己處理，結果A部門處理了三個禮拜後關掉bug原因是無法複製，B繼續卡著不上那才叫故意好嗎…然後呢？兩部門打一場決定該不該上嗎？120F 07/29 08:43
→ superpandal: 因為B不相信A/QA沒問題還commit 你是怎麼得出B相信B妥協的？ 不管最後有沒有測 B都是清楚還有問題 沒測127F 07/29 08:57
推 wmtsung: 你要拿B承認故意來嘴也先看看B當時有沒有卡著不上的選擇好嗎，環境被A說搞砸，那他複測fail能代表什麼？拿這理由繼續卡A部門會同意？129F 07/29 08:58
→ superpandal: 測就commit很有問題 B測了不管是否有測出但B曝露意圖了就是有問題
B是有卡著不上的選項阿 怎麼會沒有 這事件哪個人逼他上？
他沒有複測不是嗎
整合的人節奏在他 他決定先不上有理由別人也會先放著132F 07/29 08:59
推 wmtsung: 撇開一般公司裡bug根本不該由A來關閉，A部門如果不想feature release最簡單就是bug先不關繼續查，當時真認為B知道問題，B在忙別的開發看是要等還是HL到大老闆去，現在看我只覺得當時A部門對這個bug根本不太在意，對自己部門debug能力信心爆棚，甚至最後覺得B亂開就關了bug，是客戶炸了後又被B嘴賤火到才回頭懷疑B搞你，主責可以搞到一堆人來罵B，原po目的也已達成138F 07/29 09:21
→ superpandal: 信心爆膨的是B A是有信心環境問題 確實也是環境問題145F 07/29 09:31
推 wmtsung: 還有，bug owner不是固定的，A認為他無法複製沒有事情可以做了不是只能關閉bug，而是應該把owner轉回B請B複測或提供更詳細步驟，但A是把bug關閉，原因就是A肯定是B搞砸環境146F 07/29 09:32
→ superpandal: A就沒訊息找不到是要從哪生出原因... B除了一開始開issue在意過什麼時侯在意過這bug...
從文內沒看出來對debug信心爆膨 信心爆膨應該在close時寫沒這問題 無法複現不是沒問題
B就不是嘴賤 是掏心掏肺
當然這部份被原po cover掉 後來原po越想越不對勁不爽A/QA都測不出當然有其它因素 卡三週B都沒提供詳細資料是要怎麼繼續...
文內無法證明B嘴賤的 這是你們的自由心證150F 07/29 09:34
推 luciferii: 原PO就說Bug關閉和B要驗測要當成兩件事分開究責，bug關閉但是 A code 更新的，B就是要驗測。B現在是明知自己code會跟著一起爆炸，不管他有沒有真的測過，他的責任就沒盡到了。
B 不該 commit 的最大理由就是他自己code沒法正常跑。後來也是確認了B惡搞，只是惡搞程度從嚴重改成輕微而已從「故意放過」改為聲稱「故意沒測」而已。159F 07/29 09:57
推 Beramode: 他code 能跑吧 唯一一次不能跑不也是誤打誤撞166F 07/29 11:15
推 luciferii: 根據他自己的說法，他第一版只測一次就爆了
第二版完全沒測就放行。
根據原PO懷疑他自己承認的實情可能是，他第一版測多次(正常工作流程)100%爆掉，第二版也是測多次(正常工作流程)確認沒修，但刻意commit要HL A(本人說法)
不管你相信B哪種說法，他都是故意放過code了，免不了責而且這個測試不是對A code UT，而是自己的 feature UT167F 07/29 12:49
推 Beramode: 不能跑怎麼能merge跟過度QA那關 神奇
只是說幹話吧 自動測試也會跑整個flow174F 07/29 14:55
→ qazwsxedc597: 流程上來說qa驗能過的話，b有沒有複測不應該是問題的焦點吧，尤其是被認為說自己環境搞砸，又只是個支援仔的情境下176F 07/29 15:33
推 luciferii: 同段code在B local會fail，在A/QA 環境會過啊179F 07/29 15:34
→ qazwsxedc597: 我自己收到的單子沒有請開單的人測試ok根本關不掉，應該說就只有開單的人可以關，A這個可以自己關單的動作才是整個流程上最失敗的點吧180F 07/29 15:35
→ luciferii: B現在被懲處不是沒複測code，是自承feature UT沒作183F 07/29 15:36
→ qazwsxedc597: 這個問題會發生應該是因為一開始就沒確認好環境問題，測試機跟客戶的環境不完全一樣，再來就是A拿到的單他可以自己關....你要說B也是個點我不反對，但我覺得以B的角色沒有能力擋住這個問題的話他就不該擔責，b開給a的問題單能被a自己關掉我自己可以想像b的心態會有多炸裂，不複測是個點但嚴重性沒有比上面兩個高，畢竟後面還有qa背書
話說我之前回過superpandal一大串，跟他說A卡三週的時間裡是是A要負責找B喬環境，現在看來他還是認為B是那個要負責的角色lol184F 07/29 15:44
→ labbat: A部門要對整個專案成敗進行負責，會認為專業分工下B部門本來就要調查清楚未知問題且完整揭露訊息。可是B部門要有A部門的才有的東西根本拿不出來，情況就僵在那了
A部門的二元矛盾是做之下的api也做整合之上的專案領導194F 07/29 16:00
--