Метрики — они как фломастеры, каждому по вкусу свои. Без метрик существование прибыльного бизнеса как такового невозможно, они окружают нас постоянно, это неприятная, но аксиома. Для кого-то метрика — план продаж на месяц, кому-то — выполнение заказа до оговоренного дедлайна, а другим — количество отработанных часов.
Подходящей «Картинки Для Привлечения Внимания» на эту тему нет, так что держите котика
Почему-то слово «метрики» в IT-сфере плотно ассоциируются с такими «превосходными» по своей тупости практиками, как подсчет написанных строчек кода или закрытых тасков. С уверенностью можно сказать, что это — самые бесполезные и беззубые в управленческом плане «инструменты» контроля. По сути же, адекватные метрики бывают, весьма условно, но все же, только двух типов: метрики для проекта и/или работ, результат и время исполнения которых ясен и прогнозируем во времени, и напротив, метрики для проекта и/или работ, результат и время исполнения которых спрогнозировать физически невозможно. Для первого типа выставляются метрики результата, а для вторых — дистанции, сиречь отработанного времени.
Все прочее от лукавого, и сейчас я поясню почему.
Первый тип метрик «по результату»
Универсального рецепта для выставления метрик любому работнику нет — это всегда ситуационное явление. Метрика работника всегда формируется из одного простого ответа на следующий вопрос: можем ли мы четко предсказать конечный результат и, как следствие, время работ на малой или средней дистанции?
Давайте рассмотрим ситуацию на фрилансе. Чаще всего заказчики выстраивают взаимоотношения с исполнителями по принципу оплаты за выполненный объем работы. То есть существует бюджет на проект, и под этот бюджет уже в ходе переговоров согласуется редлайн и дедлайн его сдачи. Так работают дизайнеры, верстальщики, ряд разработчиков. Чаще всего бюджет не двигается с места, то есть подвижной частью является «время выполнения».
Но оно всегда плюс/минус прогнозируемо, то есть заказчик четко понимает, сколько «примерно» времени уйдет на исполнение его заказа. Отталкиваясь от этой цифры выделяется бюджет, после чего ищется подходящий по стоимости исполнитель.
Вообще во фриланс-среде четко проповедуется принцип «нам все равно, сколько времени вы потратите на выполнение заказа, просто сделайте хорошо и в сроки, которые для нас приемлемы». Таким образом снимается масса вопросов по контролю за работой наемного фрилансера или временного сотрудника, снимается необходимость платить ему три, четыре, десять раз «зарплату» и так далее. Есть транш предоплаты, есть закрытие итогового, заранее оговоренного счета.
Подобный подход просочился и в малый и средний бизнес, где люди работают вроде бы, и на фуллтайм, но компания живет в состоянии жесткой конкуренции и коротких дистанций, когда результат нужен в конкретные сроки. Приложив «безумные усилия» можно нарисовать вот такую грубую-грубую блок-схему, которой руководствуются при принятии решения:
А что насчет почасовых рейтов UpWork и прочих моделей фриланса по времени?
Возможно, этот вопрос родился у тебя, читатель, еще в начале статьи, но пришли к ответу на него мы только сейчас. Точнее, к ответам, потому что их несколько.
Первый: нанимающая компания привыкла к контролю, потому что почасовая ставка в 50% случаев подразумевает трекер, а в 100% — периодические отчеты с проведением ревизии выполненных работ. То есть заказчик перекладывает часть менеджерских функций на самого исполнителя, который отчитывается сам за себя.
Второй: компании нужен контроль за ходом разработки, потому что у нее есть только одна попытка. Если проект растягивается более, чем на несколько недель, заказчику нужно понимать, «на каком свете» находится работа. Чаще всего на такие массивные заказы бюджет выделяется один раз и попытка есть только одна. На самом деле на рынке когда-то были и компании, которые не требовали такой периодичной и временами жесткой отчетности от исполнителей на крупных проектах, но с ними случилось тоже самое, что и со слонами с маленькими ушами — они вымерли (слоны от перегрева, а компании — из-за сорванных сроков).
Второй тип метрик «по времени»
Но все становится намного, намного сложнее, если мы начинаем говорить о крупном проекте, сроки сдачи которого колеблются в диапазоне «от года до трех» и до «это вечная разработка».В случае «вечной разработки» спрогнозировать время получения конечного результата практически невозможно по следующим причинам:
- над проектом работает не то что один человек, а даже несколько команд;
- каждая команда «по направлениям» насчитывает от двух-трех, до нескольких десятков сотрудников;
- когда закончится работа над проектом никто не знает.
В подобных условиях легко затеряться и околачивать известным предметом известные груши. Но так как бизнес благотворительностью не занимается, приходится переходить от метрик «по результату» к более сложной категории метрик «по времени».
Самый простой и логичный пример работы «по времени» — это обычный офисный фулл-тайм в компаниях от 30-50 человек в отделе разработки. В этих условиях бизнес «на берегу» договаривается с потенциальным работником, то есть еще на этапе собеседования, не о моменте сдачи проекта, а о стоимости часа работы исходя из 40-часовой рабочей недели согласно ТК. Для нас это выглядит просто как размер заработной платы.
При этом надо четко понимать, что бизнес — не дураки. В размер ЗП (точнее в ее сокращение) закладываются личностные кризисы, шатания по офису, перекуры, лишние 20-30 минут на обед (то есть полтора часа, вместо часа) и просто прокрастинация на YouTube. Какие-то компании могут позволить себе эти издержки, так как из бизнес является в данный момент прибыльным и он может позволить себе «легкую» версию контроля через простое выставление краткосрочных задач с размытыми дедлайнами, которыми занимается менеджмент младшего и среднего звена.
Но если бизнес низкомаржинальный или существует в конкурентной легаси-среде, то все становится еще хуже. И вот тут начинается форменный ад, за который разработчики так не любят слово «метрики».
Реальная жесткая привязка к отработанному времени не является самостоятельной метрикой эффективности, тут нужны костыли
Если человеку платят не за результат, а за количество отработанного времени, то как оценить его эффективность? Этим вопросом постоянно задается бизнес. Тут есть несколько переменных:
- Привязка результативности команды к метрике «результат» на короткой дистанции.
- Использование более мелких метрик на уровне задач и спринтов.
- Выстраивание четкой структуры ответственности, сроков и приоритетов, называйте как хотите, например, «политика разработки».
По сути, бизнес сталкивается с ситуацией, когда он перешел, вроде бы, на более чем понятный механизм «покупки времени», но контроль за тем, было ли что-либо получено за оплату этого времени взамен в виде результатов труда все равно нужно. То есть наше понятие «покупки результата» становится вложенной переменной в понятие «покупка времени».
Чаще всего происходит так, что менеджмент не способен четко проследить потребности бизнеса и работников одновременно, то есть выстроить систему и политику применения метрик, при которой обе стороны были бы довольны происходящим. Что имеется в виду: метрики должны одновременно выполнять интересы бизнеса и быть понятны и выполнимы работниками.
Тут мы сталкиваемся с другой проблемой: если при работе «на заказ» на коротких дистанциях задача, чаще всего, ясна и понятна всем сторонам, то при разработке крупного продукта вся структура находится в постоянном движении. Банально: конкуренты выпустили новый продукт или появился новый инструментарий и все планы, которые были любовно созданы менеджментом, пошли прахом.
В этот момент очень много зависит от менеджмента. Тут можно просто описать неадекватный и адекватный подходы к выставлению метрик.
Неадекватные метрики:
- количество строк кода и коммитов;
- количество закрытых тасков без учета сложности;
- лишение разработчика права голоса;
- игнорирование динамики и потребностей разработки в отчетный период (выполнение метрик превыше здравого смысла);
- длительный процесс пересмотра метрик, отсутствие гибкости, игнорирование мнения разработки.
Вот тут я описал типичную «галеру», когда разработчик превращается из человека в «машину по написанию кода» и всем плевать, как он справляется с краткосрочными задачами/метриками, которые ему спускаются сверху. В этом случае девелопер теряет любую возможность повлиять на разработку, даже если он видит «изнутри» проблемы. При этом сложность задач не учитывается и все сводится к monkey-job.
Адекватные метрики:
- Учет сложности задачи;
- Возможность пересмотра метрики постфактум при возникновении проблем;
- Возможность комментирования задачи;
- Отсутствие жесткой привязки к количественным показателям строк кода/количества тасков;
- Игнорирование частичного несоблюдения метрик, если в этом была необходимость.
Адекватные метрики — это те метрики, которые не прибиты гвоздями к полу и которые можно двигать. Если бизнес стремится к максимальной эффективности, то эта эффективность должна быть на всех уровнях. Уже давно понятно, что количество тасков или строк кода, по факту, значат не очень много, так как некоторые задачи могут иметь решающее влияние на продукт и стоят сотни других.
Кроме того, жесткая привязка к соблюдению метрик контр-продуктивна: если девелопер знает, что у него начнутся «проблемы» из-за того, что он закрыл 19 тасков за неделю вместо 20, то качество выполнения задачи уходит на задний план. И минимум последний, 20 таск, будет сделан на «отвали», с костылями и велосипедами вместо того, чтобы по-настоящему раз и навсегда решить поставленную задачу.
Обратная связь как неотъемлемая часть модели «покупки времени»
Фактически, качественно построенная модель разработки, привязанная ко времени работы, намного сложнее, чем может показаться на первый взгляд. Для эффективной работы по этой модели должна быть организована качественная обратная связь между исполнителями и руководителями, которые должны постоянно корректировать «политику партии» на всех уровнях. Ведь неадекватно поставленная задача, то есть сформулированная метрика — это проблема далеко не разработчиков, хотя эту проблему у нас принято спихивать именно на исполнителей. Неадекватно сформулированная метрика — это проблема, как раз менеджмента, который эту задачу поставил перед исполнителями при условии прозрачности работы обоих сторон.
Именно менеджмент должен организовывать работу так, чтобы время работы расходовалось эффективно, то есть бюджеты не «сжигались», но при этом и разработчики могли бы справиться с поставленными перед ними задачами без тотального выгорания через несколько недель. Потому что людской ресурс хоть и обширен, но не бесконечен, особенно, если речь идет о квалифицированных кадрах.
Именно наличием обратной связи и ответственностью за принятые решения со стороны менеджмента отличается от компания, которая ведет детальный учет отработанного времени, от явной «галеры», где разработчики попадают в бессмысленную мясорубку.
Именно обратная связь позволяет бизнесу найти «узкие места» в разработке. Как часто вы сталкивались с ситуацией, когда сотрудники какого-либо отдела задыхались, работая на износ, но так и не получали «подкрепления» в виде пары новых специалистов, которые бы подставили плечо и забрали на себя часть нагрузки? Такие ситуации возникают сплошь и рядом именно из-за отсутствия качественной обратной связи между разработкой и менеджментом. Вместо четкого отслеживания эффективности команды и ее нагрузки, менеджер ковыряется в носу пальцем, а когда кто-то «ломается», не выдерживая такого ритма, все спихивает на оставшихся девелоперов. Не надо так.
Автор: ragequit
