文檔。

經常提交頻繁的代碼。

文檔。

記錄您的想法，設計和代碼。您知道的所有陷阱。

文檔。

記錄您的錯誤修復程序說明問題所在以及如何解決，以及原因。

我還提到過文檔嗎？

如果您在政策寬鬆的環境中工作（因此，初級開發人員根本就不必費心提交文檔更改-相關文檔更新應授權和每個分支合併在一起），缺少同行評審（因此，初級/高級開發人員在大量可理解的懶惰中被捉住了），和/或文檔與代碼分開存儲（因此很容易丟失） ，那麼考慮是否可以更改環境也很重要，以免造成這些問題。否則，您的所有編寫文檔的工作可能都是徒勞的。

也就是說，我不會總是這麼稱呼它是個人責任：最終，如果團隊的管理和/或組織不當，最終，那不是您的責任；如果您要繼續從事新工作，我將交出完整的文檔，並認為“好吧，如果您不能正確使用和維護它，那是您的錯誤……現在很好

但是，這種思路並不真正適用於“被公共汽車撞”的情況，在這種情況下，您可能正在製定此類政策，但還沒有完全完成然而。對於這種情況，我只是建議您鼓勵管理層（和您的高級開發人員）盡快認真對待這些東西。

別無所求。好像明天不會被公共汽車撞到一樣。

“公交車撞車”問題是組織問題，不是您自己的工作目標中需要明確解決的問題。

您的同事和管理層應該考慮這一點，但是我認為，期望個人貢獻者像明天可能真的消失了那樣工作太過分了。如果管理人員忽略了這裡的潛在問題，則意味著它們與您完全脫節，或者您不是您想像中不可或缺的。

充其量，如果您很慷慨，您可能想要提醒關鍵人物和領導在緊急情況下需要備份。但是，在一個公司為了短期利益而一時興起地將職業“拋棄”的時代，您真正應該關心多少？

勤奮的工程實踐解決了許多“被公共汽車撞”的困境。超過此限制，以至於準備立即永久消失，將給個人貢獻者帶來很多開銷。聽起來，OP所描述的環境可以僅通過更好的實踐和人員配置而受益，不需要他工作，好像他隨時都可能會蒸發一樣。

如果您是承包商，我想說這是您雇主的100％。告訴他們，實現他們為您設定的目標意味著沒有完成您認為應視為目標的其他事情；問他們是否要調整您的目標。他們可能會告訴您按原樣進行，因為您的時間很昂貴，而且他們希望短期內獲得最佳的金錢價值。

如果您是員工，則可能會有更多的迴旋餘地規劃繼任計劃（或者可能已經期望您已經這樣做了）。儘管如此，還是要與您的團隊負責人或經理一起提出問題，因為他們需要了解問題以及您的狀況，並認為應該花時間。

有些事情可以幫助您進行計劃繼承：

• 應該在一定程度上記錄每天的流程，但是團隊中的其他人很可能遵循相同的流程，並可以向新來的人傳授知識。如果您不都使用類似的流程，那麼這是當前應解決的問題；聚在一起，討論哪種方法最好，達成某種標準（同意或強制執行），並使用該標準，祝賀標準可以在新手的文檔中使用。
• 傳達的重要內容通過電子郵件，會議或隨意對話，需要使其成為共享資源，從共享驅動器上的文檔文件夾到Wiki等任何內容。這種奇怪的信念（至少在我工作過的地方）認為，如果通過電子郵件將某些內容髮送給團隊的所有成員，那麼該團隊將永遠知道這件事；這並沒有考慮到團隊構成的變化，並且任何培訓（即使可能發生）也永遠不會轉移所有知識，而只會轉移一部分經常使用的知識。
• （可能是特定於軟件的）清楚地記錄違反直覺的過程或設計決策，重要的是要確定該過程被認為是違反直覺的，以及為什麼如此。例如，如果您的客戶要求您做一些看起來“不正確”的事情（“我不是域名專家，但您確定要這樣做嗎？”），然後您解釋了為什麼認為不正確的原因，他們確認這是他們想要的（如果他們解釋了原因，那就更好了），然後應記錄您認為它不正確的原因以及對原因的解釋。該軟件功能不符合規範不足以替代它，它們將與您遇到相同的問題。
• 對於遇到的任何需要花費大量時間/研究才能解決的問題，記錄問題，症狀，縮短解決方案的路徑（即：知道您現在所知道的知識，從識別症狀到解決方案的最快途徑）以及解決方案。症狀對於您的替換而言確實很重要，因為它們會在您完全理解問題之前先將它們擊中。
• 對於要使用新版本的舊系統（例如庫或平台），上一點更為重要已發布但未在您的產品中使用。您在版本中遇到的問題（或者更糟的是，在多個舊系統之間的交互中遇到的問題）可能會在將來的版本中得到解決，因此該缺陷的存在將逐漸從公眾的知識中消失，直到幾乎找不到它的信息為止。 / li>

