前言
如果說要為軟體工程師的工作內容找一個合適且高層級的切分單位，我想專案這個名詞會是最為合適的，軟體工程師的身上可能同時肩負一個或以上的專案，每天的行程例如寫code、開會...等，也都是圍繞著負責的專案作安排。
最近在看著窗外發呆時，腦中突然浮現了以前看過無數次的一張圖，是以緊急與重要兩個維度來進行工作排序的二維陣列，長得像這樣
這張圖最主要的作用，是將手上的工作依照情況分類到這四個象限當中，並且從重要且緊急開始處理，慢慢消化待辦事項。
反思
然而這張圖再次浮現腦中時，用處並不是來協助排序工作，反而是有了工作內容的一些反思。
綜觀起來，這四個象限的工作對應到員工身上的影響會像下方這張圖
重要且緊急
從重要且緊急說起好了，這類型的工作往往是因為你對於業務的熟悉程度高於其他人，或者是恰好這項工作因為某些原因只你能夠勝任，因此落到你的身上。
而重要且緊急的工作做起來特別考驗手上工作的掌握程度，因為你需要在短時間內解決重要的問題，累積一定這類型工作的經驗後，對於公司業務的熟悉程度會明顯高於其他同事。
不重要也不緊急
如果發現被安排的工作，盡是不重要也不緊急的，照理說會很快進入茫然的階段，不明白自己為何在這，不明白自己為何要做這些事。
因為工作結果的被重視程度低，而且沒有立刻解決迫在眉睫的問題，也相對的難以取得成就感。
重要但不緊急
這類型的工作最為理想，因為能夠在貢獻公司與自我成長間找到平衡。
沒有立即性的需求要解決，但以長遠規劃來看能夠為公司帶來助益，而員工可以在完成這些任務的期間深入探索和學習，是屬於員工和公司的雙贏局面。
不重要但緊急
當手上充滿這類型的工作，會不斷地消磨工作熱情，講白了就是會心很累啦。
即便面臨的問題影響層面不大，但又需要立刻放下手上的其他事情，投入精神來解決，隱含的除了工作上常常被天外飛來一筆打斷之外，也可能受到既存且無法解決的問題困擾。
以後端工程師為例
回到文章一開始提到的專案，一個專案的生命週期大致會像..
而以後端工程師的角度來說，各類型工作在各期間的佔比大約會是
| 需求產生 | 設計 | 開發 | 測試 | 上線 | 維護 | |
|---|---|---|---|---|---|---|
| 重要且緊急 | - | - | 20% | 40% | 70% | 10% |
| 重要但不緊急 | - | 100% | 80% | 50% | 20% | 20% |
| 不重要但緊急 | - | - | - | 10% | 10% | 70% |
| 不重要且不緊急 | - | - | - | - | - | - |
前期的需求產生階段，大多會由 PM 和 UX 進行需求訪談，了解使用者的痛點，此時後端工程師的工作參與量不高。
設計階段則幾乎符合重要但不緊急的條件，可以在時程不趕的情境下完成技術決策，專案架構的設計，同時透過這段時間學習，奠定下一階段開發的基礎。
開發階段也能夠花足夠的時間 code review ， 雕琢整個專案的 coding style，和夥伴一起精進 code 的品質，而因為開發過程的 trail and error，可能會有一些小插曲的發生。
當到了開發中後期，到了測試階段時，QA 會設計測試流程和案例，模擬各種情境針對軟體做測試，這時會陸續發現一些 bug 或是設計上的缺陷，根據嚴重程度會決定處理的優先順序，開始有些時程上的壓力出現。
上線階段最令人期待，經過一段時間的努力，終於要推出產品了，不過此時出現的任務，通常會落入重要且緊急的情況，因為使用者已經能夠直接使用到產品，任何業務流程上的瑕疵都會影響到使用者體驗，更別說是牽扯到商業行為，嚴重程度就更不用說，因此問題通常需要在短時間內迅速修復或是找出解決方案。
維護的階段最為 tedious ，因為嚴重問題會在上線初期解決，這時工程師碰到的任務通常會是 known issue，在無法解決的情況下找出一個 workaround 處理，並在空檔時優化為了急忙解決問題所寫的 code，避免未來維護上的負擔。
結語
整體而言，作為一位後端工程師，喜歡的部份會是在設計、開發、測試，如果是有技術熱情的人，能夠在這段時間研究新技術，並實際應用到工作上。
而上線階段則是最能考驗工程師迅速解決問題能力的階段，因為面臨的情境大多是重要且緊急的。
相對較為無趣的就是維護階段了，因為當專案上線後，受限於服務持續運作的關係，很難做出重大的技術變革、升級，除非特殊情況，否則就是維持現狀並做小幅度的修正。
(綜合以上就是一些工作的雜談..)