AI Agentic Lab

Голос задрожал, но я был к этому готов Я презентовал результаты аудита процессов двух команд. В аудитории — техлиды команд, ИТ-лид кластера и CTO. Проведение аудита — его запрос. Лид кластера был не в восторге от результатов — разговор предстоял непростой. На первых минутах голос даже начал дрожать. Но я быстро взял его под контроль, потому что уже полтора месяца занимался с преподавателем по речи. Я всегда говорил быстро — меня периодически переспрашивали. Мысли в голове бежали так, что я не успевал их произнести. Боялся, что буду казаться медленным — поэтому старался говорить как можно скорее. Когда я смотрел на руководителей, то замечал, что они говорят иначе. Спокойно, размеренно и на пониженных тонах. Такая речь смотрелась убедительно и вызывала доверие. Я понимал, что нужно говорить иначе, но ничего не менял — ведь это не приводило к катастрофам. Успокаивал себя, что самое главное — содержание речи, с которым у меня не было проблем. Но ощущение, что мой образ явно проигрывает более опытным коллегам, меня не покидало. Весной 2026 я решил форсировать карьерный рост. Процессы в моей команде были выстроены хорошо. Поэтому CTO поручил мне провести аудит работы двух смежных команд. Это была отличная возможность применить мои компетенции на уровне кластера. Впереди были важные разговоры и презентации. Я осознал: моя манера говорить может помешать в карьерном росте. Параллельно я учился сторителлингу для блога. И меня тогда поразило, как чётко и убедительно говорила автор курса. Она рассказывала, что уделяет этому большое внимание и специально берёт занятия по голосу. Я решил пойти тем же путём. Времени на подготовку оставалось чуть больше месяца. Я срочно начал искать преподавателя или курсы. В итоге решил, что индивидуально будет эффективнее. На первом занятии преподаватель определила мою главную проблему — слабую артикуляцию губ. Но сами занятия оказались не про голос. Упор был сделан на содержание речи. Я прямо сказал, что мне нужно подтянуть именно тембр и интонации, а не структуру рассказа, но не был услышан. Поэтому после двух занятий я решил сменить преподавателя. Вторая попытка была успешной. Мы работали над сложными звуками и их сочетаниями. Читали скороговорки, прозу и стихи. Я делал домашние задания и уже через пару недель стал виден результат. Губы задвигались выразительнее — сначала я даже комплексовал. Но потом привык и перестал обращать на это внимание. Речь становилась чёткой и понятной. Но вернёмся к презентации результатов аудита. Разговор с самого начала был непростым. Голос дрожал на первых минутах. Но мне быстро удалось побороть волнение. Паузы в речи, утвердительные интонации и низкий тембр дополняли мой стройный и логичный рассказ. Помогали снять волнение и отвечать на вопросы коллег. После презентации я получил отличный фидбэк от руководителя и предложение перейти на позицию ИТ-лида. Сейчас я продолжаю работать над голосом. Хочу научиться стабильно говорить на пониженных тонах. Получается ещё не всегда. Но я стараюсь контролировать себя, чтобы довести навык до автоматизма. После начала занятий я стал больше обращать внимание на то, как говорят окружающие. Заметил, что чем лучше у человека поставлена речь, тем более сильное впечатление он производит на окружающих. Сейчас я провожу много интервью — и здесь ситуация повторяется. Лучшие результаты показывают кандидаты, которые могут просто и понятно доносить свои мысли. Это значительно повышает шансы получить оффер при прочих равных. Уверен, что важность качества речи для разработчиков также будет только расти. В 2026 году AI быстрее пишет код, но не защищает архитектуру перед бизнесом. Не убеждает команду в правильности предлагаемых технических решений. Эта роль остаётся за человеком. Поэтому способность убедительно говорить о себе и своих решениях — это уже не опциональный софт-скилл. Это новый хард-скилл продуктового инженера. А вы обращаете внимание на речь коллег вокруг? Обо мне | Telegram | MAX

Создание AI-агентов. Глава 1. Обзор На прошлой неделе я наконец-то получил книгу «Создание приложений с ИИ-агентами» и прочитал первую главу залпом. До этого я целый год занимался разработкой AI-агентов и собирал информацию по крупицам. Читал десятки статей и смотрел видео, но там были только базовые концепции и простые примеры. Как из этого строить сложные системы — информации практически не было. Да и парадигма работы с LLM постоянно менялась: сначала все верили в промпты, потом в силу контекста, а сейчас — в harness и мультиагентные системы. Как и многие на рынке, мы с командой шли к результату через неудачные гипотезы и рабочие решения. Итеративно развивали систему. Искали баланс между креативностью модели и скоростью её ответа. Всё это время я искал более глубокие материалы по теме, но ничего не находил. И вот теперь хочу поделиться впечатлениями от первой главы и мыслями о прочитанном. Ещё до появления книги я обратил внимание, что многие команды допускают одни и те же ошибки при проектировании и разработке продуктов на основе AI. Об этом же говорит автор в начале книги и даёт практические советы, как их не повторять: Основной критерий агентности — автономность и принятие решений. На практике же далеко не все системы, которые сегодня называют «агентными», действительно обладают автономностью. В основе этих ошибок — лёгкость интеграции LLM в любое приложение. Я видел кейсы, когда сама идея разработки агентов даже не подвергалась сомнению Не последнюю роль в этом играет хайп вокруг AI, когда все хотят разрабатывать именно агентов. Чтобы задать некоторые ориентиры, автор приводит самые распространённые типы агентных систем на сегодня: • Агенты бизнес-задач и разговорные агенты. • Агенты-исследователи (Perplexity AI или Elicit). • Аналитические агенты (Power BI Copilot или Glean). • Агенты разработки (Claude Code или Codex). • Агенты предметных областей и браузерные агенты. На этом концептуальная часть завершается, и автор переходит к практическим советам — рассказывает, как определить наиболее подходящий тип системы под конкретную задачу: В основе выбора — четыре ключевых фактора: изменчивость данных, сложность необходимой логики и рассуждений, ограничения по производительности, а также сложность сопровождения. В итоге получаем четыре основных кейса: • Предсказуемый ввод + простая логика → детерминированный код. • Большое конечное число шагов и ветвлений → workflow-движки. • Вопросы и ответы по базе знаний без действий → RAG-системы. • Динамическое планирование и обучение → полноценный AI-агент. По опыту, ошибки на этапе проектирования закладывают в систему проблемы, которые со временем будут только нарастать, а сложность их исправления — увеличиваться. Именно поэтому автор в итоге делает следующий вывод: Сознательное принятие этого решения гарантирует, что вы получите правильное соотношение простоты, производительности и адаптируемости, чтобы ваше решение оставалось как эффективным, так и простым в сопровождении при эволюции требований. Согласен с каждым словом. При проектировании всегда есть два крайних решения и несколько промежуточных. Крайние варианты здесь — это детерминированный код и полная адаптивность. Задача архитектора — правильно выбрать одно из них. В условиях, когда индустрия идёт в сторону единой роли Product Engineer, совсем скоро этот выбор будет стоять перед большинством сегодняшних разработчиков. А умение и опыт в этом вопросе будут определять востребованность каждого на рынке труда. В следующей главе автор рассказывает о проектировании полноценных агентов крупными мазками. С большим интересом продолжаю читать и в итоге сделаю очередной обзор. Поделитесь, был ли у вас опыт работы с «агентными» системами, которые в действительности таковыми не являлись? Обо мне | Telegram | MAX

