Time-to-First-Commit как метрика
Сколько дней нужно новому разработчику до первого коммита и почему это важно
Первый день, который определяет всё
Картинка знакомая. В команду выходит новый разработчик. Четыре раунда собеседований, оффер, согласованная дата — и вот он сидит перед корпоративным ноутбуком с чистой операционной системой. То, что произойдёт дальше, — один из самых недооценённых моментов в инженерной культуре. Первые дни закладывают фундамент отношения к компании, к коду и к команде на месяцы вперёд.
В индустрии для этого процесса есть отдельная метрика — Time to First Commit, или TTFC. Она показывает, сколько времени проходит с момента выхода нового разработчика до его первого осмысленного коммита в кодовую базу. По данным Stripe Developer Coefficient и другим индустриальным исследованиям, среднее значение TTFC в отрасли — от двух до четырёх недель, а лучшие команды добиваются первого коммита за один-три дня.
Что показывает TTFC
TTFC — метрика не скорости разработчика, а качества инженерной инфраструктуры. Если человек две недели не может закоммитить ни строчки, проблема не в нём — проблема в документации, в процессе настройки окружения, в системе доступов, в архитектуре.
Каждый день задержки складывается из конкретных блокеров, и GitLab хорошо описал типичный набор. Устаревшие README с инструкциями по настройке, которые никто не обновлял с прошлого года. Цепочка из восьми-десяти internal-инструментов, каждый со своим аккаунтом и VPN. Локальное окружение, зависящее от специфической версии Node.js, конкретного образа Docker, правильных переменных окружения и удачного расположения звёзд. Новичок становится первым, кто обнаруживает все накопившиеся поломки: остальные давно настроили окружение и забыли, через какой ад прошли.
Экономика ожидания
Считаем. Senior-разработчик обходится компании в 500–700 тысяч рублей в месяц (с учётом налогов, оборудования, лицензий). Один рабочий день — около 25–35 тысяч рублей. TTFC в две недели вместо двух дней — это 200–300 тысяч рублей на каждого нового сотрудника ещё до того, как он начал приносить пользу. При найме 20 человек в год — 4–6 миллионов рублей, выброшенных на борьбу с инфраструктурой.
Прямые финансовые потери — лишь часть. Есть скрытая стоимость: время действующих инженеров, отвлекающихся на помощь новичкам (по данным исследований, сеньоры тратят 4–8 часов в неделю на поддержку каждого новичка в период онбординга). Есть мотивационная стоимость: тот, кто две недели сидит и настраивает окружение, начинает сомневаться в выборе работодателя, и первое впечатление потом исправлять трудно.
Как компании решают эту проблему
Shopify построил недельную программу онбординга, в которой каждый новый разработчик к пятнице делает коммит, попадающий в продакшен, — реальный фикс, затрагивающий реальных пользователей. Для этого готовится пул задач подходящей сложности, каждому новичку назначается ментор, а настройка окружения автоматизирована до одной-двух команд в терминале. Идея: impact в первую же неделю, для чего нужны рабочие инструменты, а не тридцатистраничный гайд по настройке.
Stripe группирует новых инженеров во временные команды на три-четыре недели, где они работают с выделенным ментором над конкретным проектом — внутренним инструментом или улучшением продукта. Каждому назначают spin-up buddy из будущей команды, который помогает со всем — от технических вопросов до культурных норм. Stripe учился на собственных ошибках: в ранние годы компания не вкладывалась в онбординг, и сотрудники описывали первые недели как «sink or swim».
Общий паттерн у компаний с коротким TTFC: предварительная настройка (всё, что можно подготовить до первого дня, подготовлено), автоматизация окружения (dev containers, скрипты, cloud environments), структурированный первый проект (не «разберись сам», а конкретная задача с ментором).
Как измерять и на что ориентироваться
Измерить TTFC проще, чем кажется: фиксируется дата выхода сотрудника и дата его первого мёрджа в основную ветку. Считать стоит осмысленный коммит — не тестовый «hello world» в README, а реальное изменение в кодовой базе, пусть и маленькое.
Ориентиры:
- Меньше 1 дня — мировой класс, достигается через cloud development environments и полностью автоматизированное окружение
- 1–3 дня — хороший уровень, говорит о работающем процессе онбординга
- 1–2 недели — средний по индустрии, есть пространство для улучшения
- Больше 2 недель — серьёзный сигнал о проблемах с инфраструктурой и документацией
Помимо общей цифры, стоит отслеживать TTFC по отделам и командам. Если в одной команде новички стартуют за день, а в другой за три недели, проблема локализована и чинится легче. Полезно проводить ретроспективу онбординга с каждым новым сотрудником через месяц: что было сложно, где застряли, что улучшить. Эти данные — золото: через полгода человек привыкнет ко всем неудобствам и перестанет их замечать.
Рекомендации
Сокращение TTFC начинается с аудита: следующий новый сотрудник записывает каждый блокер с точным временем. Через неделю появится карта боли, которую можно приоритизировать. Обычно 80% времени онбординга съедают 3–4 конкретные проблемы: настройка локального окружения, получение доступов, поиск актуальной документации, разбирательство с зависимостями. Каждую из них можно решить — конкретные инструменты разбираются в следующих главах: Dev Containers, Cloud Development Environments и практики компаний, которые довели онбординг до нескольких минут.