Войны фреймворков, неуправляемые разработчики и инопланетяне-фашисты: разговор с тимлидом Авито

Всем привет! Меня зовут Наташа Болдырева, я технический журналист в Авито. Как-то я наткнулась подкаст «Мы обречены» — его ведут программист Фил Ранжин и журналист Тёма Малышев. Один из выпусков меня особенно заинтересовал — ребята пригласили в гости нашего тимлида Машу Кондрашину. Они обсуждали важные темы: как изменился рынок за десять лет, как работает корректирующий фидбэк и почему «бутерброд» давно не работает, зачем нужны матрицы компетенций и что реально происходит, когда команда остаётся без лида на год. А ещё были всякие интересности — например, что делать, если в команде завёлся вредитель-инопланетянин.

Я не смогу передать всё содержание разговора, но постараюсь вынести для вас самое главное — где-то спорное, местами смешное, но очень честное. Если хотите послушать и узнать больше, — вот тг-канал подкаста. Там есть ссылки на беседу на разных платформах.

Начали сразу в лоб.

— Многих лидов шатает в момент перехода из инженера в менеджера. Это нормально: ты уже оставил одни навыки, а новые ещё не освоил полностью. Появляется ощущение «я теперь ни то, ни другое», — размышляла Маша.

Когда много лидишь и ничего не делаешь руками, ты как будто бы перестаёшь быть программистом. Читать код ещё можешь — насмотренность никуда не девается. Но чтобы снова стать штатным кодером, который каждый день пишет, нужно несколько месяцев вкатываться обратно.

Ещё один страх — последующий найм. Устроиться на позицию лида всегда сложнее. Большинство лидов растёт внутри компании или команды и, если ожидания от разработчиков примерно унифицированы, то ожидания от лидов могут быть абсолютно разными.

— Практически везде в бигтехе смотрят на два трека: есть ли компетенция старшего инженера, то есть понимаешь ли ты, что происходит технически, и есть ли менеджерский опыт, — объясняет Маша. — Не «пишешь ли ты код каждый день», а «понимаешь ли ты архитектуру и можешь ли управлять людьми».

Маша вспомнила такой эксперимент — ненамеренный, но очень показательный.

— Я работала в рекламной команде. Там был очень классный тимлид: много делегировал, команда была самостоятельная, все сами ресёрчили, лид занимался people management. Настоящая мечта.

Он ушёл. И команда первое время ехала отлично — процессы выстроены, люди самостоятельные, всё работало. Потом начался медленный распад.

Нового лида не могли найти год. За этот год: самые инициативные ушли туда, где есть перспективы роста и человек, который их видит. На команду навалили новые проекты и некому было сказать «стоп, у нас нет ресурса». Продукт продолжал генерировать идеи, но некому было удерживать баланс между фичами и техдолгом. Пять человек поддерживали пять проектов и за всем не успевали. Качество сервисов начало проседать.

Команда какое-то ограниченное время может ехать без лида, но потом становится видно, что лид отстаивает технический и менеджерский интерес команды — он держит много вещей, которые не заметны, пока он есть.

Фил в подростковом возрасте работал на стройке и паял трубы отопления, которые потом зашивали гипсом. Конечно, проверять надо было до того, как зашьют, но проверили после. Оказалось, что его трубы было очень легко найти — по мокрым пятнам.

— Мне дали корректирующий фидбэк, — говорит Фил. — Несмотря на то, что в нашем подкасте можно материться, я всё равно его не смогу воспроизвести. Потому что он был слишком…

У человека был талант. Он был создан для дачи корректирующего фидбэка.

Тёма, в свою очередь, признался, что ценит фидбэк пожёстче. Вспомнил, как работал сценаристом: принёс текст своему тимлиду. Тот был человеком старой школы, телевизионной закалки. Тот мгновенно его разнёс — всеми последними матами, которых Тёма и знал, и не знал, и не знал, что в таких сочетаниях вообще можно. Но зато те ошибки он запомнил на всю жизнь.

— А если бы убрать мат, и он тебе просто мягко сказал — ты бы не научился? — спросила Маша.

Конечно, научился бы. Но когда он прочитал свой текст после «корректирующего фидбэка», полученного ранее, он принёс ему невероятные страдания: «у него потекла кровь из глаз, из мозга» — и это цитата.

Вот здесь важное различие. В IT не принято орать, даже если человек сделал всё не так. И неважно почему именно случился фейл: случайно или из-за систематического «забивания». Жёсткость по содержанию и неуважение к человеку — это разные вещи.

Многие знают методику «бутерброда»: говоришь что-то хорошее, потом — проблему, потом — опять что-то хорошее. Логика простая: сладкое смягчит горькое.

По словам Маши, её уже давно считают неэффективной.