Не жди, когда будешь знать всё Месяц назад на встрече 1:1 разговорились с разработчиком из команды. Он отлично пишет код, но не решается проектировать и принимать решения и говорит: Я не уверен, что готов к этому. Тогда я рассказал ему свою историю, как не ждать, когда будешь знать вообще всё, и сделать это драйвером своего роста. Мне было 30 лет. Я только перешёл в Java-разработку. Джун с зарплатой в 50 000 ₽, а дома ребёнок и беременная жена. Для сравнения — мои ровесники тогда были с 5–7 годами опыта. Уверенные сеньоры и даже техлиды. Я же был в роли догоняющего — временем на медленный рост я не располагал. Проходил курсы: Java, Spring, базы данных. Через полтора года даже перешёл на мидла в новый проект. Зарплата росла, но не так, чтобы быстро. Я тогда работал через подрядчика. Под Новый год коллеги по команде из Сбера получили годовые бонусы. Размер, понятно, никто не говорил, но путешествия на острова или в горы говорили сами за себя. Мне стало грустно — и я подумал: Догоню ли я их когда-нибудь? Кажется, что разрыв между нами уже слишком велик. И вот ещё через год мне предлагают перейти в Сбер и стать техлидом. Опыт работы с людьми у меня был большой, а вот технических скилов явно не доставало. Но я всё равно согласился. Почему? Других вариантов у меня не было. Ждать ещё 2-3 года, пока догоню ровесников? Это значило бы навсегда остаться в роли догоняющего. Поэтому я решил рискнуть — учиться на реальных задачах, а не готовиться к ним заранее. Кстати, в моей первой команде PO как-то даже принёс с конференции обложки для пропуска с этой же идеей: Хочешь — делай. Опыт приходит со временем. В первую очередь мне не хватало опыта проектирования. Поэтому я сразу же пошёл на курсы по архитектуре микросервисов. Слушал лекции, а вместо ДЗ применял всё это на проекте. Никто в команде, как и я, раньше не проектировал. Коллеги из смежных команд были заняты. А IT-лида у нас тогда не было. Поэтому не всё получилось с первого раза. Изначально при разработке MVP мы поделили систему на пару сервисов. Но позже поняли, что деление было ошибочным. Нам было сложно делать доработки в этой архитектуре. К тому моменту были проверены бизнес-гипотезы — часть из которых сработала, а другая нет. Мы учли проблемы первой версии архитектуры и спроектировали вторую. Получилось значительно лучше. Доработки стали проще. Было пройдено НТ, а система хорошо показала себя при масштабировании под возросший поток клиентов. Бизнес был доволен. Подход, при котором опыт приходит со временем, сработал. Мои компетенции в проектировании быстро выросли на реальных задачах. Я стал сначала техлидом нескольких команд, а после и IT-лидером стрима. Похожий кейс произошёл со мной год назад. В 2025 году мы начали внедрять AI в процесс обслуживания клиентов. Тогда в индустрии ещё не было устоявшихся подходов к проектированию и разработке AI-агентов и мультиагентных систем. Мы разработали MVP. Вначале агенты работали долго — иногда по 30 секунд. Пришлось делить большую задачу на части и добавлять параллельную обработку. Время ответа сразу сократилось до 7 секунд. Также мы решили разделить одного из агентов на 2 после получения от бизнеса новых требований. В итоге прошли НТ и успешно подготовили систему к тиражу. И знаете, что самое интересное? За все 8+ лет опыта в IT я никогда не встречал людей, которые были бы заранее готовы к новым вызовам в разработке и проектировании. Поэтому отбросьте в сторону сомнения и страхи. Не ждите, когда выйдут лучшие курсы или вы прочитаете все возможные книги. Пока другие ждут — просто берите и делайте. Успех в этом случае — вопрос времени. Главная компетенция сегодня — это уже не просто набор полученных заранее знаний и навыков, а умение решать новые для вас задачи. Разбираться в передовых технологиях на основе предыдущего опыта и применять их для решения реальных задач. А что бы вы посоветовали разработчику, который не решается проектировать в эпоху AI? Обо мне | Telegram | MAX

Порядок или хаос при внедрении AI Если на проекте нет системы, моя продуктивность падает, а когнитивная нагрузка взмывает вверх. С внедрением агентной разработки всё то же самое. Если перед этим не навести порядок на проекте, ИИ просто масштабирует хаос. При системном подходе наоборот — если дать достаточный контекст, разберется даже новичок. И чем сложнее проект, тем важнее для него системная работа. Я пришел к этому выводу ещё до перехода в IT, 10 лет назад, когда был руководителем сервиса в компании OTIS и отвечал за работу 3500 лифтов в Москве. Заказ запчастей, проведение сертификаций и проверок, отчетность перед госорганами и заключение договоров. Понемногу я начал тонуть в потоке вопросов. Взять ситуацию под контроль помогла книга Дэвида Аллена «Как привести дела в порядок». Я разложил всю работу на понятные процессы, структуры и иерархию задач. Хаос стал управляемым и превратился в систему. Карьера пошла в гору — я стал техническим директором. Видимо, страсть к систематизации у меня именно оттуда. При этом, как только я не вижу понятную логику и четкую структуру, моя картина мира начинает разваливаться на части, а продуктивность падает. В разработке это мешало мне делать задачи быстро. Пока другие брали в работу не проработанные фичи, я разбирался в требованиях и проектировал решение без костылей. В роли техлида это усложняло работу с бизнесом. Приходилось объяснять важность построения системы и детальной проработки фичей, чтобы продукт оставался надежным. Это верная стратегия вдолгую. При этом в глазах бизнеса ты проигрываешь коллегам, готовым на любые компромиссы ради скорости в моменте. Было время, когда я думал, что со мной что-то не так. Ведь проектов без системы реально много. Они живут в режиме стартапа годами, хотя это уже серьёзный Enterprise. Я даже пытался примерить на себя такой подход. Ну а что? Бизнес доволен, продукт приносит деньги. Половину времени чиним баги, зато быстро катим фичи. Но в итоге понял, что это тупик: Пока идет разработка, бизнес — это адвокат, который согласен тестировать прямо на ПРОДе. Но с первым же инцидентом бизнес — это прокурор, который никого не просил ускоряться в ущерб качеству. Единственный выход из тупика — быть честным с собой, командой и бизнесом. Принять, что создание и развитие надежных продуктов невозможно без системной работы. Гораздо проще строить эту работу на новых проектах с нуля. Поэтому я выбирал команды, где мог принести максимальную пользу через системную работу, а не через тушение пожаров. На проектах с историей в роли техлида я проводил большую работу с бизнесом, чтобы донести до коллег важность построения системной работы для развития продукта вдолгую. Этот подход обретает ещё большую актуальность сегодня, когда все активно смотрят в сторону агентной разработки. Важность наведения порядка перед внедрением AI подтверждается выводами рабочей сессии C-Level клуба Онтико, которые были представлены в ходе AgenticDevConf в июне 2026 года в Москве, цитирую: Процессы и принципы должны стать явными и описанными. Если внедрять ИИ поверх устных договоренностей, агент просто размножит существующий беспорядок. К этому выводу несколько команд пришли независимо друг от друга. Лидеры индустрии сходятся в главном. Системность мышления становится важнейшей компетенцией при переходе к Specification Driven Development. Именно этот навык во многом будет определять успех и востребованность IT-специалистов в эпоху AI. А как вы справляетесь с хаосом? Делитесь в комментариях. Обо мне | Telegram | MAX

