[故事分享]搞砸工作時第一時間往上報，後果是最輕的
Designed by Nijijourney AI
今天要說的是我在前公司砸鍋的故事。
前公司是軟體公司，我在那邊擔任前端工程師，負責維護公司後台網頁的介面跟資料串接。
先交代一下故事背景：
因為公司已經經營數年，後台的功能龐大又複雜。當時公司的品管(QA)處在一個斷層，原本公司的QA是FAE工程師部門負責，但因為公司轉型&擴大的速度太快，那個部門的工程師都被派去做新任務、新案件、既有客戶的維護，三天兩頭都在出差，就算勉強抽出時間測試系統，也都只簡單測過，通常都測不出問題。通常都要等到了客戶端實際案場測出Bug才會回報給我們研發部門(RD)。
這種狀況持續了好幾個月，常常出Bug都是我們RD在寫Code時自己發現的，或者客戶在案場實際出問題回報給我們，我們內部的QA等於是沒有。
問題是，客戶測出Bug時，第一個回報的對象也是FAE部門。
換句話說，在出新版本前FAE部門沒有詳盡的測試，Bug去到客戶那邊，最後遭殃的也是FAE部門。隨著我們的客戶數越來越多，回報Bug、安撫客戶的成本呈現指數型飆高，他們為了處理客訴問題，又更沒時間測試系統了。
以前公司規模還小的時候，覺得這些不太構成問題，反正人力都Cover得過來，但規模變大後，這些潛在的問題就紛紛冒出來了。
後來發現這樣真的不行，客戶回報回來的Bug越來越多，我的主管(研發部門主管)才決定我們部門底下自己養一個QA，這個QA不能被其他部門挪去做其他用途，就是專門在測試系統。
然後今天要說的我砸鍋的故事，就是發生在「新的QA已經進RD團隊，但還在培養途中」的階段。
◆
我砸的鍋有多嚴重呢？
公司主要賣出的重要模組，新增、編輯的功能都會壞掉。
就是這種靠北的程度。
這個Bug是我自己查出來的，那時候新版本剛出去沒多久，假設是2.2.0版本剛出好了。我閒著沒事在看Code，逛來逛去忽然發現某個地方壞掉，而且還是共通性很高的元件(Component)壞掉。因為我算是公司早期就入職的，大概知道公司主要的營運項目是哪些，我當下很明確的知道──
幹，這裡壞掉的話公司的電話一定會被打爆。
我就去查這裡是因為什麼改動才壞的──靠北，是因為我上個版本要修某個Bug，結果沒注意才導致這裡壞掉的。
但好在這個Bug只要修一行就可以完全修好，不用花太多時間。我認真看了一下這個Bug的出現時間──是2.2.0版本後才發生的，我開了另一個Server起來跑2.1.X的版本，確認沒有這個Bug，我就安心了。
由此可以總結：
- 這個Bug會引發的災情很大，必須立即處理
- 但是影響範圍只有2.2.0版本，之前的版本不受影響
- 2.2.0版本在我發現Bug的當下只出去沒幾天，有更新這個版本的客戶應該不多
- 這個Bug的解決方法已經找到，可以隨時更新
歸納完之後，我就直接跑去找我主管說這件事。然後問他：「2.2.0版本現在有哪些客戶更新了？」
我主管知道事情不太妙，就馬上打給FAE主管確認。幸好版本的確剛出去，只有一個客戶更新2.2.0這個版本。所以災情其實很小，事前告知FAE他們這個客戶更新的版本會有這個問題，他們之後也比較好應對。同時也得公告給整個FAE部門的人知道2.2.0這個版本不能使用，要等2.2.1版本再更新。
我的主管聽到我的報告後，糾結沒幾分鐘，就決定直接再出一個新版本把Bug修掉。
你們可能會覺得很奇怪，啊主管是要糾結什麼？聽起來為了修這個Bug直接出一個新的小版本很合理啊？
這就很值得一提了。
事實上發生這件事的前一兩週週會上，我主管(研發部門主管)才被副總念說不要這麼常出新版本，這樣會被客戶覺得我們公司的Bug是不是很多？穩定性不足等等。
還真的是啦。Bug滿多的。
一直在修，修得很快，但一直有新的，哭喔。
當時我的主管表面上點頭說是，但心底也是狗幹到不行。總之為了處理Bug過多的問題，才在RD部門找了新的QA來測試系統。我想我主管糾結的原因就是怕副總之前念過他的這句話，但不管是我，還是我主管，我們心底都很明確的知道一件事──
現在不處理，之後會死得更慘。
如果現在裝死，FAE在不知情的狀況下會讓很多客戶更新2.2.0這個有重大問題的版本，接著就是客訴接不完。
既然最後都是要修這個Bug，為什麼不在還不會有客訴的階段就解決這件事呢？
如果拖到那個時候才修，可就不是簡簡單單帶過、念一句就沒事的，到那時候應該副總跟FAE主管會一起狗幹我的主管。如果是不知情的狀況也就算了，知情不報不處理就是該電死。
好在我的主管沒糾結太久，直接指示我出一個新的小版本，把這個Bug處理掉。主管事後也沒責怪我，這件事就這樣平淡的結束了。
◆
為什麼明明是一個超級大包，最後卻能平淡的結束呢？
我認為決定性因素有以下這些：
１ 馬上查清影響程度（是否嚴重影響到使用）、影響規模（可能影響到多少客戶）
２ 馬上確認可以解決此問題
３ 把所有事情告訴主管，讓主管評估完決定要怎麼做
我們來拆解一下：
１ 的影響程度、影響規模其實是FAE部門最關注的，因為會影響到他們要如何應對客戶。
２ 是我的主管比較關注的，畢竟我們是RD部門。
３ 這是尊重上司的行為。儘管我心中已有定見（當然是快速處理掉最好），但最後主管決定怎麼做也是由他決定，而決定完的後果也是由他來承擔。
原本出了一個Bug，主要會影響到的就是我自己(要負責維修)、FAE部門(要被客訴、處理客戶情緒、額外出差版本更新)、我的主管(要被工作量額外增加的FAE狗幹、可能會接到一堆大客戶的電話、可能要去大客戶的會議室下跪、要盯我維修進度)，而這些可能性都在最前期就被消滅。
我想最關鍵的一點，還是同理吧。
如果我站在他們的角度，我也不想莫名其妙多一堆工作，所以我才會提早說出這些問題。雖然他們心底難免還是有「怎麼又有Bug了」的想法，但他們也知道這種東西越早處理掉工作量越少，所以也不會有太強烈的譴責。
就我的觀察，通常會有情緒、會想謾罵時，都是「不知道該怎麼辦」的時候。
我超討厭被罵，被罵我通常都會氣很久，那段時間根本沒辦法做事，我會把所有力氣都花在「不要成為下一個謾罵的人」上面。
所以為了不要被罵，我練成了「先組織好所有長官需要聽的資訊再去報告」的技能。
因為資訊已經夠多了，我也沒廢話，直接講重點。
通常我講完，長官會直接開始思考後續要怎麼處理，屢試不爽，就算是平常很爆脾氣的長官也一樣。
如果看到這邊的你，很害怕出包，總是不知道出包時該怎麼解決，你可以試試這個方法。
找主管前先確認：
- 問題的
影響程度 - 問題的
影響範圍 - 先想好1~3個
解決方案
問題還沒處理，找主管後要說的話：
- 「有空嗎？」確認主管沒有在接電話、忙其他事、情緒不平穩。有異常就盡量晚點再聊，除非是必須當下馬上處理的（例如辦公室起火…）。
- 開始說你出的包。不要說故事，兩句話以內講完你的包
造成的結果。 - 說明問題的
影響程度、影響範圍 - 說明你事先想好的
1~3個解決方案 - 問主管覺得接下來應該怎麼做
基本上以上幾點都有做到，你就算出包也不太需要擔心挨罵，反而會被稱讚危機處理能力好。
如果你已經處理完才報告：
- 確認主管有空
- 說明問題造成的
結果、影響程度、影響範圍 - 說明你的
處理方式 - 問主管有沒有更好的處理方式？還是照你現在的處理方式就可以了？
就算你已經解決了問題，還是必須讓你的主管知道發生了什麼問題。
主管的職責就是了解下屬的動向及問題，如果他不知道，其實他是失職的，我們沒必要在不知情的狀況下讓主管成為一個失職的上司。因此比較重要的事情最好都向你的主管報告，尤其是出包的時候。如果你出包後會自行解決，其實你的評分不會下降，反而會上升，你的主管會認為你是個值得託付的對象，升遷的機會會比較高。
以上是今天的分享，如果喜歡可以幫我按個愛心哦！
