Вопрос “Сколько времени тратить на технические задачи?” вызывает самые ожесточенные бои между продактами и разработчиками. В этой статье расскажем, как считают метрики в hh.ru, зачем нам потребовалось считать ее двумя способами, и что из этого получилось.
У этой статьи есть видеоверсия, для тех, кому не нравится читать буквы. Однако статья является более полной, и да, я нашёл ошибки в скрипте и получил новые, более правдоподобные цифры!
Что за зверь такой?
Для начала давайте определимся, кто такой этот наш техналог. Мы делим его на 3 части. Первая – это работа с застарелым legacy. Вторая – ресерч новых подходов, фреймворков и применение их к нашей кодовой базе. Третья — это публичные выступления, запись видео для техноблога и написания статей.
Что техналогом не является? Хитрый продакт может предложить: “А давайте сейчас фичу на костылях и пластилине сделаем, а если стреланёт, в следующем релизе перепишем по-царски”. Так вот, переписывание фичи на эти ваши архитектуры техналогом являться не будет — это всё та же продуктовая фича!
Как выбрать процент техналога?
Сколько вообще времени стоит тратить на работу с техналогом? Всё зависит от состояния вашей кодовой базы. Если вы только что стартанули проект, выбрали фреймворки и технологии, которые у вас будут на борту, то о каком вообще техническом долге может идти речь? Бизнес его не одобрит и будет прав. А вот когда пройдет годик-другой, в коде расплодятся кривые решения, недоработки, а половина технологий устареет, вот тогда уже стоит садиться за стол переговоров со своей технической совестью. Что касается ресерчей и публичных выступлений — время на них мы резервируем всегда, чтобы инженеры могли переключиться и отдохнуть от продукта.
В hh.ru с одной стороны достаточно старая кодовая база, а с другой, мы очень много вкладывались в рефакторинг. В этом году мы остановились на том, что процент техналога для продуктовых мобильных команд будет 25%, а для технической команды — безлимит.
Если быть точным, техническая команда не тратит всё своё время на работу с техналогом. Во-первых, постоянно заниматься только ресерчами и рефакторингами достаточно утомительно. Это как в детстве на Новый год получаешь пакет сладостей — сначала ешь с удовольствием, а потом уже и живот болит, и на оливье снова косишься с одобрением. А во-вторых, за вечным построением архитектурных воздушных замков можно здорово оторваться от земельки и начать делать то, что вообще не важно продуктовым командам.
Таким образом, примерно 80% времени наша техническая команда занимается техналогом, а остальные 20% помогает продуктовым командам: подключается к достаточно сложным фичам и пробует свои задумки уже на практике.
Как рассчитывается техналог в hh.ru?
Мы давно используем достаточно простую формулу. Перед вами типичная карточка «портфель»:
Портфель – это тип задач в Jira, который соответствует фиче. Обычно он привносит какой-либо продуктовый или технический инкремент. Соответственно, если у портфеля есть лейбл «tax», это означает работу с техналогом. У портфеля есть обязательное поле – «story point», который показывает относительную величину фичи. Наш технический департамент достаточно большой – более 30 команд, и вес «story point» варьируется в зависимости от команды.
В мобилке мы договорились, что у нас это будет «грязный день». День, в который мы ведем разработку, оцениваем задачи, ходим на какие-то встречи, смотрим видео про выгорание в других компаниях, пьем чай, общаемся с коллегами, выбираем себе яхту. Короче говоря, типичный день разработки. Мы решили, что технический долг будет рассчитываться от начала календарного года, то есть от первого января, и в него будут включены все портфели, которые побывали в разработке.
Итак, формула следующая: мы берем эти портфели, вытаскиваем из них «story point» и складываем отдельно для технических и для всех. Потом делим одно на другое. В результате получается вот такой нехитрый процент.
На текущий момент только одна из наших мобильных продуктовых команд добрала допустимый процент техналога, а другие сильно торчат своей кодовой базе. Обратите внимание, недобор техдолга является отклонением и загорается на табло красным цветом. А еще на дверях своей квартиры можно обнаружить записки от технических коллекторов. Реальное фото:
Метрика получилась достаточно простая и легкая. Но вам не кажется, что с ней что-то не так?
Я составил табличку, где в одном столбике показано, сколько было «Story point» в портфеле, в другом – сколько дней в разработке был портфель. И получилось так, что эти цифры слабо коррелируют. Выходит, наша метрика не особо точная.
Как же тогда ее считать? Давайте попробуем оперировать не оценкой, а посчитаем на на реальных часах в разработке. Для этого сделаем запрос в API Jira, вытащим из неё даты, когда портфель переходил в статус «разработка: в работе», и когда он из него выходил. И собственно этот интервал и будем считать вместо «Story point». Таким образом вместо него будут реальные дни разработки.
Отлично! Получилось что-то интересное. Но вам не кажется, что опять что-то не так? Я снова залез в табличку и увидел, что некоторые портфели делались подозрительно быстро.
Например, в одном портфеле оценка была 20 «Story point», это достаточно много. При этом портфель мы сделали за 9 дней. Я стал разбираться и понял, что на самом деле его делали 4 человека. То есть вся команда подключилась, и они хором собрались и быстро-быстро довели фичу до релиза.
Как починить нашу формулу? Давайте введем еще один лейбл: будем указывать, сколько разработчиков работало над портфелем. Мы ввели лэйблы developers_count_1, developers_count_1,5, developers_count_2 и так далее. Откуда взялись эти полтора землекопа? В некоторых случаях один человек начинает портфель, а другой подключается к нему уже ближе к середине. Таким образом, можно примерно оценить, сколько людей работало над фичей. Получается уже достаточно честно.
Как изменится наша формула? Теперь вместо просто дней разработки мы складываем дни разработки, умноженные на число человек, которые принимали участие в работе над портфелем. Получаются самые настоящие «человекодни». Мы берем «человекодни», которые у нас были на разработку технических портфелей, делим на «человекодни», которые потратили всего и получаем искомый процент.
Важное замечания, для те. кто будет вести подсчёт
Не забудьте учесть то, что у вас портфель может два раза побывать в статусе «разработка» и «в работе». Например, кто-то его взял, случайно сдвинул и после вернул в исходный статус. В этом случае ваше вычисление собьется, поэтому учитывайте все вхождения в нужный статус.
Можно ли посчитать еще более честно? Конечно! Во-первых, можно выкинуть выходные и праздничные дни для абсолютно точного расчета. Во-вторых, когда разработчик уходит в отпуск или берёт day-off, его портфель нервно ждёт хозяина. Этими двумя факторами мы решили пренебречь.
И что в итоге?
Мы получили целый график. В каждой точке мы смотрим, какой процент техналога имеем на текущий день в году. И, кажется, что вот тут-то и должно начаться самое интересное. Но на самом деле нет. График очень скучный. Судите сами:
Каждый новый портфель, чем дальше мы идем по году, всё меньше и меньше влияет на общий процент техналога. Что закономерно, поэтому на график смотреть скучновато. Если в начале года он еще немножко бултыхается, то потом становится ощутимо стабильнее. Следственно, тут возникает идея: давайте будем смотреть график на более коротком промежутке и учитывать только те портфели, которые были в разработке последние 30 дней.
И этот график уже гораздо более интересный. По нему можно понять, занимается команда техническими задачами или же продуктовыми. Давайте посмотрим новые графики по командам и направлениям, которые у нас получились.
В красном прямоугольнике указаны значения, полученные при подсчёте новым способом, в белом — значения, подсчитанные по старой канонической формуле. Реальные значения в 3 из 4 продуктовых командах немного выше. Возможно это вызвано тем, что при съёмке “Охэхэнных историй” (а на текущий момент вышло аж 24 эпизода) их портфели довольно долго стояли на паузе в ожидании монтажа.
В начале статьи я обещал рассказать про ошибку в расчётах. И вот она. В видео я рассказывал о том, что цифры у нас катастрофически не сошлись в старом и новом способе. Местами расхождение достигло 10% и всегда в одну сторону. Из-за конфликта интересов я не продвигал новый способ расчета.
Так вот, на днях я решил добавить в график процента техналога по платформам и с ужасом обнаружил, что у нас в скрипте не было учтено количество разработчиков на портфеле. Когда я добавил этот параметр, графики пришли в норму. Теперь можно отслеживать не только тренды по соотношению техналог/продуктовые фичи, но и полностью им доверять.
Вместо выводов
Считать процент техналога просто необходимо. Ведь это может быть решающим аргументом в споре с продактом и докажет, что именно сейчас вам необходимо потратить время на технические задачи, чтобы разработка внезапно не затормозила плотно и надолго. Ну и, конечно же, проверяйте свои скрипты и будьте честны со своим продактом и кодовой базой!
На этом всё. Комментируйте, пишите, какой процент техналога у вас. Подписывайтесь, ставьте лайки и ждите новых «Охэхэнных историй» и статей. Пока!
