如果您的程序员中奖，如何确保您的公司不会破产？

我下面有几个程序员，显然他们都很出色，非常聪明。非常感谢你。

但是问题在于，每个人都对一个核心领域负责，而团队中的其他人对此一无所知。这意味着，如果将他们中的任何一个带走，我的公司将因为无法替代而破产。

我正在考虑引进新的程序员来掩盖他们，以防万一他们被公交车，辞职或其他任何事情所打击。但是我怕

1. 老式的程序员可能会主动抵制知识转移的想法，担心备份会降低其价值。
2. 我没有一个可促进不同开发人员之间的技术转让的系统，因此即使我要求他们这样做，也无法保证他们会正确执行。

我的问题是

1. 如何将它们交给老程序员，使他们同意
2. 您使用什么系统来促进这种“备份”？我知道您可以进行代码审查，但是有没有简单的方法来执行此操作？我认为我们还没有准备好通过检入代码审查来进行全面检入。

如何将它们交给老程序员，使他们同意

当然，向他们公开提出问题，以使他们不会将其视为威胁，而是使团队和项目更好地进行工作的机会。例如，“如果别人被解雇，我想让别人知道你所知道的事情”显然是错误的方法：-) “即使某些人去度假或生病，我也要确保项目的顺利进行”要好得多。

通常，开发人员自己在每次度假时都会遇到问题，因此他们需要为他/她掩护。而且，优秀的开发人员会为他们正在从事的项目感到责任，因此他们可能会同意这一想法。不过，请给他们时间讨论并（希望）致力于该想法。另外，让他们对在团队内部分享知识的方式和对象发表意见。事实证明，乔觉得可以和吉姆一起工作（并分享他的知识），但不喜欢杰克等。

您使用什么系统来促进这种“备份”？我知道您可以进行代码审查，但是有没有简单的方法来执行此操作？我认为我们还没有准备好通过检入代码审查来进行全面检入。

在我们的团队中，除了代码/设计审查，我们还使用

• 团队成员之间任务和职责区域的轮换（我们每个人都有他的主要职责范围，但是我们时不时地在另一个团队成员更熟悉的领域中执行任务）
• 面对面的知识转移会议（通常在上述任务需要时，也要在有人离开团队之前）
• 团队/项目Wiki

代码审查本身可能还不够，因为在许多领域中，开发人员通常要比直接从代码中读取的内容多得多。换句话说，也有领域模型。你可以阅读什么样的代码实际上做了，但没有模型，你不会知道为什么。

激励他们分享知识的一种方法是要求他们向他人做简短的演讲。程序员通常对他们的工作感到非常自豪，这将是一次展示它的机会。演讲是一个很好的机会，可以使他们展示一些局外人鲜为人知的怪癖。

此外，为什么不公开讨论并告诉所有人，如果有人被公交车撞到了，您都需要提出一个知识共享计划。我不认为这是不合理的。现在我公司正在发生这种情况，尽管有些人对此表示防御，但他们知道这是必须做的。

也许他们可以在某些事情上结对工作，如果他们具有好奇心，应该没有问题。

在开始雇用新员工之前，获取软件内部文档的最新信息应该是第一步。当然，这意味着您有价值的程序员将花一些时间在Office和UML工具上，而不是IDE上，但是我认为在任何情况下都是值得的。

拥有最新文档后，您可以让程序员进行交叉检查，以确保每个人都了解其他人写的东西。仍然不需要新人。

然后，您可以考虑雇用新人。是否可以，取决于公司的工作量。

如果您在大型公司中，可以致电HR并讨论此问题。相信我，如果关键人员被公交车撞到，会计人员也会遇到同样的问题。如果关键业务员在重要的谈判中变成僵尸，那么营销人员也会遇到很多麻烦-这种情况经常发生，或者有人告诉我。

我相信继承计划是正确的HR语言。您的公司可能已经有处理此问题的政策和框架。

我工作过的一个地方也有同样的问题。他们所做的是雇用一名初级开发人员与每个高级开发人员一起工作。他们创建了一个由2人组成的小型团队，共同致力于项目。每隔几个月或项目，他们就会在团队之间轮换初级开发人员。这样，高级开发人员仍然是主题专家，但是初级开发人员开始对所有系统以及它们如何协同工作有了很好的了解。此外，随着团队规模的扩大，项目的完成速度更快。

对于即将出现的大型项目，有时会要求高级开发人员在项目的整个过程中充当系统另一部分的初级开发人员，以便他们可以开始学习其他系统。

关键是要尊重现有开发人员的知识和资历，同时还要继续扩大和发展团队。这是一个缓慢的过程，但随着时间的推移效果很好。

使成功的开源项目如此成功的原因之一是缺少代码“所有权”。我的意思是，没有人是应用程序区域的唯一维护者，任何人都可以并且被鼓励为应用程序的任何部分做出贡献。我坚信这一点。

您想要做的是说明事情的方式实际上正在伤害您现在的团队。这是您想了解的要点，最好按此顺序：

• 如果您是唯一知道这是如何工作的人，那么我不能释放您去研究其他很酷的东西。
• 我们希望您能够度过一个愉快的假期，但又无法承受，因为没有其他人可以做您所做的事情。
• 人们因对当前职位不满意而更换工作是一个不愉快的事实，我们不想失去您，因为您感到被工作区域所困。

