Главная » Хабрахабр » Давайте поговорим о метриках как способе оценки труда программиста

Давайте поговорим о метриках как способе оценки труда программиста

Метрики — они как фломастеры, каждому по вкусу свои. Без метрик существование прибыльного бизнеса как такового невозможно, они окружают нас постоянно, это неприятная, но аксиома. Для кого-то метрика — план продаж на месяц, кому-то — выполнение заказа до оговоренного дедлайна, а другим — количество отработанных часов.


Подходящей «Картинки Для Привлечения Внимания» на эту тему нет, так что держите котика

С уверенностью можно сказать, что это — самые бесполезные и беззубые в управленческом плане «инструменты» контроля. Почему-то слово «метрики» в IT-сфере плотно ассоциируются с такими «превосходными» по своей тупости практиками, как подсчет написанных строчек кода или закрытых тасков. Для первого типа выставляются метрики результата, а для вторых — дистанции, сиречь отработанного времени.
По сути же, адекватные метрики бывают, весьма условно, но все же, только двух типов: метрики для проекта и/или работ, результат и время исполнения которых ясен и прогнозируем во времени, и напротив, метрики для проекта и/или работ, результат и время исполнения которых спрогнозировать физически невозможно.

Первый тип метрик «по результату»

Универсального рецепта для выставления метрик любому работнику нет — это всегда ситуационное явление. Метрика работника всегда формируется из одного простого ответа на следующий вопрос: можем ли мы четко предсказать конечный результат и, как следствие, время работ на малой или средней дистанции?

Чаще всего заказчики выстраивают взаимоотношения с исполнителями по принципу оплаты за выполненный объем работы. Давайте рассмотрим ситуацию на фрилансе. Так работают дизайнеры, верстальщики, ряд разработчиков. То есть существует бюджет на проект, и под этот бюджет уже в ходе переговоров согласуется редлайн и дедлайн его сдачи. Чаще всего бюджет не двигается с места, то есть подвижной частью является «время выполнения».

Отталкиваясь от этой цифры выделяется бюджет, после чего ищется подходящий по стоимости исполнитель. Но оно всегда плюс/минус прогнозируемо, то есть заказчик четко понимает, сколько «примерно» времени уйдет на исполнение его заказа.

Таким образом снимается масса вопросов по контролю за работой наемного фрилансера или временного сотрудника, снимается необходимость платить ему три, четыре, десять раз «зарплату» и так далее. Вообще во фриланс-среде четко проповедуется принцип «нам все равно, сколько времени вы потратите на выполнение заказа, просто сделайте хорошо и в сроки, которые для нас приемлемы». Есть транш предоплаты, есть закрытие итогового, заранее оговоренного счета.

Приложив «безумные усилия» можно нарисовать вот такую грубую-грубую блок-схему, которой руководствуются при принятии решения: Подобный подход просочился и в малый и средний бизнес, где люди работают вроде бы, и на фуллтайм, но компания живет в состоянии жесткой конкуренции и коротких дистанций, когда результат нужен в конкретные сроки.

А что насчет почасовых рейтов UpWork и прочих моделей фриланса по времени?

Возможно, этот вопрос родился у тебя, читатель, еще в начале статьи, но пришли к ответу на него мы только сейчас. Точнее, к ответам, потому что их несколько.

То есть заказчик перекладывает часть менеджерских функций на самого исполнителя, который отчитывается сам за себя. Первый: нанимающая компания привыкла к контролю, потому что почасовая ставка в 50% случаев подразумевает трекер, а в 100% — периодические отчеты с проведением ревизии выполненных работ.

Если проект растягивается более, чем на несколько недель, заказчику нужно понимать, «на каком свете» находится работа. Второй: компании нужен контроль за ходом разработки, потому что у нее есть только одна попытка. На самом деле на рынке когда-то были и компании, которые не требовали такой периодичной и временами жесткой отчетности от исполнителей на крупных проектах, но с ними случилось тоже самое, что и со слонами с маленькими ушами — они вымерли (слоны от перегрева, а компании — из-за сорванных сроков). Чаще всего на такие массивные заказы бюджет выделяется один раз и попытка есть только одна.

Второй тип метрик «по времени»