— Человек слышит хвалебный шум в начале и в конце и плохо усваивает то, что в середине. Или, что хуже, начинает ждать подвоха каждый раз, когда ему говорят что-то хорошее. «Ага, похвалили — значит, сейчас прилетит».

Нормальный корректирующий фидбэк устроен иначе:

Никакой сладкой обёртки. Никакого «но молодец в целом». Прямо, конкретно, с уважением к человеку.

Ребята смоделировали, как это звучало бы в случае Тёмы с текстом: «Ожидания были такими-то. Вот здесь не получилось, вот здесь не получилось. Это не совпадает с тем, что мы называем хорошим текстом. Пожалуйста, сделай по требованиям». Всё. Без травмы, но и без размазывания.

Фил предложил свой вариант:

— Чувак принёс pull-request, и мы поняли, что наняли некомпетентного кретина. Ожидание, что мы наймём адекватного человека, у которого есть минимальные мозги и который делает то, что надо. Ожидания не совпали. Чего мы теперь ждём?..

Маша порекомендовала попробовать потренироваться, чтобы не было оскорбления хотя бы в первом предложении. Ладно уж, пусть будет во втором.

— Есть люди, которые любят оскорблять. Их защитная позиция в том, что они якобы констатируют факт. Мол, «Я же не виноват в том, что ты идиот. Есть же другие люди, не идиоты, и им я никогда так не скажу, но ты сам это с собой сделал», — сказал Фил.

В разговоре возник конкретный кейс: что, если человек две недели делал большую задачу, принёс результат, а он неправильный вообще во всём? Оно намеренно неправильное. Допустим, он всё завайбкодил. Как бы звучал грамотный корректирующий фидбэк в таком случае? Ты нас обманул?

На это Маша предложила сначала разобраться в другом:

— Первый вопрос, который я задаю себе в такой ситуации: это была задача в рамках его ожиданий или выше?

Если в рамках грейда — значит, он не соответствует своему грейду. Тогда разговор прямой: «Смотри, ожидания вот такие. У тебя здесь не получилось. Возможно, я не досмотрела — надо было не две недели ждать, а поставить точки контроля раньше. Давай переделаем и постараемся так не делать».

Если задача была выше его уровня — то это скорее ошибка планирования. Тогда другой разговор: «Кажется, с первого раза прыгнуть выше головы не получилось. Давай подходить к таким задачам более итеративно».

Тёма в ответ пошутил, что это звучит как «тимлид допустил ошибку и дал задачу идиоту» — то есть тимлид берёт ответственность на себя.

— Звучит, конечно, жестоко. Странно считать всех вокруг идиотами, ведь все ошибаются. Но, по факту, ответственность действительно на тимлиде, — ответила Маша. — Потому что если ты нанял «идиота», стоит задуматься, кто принимал решение о найме.

Очень сложно качественно определить, что такое этот самый грейд и каковы его границы. Даже если человек получает задачу выше своего грейда, он может заняться ей после работы, посоветоваться с товарищем, подучить что-то и так далее. Как правильно заметил Фил, мы не в компьютерной игре, где на человека наводишь рамку и четко видишь уровень. Для этого обычно используют матрицы компетенций, где расписаны ожидания, чтобы можно было понять и как определить грейд, и чего ожидать.

— Ещё важно помнить, что человек не может знать все. Главное — выстроить с командой такие отношения, чтобы, в случае ступора или незнания, любой мог вовремя прийти и поделиться этим. Человек должен иметь возможность, а главное — уметь вовремя сказать, если что-то идёт не так, — объяснила Маша.

На старте карьеры особенно сложно признаваться, что ты чего-то не знаешь. Страшно: вдруг подумают, что я идиот :) Для этого и нужна среда, в которой это безопасно сказать.

Отдельная история — концепция таланта. Как его определить? Что это такое? Ребята обсуждали на примере: «Допустим, есть человек, у него неплохие компетенции, но недостаточно “ума”. Ему приходит задача сделать внутреннюю библиотеку. Что делать в такой ситуации, когда очевидно, что человек недостаточно интеллектуален и шансов получить удобный инструмент очень мало?»

Если у тебя нет таланта — всё решается усердием.

Например, Фил честно признался, что не считает себя талантливым программистом. У него неплохо получалось кодить, проходить собеседования, рассуждать о программировании и придумывать что-то. Его карьера была вечным побегом от того, чтобы сделать что-либо. Нормально и вовремя закрывать задачу (или заранее предупреждать, что в срок не получается) — уже талант. И это обычное ожидание сейчас в IT, потому что указывает на управляемость.

Когда человек не приходит в день дедлайна и говорит: «У меня не вышло». А приходит заранее и говорит: «Я застрял, вот в чём проблема, вот что мне нужно». Тогда в игру вступает тимлид: редактирует сроки, перераспределяет задачи и так далее.

