Меня зовут Александр Бунтов. Я разработчик, который однажды внезапно стал тимлидом: сначала пришел как старший/ведущий инженер, через несколько месяцев прежний лид ушел - и я взял роль на себя. Сейчас работаю в Ви.Tech - IT-дочке ВсеИнструменты.ру
В статье расскажу, как за первые 100 дней перевел команду в более устойчивый режим: без «реформ с порога», но с понятными договорённостями, нормальными ритуалами, фиксом оценки задач и делегированием так, чтобы команда меньше дергалась и больше делала.
Будет полезно новым тимлидам и сеньорам перед промо. Если у вас сейчас ощущение “все горит, люди устают, планирование не работает” - тут для вас.
Точка А: с чем я зашел в роль и чего боялся
На старте у меня была маленькая команда: 4 человека - 2 разработчика и 2 QA. Команда в целом самостоятельная, но после ухода прежнего тимлида было видно, что людям не хватает опоры: где-то усталость, где-то раздражение, где-то осторожность.
Параллельно пришлось быстро закрывать вакансию - примерно за месяц нанял middle-разработчика. Это добавило онбординга и нагрузило тех, кто и так тащил.
Из того, что болело сильнее всего:
Оценка задач - скакала и рушила планирование. То «на день», то «на две недели», и в итоге никто не верит цифрам.
Коммуникационный шум - всех дергали по любому поводу: «а вы можете посмотреть…», «а давайте срочно…», «а вот тут надо созвон…».
Состояние людей - последствия смены лида: кому-то нужно было пространство, кому-то - ясность, кому-то - ощущение, что их слышат.
Мой главный страх был не “как чинить процессы” — это я воспринимал как набор рабочих задач. Страх был один: как меня примет команда.
На входе: сначала играем по текущим правилам, потом меняем
Я заранее заключил с собой договор на первую неделю: не устраивать революцию.
Что я делал:
погружался руками: понять сервисы, потрогать код, посмотреть релизный процесс;
на��людал: где реально тормозит, где «так исторически сложилось», а где просто никто не взял ответственность;
много слушал: что людям мешает и где они уже пробовали чинить, но бросили.
Чего точно не делал:
микроменеджмент и “дышать в затылок” по каждой задаче;
перерисовывать процессы на доске в первый же день;
играть в «я сейчас наведу порядок» - это быстро убивает доверие.
Что я сказал команде прямо:
люди важнее процессов;
моя роль - убирать помехи, а не контролировать ради контроля;
если обещаю «схожу/узнаю/согласую» — делаю в срок; если не уверен — не обещаю.
Это банально звучит, но доверие в реальности покупается именно так: маленькими выполненными обещаниями.
Дни 0–30: погружение, 1:1 и первые быстрые победы
Первые 30 дней у меня было две параллельные линии:
продолжать закрывать свои инженерные задачи по OKR/плану;
не “управлять командой”, а настроить связь с людьми и убрать самый токсичный шум.
1:1: что спрашивал
Я провёл 1:1 со всеми. Без сложной психологии - просто вопросы, которые быстро дают картину:
что бесит в текущей работе;
где застреваешь чаще всего;
что было бы самым полезным изменением на ближайший месяц;
где тебе нужна моя помощь как лида;
что ты точно не хочешь, чтобы я делал.
Сам факт 1:1 дал эффект: люди увидели, что новый лид пришёл не “сверху рулить”, а разбираться.
Быстрые победы (те, которые команда реально почувствовала)
1) Срезал встречи в “тяжёлый день”
Часть ритуалов (включая daily) перевел в асинхрон. Важно: я не “отменил коммуникацию”, я поменял форму.
Результат ощущался сразу: меньше зума, больше времени на работу.
2) Перезапустил ретро
Вместо унылого “хорошо/плохо” в Google Docs - Miro, разминка, сменные шаблоны, эмоциональный чек-ин.
Цель была простая: сделать так, чтобы люди начали говорить, а не ставить галочки.
3) Забрал кросс-коммуникации на себя
Все, что “не про текущий спринт”, начал фильтровать сам: будущие проекты, внешние согласования, «просто уточнить».
Это резко снижает дерготню: разработчик может закончить задачу, не переключаясь каждые 15 минут.
Дни 31–60: чиню оценку и ритуалы «по делу»
На этом участке стало ясно: если не починить оценку - мы будем вечными заложниками хаоса.
Что пробовали и что не взлетело
Мы пытались делать асинхронный теханализ. Идея понятная: “вот задачка, вот контекст, напишите мысли”.
По факту - не заработало. Асинхрон размазывает ответственность: никто не уверен, что это “его”, и все расползается.
Что заработало: еженедельный теханализ-созвон
Мы закрепили еженедельную сессию теханализа: аналитики + разработчики вместе декомпозируют задачи, задают вопросы, фиксируют подход.
Ключевой момент - не “созвон ради созвона”, а конкретный выход:
понятный scope,
список вопросов/рисков,
договорённость по реализации,
после этого — оценка.
Эффект: меньше «задач на два спринта», оценки стали ближе к реальности, и главное - команда начала верить в планирование.
Ретро: замкнутый цикл, а не разговоры
Я ввёл структуру, чтобы ретро не пре��ращалось в терапию:
боль > гипотезы > план действий > owner > срок > проверка прогресса на следующем ретро.
Пока у ретро нет продолжения - это просто разговор. Когда есть продолжение - люди видят смысл и включаются.
Дни 61–100: делегирование, автономность и подстраховка
Цель этого этапа я формулировал так: “чтобы без меня работало”.
Что делегировал
Ретро: по моему формату начали вести ребята. Я помог с подготовкой, шаблонами, таймингом - дальше они сами.
Демо: отдал старшему QA как постоянную зону ответственности. Это неожиданно хорошо ложится на QA-роль: они часто видят продукт шире и умеют “показать глазами пользователя”.
Подмена на отпуск: заранее готовил 2–3 человек - чтобы могли провести покер-планирование, ответить на кросс-вопросы, удержать ритуалы.
Почему “подстраховка” важнее, чем кажется
Пока тимлид - единственная точка принятия решений, команда неустойчива.
Когда есть заранее понятная схема подмены - исчезает нервяк. И у тебя появляется нормальный отпуск, а не “отпуск с ноутбуком”.
Как я мерил вовлечtнность и здоровье процессов
Я не люблю “опросятины”, поэтому старался мерить то, что видно по делу.
Процессные метрики
cycle time
попадание в план / стабильность velocity
время ревью и зависания задач
После фикса оценки cycle time сократился примерно с 30 до 14–15 дней. Это не “магия”: просто стало меньше сюрпризов и переработок.
Качество
критичные баги за полгода - 1
отношение багов к фичам - <5%, часто 0% месяц к месяцу
“Температура кома��ды”
На ретро делали эмоциональные штуки типа “графика настроения” по спринту или “найди себя среди мемов”.
Не для смеха, а потому что это показывает: команда бодрая или уже буксует, и где именно.
Обратная связь, когда вслух еще не говорят
Каналы я держал простые:
1:1
ретро
иногда анонимная форма (редко, но полезно, когда команде трудно говорить вслух)
Фрейм разговора, который у меня чаще всего работает:
факт > интерпретация > запрос/предложение.
Не “ты плохой”, а:
вот конкретная ситуация,
вот как я это понимаю,
вот что предлагаю попробовать.
Один кейс из практики: у разработчика “сыпалась организация”. Дал своевременную обратную связь, предложил понятный инструмент (и, да, книжку про тайм-менеджмент). Через пару недель стало заметно: меньше опозданий, меньше ошибок, больше предсказуемости.
Ритуалы, которые «разговорили» команду
Мой рабочий шаблон ретро выглядел примерно так:
Check-in (2–3 минуты): шкала состояния / короткая разминка
Факты и боли (10 минут)
Решения (через вопросы):
откуда знаем, что проблема есть?
что делаем сейчас? что мешает?
какой самый простой шаг в следующий спринт?
Экшен-план: owner, срок, критерий
Проверка прогресса на следующем ретро
Ключевой эффект - замкнутый цикл: люди видят, что их боли превращаются в действия.
Ошибки и развилки
Одна ошибка, которую я не хочу повторять: компромиссный найм.
На сложный домен взяли middle - и онбординг занял сильно больше времени, чем мы закладывали.
Вывод, который я себе записал: лучше дольше искать сеньора, чем “закрыть по-быстрому тем, что есть на рынке”, если домен тяжёлый и цена онбординга высокая.
Лидерские принципы
Люди важнее процессов, но процессы - это забота о людях.
Береги фокус команды: шум убивает скорость сильнее, чем сложные задачи.
Доверие - валюта. Его покупают делами, а не словами.
До/после: цифры, которые видит менеджмент
Показатель | Было | Стало | Комментарий |
|---|---|---|---|
Cycle time (p50) | ~30 дней | 14–15 дней | после еженедельного теханализа |
Критичные баги / полгода | — | 1 | стабильность релизов |
Баги/фичи | — | <5% (часто 0) | месяц к месяцу |
ENPS команды | 4,4? | 4,6 | нужно уточнить “до” |
360 (3-балльная / 5-балльная) | — | 2,6 / 4,6 | по разным кварталам |
Что точно продолжу в практике, а от чего откажусь
Оставляю:
совместный теханализ с аналитиками раз в неделю;
ретро с экшен-планом и проверкой прогресса;
делегирование ритуалов + схема подмены на отпуск.
Иначе в следующий раз:
раньше зафиксировать кросс-коммуникации на тимлида (фильтр шума);
не соглашаться на middle в сложный домен;
быстрее запускать эмоциональные чек-ины - это помогает раньше поймать выгорание.
Итог
За первые 100 дней я:
стабилизировал планирование (еженедельный теханализ, точнее оценки, короче cycle time);
снял шум (асинхрон там, где перегружено, кросс-коммуникации на себе);
разговорил команду (ретро с экшенами, чек-ины, замкнутый цикл изменений);
начал делегировать и сделал подстраховку (ритуалы ведут ребята, есть подмена на отпуск);
по метрикам: ENPS 4,6; 360 — 2,6/3 и 4,6/5; cycle time 14–15 дней; критичных багов — 1 за полгода.
Коротко план, как вторить за два спринта:
Спринт 1
1:1 со всеми > карта болей
убрать 1–2 самых шумных встречи (перевести в async)
запустить ретро с экшен-планом и проверкой прогресса
Спринт 2
еженедельный теханализ с аналитиком > правила оценки
выбрать и обучить владельцев ритуалов (ретро/демо)
добавить эмоциональный чек-ин (простой)
Трекер
cycle time, попадание в план, баги/фичи
раз в ретро - сверка экшен-плана
