Re: [心得] 我在科技業遇到的鬼故事之一
※ 引述《pokkys (人很好那一個)》之銘言：
: 我是原po，我來交代一些細節，供大家參考一下。
: 角色：
: 我在這裡的角色是application owner，我要推一個應用給客戶去使用。
: 我這個application需要多個feature來組成，B是我其中一個feature owner。
: B這個feature需要多個kernel function整合才有辦法達成，當然B自己也要寫不少code。: A是B負責的feature的kernel function owner，同時我也是A的主管。
: 我也有配到一組跟我對應的QA，而我要承擔最終的成敗。
: 這其中：BU1:{{A,我},QA} BU2:{B}
: 一開始A接到bug試不出來，有去找B討論，但是B認為步驟寫在bug report上很完整了。: 而且B有其他feature要開發，無法把機器+環境借給別人。
到這邊為止
A看起來有把問題反應給你
你的工作應該是跟B的主管協調,看能不能讓B優先處理這個issue吧
大部分職場都會把開發需求區分piority
如果這是個嚴重的issue, piority設高並且必須優先處理.
我會好奇為什麼不能要求B優先處理你們的問題
如果B真的無法處理,issue也是等到他有空能幫忙後才關閉吧.
會在客戶端爆炸的問題我認為piority應該要設高才對 @@
: 我問B：你是看到A/QA把bug close後，你又測了一次發現還是一樣，所以才打算commit上: 去想要highlight他是嗎？
: B說：沒有，後來就沒有測。
: 我問：你沒有測，你怎麼會知道這個問題還在？
: B說：他就說can not reproduce啊，所以問題一定還在。
: 我說：這不一定吧？
: B的主管：所以你只是因為他沒有解，所以你認定問題還在，才想要highlight這個問題？: B說：對，我只是想提醒大家問題沒有被解決。
: 我說：那你到底測過幾次？
: B想了一下說：1次
: 我說：可是你寫always耶！
: B說：我就想說測1次中一次就100%啊。
B的回答0分
但從B的角度看,他不是QA也不是負責人
回報問題 -> 被mark close -> commit上去後release
這個過程聽起來也沒什麼錯,bug都被close了為什麼不能release.
我個人在這種情況下都會複測一次確保沒問題
而主管的工作是要在這種情況下確定底下工程師有複測
原po作為管理者(app owener),該處理的問題是
1. 要求B優先處理這個issue
2. 確保B真的有複測,而且要能看到複測結果. (附一張截圖之類的)
管理者本來就要幫下屬爭取必要的資源
這樣看起來A算苦主,他就真的無法複測,也有向上反應,
但上面沒有提供足夠的資源 (要求B優先處理這件事情)
QA也無法重現的情況下就應該抓B一起進來解問題...
B的工作態度有問題,但可能對公司積怨已久或是失去工作熱情
看起來是原本就想跑了,跑之前放個火燒一下.
我好奇的是是否有要求B進來一起解bug,以及這件事情是否被拒絕 @@
: 後來B先被請出去了，我跟他主管談這件事。
: 我們最後的共識是相信B主管的總結：因為bug close當下，那段有問題的LAGG test code: 已經被修掉很久了。 B不太可能有真的機會複製出這個問題。 而且LAGG test code被修: 掉這件事，也可以解釋為何我跟QA沒有辦法複製。 這個說法，大家都會有台階下。
: 所以最後我沒有去糾結為何他那麼明確知道bug還在這件事.....我接受B主管的說法了。
並不是有台階下就好,問題還是沒解決
而且這個台階是建立在A背了黑鍋的前提下...
--
最原始的發文就是這個bug不是100%重現，但feature不能開
但重現過的只有B，把他抓進來參與討論很正常吧
B說他沒辦法幫忙，就close bug，感覺問題點發生在這裡
從後續原po他們復現的情況來看B真的進來可能也沒用，因
為B後來一開始也無法復現，問題沒在客戶那邊炸開時看得
出來A部門對B的信任度相當低，才會有A認為他複製不出來
這個問題，肯定是B把自己環境搞砸了就可以關掉bug的情況
。否則不太可能輕率處理這種會造成資料損毀的嚴重問題
如果B也無法重現的話就真的沒輒了
但B沒被拉進來是別的問題@@
從B只測過一次這件事也是原po在事後檢討時問B才知道，那
當初A有沒有認真找B討論過這個bug可想而知
因為雙方沒有信任，A部門當然也不會拉B進來處理，可能還
覺得B根本在亂開bug
呃這個我覺得當事人才知道怎麼回事
但文內敘述是B在忙，無法提供設備做測試
這bug會造成資料損毀基本上算是非常嚴重的等級，如果A部
門真想要查清楚就不該關閉吧？看是要找B主管調整B的工作
還是等B忙完再來一起解
說實在應該一堆公司都有類似的問題，只是沒炸開而已
一堆公司？可否舉例？個人待過的公司超過6家了。從來沒有
一家 有bug，工程師可以隨意關。有問題的程式碼，開發者可
以隨意release到產品，不會有人審。出了事情，owner優先檢
討人說話態度不對的。
全台幾間公司，你也才待六間。D大你是神人沒遇過正常
A可以close bug應該是主管也同意 也就是原po 不關的話應該也
沒辦法按schedule推出產品
看一堆人想跟A當同事不想跟B 就知道有一堆公司認為說話
的態度比邏輯跟流程重要啊
今天B沒有運氣好打到規格外的bug，產品一樣會炸
但是B打到了之後沒有執意卡release卡到能復現為止，所以
會炸都是B害的，如果B心態積極善良產品就不會出包了
其他人輕忽資料毀損bug根因未解，都沒責任，因為態度良好
一堆人是這種想法
B懂個屁邏輯與流程 什麼叫作一樣會炸 B不commit會炸
嗎 也沒有人故意讓他說錯話 他自己曝露動機不能怪人
你要不要去看一下出bug的點 無法複現可以理解
在中小企業很隨意是很常見的 看來DrTech是都待在很好
的公司
就環境問題 這應該還要再開另外的issue B早就忙完
commit不是嗎 為何是A部門要主動？ 如果A部門有視野
那A部門理應主動 看不見的東西沒有目標還要主動...
嗯？你把B換成CDEF都有可能炸啊A的code就是有問題而且他
沒打算查啊因為他跟你的邏輯一樣啊，「雖然問題出在我的f
unction，但是我不用主動，因為我不能復現，看不到目標，
別人要幫我復現我再來查，不然我就關票，沒問題的」你把B
換成任何人都一樣會炸
所以應該是找B主管討論後拉B進來debug阿...
要是B進來後無法重現，那就真的沒輒
未知的情報你要怎麼讓A主動認為是己方問題？ 換任何
人都會炸然後呢？ B沒犯錯？ 硬找理由cover B
關bug 很奇怪+1 通常都是開著讓他變known issue 除非r
oot cause 找到，然後如果issue 夠嚴重，應該要請B的
主管壓著他壓到他重新復現並給出詳細步驟為止
關close理由都給你了有什麼好奇怪...
爆
首Po講一個我在科技業遇到的鬼故事 這件事主要發生在兩個人身上： A:是我同部門的同事，主要開發kernel層以下的功能。 B:是隔壁整合部門的同事，主要是開始kernel層以上的功能。 有一天A開發了某一個功能，B整合完之後發現會導致資料損毀。於是B發了一個bug給A，![[心得] 我在科技業遇到的鬼故事之一](https://i.imgur.com/13sxjYWb.png "[心得] 我在科技業遇到的鬼故事之一")
這個怎麼想都是公司的問題 居然沒有CI/CD? 環境怎麼會是以個人當標準? CI/CD過了 誰local有問題就你家的事啊 這種垃圾公司原PO還是快逃13
難怪IC house要推當責Accountablity 提到的每個人都幾乎有責任啦 就跟空難和起司理論一樣 不是只有一個單純的原因造成 Product owner每天或每周都應該了解進度/severity72
這篇文最鬼的明明就是原PO，這個Feature在他的組開發然後有問題，自己組的人+QA竟然 測不出來，結果隔壁組的人竟然有權限把Feature打開，B就算說原本就知道有問題硬要搞 最後補一句「有可能是我自己環境有問題」也是能全身而退 說到底身為新Feature的lead管產品品質+QA都管不好，有問題的code還能進到release br anch，最後還能PO出來讓大家評論B，這才是我看過最鬼的鬼故事吧78
我是原po，我來交代一些細節，供大家參考一下。 角色： 我在這裡的角色是application owner，我要推一個應用給客戶去使用。 我這個application需要多個feature來組成，B是我其中一個feature owner。 B這個feature需要多個kernel function整合才有辦法達成，當然B自己也要寫不少code。8
→ pokkys: 所以B根本不需要講他是故意的話。 07/25 19:37 所以大部分的人都搞錯重點了 因為事情對或錯往往都不是重點 而是看哪個部門比較大聲 B大也可以裝傻 退一步假裝真的是當時誤以為自己搞砸環境4
不是mindset也不是制度問題吧 是你們所有人的環境為什麼都跟客戶不一樣？ B只有一開始的環境類似於客戶 後來也不一樣了所以可能也做不出來 環境不一樣25
再回一篇，先說我不是B但是這個細節出了更明顯不是B的問題了啊 這個Bug本來就是一個corner case只是好巧不巧在B開發的時候遇到一次，要是今天B剛好 就沒遇到這個Bug，你們還不是一樣照常Release，客戶一樣爆掉，這樣B不就剛好衰幫你 發現Bug而已？ 你硬要說B的態度有問題，他也只是表達出他遇過且在你們根本沒修的情況本來就很可能24
第一篇文章推文： pokkys: 我的職位要扛feature成敗，所以我也因此卡到升遷。 pokkys: 沒有火B這件事我也是傻眼+不滿，所以我比B還早離職 XD 第二篇文章內文： 其他人的部分，我是極力不想對A究責，B的主管也是一樣的態度。最後我們兩個送上去給老闆的說法是這兩個人的責任，10分裡只有1分。27
大家好我是原po，大家討論那的激烈，我覺得我需要補充一下。 我認為有一個癥結點需要解釋一下，雖然有可能解釋完結果可能更糟 XD 因為中間有一段，完全是我的臆測，我也沒有絕對證據去證實我的論點。 如果各位要反駁我，我也完全接受。 我主要是要講一下，為何我會覺得B應該被火？
91
[情報] IOS 14.0.1IOS 14.0.1，修正一些錯誤 Following last week’selease of iOS 14 to the general public, Apple is releasing a bug fix update today in the form of iOS 14.0.1. Today’s update brings fixes for iOS 14 home screen widgets, default app settings, and more. Here are the full release notes for today’s iOS 14.0.1 update: 1. Fixes an issue that could cause default browser and mail settings to reset after restarting your iPhone![[情報] IOS 14.0.1](https://i.imgur.com/uYDGas4b.png "[情報] IOS 14.0.1")
9
[問卦] 你敢嗆自己公司的主管嗎？老闆說什麼 我也只能聽 嗆嗆我都不敢 叫工程師吃屎就必須吃… 出事8d report也是叫你寫 issue也是你在解 反正工程師都免洗得的 release出事也是你的問題 主管只要專心升遷就豪![[問卦] 你敢嗆自己公司的主管嗎？](https://img.youtube.com/vi/f4YcT8NXdaE/mqdefault.jpg "[問卦] 你敢嗆自己公司的主管嗎？")
5
Re: [討論] 怎麼克制不想教白目同事的衝動: : 已試過以下方式： : 1. 統一講解code style、函式用法並有書面文件參考，結果還是亂做。 : 2. 製作sop，結果只看第一頁。 : 3. 指派工作，連程式碼都給了，只要上傳即可 ，也在旁邊壓著看，確定已經完成工作5
[心得] Bug的分級與解決這邊介紹比較正式的Bug處理方式。 一、Bug 分級：何時該修，何時可以不修 二、相關配套 補充：每間公司的文化不同，常見叫法有 Issue / Case / Defect(偏硬體廠商) =======================3
[寶寶] 新生兒聽力篩檢複檢過程分享(台大)爬文看板上比較少關於新生兒聽力篩檢複測過程的文章，想說上來分享一下。 二寶預產期7/15，7/3在台大出生，38+2。住院時測AABR新生兒聽力篩檢，左耳兩次都沒過，因此醫院請我們在寶寶滿月後自己掛耳鼻喉科門診複測（這裡滿月的意思是預產期後 加一個月，而不是出生日加一個月。）醫院會給一張說明書，告知可以掛的醫師姓名及時 段，不會幫你掛好。 目前台大是兩週前的00:00開放網路掛號，可以下載app，滿方便的。另外因為疫情關係，