假期可以很好地進行“培訓”，為此類事情做準備。它還有助於衡量您的準備情況。 2-3週後恢復工作，併計算清理“積壓”所花費的時間和精力-這可以近似於“按公交車撞車的情況”。

這也非常有用工具，如果你想改善。分析您需要解決的積壓項目，並問自己，可以做什麼，以便其他人可以完成。在過去的一項工作中，這幫助我在不到一年的時間內將“假期積壓”工作從大約三週減少到了兩天。

• ^{哦，我似乎是只有一個擁有此信息的人，我需要將其記錄下來，以供整個團隊使用。
  該死，沒有人可以解決此錯誤，但是我，我需要找到並訓練一名後備人員... sup>}

需要牢記的一點是，通常這被視為您的管理職責，因此您可以做任何超出要求的事情。問問自己，您想要多少來對抗公交因素並據此進行。

我想成為一個可替代的人 ...

• ...，以便其他人從存儲庫檢查我的東西時不必找我試圖理解不可維護的代碼
• ...從而使其他人在問題跟踪器中查看我的記錄不需要我幫忙圖我在考慮時正在考慮
• ...以便其他人閱讀我的 wiki頁面不需要我解釋那裡記錄的內容
• ...以便我可以欣賞自己製作的東西的成長和繁榮，過著自己的生活

...以便我可以專注於做新事物東西而不必擔心剩下的東西。

問您的團隊。問你的經理。按照您對我們的確切方式向他們提出問題。

給他們選擇。面向未來開發人員的文檔。他們的文檔。還清技術債務。您能想到的任何東西。給他們時間估計。給他們選擇。讓他們權衡一下您的日常工作。

嘿，他們甚至可能認為這值得冒險。但是，實際上，這取決於他們的決定。

如果他們決定抓住這個機會，那麼您不朽的精神應該不再對此感到內。

我想伸出手來回答那些問題...

我所學到的最難的教訓是不回答那些問題。但是要問一個正確的問題，以引導他們毫無疑問地為自己找到答案。

給出的答案與所學到的教訓不同！

解釋

基本上，有兩種不同的情況會創建OP要解決的單點故障。

業務

這可能是有意識的決定，也可能是業務計劃，流程或業務發展不佳的結果。也可能是由於無所作為或沒有意識到並解決不斷擴大的知識鴻溝的結果。

無論如何，企業都會創造這樣的局面：他們高度依賴單個個人或一小群人構成其知識庫核心的個人。許多公司通過使用指導計劃，交叉培訓以及正式和非正式的知識共享來解決此問題。

根據我的經驗，在此方面最成功的公司還培養了一種教學方法​​。我的意思是說，很少給您一個問題的“答案”，而是專家的討論和尖銳的問題，這些問題會引導您走上一條學習和擴展您對產品，過程，技術知識的道路。

這也為討論中的專家提供了新的見解和觀點。教學確實可以雙向進行。

員工

通常來說，您有兩種不同類型的員工最終都擔任這個職位。我稱之為“ 轉到”和“ 保護者”。

'繼續前進'是大多數經理喜歡的員工。他/她是您可以分配幾乎任何任務或項目而不必擔心的人。這些人是在公司中開拓自己的利基市場的人，是成為人脈的人，更有可能找到答案的人。

'保護者'是那個員工誰決定保護自己的草皮。他們認為，通過保護自己的知識，他們可以確保自己在公司中的地位，重要性和前途。

兩者都無意間造成了單點故障。通過始終提供快速答案來提供“ 轉到”，而通過不共享任何或所有信息來提供“ 保護者”。

