您可能会说：“能力矩阵？ 真的吗？ 您很可能已经听说过有关此工具的信息，甚至做出了不使用该工具的结论。 也许不是以前，或者谋杀性论点“历史上如此发生……”。

实际上，这是完全合乎逻辑的，不是一个非常有用的新工具。 您可以用完全不同的方式来实现它，我们将尝试在两个不同团队的实际案例（技术支持和开发）上向您证明。 基于它们，您自己将能够估算人工成本（它们可能大不相同），并在此方向上找到更合适的方法。

与龙有什么关系，我们将在删节中进行解释。



本文基于我们与TeamLead Conf上的Konstantin Kaftan 共同撰写 。 IPONWEB技术支持部门的Konstantin Timlid，我是IPONWEB开发团队的技术作家，从事知识管理。

这个故事是建立在IPONWEB实际案例的基础上的，因此首先要对公司有所了解，以便您可以了解该材料是否离您很近。

我们的人力资源部根据要求提供一幅可以介绍我们业务领域的精美营销图片，提出以下要求：


实际上，IPONWEB正在为从事在线广告的客户开发平台。 我们正在研究软件即服务（或更确切地说是平台即服务）的模型。 我们有许多组件：HTTP服务器，预测算法，UI，报告。 用Lua编写的大约50个项目的业务逻辑。

我们还拥有旗舰产品BidSwitch，该产品最初是衍生产品。 我们对合作伙伴（需求方，供应方）的集成更感兴趣，因此我们有很多日志。 这是同一项目，在相同的堆栈上，但是它足够大，具有具体细节和Konstantin负责的专门技术支持热线。

为什么我们选择“ Dragons Live Here”这个名字呢？ 因此，在早期的中世纪地图上，指定的是未知发生地点的地方-例如Terra Incognita。 关于这个有两个故事。 首先是团队的技能结构，团队越大，Terra Incognita越多。 再过一会再谈第二个。

我们怎么到这里

碰巧我们（Svetlana和Konstantin）的工作并不经常重叠，并且我们仅从会议网站提交了关于同一主题的申请。 然后我们决定团结起来-在我们看来，这对于每个人来说都会更加有趣。

团队简介

康斯坦丁（Konstantin）的技术支持团队：

• 人数：10-12人。
• Timlid距离：短-彼此可见。
• 一套技能：一套非常多样的技能，能力和工作工具-这是由于我们有一种从其他团队和部门的同事那里为我们拉动新任务的方式。
• 工作风格：从同事那里窃取任务。 首先，这样做是为了稀释支持程序，因此，日复一日地分析相同类型的请求不是很有趣。 其次，看谁在得到什么，并概述发展方向。

我的Lua开发团队：

• 员工人数：40人，但人数在不断变化；
• 与团队负责人的距离：由于公司管理结构的具体细节而需要足够长的时间（矩阵）。 也就是说，团队负责人不会每天看到每个开发人员，也不确切知道他的日常任务是什么。
• 技能集：或多或少统一。 开发人员使用Lua编写业务逻辑，但同时他们都进入业务部门，即 例如，通过项目组合来销售广告位或作为广告商购买广告。
• 工作作风：具体任务，总线因素。 通常，知识集中在个人的头上，而不是整个团队都是可互换的。

需要使用命令描述来明确我们的矩阵实现方式之间的差异。 我们将尝试描述不同的团队是如何做到这一点的，最终发生了什么，因为团队的结构，消息，目标，触发因素和最终结果有些不同。

目标和触发因素

在技​​术支持团队中：

• 谁在做什么？ 有必要弄清什么时候一切变得太多，并且不再适合我的头脑，谁在做什么，谁在做什么，什么能力在什么水平上做。
• 缺少哪些专家？ 结果，缺少谁来完成任务，谁需要培训。
• 每个人的共同能力是什么？ 最主要的是在选拔阶段了解什么是通用的和强制性的，什么是在理想候选人的简历中需要为人力资源撰写的内容。

在开发团队中，目标和触发因素略有不同。 最初的动机恰恰是知识管理，因为正如我们已经提到的，我们有一个非常特殊的业务-广告技术。 有人拥有现成知识的可能性非常低，同时，对于开发人员而言，了解业务细节非常重要。

