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



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


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

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

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


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

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

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

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

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



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


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

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

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

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


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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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


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

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

Вы можете помочь и перевести немного средств на развитие сайта



Комментарии (24):

  1. AlexTest
    /#19457864

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

    • ragequit
      /#19457922

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

  2. yoshka
    /#19458322

    На приведенной блок-схеме стрелка от «Нет» к «Нет» — лишняя, нет?

  3. robux
    /#19460606

    Свой вариант, что учитывать, я озвучивал пол года назад на Тостере.
    Если коротко:
    — число строк,
    — время в офисе,
    — выполнение задач,
    — фикса в месяц.

    Если полностью:
    1. Количество написанных строк обязательно должно оплачиваться деньгами, либо как основная оплата («сколько написал — столько получил, например 35 руб./строка»), либо в качестве поощрения («фикса 20 тыс. руб./месяц + 25 руб./строка»).
    2. Новые строки кода должны разделяться на разные виды и оплачиваться по-разному:
    1) абстракции (описание классов, структур, заголовки модулей, названия методов) и пустые строки — 0 руб. (т.е. не учитываются в оплате за строки кода)
    2) рабочий код (тело методов, тело функций, тело процедур и т.п.) — 70 руб./строка*
    3) определение констант, массивов, переменных вне тела методов — 10 руб./строка
    4) комментарии (не более 10% от всего числа строк) и todo — 5 руб./строка
    5) документация, changelog, bugfix-файлы — 20 руб./строка.

    *Цена за рабочий код зависит от языка программирования, для низкоуровневых языков она должна быть меньше, для высокоуровневых — больше, например:
    — Си — 50 руб.
    — С++, Pascal, PHP — 60 руб.
    — Ruby и Python — 70 руб.
    Ну и так далее.

    3. Измененные строки (не новые) должны оплачиваться в 30%-50% от новых.
    4. Перенесенные строки (не изменялись, просто перенесены) — не оплачиваются.

    Учёт строк должен проводиться по распечатанному «git diff» или специально написанными для этого утилитами.

    Помимо оплаты за строки кода желательно оплачивать:
    1) фикса в месяц — например, минимум 15 тыс. руб./мес. включающие оплату первых строк кода (т.е. напишет или не напишет на 15 тыщ, но всё равно получит, даже если весь месяц ни строчки не написал, или писал, но на 15 тыщ не написал). Это что-то типа подушки безопасности для новичков.
    2) время, проведенное в офисе — например, 50 руб./час. Это не должно быть много, но должно стимулировать писать в офисе, а не из дома. Для работодателя, пишущий в офисе эффективнее, чем пишущий дома, т.к. он вживую общается с коллегами и больше пишет кода. К тому же присутствующий в офисе участвует в мозговых штурмах, совещаниях и тому подобном, что тоже положительно скажется на процессе. Чтобы не просыпали, первый утренний час сделать дороже, например 100 руб./час. Учёт входов и выходов вести турникетом по электронной карте или паролю номеронаберателя. Бюджетно — положить самозаполняемый журнал на тумбочку или бумажки, ручку и ящик с прорезью. Можно рядом повесть веб-камеру.
    3) бонус за выполнение поставленной задачи. Работодатель перед раздачей заданий сотрудникам может оценить каждое из них, например:
    — Написание GUI для ввода формы «Счета на оплату» — 3200 руб.
    — Реализация сетевого обмена записями по подпискам — 7500 руб.
    — Сохранение сообщений об ошибках в лог-файл — 1000 руб.
    Ну и так далее. Бонус учитывает сложность и срочность выполнения с точки зрения работодателя.

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

    Все цифры приведены примерно и должны подбираться экспериментально конкретно для вашей ситуации.

    • robux
      /#19460670

      Дополнительно можно добавить метод Водянова, когда часть бюджета разработки (например 20%) распределяется самими разработчиками между собой.

      К примеру в конце каждого месяца (или спринта) сотрудники садятся в одной комнате в круг, каждому даётся 3 фишки (красная-600р, зеленая-300р и синяя-200р), перед каждым ставится пустая коробочка, и по кругу разрабы скидывают свои фишки друг другу, на первом круге — красные, потом зеленые, а потом синие. При сбросе фишки, разраб говорит, за что он поощряет, например «за крутой рефакторинг сетевого модуля», «дал мне дельный совет», «носил всем вкусные печеньки», ну и так далее.

      После собрания разраб со своей коробкой идет «обналичивать» премию (если ему накидали), в кассу или у начальника.

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

      • w3ga
        /#19461834

        лучше 40% бюджета, и выдавать не фишки, а по ножу каждому… банк забирает тот, кто выйдет из комнаты. так ведь интересней будет, больше мотивации, да?

    • Deosis
      /#19460798 / +1

      Вижу три минуса подобного подхода:


      • Исправление багов невыгодно. внесенные изменения будут оцениваться как минимум вдвое меньше, чем написание нового функционала.
        • На исправление бага требуется время на поиск (минимальная ставка)
        • При исправлении бага будет больше измененных строк чем новых (минимальная ставка)
      • Рефакторинг невыгоден (абстракции оплачиваются по минимуму). Значит технический долг будет расти.
      • Дикое поощрение копи-пасты. Вместо вынесения общего кода будет выгодно сделать свою версию функции.
        • на С++ шаблоны не будут использоваться. Выгоднее сделать копию и поменять типы данных.

      PS. Если разработчик найдет дублирующий код и удалит его, то будут ли его штрафовать за это? (например по 5 рублей за каждую удаленную строчку)

      • WraithOW
        /#19462088

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

    • DelphiCowboy
      /#19460818 / +2

      — число строк,
      — время в офисе

      ПЕСЕЦ!
      А ваши robux статьи на Хабре, давшие вам позитивную карму, судя по всему литературные негры писали?
      Потому что всё это приведёт к том, что на код вместо нормального исправления ошибок с рефакторингом будут лепить заплатки, поверх которых будут лепить новые заплатки, так что в итоге будет тормозной и глючный говно-код состоящий на 99% из заплаток сидящих на заплатках и заплатками погоняющими.
      Deosis
      Дикое поощрение копи-пасты. Вместо вынесения общего кода будет выгодно сделать свою версию функции.

      Не только! Вместо нормального цикла «повторить 100 раз» будет очень выгодно вставить копию кода 100 раз, а если потребуется цикл на 99 раз, то будет выгодно написать ещё одну копию из 99 элементов. Если же цикл может выполнять от 100 до 1 раза, то будет создано сто копий раскрытого цикла.
      А ещё это стимулирует создавать функции которые ничего не делают в итоге. Вместо 2+2 будет написанно, divide(sum(mult(2,100),mult(2,100),100), а сама функция sum(a,b) внутри будет вида a=a+1 повторённое b раз.

    • NecroRomnt
      /#19461554 / -1

      Интересно узнать, где Вы этого говна набрали, чтобы обходить людей и организации черпающие субстанцию из этого источника.

      — Си — 50 руб.
      — С++, Pascal, PHP — 60 руб.
      — Ruby и Python — 70 руб.
      Ну и так далее

      Следуя этой логики получается, что JS — 100 рублей строка. Мы чудесным образом приходим к тому, что чем менее профессиональный специалист, тем больше он получает.

      П.С. Вдруг пришло осознание откуда появился Skype на электроне и почему всё больше в нашем мире говнософта с титаническими аппетитами на ресурсы.

      • striver
        /#19461892

        Можно пойти от обратного, чем меньше строк, тем лучше… и будут все писать в одну строку. И пускай весь мир подождет…

      • Space__Elf
        /#19463722

        Получается что за ассемблер этот самозванец robux со статьями от литературных негров собирается платить 5 коп. как язык самого нижнего уровня, а за машинные коды и вовсе полушку! (полушка = полкопейки)

      • w3ga
        /#19465680

        а ты думал? по твоему почему те, кто по JS шарит — работает удалённо в Тае, на берегу моря, попивая свой мохито, а спецы по Си сидят в подвалах, в старых свитерах своих, с катышками, едят дошик в сухомятку, запивая пивом… блин, да у ребят даже денег нет, чтобы элементарно побриться :)

    • VIkrom
      /#19461830

      Я говорю о том, что если уж мы так хотим считать количество строк кода, нам следует смотреть на них не как на «произведенные строки», но как на «потраченные строки», — Э. Дейкстра,

      «Я говорю о том, что если уж мы так хотим считать количество строк кода, нам следует смотреть на них не как на «произведенные строки», но как на «потраченные строки»»
      — Э. Дейкстра

    • roscomtheend
      /#19462272

      Пункт 1 — у меня, кажется, есть лайфхак…
      Хотя, лично у меня есть пункт 0 — обходить подобные конторки подальше, пусть своими кепеями развлекаются сами. И тратят кучу денег на подобных учётчиков.

      > но должно стимулировать писать в офисе, а не из дома

      «Ходите в туалет на работе, так вы не только экономите туалетную бумагу, но вам за это ещё и платят».

    • vt4a2h
      /#19463302

      Вы троллте или серьезно?

    • robux
      /#19465170

      Выше отбомбили ленивые пафосные лоботрясы, не умеющие и не любящие писать код, но любящие гнуть перед руководством пальцы и завышать свою значимость :)

      • Space__Elf
        /#19465508

        По твоему писать не говнокод и заботиться о качестве — это быть пафосным лоботрясом?!
        И по твоему писать на ассемблере, а не скриптовом языке — тоже лоботряство?!
        Ты — точно САМОЗВАНЕЦ!

  4. bayarsaikhan
    /#19462038

    Не могу понять, чем плоха метрика — качественно сделанная в разумные сроки работа? Это же вполне реально оценить.

    • kinall
      /#19462080

      Потому что нет общего для всех определения, что такое «качественная» и что такое «разумные».

  5. eefadeev
    /#19462812 / +1

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

    • TerraV
      /#19464064

      Можно лаконичнее: «Люди производят то, что вы измеряете»