Всем привет! Меня зовут Наташа Болдырева, я технический журналист в Авито. Как-то я наткнулась подкаст «Мы обречены» — его ведут программист Фил Ранжин и журналист Тёма Малышев. Один из выпусков меня особенно заинтересовал — ребята пригласили в гости нашего тимлида Машу Кондрашину. Они обсуждали важные темы: как изменился рынок за десять лет, как работает корректирующий фидбэк и почему «бутерброд» давно не работает, зачем нужны матрицы компетенций и что реально происходит, когда команда остаётся без лида на год. А ещё были всякие интересности — например, что делать, если в команде завёлся вредитель-инопланетянин.
Я не смогу передать всё содержание разговора, но постараюсь вынести для вас самое главное — где-то спорное, местами смешное, но очень честное. Если хотите послушать и узнать больше, — вот тг-канал подкаста. Там есть ссылки на беседу на разных платформах.
Содержание
Тимлид: программист или менеджер?
Начали сразу в лоб.
— Многих лидов шатает в момент перехода из инженера в менеджера. Это нормально: ты уже оставил одни навыки, а новые ещё не освоил полностью. Появляется ощущение «я теперь ни то, ни другое», — размышляла Маша.
Когда много лидишь и ничего не делаешь руками, ты как будто бы перестаёшь быть программистом. Читать код ещё можешь — насмотренность никуда не девается. Но чтобы снова стать штатным кодером, который каждый день пишет, нужно несколько месяцев вкатываться обратно.
Ещё один страх — последующий найм. Устроиться на позицию лида всегда сложнее. Большинство лидов растёт внутри компании или команды и, если ожидания от разработчиков примерно унифицированы, то ожидания от лидов могут быть абсолютно разными.
— Практически везде в бигтехе смотрят на два трека: есть ли компетенция старшего инженера, то есть понимаешь ли ты, что происходит технически, и есть ли менеджерский опыт, — объясняет Маша. — Не «пишешь ли ты код каждый день», а «понимаешь ли ты архитектуру и можешь ли управлять людьми».
Что происходит с командой, когда лид уходит
Маша вспомнила такой эксперимент — ненамеренный, но очень показательный.
— Я работала в рекламной команде. Там был очень классный тимлид: много делегировал, команда была самостоятельная, все сами ресёрчили, лид занимался people management. Настоящая мечта.
Он ушёл. И команда первое время ехала отлично — процессы выстроены, люди самостоятельные, всё работало. Потом начался медленный распад.
Нового лида не могли найти год. За этот год: самые инициативные ушли туда, где есть перспективы роста и человек, который их видит. На команду навалили новые проекты и некому было сказать «стоп, у нас нет ресурса». Продукт продолжал генерировать идеи, но некому было удерживать баланс между фичами и техдолгом. Пять человек поддерживали пять проектов и за всем не успевали. Качество сервисов начало проседать.
Команда какое-то ограниченное время может ехать без лида, но потом становится видно, что лид отстаивает технический и менеджерский интерес команды — он держит много вещей, которые не заметны, пока он есть.
Корректирующий фидбэк: почему «бутерброд» не работает и что делать вместо него
Фил в подростковом возрасте работал на стройке и паял трубы отопления, которые потом зашивали гипсом. Конечно, проверять надо было до того, как зашьют, но проверили после. Оказалось, что его трубы было очень легко найти — по мокрым пятнам.
— Мне дали корректирующий фидбэк, — говорит Фил. — Несмотря на то, что в нашем подкасте можно материться, я всё равно его не смогу воспроизвести. Потому что он был слишком…
У человека был талант. Он был создан для дачи корректирующего фидбэка.
Тёма, в свою очередь, признался, что ценит фидбэк пожёстче. Вспомнил, как работал сценаристом: принёс текст своему тимлиду. Тот был человеком старой школы, телевизионной закалки. Тот мгновенно его разнёс — всеми последними матами, которых Тёма и знал, и не знал, и не знал, что в таких сочетаниях вообще можно. Но зато те ошибки он запомнил на всю жизнь.
— А если бы убрать мат, и он тебе просто мягко сказал — ты бы не научился? — спросила Маша.
Конечно, научился бы. Но когда он прочитал свой текст после «корректирующего фидбэка», полученного ранее, он принёс ему невероятные страдания: «у него потекла кровь из глаз, из мозга» — и это цитата.
Вот здесь важное различие. В IT не принято орать, даже если человек сделал всё не так. И неважно почему именно случился фейл: случайно или из-за систематического «забивания». Жёсткость по содержанию и неуважение к человеку — это разные вещи.
Почему «бутерброд» уже не считается хорошей практикой
Многие знают методику «бутерброда»: говоришь что-то хорошее, потом — проблему, потом — опять что-то хорошее. Логика простая: сладкое смягчит горькое.
По словам Маши, её уже давно считают неэффективной.
— Человек слышит хвалебный шум в начале и в конце и плохо усваивает то, что в середине. Или, что хуже, начинает ждать подвоха каждый раз, когда ему говорят что-то хорошее. «Ага, похвалили — значит, сейчас прилетит».
Нормальный корректирующий фидбэк устроен иначе:
описываешь ситуацию — что именно произошло, без оценок;
описываешь поведение — конкретное поведение, которое хотели бы поддержать или изменить;
описываешь влияние — как то, что произошло, на всё повлияло;
говоришь, что хочешь изменить.
Никакой сладкой обёртки. Никакого «но молодец в целом». Прямо, конкретно, с уважением к человеку.
Ребята смоделировали, как это звучало бы в случае Тёмы с текстом: «Ожидания были такими-то. Вот здесь не получилось, вот здесь не получилось. Это не совпадает с тем, что мы называем хорошим текстом. Пожалуйста, сделай по требованиям». Всё. Без травмы, но и без размазывания.
Фил предложил свой вариант:
— Чувак принёс pull-request, и мы поняли, что наняли некомпетентного кретина. Ожидание, что мы наймём адекватного человека, у которого есть минимальные мозги и который делает то, что надо. Ожидания не совпали. Чего мы теперь ждём?..
Маша порекомендовала попробовать потренироваться, чтобы не было оскорбления хотя бы в первом предложении. Ладно уж, пусть будет во втором.
— Есть люди, которые любят оскорблять. Их защитная позиция в том, что они якобы констатируют факт. Мол, «Я же не виноват в том, что ты идиот. Есть же другие люди, не идиоты, и им я никогда так не скажу, но ты сам это с собой сделал», — сказал Фил.
Что делать, когда человек завалил большую задачу
В разговоре возник конкретный кейс: что, если человек две недели делал большую задачу, принёс результат, а он неправильный вообще во всём? Оно намеренно неправильное. Допустим, он всё завайбкодил. Как бы звучал грамотный корректирующий фидбэк в таком случае? Ты нас обманул?
На это Маша предложила сначала разобраться в другом:
— Первый вопрос, который я задаю себе в такой ситуации: это была задача в рамках его ожиданий или выше?
Если в рамках грейда — значит, он не соответствует своему грейду. Тогда разговор прямой: «Смотри, ожидания вот такие. У тебя здесь не получилось. Возможно, я не досмотрела — надо было не две недели ждать, а поставить точки контроля раньше. Давай переделаем и постараемся так не делать».
Если задача была выше его уровня — то это скорее ошибка планирования. Тогда другой разговор: «Кажется, с первого раза прыгнуть выше головы не получилось. Давай подходить к таким задачам более итеративно».
Тёма в ответ пошутил, что это звучит как «тимлид допустил ошибку и дал задачу идиоту» — то есть тимлид берёт ответственность на себя.
— Звучит, конечно, жестоко. Странно считать всех вокруг идиотами, ведь все ошибаются. Но, по факту, ответственность действительно на тимлиде, — ответила Маша. — Потому что если ты нанял «идиота», стоит задуматься, кто принимал решение о найме.
Честность и точки контроля — лучше, чем сюрпризы в дедлайн
Очень сложно качественно определить, что такое этот самый грейд и каковы его границы. Даже если человек получает задачу выше своего грейда, он может заняться ей после работы, посоветоваться с товарищем, подучить что-то и так далее. Как правильно заметил Фил, мы не в компьютерной игре, где на человека наводишь рамку и четко видишь уровень. Для этого обычно используют матрицы компетенций, где расписаны ожидания, чтобы можно было понять и как определить грейд, и чего ожидать.
— Ещё важно помнить, что человек не может знать все. Главное — выстроить с командой такие отношения, чтобы, в случае ступора или незнания, любой мог вовремя прийти и поделиться этим. Человек должен иметь возможность, а главное — уметь вовремя сказать, если что-то идёт не так, — объяснила Маша.
На старте карьеры особенно сложно признаваться, что ты чего-то не знаешь. Страшно: вдруг подумают, что я идиот :) Для этого и нужна среда, в которой это безопасно сказать.
Человек не может знать всё. Задача менеджера — создать среду, в которой люди могут вовремя сказать об этом
Отдельная история — концепция таланта. Как его определить? Что это такое? Ребята обсуждали на примере: «Допустим, есть человек, у него неплохие компетенции, но недостаточно “ума”. Ему приходит задача сделать внутреннюю библиотеку. Что делать в такой ситуации, когда очевидно, что человек недостаточно интеллектуален и шансов получить удобный инструмент очень мало?»
Если у тебя нет таланта — всё решается усердием.
Например, Фил честно признался, что не считает себя талантливым программистом. У него неплохо получалось кодить, проходить собеседования, рассуждать о программировании и придумывать что-то. Его карьера была вечным побегом от того, чтобы сделать что-либо. Нормально и вовремя закрывать задачу (или заранее предупреждать, что в срок не получается) — уже талант. И это обычное ожидание сейчас в IT, потому что указывает на управляемость.
Когда человек не приходит в день дедлайна и говорит: «У меня не вышло». А приходит заранее и говорит: «Я застрял, вот в чём проблема, вот что мне нужно». Тогда в игру вступает тимлид: редактирует сроки, перераспределяет задачи и так далее.
Тёма признался, что у него нередко такое бывает: «5 минут до дедлайна — сдавать нечего». Фил, конечно, пошутил, что Тёма не пришёл раньше, потому что сел за задачу 5 минут назад. Правда, у Тёмы творческая работа, но и любой программист, как Фил, может решить, что именно его работа — творческая.
По словам Маши, именно для этого и нужны точки контроля на ранних этапах — особенно с новыми людьми и сложными задачами. Не чтобы следить, а чтобы вовремя заметить проблему и помочь. Когда между вами выстраивается доверие и человек становится более зрелым внутри компании, точки контроля снижаются сами собой.
А что делать с совсем неуправляемым
По мнению Маши, сначала стоит пытаться выровнять ситуацию — составлять планы, ставить чёткие сроки, давать поддержку. Если всё мимо и не получается — увольнять. Потому что неуправляемый процесс невозможно прогнозировать. Соответственно, выполнять задачи становится практически невозможно.
Конечно, не везде так. Весь диалог шеф подкаста всё ждал ответа на вопрос: «Что же делать с Тёмой?». Ответ ему никак не помог: благо, Тёма не в найме, его никак не уволить.
В жирные времена рынка такой ответ не был выходом. Невозможно было просто взять и уволить синьора. До последнего. К нему приходили и постоянно спрашивали: «Что нам сделать? Как тебе помочь? Дай нам путь, чтобы ты делал работу хоть чуточку».
— И сейчас вопрос именно в системности, — отметила Маша. И добавила:
— Мы не увольняем после первой ошибки. Поможем, чем сможем, но если движения навстречу нет — нам не подходит неуправляемый процесс. Ведь кто знает, может у человека кризис и он полгода ничего не хочет делать.
Кризисы и саббатикал
Кризисы случаются. По словам Маши, некоторым удавалось оставаться в команде и не перформить как раньше — важное уточнение: как раньше, такая история не сработала бы, если ты только пришёл в компанию и решил отдохнуть. Сейчас лучшим выходом из данной ситуации является саббатикал — неоплачиваемый отпуск с сохранением рабочего места.
По наблюдениям Фила, среди его знакомых после саббатикла чаще всего ничего особо не меняется.
Фил в этот момент вспомнил историю про Тёму. Он устроился писать статьи, и его заставляли их писать. Он был очень грустный и жаловался. Ему сказали: «Слушай, может, уйдёшь на месяц, отдохнёшь?» Он ушёл. Вернулся. И вдруг его снова работать заставляют.
Вайбкодинг, курсы «за три месяца» и иллюзия простоты
Раньше также было множество споров, кто вообще должен писать код. Вайбкодинг изменил ситуацию. Простые приложения, скрипты, дашборды — всё это может собираться быстро, даже менеджерами без опыта программирования. Есть реальные истории, когда что-то навайбкодили, выложили, и оно приносит деньги.
Но у людей начала формироваться иллюзия, что программирование в целом — это просто. А для того, чтобы стать штатным кодером — учитывать весь контекст, аспекты, особенности и оптимально по времени выдавать результат — потребуется немало времени и усилий.
Фил сравнил это с болью дизайнеров. Дизайнер учился десять лет, прочитал кучу книг, сделал тысячи проектов. Приходит заказчик, считает, что он дизайнер, и говорит: «По-моему, красиво сочетается жёлтый с оранжевым». И платит десять тысяч рублей. По словам Фила, инженеры оказались в похожей ситуации:
— Любой человек может за вечер сделать что-то, примерно похожее на часть нашей работы. И из-за этого думает, что разобрался в программировании и понимает, сколько делается задача.
Был показательный случай, который рассказал Фил. Один его друг-менеджер долго просил сделать ему приложение. Фил отказывал: сложно, долго. В какой-то момент друг взял GPT и объявил: «Теперь мне программист не нужен, я сам сделаю». Первое время получалось. Потом контекстного окна не хватило, всё посыпалось, и в итоге — тысяча Java-ошибок при сборке. Весь запал мгновенно сдулся. Это было год назад — с тех пор инструменты стали сильно лучше. Но суть не изменилась: разница между «накодить прототип за вечер» и «сделать поддерживаемую систему» — огромная.
Вайбкодинг хорошо работает для изолированных задач. Он плохо масштабируется на системы с архитектурой, зависимостями и требованиями к поддержке
По словам Фила, есть ещё один риск: продакты, которые сами что-то вайбкодят, теряют связь с реальностью о том, сколько это делается по-настоящему. Приходят и говорят: «Я за вечер сделал — вы шесть человек сделайте за два дня». И это уже управленческая проблема. К счастью, по словам Маши, с такой проблемой сталкиваться не приходилось.
Это не вайбкодинг виноват
Иллюзия простоты началась раньше — с волны курсов «стань синьором за три месяца» и «зарабатывай 300 тысяч с нуля». Вот тогда в массовом сознании и сложилось: программирование — это быстро и просто.
Внутри больших IT-компаний это не такая острая история — там все понимают разницу между «прокликать промпт» и «выстроить архитектуру». Опаснее в маленьких командах и при работе с внешними заказчиками: именно там ожидания и реальность расходятся сильнее всего.
Реклама, геймификация и «на меня это не работает»
В разговоре была отдельная тема, которую грех пропустить.
Тёма скачал Temu в Грузии. Просто хотел найти коробочку, но, прежде чем добраться до поиска, прошёл через сотни экранов с розыгрышами, подарками, колёсами фортуны и таймерами. «Три минуты, чтобы забрать абсолютно всё бесплатно». «Возьми пять вещей любых».
Пятнадцать минут — и только потом система «пообиделась» и позволила поискать самому.
Это не случайность. Геймификация — сознательная стратегия, которая пока законодательно не ограничена. Она работает, потому что лёгкий эндорфин от «выигрыша» является мощным механизмом.
Маша вспомнила, что до логистики в Авито работала в команде рекламы.
— Это хорошо зарабатывающий продукт. Особенно после того, как ушли зарубежные игроки типа Google. И я немного устала слышать одно и то же: «На меня реклама не работает». Нет, работает. Просто люди воспринимают рекламу только как прямое целевое действие — кликнул, купил. Но реклама работает и на брендинг: просто мелькает перед глазами, и ты запоминаешь, что бренд существует. Не кликаешь сейчас, но когда придёт момент выбора, он окажется среди тех, кого ты «знаешь».
Тут Фил добавил:
— Баннерная слепота — это не значит, что реклама на тебя не работает. Это значит, что ты не осознаёшь, как именно она работает.
Отдельная история — маркировка. Раньше рекламный рынок был совсем диким: говори «лучшее пиво в мире», никто не проверял. Фил вспомнил, что ещё в детстве задавался вопросом: как можно называть себя «номер один в мире», это же ложь.
Сейчас обязали маркировать каждое рекламное сообщение — появился специальный ID, по которому государство может проверить, где и что было показано. Появились целые компании, которые помогают с этой маркировкой.
Это всё, конечно, никак не мешает Temu крутить колёса фортуны.
Мысленный эксперимент: вредитель в команде
В конце разговора Тёма достал традиционную рубрику «шизанутый мысленный эксперимент». Он предупредил, что они давно этого не делали, а Маша стала первым гостем после возвращения этой традиции.
Условие: началось нашествие опасных крэйзи-инопланетян. Они захватывают тела людей. Тебя поймали. Говорят: твоя команда должна разработать фичу в очень сжатые сроки. Если провалите — убьём всех. Цена ошибки максимальная.
Но ты, как член сопротивления, знаешь: среди твоих разработчиков есть засланный казачок от инопланетян. Он будет намеренно писать плохой код и саботировать всё, что можно. Ты не знаешь, кто это. Твоя задача — выполнить фичу в срок. Что делаешь?
— Подожди, — остановила его Маша. — Значит, у нас команда, есть задача, есть лазутчик, и я не знаю, кто он?
— Именно. И всё, что он пишет, делает только хуже.
— Выстраивать нормальный процесс разработки, — ответила Маша.
Обязательные аппрувы на код-ревью — минимум два. Тесты. Автоматические проверки сборок. Валидация на каждом этапе. При таком процессе вредоносный код одного человека с большой вероятностью не проскочит незамеченным.
— Скажу ли я команде, что среди них вредитель? Нет.
Фил удивился:
— А почему?
— Потому что это потеря времени и паранойя, которая замедлит всех. Мне не нужно его искать — мне нужно сделать так, чтобы его действия не привели к катастрофе. Это разные задачи.
Фил добавил, смеясь:
— Если пойти к команде разработчиков и сказать: «Среди вас есть злонамеренный вредитель», — они такие: «А, я всегда это знал».
И ещё один аргумент привела Маша:
— Разработчики ошибаются, поэтому даже человек, который хочет всё сломать, вполне может ошибиться и случайно сделать всё хорошо.
Заниматься системами ограничений и проверок, по её словам, должны тимлид и несколько доверенных инженеров.
Тогда Тёма добавил условие: а если ещё нельзя написать ни строчки кода самой? Иначе убьют.
Ответ почти не изменился.
— Настраивать инфраструктуру — это не обязательно писать код. Код-ревью, пайплайны, системы тестирования, делегирование предохранителей инженеру — всё это работа тимлида без единой строки кода. Смотреть код же можно? Можно. Настраивать системы? Можно.
— Слабое место этого эксперимента, — говорит Фил, — в том, что когда приходишь к тимлиду и говоришь: «Представь, что у тебя в команде вредитель», он такой: «Так. И что изменилось?»
— Это примерно мой обычный вторник, — пошутила Маша.
Короче
Если сжать всё, о чём говорили в подкасте, до нескольких честных тезисов:
Войны фреймворков закончились. Выбор технологии больше не определяет профессиональную идентичность — рынок решает за тебя.
Сеньор сегодня — это не только «шарит», но и несёт ответственность. Время «двух месяцев ничегонеделания» ушло вместе с голодом на рынке.
Тимлид — это другая профессия. Не «лучший программист в комнате», а менеджер с инженерным бэкграундом. Понимать код обязательно. Писать каждый день — нет.
Команда может работать без лида, но не бесконечно. Деградация приходит постепенно.
Корректирующий фидбэк — это не бутерброд. Описывай ситуацию, поведение, эффект и что нужно изменить. Прямо, конкретно, с уважением.
Важно не сюрпризить в дедлайн. Создавай среду, в которой люди могут вовремя сказать, что что-то идёт не так.
Вайбкодинг снижает порог входа, но не отменяет инженерию. Иллюзия простоты опаснее, чем кажется.
Лучшая защита от хаоса — не поиск виноватых, а системы предохранения.
Спасибо, что дочитали до конца! Делитесь мыслями и задавайте вопросы в комментариях!