(Не) качесвенный код агента Сегодня большинство в индустрии признаёт нежизнеспособность вайб-кодинга в Enterprise. Для прототипов — да, но для серьёзной разработки — точно нет. Тут практически консенсус. Но при этом идея сильно не погружаться в код никуда не исчезла. Признавайтесь, кто из вас устал от скорости, с которой меняются тренды вокруг? Поднимаю руку первым! За последние пару недель я прочёл о процессе AI-разработки столько, что мозг уже кипит. Но это так интересно, что остановиться порой невозможно. Мейнстрим сегодня — SDD, или Specification-Driven Development. Пишешь спецификацию о работе функционала. Получаешь одновременно и актуальное описание системы, и постановку на разработку для AI-агента. Запускаешь его в специальном окружении (harness) и получаешь результат. Концептуально — просто и логично. Также все сходятся во мнении, что код должен быть качественным. А вот дальше начинается самое интересное. Каждый вкладывает свой смысл в «качество кода» Нейтральная точка зрения такова: качественный код — соответствует спецификации. Формулировка обтекаемая, но с ней не поспоришь. При этом итоговый результат будет сильно зависеть от того, что именно положили в спеку. И вот об этом как раз две другие точки зрения — более конкретные и интересные. Первая предлагает не смотреть в код вообще. Суть такова: задаём бизнесовые и технические инварианты в спеке, а потом валидируем их через evals в цикле разработки методом чёрного ящика. Мотивация: Код живёт 2–3 коммита, потом переписывается агентом, поэтому неважно, как именно он написан. Паттерны типа SOLID были нужны людям, чтобы понимать код, который был единственным источником правды. Теперь есть спецификация, которая решает эту задачу, поэтому чистый код больше не актуален. Другие утверждают обратное. Кроме бизнесовых и технических инвариантов, важно явно указывать архитектурные ограничения на уровне кода до старта разработки. А после контролировать их выполнение gate-ами прямо в агентском цикле. Мотивация: Без явных ограничений агенты склонны к созданию монолитных архитектур. Они оптимизируют код под функциональную корректность, а не под архитектурные атрибуты качества. В результате — техдолг растёт по экспоненте, а человек уже не сможет помочь, если агент зайдёт в тупик. Почему важно решить, на чьей вы стороне При переходе к SDD мы не должны использовать агентов типа Claude Code / Open Code без инженерной обвязки (harness). Потому что именно он, а не модель, в итоге определяет качество результата. Не верите — посмотрите статью о том, что поведение Claude Code на 98,4% — это детерминированная инфраструктура, и только 1,6% приходится на логику принятия решений ИИ. В итоге именно те идеи, которые будут заложены в harness на этапе его проектирования, будут определять качество продукта, который создаст агент по спеке. Я считаю, что в основе эффективных решений в IT лежит умение декомпозировать задачи и делать сложное простым. А опыт взаимодействия с LLM показывает, что наилучший результат работы модели обеспечивается путём декомпозиции задач и структуризации данных, с которыми она работает. Поэтому для меня выбор очевиден. Бизнесовых и технических инвариантов при постановке задачи разработки AI-агенту недостаточно. Важно явно задавать архитектурные ограничения, а также контролировать цикломатическую сложность прямо внутри цикла разработки. А на какой вы стороне? 🤖 — если доверяете структуру кода агенту. 😃 — если задаете арх.требования к коду. Обо мне | Telegram | MAX

Привет! Меня зовут Александр Романов. Решил немного освежить информацию о себе. Я ИТ-лидер кластера в Сбере. Последние 8 лет проектирую распределённые системы, а сейчас — внедряю AI-агентов в production и разбираюсь, как сохранить контроль над архитектурой, когда код генерирует ИИ. Мой путь — это не линейный рост, а серия инженерных вызовов: • 2018-2020, Сбер: Начал с кредитного сервиса для малого бизнеса («СберБанк Бизнес Онлайн»), затем — проект «СберБизнесБот». Параллельно получил Oracle Certified Associate. • 2020-2022, Сбер: Стал техлидом команды биллинга «СберБизнесБот». Мы с нуля разработали распределённую систему тарификации и оплаты. • 2022-2024, Т-Банк и МТС Банк: Руководил кластерами из 2-3 команд, запускал новые платёжные инструменты (заправки через «Т-Бизнес», карту «МТС Деньги»). • 2024-2026, Сбер: Техлид команды, затем ИТ-лидер кластера. Сейчас занимаюсь внедрением AI-агентов в процесс обслуживания клиентов. За эти годы: • Проектировал микросервисную архитектуру и руководил кластерами из 40+ человек. • Проводил R&D и запускал MVP, обеспечивал тиражирование функционала. • Вырастил двух техлидов и трёх сеньоров исключительно на рабочих задачах. • Отсмотрел 1000+ резюме и провёл 100+ технических интервью с кандидатами. Этот канал для Middle+ / Senior Java-разработчиков, которые: • Чувствуют, что переросли текущую роль и хотят расти в Solution Architect. • Внедряют AI-агентов в production и не знают, как сохранить контроль над архитектурой. • Не хотят уходить в people-менеджмент, чтобы остаться востребованными. • Боятся, что их экспертиза обесценивается в эпоху AI. Буду писать о том, как: • Оставаться востребованными в эпоху развития AI. • Проектировать и внедрять AI-агентов в production. • Сохранить авторство над системой при агентной разработке. • Не потерять в надёжности и качестве при AI-разработке. А самое главное — всё это: • Без сухой теории, шаблонных примеров и необходимости знать всё. • Без понижения до роли оператора LLM и слепого доверия AI. • Без потери авторства и контроля над архитектурой и кодом. Telegram | MAX

