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 миллионов рублей, выброшенных на борьбу с инфраструктурой.
Но прямые финансовые потери — это только часть проблемы. Есть ещё скрытая стоимость: время ваших текущих инженеров, которые отвлекаются на помощь новичкам (по данным исследований, senior-разработчики тратят от 4 до 8 часов в неделю на поддержку каждого нового человека в период онбординга). Есть мотивационная стоимость: человек, который две недели сидит и настраивает окружение, начинает сомневаться в своём выборе работодателя — и это ощущение первого впечатления очень трудно исправить.
Как компании решают эту проблему
Shopify построил недельную программу онбординга, в которой каждый новый разработчик к пятнице делает коммит, попадающий в продакшен — реальный фикс, который затрагивает реальных пользователей. Для этого 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 по отделам и командам — если в одной команде новички стартуют за день, а в другой за три недели, то проблема локализована и её легче починить. Полезно также проводить ретроспективу онбординга с каждым новым сотрудником через месяц: что было сложно, где застряли, что можно улучшить. Эти данные — золото, потому что через полгода этот человек привыкнет ко всем неудобствам и перестанет их замечать.
Рекомендации
Если вы хотите сократить TTFC в своей команде, начните с аудита: попросите следующего нового сотрудника записывать каждый блокер, с которым он сталкивается, с точным временем. Через неделю у вас будет карта боли, которую можно приоритизировать. Обычно 80% времени онбординга съедают 3-4 конкретные проблемы: настройка локального окружения, получение доступов, поиск актуальной документации, разбирательство с зависимостями. Каждую из этих проблем можно решить — и в следующих главах мы поговорим о конкретных инструментах: Dev Containers, Cloud Development Environments и практиках компаний, которые довели онбординг до нескольких минут.