Собственник: «Олег, у меня IT-компания. 20 разработчиков. За год уволились 15 человек. Каждые 2-3 месяца кто-то уходит. Плачу выше рынка, даю плюшки, но люди все равно уходят. Что делать?»
Я: «А ты проводил exit-интервью?»
Он: «Ну да. Говорят, что нашли интересный проект. Или устали. Или хотят расти. Ничего конкретного».
Я: «Они не говорят правду. Потому что боятся сжечь мосты. Давай копнем глубже».
Коротко
IT-компании теряют разработчиков не из-за денег.
Деньги - это предлог.
Уходят из-за хаоса, непонимания целей, отсутствия роста, плохого управления.
Просто не говорят об этом на выходе - зачем портить отношения?
Мы зашли в компанию, где текучка была 70% в год.
Нашли 5 причин.
Через 3 месяца текучка упала до 15%.
Дыра 1. Нет понятного карьерного трека
Как было
Разработчик приходит, работает, получает задачи.
Через год - делает то же самое.
Через два - то же самое.
Непонятно, как вырасти.
Непонятно, что нужно сделать для повышения.
Непонятно, когда это произойдет.
Что увидели в опросах
90% уволившихся сказали: «Не было роста».
Но на самом деле им не нужна была должность «тимлид».
Им нужна была понятная лестница:
- джун → мидл → сеньор → лид
- с понятными критериями
- с конкретными сроками
Этого не было.
Потери:
каждый уход разработчика - 3-6 месяцев на поиск и ввод нового
прямые потери: рекрутинг, адаптация, потеря скорости
1,5-2 млн на одного сотрудника
Что сделали
Создали карьерную матрицу.
Джун:
- решает задачи с наставником
- код-ревью обязательно
- срок: 6-12 месяцев
Мидл:
- решает задачи самостоятельно
- пишет тесты
- помогает джунам
- срок: 12-18 месяцев
Сеньор:
- проектирует архитектуру
- проводит код-ревью
- учит других
- срок: от 2 лет
Лид:
- управляет командой
- общается с заказчиком
- строит процессы
Каждый разработчик знает:
- где он сейчас
- что нужно сделать, чтобы перейти на следующий уровень
- примерные сроки
Результат:
люди перестали уходить «потому что некуда расти»
Дыра 2. Бесполезные код-ревью
Как было
Код-ревью было формальностью.
Сеньор писал «ок» или «исправь» без объяснений.
Разработчик не понимал, что не так.
Исправлял наугад.
Злился.
Что увидели в опросах
- 60% разработчиков назвали код-ревью бесполезным
- 40% сказали, что боятся показывать код
- 30% признались, что «забивают» на правки, если ревьювер не настаивает
Качество кода падало.
Багов становилось больше.
Разработчики выгорали.
Потери:
- больше времени на отладку
- больше критических багов
- медленнее фичи
Что сделали
Ввели правила код-ревью.
- каждое замечание - с объяснением: «почему так не надо» и «как надо»
- не более 50 строк за один раз (иначе сложно читать)
- время на ревью - не более 2 часов
- нельзя оставлять комментарий «ок» - только содержательные замечания или одобрение
Сделали чек-лист для ревьювера:
- код соответствует задаче?
- есть тесты?
- нет дублирования?
- названия переменных понятны?
Результат:
- качество кода выросло
- разработчики перестали бояться ревью
- багов стало меньше на 40%
Дыра 3. Нет четкого процесса постановки задач
Как было
Задачи ставили кто во что горазд.
В устной форме.
В мессенджерах.
На летучках.
Разработчик получал задачу, делал, а через неделю выяснялось: «Я имел в виду другое».
Что увидели в опросах
- 50% времени тратилось на переделки
- 70% разработчиков жаловались на нечеткие требования
- 30% сказали, что перестали уточнять - делают «как поняли», потому что все равно переделают
Потери:
половина времени команды - в переделках
при фонде оплаты труда 2 млн в месяц - 1 млн потерь
Что сделали
Ввели единый шаблон задачи:
- что нужно сделать (конкретно)
- зачем это нужно (контекст)
- критерии приемки (как поймем, что готово)
- дедлайн
Задача не принимается, если не заполнены все поля.
Результат:
- переделки сократились на 60%
- скорость выросла на 30%
Дыра 4. Митинги ради митингов
Как было
Утром - стендап.
В обед - планерка.
Вечером - ретро.
На каждом митинге - по часу.
Итого - 3 часа в день.
Из них полезных - 30 минут.
Что увидели в опросах
- 80% разработчиков назвали митинги главным пожирателем времени
- 60% признались, что отключаются через 15 минут
- 40% работают на митингах (пишут код)
Потери:
3 часа × 20 разработчиков = 60 часов в день
60 × 500 руб (стоимость часа) = 30 000 руб в день
660 000 руб в месяц
Что сделали
Ввели правила митингов:
- стендап - 10 минут, только «что сделал, что буду делать, какие блокеры»
- планерка - 30 минут, только для принятия решений
- ретро - 1 раз в неделю, 1 час
- остальные вопросы - асинхронно в чатах или тасках
Результат:
- время на митинги сократилось с 15 до 4 часов в неделю
- +11 часов чистого кодинга на человека
- скорость разработки выросла на 25%
Дыра 5. Нет обратной связи
Как было
Раз в год - формальная оценка.
Собственник: «Ты молодец. Работай дальше».
Никакой конкретики.
Разработчик не знал:
- что у него хорошо
- что плохо
- куда расти
Что увидели в опросах
- 70% уволившихся назвали «отсутствие обратной связи» одной из причин
- 50% текущих сотрудников не знают, доволен ли ими руководитель
Потери:
люди уходят, потому что не понимают, где они находятся
Что сделали
Ввели регулярные one-on-one.
Раз в 2 недели - 30 минут с руководителем.
Без задач.
Без проектов.
Только:
- как дела
- что нравится
- что не нравится
- что хочется изменить
- как помочь
И раз в квартал - формальная оценка по критериям из карьерной матрицы.
Результат:
- люди перестали уходить «ни с того ни с сего»
- проблемы видны за 2 недели, а не в день увольнения
Что сказал собственник
«Я думал, что люди уходят из-за денег.
Поднимал зарплаты - не помогало.
А оказалось, что у нас не было системы.
Люди не знали, как расти.
Код-ревью было формальностью.
Митинги съедали половину дня.
Обратную связь не давали.
Сейчас у нас карьерная матрица, понятные задачи, быстрые митинги, регулярные one-on-one.
Текучка упала с 70% до 15%.
И знаете - зарплаты мы не поднимали».
Чек-лист для IT-компании
Карьерный трек
- Есть понятная карьерная матрица?
- Разработчик знает, как перейти на следующий уровень?
- Есть примерные сроки?
Код-ревью
- Ревью полезное или формальное?
- Замечания с объяснениями?
- Есть чек-лист?
Задачи
- Задачи ставятся по шаблону?
- Понятны критерии приемки?
- Переделок мало?
Митинги
- Митинги короткие?
- Только нужные люди?
- Нет митингов ради митингов?
Обратная связь
- Регулярные one-on-one?
- Разработчик знает, как у него дела?
- Проблемы видны заранее?
Если хоть на один вопрос ответ «нет» - вы теряете разработчиков.
P.S. Про MAX
В MAX я каждый день разбираю такие кейсы.
Приходите со своей IT-компанией - найдем ваши дыры.
P.P.S. Прямо сейчас.
Откройте список уволившихся за последний год.
Подумайте: если бы вы знали их реальные причины за 2 месяца до ухода, скольких удалось бы удержать?
Если больше половины - вы теряете деньги. Каждый месяц.