Но все становится намного, намного сложнее, если мы начинаем говорить о крупном проекте, сроки сдачи которого колеблются в диапазоне «от года до трех» и до «это вечная разработка».В случае «вечной разработки» спрогнозировать время получения конечного результата практически невозможно по следующим причинам:

  • над проектом работает не то что один человек, а даже несколько команд;
  • каждая команда «по направлениям» насчитывает от двух-трех, до нескольких десятков сотрудников;
  • когда закончится работа над проектом никто не знает.

В подобных условиях легко затеряться и околачивать известным предметом известные груши. Но так как бизнес благотворительностью не занимается, приходится переходить от метрик «по результату» к более сложной категории метрик «по времени».

В этих условиях бизнес «на берегу» договаривается с потенциальным работником, то есть еще на этапе собеседования, не о моменте сдачи проекта, а о стоимости часа работы исходя из 40-часовой рабочей недели согласно ТК. Самый простой и логичный пример работы «по времени» — это обычный офисный фулл-тайм в компаниях от 30-50 человек в отделе разработки. Для нас это выглядит просто как размер заработной платы.

В размер ЗП (точнее в ее сокращение) закладываются личностные кризисы, шатания по офису, перекуры, лишние 20-30 минут на обед (то есть полтора часа, вместо часа) и просто прокрастинация на YouTube. При этом надо четко понимать, что бизнес — не дураки. Какие-то компании могут позволить себе эти издержки, так как из бизнес является в данный момент прибыльным и он может позволить себе «легкую» версию контроля через простое выставление краткосрочных задач с размытыми дедлайнами, которыми занимается менеджмент младшего и среднего звена.

И вот тут начинается форменный ад, за который разработчики так не любят слово «метрики». Но если бизнес низкомаржинальный или существует в конкурентной легаси-среде, то все становится еще хуже.

Реальная жесткая привязка к отработанному времени не является самостоятельной метрикой эффективности, тут нужны костыли

Если человеку платят не за результат, а за количество отработанного времени, то как оценить его эффективность? Этим вопросом постоянно задается бизнес. Тут есть несколько переменных:

  1. Привязка результативности команды к метрике «результат» на короткой дистанции.
  2. Использование более мелких метрик на уровне задач и спринтов.
  3. Выстраивание четкой структуры ответственности, сроков и приоритетов, называйте как хотите, например, «политика разработки».

По сути, бизнес сталкивается с ситуацией, когда он перешел, вроде бы, на более чем понятный механизм «покупки времени», но контроль за тем, было ли что-либо получено за оплату этого времени взамен в виде результатов труда все равно нужно. То есть наше понятие «покупки результата» становится вложенной переменной в понятие «покупка времени».

Что имеется в виду: метрики должны одновременно выполнять интересы бизнеса и быть понятны и выполнимы работниками. Чаще всего происходит так, что менеджмент не способен четко проследить потребности бизнеса и работников одновременно, то есть выстроить систему и политику применения метрик, при которой обе стороны были бы довольны происходящим.

Банально: конкуренты выпустили новый продукт или появился новый инструментарий и все планы, которые были любовно созданы менеджментом, пошли прахом. Тут мы сталкиваемся с другой проблемой: если при работе «на заказ» на коротких дистанциях задача, чаще всего, ясна и понятна всем сторонам, то при разработке крупного продукта вся структура находится в постоянном движении.

Тут можно просто описать неадекватный и адекватный подходы к выставлению метрик. В этот момент очень много зависит от менеджмента.

Неадекватные метрики:

  • количество строк кода и коммитов;
  • количество закрытых тасков без учета сложности;
  • лишение разработчика права голоса;
  • игнорирование динамики и потребностей разработки в отчетный период (выполнение метрик превыше здравого смысла);
  • длительный процесс пересмотра метрик, отсутствие гибкости, игнорирование мнения разработки.

Вот тут я описал типичную «галеру», когда разработчик превращается из человека в «машину по написанию кода» и всем плевать, как он справляется с краткосрочными задачами/метриками, которые ему спускаются сверху. В этом случае девелопер теряет любую возможность повлиять на разработку, даже если он видит «изнутри» проблемы. При этом сложность задач не учитывается и все сводится к monkey-job.

Адекватные метрики:

  • Учет сложности задачи;
  • Возможность пересмотра метрики постфактум при возникновении проблем;
  • Возможность комментирования задачи;
  • Отсутствие жесткой привязки к количественным показателям строк кода/количества тасков;
  • Игнорирование частичного несоблюдения метрик, если в этом была необходимость.

