怎样才能做好被公车撞到的准备？

合理频繁的代码提交

文档

记录你的想法，你的设计和代码。

文档

记录你的bug修复_说明问题是什么，你是如何修复的，以及为什么。

如果你工作的环境中政策不严格（所以初级开发人员可以懒得提交文档修改–相关的文档更新应该在每次分支合并的时候_强制要求），缺少同行评审（所以初级/高级开发人员在可以理解的懒惰中被抓到），和/或文档与代码分开存储（所以很容易丢失），那么同样重要的是要考虑环境是否可以改变，使这些问题不至于出现。

话虽如此，但我不会总是把它说成是个人责任：最终，如果团队管理和/或组织不当，那就不是你的责任；如果你换了新的工作，我会把完成的文档交给我，然后想 “好吧，如果你不能正确地使用和维护这个，那就是_你的错………..现在祝你好运"。

这种思路在 "被公交车撞了 "的情况下并不适用，在这种情况下，你可能正在制定这样的政策，但还没有完成。在这种情况下，我只是建议你鼓励管理层（和你的高级开发人员）尽快开始认真对待这个问题。

不要做任何不同的事情。

你的同事和管理层应该考虑到这个问题，但我认为，指望个人贡献者的工作就像明天可能会被 “公交车撞上 "一样，这也太过分了。如果管理层对这里的潜在问题视而不见，那就意味着他们完全不在状态，或者说你并不像你想象的那样不可或缺。

充其量，如果你很慷慨的话，你可能会提醒关键人物和领导，在紧急情况下要有后备力量。但是，在这个企业为了短期利益而随意将事业 "扔在大巴车下 "的时代，你到底应该关心多少呢？

勤奋的工程实践解决了许多 "被大巴车撞到 "的困境。超越这一点，到了准备立即永久消失的地步，会给个别出资者带来很多开销。听起来，OP所描述的环境只需改进做法和人员配置就能让他受益，没有必要让他的工作好像随时会蒸发一样。

如果你是以承包商的身份工作，我想说这是你的雇主100%的责任。告诉他们，完成他们为你设定的目标，意味着你认为应该被视为目标的其他事情没有完成；问他们是否要调整你的目标。他们很可能会告诉你按原样继续下去，因为你的时间很贵，他们希望你的时间能得到最好的短期价值。

如果你是以员工的身份工作，你可能会有更多的回旋余地来规划接班人的工作（也可能有可能是期望你已经在做了）。

–日常的流程应该在一定程度上被记录下来，但很可能你的团队中的其他人也会遵循同样的流程，并且可以教给新人。如果你们不都使用类似的流程，那是当前应该解决的问题；聚在一起，争论一下哪种方式最好，得出一些标准（合意或上面强迫的），并使用这个标准，恭喜你，这个标准可以放到你的文档中，给新人使用。 –通过邮件、会议或随意的对话沟通的重要事情，需要把它变成共享资源，从共享驱动器上的文档文件夹到wiki的任何东西。有一种奇怪的信念（至少在我工作过的地方），即如果通过电子邮件将一些东西发送给团队的所有成员，那么这个团队永远都会知道这些东西；这并没有考虑到团队的组成会发生变化，而且任何培训（如果有的话）永远不会传递所有的知识，只传递一些常用知识的子集。比如说，如果你的客户要求你做一些看起来 “不正确 "的事情（"我不是领域专家，但你确定你要这么做吗？"），而你解释了你认为不正确的原因，他们确认这是他们想要的（如果他们解释了原因就更好了），那么你认为不正确的原因和解释正确的原因就应该被记录下来。 - 对于你遇到的任何需要花大量时间/研究才能解决的问题，记录下问题、症状、解决问题的捷径（即：知道你现在所知道的，从确定症状到解决问题的最快路径是什么），以及解决方案。症状对你的替代者来说真的很重要，因为在他们完全掌握问题之前，症状就会击中他们。 –前一点对于遗留系统，比如库或平台，新版本发布了但没有在你的产品中使用，这一点就更重要了。你在你的版本中遇到的问题（或者更糟糕的是，在几个遗留系统之间的交互中遇到的问题）可能会在未来的版本中得到解决，因此，缺陷的存在本身就会从公众的认知中淡出，直到几乎不可能找到有关它的信息。

