Thoughts💡如何在戰鬥型公司中生存
--
筆者曾任職 Yahoo ，《軟體需求溝通 ─ 從外商公司學跨部門協作開發》線上課程講師，紛絲團《程式猿吃香蕉🍌》
為什麼會寫這個題目呢？
主要是這 4 個月來的生活實在太精實，每天上班都像在戰鬥，部落格也硬生生地停更了 4 個月。最近公司夥伴聚餐，大家都像從地獄走過一回，同事還開玩笑地對我說：
同事：「知道你那邊也忙得很慘，我就安心了😎」
我：「？？？」(不能只有我忙到的意思嗎 😅)
這幾個月來，每天下班躺在床上都在想，要怎麼調整才能更有效率地完成工作。我明白世界上大部分的公司都不完美，邁向完美的路上需要過渡期，戰鬥型的公司就是在這個過渡期中奮鬥，而副作用就是會讓你忙到爆。
因此，我想討論的不是高大上的管理或改革，因為改變是需要時間的，我想聊的是「真實的每一天」，談談那些已經被丟在戰場上的勇士們，怎麼做好日常的小事，來面對各式各樣的戰鬥。
❶ 要有意識地做精力管理
人一天的精力 (Energy) 是有限的，在戰鬥型的公司會有大量消耗你精力的事件，就像遊戲中的小怪，輪番一刀刀地偷砍你，讓你不斷掉血，例如：
- 這個需求的 OOXX 我們討論一下？
- 查一下這個問題？客戶在問。
- 看一下技術實現，排期估一下？
然而，如果你的工作是需要高度專注的 (例如寫程式)，那麼被中斷後再恢復狀態是非常消耗精力的。
要有意識地避免中斷，不讓你的精力投入變成沈沒成本。
我們可以觀察一天內最常被 cue 的時段，把需要專注的工作延後或排在特定時段執行。例如 16:00 點前隨時做好被中斷的準備，先做「互動性」高或是「可被中斷」工作，例如：
- 回覆訊息
- 和同事討論問題：要事先條列好問題，被中斷還能接上討論
- 整理 Legacy Code：有 Unit Tests 保護，被中斷也不太會出錯
就像攀岩時有繩索保護，如果你進行的工作是有保護的，就可以不怕被中斷。
以上面的例子，你的「繩索」就是事先條列好的問題，還有 Unit tests。
另外，盡可能地在一天的「前期」，把資訊收集齊全，在「後期」需要高度專注產出時，就不必再問。例如：該要的文件/該問的需求都先弄明白，千萬不要一邊開會一邊開電腦弄自己的東西，盡可能「當下」把事情解決，節省來來回回溝通的精力。
❷ 建立自己的搜尋系統
同事：「之前那個 OOXX 的權限，你後來找誰開通的？」
同事：「之前你是不是做過 OO 的邏輯？你還記得是怎麼算的嗎」
我覺得建立自己的搜尋系統非常重要，簡單來說就是：
把做過的事存下來，方便之後找。
公司通常會有追蹤工單的系統，例如 Jira 或是 Redmine，要養成隨手更新工單的習慣：當時怎麼做的？找誰做的？ 如果這些訊息都寫在系統裏面，就可以快速搜尋出來。當作留給未來自己的一封信 (這些信救了我無數次)。
除此之外，以工程師來說，發過的 requests 可以存在 Postman 統一管理，程式碼片段可以寫 script 快速搜尋。為了避免工作時的「心流」被中斷 (能省一秒是一秒)，我把我負責的微服務監控 log 位置、程式碼位置、和系統配置位置等等都寫了 sccript ，可以配合快捷鍵直接開啟。為了工作效率：
盡量用搜 (Search) 的，不是用找 (Find) 的。
❸ 產出 (Output) 要能大卸八塊，方便分段驗證
在戰鬥型的公司做事情，需要的是快狠準，但是：
你怎麼知道你的產出是對的？
不但同事或問你，老闆也會問你！此外，當出現問題時，你能快速找到嗎？這點我們可以向會計 (Accounting) 學習，他們做財務報表的時候，是先從月報、季報編到年報。就像堆積木一樣，一層一層堆疊起你的產出 (Output) 。會計的產出裡面有明細、也有匯總，當懷疑數字有問題的時候，還可以分段驗證。
我們也可以用這種方式來組織你的產出 。以工程師來說，如果你的程式碼可以拆出 Unit tests 來驗證，又能拆出 API tests 來驗證，你做的軟體是能夠大卸八塊，分段執行，當有問題時，就比較容易找出 Bug 快速修正。
總結了三點心得，看似精簡但確實數個失眠的夜晚熬出的道理，字字句句都是真實血淚。如果你也在戰鬥型的公司中奮鬥著，希望這些小技巧能幫助到你，如果你有其他的技巧也歡迎留言讓我知道 :)
若是喜歡我分享的內容，歡迎幫我按個拍手，可拍 50下，給我一點鼓勵，或是加入我的粉絲團《程式猿吃香蕉🍌》，一起分享軟體知識與心得！
