Меня зовут Александр Бунтов. Я разработчик, который однажды внезапно стал тимлидом: сначала пришел как старший/ведущий инженер, через несколько месяцев прежний лид ушел — и я взял роль на себя. Сейчас работаю в Ви.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, попадание в план, баги/фичи
раз в ретро — сверка экшен‑плана
