Уроки техлида Авито: как давать фидбек, почему разваливаются команды и в чем риски вайбкодинга
Управление разработкой в крупных технологических компаниях давно вышло за рамки чисто технического контроля. Сегодня это сложная дисциплина на стыке психологии, системного менеджмента и инженерии. Как эффективно выстраивать процессы в условиях высокой неопределенности, почему классические методы обратной связи приносят вред вместо пользы и что происходит, когда команда надолго остается без лидера? Эти и другие вопросы обсудила техлид Авито Маша Кондрашина в рамках интервью для ИТ-подкаста «Мы обречены». Выводы этой беседы позволяют по-новому взглянуть на привычные управленческие практики и внутренние процессы разработки в бигтехе.
Тимлид: между кодингом и менеджментом
Переход из роли сильного инженера в позицию тимлида — один из самых болезненных этапов в карьере разработчика. Основная проблема кроется в психологической ловушке: специалист оставляет привычные технические задачи, но еще не успевает полноценно освоить новые управленческие навыки. В результате возникает ощущение профессиональной неопределенности: «я уже не полноценный программист, но еще и не состоявшийся менеджер».
Когда тимлид перестает ежедневно писать код и фокусируется на координации, его навыки практического программирования неизбежно снижаются. Насмотренность и понимание архитектуры никуда не деваются, однако для возвращения к активному ежедневному кодингу после долгого перерыва специалисту потребуется несколько месяцев адаптации.
Эта специфика накладывает отпечаток и на процесс трудоустройства. Нанимать лидов всегда сложнее, так как требования к разработчикам в индустрии стандартизированы, а ожидания от руководителей сильно различаются от компании к компании. В бигтехе при найме оценивают два ключевых трека:
- Инженерная экспертиза: понимание архитектуры систем, технического стека и способность разговаривать с разработчиками на одном языке;
- Менеджерский опыт: умение управлять людьми, распределять ресурсы, выстраивать коммуникации и нести ответственность за конечный результат.
Анатомия распада: год без лидера
Чтобы понять истинную ценность роли руководителя, Маша Кондрашина привела показательный кейс из личной практики в рекламной команде Авито. Тимлид этой команды выстроил процессы образцово: активно делегировал задачи, развивал самостоятельность инженеров и фокусировался на развитию людей. Когда этот руководитель покинул компанию, процессы были настолько отлажены, что команда долгое время продолжала работать без каких-либо сбоев.
Однако поиски нового тимлида затянулись на целый год, и постепенно начался скрытый распад коллектива:
- Отток ключевых кадров: наиболее амбициозные и инициативные сотрудники, не видя перспектив роста и личного внимания со стороны руководства, покинули команду;
- Размытие фокуса: на самостоятельную команду начали напрямую вешать новые проекты. Без тимлида, способного твердо сказать «нет» внешним заказчикам, ресурсы быстро истощились;
- Дисбаланс задач: продуктовая команда продолжала генерировать новые фичи, но некому было защищать технический долг. В результате пять инженеров поддерживали пять разрозненных проектов, разрываясь между доработками и качеством кода;
- Падение стабильности: качество сервисов начало постепенно проседать.
Этот кейс доказывает: команда может автономно существовать без руководителя лишь ограниченное время. Лид выполняет массу невидимой работы, защищая технические и менеджерские интересы инженеров перед бизнесом.
Почему метод «бутерброда» не работает
Обратная связь — главный инструмент корректировки поведения сотрудников, но пользоваться им нужно уметь. Популярная методика «бутерброда» (когда критику упаковывают между двумя слоями похвалы) в современной практике менеджмента признана неэффективной и даже вредной.
Когда руководитель пытается сгладить углы, сотрудник слышит позитивное начало и хвалебный финал, полностью игнорируя критическую суть в середине. В худшем случае у человека вырабатывается рефлекс ожидания подвоха: получая искреннюю похвалу, он подсознательно ждет, что сейчас «прилетит» критика.
Здоровый корректирующий фидбек строится по жесткой, но уважительной четырехшаговой структуре:
- Описание ситуации: констатация факта без личных оценок и эмоций;
- Описание поведения: выделение конкретных действий сотрудника, которые необходимо изменить;
- Описание влияния: объяснение того, как именно это поведение отразилось на проекте, сроках или команде;
- Формулирование требований: четкое проговаривание того, какие изменения ожидаются в будущем.
В таком подходе нет сладкой обертки, но есть уважение к профессионализму сотрудника. Он понимает суть проблемы без лишних эмоций.
Разбор провалов: грейды и ответственность
Что делать, если сотрудник потратил две недели на важную задачу, но принес абсолютно неверный результат? В такой ситуации тимлид должен начать с анализа собственных управленческих действий.
В первую очередь необходимо сопоставить сложность задачи с грейдом исполнителя. Если задача соответствовала его уровню, но была полностью завалена, это указывает на несоответствие квалификации сотрудника его позиции. Тимлид должен провести прямой разговор и переделать задачу, сделав выводы на будущее. Если же задача была повышенной сложности, то провал — это ошибка планирования самого руководителя. В таком случае нужно менять подход и двигаться итеративно.
Во избежание подобных сюрпризов в день дедлайна критически важно выстраивать в команде культуру доверия. Разработчик должен иметь возможность открыто и безопасно признаться на раннем этапе, что он застрял или чего-то не знает. Для контроля сложных задач тимлиду необходимо внедрять ранние точки контроля. Они нужны не для тотального надзора, а для своевременной помощи и корректировки курса.
Если же сотрудник демонстрирует полную неуправляемость, не идет навстречу и систематически срывает сроки, единственным выходом остается увольнение. Непредсказуемый процесс делает невозможным выполнение обязательств перед бизнесом.
Вайбкодинг: иллюзия легких решений
Современные ИИ-ассистенты и визуальные инструменты разработки породили феномен вайбкодинга — быстрого создания работающих прототипов, скриптов и дашбордов силами менеджеров или начинающих специалистов без профильного образования. Это создает у бизнеса опасную иллюзию простоты программирования.
Написать рабочий прототип за один вечер с помощью генеративных моделей действительно стало легко. Однако существует колоссальная разница между прототипом и поддерживаемой промышленной системой. ИИ-помощники отлично решают изолированные задачи, но быстро теряют контекст при масштабировании, что приводит к архитектурным ошибкам, проблемам с зависимостями и сбоям при сборке.
Опасность вайбкодинга также заключается в том, что продакт-менеджеры теряют связь с реальностью. Сделав простой скрипт за пару часов с помощью нейросети, они начинают требовать от команды инженеров создания сложной отказоустойчивой системы за пару дней, не понимая разницы в объемах работы.
Системы ограничений вместо паранойи
В завершение беседы был проведен мысленный эксперимент: как выстроить работу над критически важным проектом в сжатые сроки, если известно, что в команде есть скрытый саботажник, намеренно пишущий плохой код?
Ответ техлида Авито оказался строго системным: не нужно тратить время на поиски «вредителя» и устраивать паранойю в коллективе. Это лишь парализует работу. Взамен необходимо настроить надежную инженерную инфраструктуру, которая автоматически нейтрализует любые деструктивные действия:
- Внедрение обязательного код-ревью с аппрувом минимум от двух независимых инженеров;
- Написание автоматических тестов, покрывающих ключевую бизнес-логику;
- Настройка жестких пайплайнов сборки и автоматических проверок кода.
Правильно выстроенная система ограничений защитит проект от любых рисков — будь то случайные ошибки уставшего сотрудника или намеренный саботаж. Задача лида — создавать именно такие устойчивые процессы.