作者查詢 / sirlers
作者 sirlers 在 PTT 全部看板的留言(推文), 共898則
限定看板:全部
看板排序:
全部Soft_Job136FORMULA1115ck56th32076MenTalk76Hearthstone60MobileComm46HOT_Game34NEHS19th433Suckcomic27Key_Mou_Pad25SYSOP13Android11C_Chat11Gossiping11movie11FuMouDiscuss6Ghost-Shell6Tech_Job6Beauty5EYESHIELD215Wallpaper5Browsers4Evangelion4PC_Shopping4TaiwanDrama4WomenTalk4BBSmovie3BuyTogether3cksh81st3203CultureShock3customers3DeathNote3EZsoft3GUNDAM3Hate3HatePolitics3Hunter3iOS3Japanese-B943KS94-3203media-chaos3NCTU_INT_NDL3NUU_ER3StupidClown3NTUE-EPC-982PublicIssue2RSSH93_3052TFSHS64th3092TWvoice2Adachi1AVEncode1B951010XX1BLEACH1book1Bus1CATCH1CCSH_92_3161ck-talk1ck48th3021ck50th3231ck54th3311ck56th3221ck57th3201CK85wisdom1ck_17_3011CSMU-D891CTSH923061Detective1e-shopping1erementar1FJU-Laws941FJU-Laws951FJU_JCS71FJU_PSY0941FJUStatG941FlashWolves1gallantry1Gintama1Google1HC5th-3121Headphone1HSNU_10081HSNU_10151HSNU_9271HSNU_9511HSNU_9631HSNU_9751IME1ISU_MSE_931joke1KenAkamatsu1KS92-3011KS94-3011KS94-3021KS94-3091KUAS_IEM941Kusan_89-3121MCU-LAW1NCCU05_ITMBA1NCCU06_PSYCH1NCHU-AGR021NDHU-MSE921NDHU-phy951NDMC-D621NDMC-F81NDMC-N561NDSH1NTNU_bridge1NTPU-STAT941NTU-EM921NTUCH-901NTUdent941NTUEOE_R4021NTUJapan1NTUJudo1NTUphy941NTUPP-871NTUSTMIS_M941NTUT_EE490A1Ocean1RSSH90_3021RSSH91_3021RSSH94_3061SCU_CIS-92A1SFFamily1specialman1STDM-91-3111Steam1Storage_Zone1TA_AN1Tennis1THU_BA20001THUAS_911Tin-Ha1TKU-ee-91a1TNFSH96101TSH93_11TTU-AMath1TTU-ME941tyart1TYSH49-3021TYSH50-3031VET_941YP90-3101YP94-3041<< 收起看板(145)
195F→: 這是哪裡的市區高架沒有隔音牆呀?223.137.139.205 05/14 19:04
114F→: A男是啥男性向后宮作的主角嗎?01/03 17:02
37F推: 推分享 這樣的流程好好導入原原po就無從把自己team的鍋07/28 13:18
38F→: 推給B囉07/28 13:18
15F→: 你不如說說為什麼A在被你review過issue確認可以close以07/28 00:10
16F→: 後還被懲處吧 你有坦住你下面的RD嗎? 尤其他還是你身為P07/28 00:10
17F→: L卻沒把客戶需求釐清的第一受害者07/28 00:10
18F→: 檢討B的紀律問題跟你們project出bug真的有關?07/28 00:11
23F→: 所以B不是被認定這個事故該負責的人嘛07/28 00:13
32F→: 所以B鬼的點在哪? 沒有紀律自業自得 但你是不是該學學B07/28 00:15
33F→: 主管怎麼維護自己的戰力?07/28 00:15
57F→: 奉勸原po別再糾結B心態如何 A被提報出bug時你身為最初埋07/28 00:22
58F→: 炸彈的人是否出來坦坦承這是你的錯誤導致的?07/28 00:22
61F→: 重點在A沒有做錯07/28 00:24
73F→: 你認為他為什麼會寫出沒考慮到LAGG的bug? 是不是你提供07/28 00:28
74F→: 他的spec跟測項沒有? 那這bug是誰的責任?07/28 00:28
77F→: 好 那麼A的1/10是不是該算你這?07/28 00:29
90F→: ok 那麼issue close時A提供的解方也還是沒有涵蓋到這 你07/28 00:33
91F→: 是review的人 A還是要擔這1/10?07/28 00:33
94F→: 你是leader, review這個點是可以用來保護A的你知道嗎?07/28 00:35
142F→: 最終結果走了3個戰力 如果這樣可以視為老闆排毒成功 我07/28 01:12
143F→: 也沒啥好說了 就祝福原po及其部屬07/28 01:12
9F→: QA建完測項沒跟PM/leader核對過需求嗎? 這補述B根本該007/25 20:23
10F→: 責 真的做出release到客戶端的是QA呀 你們這流程B當時的07/25 20:23
11F→: 確就該commit了07/25 20:23
21F推: 你說"原本以為" 那現在回看呢? B作業上的疏失在哪?07/25 20:34
34F→: 那再問你們這制度B該怎麼擋? 是要他承擔QA責任?07/25 20:56
35F推: 這篇問題二就說了 該issue身為項目負責人的原po是給關的07/25 21:07
36F→: B真要HL是要越級申訴到大老闆嗎?07/25 21:07
41F推: 更何況"HL到客戶"云云更像是氣話 實際上pick commit去re07/25 21:09
42F→: lease的也是QA07/25 21:09
50F→: 我是認為很多推文有被原po單方說詞誤導為道德瑕疵 其實B07/25 21:12
51F→: 更像是被抓住話柄被往上報的冤大頭07/25 21:12
54F→: 故意一說 也可能是會議上被話語究責擠出來的07/25 21:13
67F推: 這要看怎麼問 技巧性的釣話也可問你"你是故意commit的嗎07/25 21:26
68F→: ?" 當你明知道bug不是你出的時候有誰會說"我code是不小07/25 21:26
69F→: 心commit的"07/25 21:26
72F→: 調查中真正該問的是"有疑慮怎不提出來" 而不是"你是不是07/25 21:27
73F→: 故意進code?"07/25 21:27
81F→: 但主持會議的就是給issue過的原po 球員兼裁判當然不會把07/25 21:28
82F→: 火往自己身上引07/25 21:28
94F→: 補充的B處理不正是說明B沒有"release bug到客戶"的意圖07/25 21:39
95F→: 嗎? 他是要凸顯問題還在 看能不能被後來QA release前抓07/25 21:39
96F→: 到呀07/25 21:39
98F→: 我是不懂原po為什麼會因為氣B沒有被火而離職啦(前篇1:3007/25 21:42
99F→: 原po推文推文)07/25 21:42
110F推: 挑commit release明明是QA幹的 把沒測出來都責任往B身上07/25 21:48
111F→: 丟上 這卸責手腕我給10007/25 21:48
112F→: 舉報B的是QA07/25 21:48
118F→: 真要說根因我會認為需求根本沒釐清 從上到下LAGG都不在07/25 21:56
119F→: 團隊視線範圍內 B也是意外才打到這個測項沒有的情境07/25 21:56
137F→: 如果B跟主管真有套過 那還真沒套好 commit前沒測過這點07/25 22:13
138F→: 是可以抓著鞭的 他們該套的說詞是"有測過,但因為LGAA測07/25 22:13
139F→: 項修好沒測出來所以commit" 保證責任一乾二淨07/25 22:13
142F→: 套過那句就不會出現了07/25 22:16
147F→: …我怎麼覺得現在像在玩海龜湯07/25 22:19
242F→: 為了單一無法再現的bug再生一台機器不符比例 歸根結底問07/25 23:49
243F→: 題還是在需求沒弄清楚 甚至可以說B測出有問題時的環境不07/25 23:49
244F→: 符合RD收到的需求07/25 23:49
347F推: 不 真正啟用的是QA 我認為B在那個時點commit是應當的07/26 12:48
348F→: 他的失誤是沒有在commit前再run一次 但從事後反推可以得07/26 12:48
349F→: 知 就算他run了 因為LGAA已解他也是打不到bug的07/26 12:48
354F→: 第一順位也不是B呀 注意身為PL的原PO看過issue是同意關07/26 12:55
356F→: 閉的喔 那來支援的B要HL到哪去 不就是只能進code期望問07/26 12:55
357F→: 題能被突顯嗎? 結果release前QA沒有測出(因為根本不在測07/26 12:55
359F→: 項內)07/26 12:55
371F→: pick commit+release都是QA07/26 13:01
373F→: 啟用功能內部測試才更有可能測出問題不是嗎?07/26 13:02
377F→: 沒有 因為bug close不會有人去解的07/26 13:04
378F→: QA pick commit表示至少還要再build一版 正常來說這裡會07/26 13:06
379F→: 測過以後再release 如果測出問題就不會用有問題的commit07/26 13:06
380F→: 了07/26 13:06
384F→: 哈哈 QA有問題的其實也不是這個時點 而是更早建立測項的07/26 13:11
385F→: 時候就沒有cover需求(不確定是PM或是PL的鍋, 也可能是客07/26 13:11
386F→: 戶真的沒講清楚 這就開發日常)07/26 13:11
423F推: 嘿我有不同見解 這件事根源是在需求就沒搞清楚 請問這是07/26 18:31
424F→: A或B的鍋嗎?07/26 18:31
425F→: 再來對於issue close, PL都下來看過issue也同意解法給過07/26 18:31
426F→: 那麼責任就已經是在PL這裡了07/26 18:31
427F→: 接下來B沒run過就commit可以算他一筆 但就結果來說(LAGG07/26 18:31
428F→: 已解 run也打不出bug) 他這個過失根本不影響最後會爆在07/26 18:31
429F→: 客戶那 整件事故的究責不該燒到他07/26 18:31
430F→: 甚至嚴格點說 LAGG就不在最初RD收到的spec裡 B報這個bug07/26 18:31
431F→: 反而還不符合需求環境咧07/26 18:31
432F→: 我認為A真正不爽的對象會是他的主管也就是原PO,責任明明07/26 18:31
433F→: 該在PL頭上最後受罰的卻是底下RD07/26 18:31
442F推: super你看下這篇原po提到的錯誤三 基本上客戶端需求他跟07/26 18:42
443F→: QA應該是可以弄清楚的 但這點沒做好07/26 18:42
448F→: 我個人會定調這就是個事故 而且最後客戶資料也有救回來07/26 19:03
449F→: 實質上的損傷是很小的 如果公司真的無法承受那該改進的07/26 19:03
450F→: 是更嚴謹的流程 若還要下懲處那還是快逃吧 (除了B該因為07/26 19:03
451F→: 上code紀律問題扣點考績)07/26 19:03
472F→: 我同意B沒有run過就commit是有問題的 但我想爭執的點不07/26 23:26
473F→: 在這07/26 23:26
474F→: 假設今天B實際上在commit前run過 且從原po事後回推我們07/26 23:26
475F→: 可以得知 當時LAGG的測項問題已經解掉 所以A的bug不會被07/26 23:26
476F→: 他打到 但若你身為B確信該bug並沒有解掉 你會如何行動?07/26 23:26
479F推: 只是卡著不上code? project leader來催你呢?07/26 23:35
483F推: 我們單講這個project就好 你認為這邊B不能上的理由在哪?07/26 23:39
484F→: B的心證嗎?07/26 23:39
487F→: 要等多久驗證才夠?07/26 23:41
490F→: 沒有 以B來講已經無法復現了 因為LAGG測項已經修掉了如07/26 23:45
491F→: 同這篇B主管跟原達成的結論07/26 23:45
504F→: 所以我可以理解為 super願意把自己整合的code交給別人co07/26 23:59
505F→: mmit 是吧?07/26 23:59
510F→: 我還以為只是對fail fast見解不同 原來連合作模式都不一07/27 00:03
511F→: 樣 好喔07/27 00:03
13F推: 因為追究根因"需求未釐清" 會燒到主持究責會議的PL原po07/26 12:16
14F→: 還有早早就甩鍋的QA呀07/26 12:16
67F推: bug開著卡了feature三個禮拜 扛feature成敗的人不應該等07/23 04:10
68F→: 問題流到客戶那裡才知道吧? 這種有跨team爭議不需要長官07/23 04:10
69F→: 出來協調嗎?07/23 04:10
104F→: QA把關不到位 A程式品質差且態度消極 B錯在選了最差的方07/23 08:57
105F→: 式HL 最大問題是issue嚴重程度明顯被低估就放行了 不過07/23 08:57
106F→: 這個故事裡缺了好幾個該把關的角色(A,B主管) 也許還是看07/23 08:57
107F→: 看就好07/23 08:57
222F推: 樓上這就雙標了呀 認為公司死不是他的事的人豈不是允許b07/23 15:39
223F→: ug被關了的所有人嗎?07/23 15:39
229F推: 那怎麼對B就那麼嚴格呢? 這bug甚至不是他弄出來的 他的f07/23 16:16
230F→: eature被卡也要要有個停損點吧? 怎麼就變不顧公司死活了07/23 16:16
304F推: 鬼故事的點難道不是B主管神隱嗎XD 不管是要推或扛至少站07/23 19:31
305F→: 隊自己底下的人吧 能夠硬commit出事主管怎會無責07/23 19:31
1000F推: A的責任在 面對B這樣不願提供環境資訊者 沒有想辦法拉高07/24 02:07
1001F→: 層級來解07/24 02:08
1002F→: B的責任在 面對A這樣擺爛直接把問題拉高層級到客戶07/24 02:08
1026F推: 這邊我倒不覺得not reproducible 不能是issue close的理07/24 02:19
1028F→: 由 因為如果issue真的不存在或是已經因為其他人進的code07/24 02:20
1029F→: 剛好解掉都是有可能發生的. 有問題的地方在A去要環境資07/24 02:20
1030F→: 料而不得 這時不該直接以不能重現關掉07/24 02:20
1052F推: "A很誠實的把自己的擺爛呈現在issue的close reason欄位07/24 02:32
1054F→: 上" 這描述不知道是不是兩方都可以接受07/24 02:32
1058F推: 當證據可以啦 改了會有紀錄07/24 02:34
1075F推: 喔喔 要回來討論"都不escalate" vs "直接escalate到客戶07/24 02:44
1076F→: " 哪個比較嚴重了嗎?07/24 02:44
1127F推: 半夜三點,抬槓停不下來。是愛吧? 嗯,是愛。07/24 03:07
1326F推: 也許不會 但能減低自己被他人擺爛造成的專案失敗而拖累07/25 03:45
1327F→: 的可能性 畢竟當下身為B也無從換掉上游的A07/25 03:45
76F推: 同意12/12 23:58
37F推: 好像不少版友認為在VSC那邊跟在Max後面換胎的話優勢會小12/12 23:53
38F→: 於 用20幾圈白胎領跑? 小弟覺得Ham沒不至於那麼差 在車輛12/12 23:53
39F→: 優勢這麼明顯的情況下會超不回來…XD12/12 23:53
95F推: VSC那邊不跟著換就是明擺著讓Max 23圈的白胎 有這種自信12/12 23:23
96F→: 可以保持領先的話 我是不懂為什麼不用更新的胎讓優勢更大12/12 23:23
97F→: 除非AMG自認白胎用20幾圈跟新胎會沒差多少…12/12 23:23