Адекватные метрики — это те метрики, которые не прибиты гвоздями к полу и которые можно двигать. Если бизнес стремится к максимальной эффективности, то эта эффективность должна быть на всех уровнях. Уже давно понятно, что количество тасков или строк кода, по факту, значат не очень много, так как некоторые задачи могут иметь решающее влияние на продукт и стоят сотни других.

И минимум последний, 20 таск, будет сделан на «отвали», с костылями и велосипедами вместо того, чтобы по-настоящему раз и навсегда решить поставленную задачу. Кроме того, жесткая привязка к соблюдению метрик контр-продуктивна: если девелопер знает, что у него начнутся «проблемы» из-за того, что он закрыл 19 тасков за неделю вместо 20, то качество выполнения задачи уходит на задний план.

Обратная связь как неотъемлемая часть модели «покупки времени»

Фактически, качественно построенная модель разработки, привязанная ко времени работы, намного сложнее, чем может показаться на первый взгляд. Для эффективной работы по этой модели должна быть организована качественная обратная связь между исполнителями и руководителями, которые должны постоянно корректировать «политику партии» на всех уровнях. Ведь неадекватно поставленная задача, то есть сформулированная метрика — это проблема далеко не разработчиков, хотя эту проблему у нас принято спихивать именно на исполнителей. Неадекватно сформулированная метрика — это проблема, как раз менеджмента, который эту задачу поставил перед исполнителями при условии прозрачности работы обоих сторон.

Потому что людской ресурс хоть и обширен, но не бесконечен, особенно, если речь идет о квалифицированных кадрах. Именно менеджмент должен организовывать работу так, чтобы время работы расходовалось эффективно, то есть бюджеты не «сжигались», но при этом и разработчики могли бы справиться с поставленными перед ними задачами без тотального выгорания через несколько недель.

Именно наличием обратной связи и ответственностью за принятые решения со стороны менеджмента отличается от компания, которая ведет детальный учет отработанного времени, от явной «галеры», где разработчики попадают в бессмысленную мясорубку.

Как часто вы сталкивались с ситуацией, когда сотрудники какого-либо отдела задыхались, работая на износ, но так и не получали «подкрепления» в виде пары новых специалистов, которые бы подставили плечо и забрали на себя часть нагрузки? Именно обратная связь позволяет бизнесу найти «узкие места» в разработке. Вместо четкого отслеживания эффективности команды и ее нагрузки, менеджер ковыряется в носу пальцем, а когда кто-то «ломается», не выдерживая такого ритма, все спихивает на оставшихся девелоперов. Такие ситуации возникают сплошь и рядом именно из-за отсутствия качественной обратной связи между разработкой и менеджментом. Не надо так.

Вместо вывода

Самое худшее, что может случиться в процессе организации рабочего процесса — «передергивание» механизмов, присущих одной модели в другую. Например, когда для долгосрочных проектов выставляются жесткие дедлайны без здравой оценки сложности и возможностей команды. Или когда на краткосрочные самодостаточные проекты и задачи надстраиваются такие формы контроля, которые впору применять в области ракетостроения, а речь идет всего-то о заказе на фрилансе.

И чем больше разработчиков, менеджеров и владельцев бизнеса будут понимать эти механизмы — тем лучше будет для всех участников IT-сегмента. Четкое понимание уместности тех или иных методов работы в различных по структуре и размеру компаниях поможет уберечь огромный кусок здоровья и нервной системы при поиске работы.


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

Вырастить и научить. Как мы подружились с PEGA

В группе компаний ЛАНИТ работают более десяти тысяч человек. Кажется, что в таком коллективе всегда найдётся подходящий специалист. Однако с каждым годом на рынке появляется всё больше новых продуктов, методик, решений. ИТ-профессионалам интересны новинки отрасли, но для того, чтобы изучить ...

В ЕС добиваются права на ремонт крупной бытовой техники

Источник: Schraube locker!? Им удалось собрать более 100 тыс. Европейские активисты движения «права на ремонт» решили начать с холодильников. подписей под соответствующим документом и даже добиться голосования в Брюсселе по поводу изменения законодательства, имеющего отношение к ремонту бытовой техники. Традиционная ...