Re: [心得] 我在科技業遇到的鬼故事之一
針對上一篇還是有人在追殺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的人會有權限可以cl
ose。我用過的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 applic
ation 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其實很正常,因為多數人不喜歡烏鴉,你不是bug
owner且無法確定問題怎麼發生的這時候通常就是以bug ow
ner判斷為主,畢竟那裡的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部門如果不想fea
ture 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會跟著一起爆炸,不管他有沒有真的測過,他的責
任就沒盡到了。
B 不該 commit 的最大理由就是他自己code沒法正常跑。
後來也是確認了B惡搞,只是惡搞程度從嚴重改成輕微而已
從「故意放過」改為聲稱「故意沒測」而已。
他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部門認為輪胎有問題跟
輪胎原廠A部門反應。A部門說先不管輪胎了,新年款式車的
案子很急能不能收斂掉問題,車子能不能跑,有沒有壓力測
試,未知問題能不能先釐清?
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以後怎麼在
這公司工作,直接被貼一個能力差又固執機掰的標籤
回superpandal,你是不是就覺得b身為一個bug發現者
,開了單子之後,是他自己要去“主動”要跨部門幫A
釐清環境問題,跟A一起除錯修改,直到問題解決,
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的時候就知道是Lag
g什麼的的因素結果隱瞞不說,出問題的是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不知道客戶用lagg
b沒提供訊息最好是能準確驗證這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要去問他啊zz
close不重要的話,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處理的人不能自己c
lose是通則我才花時間跟你討論欸,如果基本認知就
不一樣難怪責任釐清的方向差這麼多 ㄎㄎ
通則是指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問題 哈哈哈
有這麼低能的 世間也是少見
爆
首Po講一個我在科技業遇到的鬼故事 這件事主要發生在兩個人身上: A:是我同部門的同事,主要開發kernel層以下的功能。 B:是隔壁整合部門的同事,主要是開始kernel層以上的功能。 有一天A開發了某一個功能,B整合完之後發現會導致資料損毀。於是B發了一個bug給A,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的態度有問題,他也只是表達出他遇過且在你們根本沒修的情況本來就很可能8
到這邊為止 A看起來有把問題反應給你 你的工作應該是跟B的主管協調,看能不能讓B優先處理這個issue吧 大部分職場都會把開發需求區分piority 如果這是個嚴重的issue, piority設高並且必須優先處理.24
第一篇文章推文: pokkys: 我的職位要扛feature成敗,所以我也因此卡到升遷。 pokkys: 沒有火B這件事我也是傻眼+不滿,所以我比B還早離職 XD 第二篇文章內文: 其他人的部分,我是極力不想對A究責,B的主管也是一樣的態度。最後我們兩個送上去給老闆的說法是這兩個人的責任,10分裡只有1分。
39
Re: [心得] (轉)軟體開發六年後我改變想法的事情這篇滿有意思的,牽涉的主題很廣,不過有些事情只有一句很難講清楚 針對中間幾點,分享一些我自己的理解 ※ 引述《alihue (wanda wanda)》之銘言: : 看到不錯的文章 翻譯分享一下 : 原文:27
Re: [心得] 我在科技業遇到的鬼故事之一大家好我是原po,大家討論那的激烈,我覺得我需要補充一下。 我認為有一個癥結點需要解釋一下,雖然有可能解釋完結果可能更糟 XD 因為中間有一段,完全是我的臆測,我也沒有絕對證據去證實我的論點。 如果各位要反駁我,我也完全接受。 我主要是要講一下,為何我會覺得B應該被火?23
Re: [討論] 怎樣算是一個合格的junior cpp programme針對關於 TDD 的討論另外回一篇好了 覺得用推文太長了 XD : 推 stupidlove0: 朝聖!重要的真的是unit test 08/23 18:47 : → HZYSoft: 回樓上 TDD 問題,TDD 不只要測試,還要先寫測試才寫code 08/23 21:33 : → HZYSoft: 很多人無法習慣這種順序,是否一定要 TDD 這有爭議 08/23 21:3418
Re: [心得] 我在科技業遇到的鬼故事之一單純經驗交流一下 我遇到正常的軟體UT與品質驗證流程吧: 1.開發者寫完程式碼與UT。 2.在自己電腦上跑UT。 在自己電腦上跑UT,是部門不認的UT。11
Re: [請益] QA轉RD請益看到這文章就想到自己以前也是這樣想 給你我的歷程跟想法做參考 我目前是QA大概加減做了大約十年 歷程: QA -> iOS RD -> QA (目前) 先分析職位的 POC11
Re: [請益] 請問這樣的git使用方式是否是正確的?個人意見,僅供參考 不太確定常不常見,但看起來是合理的。 可以想到的好處和情況是 不同的service 可以分開Build,Build 之後的artifact 可以依照每個service 的開發進 度deploy 到不同的測試環境,利於不同進度的開發和整合。3
Re: [請益] 有人的公司也沒有提供API文件的嗎: : 安安 : : 小弟剛轉前端,進到一家接案公司寫網頁,工作大概9成都在接API, : 但公司內部沒有提供api規格文件讓我參考,