Вопрос “Сколько времени тратить на технические задачи?” вызывает самые ожесточенные бои между продактами и разработчиками. В этой статье расскажем, как считают метрики в 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% и всегда в одну сторону. Из-за конфликта интересов я не продвигал новый способ расчета.
Так вот, на днях я решил добавить в график процента техналога по платформам и с ужасом обнаружил, что у нас в скрипте не было учтено количество разработчиков на портфеле. Когда я добавил этот параметр, графики пришли в норму. Теперь можно отслеживать не только тренды по соотношению техналог/продуктовые фичи, но и полностью им доверять.
Вместо выводов
Считать процент техналога просто необходимо. Ведь это может быть решающим аргументом в споре с продактом и докажет, что именно сейчас вам необходимо потратить время на технические задачи, чтобы разработка внезапно не затормозила плотно и надолго. Ну и, конечно же, проверяйте свои скрипты и будьте честны со своим продактом и кодовой базой!
На этом всё. Комментируйте, пишите, какой процент техналога у вас. Подписывайтесь, ставьте лайки и ждите новых «Охэхэнных историй» и статей. Пока!