在开发团队中，有必要：

• 加快新手入门 。 将开发人员长期包含在项目中是一个很大的痛苦。 入职大约需要六个月的时间，即超过试用期，这意味着我们将自费培训开发人员。
• 了解知识的结构，评估知识的差距 ，发现白点，概述培训计划，概述个人成长路径。
• 由于矩阵结构，有必要在业务部门和任务之间更均匀地分配开发人员 ，而不得罪任何人。 也就是说，请勿将所有上级派遣到一个业务部门。

还有一个附带目标- 使绩效审核过程更加透明，易于理解，以便在单个坐标系中制定目标。

绩效考核

绩效审查是我们公司的标准。 每N个月一次，使用人力资源部或公证人作为裁判，在员工及其团队负责人在场的情况下，对每位员工进行绩效评估。 在绩效评估中，我们检查员工对设定的任务做了什么，他没有成功，如果他没有成功，为什么，我们想要实现什么，我们可以提供什么。 之后，设定新的目标和目的，设定下一个截止日期。

在支持团队中，此期限很短，因为没有大型且耗时的项目-这是3个，最多4个月。 开发团队有半年的审查周期。 以前，截止日期更长，这仅仅是因为开发人员可以更好地概述路线图。 例如，在其他一些开发团队中，前端性能检查也会每3-4个月进行一次。 间隔时间可能与团队的发展或支持无关，但它与我们有关。

为什么需要一个能力矩阵

一年前，我们公司经历了一段密集的增长期，这里有更多的人，更多的工具，更多的任务，更多的东西。 一方面，很明显，如果没有正确的文档，很难理解正在发生的事情。 我们找到了一种解决方案，以实现信息系统化：关于任务； 工具和技能； 员工。

为什么需要所有这些？ 您将了解我们的实际案例，但您可能会有一个合理的问题-如何理解我需要它？

如果您遇到的问题与我们上面指出的类似，即您不了解开发人员的全部任务，介绍新员工的时间过长以及已经提到的其他问题，那么您可能需要这样做。

从哪里开始

从哪里开始，我们将通过示例说明。

在技​​术支持团队中，我们：确定了我们从事的任务； 将任务分解为单独的操作； 找出员工在特定部门工作应该知道哪些工具。

下面是一个稍微简化的示例。


该团队有Batman，Joker，Flash和Ivanov的员工，以及标准任务：

• 一般交通诊断；
• 诊断交易流量；
• 部署监控；
• 测试买卖双方新合作伙伴（DSP和SSP）的集成。

我们拥有的工具：

• uSIicer允许您获得非常详细的交易编号；
• Graphite提供实时的系统状态数据；
• Google BigQuery（BQ）-我们的日志保存在此处；
• Grafana，它使您可以从Graphite聚合指标，如果需要的话可以方便地在其上发出警报；
• 管理界面中的Ul调整，可让您更改特定合作伙伴，交易对，数据中心等的流量参数。

然后我们找出谁知道什么以及什么程度。


2-可以教书的专家； 1-表示一个人或多或少知道； 空单元格，以免冒犯任何人。

我们总结在一张表中：


给定任务中不需要的那些工具以灰色突出显示。 例如，对于一般诊断，我们不需要了解BQ和Grafana。 结果是一幅相当有趣的图画。

Nezhdanchiki（支持）

几个意想不到的人浮出水面，他们帮助理解了：

• 哪些同事应该提高什么技能来吸引他们从事新工作？ （指明发展方向）；
• 员工流失会在哪里出现问题？
• 员工的薪水对他的任务池是否足够？
• 团队的人员配备和培训情况如何？

稍后我们将详细讨论每个要点。

让我们回到桌子上。



正式而言，蝙蝠侠正忙于常规诊断。 该表显示，鉴于小丑仍然是UI专家，如果有必要，小丑将很好地替代他-为什么不呢？ 也就是说，蝙蝠侠在这里是可替换的。

小丑通常做得很好-除了部署监控外，几乎到处他都很精明，但这是可以教的。



