專案公司到職半年，又過兩個月，這跟我想的不一樣。

續上篇，我所在的團隊總共有十七人，主要分成兩群人負責兩個專案開發，根據專案狀況調派人力支援，我也因此在另一個專案開發了大約一個半月的時間。

我所屬的專案內容是翻新客戶既有的兩項運作中服務，有兩個年份開發的不同版本，由於服務有對外開放API提供相關廠商與單位讀寫資料使用，為了維持輸入輸出格式不變，必須將原本使用不同語言寫成的程式邏輯盤點清楚。

然而解讀這原有的程式結構的步驟真是相當費工。不能照著舊版說明文件上提供的格式進行開發是因為程式本身也有與文件不對齊的情況，甚至兩份舊版程式的說明文件部分同樣的功能結構也是不一致的，實際碰到還需要決定照哪一份規格執行，真是非常麻煩。

員工到職有先後，因此出現前輩後輩之分，比較複雜或是影響層面較大的事項通常由前輩負責，這個專案也是如此，包含啟動多台機器分擔負荷的平衡附載設定、資料庫的安裝，以及後續維護的監控功能都是由資深的前輩負責。

當這樣的前輩離職的時候就出事了。

很不幸的，打算離職的前輩不只一人，因此後續維護的工作掉到我的頭上，我要和另一個前輩負責這個專案到年底，包含排定後續開發和測試的幾個小功能。

對我來說，現在最困擾的就是為了接手工作需要補上這段原本沒接觸的工作所需要的知識，包含設備如何設定、臨時發生問題的時候需要從哪裡檢查起，如何處理，這對我一個只開發了小部分功能的工程師來說實在太多要研究了。

此外關於操作的內部用說明文件實在是相當缺乏，包含在大版本更新，列出當天待辦事項由每個成員認領的時候，具體的執行步驟是「問他，他知道。」透過口耳相傳的方式，或者是自己研究網路上的資料之後找前輩確認這個執行步驟是否可行，而沒有已驗證過可行的操作步驟。

往不好的方向講，萬一正式時執行失敗，甚至造成危害時，聲稱執行步驟是與前輩確認過，對方也可能回應「我沒有這樣說」。實際上最近我被點出兩個月前照著文件開發，中途多次詢問前輩修改方式的功能，最近被一個前輩點出「你怎麼這樣做？你當初問誰？」這是兩個月前開發的其中兩個功能，我還真不記得當時問誰，但是這種暗示他認為我自己為了方便而改規格，甚至不肯看文件實際定義的狀況我真的不能接受，或許以後要考慮上班全程開著錄音筆？保護自己真的很重要。

因此上線前一天我在待辦事項的表單上，將負責執行的以及需要問我如何執行的項目都寫下具體的步驟，當天執行的時候得以參考。

其實以專案公司的立場，一般的案子負責的範圍應該是在測試環境測試，交付文件和程式之後在問題發生時負責找問題與修正，而正式環境的管理等等應該由客戶公司負責，但現在這個案子則不然，對我們來說可能出錯、需要負責的範圍變大很多，程式以外的錯誤例如資料庫設定也也需要研究。

當然這樣的結果是可以學習到更多東西，但是說實話非常累，這份工作除了消磨我作為工程師的熱情之外，最近甚至出現了「累到連假日都對原本的興趣提不起勁」的情況，真是糟透了。

自問「我到底願意為工作犧牲多少生活品質？」，這不是錢的問題，就算加薪也沒用，前輩曾說過的「有人要辭職通常都去意已決，留不住」，現在真是深刻體會到了，如果我提離職絕對不會反悔。

與人資進行心理諮商的時候得到意見：「你應該為了想達成的目標而留在公司，從公司的角度員工離職了一定能安排適合的人接替，不用把『這只能由我來』當成勉強自己留下的理由。」因此目前暫定先努力堅持到年底，一邊進行日常開發與維護，一邊整理對自己有用的筆記，同時找尋自己還有什麼留下的目標，如果真的找不到就年後提離職吧。