一位非常了解，知道如何并且准备在他的草地上扑灭大火的员工当然做得很好。 但是，如果这个英雄去度假甚至辞职，困难时期就会来临。 事实证明，不仅要了解很多知识，而且要能够分享这些知识很重要。
Aleksey Troshin（
morroz ）从事该行业已有近20年，自2002年以来一直担任项目和产品经理。 在此期间，他曾在多家公司工作，领导2至150人的团队，现在负责FINAM的开发。 Alex在这里建立了一个系统，该系统不仅有助于传播知识，还可以激励开发人员朝着正确的业务和团队方向发展。 但是，并非所有团队都使用该系统。 怎么了 我们了解了这一点以及所使用的方法。
该文章基于Aleksey Troshin在Saint TeamLead Conf上的一份报告，该报告讲述了FINAM如何传播知识：绝地的力量和技能如何增长，帕达瓦人如何训练以及在力量的黑暗面发生了什么（没有它会在哪里）。产品和FINAM IT团队
首先，我将讨论一些产品来确定公司的环境。
网站Finam.ru-关于金融主题的第1号站点，其中包含许多具有金融信息的不同部分以及有用的服务，例如，在线股票商店。 例如，您可以购买一股苹果股票并将其送给某人过生日。
FinamTrade交易平台 ，对于初学者也有
零佣金率。
Comon.ru-专业交易者的自动重复交易系统-为初学者和没有足够空闲时间创建自己的投资组合的投资者提供的解决方案。
交易者的社交网络等等 。
FINAM IT是150人，分为25个团队。 发展只是内部的，我们几乎没有吸引第三方公司来满足我们的需求。 标题图片完美地展示了我们如何安排一切。 团队的组成可以不同：有些团队有产品负责人，但是没有测试人员，例如，其他团队有测试人员，但是没有产品负责人，但是有分析师。
在开发中，我们使用不同的技术堆栈：
- 前端：React.js，VUE.js。
- 语言：C＃，PHP，C ++，Java，移动。
- 数据库：MSSQL，PostgreSQL，Oracle。
- 平台：SharePoint，1C，Diasoft，MS CRM等。
当我第一次加入公司时，我们试图吸引团队，产品和关系。 结果是一个如此复杂的计划，其中圆圈表示我们正在开发的产品：
通过颜色，我表明团队的组织方式不同。 有些制造一种产品，另一些制造几种产品。 而且有些产品是几个团队同时开发的（例如，内部后台）。
我将以两个团队为例讲故事，我将有条件地称为团队1和团队2。
一队
第一小组开发了一个内部信息系统。 最初，它看起来像这样：
- 一名员工是该平台当前版本的专家 。 由于不再支持旧版本，因此有一个任务要将该平台转移到新的导轨上。
- 我们聘请了一位新员工，他是该平台新版本的专家 。 他参与了将所有功能移植到此新版本的工作。
2队
第二小组开发了几个内部系统：
- 一名员工是一个系统的专家 。
- 另一名员工是其他系统的专家 。
- 某些系统是由两位员工共同开发的。
关于专家
在上面的文本中突出显示“专家”一词并不是巧合，我想澄清在这次对话中谁是专家。 作为《星球大战》的主人，这个人拥有力量：在他的学科领域，技术和产品方面的深厚能力。 这通常对于企业来说很方便，因为它提供了一个切入点：询问专家如何做或何时完成，如果这是新任务的问题，或者询问是否有故障或工作不正常。
我想像电影《星球大战》中的绝地大师这样的专家-他可以做任何事情（好，或几乎所有事情）。
但是绝地专家有其缺点：
- 他需要被“抬高”很长时间，才能得到这支部队。
- 当他休假时，总是这样：“我们所有人都要做什么？”
为了克服这些弊端的影响，我们开发了一个维护能力矩阵的系统，我将在后面讨论。 我注意到我们并没有在所有团队中实施它，而是仅在有问题的地方实施。 最糟糕的是小团队。
我们最头疼的问题是“如果专家发生什么事情（如下图所示，尤达大师），将会发生什么？”
您可能还听说了总线系数的概念。
总线系数
总线系数是衡量单个项目成员之间信息集中程度的一种方法。
在Wikipedia的定义中，该因素决定了项目参与者的数量，在失去参与者之后，其余参与者无法完成项目。 按照惯例，这意味着必须有多少人移动公交车才能使该项目发生无法挽回的灾难。
当您只有一名专家时，总线系数等于1，也就是说，项目的所有风险都由一个人掌握，这是很糟糕的。
历史的一个例子：2010年，在斯摩棱斯克附近发生了一起飞机失事，包括波兰最高领导人在内的96人丧生。 此事件发生后，波兰批准了一项规则-国家的四位最高领导人（总统，总理，参议院议长，下议院议长）在任何情况下均不得一起飞行。 这是针对总线因素的保护因素。
如您所知，在第1和第2小组中，专家不可互换，这会带来潜在的问题。 必须采取一些措施来增加总线系数，并扩大绝地专家的能力。 我们已采取以下步骤。
步骤1.增加总线系数
绝地不应该一个人呆着。 因此，有必要训练和训练绝地，以便有更多的人。
我要澄清一下，
绝地是一个角色，而不是一个能力 。 绝地可以复活。 第二个角色（就《星球大战》而言）是绝地的弟子
Padawan 。 他努力使绝地的知识充实，并在休假时取代他。 而且，可以有一个以上的Padawan-如果团队很大，我们可以一次种植多个Padawans。 但是绝地仍然是主要的决策者。
当我们决定谁成为绝地武士时，我们就Padawans达成协议，分配角色并将其可视化在管理表中：
这是水平产品，区域或模块。 例如，如果产品为1C，则可以是“薪资和人事”或“会计”或其他模块。 垂直列表示员工。 在十字路口，我们输入角色-谁是绝地武士，谁是帕达旺人。 这样可以产生清晰的分布。
我们商定了一些开始分发的规则。
分配规则，第1部分：- 一种产品，区域或模块-一种Jedi 。 我们记得我们要保持专家级和负责任的“一站式服务”的便利。
- 至少一个Padawan 。 这与总线系数有关，越多越好。
- 绝地武士的均匀分布 。 为了不让员工超负荷，公平起见。
似乎所有内容都是逻辑分布的，结果是这样的：
在第一个团队开发一种产品时，一个人开发旧产品（Sunset），另一个人开发新产品（Sunset 2.0）。 在产品的“自己的”版本中，该员工被视为绝地，而在“异形”的版本中-Padawan被视为另一名员工的学生。
在第二小组中，最初刚到来的员工参加了Padawans，因为他们仍然对他们一无所知。 然后类似于数独-我们尝试在行和列中获得大约相同数量的Jedi和Padawans。
步骤2.控制知识共享
但是，如何验证拥有所有知识力量的帕达万将成长为绝地武士呢？
我们修复知识
为此，我们修复了我们产品的知识：列出所有知识的列表并将其放在表格中。 对于单独的Confluence页面上的每个产品，我们只需写下该产品组成的知识并将其分解。 分解知识的方式有多种，我记得这些表格是在绝地和帕达旺人分布的页面下绘制的。 例如，对于团队1，一页用于Sunset知识，另一页用于Sunset 2.0知识。
进一步的截图来自我们的Confluence分解示例。
按产品模块。 例如，其中一种产品具有单独的软件模块：贷款，存款，货币控制-我们只对它们进行了粉刷并开始使用它们。
按功能。 在这里，我们在系统的页面和部分上绘制了知识单位。
对于技术知识。 我们只是根据团队的技术知识来布置一些产品。
您可以通过任何其他方式进行分解，主要是可以将产品知识喷入大量原子元素中。
添加文件
在详细列出知识列表之后，我们在表格中添加了“文档”列，并开始逐步填充它-每一行知识都有其自己的页面，并带有描述。
我必须马上说这不是一个快速的过程，它花了我们几个月的时间，但是随着时间的流逝，文档列表被填满了，最后，在产品的所有知识领域，我们都编写了某种文档。
新增评分
在“文档”列的右侧，我们为每个团队成员添加了一个列，并评估了每个员工有多少知识。
我将破译等级：
- 1-如果您尚未看到或接触过这一知识领域。
- 2-看到或听到一些东西，知道它在哪里。 例如，我阅读了文档，请求访问服务器或存储库。
- 3-看过，感动，可以做。 例如，我排除了这部分代码中的错误，然后用手检查了一些内容。
- 4-不止一次工作，可以告诉别人。
在第一个版本中，我们有五个年级-学校教我们从1到5进行计数。但是后来证明四分制就足够了，我们停下来了。
在对知识进行评分时，我们可以提出控制问题。 向项目介绍新移民的团队之一有一个长达一个小时的视频，您需要观看视频并在清单上回答问题。 如果一个人没有回答所有问题，则认为他什么都不懂，因此需要对视频进行复审，因为它具有所有答案。
步骤3.可视化
在第三步中，出现了一个问题-经理我如何立即清楚地了解团队内部的知识积累是如何发生的？
我们通过用不同的颜色绘制Jedi和Padawans正方形来可视化当前状态：绿色-训练已完成，灰色-在学习过程中，红色-尚未开始学习。 首先，通常是很多红色，但最后每个人都应该“变成绿色”。
最初，我们玩一个交通信号灯，以为红色和绿色之间应该有黄色，但是事实证明，明亮的黄色将我们从本质上分散了注意力。 因此，我们放弃了它并变成了灰色。 实际上，最主要的是尽快消除红色。 图片以交通信号灯为例：
之后，我们进一步完善了规则。
发行规则，第2部分：- 绝地必须先“变绿”。 也就是说，我们专注于抽出绝地武士。 首席负责人应尽快胜任。 特别是如果这是新员工。
- 完全完成培训后，至少一个Padawan必须是绿色的。 但是他可能并不急于赶上绝地的知识，这里的主要目的不是停止。
- 其余的Padawans可能正在学习过程中。 我们的任务不是忘记“涂抹”知识，以确保员工的知识领域相交并且覆盖面最大。
差异化需求
在启动系统的第一阶段，即知识的描述和数字化才刚刚开始的时候，有一个良好的实践：将绝地和帕达万的要求分开。
让我们回想一下这些估计：Padawan如果在该区域至少做过某事，则为“三个”加一个绿色标记，而绝地应该为“四个”在同一区域完全定位。 此外，如果无法获得访问权限，未编写文档等对绝地（红色）不利，即他的下限为“两个”。 下表说明了这种方法。
这足以开始。 在下一阶段，您可以提高标准，说现在所有数字都应该相同。
现在，我们的盘子被涂上了油漆，一切变得更加有趣和易于理解：
我们一年半去看一些绿色的照片。 我们每两周或一个月与团队负责人慢慢聚会一次，观察正在发生的事情，并不断进行更新。
当我们添加新功能时，出现了红色骰子。 然后在下一次Timlid会议上，我们检查了它们是否仍为红色。 如果是这样，那么他们开始找出为什么培训在两周后仍未进行的原因。 如果红色消失了，灰色方块仍然存在，我们会定期检查它们。 团队会议的结果记录在Confluence的检查表中，其中注明了状态。 例如：“员工1-在20人中平均占10位”。 如果这些值在两周内没有变化，他们会寻找原因。
每位新员工始终处在红色区域，需要尽快对其进行培训和抽水。 但是如何？
步骤4.泵送知识和技能
填写：填写文档
我们了解到，我们应该努力确保产品分解表的一行对应于一种知识（文档的一页）。
不完美的描述仅在此表中可见。 这意味着左栏中的知识领域过于详尽，而右侧可能是一大本难以阅读和学习的文档。 也就是说，他们阅读了文档的一页，并一次注入了5条知识线-以某种方式获得知识是不合逻辑的。 最好在Confluence中一行对应于一页。 选中所有页面都经过研究和学习的复选框（数字）会更容易。
我们使用两种填充方法：
- 从内存写入 （专家方法）。 知道如何做的任何人，都要坐下来并开始记录他们的步骤，例如，用屏幕快照补充说明。
- 我看到的第二种方法- 研究 -然后我写。 这样，当我们在一个没人记得该怎么做的系统上工作时就使用它。 员工坐下来理解并写下了他分步进行的所有事情：这里您需要请求权限，然后写一封信，等等。 因此，为他调查的部分填写了文档。
碰巧开发商在自我发展方面的利益与公司的需求不一致。 在这里，您可以玩赔率游戏。 例如，您需要提高分析技能，这意味着我们将0.5的系数用于分析。 很明显，您可以在那里更快地“变绿”。 但是，在员工本身更感兴趣而不是团队更感兴趣的地方，机会更大。 在这些部分中，泵送将花费更多时间。
除了处理文档外，我们还会进行技术讲座。 但是文档是基本的。 我相信这是控制所有流程的最佳方法。 在文档中，所有内容都摆放在架子上，可以看到完整的图片，您可以影响知识的传播和积累。
因此，我们已记录了所需的一切。 下一步是更新。
实现
当所有团队成员都有权编辑文档时，这非常好。 然后，任何一名熟悉文档，阅读如何做的员工都可能在某个地方绊倒并立即进行纠正。 例如，服务器名称已更改或其他原因，员工可以立即更改文档。 因此，发生
了知识的自动更新和补充 。
如果您在Confluence空间中的团队订阅了这些更改，它将收到有关已添加，更改，改进了哪些内容的通知，因为在Atlassian Confluence中有：
- 页面更改历史记录-您始终可以看到更改的内容和时间。
- 订阅页面更新通知。
- 删除垃圾桶。
方便地，通过篮子删除了。 如果有人不小心单击了“删除页面”，它仍然不会丢失。 您可以还原它，并弄清楚为什么有人试图从您的空间中根除此知识。
我们大多数团队没有单独的文档审核过程。 , , . . , .
— . , , , , .
« », , .
, — , - . - : , , - . . , , . , , , . .
使用方法
?
. . , 4 , . , , - . , , . , , . , .
, . : « , . , ».
, — , . «», , . , : « , . ».
. , , 1, 2, 3, 4 . , , . . , , 1, 2, 3, 4. .
« »KPI, : « - KPI , - - , ». , , , , . — .
— , , .
Bus factor: , . , bus- , , , . : , . , . , , . , , . . : «, . - , ».
, , . () . , , . ( ). . , — . .
. , , . , . , . .
结论
, , , .
« ! ». . !
TeamLead Conf 2020 , . , «», . , . , , , telegram- . 10 11 !