救場到佈場，我正在轉變的角色

忙了一天，帶著疲憊回家

已經超過下班時間，終於收到客服人員傳來「客戶問題已解決，請對方確認」的訊息，如果沒有其它問題，這次的客服需求就可以結案了。能夠稍稍鬆一口氣了。

雖然這次的問題處理不算慢，半天之內完成前期判斷，到後面的資料修復。但是在回家的路上，並沒有感受到解決問題的成就感，而是有一種深深的無奈。

曾經的工作熱情，在我不知不覺之中消失了許多，讓我開始思考哪裡出現了問題？現在的工作，與我心中的標準差距在哪裡？

我開始回顧這陣子，經常讓我有無奈心情的客服問題處理，試著找出哪裡不對勁。

希望讓組織因為我而變好，卻漸漸成為一名救火員

我習慣以多種角度來看待事情，作為行事的準則。而組織與客戶的觀點，也是其中一部分…

所以遇到客服需求，我通常會依幾個原則去處理

• 除非有其它事情真的分不開身，儘量協助處理，不讓問題被拖太久
• 儘早的提出對問題的初步判斷，讓客服人員能回應客戶，降低壓力
• 主動收集相關的情報分析，縮小檢查的範圍，加快查找問題
• 分析程式既有的規則，不只查到問題，也同時把造成問題的原因找出來
• 依問題的急迫性與影響，決定單純修正資料，或是進行程式的修正
• 處理問題之前，進行資料備份或復原計劃，處理之後，找相關人員確認後才結案
• 結案後，也會針對架構或流程面上的盲點，提出看法與修改建議

因為前面幾項原則，我得到同事在處理問題上的倚重，但是最後一項原則所提出來的建議，經常被忽略。
甚至因為問題被處理的太快，主管感受不到「調整架構」的必要性，把人力都拿去開發其它有亮點的新功能。

這樣子的結果，就導致了專案一直處在體質不良，甚至有部分流程錯誤的狀況下持續運作，出現客訴(失火)的狀況也不讓人意外了。

這種本該能夠被避免的問題，經常在我專注於其它事情的時候忽然冒出，打斷我的思緒。看著怎麼都處理不完的重覆問題，心裡面自然充滿了無奈。

良好規劃與前期建置工作，可以降低問題發生風險、讓開發聚焦

因此當我在設計系統時，會透過由不同的面向切入，去思考如何讓它能長期運作良好

• 資料結構如何設計？ → 保留未來彈性
• 哪些流程能自動化？ → 降低人為失誤
• 關鍵概念怎麼定義？ → 對齊理解
• 操作方式符合直覺。 → 減少繁雜的文件
• 程式架構的模組化。 → 在每個小範圍專注邏輯

雖然我無法百分之百在專案中把這些觀念實現出來，但通常有人問我專案問題，即使經過了數個月我還是能很快回答。
聽到新功能的需求，在聽到描述的時候，就能夠有實作的想法，並且有信心，在新功能加入後，其它的功能仍能夠正常的運作。

也因為這樣，所以絕大的部分的「救火」，都是我無法掌握開發的專案，看著那些能根本解決問題的方法（或隱患），卻遲遲沒有得到人力處理。
被拖入協助解決的我，看著只能治標無法治本的處置，心理滿難受的。

但一個人的能力有限，我無法把全部的事情統統攬在自己身上做完，我必須改變自己的心態，把有限的心力，用在重要的事情上。

如果我能看到問題，提出架構上的處理方案，就該保留能量來把它做好

既然我不可能靠一個人，在時間內把所有的工作做完，那讓開發中的每一個角色都動起來，不要讓自己熱心造成阻礙，就是一件重要的事情。

如果組織需要深切體會到事情的嚴重性，那問題就不該過快的被解決。需要讓問題被浮現、被看到，也該讓負責的人，不會認為「總有個人能救場與收尾」。這樣對於專案規劃的熟悉的人才會變多，而不只是經常在救場的我。

對於其它人負責的專案，不該過度熱心協助，讓他們有「問題不處理也不要緊」的錯覺。才會安排專案的人力去處理，讓實際接觸核心的人變多，讓經驗沒那麼多的新人，有機會了解為什麼出問題，以及要如何避免它們。

定義好自己的邊界，在提出想法與親自動手之間，找到平衡。認清自己的目標是在一起努力的團隊中，當其中一塊重要的拼圖，而不是一個拖著整個開發團隊前進。

要發掘自己多視角，架構觀點的重要性，有意識的保護它不被無窮盡的救火任務掏空了能量，這樣子的能力，才能發揮出來為組織創造價值。

而最後，應該就能夠得到價值產生後隨之而來的成就感，找回失去的工作熱情吧！