Тёма признался, что у него нередко такое бывает: «5 минут до дедлайна — сдавать нечего». Фил, конечно, пошутил, что Тёма не пришёл раньше, потому что сел за задачу 5 минут назад. Правда, у Тёмы творческая работа, но и любой программист, как Фил, может решить, что именно его работа — творческая.

По словам Маши, именно для этого и нужны точки контроля на ранних этапах — особенно с новыми людьми и сложными задачами. Не чтобы следить, а чтобы вовремя заметить проблему и помочь. Когда между вами выстраивается доверие и человек становится более зрелым внутри компании, точки контроля снижаются сами собой.

А что делать с совсем неуправляемым

По мнению Маши, сначала стоит пытаться выровнять ситуацию — составлять планы, ставить чёткие сроки, давать поддержку. Если всё мимо и не получается — увольнять. Потому что неуправляемый процесс невозможно прогнозировать. Соответственно, выполнять задачи становится практически невозможно.

Конечно, не везде так. Весь диалог шеф подкаста всё ждал ответа на вопрос: «Что же делать с Тёмой?». Ответ ему никак не помог: благо, Тёма не в найме, его никак не уволить.

В жирные времена рынка такой ответ не был выходом. Невозможно было просто взять и уволить синьора. До последнего. К нему приходили и постоянно спрашивали: «Что нам сделать? Как тебе помочь? Дай нам путь, чтобы ты делал работу хоть чуточку».

— И сейчас вопрос именно в системности, — отметила Маша. И добавила:

— Мы не увольняем после первой ошибки. Поможем, чем сможем, но если движения навстречу нет — нам не подходит неуправляемый процесс. Ведь кто знает, может у человека кризис и он полгода ничего не хочет делать.

Кризисы и саббатикал

Кризисы случаются. По словам Маши, некоторым удавалось оставаться в команде и не перформить как раньше — важное уточнение: как раньше, такая история не сработала бы, если ты только пришёл в компанию и решил отдохнуть. Сейчас лучшим выходом из данной ситуации является саббатикал — неоплачиваемый отпуск с сохранением рабочего места.

По наблюдениям Фила, среди его знакомых после саббатикла чаще всего ничего особо не меняется.

Фил в этот момент вспомнил историю про Тёму. Он устроился писать статьи, и его заставляли их писать. Он был очень грустный и жаловался. Ему сказали: «Слушай, может, уйдёшь на месяц, отдохнёшь?» Он ушёл. Вернулся. И вдруг его снова работать заставляют.

Раньше также было множество споров, кто вообще должен писать код. Вайбкодинг изменил ситуацию. Простые приложения, скрипты, дашборды — всё это может собираться быстро, даже менеджерами без опыта программирования. Есть реальные истории, когда что-то навайбкодили, выложили, и оно приносит деньги.

Но у людей начала формироваться иллюзия, что программирование в целом — это просто. А для того, чтобы стать штатным кодером — учитывать весь контекст, аспекты, особенности и оптимально по времени выдавать результат — потребуется немало времени и усилий.

Фил сравнил это с болью дизайнеров. Дизайнер учился десять лет, прочитал кучу книг, сделал тысячи проектов. Приходит заказчик, считает, что он дизайнер, и говорит: «По-моему, красиво сочетается жёлтый с оранжевым». И платит десять тысяч рублей. По словам Фила, инженеры оказались в похожей ситуации:

— Любой человек может за вечер сделать что-то, примерно похожее на часть нашей работы. И из-за этого думает, что разобрался в программировании и понимает, сколько делается задача.

Был показательный случай, который рассказал Фил. Один его друг-менеджер долго просил сделать ему приложение. Фил отказывал: сложно, долго. В какой-то момент друг взял GPT и объявил: «Теперь мне программист не нужен, я сам сделаю». Первое время получалось. Потом контекстного окна не хватило, всё посыпалось, и в итоге — тысяча Java-ошибок при сборке. Весь запал мгновенно сдулся. Это было год назад — с тех пор инструменты стали сильно лучше. Но суть не изменилась: разница между «накодить прототип за вечер» и «сделать поддерживаемую систему» — огромная.

По словам Фила, есть ещё один риск: продакты, которые сами что-то вайбкодят, теряют связь с реальностью о том, сколько это делается по-настоящему. Приходят и говорят: «Я за вечер сделал — вы шесть человек сделайте за два дня». И это уже управленческая проблема. К счастью, по словам Маши, с такой проблемой сталкиваться не приходилось.

Иллюзия простоты началась раньше — с волны курсов «стань синьором за три месяца» и «зарабатывай 300 тысяч с нуля». Вот тогда в массовом сознании и сложилось: программирование — это быстро и просто.