就个人而言，我不得不与一位去世的同事打交道。尽管没有任何信息孤岛，但损失仍然沉重。发生这种情况的可能性远低于上述第三个要点。

将案件放到那里后，请他们的帮助寻求有关如何解决问题的想法。当然要随身携带。他们的想法将帮助他们认识到自己是团队的一部分，而不仅仅是他们的专业领域所需要的。可能Jane可能对Joe所做的事情感兴趣，但对此感到有些害怕。知道可以帮助使知识转移变得更加有趣。您需要做的一些事情是：

• 对当前团队进行交叉培训。您可能会在短期内失去一点效率，但是在应用程序的一个角落可能会吸取一些经验教训，可以将其应用于应用程序的其他部分。让Jane和Joe在彼此的项目上合作一段时间。
• 培养知识共享的文化。我供职的一家公司进行了“棕色皮包技术讲座”计划。任何人都可以参加任何已批准的主题（通常介绍技术或软件过程）。该公司提供午餐，主持人得到了几百美元。
• 指导应该是一种生活方式。指导他人的目的是使您自由地做新的事情，并使您对公司更有价值。
• 寻找方法，跨越信息孤岛边界而不拉等级。您获得的乐趣越多，威胁就越小。如果您团队中的人像您所说的那样出色，那么他们可能对事情的状态并不完全满意。您必须判断团队是否可以处理它，但是您可以在“某某某周让我们选择”这一周。总是从这里开始。这个想法是让每个人都关注某某某人的职责，以及他们如何解决自己遇到的问题。只要您从头开始就行，他们就会想到没有人愿意承担工作

通常，尝试让他们印象深刻，您想使工作变得更有趣，并且需要他们的帮助。

实习生可能是一个好主意，他们将成为当前开发人员的直接下属，因此他们不会感到受到威胁。

随着公司的发展，您将既需要老开发人员，也需要在实习后成功的开发人员。

我认为这可能有效。

通常，当某个经理突然开始关心文档和继任计划时，这是一个强烈的警告信号，表明程序员将被解雇或解雇。它与典型的管理行为背道而驰，并引起了程序员的各种警告信号。

每个人都被告知要记录其所有程序和过程

“ 公司厄运警告标志 ”的第3级。

作为替代方案，一篇文章建议我们鼓励“ 向上或向外 ” 的文化，尽管反驳是很少有公司具有技术职业阶梯，而该职业阶梯在任何方面都类似于（错误）管理职业阶梯的财务和权力范围。包含。

以@ammoQ在他的回答中开始的完整文档的概念为基础...

一位好的经理要努力发展直接报告的技能，以便任何一份报告都可以代替他们。让您的开发人员了解，提供完全透明的工作的员工比将所有工作保密和隐藏的员工更有价值。如果“秘密”开发人员今天去世，对公司来说，要重新获得失去的知识将是巨大的成本责任。如果“全披露”员工今天去世，该公司仍将蒙受损失，但破坏力不会那么大。因此，“全披露”员工具有更大的价值。

任何试图保留隐藏知识以使其免于被解雇的员工，也使自己免于晋升。如果没有人能够完成他们如今所承担的繁琐任务，那么您就无法将开发人员带入更具挑战性和回报的职位。如果平凡的任务得到了充分的记录和充分的披露，那么您可以雇用新的初级开发人员来填补并将以前的开发人员提升为更高的职位。

这意味着您也需要记录您的工作并为每个直接报告提供培训。这样，如果您今天去世，其中一个人可以为您填补，直到找到一个全职的替补。

在开始引入新程序员之前，我会要求他们每个人帮助创建自己的文档遗产。

可以是Wiki，也可以是关于工作各个方面的三环圣经。

或者，如果您想要真正详细而透彻的文档，请雇用技术作家，采访每个程序员，然后创建所有内容的文档，每个人每天，每周，每月，每年都要这样做。

然后制作一个Wiki版本，以便程序员可以对其进行更新/编辑/参与/评论。

这样，您的系统就会随着时间的推移而增长，并且将成为任何新程序员的改进学习曲线。

坦白说，让程序员只停留在一个核心区域是不明智的，交叉培训，交叉核心工作确实值得。

然后，当1个人休假或类似时间时，您可以使用现有的人员。

每次您的一名程序员生病时，请反复向他打电话询问问题。

每当您的一位程序员休假时，请反复打电话给他询问问题。

他们很快就会意识到，对他们和公司而言，最好不要让一个人负责核心领域。

没有人愿意被公交车撞到，但他们也不想在短时间内接管别人的项目并维护他们的项目。这样，每个人都将面临破产的风险。

如果您正在孤岛中进行开发，则需要开始将人们从一个项目迁移到另一个项目。从文档，代码审查或修复简单的错误开始。任何小的代码保护/领土行为，都应在此之前解决。

在代码中只有一个专家是一种效率幻想。

有人想去度假吗？

由于管理层的愚蠢失误，我有更多的公司倒闭。如果一两个工程师离开，您将不会崩溃或燃烧，您只需花一会儿时间。Sheesh，我管理一个离岸团队，每个季度都会失去一个人。开始移动任务。今天。