編輯導語：在職場中，我們免不了要經歷工作交接。在這個時候，如果交接過程存在很多問題，導致交接效果很差，只會讓後面的工作變得更加困難。那麼，交接這個過程需要注意些什麼規範呢？作者結合了自己的經驗，談談應該如何對待交接這件事。
工作交接是無論身處任何行業、任何崗位都會遇到的事情，交接的原因也很多，因為入職、離職、崗位變動、工作重心調整、工作階段調整等等。而在交接中也會存在很多問題導致最終交接效果很差，讓原本順利的事情變得問題百出，讓原本困難的工作變得更加艱難。
所以想根據自身的經驗來聊聊應該怎樣對待和規範這個過程。
一、關於“交”的問題
無論因為何種原因，其他人要接手這部分工作，我們都要考慮這些問題。
怎麼給對方講能更明白，讓他快速理解？
怎樣能確保他的理解沒問題？
怎樣能避免以後他又忘了？
交出去的內容，後續對方又頻繁來問，是哪裡出了問題？
二、關於“接”的問題
同理如果我們是接手人，就要轉換身份來考慮上述的問題。
我需要交接人怎樣做，我才能更快速的掌握這些工作？
我需要怎樣做才能發現哪些關鍵問題有遺漏？
對方短時間講了這麼多內容，過幾個月我都忘了怎麼辦？
如果對方是要離職，那以後如果有問題不明白找誰問呢？
三、交接過程中常見的壞習慣
1. 沒有可參照的文件
大家在交接的時候，直接對著系統講，或者開發直接對著程式碼講，這裡是什麼意思，當時為什麼這麼做。一個講、一個記，也不知道講的人準備是否充分，也不知道記的人記得是否準確。
可能會講很久很久。稍微規範些的，可能會錄屏、錄音。
講完之後問一句：明白了嗎？
答：我消化消化，哪兒不理解再問你。
2. 文件內容不對
我們也許會有覺察，平時的文件和實際的應用之間存在一些（也可能很多）的差異。交接的時候依託文件內容會讓雙方都很懵，但是又沒有人來痛下決心持續更新文件。
尤其是某些功能經過多輪演變，你、我、他三方對此功能的認知又停留在不同的版本狀態下，後面再更新迭代就又很麻煩了。
不僅文件內容不對，可能開發寫的程式碼註釋也不準確，後期根據註釋理解流程時，又發現註釋、流程、文件三方不同。
3. 只有兩方參與交接過程
可能有人會很奇怪，交接不就是兩方的事情嗎，兩方參與有什麼問題？
這裡面會涉及三個問題：
接手人接不住，怎麼辦？後續有問題找誰？即便反映到領導層，領導對這些事情也不瞭解，那問題如何解決？
交出人講不明白，或者講的內容有誤，誰來識別其中的錯誤？
雙方認為交接完了，但是真的完成了嗎？是否需要有第三方角色的參與來驗證交接效果，或協助疑難雜症的持續推進呢？
因此我認為只有兩方參與的交接過程，是不保險的。除非接手人是後續此事的直接領導者或是交出人的上級。
4. 不主動
我曾經遇到過這樣的情況：
交出人提前發了一個文件和幾張截圖（很籠統的內容），然後說：你看完有啥問題，問吧。
接手人：你給我這麼個破玩意，啥背景現狀也不講，我**知道要問什麼嗎？
即雙方或某方沒有人主動因為此事而做準備，做約定，做事前溝通，真正交接時效率低下。
5. 個人的態度問題
上一點也屬於個人態度問題，但本條的態度問題是想著重強調大家對交接工作的不重視，以及後續工作中風險的預知程度不足。
尤其是此項工作的直接領導者沒有識別交接工作的重要性，任由雙方自由發揮。
6. 交接沒有持續性
就像我在上一篇文章《小問題，折射大風險》最後提及的，A交給B可能還好，但是沒多久B又交給C，C又交給D，這時候事情就很可怕了。
如果A沒離職，那A還會經常接到D、E的諮詢電話。而且這個電話是D打給C、再打給B、最後打給A，問題才搞清楚。這時就更加彰顯了交接流程、交接質量、交接持續性的重要。（嗯，沒錯，我就是那個沒有做好交接坑了很多人的A）
說了這麼多問題，其實大家也會有很多做好交接工作的想法和成功實踐，下面我來總結我的方法論。
四、我設想的交接流程
1. 有清晰準確的參照物
首先要準備豐富的交接文件，根據工作型別、工作內容不同，文件組成會有很多不同，在此不一一列舉。
但更重要的是，要有一個對所交事項的整體描述，這個描述是需要重新編寫的，包含工作現狀以及現狀的背景、原因，關鍵事項或關鍵流程，遺留問題及針對這些問題的規劃，後續的可預知風險，後續工作重點等等。
尤其是涉及到對外的關聯方、對接人，一定要介紹相關人員為人處世的風格特點，關聯方的實際情況及配合度等等。這些均要作為“交接目錄”進行逐一整理。
當然，工作過程中所產生的各類物料（文件、設計圖、程式碼等等）不標準、不完整、與實際不匹配等相關問題，屬於日常工作管理的問題，在此不做展開討論。交接時若能夠完善則需要儘量修改完善。但這一定是一項很龐大的工程，用功在平時，臨時抱佛腳的辦法一定不會太好。
2. 分批分階段按優先順序依次交接
交接物料準備完整後，在真正執行過程中，還要有的放矢，按照合理的順序和優先順序逐一講解、逐一交接，切勿一個大壓縮包發過去拍屁股走人。
就像我們在接觸一個新的業務、新的專案時，一定是要先搞清楚背景、關聯關係、整體流程，有了宏觀概念之後，再深入瞭解細節。交接也是如此，因為接手人就是要透過這種思維模式來快速上手，所以交出人按照這樣的邏輯講，最終的效果也會更好。
3. 有核驗流程
如何確認交接完成了？一定不是大家說完成就是完成。需求有評審、設計有評審、程式碼有走查，交接是否需要增加核驗流程呢？
我個人的觀點是，針對重點、中大型工作的交接，一定要有核驗流程。其他情況的交接可不做固定要求。
核驗形式多種多樣，既要不讓大家覺得形式化，又能簡單直接地達成目的即可。比如由領導進行關鍵問題提問（有點類似程式碼走查）；比如由接手人進行整體講解；再比如有一週的“試行期”等等，結合自身團隊的實際情況，制定相應的核驗規則。
4. 有領導或其他輔助崗位參與並協助
為了防止交接過程中講不明白、講不全面等問題，需要更有經驗的人（或pmo等角色）參與到此過程中作為協助者，並且此人可以執行後續的核驗任務，同時針對工作中後續的風險、待解決問題等關鍵事項，也可以協助解決。
其實直屬領導參與關鍵工作的交接是非常有必要的。
5. 從意識上加強，從流程上規範
工作交接的質量能夠反映出一個團隊的整體執行質量和管理質量，交接不明白的團隊，執行中一定會存在各種各樣其他型別的管理風險。但是大多數人，或大多數團隊對於工作交接並沒有引起足夠的重視，沒有為之付出足夠的精力。
因為交接不完整引起的後續工作問題，卻會極大增加團隊工作負荷度，進而花費更多的代價來彌補，因此今天特意以此為題進行整理，希望我們的工作能更好的推進，更好的流轉。
五、寫在最後
規則的設立和執行是非常困難的，如若因為困難而遲遲不肯改變，那後續的壓力也會越積越多，問題越攢越滿，直到大家不堪重負。
因此“重要但不緊急”的任務，應該是我們日常工作的重中之重，提升意識，強化管理，點滴執行，長期見效，才是團隊良性成長的模式。
其中提到的很多方法我也在實踐，也在不斷探索，有對有錯，有適合與不適合，希望大家也能辯證性的看待這些問題。到最後不都是為了更順利的工作，更健康的成長嘛。
作者：不想延期了，公眾號：不想延期了
本文由 @不想延期了 原創釋出於人人都是產品經理，未經許可，禁止轉載
題圖來自 Unsplash，基於 CC0 協議。