假期是一个很好的 “训练"，让你为这样的事情做准备。这也有助于衡量你的准备程度。2-3周后回到工作岗位，计算一下你在清理 "积压 "上花费的天数和精力—这可以做一个像样的近似于 "撞车场景"。

如果你想改进，这也是一个有用的工具。分析一下你要解决的积压项目，问自己，有什么可以做，这样就可以由别人来做。在过去的一份工作中，这帮助我在不到一年的时间里，把 "假期积压 "的工作从大约三周的时间降到了两天。

–我的天啊，似乎只有我一个人有这些信息，我需要把它记录下来，让整个团队都能用。
该死的，除了我，没有人可以解决这个bug，我需要找到并培训一个后备人员…..

值得记住的是，一般来说，这被认为是你的管理层的责任，所以你做的任何超出要求的事情都是随意的。问问你自己，你有多想和总线因素战斗，并据此进行。

我想成为_可替换的人…..

• …这样其他人从仓库检查我的东西，就不用再找我了解不可维护的代码
• … …这样，其他人在issue tracker中查看我的记录时，就不需要我帮忙算出我在工作时的想法
• ….这样，其他人读我的wiki页面就不需要我解释记录在那里的东西

• . ….这样我就可以享受看着我做的东西是如何成长和发展的，过着自己的生活

• …这样我就可以专注于做新的东西，而不会被担心留下的东西分心。

问问你的团队。问你的经理。将问题完全按照你的方式向他们提出来，

给他们选择。为未来的开发者提供文档。为他们提供文档。为他们偿还技术债务。任何你能想到的东西。给他们时间估计。给他们选择的机会。让他们权衡一下你的日常工作。

嘿，他们甚至可能会决定这是一个值得冒的风险。但是，真的，这是由他们自己决定的。

而且，如果他们已经决定了要冒这个险，那么你的不死之魂就不要再为此感到内疚了。

我想伸出手去回答这些问题…..

我学到的最难的一课就是不回答这些问题。但要问出正确的问题，引导他们在毫无戒心的情况下，自己去寻找答案。

给出的答案和学到的教训是不一样的！

解释*

基本上有两种不同的情况，造成了OP所要解决的失败点。它也可能是不作为或没有认识到并解决不断增长的知识差距的结果。

无论如何，企业都会造成这样的情况，即他们对一个人或一小群人形成了超级依赖，这些人构成了他们知识库的核心。许多公司通过使用指导计划、交叉培训以及正式和非正式的知识分享来解决这个问题。

根据我的经验，在这一点上最成功的公司也是采用了教学的方式。我的意思是说，你很少会得到一个问题的 “答案"，而是由专家的讨论和提出尖锐的问题，引导你学习和扩展你对产品、工艺和技术的知识。教学确实可以一举两得。

员工

一般来说，你有两种不同类型的员工，最终都会走到这个位置。我称其为 "要去的人 "和 "保护者"。他是一个你可以分配任何任务或项目而不用担心的人。这些人是在公司中划出自己的利基，成为公司的 "利基人"，而且更有可能是有答案的人。他们认为，通过保护自己的知识，就等于保证了自己在公司中的地位、重要性和未来。

两者都会在不经意间创造出单一的失败点。

所以，简而言之，世界上所有的文档都无法解决单点失败的根本问题。是的，它很重要，应该是每个BCP和灾备计划的一部分。但是，文档并不是真正意义上的知识共享，在这个意义上，有人应该能够介入并执行你的工作任务，而不需要在手边浏览200页的文档。

在我工作的地方，我们是这样做的：

a) 我们用wiki来做文档。不是Microsoft Word文件，也不是文本文件。一个可搜索的、可完全跟踪更改的维基，等等（我推荐使用Confluence，但Confluence v4是个狗，我建议你去别的地方看看）

• 任何重复的或可委托的过程都应该被记录下来。应该写上 “这里是我们如何做的 "的核对表
• 核对表对建立团队非常重要，因为它允许任何人都可以按照清单来做流程…..

b) 版本控制，显然

c) 案件/问题跟踪系统，显然

