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

Тема: «Системы международных отношений в ХХ веке: Версаль, Ялта и другие»

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

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

Когда: 27 мая, регистрация с 18:30, начало в 19:00
Где: Санкт-Петербург, отель Коринтия, зал «Ландскрона»

Если хотите присоединиться к встрече, обратите внимание, что регистрироваться обязательно. Сделать это можно по ссылке.

Будем рады вас видеть!

Реклама. ООО "Астон", ИНН:9715350151, erid: 2Vtzqv8BvJZ

Подкасты на выходные

Возвращаемся к нашей нерегулярной рубрике "Что послушать про тимлидство на выходных":

👉"Бреслав и Ложечкин" про вайбкодинг: область применимости, польза и последствия, влияние на будущее языков программирования и джунов в индустрии.
👉"КОДА КОДА" про проектный менеджмент как профессию: чем занимаются, как делится ответственность с продактом и тимлидом, что ожидает в будущем.
👉"Три тимлида заходят в бар" про succession planning: как вырастить себе замену, которая подменит тебя в отпуске или когда ты пойдешь на повышение.
👉Weekend Talks с Романом Ивлиевым, бессменным директором TeamleadConf, про переосмысление карьеры после 25 лет в IT, боли тимлида и отказ от консалтинга.

Про экономику вайбкодинга

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

Самое простое объяснение этому – сравнительная незрелость моделей, к тому же натренированных на больших количествах плохого кода. Но есть и другое возможное объяснение – провайдеры моделей в целом не очень заинтересованы в том, чтобы кода генерировалось меньше. Они зарабатывают деньги на токенах, а чем больше кодовая база, тем больше токенов вы потратите за каждую итерацию работы с ней.

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

Как нанимать джунов с учетом AI

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

👉Умение формулировать понятный промпт и верифицировать результаты AI.
👉Умение смотреть на код критически, задавая вопросы "почему здесь так, а не иначе?"
👉Понимание границ применимости AI и всех ограничений, включая приватность и этику.

Такие навыки превращают джуниора в полезного члена команды, а не в бездумную прослойку между AI и ментором. Что можно сделать, чтобы прийти к этой картине:

1️⃣Сменить подход к найму – вместо оценки знания алгоритмов смотреть на то, как кандидат задаёт вопросы модели и исправляет её промахи.
2️⃣Организовывать работу через трио сеньор + джуниор + AI. Пусть опытный разработчик показывает ход мысли, новичок – задает вопросы и озвучивает сомнения, ассистент – генерирует код. Знания передаются быстрее, ошибки ловятся раньше.
3️⃣Чередуйте задачи с AI и без него. Хотя бы раз в спринт давайте новичку задачу, решить которую надо целиком вручную, чтобы не атрофировались навыки вроде дебага.
4️⃣ Добавьте в свой онбординг гайд по AI, в том числе какие данные можно загружать в модель, какие – категорически нельзя.
5️⃣Пересмотрите свои критерии перфоманса для джунов. Оценивайте не просто закрытые задачи, а способность объяснить решение, быстро найти и починить баг, предложить улучшение после отклика ассистента.

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

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

Например, Яна, продакт в Яндекс Музыке, составляет свой личный контент-план и постоянно пополняет его новыми книгами и фильмами. А еще — пишет и выпускает электронную музыку с этно-мотивами! Всё это — не только классные хобби, но и способ по-новому взглянуть на рабочие задачи.

Это мы узнали из нового фан-исследования Яндекса о продактах компании. Ребята провели его, чтобы показать: за каждой метрикой стоят люди со своими историями и увлечениями.

Исследование открытое. Присоединяйтесь и узнайте, какой вы всё-таки продакт: маэстро хаоса, техномаг или властелин порядка?

Architecture Decision Records

Как вы знаете, ADR – документ, который описывает важные технические решения, весь нужный контекст вокруг из принятия и последствия. По ссылке – большая подборка шаблонов, рекомендаций по работе с ними и даже специализированных тулов вроде adr-tools. А самое интересное – публичные гайдлайны конкретных компаний:

👉Amazon
👉GitHub
👉RedHat

Как выглядит продуктивность разработчика при использовании AI инструментов

Сотрудники Авито ведут свой telegram-канал ⭐️

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

А вообще хвалим и одобряем. Во-первых, смело и интересно. Во-вторых, для тех, кто рассматривает работу в компании, это возможность изучить культуру и вайб команды ещё до трудоустройства.

🔥 Однозначно подписка — @avito_life
🔥🔥 Если думаешь о работе в Авито, то добавляй сразу — @avito_career

Как хвастаться своей работой

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

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