Будущее уже наступило Привет! Я не писал в канал почти 9 месяцев. Кажется, что прошла целая вечность. А сколько событий за это время произошло в мире разработки! И это только начало. Помню, как ровно год назад мы с командой начали внедрять AI. Проектировали, писали код. Все как обычно. Тогда уже была IDE с умным автокомплитом. Но давайте честно — в этом не было новизны. Все было достаточно привычно. И казалось, так будет всегда. Примерно тогда же я узнал про Cursor. Одни восхищались, другие смотрели скептически. Но это был прорыв. Можно было легко сделать UI для бэкенда без единой строки кода. Да, местами он был сыроват. Но уже тогда у меня появились первые тревожные мысли. Ситуация явно выходила из привычных рамок. Ценность умения писать код пошатнулась. Тогда я первый раз подумал: А сколько нам ещё осталось работать? Год, три или хотя бы лет пять? Но понемногу хайп утих, и для меня тема отошла на второй план. Тем более в компании таких инструментов тогда не было. Мы продолжали писать код руками. Тогда мне удалось убедить себя, что это либо хайп, либо совсем далекое будущее. Тревожные мысли забылись. Фокус перешел на текущие задачи. Вернулась уверенность, что AI пока не готов заменить человека в разработке. Так было до февраля, когда Claude Code и другие CLI-агенты для разработки быстро стали набирать популярность. Некоторые коллеги прямо говорили мне, что мы чуть ли не динозавры. Ведь писать код руками — уже прошлый век. Убедить себя в обратном в этот раз было гораздо сложнее. Но квартальные цели не давали скучать. Я решил сконцентрироваться на работе. Команда продолжала интенсивно перформить, и я вместе с ней. К концу квартала мы сделали все, что планировали. Внедрили AI в процесс обслуживания и вышли в пилот на первые 14 офисов. Смешанные были чувства. Мир менялся, и отрицать это было бессмысленно. Поэтому именно успехи команды были важным противовесом окружающей неопределенности. Пилот прошел успешно, и спустя месяц был согласован план тиража на сотни отделений. Мы с командой приходили в офисы обслуживания, чтобы проверить функционал на себе и лучше понять клиентов. Я смотрел на продукт и чувствовал удовлетворение от качественно проделанной работы. В это же время PO одной из команд ставит себе дома Claude Code. И за вечер собирает рабочий прототип с UI. Моя первая реакция: Можно собирать чемоданы. Game over. Я бы не удивился, если бы это получилось у разработчика, потому что и сам уже так делал. А тут как будто разом обесценился весь инженерный опыт. Во всяком случае, на первый взгляд казалось именно так. Но одно дело прототип, а другое — production. Опыт подсказывал мне, что не все так просто. Мои эксперименты показали, что получить промышленный код от Claude/Qwen/Open Code не так уж и просто. Я стал искать способ, как создавать production-решения со скоростью разработки прототипа. И как раз в этот момент руководитель рассказал мне про AI-Disrupt PDLC. Там изложены основные концепции агентной разработки в эпоху AI. Пазл окончательно сложился на конференции Agentic Dev Conf 2026 в Москве, которую я посетил в прошлую пятницу. Там обсуждали AI в разработке, трансформацию процессов, перспективы рынка труда и компетенции будущего. Разработка не исчезнет. Наоборот, мы будем работать быстрее. Будет меньше рутины и больше по-настоящему инженерных задач. Это не только кризис, но и окно возможностей, которым нужно обязательно воспользоваться. Тема инженерная и очень интересная. Я сейчас много времени уделяю этому вопросу. Поэтому в канале буду рассказывать о своих экспериментах и инсайтах. Сейчас действительно прекрасное время — время прокачивать компетенции будущего. А вы как? Чувствуете тревогу из-за AI? Или уже нашли свой путь? Поделитесь в комментариях. Telegram | MAX

Порты и адаптеры в чистой архитектуре В прошлых постах я рассказывал, как реализовать уровни core и application в гексогональной архитектуре на примере микросервиса авторизации. Когда основная логика уже написана, остается дать возможность приложению взаимодействовать с внешним миром: 💡 Обрабатывать входящие запросы или сообщения. 💡 Вызывать другие системы и отправлять нотификации. 💡 Работать со различными базами данных. Для этого нужно написать код уровня инфраструктуры, основу которого составляют ingress и egress адаптеры. Входящий поток (ingress) Адаптерами здесь являются, например, REST-controllers и Kafka-listeners. Они решают 3 главных задачи: 💡 Проверка данных запроса и генерация ошибок валидации. 💡 Маппинг транспортных моделей в доменные и обратно. 💡 Вызов основной бизнес-логики приложения. Адаптеры на выходе из приложения решают те же задачи, но устроены чуть сложнее. Исходящий поток (egress) Для интеграции они используют клиентов к внешним системам. И в рамках одного метода адаптер может вызывать их несколько раз. Типичные кейсы: 💡 Получение данных одной модели несколькими REST-запросами. 💡 Сохранение данных одной модели вставкой в несколько таблиц. Таким образом, основное назначение адаптеров в чистой архитектуре - абстрагировать логику работы приложения от деталей внешних интеграций. Это, действительно, удобно. Только вот с ходу заходит не всем. Мне по началу тоже было не просто. Поэтому я решил собрать ответы на вопросы, которые у меня возникали в ходе погружения в тему: Вопрос: Как взаимодействуют между собой порты и адаптеры? Ответ: Входящие адаптеры вызывают ingress-порты application-слоя. Исходящие адаптеры имплементируют egress-порты application-слоя. Вопрос: Можно ли исходящие адапптеры делать по одному на каждую вызываемую систему? Ответ: Нет, каждый адаптер дает возможность работать только с одной доменной моделью. Корреляции с вызываемыми системами быть не должно. Вопрос: Как быть, если мне нужно вызывать один и тот же egress-адаптер из обоих слоев (core и application)? Ответ: Исходящий адапетер может имплементировать исходящие порты обоих слоев. Вопрос: Можно ли сохранять что-либо в БД не использую core-слой? Ответ: Нет, при изменении состояния базы нужно всегда проверять соблюдение бизнес инвариантов, а это ответственность ядра приложения. Ну и в завершение хочу отметить очень важный момент. Как только вы правильно разделите ответственность между компонентами системы, вы сразу же получите чистый код по всем Best practice "из коробки". Все сложится как пазл. Если у вас остались вопросы - пишите их в комментариях. Ставьте лайк, если планируете применить все это на своих проектах. TeamLead говорит | Александр Романов

Почему после 4 лет в разработке не получается вырасти выше миддла, начать получать больше, и что с этим делать На одном из проектов ко мне в команду перешел разработчик. Миддл по нижней границе. Сроки запуска проекта были сжатыми, поэтому выбирать не приходилось. Он работал не быстро и получал много замечаний на ПРках. Поэтому после запуска пилота я предложил ему сменить команду. Он понимал, что не тянет, и спросил совета: Начинал в аутсорсе, потом перешел в инхаус. Всего 4 года опыта. В предыдущей команде - полтора. Казалось, что я неплохо пишу код. Делал средние таски, но зарплата почти не росла. Перешел к вам и понял. Решать сложные задачи мне тяжело. Да и сменить команду тоже проблема. Прохожу интервью, но офферов почти нет. В итоге обычнол иду, куда позовут. И все по кругу. По человечески мне хотелось ему помочь. Но в команде не было возможности заниматься его развитием - на это нужно было слишком много времени. Поэтому я решил поделиться с ним опытом. Почему так происходит С подобными проблемами в начале карьеры сталкиваются многие. Сразу попасть в крупную компанию получается не у всех. Я и сам начинал с аутстафа. Это время, когда выбирать не приходится. При этом любой проект дает возможность получить опыт промышленной разработки. А оффер на руках - уже победа. На этом этапе может показаться, что меня всему научат. А для развития нужно просто делать рабочие задачи. Но это мало вероятно. Если очень повезет, то действительно получится прокачаться в процессе работы. Но тут многое зависит от культуры компании, лида команды и состояния проекта. По моему опыту таких команд 3 из 10. В остальных - компетенции разработчиков не растут в принципе. А иногда даже наоборот. Ведь с кем поведешься, от того и наберешься. Поэтому важно брать ситуацию в свои руки. Как выйти из тупика Решение действительно есть. Даже если за плечами уже N лет опыта на legacy проектах, зарплата не растет, а крутых офферов пока нет: 💡 В начале нужно прокачать знания и отработать их на практике. Язык программирования, фреймворки и все сопутствующие технологии. Чтобы легко в них ориентироваться, перестать искать ответы на простые вопросы в ChatGPT и начать производить уверенное впечатление на интервью. 💡 Дальше нужно познакомиться с Best practice индустрии в коде и архитектуре. Это позволит критически смотреть вокруг и начать сравнивать результаты своей работы и решения коллег с высокой планкой требований. Научиться делать не только быстро, но и качественно. 💡 Найти команду, в которой получится на практике применять и развивать все это. Команду, в которой вы сможете раскрыться. А не продолжать писать как-нибудь, потому что сроки горят и тут так принято. Ведь если придется плыть против течения, то ни о каком развии не может быть и речи. На это просто не останется сил. Пройти по этому плану нужно именно в таком порядке. Спокойно, последовательно и основательно. Именно это поможет начать решать по настоящему сложные сеньорные задачи и получать действительно высокую зарплату. А как вы развиваете свои компетенции и изучать Best practice? 🔥 - работаю с ментором, это наиболее эффективно. 😎 - хожу на курсы, не вижу смысла переплачивать. 👍 - изучаю самостоятельно, сейчас это проще простого. TeamLead говорит | Александр Романов

