交接心得

時間是交接的關鍵點。
花多少時間，交接人家已經累積了多少時間的工作業務。

隨著時間越來越久，
*　專案的程式碼
　　*　越來越多。
　　*　由於開發結束後追加的功能不符原先設計架構，顯得越來越雜亂。
*　文件
　　*　缺乏維護，內容越來越偏離現況。
　　*　不同時期為了不同目的產生的文件彼此內容不一致。
*　現職人員
　　*　經驗累積而成的解決問題直覺越來越強，難以完整地傳承給接手的人。
　　*　對於現有工作環境的潛規則掌握度高。

接手人員可能因為
*　經驗不足
*　沒有足夠的時間
*　(看到一堆文件程式碼就覺得懶)
對承接以上事項感到困難。

這些是交接職務內容的問題點：從一個不懂這方面業務的位置跳下去，連從哪裡開始找解答都沒有頭緒。也是所有接手者／接手者的主管必須面對的新手上路焦慮「如何在短時間內熟悉既有系統」，以及「連這種問題我都不會」的挫折感。

然而，在這個標榜「管理」的時代，希望透過各種手段，如文件的產出(系統分析書、系統設計書、程式說明書、測試報告…)、工作的規劃與規範(開發流程、程式撰寫原則、註解)等等，降低、甚至去除任何交接後新手上路的陣痛期，無疑反襯出現職者本身的價值，以及「管理」力有未逮的困窘：人無法完全由「精密的管理方式」變成一部泰勒主義所希冀的人肉機器。

所以我不太相信、也不喜歡一切都得「管理」這回事，因為始終會有那麼一部分由人類的潛能捍衛著，令「管理」無法完全攻城掠地，獲得100%的勝利。或許哪天「管理」會阿Q的說：我不在乎100%的勝利，99%就夠了，間接承認完全管理的不可能。