Re: [心得] 我在科技業遇到的鬼故事之一
這篇文最鬼的明明就是原PO,這個Feature在他的組開發然後有問題,自己組的人+QA竟然測不出來,結果隔壁組的人竟然有權限把Feature打開,B就算說原本就知道有問題硬要搞最後補一句「有可能是我自己環境有問題」也是能全身而退
說到底身為新Feature的lead管產品品質+QA都管不好,有問題的code還能進到release branch,最後還能PO出來讓大家評論B,這才是我看過最鬼的鬼故事吧
--
一個是制度有問題 一個是人有問題 這能比嗎 哪個比較該
死 不能留 大家心知肚明
你講的是流程跟制度上有問題,但B已經是其它問題了
,而且說一句「可能是我自己環境有問題」就能全身而
退,在我看來是不可能啦
可怕的是bug 可以隨便關,沒人審核。Release可以讓開發者
自行決定隨便開feature,沒人審核吧。
真的是組織制度設計的問題,最鬼的真的不是A或B。
結果原文還誤導大家問題在A與B。
都有問題啊,只是人的問題,可以靠制度規範,但不是所有組織都能
一開始就有完善規定,這時候遇到獨善其身的人只能死了
A亂關issue要其他人怎麼審核?issue能關本來就一直都有
信任成分在,要B負責也很怪,那之後B有權限去重開其他
所有人的issue嗎?
擺爛的人沒啥,失言的該死XD
從原po講的組織來看,A與原po同部門,原po可能是主管或
資深人員,因為他扛feature成敗,QA與他們是同一個大部
門,只有B是另一個大部門的人,B的主管看來也沒有進到這
個案子處理,現有資訊看起來原po的大部門應該是這功能甚
至整個案子的主導部門吧?那原po所謂的B release featur
e指的是什麼?把他上層沒問題的code進到release branch
嗎?這有什麼問題?有問題的是A的code,這部份是A自己已
經上了才會被B開bug不是嗎?結果一堆人因為原po最後兩段
可能是B的氣話覺得B很雷?我只覺得有心人比鬼還可怕…
B不是QA,他有自己code整合進去才是成品,而那成品是
有問題的,這不是只有信任上層code問題,而是他是把自
己整合完確定還有問題的東西release出去而不是再通知
沒修好。
用炸客戶的方式來highlight內部的人難道沒問題嗎?
B發現有問題時已經開了bug給A,後來是A關了bug,甚至原p
o也寫了A認為他複製不出來這個問題,肯定是B把自己環境
搞砸了,這種時候要求B一人對抗A和QA整個大部門嗎?
A有錯,但問題較單純,可能用流程或制度可改善,但B的心
態今天不炸你 改天也會炸你,沒有職業道德。無論如何只
想離B遠遠的
B沒有往自己上面求援讓自己安全下莊這倒是B自己的問題,
不過以原po透漏的組織來看我是不覺得B有何能耐能讓客戶
不被炸到,B撐著不上自己的code又無法幫A找到問題點,A
這邊可以說是B害這個feature延期啊
說炸客戶有點偏頗 誰知道客戶的環境是怎樣 如果客戶環境是A
B直接 Demo 出問題就可以驗證了,哪來無能為力的問題
即使有bug也不會出事 A說沒問題 B當然就相信他沒問題
又不是要B修
B是用A的東西做feature,看到A標無法複製而關issue,他
身為第一線使用者不向上反應而且還惡意推送,說到底沒人
所以一些人要B一定要擋下來我也不知道為什麼,B開給A的b
比他更了解事情嚴重性,我是覺得他責無旁貸
ug可以讓A自己關掉我就不認為B有能力卡啊
換成客戶和客服就比較清楚,客戶回報有Bug有問題但不給
任何資訊,客服和後端怎麼測都很難找到問題點
換成B也是一樣,你明知有問題又不想給資訊,當然解不了
A的做法是把制度搞砸,不知道為什麼這個版講得像是日常
一樣,今天B要擋A close的issue,請問其他close的issue
也要B擋嗎
A的code影響你的code,你還能說沒問題開出去,當然最後
主責在你。
kernal是A的,feature是B的,沒擋那開出去feature有問
題,還是你要扛
欸不是 ,B是A功能的第一線使用者耶,直接相關,沒有其他
人比B更了解實際情況,而且B是知道會炸他還故意讓客戶炸
。
B不給資訊是腦補還是事實?而且整個bug放三個禮拜,A、
原po和QA無法讓一個B透漏資訊,B是多大咖的魔王嗎?你一
個客服不給完整資訊我RD不先找客服主管highlight就自己
關掉bug?你是把RD當OP還是客服在做嗎?
A和QA測不出來,代表code是符合Spec和測試項目的,Use
應該是QA要扛責任吧 怎麼會是B 不然請QA來是幹嘛的
Case出問題,也只能User提供訊息才能測。這不是B對抗
人家,是B搞人家。
我覺得這問題換成A和B只能選一個,你寧願和誰合作?就比
較好選了
原文就有說B不願意提供資訊,藉口說要忙不理了。
Issue CLOSE就是解完了,全部流程就是繼續往下跑,難道
現在還有"類close"這狀態嗎?
B真的不提供資訊,我也沒看到原po或A有找B的主管這個動
作啊,那這所謂B不提供資訊的指控不就很奇怪?
Issue close是解完?A明明是標無法複製
B 有報bug,A找3禮拜,說B沒提供環境? 那客戶環境只B有?
全部流程哪可能繼續往下跑?release前不用再複測一次?
B再怎樣也可以開會議或發mail HLA啊,怎可以故意炸客戶
就算是後端真的解完bug,丟回來的code也是矇眼直接放?
下層的code怎麼會是B在上?
因為B...負責上層。最後給客戶的東西是B整合的啊,當然
是B在上。
A跟QA 測試沒用客戶環境測?
A自己上自己的code才對吧,現在是A有問題的code早就在上
面了,B上的只是去call A的部分吧
我是無法理解B都惡意搞事了,還有人覺得他沒錯,今天他
看A不爽就用公司信譽搞人,哪天會不會看誰不爽又這樣做
呢,防不勝防,誰敢和他合作
破壞公司信譽的原因不就是A沒解就把bug關了
原文作者在怪B差點毀到自己的利益,光聽他轉述B說的話可能
不會100%正確
當然不是
怎會是A
B故然態度有問題,但是A和QA 不適任或是教育訓練有問題
我覺得原文把B描述成惡意搞事是討論的最大癥結 我不覺得是這
樣 B事後承認就太蠢了 搞這種事就是要最後跳出來當英雄升官
我也覺得寫個幾句氣話就能帶到風向蠻神奇的
我看B也不覺得問題有這麼大 A都說沒問題了
沒人會喜歡B,但B事後有沒有垃圾話不影響客戶炸掉,因
為A關掉issue了,除非原po公司close不等同resolve
原文第一句就寫A是kernal B是feature了
A code 要在透過B整合完才會給客戶用
就我使用JIRA的方式來看,resolved後要reporter確認沒問
題才能closed
不管有沒有解,都是B要複測確認才能開出去啊。
你用git的話所謂整合也是各自上各自的code啊
A是kernal,B的工作是整合A,何來各自上各自code?
A的Bug直接影響B的code
A是標無法複製關的issue,不是標解決吧,而且B不用測嗎
A的function平常不會被call當然自己上沒問題啊,現在是B
的feature會去call,所以一開始有問題B開了bug,結果三
週後A認為是B自己搞砸環境造成,那B為何不能上自己那部
分沒問題的code?
A認為他複製不出來這個問題,肯定是B把自己環境搞砸了。
A都這樣說了,QA也測不出來,這樣B要怎麼證明自己的環境
才是對的?
很簡單啊,把A叫過去給他看demo啊
你平常寫的程式 call的 library 有問題,你覺得你寫的
call function沒問題,所以你覺得就可以開出去嗎?
library的開發者認為是我的環境有問題,我無法證明誰的
環境才對而出事他願意負責那我當然上啊
所以,你其實就是B吧...希望不要遇到你
很好啊,擺爛的總是不願意遇到想做事的人這沒啥問題
A說環境搞砸close掉issue你要B拿什麼去挑戰,這樣會變
成B要去找A吵架來把關產品的品質,這樣流程靜電很不合
理
*流程變得
我是B的話當然先拉主管進來下車之後看A部門決定怎麼做啊
對啊應該拉主管 而不是放出去啊
正常流程就是bug reporter覆核不過,除非流程裏不要求
覆核。
拉主管這點完全同意,但我想這邊都是在討論事後究責吧
從原文就是只說A關了bug啊,B看來不是爭論輸了就是根本
沒必要他同意
如果流程上有覆核,那主責任就在B身上。
如果原文是寫B關了bug,那B當然就有責任
RD居然可以隨便關ticket,當QA塑膠的嗎
看到現在總覺得原po有些事情沒有講,當故事來看就好
原po留言有說他扛責了呀 感覺他發這篇只是想臭b
一個bug 弄3個禮拜是正常的嗎?
一個feature 是有多大? 還是A部門有一大堆債?
反正這故事裡面看起來也沒人在review issue,所以RD可以隨便關
ticket也沒什麼吧
就是一鍋粥,然後現在在那邊互噴,呵呵
寫出bug給其他部門測到誰沒有過?
但明知道有嚴重bug還出給客戶 這我可從來沒做過
討論半天怎麼沒人討論到QA 就算RD想亂搞 也要過QA這關吧
qa跟A同部門唄
原po推文自己有說B有開bug給QA也被關
原來開 issue,開發者可以隨便關掉的喔。推文真的大開眼界
。這種情況,誰還要解Issue,直接關掉就好。
順便報一下公司部門啊,聽起來好爽的單位。
另外,哪一套issue管理系統,別人/別部門提的issue,自己
可以關? 我也是從來沒見過啦。
隔壁討論串更猛 還有你的close不是close笑死
正常A搞不出來 主管要幫A看吧
一般是可以標記狀態 但關不關掉權限不在RD
所以這問題確實是制度很鬼 人人可開關 沒人管為何
b的背景原作交代不清啦 我提出你的func有問題,結果你
說沒有問題,原作也沒詳述b到底有沒有提供,a收到問題
也沒有向上呈報,跨部門處理,就這樣當作沒問題,怎麼
想都是a有問題啊,要死一起死 讚讚
我也覺得原po的問題最大
只有一來一往阿 B回報問題A/Qa 找不到close B沒再踢
回去
開issue開發者不能隨便關那當初就不要給權限 樓主的
公司肯定不是制度非常好的
嚴格說起來是A部門的bug,別的部門B幫忙測出來就該感謝了
這都不算太算bug 是feature 不支持該客戶環境的
feature 測出來暗槓
,ㄏ話說其實只要技術上禁close就好
權限劃分
說B有問題是他自爆或是站在上帝視角
沒有上帝視角B被小懲是這樣 畢竟他是統整的人 他如果
隱藏那會是更恐怖的人 但這事情沒如果 你掘地三尺必
然會更接近真相 你還在那邊如果如果那這問題就變寫故
事而不是說故事
客戶那邊出事了 原來是這兩個鬧小脾氣的搞事 誰在
乎權限三小 通通下去
這是全部人的問題 這事件原po/A/B通通下去了 只是時
間早晚
A自己能close bug 是公司流程有問題 A自己也不搞清
楚不負責 B明知有問題A沒解好就close了 故意讓它出去
來highlight A 這心態很有問題 而且這個feature是他
的責任 底層沒好他把feature一樣丟出去 以為之後客
戶會回來highlight A 心態做法都錯
真是蠻多人要B當上帝的樣子XD,B遇到問題時開了bug,結
果A認為是B把環境搞砸才有這個問題所以關了bug,不少人
拿B後來的嘴砲咬定B知道一定會在客戶那邊炸開?這其實後
來原po補充那篇就說明根本不是了,不然在客戶那邊炸開後
怎麼也無法在B的環境復現?
底層沒好 feature就出去了是啥小 以為root cause不在
己就沒事? 對外面的人來說這個feature的問題就是B的
問題 應該是B要把關 B要去追A請他改好 A堅持不改那就
報上去 請QA或主管處理
文章要看清楚啊,底層到上層串接功能基本上是沒有問題,
他們release前QA還測過好嗎…B遇到的是某個狀況下會有資
料損毀的狀況,但這狀況在A與QA的環境中都不會發生,所
以要說什麼沒有整合好根本就不是這樣啊,B的整合只是去c
all A的function,造成資料損毀是因為A function裡的動
作而不是B整合的問題啊
所以B當初開了bug給A,而A認為B環境搞砸才會遇到,那本
來就是A的問題啊,A不是把bug掛回B說是B沒整好ok?
還有從原po兩片敘述來看A部門關閉bug也沒有經過B同意,
所以B到底該怎麼擋?
兩篇*
這裡有這麼多人不在意bug被關閉而在意B嘴巴說的實在讓我
覺得非常神奇,難道台灣多數公司的軟體開發都還在用嘴巴
管理bug嗎?
那以後有要整合麻煩找j大啊,有幾個module出包就請他扛
責任幾次,畢竟這是他整合的
優文
追蹤平台就是方便你追蹤 你要拿來當什麼標準那就多
了 很不可靠的東西拿來用還判斷一些有的沒有
是環境問題阿 這不能全算A程式的問題 至於在意B所說
是他不想幫就算了搞到全公司 影響範圍很大 最好這不
嚴重 就是非常嚴重
B本來就應該推掉整合的角色 B可以踢回去這講了好幾次
還有人在問"所以B到底該怎麼擋?"
B自己就說了 明知道有問題要用這種方式highlight A
是還要再辯什麼? 這跟上帝不上帝有什麼關係? 就知道
有這個問題而且 也爆了 扯一堆環境不環境的
A認為他複製不出來這個問題,肯定是B把自己環境搞砸了,
這第一篇自己說的
B的說詞是在客戶那裡炸了之後,而第二篇看他們release流
程,release時QA也都驗過,客戶炸了之後用B環境也無法復
現,所以後來才又發現是LAGG造成,整個看下來B也只是矇
到的啊…
A有沒有問題關我屁事 之前就有說他有問題啊 QA也有
問題 這個大家都知道 問題是事情爆開來你覺得公司只
去會怪A嗎? 應該是兩個都怪吧 重點是B的心態跟做法
而且他也得償所願 他高興就好 反正就是要讓大家high
light A 公司產品炸掉也沒關係 他是明知故犯的
又一個思想犯該死的,算了…
wmt是不是沒在看文 B哪有再測一次 B明明講後來就沒有
再測 B是認定絕對有這bug 100%
爆
首Po講一個我在科技業遇到的鬼故事 這件事主要發生在兩個人身上: A:是我同部門的同事,主要開發kernel層以下的功能。 B:是隔壁整合部門的同事,主要是開始kernel層以上的功能。 有一天A開發了某一個功能,B整合完之後發現會導致資料損毀。於是B發了一個bug給A,13
難怪IC house要推當責Accountablity 提到的每個人都幾乎有責任啦 就跟空難和起司理論一樣 不是只有一個單純的原因造成 Product owner每天或每周都應該了解進度/severity78
我是原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的態度有問題,他也只是表達出他遇過且在你們根本沒修的情況本來就很可能8
到這邊為止 A看起來有把問題反應給你 你的工作應該是跟B的主管協調,看能不能讓B優先處理這個issue吧 大部分職場都會把開發需求區分piority 如果這是個嚴重的issue, piority設高並且必須優先處理.24
第一篇文章推文: pokkys: 我的職位要扛feature成敗,所以我也因此卡到升遷。 pokkys: 沒有火B這件事我也是傻眼+不滿,所以我比B還早離職 XD 第二篇文章內文: 其他人的部分,我是極力不想對A究責,B的主管也是一樣的態度。最後我們兩個送上去給老闆的說法是這兩個人的責任,10分裡只有1分。27
大家好我是原po,大家討論那的激烈,我覺得我需要補充一下。 我認為有一個癥結點需要解釋一下,雖然有可能解釋完結果可能更糟 XD 因為中間有一段,完全是我的臆測,我也沒有絕對證據去證實我的論點。 如果各位要反駁我,我也完全接受。 我主要是要講一下,為何我會覺得B應該被火?
29
[請益] 真外商?小弟目前在一家總部在歐洲的外商工作 我待過其他一家美國外商, 但沒有這麼誇張 目前這家待起來的感覺是 1. PM 從來沒有提供 spec 都是我們去猜的(也沒有任何文件), 然後 release 到 production PM 也不會再來確認, 所以導致有許多 feature 都是做錯的 2. 外國人他們責任感超差的, 有許多事情他們認為他們的 task 做完就是算完成, 假設這個 task 關係到其他 feature, 但那個 feature 有 bug 他們也不會回報24
Re: [請益] QA學生實習的問題其實我也有類似的問題,小弟我目前也在某美商當軟體測試實習生 因為公司原本員工眾多,但隨著部分產品開發成熟的關係,有些東西已經轉往美國 很尷尬的是,因為過去人數多,所以整個開發流程根據板上,應該算滿正式的(吧? 專案管理有用 Jira,手動測試後要寫 automation test case,用 robot framework 因為這些自動化程式會放到 Jenkins 上,所以我們也有用到 Git22
[請益] git協同合作問題遇到一個情境 想請問應該如何操作 假設現在 有一個主分支release 兩個feature branch 第二個分支需要用到第一個分支部分代碼11
Re: [請益] QA轉RD請益看到這文章就想到自己以前也是這樣想 給你我的歷程跟想法做參考 我目前是QA大概加減做了大約十年 歷程: QA -> iOS RD -> QA (目前) 先分析職位的 POC11
Re: [請益] 請問這樣的git使用方式是否是正確的?個人意見,僅供參考 不太確定常不常見,但看起來是合理的。 可以想到的好處和情況是 不同的service 可以分開Build,Build 之後的artifact 可以依照每個service 的開發進 度deploy 到不同的測試環境,利於不同進度的開發和整合。7
Re: [討論] 所謂的開發強者是怎麼樣子的?我以前在漂亮國工作的時候 有遇過一個美國白人大神 CMU畢業的 在IC design公司寫軟體 簡直屌打一票人3
Re: [討論] 用AI寫code產生的疑問幾個未來可能的 cases: 當工程師工作開始都提早完成了,會有以下幾種發展 1-0: 裝忙不要被老闆發現 or 更早下班 1-1: 老闆接更多工作 1-2: 砍人,更少工程師做更多工作1
[心得] 產品 Beta Release、Feature Flags 分享之前有在板上分享上分享過每天上版的部署流程、單一功能釋出從功能拆解到分階段釋出的概念,這篇文章則會著重分享之前文中提到的 Beta Release、Feature Flags 的使用方法。 主要也是寫給 PM 看的,文章內容包含: - 適用 Feature Flags 的時機 - Beta Release 的流程規劃 - Beta Release 的受眾選擇、移除功能的做法、測後訪談方向