因此，簡而言之，世界上所有文檔都無法解決單點故障的根本問題。是的，它很重要，應該成為每個BCP和災難準備計劃的一部分。但是從某種意義上說，文檔並不是真正的知識共享，因為某人應該能夠介入並執行您的工作任務，而無需事先瀏覽200頁的文檔。

不要回答這個問題；賦予他們權力，以便他們可以自己回答。

這是我工作的地方：

a）我們使用Wiki作為文檔。不是Microsoft Word文件或文本文件。 Wiki是可搜索的，可以完全跟踪更改，等等。（我建議 Confluence，但是Confluence v4是這樣的狗，我建議您去其他地方看看）

• 任何
• 應該寫出“這是我們的工作方式_____”的清單
• 清單對於建立團隊非常重要，因為它們允許流程可以由可以按照列表進行操作的任何人完成...

b）顯然是版本控制

c）顯然是案例/問題跟踪系統

d）評論您的工作。這是最微妙的事情，很難教，但作為承包商/獨立人士，您也許可以ok昧：註釋應說明您的思考過程以及所做工作的原因。指向文檔，堆棧溢出等的鏈接是適當的。段落和評論頁面是適當的。解釋您嘗試過和未做的事情是適當的。代碼最大的問題之一是，使某種方式（而不是另一種方式）工作的思想和精力丟失了。有一本書，例如“美麗代碼”之類，在大型開放式 VCS系統（ Subversion或我認為 Git）。之所以美麗，是因為它講述了故事。這是這段代碼的作用。下面是它的工作原理。這是它的結構。 （我記得，我承認，這個障礙可能不會深入到“為什麼”問題上。）

一個推論是：有多少人回去編輯代碼只是為了添加註釋？我們都應該...很多。但是實際上幾乎沒有人這麼做。

Netflix有一個他們稱為 ChaosMonkey的系統。它本質上是“破壞”或模擬隨機破壞某些系統。

可以將員工視為系統，並且模仿員工離職的一種方法是讓該員工免於宣布，計劃外的休假。 ChaosMonkey告訴您在不通知同事的情況下去看電影。在短期內，對它們的影響就好像您被公交車撞到一樣。

這可以測試其係統的健壯性，並允許他們發現系統中可能存在的新缺陷。不為人知。

這可能會全面地幫助知識轉移，因為更健壯的系統可能破壞得更少，並且需要注意的大型錯誤也將更少，從而使相關人員能夠更加專注於系統如何工作以及為什麼會執行它，而不是僅僅解決煩人的問題，這些問題會佔用寶貴的知識交換時間。

自從編寫了此答案以來，我已經意識到 https：// www.fdic.gov/news/news/financial/1995/fil9552.html。基本上，聯邦存款保險公司（FDIC）建議銀行對主要銀行僱員施加至少連續兩週的強制性帶薪休假。員工福利是次要考慮因素。主要考慮因素是，這將迫使銀行任命其他人來照顧空缺員工的責任。如果空缺員工在挪用公款，該計劃將在替代者的監督下分崩離析。這也意味著銀行將不會受到公共汽車攻擊的攻擊。

我將以

1. 標準化

   開始。 。每個人都使用他們想要的工具，他們熟悉的工具。重要的是使項目按時良好地交付。它用於可怕的代碼維護，其中一個項目將使用GWT作為表示層開發，而JUnit僅用於各種單元測試，而另一個開發人員則堅持使用原始JSP，而另一個開發人員則將JSF納入其中。每個人都束縛自己的項目，許多人都無法休假，並敲響了代碼審查和優化的喪鐘。

   我提議我們對多種行業標準技術和工具進行標準化，以確保我們所有人朝床的同一方向睡覺（用於ws測試的SoapUI，用於Web層並取得一定成功的JSF，用於後端處理的Spring和其他一些東西）。從此我們所有人都過著幸福的生活。當涉及將創建具有專有擴展名的文件的交易工具時，應避免任何個性化（或至少嘗試減輕它）；我

   如果有人擁有自己喜歡的工具，讓他們信任自己的生活，就讓他們將其提交法庭進行評估，並可能在整個團隊範圍內採用。您應該自己動手使用工具設置標準。好處是顯而易見的，每個人都使用相同的東西，並具有可接受的舒適度，因此有了不錯的設計文檔，任何人都可以撿起別人的東西繼續前進。

