Re: [心得] 我在科技業遇到的鬼故事之一

看板Soft_Job作者 (NickLin)時間9月前 (2023/07/25 02:48), 9月前編輯推噓72(74推 2噓 162→)
留言238則, 28人參與, 9月前最新討論串4/17 (看更多)
這篇文最鬼的明明就是原PO，這個Feature在他的組開發然後有問題，自己組的人+QA竟然 測不出來，結果隔壁組的人竟然有權限把Feature打開，B就算說原本就知道有問題硬要搞 最後補一句「有可能是我自己環境有問題」也是能全身而退 說到底身為新Feature的lead管產品品質+QA都管不好，有問題的code還能進到release br anch，最後還能PO出來讓大家評論B，這才是我看過最鬼的鬼故事吧 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 73.93.82.238 (美國) ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1690224492.A.567.html ※ 編輯: handsomeLin (73.93.82.238 美國), 07/25/2023 02:49:25
推
07/25 07:44, 9月前 , 1F
一個是制度有問題 一個是人有問題 這能比嗎 哪個比較該
07/25 07:44, 1F
→
07/25 07:44, 9月前 , 2F
死 不能留 大家心知肚明
07/25 07:44, 2F
→
07/25 07:44, 9月前 , 3F
你講的是流程跟制度上有問題，但B已經是其它問題了
07/25 07:44, 3F
→
07/25 07:44, 9月前 , 4F
，而且說一句「可能是我自己環境有問題」就能全身而
07/25 07:44, 4F
→
07/25 07:44, 9月前 , 5F
退，在我看來是不可能啦
07/25 07:44, 5F
推
07/25 07:54, 9月前 , 6F
可怕的是bug 可以隨便關，沒人審核。Release可以讓開發者
07/25 07:54, 6F
→
07/25 07:54, 9月前 , 7F
自行決定隨便開feature，沒人審核吧。
07/25 07:54, 7F
推
07/25 07:57, 9月前 , 8F
真的是組織制度設計的問題，最鬼的真的不是A或B。
07/25 07:57, 8F
→
07/25 07:58, 9月前 , 9F
結果原文還誤導大家問題在A與B。
07/25 07:58, 9F
推
07/25 08:41, 9月前 , 10F
都有問題啊,只是人的問題,可以靠制度規範,但不是所有組織都能
07/25 08:41, 10F
→
07/25 08:41, 9月前 , 11F
一開始就有完善規定,這時候遇到獨善其身的人只能死了
07/25 08:41, 11F
推
07/25 08:46, 9月前 , 12F
A亂關issue要其他人怎麼審核？issue能關本來就一直都有
07/25 08:46, 12F
→
07/25 08:46, 9月前 , 13F
信任成分在，要B負責也很怪，那之後B有權限去重開其他
07/25 08:46, 13F
→
07/25 08:46, 9月前 , 14F
所有人的issue嗎？
07/25 08:46, 14F
推
07/25 09:25, 9月前 , 15F
擺爛的人沒啥，失言的該死XD
07/25 09:25, 15F
推
07/25 10:05, 9月前 , 16F
從原po講的組織來看，A與原po同部門，原po可能是主管或
07/25 10:05, 16F
→
07/25 10:05, 9月前 , 17F
資深人員，因為他扛feature成敗，QA與他們是同一個大部
07/25 10:05, 17F
→
07/25 10:05, 9月前 , 18F
門，只有B是另一個大部門的人，B的主管看來也沒有進到這
07/25 10:05, 18F
→
07/25 10:05, 9月前 , 19F
個案子處理，現有資訊看起來原po的大部門應該是這功能甚
07/25 10:05, 19F
→
07/25 10:05, 9月前 , 20F
至整個案子的主導部門吧？那原po所謂的B release featur
07/25 10:05, 20F
→
07/25 10:05, 9月前 , 21F
e指的是什麼？把他上層沒問題的code進到release branch
07/25 10:05, 21F
→
07/25 10:05, 9月前 , 22F
嗎？這有什麼問題？有問題的是A的code，這部份是A自己已
07/25 10:05, 22F
→
07/25 10:05, 9月前 , 23F
經上了才會被B開bug不是嗎？結果一堆人因為原po最後兩段
07/25 10:05, 23F
→
07/25 10:05, 9月前 , 24F
可能是B的氣話覺得B很雷？我只覺得有心人比鬼還可怕…
07/25 10:05, 24F
推
07/25 10:17, 9月前 , 25F
B不是QA，他有自己code整合進去才是成品，而那成品是
07/25 10:17, 25F
→
07/25 10:17, 9月前 , 26F
有問題的，這不是只有信任上層code問題，而是他是把自
07/25 10:17, 26F
→
07/25 10:18, 9月前 , 27F
己整合完確定還有問題的東西release出去而不是再通知
07/25 10:18, 27F
→
07/25 10:18, 9月前 , 28F
沒修好。
07/25 10:18, 28F
推
07/25 10:18, 9月前 , 29F
用炸客戶的方式來highlight內部的人難道沒問題嗎？
07/25 10:18, 29F
推
07/25 10:22, 9月前 , 30F
B發現有問題時已經開了bug給A，後來是A關了bug，甚至原p
07/25 10:22, 30F
→
07/25 10:22, 9月前 , 31F
o也寫了A認為他複製不出來這個問題，肯定是B把自己環境
07/25 10:22, 31F
→
07/25 10:22, 9月前 , 32F
搞砸了，這種時候要求B一人對抗A和QA整個大部門嗎？
07/25 10:22, 32F
推
07/25 10:26, 9月前 , 33F
A有錯，但問題較單純，可能用流程或制度可改善，但B的心
07/25 10:26, 33F
→
07/25 10:26, 9月前 , 34F
態今天不炸你 改天也會炸你，沒有職業道德。無論如何只
07/25 10:26, 34F
→
07/25 10:26, 9月前 , 35F
想離B遠遠的
07/25 10:26, 35F
推
07/25 10:30, 9月前 , 36F
B沒有往自己上面求援讓自己安全下莊這倒是B自己的問題，
07/25 10:30, 36F
→
07/25 10:30, 9月前 , 37F
不過以原po透漏的組織來看我是不覺得B有何能耐能讓客戶
07/25 10:30, 37F
→
07/25 10:30, 9月前 , 38F
不被炸到，B撐著不上自己的code又無法幫A找到問題點，A
07/25 10:30, 38F
→
07/25 10:30, 9月前 , 39F
這邊可以說是B害這個feature延期啊
07/25 10:30, 39F
還有 159 則推文
→
07/27 16:37, 9月前 , 199F
他們release前QA還測過好嗎…B遇到的是某個狀況下會有資
07/27 16:37, 199F
→
07/27 16:37, 9月前 , 200F
料損毀的狀況，但這狀況在A與QA的環境中都不會發生，所
07/27 16:37, 200F
→
07/27 16:37, 9月前 , 201F
以要說什麼沒有整合好根本就不是這樣啊，B的整合只是去c
07/27 16:37, 201F
→
07/27 16:38, 9月前 , 202F
all A的function，造成資料損毀是因為A function裡的動
07/27 16:38, 202F
→
07/27 16:38, 9月前 , 203F
作而不是B整合的問題啊
07/27 16:38, 203F
→
07/27 16:40, 9月前 , 204F
所以B當初開了bug給A，而A認為B環境搞砸才會遇到，那本
07/27 16:40, 204F
→
07/27 16:40, 9月前 , 205F
來就是A的問題啊，A不是把bug掛回B說是B沒整好ok？
07/27 16:40, 205F
→
07/27 16:41, 9月前 , 206F
還有從原po兩片敘述來看A部門關閉bug也沒有經過B同意，
07/27 16:41, 206F
→
07/27 16:41, 9月前 , 207F
所以B到底該怎麼擋？
07/27 16:41, 207F
→
07/27 16:41, 9月前 , 208F
兩篇*
07/27 16:41, 208F
推
07/27 16:47, 9月前 , 209F
這裡有這麼多人不在意bug被關閉而在意B嘴巴說的實在讓我
07/27 16:47, 209F
→
07/27 16:47, 9月前 , 210F
覺得非常神奇，難道台灣多數公司的軟體開發都還在用嘴巴
07/27 16:47, 210F
→
07/27 16:47, 9月前 , 211F
管理bug嗎？
07/27 16:47, 211F
推
07/27 16:59, 9月前 , 212F
那以後有要整合麻煩找j大啊，有幾個module出包就請他扛
07/27 16:59, 212F
→
07/27 16:59, 9月前 , 213F
責任幾次，畢竟這是他整合的
07/27 16:59, 213F
推
07/27 17:55, 9月前 , 214F
優文
07/27 17:55, 214F
→
07/27 18:34, 9月前 , 215F
追蹤平台就是方便你追蹤 你要拿來當什麼標準那就多
07/27 18:34, 215F
→
07/27 18:34, 9月前 , 216F
了 很不可靠的東西拿來用還判斷一些有的沒有
07/27 18:34, 216F
→
07/27 18:37, 9月前 , 217F
是環境問題阿 這不能全算A程式的問題 至於在意B所說
07/27 18:37, 217F
→
07/27 18:38, 9月前 , 218F
是他不想幫就算了搞到全公司 影響範圍很大 最好這不
07/27 18:38, 218F
→
07/27 18:38, 9月前 , 219F
嚴重 就是非常嚴重
07/27 18:38, 219F
→
07/27 18:41, 9月前 , 220F
B本來就應該推掉整合的角色 B可以踢回去這講了好幾次
07/27 18:41, 220F
→
07/27 18:41, 9月前 , 221F
還有人在問"所以B到底該怎麼擋?"
07/27 18:41, 221F
噓
07/27 19:19, 9月前 , 222F
B自己就說了 明知道有問題要用這種方式highlight A
07/27 19:19, 222F
→
07/27 19:19, 9月前 , 223F
是還要再辯什麼? 這跟上帝不上帝有什麼關係? 就知道
07/27 19:19, 223F
→
07/27 19:19, 9月前 , 224F
有這個問題而且 也爆了 扯一堆環境不環境的
07/27 19:19, 224F
推
07/27 19:23, 9月前 , 225F
A認為他複製不出來這個問題，肯定是B把自己環境搞砸了，
07/27 19:23, 225F
→
07/27 19:23, 9月前 , 226F
這第一篇自己說的
07/27 19:23, 226F
推
07/27 19:26, 9月前 , 227F
B的說詞是在客戶那裡炸了之後，而第二篇看他們release流
07/27 19:26, 227F
→
07/27 19:26, 9月前 , 228F
程，release時QA也都驗過，客戶炸了之後用B環境也無法復
07/27 19:26, 228F
→
07/27 19:26, 9月前 , 229F
現，所以後來才又發現是LAGG造成，整個看下來B也只是矇
07/27 19:26, 229F
→
07/27 19:26, 9月前 , 230F
到的啊…
07/27 19:26, 230F
推
07/27 19:32, 9月前 , 231F
A有沒有問題關我屁事 之前就有說他有問題啊 QA也有
07/27 19:32, 231F
→
07/27 19:33, 9月前 , 232F
問題 這個大家都知道 問題是事情爆開來你覺得公司只
07/27 19:33, 232F
→
07/27 19:33, 9月前 , 233F
去會怪A嗎? 應該是兩個都怪吧 重點是B的心態跟做法
07/27 19:33, 233F
→
07/27 19:33, 9月前 , 234F
而且他也得償所願 他高興就好 反正就是要讓大家high
07/27 19:33, 234F
→
07/27 19:33, 9月前 , 235F
light A 公司產品炸掉也沒關係 他是明知故犯的
07/27 19:33, 235F
推
07/27 19:37, 9月前 , 236F
又一個思想犯該死的，算了…
07/27 19:37, 236F
→
07/27 23:12, 9月前 , 237F
wmt是不是沒在看文 B哪有再測一次 B明明講後來就沒有
07/27 23:12, 237F
→
07/27 23:13, 9月前 , 238F
再測 B是認定絕對有這bug 100%
07/27 23:13, 238F
‣ 更多 handsomeLin 的文章
文章代碼(AID): #1aliTiLd (Soft_Job)
討論串 (同標題文章)
完整討論串 (本文為第 4 之 17 篇)：
排序： 最舊先 | 最新先 | 留言數
在新視窗開啟完整討論串 (共17篇)
‣ 更多 handsomeLin 的文章
文章代碼(AID): #1aliTiLd (Soft_Job)