Внутри больших IT-компаний это не такая острая история — там все понимают разницу между «прокликать промпт» и «выстроить архитектуру». Опаснее в маленьких командах и при работе с внешними заказчиками: именно там ожидания и реальность расходятся сильнее всего.

В разговоре была отдельная тема, которую грех пропустить.

Тёма скачал Temu в Грузии. Просто хотел найти коробочку, но, прежде чем добраться до поиска, прошёл через сотни экранов с розыгрышами, подарками, колёсами фортуны и таймерами. «Три минуты, чтобы забрать абсолютно всё бесплатно». «Возьми пять вещей любых».

Пятнадцать минут — и только потом система «пообиделась» и позволила поискать самому.

Это не случайность. Геймификация — сознательная стратегия, которая пока законодательно не ограничена. Она работает, потому что лёгкий эндорфин от «выигрыша» является мощным механизмом.

Маша вспомнила, что до логистики в Авито работала в команде рекламы.

— Это хорошо зарабатывающий продукт. Особенно после того, как ушли зарубежные игроки типа Google. И я немного устала слышать одно и то же: «На меня реклама не работает». Нет, работает. Просто люди воспринимают рекламу только как прямое целевое действие — кликнул, купил. Но реклама работает и на брендинг: просто мелькает перед глазами, и ты запоминаешь, что бренд существует. Не кликаешь сейчас, но когда придёт момент выбора, он окажется среди тех, кого ты «знаешь».

Тут Фил добавил:

— Баннерная слепота — это не значит, что реклама на тебя не работает. Это значит, что ты не осознаёшь, как именно она работает.

Отдельная история — маркировка. Раньше рекламный рынок был совсем диким: говори «лучшее пиво в мире», никто не проверял. Фил вспомнил, что ещё в детстве задавался вопросом: как можно называть себя «номер один в мире», это же ложь.

Сейчас обязали маркировать каждое рекламное сообщение — появился специальный ID, по которому государство может проверить, где и что было показано. Появились целые компании, которые помогают с этой маркировкой.

Это всё, конечно, никак не мешает Temu крутить колёса фортуны.

В конце разговора Тёма достал традиционную рубрику «шизанутый мысленный эксперимент». Он предупредил, что они давно этого не делали, а Маша стала первым гостем после возвращения этой традиции.

Условие: началось нашествие инопланетян-фашистов. Они захватывают тела людей. Тебя поймали. Говорят: твоя команда должна разработать фичу в очень сжатые сроки. Если провалите — убьём всех. Цена ошибки максимальная.

Но ты, как член сопротивления, знаешь: среди твоих разработчиков есть засланный казачок от инопланетян. Он будет намеренно писать плохой код и саботировать всё, что можно. Ты не знаешь, кто это. Твоя задача — выполнить фичу в срок. Что делаешь?

— Подожди, — остановила его Маша. — Значит, у нас команда, есть задача, есть лазутчик, и я не знаю, кто он?

— Именно. И всё, что он пишет, делает только хуже.

— Выстраивать нормальный процесс разработки, — ответила Маша.

Обязательные аппрувы на код-ревью — минимум два. Тесты. Автоматические проверки сборок. Валидация на каждом этапе. При таком процессе вредоносный код одного человека с большой вероятностью не проскочит незамеченным.

— Скажу ли я команде, что среди них вредитель? Нет.

Фил удивился:

— А почему?

— Потому что это потеря времени и паранойя, которая замедлит всех. Мне не нужно его искать — мне нужно сделать так, чтобы его действия не привели к катастрофе. Это разные задачи.

Фил добавил, смеясь:

— Если пойти к команде разработчиков и сказать: «Среди вас есть злонамеренный вредитель», — они такие: «А, я всегда это знал».

И ещё один аргумент привела Маша:

— Разработчики ошибаются, поэтому даже человек, который хочет всё сломать, вполне может ошибиться и случайно сделать всё хорошо.

Заниматься системами ограничений и проверок, по её словам, должны тимлид и несколько доверенных инженеров.

Тогда Тёма добавил условие: а если ещё нельзя написать ни строчки кода самой? Иначе убьют.

Ответ почти не изменился.

— Настраивать инфраструктуру — это не обязательно писать код. Код-ревью, пайплайны, системы тестирования, делегирование предохранителей инженеру — всё это работа тимлида без единой строки кода. Смотреть код же можно? Можно. Настраивать системы? Можно.

— Слабое место этого эксперимента, — говорит Фил, — в том, что когда приходишь к тимлиду и говоришь: «Представь, что у тебя в команде вредитель», он такой: «Так. И что изменилось?»

— Это примерно мой обычный вторник, — пошутила Маша.

Если сжать всё, о чём говорили в подкасте, до нескольких честных тезисов: