根据客观数据评估开发人员

不幸的是，我们并不生活在一个理想的世界中，在这个理想世界中，每个开发人员都拥有理想且平衡的生产力水平，同时专注于任务并从一个任务到另一个任务进行思考。 团队协作也不总是设计成使所有团队成员都能以最高效率工作。 与一般的许多问题一样，开发团队的早期开发可以节省资源，管理神经，并营造良好的工作氛围。

在小型团队中，团队负责人可能会尝试根据主观感觉来判断发生的一切，但是公司规模越大，使用客观数据和指标就越重要。 Alexander Kiselev （ AleksandrKiselev ）和Sergey Semenov在他们对TeamLead Conf的报告中，展示了如何使用您已经积累的数据，从何处获取其他数据，以及它们一起可以帮助识别非显而易见的问题。 甚至，在积累了许多同事的经验之后，他们提出了解决方案。


关于演讲者： Alexander Kiselev和Sergey Semenov，我们从事IT工作已有8年以上。 两者都从开发人员转到团队负责人，再到产品经理。 现在，他们正在使用分析服务GitLean，该服务会自动从开发团队收集团队负责人和CTO的分析数据。 该服务的目的是使技术经理可以根据客观数据做出决策。

问题陈述

我们俩都是团队负责人，经常在工作中面临不确定性和模棱两可的问题。


结果，常常有必要盲目地做决定，有时不清楚是好是坏。 因此，我们研究了市场上现有的解决方案，研究了评估开发人员性能的方法，并意识到没有任何满足我们需求的服务。 因此， 我们决定自己创建它 。

今天，我们将讨论如何告诉您已经积累的数据，但是很可能不使用它们。


这在两个主要情况下是必需的。

绩效评估是一个相当复杂且主观的过程。 自动收集有关开发人员工作的事实将非常有用。

我们与一家拥有大量开发人员的大型德国公司的代表进行了交谈。 大约每年一次，他们停止了整个开发工作2周，然后整个公司进行了绩效评估-开发人员整天为与他们一起工作了一年的同事写了匿名声明。 如果该公司有机会自动收集事实，他们将节省大量时间。

第二个方面是监视团队的当前状况。 我想快速了解出现的问题，并迅速做出反应。

决策选项

可能有几种解决方案。


首先，您根本不能使用任何分析 ，而只能使用主观评估。 如果您是小型团队的团队负责人，则此方法有效。 但是，如果您已经是CTO，并且拥有很多团队，那么您将无法使用主观评估，因为您并不了解所有情况。 您将不得不对您的蒂米德进行主观评估，这是一个问题，因为蒂米德通常对主观评估的看法大不相同。


这是下一步。 由于主观评估通常是不够的，因此您可能会感到困惑并用手收集事实 。

例如，与我们交谈的一位CTO怀疑该团队他们进行代码审查的速度太慢，但是没有任何东西可以向他们展示。 由于他只有一种模糊的感觉，因此他决定收集事实，只需要几个星期就可以观看整个团队。 CTO记录了团队审核所需的时间，他最终发现的结果震惊了他。 事实证明，有2位大四学生在代码审查中长期处于冲突状态，而他们根本没有将其删除。 他们像老鼠一样坐着，没有人向任何人大喊-团队根本不知道。 他们唯一要做的就是定期去凉爽的地方，给自己倒一些水，然后在代码审查中向他们的请求中的敌人写机智的答案。

当CTO发现时，事实证明问题太老了，无法执行任何操作，最后不得不解雇一名程序员。


吉拉（Jira）统计信息是经常使用的选项。 这是一个非常有用的工具，其中包含有关任务的信息，但是它非常高级。 通常很难理解团队中正在发生的事情。

一个简单的示例-上一个sprint中的开发人员完成了5个任务，其中一个-10。是否可以说他开始工作得更好？ 这是不可能的，因为任务是完全不同的。


存在的最后一种解决方案是简单地卷起袖子，编写自己的脚本来自动收集数据 。 这是大公司中所有CTO或多或少地采用的方式。 他是最有生产力的人，但当然也是最困难的。 今天我们要谈的就是他。

选择的解决方案

因此，选择的解决方案是整理脚本以收集分析数据。 主要问题是从何处获取数据以及要测量什么。

资料来源

积累有关开发人员工作信息的主要数据源是：