Как я готовился к аттестации для руководителей В сентябре я прошел асессмент для IT-лидов. Все лето хотел начать готовиться, но так и не собрался. А потом узнал, что сдача через неделю. И тут понеслось. Про систему уровней для ИТ-руководителей я знал давно. А в июне решил пройти асессмент на следующую ступень. Основная мотивация - попасть в пул кандидатов на рост. Само интервью строится вокруг кейсов из опыта соискателя: управленческого и архитектурного. Для подготовки есть матрица компетенций. Все темы из нее были мне известны. Я ни раз применял их на практике. Но идти без подготовки все же не хотел: 💡 Во-первых, не все это используется одинаково часто в работе. 💡 Во-вторых, на интервью нужно рассказывать, а не вспоминать. Но времени тогда на это не было. Плюс к лету я объективно устал. Поэтому решил сходить в отпуск, а потом подготовиться и сдать в сентябре. Наступил август и тут произошло то, чего я не ожидал. Асессмент проводит СТО трайба с календарем под завязку. Поэтому я заранее пришел к нему с вопросом о свободных слотах на сентябрь. Для тебя время найдем! И уже вечером мне пришла встреча на следующую неделю. Вот это поворот. До даты Х оставалось 8 дней. Ну хотя бы не завтра! План подготовки был таким: 💡 Для начала я посмотрел рекомендованную серию внутренних митапов того же CTO. Это помогло быстро освежить в памяти большую часть тем. 💡 После этого по каждому вопросу я кратко сформулировал ответ. Это помогло определить западающих вопросы и устранить найденные пробелы. 💡 Оставалось только определить кейсы по архитектуре и менеджменту, которые буду рассказывать. В день асессмента я буквально засыпал. Неделя подготовки по вечерам и ночью дала о себе знать. Я рисковал затупить на элементарных вопросах. Спасти меня могло только чудо. И оно произошло. За 30 минут до встречи руководитель перенес асессмент на неделю вперед. У меня появилась возможность выспаться и восстановить ресурс. Чем я и воспользовался. Через неделю встреча состоялась. Я рассказал про архитектуру биллинга, которую проектировал в Сбере. И о том, как запускал стрим из нескольких команд в Тиньке. Мы обсудили кейсы. Я ответил на несколько вопросов. Ну и, конечно, волновался каким будет итоговый результат. Поэтому было приятно услышать, что асессмент пройден и следующий уровень подтвержден. На данном примере я ещё раз убедился. Нужно всегда идти вперед навстречу возможностям. Соглашаться, даже если кажется, что сейчас не удобно и лучше потом. Иначе идеальный момент может просто не наступить. А что вы делаете, когда хочется отложить важные вопросы на потом? Если вас тоже мотивирует, когда обратного пути нет, ставьте ❤️ TeamLead говорит | Александр Романов