👉Идеально, когда про вас рассказывают другие люди. Для этого нужно уметь вовремя оказывать помощь тем, кому она может пригодиться. Например, когда кто-то работает над знакомой вам задачей, вы можете поделиться своим опытом, или скинуть сохранившиеся документы.
👉Регулярно делитесь в релевантных каналах синтезом результатов своей работы в таком формате, чтобы это было полезно другим. Например, закончив большой проект, поделитесь lessons learned. Не забудьте дойти и до тех, кто когда-то высказывал интерес к этому проекту.
👉Не создавайте дополнительной работы для других, и явно пишите, зачем вы шарите что-то – требуется ли от читателей какое-то действие, или просто показываете для ознакомления.
👉Почаще делитесь и результатами других людей. Все как в одном из примеров выше – если кто-то работает над проблемой, а вы встречали релевантные идеи у кого-то еще, обязательно пришлите их человеку.
👉Избегайте частых ошибок: не шарьте работу плохого качества, не уделяйте слишком много внимания процессу вместо результатов и инсайтов, делитесь работой других чаще, чем своей.

Советы по созданию линеек грейдов

Есть вероятность, что в недалеком будущем все эти матрицы компетенций и структурные карьерные линейки постепенно вымрут. AI одновременно и подталкивает к тому, чтобы один человек динамично сочетал в себе несколько ролей, и существенно облегчает это – поэтому наша индустрия может прийти к небольшим командам с плоской структурой и довольно слабо зафиксированными ролями. А это плохо ложится в заранее очерченные рамки.

Но если вы уверены, что вам нужно описание карьерных уровней, вот набор советов от человека, который первым выложил карьерный фреймворк своей компании в открытый доступ:

👉Не давайте HR составлять описания уровней, получится фигня. Определять требуемый уровень экспертизы для разных уровней вообще не их работа.
👉Детали важны. Если ваше описание уровней похоже на гороскоп, оно будет только вредить. Субъективных штук вроде "high impact", "large systems" не избежать, но вы можете постараться минимизировать количество таких абстрактных терминов, и дать хоть какую-то шкалу для их оценки.
👉Хороший способ объяснить смысл и логику за табличкой – сопроводить ее подробным блог-постом.
👉Постарайтесь не превращать эту табличку в чек-лист компетенций, который гарантирует промо на следующий уровень по его заполнению. Промо – функция не только навыков человека, но и текущих потребностей компании.
👉Будьте честными – не для каждой профессии можно подготовить линейку от самых низких уровней до VP.

Про big bets

Big bet – типичное название для большой и стратегически важной инициативы, в которой напрямую заинтересован СЕО или кто-то из топов. Чаще всего они тащат за собой кучу скрытых рисков и проблем, включая ухудшение морали команды и отток ресурсов от других важных направлений.

Отличительные признаки большой ставки:

1️⃣Топ-менеджмент говорит о ней таким образом, как будто у нее нет никаких продуктовых и бизнесовых рисков, и единственное, что может пойти не так – execution.
2️⃣Проект получает не меньше ресурсов, чем полноценные зрелые направления, несмотря на свою раннюю стадию.
3️⃣Он заявляется как стратегически важный.

Так вот, лидить такой проект чаще всего плохая идея. Вот почему:

👉Как я и сказал выше, топ-менеджеры слишком верят в то, что проект выстрелит – поэтому если он провалится, то вся вина будет на лиде, который не смог его заделиверить.
👉Из-за вот этой чрезмерной уверенности, такие проекты минуют все стадии адекватной продуктовой разработки – часто нет ни исследования рынка, не проверки продуктовой гипотезы, вообще ничего. Короче говоря, big bet – это очень конкретное решение для несформулированной и непроверенной проблемы.

Учимся учиться на инцидентах

Происходит инцидент. Минимально необходимое требование – потушить пожар и вернуть ваш продукт в рабочее состояние. Задача со звездочкой – найти и устранить корневую причину его возникновения. Стандартная техника для этого – RCA, Root Cause Analysis. Это очень прямолинейный подход с понятной ценностью для команд. Но в больших и сложных системах только RCA бывает недостаточно.

Тут на сцену выходит сравнительно новый подход LFI, Learning from Incidents. В отличие от RCA, главная цель LFI – узнать новые детали про то, как работает система, и обогатить ментальную модель тех, кто ее поддерживает. Логика простая – очень часто в процессе устранения инцидента помимо корневой проблемы можно узнать много других интересных вещей и выявить какие-то проблемы, которые могут отстрелить где-то в будущем.

Иначе говоря, RCA фокусируется на known unknowns, а LFI – unknown unknowns.