1. Git-主要实体：内部的提交，分支和代码。
2. 代码审查工具 -托管代码审查的 git托管服务保存有关可以使用的请求请求的信息。
3. 任务跟踪器 -有关任务及其生命周期的信息。

辅助数据源：

1. Messenger-您可以在其中进行情感分析，计算开发人员对信息请求的平均响应时间。
2. 配置项服务 ，用于存储有关构建和发布的信息。
3. 团队民意调查。

由于我在上文中讨论的所有来源都或多或少是标准的，而最后一个并不是那么标准，所以我将再多谈一点。


另一位CTO与我们分享了这种方法。 在每次迭代结束时，他都会自动向团队发送调查，其中只有两个问题：

1. 您认为我们在这次迭代中所做的工作有多重要？
2. 您认为我们正在做的事情很有趣吗？

这是一种衡量团队情绪的相当便宜的方法，也许可以发现一些动机问题。

什么以及如何衡量

首先，我们将讨论测量方法。 一个好的指标应回答3个问题：

1. 重要吗？ 只需要测量对公司重要的东西发出什么信号。
2. 它变得更糟/更好/一样吗？ 按度量标准，它应该变得更好还是更坏应该是非常清楚的。
3. 怎么办 从度量标准来看，应该清楚该采取什么措施来纠正这种情况。

一般来说，值得遵循以下原则：

衡量您想要什么并可以更改。

值得一提的是，目前尚无通用指标，由于以下原因，我们今天将不再讨论通用指标：

• 开发人员的活动范围很广 -他负责需求，编写代码，测试，进行代码审查，进行部署-不可能将所有这些都放到一个统一的指标中。 因此，最好专注于可以检测到的个别情况。
  
• 唯一的度量标准不值得做的第二个原因是，一个度量标准很容易解决，因为开发人员足够聪明，他们会想办法独自完成。

新方法

因此，我们制定了一种解决问题的方法：尝试找出特定的问题，并为它们选择一套可以检测到它们的指标。 一个好的开发人员将被称为问题最少的开发人员。


我们根据什么选择问题？ 很简单：我们采访了37位CTO和团队负责人，他们谈到了团队中存在的问题以及如何解决这些问题。

由此产生的庞大清单，我们对这些问题的生活技巧和衡量指标进行了优先排序和收集。 我们将所有问题分为两组：

1. 单个开发人员的问题（由开发人员负责这些问题）。
   
   
2. 团队问题。 团队负责这些问题；因此，为了解决这些问题，您需要与整个团队合作并更改流程解决方案。
   
   

让我们详细考虑每个问题，可以选择度量中的哪个关键。 让我们从最简单的问题开始，然后逐步沿着复杂性梯度移动到最难测量的位置。

开发者问题

开发人员表现不佳

而且，“性能低下”通常意味着开发人员几乎什么也不做 。 有条件地，一张票挂在吉拉（Jira）上，以某种方式对其进行报告，但实际上没有任何工作在进行。 显然，这个问题迟早会出现，您会发现的，但是自动执行此操作很不错。

如何测量？

首先想到的只是看开发人员的活动天数 。 活动日将称为开发者至少提交一次提交的日期。 实际上，对于全职开发人员而言，每周活动天数的特征数至少为3。如果少于，那么我们开始怀疑开发人员的表现不会很好。

显然，仅活动天数是不够的。 开发人员可以只编写代码而不提交代码-编写，编写，然后有一天提交一堆代码。

因此，我们施加的下一个限制是开发人员还必须具有一些代码 。 如何确定阈值“小码”？ 我们建议您将其放得足够小，以便任何人（包括出色的开发人员）都可以轻松克服它。 例如，在我们的JS服务中，这大约是150行代码，对于Clojure，则是100行代码。

为什么这么小的门槛？ 我们的想法是，我们要把工作能力强的开发人员与普通工作能力的开发人员区分开来，而要把那些几乎什么都不做的开发人员与那些至少做得相当合理的工作人员区分开。

但是，即使开发人员的活动时间很少且代码很少，这也不意味着他根本没有工作。 例如，他可以进行需要少量代码的错误修复。 结果，一个人似乎完成了许多任务，但是他可能没有多少代码和活跃的日子。 也就是说，我们考虑了任务数 。

接下来值得一看的是他完成的代码审查量 ，因为一个人不能执行任务也不编写代码，但是完全沉浸在代码审查中。 它发生了。

因此，如果针对所有这些指标-仅如此！ -开发人员没有达到任何阈值，您可以怀疑他的表现不佳。

怎么办呢？

首先，如果您知道正当的理由，那么您根本不需要做任何事情-例如，开发人员经过培训或有休息时间。 如果您不知道正当的原因，那么可能值得与人交谈 。 如果没有出现正当的理由，那么就值得进一步对其进行监视；如果有时还会重复出现此问题，那么可能值得向这样的开发人员说再见。

这是最简单，最挑衅的问题。 让我们继续前进。

开发者回收

这也是一个普通的故事。 如果有人对其进行处理，则会耗尽它，最终使他们失去动力，结果可能离开公司。 我们与之交谈的一位技术经理讲述了这样一个故事。 他曾在一家集会文化于一身的美国公司工作。 结果，所有开发人员上班后都按照自己的意愿做了工作，并在几个小时和周末后编写了代码。 结果，尽管行业标准为6％，但公司开发人员的年营业额达到了30％。

结果，该办公室解雇了由30人组成的所有技术管理人员。 为了不提出这个问题，我想及时发现这个问题。

如何测量？

实际上，没有什么太复杂的-让我们看一下开发人员在数小时后编写的代码量。 如果此数量的代码在条件上可比较或大于工作时间，则开发人员将对其进行显式处理。

显然，开发人员不是一个单一的代码。 一个普遍的问题是代码有足够的时间（主要工作），但没有足够的时间进行代码审查。 结果，代码审查会延续到晚上或周末。 数小时后即可通过pull-request中的评论数简单地进行跟踪。

最后一个显式触发器是大量并行任务 。 对于开发人员，3-4个任务有一些合理的限制。 您可以根据需要通过git或Jira跟踪它们。 效果很好。

怎么办呢？

如果您找到可回收利用的开发人员，则应首先检查其日历，以查看他是否因无用的集会而超负荷工作。 如果过载，建议减少会议量，最好召开会议日，这是专门的日子，开发人员将集中大部分最长的会议，以便他可以在其他日子正常工作。

如果这不起作用，则必须重新分配负载 。 这实际上是一个相当复杂的问题-如何执行。 有很多不同的方法。 我们不会深入探讨，但是请注意Anton Potapov撰写的有关HighLoad 2017的出色报告 ，其中非常仔细地考虑了此主题。

开发人员不关注任务发布

我想了解一下您的团队中有多少这样的开发人员，以及它花了多少时间。


开发人员承担一项任务，将其带入审查，测试的状态，却忘了它是很常见的情况。 然后她返回进行修订，并在那里挂了多少时间不清楚。 我自己一次在团队中有一名开发人员。 我长期低估了该问题，直到计算出平均需要花费各种停机时间的时间。 结果，事实证明，该开发人员的任务平均在发布时间的60％处于闲置状态。

如何测量？

首先，您需要衡量取决于开发人员的所有停机时间。 这是在代码审查和测试之后进行修复的时间。 如果您连续交付，则这是发布超时。 这些时间均应施加合理的限制-例如不超过一天。

原因如下。 当开发人员早上上班时，对他来说首先分析最高优先级的任务会很酷。 如果没有错误修复或非常重要的事情，则优先级最高的任务是最接近发行版本的任务。

关于此主题的另一个很酷的触发条件是挂在开发人员（如审阅者）上的大量代码审阅。 如果一个人忘记了他的任务，那么他很可能也会与同事的任务有关。

怎么办呢？

如果您找到这样的开发人员，显然值得他去说 ：“看，这是您的30％到40％的时间都花在了停机时间上！”这通常很酷。例如，在我的案例中，它起到了这样的作用，问题几乎完全消失了，如果没有，则需要继续进行监视 （定期说），但是这里的主要目的不是要进行微观管理，因为它会变得更糟。

因此，在任何可能的情况下，都值得立即处理过程解决方案。 例如，这可以是对活动任务数量的限制 ，或者，如果您的预算和时间允许，您可以编写一个机器人程序或使用一项服务，如果任务处于特定状态的时间过长，它将自动对开发人员执行ping操作 。 这可能是这里最酷的解决方案。

开发人员没有完成足够的任务

我认为您知道这些症状-这些是无法完成我们无法完成的任务所需的时间的估计，最终的期限太长，任务中的错误数量增加-总的来说，这没有什么好处。


如何测量？

我认为您知道这些症状-这些是无法完成我们无法完成的任务所需的时间的估计，最终的期限太长，任务中的错误数量增加-总的来说，这没有什么好处。

如何测量？

为此，我们需要引入2个指标，第一个是Churn代码。


流失率是开发人员有条件地写多少代码的度量。

想象一下情况。 星期一，开发人员开始执行一项新任务，并编写了100行代码。 然后是星期二，他在此任务中又编写了100行新代码。 但是，不幸的是，他删除并释放了任务，星期一发生了50行代码。 结果，似乎在任务中创建了200行代码，但是只有150行幸存下来直到发布，而50行是徒劳的。 这50个我们称为流失。 因此，在此示例中，开发人员的流失率为25％。

我们认为， 高流失率是一个很酷的触发条件，即开发人员没有考虑完成任务。

一家美国公司的一项研究，他们测量了20,000个开发人员的客户流失水平，得出的结论是，好的客户流失代码应在10％至20％的范围内。

但是有两个重要条件：

1. 例如，如果您要制作原型或其他新项目，则高流失率会很好。 然后它可以等于50-60％几个月。 不用担心。 , Churn — , .
2. Churn — . . - . delivery .

, , , , Fixed Tasks, . , .

, bug fixes , bug fixes . bug fixes 3 , , . , , , .

— . , , , - .

?

, , , . , , , estimation ..

CTO, , workflow, , . , , , - , .

Churn Fixed Tasks

, , :

• commit message, . commit message, , git .
• git-squash commit' , Churn .
• git. merge master, merge , . — , , Churn Fixed Tasks.

, — , . , , , . , - .

, , - 3-4 . , .

?

— - , , .


, 3 , , ( ), .

, , . — , .

— , — — , , .

?

. , , . - , .

— , , . . , , . .

30-50 50-60 %. , .

, , . , , , . .


, — . product- , . , , .

?

product- , ?

, product- , :

• Churn, ;
• , , estimation;
• in progress product-.

?

product- : «, Churn - — ».

« » , 1-2 . , product-, .


. , , .

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

?

, , :

• ;
• ;
• ;
• -, - , ;
• .

?

-, , , , .

-, , , , , , .

— - , . best practise, , , , . 3 , 3 .


, — . , . - , , -. , , CTO, , 100%. , - .

?

, legacy refactoring . , . . , , , .


, legacy refactoring , , complexity , , .

?

, , . , CTO. , .

CTO , , Jira «» . , - estimation . , — , ..

CTO . , , , «Hack». - -, : « Hack — », . grep' «Hack» , .

. .

:

1. . , , Churn legacy refactoring. , .
   
2. . , , , — git , git-. — , .
3. , . , , .
4. 我们这里列出的大多数指标仅适用于Multtime开发人员，因为只有Multtime开发人员的活动才能很好地反映在可用数据源中：git，Jira，GitHub，即时通讯程序等。

结论

我们想向您传达以下内容：

• 开发人员和团队可以并且应该被衡量 。 这可能很困难，但是可以做到。
  
• 没有通用的小型KPI集 。 对于每个问题，您需要选择一组高度专业化的指标。 必须记住，即使是最简单的指标也不应忽略。 他们在一起可以很好地工作。
  
• Git可以告诉有关开发人员和开发人员的许多有趣的事情，但是您需要遵循某些实践，以便可以从中方便地访问数据，包括：
  
  • 提交中的任务数；
  • 没有南瓜
  • 您可以确定发布时间：在master，tag中合并。

有用的链接和联系方式：

• 在演示文稿演示中，存在一些奖金问题和衡量指标。
  
• 作者博客，其中包含对开发经理有用的文章
  
• 电报联系人：@avkiselev（Alexander Kiselev）和sss0791 （Sergey Semenov）。

在TeamLead Conf上，他们讨论了管理开发团队的许多不同问题，并寻求解决方案。 如果您已经走了一部分路，完成了一个以上的射击，踩了一把耙子，尝试了不同的方法，并准备下结论并分享您的经验-我们正在等待您。 您可以 在8月10日之前 申请演出。

还希望与会人员更多地参与其中，首先要订票 ，然后尝试制定让您最兴奋的事情-然后您可以讨论自己的痛苦并最大程度地利用会议。