众所周知，小丑有时会很偏心地度过闲暇时光，并且随时都可能失业。 那会发生什么呢？ 然后，一切都会对交易量的诊断感到悲伤。

不仅如此，我们没有BQ专家！ 也就是说，迫切需要有人训练。 例如，您可以教Batman BQ和​​Ivanov-Graphite。



即使采用这种简化的评估系统，您也可以为每位员工获得一定数额，以了解他的能力和熟练程度。 这些估计又引发了另一个意外。

另外两个有趣的事情是球队的总人数及其平均得分。 严格来讲，仅这些数字并不是特别有趣-它们每个月变化的动态都很有趣。 如果总数由于某种原因而开始下降，那么很可能有人离开了，而一名虚弱的员工来了-配置存在问题，您需要联系HR。 如果平均水平开始下降，则意味着培训出了点问题-团队负责人和唯一的团队负责人。

在这种情况下，重要的是不要向员工展示团队领导工具，因为评估是主观的。

开发团队

开发团队的一切都变得更加民主，或者也许我们只是使我们的任务复杂化了。 尽管任务的一致性可能更高，但是开发团队中的技能列表更大。

我们收集了来自4位经验丰富的开发人员 （包括团队负责人和知识管理专家）的建议，进行了头脑风暴，并分析了任务和技能。 我们只是一步一步地走了自己的个人感觉，但是有几个人分析了这些任务，将它们放在技能上，形成了清单。

最初，它是一个列表，然后被构造为更通用的技能，包括编码和单独的业务技能，因为对于我们的开发人员来说，这是重要的一部分。 从这个技能列表中就已经构成了矩阵。

矩阵的第一次迭代不包括所谓的软技能，即不能称为硬技能的东西。 这与日常工作有关，甚至与一些关键技能有关，包括：计划； 与团队沟通； 有能力以小组或自己的方式管理开发过程； 制定要求的能力，例如在代码审查期间。

我们没有立即包括所有这些技能，因为我们不知道如何准确地评估它们。

在第二次迭代中，他们进入了评估系统：

• 分解任务及其相关的一切；
• 文档和自文档代码
• 与项目经理沟通的能力，即理解他在说什么并依次提出必要问题的能力；
• 能够正确地编写关于代码审查的注释等的能力。

顺便说一下，关于软技能的支持。 事实是，开发团队的软技能需要单独评估。 但是，仅支持人员需要开发人员具备的个人素质。 如果某人被录用，则默认情况下已经有他们。

在开发中，我们放弃了“软技能”这一概念，并将其称为通用技能。 例如，它们不包括英语知识或您不会激怒团队的事实-这并不是因为它更接近于软技能，而是描述一个人的性格。 我们在即将到来的某个地方评估技能，因此提出了这样一个名称通用的技能 。

准备好技能清单后，我们使用连续调查评估了技能。 我们进行了一次真实的考试，其中的一些问题提出了肯定的答案，还讨论了一些工作情况：“如果有人延迟或不做某事我应该怎么办？”，“您将如何在项目中实现此功能？” 。 这对我们很有帮助，因为这部分问题使我可以与大量开发人员进行交流。

然后，针对每种技能，我们将开发人员的评分分为1到3分。

在最初的调查中无法评估的那些技能，在同伴（同伴）的帮助下进行了评估，也就是说，他们要求对同事进行评估。 当时，我们没有任何组长，否则他们可以做到。

这个矩阵看起来像这样。



当然，不可能将所有内容都拟合到图中，因此某些内容（例如，相关性和开发人员的个人资料）在此处不清楚。 但是，即使这样，您也可以粗略评估发生的情况，并看清楚它是什么以及可以衡量什么。

颜色与等级一致。 得出与支持团队相同的指标-技能总数和各种平均值。

让我们关注Dev8。 从表中可以看出，这似乎是第一个被解雇的候选人。 但是，首先，他在其中一个职位上具有特定的知识，因此我们需要他。 但更重要的是， 该表不是触发工具 。 我也会讲这个，我们还没有开始一切。

平均技能-这是一项工作，其结果应形成有关如何加强技能的计划。 也就是说，如果开发人员不了解某些内容，那么这不是他们的问题。 这意味着我们没有给他们足够的信息，并且通常，公司中对某些技能的知识通常是不够的。 您需要编写文档，或者做一些操场，以便他们可以练习，或者需要购买某种外部课程，以便他们可以学习，进行知识共享课程，相互学习，一起工作一段时间，将人员包括在另一个项目中。 知识共享可能有不同的选择。 最重要的是，您必须首先举行一个活动，然后才能谈论动态。

需要注意的是，由于我们公司具有矩阵结构，因此并非所有开发人员都需要一些技能。 当他们完成与此技能相关的任务时，他们将收到它们。 否则，这是没有意义的，尤其是如果该技能未包括在关键列表中时。 例如，在项目的某些部分中没有uPredict，这不是关键技能。 总的来说，这种方法可以帮助我们确定哪些技能是关键技能，哪些不是关键技能，以及专家在执行此类实际任务时可以掌握的技能。

关于分级的另一个重要点。 最初，我们犯了一个错误，这不仅引起了团队的抵制，还引起了更多的错误-我们并没有说出等级1，等级2和等级3的价值。直觉水平上他们处于头脑中，但是我们无法回答为什么一个开发商获得等级1，第二个-2.开发人员彼此共享传播的结果，这引发了冲突。 与支持小组不同，我们根据要求报告了个人评分，但不报告陌生人。

您需要明确定义并将其传递给所有人，例如，在Lua知识中，分数是：

• 1-表示开发人员知道所有基本运算符，知道如何使用数据结构和编写函数类；
• 2-知道如何将代码组织到库中，在整个项目中始终与它们一起工作，并且知道什么是元表；
• 3-知道公司和项目的细节，例如协程是什么（我们的服务器如何与Lua一起工作的细节），C ++代码如何与Lua代码一起工作，其施加的限制是什么，如何解释，编译的代码以及我们的JIT编译器如何工作。

因此，您可以分解每种技能，因为您已经在直觉水平上掌握了它。

自我注意：

• 对评分系统进行口头表达，即使您不向任何人展示。
• 在早期阶段，尝试包括有经验的开发人员。 您知道谁的抵抗力最大，请立即将他们包括在内。 提前消除所有异议，就像在销售中一样。

如何实施

当基本矩阵准备就绪时，在开发团队中，我们将指标附加到该矩阵上 。 基本上，这是最高技能评级的百分比，它使您可以给开发人员评分。

除了评估个人技能外，我们还需要对评分者进行评分。 我们的年级分别为A，B和C-诸如初中，中级，高级。 在IT大三，大三，大四的情况下，它已经变得太有意义了，在其中尤其要投入工作经验。 , . A, B C — . « » .

— .

, . , , , , .

, - , , . , , . , - — , , , .

, . , , . , . .

performance review . , 1 2, ( ) .

— performance review , .

(Dev Team)

. , , . , , , . . 5-6 2-3. . -, , . ( ) .

, , . . , , , . , , . , , playground, .

, , . , , , , . . . -, .

. , - : « ? ?».

, , , — , , , . .

案例

, . - , , .



, CI, . , . , 8.



, , , , , -. .

, — -. .


:

• 4 , .. ;
• 1 , ;
• 0,5 HR-, , , .

仅此而已！ 30 . , , , , , , .

Dev Team

. : ( ) 3-4 . , :

• , — 3-4 ( 4 ) — , .
• , , , , — 6 .
• . . , senior'. 2 knowledge- 2 .
• — ( 3-4 ). , 100 , .
• — 2 . , .

, - , - . .

, .

— , .

, - , . , , , , . : , , ..


Support - easy medium, Dev Team — medium.

, , . , . , , , .

.

• , , .

, , . ( ), . performance review, .

, , — . .

• . , , , , .
• , - — . . , , .

, HR, , -, , -, , , -, HR - . HR , , .

• , .

-. . , , . , . — - , — . .

• Don't try this at home — - , :)

, .

, , KnowledgeConf 2019 26 .

, ( , , , , ) ( ).

. , , , . .