Что должно быть реализовано в application слое гексогональной архитектуры В прошлый раз я рассказал, как спроектировать ядро микросервиса авторизации на принципах чистой архитектуры. Теперь поднимемся на один уровень абстракции для реализации логики application слоя. Спроектируем сервисы по работе с пользователями и сессиями. Методы каждого из них реализуют внешним API нашего микросервиса: 💡 Регистрация по логину и паролю. 💡 Создание сессии по логину и паролю. 💡 Получение данных сессии по токену. class UserIngAppService implements UserIngAppPort { UserIngCorePort userIngCorePort; @Override public void saveUser (String login, String password) { // Логика взаимодействий... } } class SessionIngAppService implements SessionIngAppPort { SessionEgrAppPort sessionEgrAppPort; SessionIngCorePort sessionIngCorePort; @Override public SessionModel saveSession (String login, String password) { // Логика взаимодействий... } @Override public SessionModel getSession (UUID authToken) { // Логика взаимодействий... } } Каждый метод представляет собой сиквенс взаимодействий микросервиса с ядром или внешним миром: 💡 Для действий с проверкой бизнес-инвариантов вызываются ingress-порты core-слоя. 💡 В остальных случаях происходит обращение к egress портам уровня приложения. Ingress порты ядра мы разбирали в прошлый раз. А egress порты application слоя - это его возможность взаимодействовать с внешними системами: 💡 Вызывать API другого сервиса. 💡 Получать данные из хранилища. 💡 Отправлять сообщения в брокер. В нашем микросервисе авторизации egress порт уровня приложения всего один. Он позволяет получить данные сессии по токену авторизации: interface SessionEgrAppPort { Optional<SessionModel> getSessionByAuthToken (UUID authToken); } Важно, чтобы сигнатуры всех методов в интерфейсах и классах application слоя содержали только простые типы (строки, числа и т.п.) либо core-модели. И тут может возникнуть вопрос: А почему нельзя использовать на уроне приложения DTO-шки из RestController-а или KafkaConsumer-а и Entities базы данных? Дело вот в чем. Эти ограничения позволяют отделить логику приложения от деталей реализации конкретной интеграции или базы данных: 💡 Если к коде в application слоя есть DTO, то при изменении контракта придется дорабатывать не только логику интеграции, но и код уровня приложения. 💡 Когда код приложения использует Entities базы данных, то это усложнит переход на чистый JDBC из-за необходимости изменений в application слое. Все это приведет к багам, которые не отловить unit-тестами. Ведь их тоже придется переписывать. Чистая архитектура, напротив, лишена подобных проблем! Уровень приложения не зависит от инфраструктурного. В результате доработки происходят быстрее и с меньшим количеством багов. Как вам концепция? Комментируем, лайкаем, задаем вопросы. TeamLead говорит | Александр Романов

Как за одну неделю дать интервью и пройти асессмент Прошедшая неделя была для меня насыщенной и напряженной. В понедельник в качестве спикера я участвовал в прямом эфире на канале Эмоции успеха | Елена Логачева. Мы обсудили, как тимлмдам проводить сложные разговоры с командой и коллегами, без которых не обходится работа любого руководителя. Это бы мой первый опыт в качестве приглашенного эксперта. И мне однозначно понравилось! Кстати, запись трансляции уже доступна к просмотру: 😉 СМОТРЕТЬ ЗАПИСЬ НА YOUTUBE Но это ещё не всё! Вчера я прошел асессмент на следующую ступень для руководителей ИТ-вертикали, к которому готовился почти всю прошлую неделю. Подобный процесс есть практически во всех крупных компаниях. А результат его прохождения напрямую влияет на возможность дальнейшего роста по грейдам и зарплате. Как к этому готовиться, и что в реальности ждет на интервью - это отдельная история, которая тянет на целый пост. Ставьте лайки 👍. Так я пойму, что вам интересно узнать подробности и мои лайфхаки для успешного прохождения. TeamLead говорит | Александр Романов

Как мы с сыном исследовали офис Сбера на Дне открытых дверей На 39 этаже Сбера открывается шикарный вид на Поклонную гору, Москва-сити и Воровьевы горы. Там расположена зона коворкинга. Удивительно, что я узнал об этом только на прошлой неделе. Когда проводил сыну экскурсию по офису. О том, что Сбер проводит дни открытых дверей для детей сотрудников, я узнал в 2019 году. Группы ребят толпились на входе и с интересом исследовали офис. Круто! - подумал я. Но тогда для меня как сотрудника подрядчика эта опция была не доступна. Когда через год я уже работал в Сбере, подобные мероприятия по понятным причинам не проводились. Тогда в самом разгаре была пандемия. Пришлось ждать ещё 2 года. И когда в 2022 ограничения наконец-то сняли, я подумал: Ну теперь наконец-то получится. Но не тут то было. Осенью того же года я сменил место работы и перешел из Сбера. Поэтому экскурсия по офису была отложена на неопределенный срок. Прошло несколько лет. Сын за это время подрос, а я снова работаю в Сбере. Поэтому когда мне пришла рассылка о старте регистрации на День открытых дверей, я был действительно рад. Мероприятие прошло на прошлой неделе и длилось целых 3 дня. Все было организовано очень интересно и познавательно. Сын был в полном восторге. Еще бы. Целый день с папой на работе. Экскурсия, разные тематические активности. Ну и возможность пройти в любое из 4х зданий Сбера на Кутузовском проспекте. И знаете, что самое удивительное? Я тоже открыл для себя новые локации. В той же башне, где сам работаю 5 дней в неделю уже почти целый год. Вот ведь как бывает. Мы часто движемся привычным маршрутом и совсем не смотрим вокруг. А в результате можем пропустить что-то действительно интересное и важное. Не очевидное на первый взгляд. Получается, что именно открытый и пытливый взгляд на мир вокруг - это ключ к росту. Личному и профессиональному. Расширяющий границы возможного. А как вы думаете? Если ловили себя на подобных открытиях, ставьте 👍 TeamLead говорит | Александр Романов

Как спроектировать ядро микросервиса на принципах чистой архитектуры В прошлом посте я рассказывал, как гексогональная архитектура помогает разработчикам перестать страдать на проектах. А сегодня покажу, как применить эту концепцию на примере микросервиса авторизации. Для начала важно вспомнить: Чистая архитектура подобна "луковице". Внешний слой - инфраструктурный. Следующий - уровень приложения. Ну и в самом центре расположено ядро. Внешние уровни зависят от внутренних. Именно поэтому в первую очередь спроектируем core-слой. Все начинается с доменных моделей Это сущности, которые определяют идентичность микросервиса и его основную задачу. В нашем случае - работу с пользователями и их сессиями: class UserModel { UUID id; String login; String passwordHash; LocalDateTime createDateTime; } class SessionModel { UUID id; UUID authToken; UUID userId; LocalDateTime startDateTime; } Поля моделей - это бизнес значимые признаки сущностей. Поэтому очень важно не пытаться повторить структуру БД или json-ки запросов/ответов один к одному. Переходим к бизнес-ограничениям Это правила и инварианты предметной области, которые должны соблюдаться всегда. Их главная задача в обеспечении целостности и стабильности бизнес-моделей и процессов. Какие требования настолько важны, что без них работа системы не имеет смысла? Например, для микросервиса авторизации критически важно: 💡 Гарантировать возможность создания только одного пользователя с одним логином. 💡 Гарантировать возможность входа пользователя только с валидной парой «логин-пароль». Для выполнения этих ограничений необходимо создать сервисы доменного уровня и реализовать в них эту логику: class UserCoreService implements UserIngCorePort { UserEgrCorePort userEgrCorePort; CoreModelFactory coreModelFactory; BCryptPasswordEncoder passwordEncoder; @Override public void saveUser( String login, String password) { // Реализация бизнес-правил... } } class SessionCoreService implements SessionIngCorePort { UserEgrCorePort userEgrCorePort; SessionEgrCorePort sessionEgrCorePort; BCryptPasswordEncoder passwordEncoder; CoreModelFactory coreModelFactory; @Override public SessionModel saveSession( String login, String password) { // Реализация бизнес-правил... } } Каждый сервис имплементирует входные (ingress) интерфейсы core-слоя. С их помощью абстракции уровня приложения смогу вызывать функционал ядра. Реализуем вызовы из ядра во внешние слои В нашем случае это нужно для поиска и сохранения пользователя, а также сохранения сессии в БД. Для этого достаточно определить исходящие (egress) интерфейсы ядра UserEgrCorePort и SessionEgrCorePort и реализовать их на верхних уровнях системы. Также в рамках доменного слоя стоит разместить перечисления (enums), исключения (exceptions) и фабрики моделей (factories). Вот и все, первый этап завершен. Мы спроектировали корневой слой микросервиса в чистой архитектуре. В результате получили заметный буст: 💡Ключевая логика сервиса выделана в ядро, которое меняется достаточно редко. 💡Методы core-сервисов небольшие, поэтому их просто покрыть юнит-тестами. 💡В итоге будет меньше критичных багов, а скорость разработки возрастет. А в следующих постах я рассажу про реализацию application и infrastructure уровней чистой архитектуры. Если пост помог лучше разобраться в теме - ставьте ❤️. Если остались вопросы - welcome в комментарии! TeamLead говорит | Александр Романов

Как писать сервисы с нуля, чтобы потом было просто развивать их Многие разработчики ежедневно страдают на проектах. Когда код - сплошные портянки на сотни строк. Разбираться во всем этом - боль. Я сам проходил через. Ну и конечно, все мечтают о проектах с нуля: Вот тогда мы бы сразу написали все как надо! Но когда эта возможность появляется, оказывается, что не так-то это и просто - сделать правильно. Думаю, вся проблема вот в чем. Когда вокруг только одни контроллеры, сервисы и репозитории, сложно начать мыслить иначе. По началу я тоже пытался выстроить что-то стройное в рамках привычной трехслойной архитектуры. Но быстро понял, что даже для логики средней сложности это тупик. И дело не в том, как разложить код по классам. Вопрос гораздо глубже. Пока не поменяешь образ мышления, ничего не получится. Все ведь как привыкли? Приложение - это только прослойка к БД. Просто CRUD и не более того. В этом и кроется корень проблемы. А что если я вам скажу, что это большое заблуждение и можно писать код иначе? Быть продуктивнее и перестать страдать. Решение проблемы - чистая архитектура. Это не просто ещё один способ скомпоновать код. Это качественно иной взгляд на работу отдельного микросервиса. Крупными мазками идея в следующем: 💡 Сначала нужно определить доменные модели/сущности, с которыми работает сервис. 💡 Затем разделить всю логику на внешние интеграции, бизнес-ограничения и прикладной код. 💡 Далее обеспечить назависимость последующих (внутренних) уровней от предыдущих (внешних). 💡 В результате получаем прозрачную структуру и компактный код, который также легко покрыть тестами. И тут может возникнуть вопрос: Раз все так классно и удобно, почему его не используют повсеместно? Многих останавливает высокий порог вхождения. Плюс к этому почти нет примеров реализации e2e сложных проектов. Только базовые кейсы. Чтобы вывести рабочую формулу этого подхода, я перепробовал несколько вариантов реализации. На это ушло около года. Да и понять саму философию подхода было не просто. Но оно того стоило. Теперь написание сервисов любой сложности не представляет особых проблем. Проверено на реальных проектах. Поэтому очень рекомендую погрузиться в эту тему глубже и начать применять на практике! Если хотите знать, как практически реализовать все это в коде - дайте знать огнем. 🔥 TeamLead говорит | Александр Романов

Как я набрал курсов с ограничением по времени доступа, сроки почти вышли, и что теперь с этим делать Качать скилы сегодня просто как никогда. Нравятся курсы? Можно выбрать онлайн или в записи. Читаешь книги? Есть в оригинале и на русском, в бумаге или планшете. Бери и изучай. Это меня и подкупило. Теперь думаю, как не надорваться в попытке научиться всему и сразу. Повторять за мной не рекомендуется) С момента перехода в IT 8 лет назад я использовал такую схему. В начале проходил онлайн-курсы, где быстро учился основам и решению задач средней сложности. Затем набирался реального опыта на работе. А после читал книги для углубления знаний. Первые курсы я изучал строго один за другим. Учился онлайн вместе с группой. Со временем поддерживать такой темп стало сложнее. Поэтому я перешел к просмотру занятий в записи. На качество это влияло незначительно. Сказывался опыт в смежных областях. А бессрочный доступ к материалам позволял не торопиться. Я спокойно осваивал темы с комфортной скоростью. Курсы обычно стоят 80-150 тыс.рублей. Чтобы оптимизировать затраты я применял разные схемы. Либо использовал преподавательский бонус в 50%, либо оплачивал обучение в сезон скидок. Пару лет назад мне нужно было расширить свои знания в DevOps. Поэтому в ноябре 2023 года я решил не упускать выгодное предложение и купил сразу Gitlab CI/CD, Kubernates для админов и несколько подготовительных курсов. Особенность площадки была такова. Доступ к записи выдавался только на 2 года. Не прошел - твои проблемы. Это меня не смущало. Я был уверен, что за это время точно управлюсь. По факту оказалось, что возможностей заниматься у меня было не так много. Все, что я успел за более чем 1,5 года - завершил один подготовительный курс и прошел процентов 60 Gitlab. Сейчас до закрытия доступа у меня есть ещё 3 месяца. За это время нужно завершить CI/CD, а еще полностью пройти K8s и пару подготовительных курсов к нему. Видимо придется меньше спать. Иначе успеть, скорее всего, не получится. Но сдаваться сразу я точно не планирую! Чтобы не повторять своих ошибок в будущем, я отрефлексировал ситуацию и сделал следующие выводы. Я наивно полагал, что ограничение по времени будет мотивировать меня к прохождению. Не учел возможность появления непредвиденных обстоятельств. Повелся на маркетинг и большие скидки. Теперь понимаю, что гораздо эффективнее не распылять свое внимание, а фокусироваться на одном направлении (курс или книга). Не переоценивать свои силы. Покупать только то, что будешь изучать сразу. Не откладывать на будущее. Это позволит сберечь нервы и силы. Поможет сэкономить деньги. Сделает обучение эффективным и комфортным. Ну а пока я пытаюсь уложиться в дедлайн, буду периодически рассказывать здесь об этом. Поддержите меня лайками и расскажите, как ограничиваете себя, когда хочется всего и сразу? TeamLead говорит | Александр Романов

Как использовать AI в разработке, и чего от него пока ждать не стоит Когда мне впервые рассказали про среду разработки Cursor с GenAI под капотом для вайб-кодинга, сначала я просто не поверил. С текстом все понятно и уже привычно. А вот написание кода искусственным интеллектом на первый взгляд казался фантастикой. Я стал разбираться. В сети одни утверждали, что вайб-кодинг - кратно ускоряет разработку без потери качества. Другие напротив считали его не применимым в сложных проектах на PROD. На получение рабочего кода с его помощью действительно требуется меньше времени. Буквально несколько часов, а не дней. Даже в незнакомом проекте или на новом языке. Например, по моему запросу Cursor написал простой фронт на React и бэкенд на Java к нему минут за 10. За качество разработки фронта не скажу, а вот на бэке пришлось вносить правки. В другой раз мне потребовалось переписать небольшой сервис с Python на Java. Я не хотел разбираться в питоне и снова зарядил Cursor. Правда, для получения приемлемого результата пришлось декомпозировать задачу. Сначала - определение логики работы исходного сервиса, а потом реализация ее на Java. При этом код под авторством AI снова был далек от production-ready. Внесение изменений потребовало несколько часов. Еще одно применение Cursor - отладка и фиксы. Например, можно решить проблему со сборкой или починить баг в работе приложения. GenAI сам предложит, куда добавить логи, проанализирует их и внесет нужные правки. Таким способом мне удалось отладить приложение на React, хотя я ранее ни разу не писал фронтовой код. Это было действительно удобно. А вот на фиксах бэкенда Cursor два раза уходил в бесконечный цикл правок. Предлагал несколько решений по очереди, и ни одно из них не работало. В итоге пришлось править руками самому. В ходе вайб-кодинга у меня возникло ощущение взаимодействия с шустрым джуном. Говорю, что нужно - он делает. Но не более. Все нужно контролировать и объяснять. Вместе с этим я почувствовал, что мне стало лень самому разбираться с проблемами. А когда это всё-таки приходилось делать, я ощущал дискомфорт и немного тормозил. И это не удивительно. Согласно некоторых исследований критическое мышление и когнитивные способности человека снижаются при использовании искусственного интеллекта. В итоге получается, что на данный момент подобные инструменты лучше использовать именно для выполнения рутинных задач. Это повысит скорость разработки. А вот полностью возлагать ответственность на GenAI за написание оптимального кода и решение проблем не стоит. Для проекта это может привести к потере ментальной модели системы разработчиками, снижению качества и надежности. Для самих инженеров - к деградации компетенций за счет снижения практики решения сложных задач. Сейчас в первую очередь стоит рассматривать искусственный интеллект как удобный способ конвертировать мысли разработчика в код. А рождаться они должны все-таки в голове человека. 🤖 - если доверишь AI продакшн. 😎 - если используешь AI для рутины. На чьей вы стороне в этом вопросе?

Как я организовал серию онлайн-митапов с младенцем на руках В начале апреля я стал многодетным папулей - у меня родилась дочка (уже было 2 сына)! А уже спустя пару недель перед майскими праздниками я провел серию онлайн-митапов Digital Dialog «Карьерный трек» с крутыми экспертами. Задача была не из легких! Мы по очереди качали малышку, а в перерывах готовились к эфирам. Жена делала дизайн, а я составлял вопросы для интервью с экспертами. Идея рассказать о карьерном росте в IT появилась у меня в прошлом году. Но тогда на это почти не было времени. Я готовился к собеседованиям, осенью перешел в Сбер и до конца года проходил испытательный срок. Единственное, что я успел - провел 27 декабря трансляцию в Telegram про найм в IT и получил много классных отзывов. Было видно, что тем зашла. А вот картинка и звук были так себе. Поэтому я решил обзавестись веб-камерой и студийным микрофоном. Мне настолько понравился формат прямой трансляции, что после январских праздников я решил организовать серию онлайн-митапов о карьерном росте. Для этого я пригласил несколько экспертов в IT, на каналы которых был подписан. Изначально шансы на согласие я оценивал 50/50. Поэтому был очень рад, когда ребята подержали идею поучаствовать и поделиться опытом. В начале марта мы обсудили темы, распределились и стали готовить материалы. Изначально планировали провести раньше, но в итоге договорились на конец апреля. В это же время мы активно занимались подготовкой к появлению нового члена семьи. Нужно было выбрать роддом и заключить контракт, подобрать коляску и много чего ещё. Так прошел ещё месяц. В итоге, когда мы счастливые и довольные вернулись домой из роддома с малышкой, на подготовку к эфирам оставалось около двух недель. И тут началась реальная жара. Нужно было сделать дизайн и тексты анонсов каждого эфира, скомпоновать визуал трансляции и настроить оборудование, провести тестовые прогоны с ребятами. В итоге мы все успели. Как? Сам удивляюсь до сих пор. Оставалось провести сами эфиры. Не буду лукавить - я волновался. До этого я ни разу не вел подкасты - был только в роли спикера. Зато я отлично ориентировался в теме каждого митапа и мог рассказать ни одну историю из опыта. Формула «Хочешь - делай. Опыт приходит со временем» в очередной раз меня не подвела. Я рад, что все получилось. Положительные отзывы после трансляции от экспертов и зрителей лучшее тому подтверждение. Вместе с этим работа в таком режиме не могла пройти бесследно. Попытка сделать все и сразу привела к выгоранию. Именно поэтому я решил отдохнуть и временно не писал посты в канал. И вот теперь после перезагрузки я снова с вами! Многие после эфиров спрашивали, будет ли запись. Поэтому сегодня я ещё раз делюсь ссылками на все 5 эфиров. Приятного просмотра! Тема: «Как договориться о повышении зарплаты» Смотреть 😉 YOUTUBE /🥰 RUTUBE Тема: «Как вырасти из исполнителя в тимлида» Смотреть 😉 YOUTUBE /🥰 RUTUBE Тема: «Как тимлиду найти работу» Смотреть 😉 YOUTUBE /🥰 RUTUBE Тема: «Как пройти HT-отбор в IT» Смотреть 😉 YOUTUBE /🥰 RUTUBE Тема: «Как пройти интервью с руководителем» Смотреть 😉 YOUTUBE /🥰 RUTUBE А что у вас произошло за это время? TeamLead говорит | Александр Романов

Ох уж эти метрики 🤦‍♂️ Менеджмент сегодня в значительной степени очарован возможностью оцифровать работу команд разработки. И действительно, собрав информацию только лишь из трекера задач и репозитория с кодом, можно узнать многое о работе команды, например: 👉 Время выпуска задач от взятия в работу до внедрения (Lead Time). 👉 Время выпуска фичей от идеи до клиента (Time To Market). 👉 Количество выпущенных задач за период (Throughput). 👉 Количество коммитов в репозиторий проекта за период (Commit Rate). И вот когда метрики собраны и визуализированы на графиках и дашбордах начинается самое интересное — нужно определить, как использовать эти данные. ☝️ Зачастую единственным вариантом применения этой информации, оказывается система поощрений и наказаний: поощряем за достижение KPI и наказываем на невыполнение. Вот именно такой подход и заводит ситуацию в тупик: ❗️ Как только метрики начинают влиять на уровень премий, процент повышения или другие схожие решения, то это неизбежно приводит к «подкручиванию» этих метрик под целевой уровень. ❗️ Менеджмент же в свою очередь теряет инструмент, который позволяет отслеживать реальное положение дел на местах, что по сути обесценивает процесс сбора и анализа метрик. В итоге команды продолжают работать так, как работали, а менеджмент ошибочно считает, что все хорошо, потому что метрики в порядке. Вывод Единственное для чего действительно стоит использовать метрики разработки, так это для принятия обоснованных управленческих решений по внесению изменений в процессы разработки и оценки эффективности этих изменений. В этом случае с одной стороны пропадает смысл «подкручивать» метрики, а с другой картина по метрикам всегда остается актуальной! А как применяют метрики у вас? TeamLead говорит | Александр Романов

DIGITAL DIALOG | Карьерный трек Друзья, мы рады приветствовать вас на серии онлайн-митапов о карьерном росте! Хотите знать, как на самом деле растут зарплаты, должности и карьера в IT? Мы собрали экспертов, которые принимают решения о найме и повышениях - они поделятся инсайтами, которые редко услышишь в офисных коридорах. Без воды, только практика: личный опыт, разбор ошибок и готовые сценарии действий 🚀 Когда: 22 - 29 апреля в 19:00 по МСК Где: Онлайн-трансляции в Telegram Цена: Абсолютно бесплатно! Вас ждут: 👉 Реальные кейсы от экспертов, которые знают систему изнутри. 👉 Живые ответы на ваши вопросы — ловите лайфхаки «из первых рук». 👉 Полезные материалы от спикеров. Наши спикеры и темы: 1️⃣ 22 апреля (вторник) Тема: «КАК ДОГОВОРИТЬСЯ О ПОВЫШЕНИИ ЗАРПЛАТЫ» Спикер: Женя Янченко — руководитель разработки в М.Видео и автор одноимённого канала Женя Янченко расскажет, как повысить зарплату внутри компании и какие ошибки мешают это сделать. 2️⃣ 23 апреля (среда) Тема: «КАК ВЫРАСТИ ИЗ ИСПОЛНИТЕЛЯ В ТИМЛИДА» Спикер: Артем Харченков — лид разработки в CTSG и автор канала Артем Харченков | IT Инсайты расскажет о тонкостях перехода в тимлиды и первых шагах в новой должности. 3️⃣ 24 апреля (четверг) Тема: «КАК ТИМЛИДУ НАЙТИ РАБОТУ» Спикер: Никита Ульшин — тимлид в Т-Банк и автор канала Никита Ульшин про IT расскажет, когда тимлиду пора искать новую работу и как правильно это делать. 4️⃣ 28 апреля (понедельник) Тема: «КАК ПРОЙТИ HR-ОТБОР В IT» Спикер: Любовь Герасимова — HR в Сбере и автор канала Герасимова Любовь | Рекрутер | IT | HR научит проходить скрининг так, чтобы вас «точно» позвали на интервью. 5️⃣ 29 апреля (вторник) Тема: «КАК ПРОЙТИ ИНТЕРВЬЮ С РУКОВОДИТЕЛЕМ» Спикер: Александр Романов — ИТ-лидер в Сбере и автор канала TeamLead говорит расскажет, что действительно важно для руководителей при найме. Как принять участие: Подписывайтесь на канал. Здесь мы будем публиковать анонсы, проводить мощнейшие трансляции и общаться со спикерами, чтобы не пропустить тонны полезных фишек, тонкостей, примеров из жизни, секретов и особенностей найма в IT от наших спикеров. 🔥 Это не «еще один вебинар» — это разговор с теми, кто решает! Приходите, если хотите карьеру, а не просто работу. DIGITAL DIALOG