d) 评论你的工作。这是最细微的东西，而且是那么难教，但作为一个承包商/独立的人，也许你能摸索到这一点。评论应该解释你的思考过程和为什么要做的事情。文档、Stack Overflow等链接为宜。段落和页数的评论是合适的。解释你尝试过和没有做的事情是适当的。代码最大的问题之一是，为了让某件事情以一种方式（而不是以另一种方式）运作而付出的心思和汗水都会被遗失。有一本书，类似于 "美丽的代码 "之类的东西，其中有一大块在一个大的开放的VCS系统Subversion或Git]&003中的单元中的注释块。它之所以很美，是因为它讲述了这个故事。下面是这个代码的工作原理。这里是它是如何工作的。这里是它是如何结构化的。(我承认，这一块，在我的印象中，可能没有大到 "为什么 "的问题。)

的一个推论是。有多少人回去编辑代码只是为了添加注释？我们都应该…..很多。但实际上，几乎没有人会去做。

Netflix有一个系统，他们称之为ChaosMonkey。它本质上是随机 “打破 "或模拟打破某些系统。

员工可以被认为是系统，而模拟打破员工的一种方法就是给这个员工突击性的、不定期的休息时间。ChaosMonkey叫你去看电影而不告诉同事。对于短期内，对他们的影响就像你被公车撞了一样。

这可以测试他们系统的稳健性，让他们发现系统中的新缺陷，否则可能会不被注意到。

这可以帮助知识转移，因为一个更稳健的系统很可能会有更少的破绽，而且需要注意的大漏洞也会更少，这样人们就可以把更多的精力放在系统如何工作以及为什么要做什么，而不是只追着烦人的问题去做，这样就会占用宝贵的知识交流时间。基本上FDIC建议银行对银行的主要员工实行至少连续2周的强制性带薪休假。员工的福利是次要考虑的。主要的考虑因素是，这将迫使银行任命其他人来承担离职员工的责任。如果离职的员工贪污，那么这个计划就会在替补员工的眼皮子底下土崩瓦解。这也意味着银行将不至于受到公车的攻击。

我想先从

1. 规范化****

2. 规范化和强制性的规范/项目评审

3. 具备团队精神

4. 显然，文件。这是一首老歌了。我就不唱了

规划这个问题是业务连续性规划的一部分，而这是对更大的灾难进行规划，而不是仅仅是对你被公共汽车撞到的灾难进行规划，但是这个过程中要把小的事件（比如一个关键人物被挖走）到大的问题（比如灾难导致建筑物和员工被毁，）的恢复工作都要到位。

Wiki-How有一篇关于如何创建BCP的文章，虽然我不建议你的企业实际使用这种方法，但它提供了一个很好的洞察力，了解创建BCP所需的流程和思路。一般情况下，BCP是分阶段进行的，先处理最大的风险，先为更可能发生的情况做准备，然后再处理低风险的问题。但每个公司一般都会根据自己的需求来建立BCP，所以具体的流程是不一样的。

我们每天都在反对人们把知识带入坟墓的规则：

–如果有人写了一个脚本/程序，那么别人必须第一个在生产中使用。 –如果有人部署了新的系统，那么没有人会使用或支持这些系统，直到他们能自己一个人在晚上不问别人的情况下，独自一人查找所有必要的访问凭证。它可以让你的后继者对你的工作进行逆向工程。

实际上，"未被列出/测试的东西对我们来说是不存在的"。只有被列出的东西才是可靠的

我们称之为 “arcane知识” 只存储在某人的脑子里），大家都拒绝行动，

显然，这在技术型和非技术型的题目之间是行不通的。但是，我们也不指望科技人员能从会计部门手中接过财务计算的工作。所以即使是我们的会计部门，如果只有1个会计做过这些计算，也可能会把 “知识带入坟墓"。

因为有一个限度。如果团队太小，那么总会有人会被公车撞到。

以下几点应该在你交给你的工作描述中，并由公司的老板确定。他们有责任将这些内容记录在案。 - 在为你的领域或组织建立的标准内工作。 - 记录你所做的工作。为它生成一个长的随机密码。将其打印在纸上。在上面签名。用信封封好，交给董事会而不是CEO。因为首席执行官可以和公司分道扬镳，但密码还在那里。告诉他们要安全存放，异地存放，而且它的用途(它可以在你不在的时候或者其他原因的情况下，给你网络上的超级用户身份)。