2. 常規和強制性法規/項目審核

   這是我上次演出的另一個功能。我們每個星期與我們的經理舉行一次小組會議，討論彼此項目的狀態，並提出關注和挑戰。我們所有人都非常了解下一個人正在從事的工作，有時會提出建議並提供幾行代碼來提供幫助。沒有完全隔離

3. Team Spirit

   我知道這似乎很陳腐，也許很容易，健康的團隊合作精神（可能還有一點競爭）可以促進信息共享。隔間環境（尤其是隔間中的團隊成員）的缺點是，團隊成員之間的工作距離通常太遠，以至於通訊崩潰很容易。當隊友彼此靠近時，最好是在開放式辦公室環境中，而牆或隔板很少，這樣可以更好地進行交流和信息共享。旨在促進信息共享的討論和討論將更加自由地進行。

4. 顯然是文檔 ​​strong>。這是一首老歌。我不會再唱歌了

ol>

對此進行計劃是業務連續性計劃的一部分，而該計劃的目的是計劃更大的災難，而不僅僅是您被公交車撞中，但是該過程將各個部分從小事故中恢復就像被偷獵的主要玩家一樣，遇到更大的問題，例如摧毀建築物的災難以及為建築物配備人員的人。

Wiki-如何在如何創建BCP上寫得不錯，儘管我不建議您在企業中實際使用此方法，但它可以很好地了解創建一個所需的過程和思維。通常，BCP採用分階段的方法來處理，以處理最大的風險，並先為更可能的場景做準備，然後再解決較低的風險問題。但是每個公司通常會根據自己的需求在此建立BCP，因此確切過程會有所不同。

該過程通常涉及：

• 確定風險領域
• 記錄涉及的過程
• 確定對各種場景的適當響應
• 制定應對場景的計劃

如果我提前兩個星期通知我該怎麼辦？

我做了一個簡短的概述，開始錄製屏幕和聲音的視頻。它包括：

1. 我將所有內容保存在哪裡。
2. 當前請求的示例以及我在此過程中的位置。
3. 如何進行演示以防某些技術水平較低的人員必須短期管理某些事情。
4. 如何在第一天建立的數據庫中查找事物以管理所有小事（剛開始工作時，您真的會發現自己不知道的地方。）。
ol>

我的目標是一如既往地為自己提供更好的工作。我盡量不要讓管理層設定我的標準。他們的工作是關注最終結果，我的工作是知道如何比他們做得更好。我不只是多餘的手。

我們的日常規則禁止人們把知識帶入墳墓：

• 如果有人編寫了腳本/例程，那麼其他人必須是第一個使用的人。
• 如果有人部署了新系統，那麼沒有人會使用或支持，除非他們可以獨自獨自在晚上查找所有必要的訪問憑據，
• 也有“代碼配置”和軟件自動測試。它使您的繼任者可以對您的工作進行反向工程。

實際上，“對於我們而言，尚未列出/未測試的內容不存在”。只有列出的東西是可靠的。 p>顯然，在技術主題和非技術主題之間不起作用。但是，我們也不希望技術人員能夠接管會計部門的財務計算。因此，即使只有1位會計師進行過這些計算，即使我們的會計部門也可能會採取“了解墳墓的知識”。

因為存在限制。如果團隊太小，那麼總會有人被公共汽車撞到。

以下幾點應在您的工作說明中交給公司，並由公司所有者確定。他們有責任做到這一點。但是，您可能是唯一知道這一點的人。

• 在為您的領域或組織建立的公認標準內工作。
• 記錄下什麼您會這樣做。
• 如果您偏離完善的標準以及為什麼這樣做，則要詳細記錄文檔。
• 記錄如何為組織記錄文檔。
• 如果您位於系統管理鏈的頂部，擁有root /超級用戶帳戶；創建一個具有最高安全權限的帳戶。為此生成一個較長的隨機密碼。在紙上打印。簽字。將其密封在信封中，然後交給董事會而非首席執行官。因為首席執行官可能會以惡劣的條件與公司分手，但仍然擁有該密碼。告訴他們安全地將其存儲在異地，並加以使用（如果您缺席或其他可能的原因，它可以在網絡上為您提供超級用戶狀態。