Посты канала Никита Ульшин про IT

В разработке есть простое правило: если процесс завязан на одного человека или одну команду, рано или поздно он упрётся в потолок масштабирования. С похожей проблемой, только на уровне всей компании, столкнулся крупный телеком-оператор. 90% корпоративных онлайн-мероприятий требовали сопровождения команды поддержки, а нагрузка доходила до 600 параллельных конференций. Платформу для коммуникаций выбирали по 70+ критериям: стабильность под нагрузкой, совместимость с корпоративной инфраструктурой, требования безопасности, понятность для конечного пользователя. Выбор пал на Контур.Толк, и вместе с инструментом поменялась сама архитектура процесса организации встреч: ➡️Часть сотрудников получила права самостоятельно планировать и запускать мероприятия без обязательного участия команды поддержки - по сути, убрали единую точку, через которую проходил весь поток ➡️Гибридные встречи: сотрудники приходят в переговорку и просто сканируют QR-код для запуска конференции. ➡️Саммаризация созвонов стала у ассистентов «инструментом №1». Теперь 19 000 сотрудников пользуются Толком ежедневно. В пике одновременно проходят 600+ конференций на 3 500 человек. От себя добавлю, что я активно пользовался Толком на одном из своих мест работы и остался им крайне доволен. 📎Как выбирали платформу и снижали зависимость от команды поддержки — в кейсе на сайте Контур.Толка

Зарабатывать деньги мне понравилось раньше, чем писать код В своём блоге я много рассказываю про IT и управление разработкой, немножко меньше про философию и свои взгляды на жизнь, совсем чуть-чуть про спорт (а зря, там много всего). Но есть одна сторона моей жизни, которая всё время остаётся за кадром. Имя ей — предпринимательство. Свои первые деньги я заработал где-то в 8 лет, когда летом помогал маме продавать всякие часы и батарейки на рынке в Люберцах. И знаете что? Мне понравилось. Когда я нашёл первую работу программистом, желание делать что-то своё и зарабатывать на этом деньги никуда не делось. Параллельно с работой в моей жизни всегда что-то происходило: ➡️ запуск со старшим товарищем своей CRM (failed); ➡️ запуск своего проекта по коммуникациям с клиентами в нельзяграме (были пользователи, но прикрыл из-за рисков бана); ➡️ «привезти партию китайской херни и сбыть её на Авито» вместе с тогда ещё будущей женой (с переменным успехом); ➡️ и многое другое (если интересны мои байки — дайте знать в комментариях). Все мои пет-проекты всегда были связаны с предпринимательством и зарабатыванием денег. Для меня пет-проект, который не преследует цель заработать деньги, — это хобби (что тоже хорошо, но немножко другое). Я ощутил вкус предпринимательского азарта ещё в детстве, и с тех пор он меня не отпускал ни на день. Эта часть моей жизни продолжается и сейчас. У меня есть несколько проектов, которые приносят деньги, причём большинство из них я делаю совместно с женой. И я понял, что хочу об этом рассказывать в блоге: вспоминать прошлые затеи, успехи и факапы. Также я хочу вести своего рода лайфстрим текущих проектов (что пробуем, какие решения принимаем и что получается по деньгам). В следующем посте расскажу о проекте, который мы развиваем последние пару месяцев. С цифрами и фактами. // Что вам интереснее про такие проекты: откуда берутся идеи, как находятся покупатели или сколько в итоге остаётся денег?

Энни Мерфи Пол, «Мыслить нестандартно. Практичная книга о том, как маленькие изменения в привычках приводят к большим прорывам и открытиям» В процессе написания своих эссе про работу с трансформирующими идеями я задумался: что может помочь мне лучше «переваривать» полученный опыт (кроме написания заметок и эссе)? На этот вопрос мой агент-ресёрчер порекомендовал мне прочитать книгу Энни Мерфи Пол «Мыслить нестандартно». ⭐️ О чём книга Книга рассказывает о том, как включать в процесс мышления внешние ресурсы: чувства, движения тела, окружающее пространство и так далее. Автор приводит исследования и делится опытом людей, которые применяли описанные в книге техники, и даёт идеи того, как внедрить описанное в свою жизнь. О том, как изменение окружения влияет на моё внимание, я уже писал на примере эксперимента со смартфоном. ⭐️ Три идеи, которые я забрал себе 🟡Определённый уровень физической нагрузки стимулирует мышление, но его превышение даёт обратный эффект. Тут интересен пример Канемана, который заметил, что при спокойной прогулке пешком ему хорошо думается, но при ускорении он не может думать ни о чём, помимо ходьбы. Монтень сетовал, что лучшие идеи приходили к нему во время движения, когда их было не на чем записать. 🟡Если мысль переполняет ум — её нужно выгрузить во внешний мир. Я это делаю с помощью заметок, но есть много альтернативных способов: диаграммы, майнд-карты, рисование, лепка. Подойдёт любой способ, который нравится лично вам. 🟡Подражание другим — это практика заимствования лучшего у мастеров, а не плод лености. Греческие и римские мыслители считали подражание самостоятельным искусством, которое следовало активно использовать. Я так часто копирую практики более опытных партнёров по боксёрскому залу :) ⭐️ Мои впечатления С одной стороны, книга — вода водой. Автор по несколько раз пересказывает простые и очевидные тезисы на разных примерах, приводя то исследования, то чей-то «вдохновляющий опыт», то своё мнение. При этом сами идеи можно достать из названий глав. При этом я не могу сказать, что книга откровенно плохая. В ней много хороших мыслей и практик. Некоторые из них я уже использую — например, заметки и подражание более опытным людям. Если хотите немножко лучше думать и приятнее себя чувствовать — рекомендую выборочно прочитать заинтересовавшие главы. Тратить время на всю книгу не вижу смысла. Все мои обзоры книг доступны по тегу #обзор_книги и в этом посте. ➡ А для тех, кто хочет читать с большей пользой, у меня есть практикум «ИнфоСушка», в котором мы полностью меняем подход к чтению и делаем его эффективным. ➖➖➖➖➖➖➖➖➖➖➖ 📝 @ulshinblog

🎯 10 готовых решений для повышения эффективности команды В 2026 году бизнес фокусируется не на том, чтобы удержать любой ценой, а на том, чтобы сотрудники работали эффективнее.  Яндекс Практикум собрал лучшие рекомендации из исследований Gallup, SHRM, ВЭФ и кейсов Т-Банка, «Магнита», Skyeng и Netflix — и упаковал в один гайд. Внутри вы найдёте: ✅ Пошаговые планы — что делать завтра, на следующей неделе, через месяц ✅ Лучшие инструменты для развития, мотивации и удержания. ✅ Советы по внедрению ИИ, созданию безопасной среды и наведению порядка в процессах ✅ Готовые формулировки, чтобы изменения принимали без сопротивления Забирайте гайд бесплатно👇 Реклама, ООО Яндекс, ИНН 7736207543, erid: 2VtzqxZTjGh

Несколько часов подготовки ради 15-минутного разговора — Хорошо, Леша, что ты заговорил. Скажи, а можно я у тебя в программе больше не буду слышать двух слов — «мудак» и «херня»? — Нельзя. Слушай, если в эфир звонит полный мудак и несет такую херню — ты придираешься ко мне! «День радио» Иногда хочется сказать коллеге примерно то же самое. Но насколько это продуктивно? На одной из прошлых работ мне в какой-то момент хотелось прямо сказать продакту, что его требования — говно и нам постоянно за ним всё переделывать приходится. Но сильное раздражение (как в этом примере) не даёт конкретного описания, что человек сделал. Мне помогает подготовка обратной связи по BOFF: она заставляет разобраться, что именно человек сделал и к чему это привело. Расшифровывается она так: ➡️ B — Behavior (Поведение). Описание конкретного факта или действия без эмоций и общих оценок. ➡️ O — Outcome (Результат). Описание реальных последствий этого поведения для работы или команды. ➡️ F — Feelings (Чувства). Выражение своих эмоций от ситуации от первого лица. ➡️ F — Future (Будущее). Совместный поиск решения и договорённость о дальнейших действиях. Необходимость описать наблюдаемое поведение помогает мне рационально разобраться, на чём основана претензия. Когда я начал формулировать ОС по BOFF, то мне пришлось проделать большую работу: превратить абстрактную оценку «говно» в конкретные наблюдаемые критерии, описать последствия (лишние затраты времени на груминг и выяснение деталей), эмоции (я раздражался) и предложить конкретные улучшения. Максимально непростая работа, скажу я вам. На подготовку к этому разговору я потратил несколько часов, а занял он всего 15 минут. Мы приятно поговорили, я объяснил наши трудности и предложил решение, которое мой коллега слегка откорректировал и принял в работу, благодаря чему качество требований стало лучше. Приятным бонусом стало улучшение наших отношений: после этого разговора мы поняли, что можем конструктивно обсуждать проблемы и находить методы их решения. Я его даже потом технике BOFF обучил :) // А что вам помогает перейти к конструктивному разговору, когда хочется просто сказать коллеге, что он несёт херню?

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

Ежегодное исследование руководителей разработки от DevCrowd Про работу тимлида много говорят и почти ничего не считают. Сколько платят руководителю с командой из пяти человек и сколько с командой из тридцати. Кто выгорел в этом году, а у кого все в порядке и почему. Что руководитель решает сам, а что все равно идет согласовывать, и как это связано с тем, тяжело ему сейчас или нет. У скольких команд часть работы уже делают AI-агенты и кто потом отвечает за их код. Ответить на такое можно только хором: цифры берутся ровно из того, что руководители расскажут про себя. Чем больше ответов, тем точнее получится сравнить. В декабре DevCrowd традиционно выпустят публичный отчет. Я уже заполнил опрос, приглашаю и вас присоединиться к исследованию 😇 📎Опрос анонимный, 12–15 минут: https://survey.devcrowd.ru/tl-2026

Как Imprint пробует ускорить код-ревью с помощью small-change Уилл Ларсон (которого я очень люблю читать) в последнее время пишет статьи про построение агентной разработки. На днях он выложил статью о модели ускорения код-ревью для маленьких изменений. Imprint столкнулись с той же проблемой, что и вся индустрия: значительный рост количества PR (средний инженер мержит в 4! раза больше PR, чем 2 года назад). При этом медианное время ревью выросло с 33 до 77 минут. Поэтому они решили ускорить проверку небольших изменений. ⭐️ Интересные идеи ➡️ Часть изменений автоматически помечаются как small-change. Условия: PR меньше 1000 строк, ai-code-review не нашел ничего критичного, автор замержил 10+ PR в этот сервис или директории, влияние ограничено N сервисами, общие библиотеки и утилиты исключены, отдельные пути можно запретить. ➡️ small-change проходят ревью отдельным скиллом. Этот скилл не комментирует, а только ставит аппрув или оставляет PR без действия. ➡️ Ожидание: если что-то по результатам мержа small-change упало, то проблема заключается в системе. По результатам такого падения нужно улучшать harness, CI/CD, механизмы верификации и т. д. ➡️ Для шаринга знаний у них есть второй скилл — review-pr-cluster. Он разбирает группы PR и предлагает общие темы для обсуждения и новые проверки. Ларсон честно признаётся, что текущих результатов пока недостаточно для того, чтобы делать какие-то далеко идущие выводы. Сейчас всего около 10% PR помечаются как small-change — он характеризует это как признак того, что сама концепция работает, но её ещё нужно допиливать. Для меня эта статья важна тем, что показывает, что я не одинок в своей борьбе с ботлнеком в код-ревью. Мне нравится, что Уилл Ларсон рассматривает изменения в процессе через призму функций самого код-ревью и старается их не потерять. Меня тоже беспокоит вопрос того, как не потерять полезные функции чтения кода (например, шаринг знаний внутри команды). small-change — это не фундаментальный ответ, а скорее эксперимент конкретной компании. Мне здесь интересен сам подход: выделить ограниченный класс изменений для быстрого ревью и отдельно продумать, как сохранить обмен знаниями в команде. Я сейчас разбираюсь, как разные команды перестраивают код-ревью под агентскую разработку, и планирую собрать из этого отдельный ресёрч. Если вы уже меняли процесс у себя — расскажите, что попробовали и что получилось. Особенно интересно, что не сработало. // А у вас какие-нибудь изменения уже проходят без человеческого ревью?

Понятную задачу легко оценить Если после декомпозиции команда долго спорит об оценке, то нужно не добиваться числа любой ценой, а вернуться к подготовке задачи и проверить проблемные места. Я в работе практически постоянно сталкиваюсь с ситуациями, когда команды затрудняются оценить сроки выполнения той или иной задачи. Попытки собрать груминг и всё решить неизменно заканчиваются спорами: обсуждаются нюансы, корнер-кейсы и детали реализации. Когда подобное случается, я первым делом проверяю: понятно ли команде, как сделать задачу? Если задача достаточно понятна, то сама оценка происходит быстро. Открытые вопросы обычно имеются, но не влияют на оценку кардинально. Но иногда буквально одна деталь может сделать оценку затруднительной. В такие моменты лучшее, что я могу сделать, — это остановить спор и попытаться понять, что же осталось непрояснённым в задаче. Вот буквально сесть, собрать открытые вопросы, назначить ответственных и отправиться их решать вместо оценки. Пробел далеко не всегда оказывается в требованиях. Например, некоторое время назад два разработчика час спорили над одним контрактом API. Помимо бизнес-требований, до оценки приходится прояснять и технические решения, потому что они влияют на архитектуру (поэтому я люблю подумать о них отдельно, в RFC). Конечно, это всё не панацея. Разброс в оценках может сохраняться по разным причинам (например, из-за разного опыта участников), и сам по себе долгий спор ещё не доказывает, что нарушен DoR или задача плохо декомпозирована. Но для меня главный критерий — чёткое понимание того, как новая функциональность будет интегрирована в существующую систему и как она будет обрабатывать пограничные случаи. Если спор упирается в то, как встроить функциональность в систему или обработать пограничный случай, я возвращаю задачу на проработку. Договариваться о числе имеет смысл после того, как разобрались с этим вопросом. // По каким признакам вы понимаете, что пора остановить оценку и вернуть задачу на проработку?

Вместе с писаниной выкинули обдумывание Я сейчас столкнулся и пытаюсь бороться с одной очень болезненной проблемой: сгенерированные требования. И я, и многие мои коллеги по цеху в последние месяцы остро страдают от портянок сгенерированных требований. И ключевая проблема даже не в объёме, а в том, что эти документы передают в разработку как постановку, хотя сам автор их толком даже не вычитывал. Разработка все эти документы добросовестно вычитывает и приходит к автору с кучей вопросов. И тут начинается самое интересное: автор документа теряется, сбивается или пытается придумывать решения на ходу. Например, недавно приятель рассказал мне, как после вопросов разработки требования пришлось переписать полностью, с нуля (хорошо хоть дизайн рисовать не начали). Когда пишешь требования сам, приходится формулировать, как всё должно работать. На этом месте можно обнаружить дырки в собственном понимании. Генерация позволяет пропустить этот этап и получить связный текст, не разобравшись в том, что он описывает. А с вопросами автор сталкивается уже позже, когда документ читают другие люди. Это не значит, что раньше все и всегда писали хорошо — иногда от требований у меня откровенно глаза на лоб лезли. Но необходимость самому сформулировать требование давала шанс заметить, что ты чего-то не понимаешь. Проблема даже не в том, что авторы не проверяют за нейронкой. Они передают в разработку требования, в которых сами не разобрались. Текст уже готов, а решения о том, как должна работать фича, приходится принимать при ответах на вопросы разработки. Конечно, использовать LLM для оптимизации своей работы можно и нужно (например, я недавно писал о том, как прожариваю аналитику LLMками). Но использование условного GPT не снимает ответственности за результат работы. Человек, который пишет требования, должен чётко и полно их осознавать, а не просто скидывать свою работу на машину.

В поисках новых любимых книжек Я тут недавно дочитал цикл «Волкодав» и в очередной раз встрял в вопрос, что почитать дальше. Вроде бэклог художки большой, но выбор следующей книги для меня сродни выбору сериальчика — с этими персонажами и историей мы проведём некоторое время, поэтому не хочется ошибиться. И хотя я с горем пополам научил себя не дочитывать художку, каждое бросание на середине всё-таки неприятно. С одной стороны, я топлю за то, что читать нужно только то, что нравится. А с другой стороны, хочется и читательский вкус как-то расширять, потому что последние года полтора я читал в основном фэнтезятину всякую и она уже немножко поднадоела. Я понял, что хочу потихоньку выходить за пределы привычного чтения и расширять свой вкус. Эту задачу отчасти решают книжные клубы, но у меня сейчас очень большие трудности с попаданием на подобные мероприятия. Поэтому я опять применил «железного болванчика» и собрал себе промпт для долгосрочного чтения художки. В промпт я заложил три основные задачи: ➡️ Собрать и постепенно уточнять контекст моего читательского вкуса. ➡️ Предлагать максимум три книги: надёжный выбор, шаг в сторону и эксперимент. Объяснять, что может понравиться и где есть риск. ➡️ После чтения обсуждать впечатления и учитывать их в следующих рекомендациях. В первый прогон он меня задалбывал вопросами минут 40, уточняя всякие-разные детали по прочитанным мною книгам. Затем я дочитал «Волкодава» и немного описал ему свои впечатления (заняло минут 10). После чего я с любопытством запросил рекомендации. Вот что мне порекомендовал промпт: ➡️ Надёжный выбор: Гиллиан Флинн, «Исчезнувшая». Плотный сюжет, психологическая война, неоднозначные персонажи, повороты. ➡️ Шаг в сторону: Джон ле Карре, «Шпион, пришедший с холода». Моральная серость, люди как часть систем; меньше экшена, больше последствий решений. ➡️ Эксперимент: Кадзуо Исигуро, «Остаток дня». Мало событий, акцент на внутреннем процессе героя; обозначенный моделью риск — слишком медленное чтение для привычного вкуса. На серьёзные эксперименты меня сейчас не особо тянет, поэтому мой выбор пал на книгу Гиллиан Флинн «Исчезнувшая». Теперь мне предстоит проверить этот промпт чтением, и я надеюсь, что эта попытка будет более успешной (через прошлую рекомендацию я продирался через боль и страдания).

Как потренировать управленческие навыки Одна из самых сложных задач для развития руководителей -- понять, как прокачивать те или иные навыки. Например, как можно прокачать лидерство? Коммуникабельность? Ответственность? Переход разработчиков в руководящие роли и так непрост,нужно быстро-быстро развить много новых навыков, и не всегда понятно, что вообще для этого делать. На VK JT TeamLead* можно обсудить эти вопросы с опытными руководителями, которые уже прошли этот путь. Это новый митап для тимлидов, руководителей разработки и тех, кто только думает о переходе в управление. Митап ориентирован на практику. В программе: ➡️ Дискуссия о профиле лидерства от экспертов из VK и других компаний. Можно перенять чужие подходы и ментальные модели к управлению, командообразованию и эффективной работе. ➡️ Практическая часть на выбор: 1-1 сессии с опытными тимлидами из VK, мастер-класс по теории ограничений или "Своя игра" для тимлидов с решением реальных управленческих задач. Митап будет проходить в Москве и Санкт-Петербурге в разные даты: 📍Москва — 24 октября 📍Санкт-Петербург — 28 октября Приходите, чтобы обменяться опытом с другими руководителями, прокачать навыки управления на практике и просто приятно провести время в кругу единомышленников! 📎 Посмотреть подробности и зарегистрироваться * VK Только Технологии для руководителей команд

Роберт Киган, Лиза Лэйхи, «Неприятие перемен. Как преодолеть сопротивление изменениям и раскрыть потенциал организации» В процессе работы над серией эссе о трансформационных идеях я стал задумываться: а почему мы не меняемся? Почему даже хорошие и умные идеи могут «пощекотать мозг» и исчезнуть без следа? Я стал ресёрчить тему и получил набор рекомендаций, одной из которых была эта книга. ⭐️ О чём книга Книга посвящена сложностям внедрения изменений в организации. Авторы книги разбирают, почему люди сопротивляются изменениям (они называют это «иммунитет к переменам»), и предлагают читателю свой фреймворк для анализа и преодоления личных причин сопротивления изменениям. ⭐️ Три идеи, которые я забрал себе 🟡Если изменение требует пересмотра убеждений, одних технических мер может оказаться недостаточно. Можно добиться временного результата, а потом вернуться к прежнему поведению. Технический подход к ним приводит к тому, что мы на время добиваемся желаемого результата, а потом ловим откат. Например, моя личная боль — сушка (технически я легко сбрасываю несколько кг, но потом они всегда возвращаются). 🟡Мы можем искренне хотеть перемен и одновременно защищать то, что эти перемены ставят под угрозу. Мы часто не меняемся, потому что защищаем себя от какого-то чувства страха и наши текущие убеждения позволяют не испытывать этот страх постоянно. Но часто случается так, что эти защиты дисфункциональны и скорее мешают нам, чем помогают. Скажем, я когда-то любил заедать стресс (а потом сушиться, ага). 🟡Размышления без действий так же бесполезны, как и действия без размышлений. Можно осознать свои защитные механизмы и испытать сильный инсайт — и всё равно ничего не изменится. Для перемен нужно начать действовать по-новому, постепенно преодолевая и перестраивая свой «иммунитет к переменам». Авторы предлагают фреймворк, который связывает разбор своих убеждений с проверкой их в действии. ⭐️ Мои впечатления Для начала мне понравился сам подход авторов к этой книге. Они провели исследования, написали научные статьи, а потом упаковали свои выводы в более простой формат для широких масс неспециалистов типа меня (за что я им премного благодарен, потому что до этого я с огромным продирался через книгу-ресёрч). Книга написана достаточно просто, чтобы интересующийся мог понять и применить ключевые идеи, не ломая мозг об академический слог. Сами идеи книги просты в понимании, но сложны в применении. Фреймворк изменений, который предлагают авторы, требует честности с собой и упорной работы. Их теория перекликается с моим опытом личностных трансформаций, и я вижу в ней смысл. По сути, авторы предлагают взять что-то очень для себя значимое, докопаться до скрытых выгод старого поведения и пошагово их менять. Они не обещают лёгких и быстрых перемен — скорее наоборот, предупреждают, что на качественные изменения могут уйти месяцы. Насколько реалистичен их подход к организационным трансформациям, я затрудняюсь оценить. Да, в книге они приводят несколько интересных кейсов групповых трансформаций, но они показались мне сложно воспроизводимыми на практике. Отдельные вопросы из книги можно попробовать, например, на ретро: что нам даёт привычный способ работы и что мы рискуем потерять, если его изменим? Но это ещё не применение всего метода, и ответы могут оказаться связаны с условиями работы команды. Книгу я бы рекомендовал тем, кто уже понимает, что хочет изменить, но снова и снова возвращается к старому поведению. Руководителям она может дать вопросы для разбора сопротивления изменениям, но я не знаю, насколько получится воспроизвести описанные организационные кейсы. Все мои обзоры книг доступны по тегу #обзор_книги и в этом посте. ➡ А для тех, кто хочет читать с большей пользой, у меня есть практикум «ИнфоСушка», в котором мы полностью меняем подход к чтению и делаем его эффективным. ➖➖➖➖➖➖➖➖➖➖➖ 📝 @ulshinblog

С кем хочется работать даже после провала Я искренне убеждён, что сотрудничество — лучшая стратегия по умолчанию для работы в долгосрок. У меня остались люди, с которыми мы вместе долгое время ели одно известное вещество черпаками. И, несмотря на все неудачи, мы до сих пор общаемся и поддерживаем контакт (и даже периодически пытаемся друг друга схантить). Люди запоминают, что ты говорил и делал в трудный момент. И запоминают это вне зависимости от успеха или провала проекта. В трудные моменты часто хочется спрятаться в свой замок (как на меме) и найти причину своих проблем где-то вовне. Но бизнес-то, в котором вы работаете, остаётся общим. Например, горит у вас релиз и вообще всё плохо. Я в такой ситуации наблюдал, как разработка начинает ругаться с продуктом: первые говорят, что хотелок слишком много, вторые обвиняют первых в лени. А ведь продуктивнее всего в такой ситуации сесть и начать сотрудничать: поговорить, обсудить проблемы и совместно придумать решения. При этом вовсе не обязательно быть героем в красном плаще. Сотрудничество складывается из простых вещей: где-то остановить пререкания и вернуться к обсуждению проблемы, где-то поддержать уставшего человека, где-то пойти на уступку ради общего результата. Конечно, не стоит терпеть бесконечно затянувшиеся конфликты и иногда нужно принимать неприятные решения. Но эти решения должны быть мотивированы желанием достичь общей цели. Проект может провалиться по сотне разных причин. Но это не обязательно означает конец человеческих отношений. // Было у вас такое: проект провалился, а с людьми из него вы с удовольствием поработали бы снова?

Про надёжность и людей, которые её возвращают Один из вопросов, который я очень люблю задавать на секции сисдиза, звучит так: «А теперь давай посмотрим на твою схему и подумаем, что произойдет в случае отказа одного ЦОДа». Задаю я его не для красного словца. В моей зоне ответственности последние годы находятся сервисы с высокими требованиями к надежности и поэтому мне важно, чтобы команда умела работать в подобных обстоятельствах. Катастрофы уровня «минус два-три ЦОДа» на моей памяти не проектировал никто. До сих пор. Сейчас я просто хочу послать лучи добра и поддержки тем, кто уже не первый день своими руками разгребает последствия произошедшего. Терпения и сил вам, ребята ❤️ А когда все успокоится немного — будем дружно возвращаться к изучению и прокачке system design. Потому что именно ради таких сложных ситуаций нужно ломать мозг об Танненбаума и Клепманна, разбираться со всякими рафтами и редлоками, решать проблемы кросс-цодовой мастер-мастер репликации, тестировать бэкапы и заниматься прочими сложными, мозголомными вещами. Читайте книжки, проводите архитектурные каты (очень рекомендую, недавно проводил — крутейший опыт) и посмотрите ещё раз на свои системы через призму надёжности нового времени. Всем сил 💪

Код-ревью в эпоху ИИ: как агенты меняют проверку кода На работе пулл-реквестов стало больше, они стали заметно объёмнее. Каждый последующий аппрув я ставлю с меньшей уверенностью. В предыдущем ресёрче про coding agents и SDLC я разбирался, как и почему проверка кода становится узким местом в разработке. А теперь я решил отдельно посмотреть, что происходит с код-ревью. Мне стало интересно: а что же сейчас происходит с код-ревью как процессом? Продолжают ли люди отсматривать построчно пулл-реквесты, сделанные агентами, или ставят аппрувы не глядя? И на что в итоге это влияет? Лично я уже смещаю внимание на спецификации, архитектуру, контракты и интеграционные тесты. Насколько такой подход сохраняет качество и передачу знаний, я пока не могу оценить. Из этих проблем и вырос мой новый ресёрч о том, как происходит код-ревью в эпоху ИИ. Вот несколько интересных тезисов: ➡️ AI-ревью на первом круге: полезные замечания есть, но экономию времени человека подтвердили далеко не везде. В A/B-тесте Google значимого ускорения ревью не нашли. ➡️ Аппрув и глубина проверки: в одной выборке люди чаще одобряют агентские PR и меньше комментируют. Это ещё не доказывает ухудшения качества, потому что дефекты за аппрувами не измеряли. ➡️ Проверка после мерджа: появляются данные о последующих исправлениях и откатах. Результаты различаются между агентами, свести всё к «AI-код хуже» не получится. ➡️ Передача знаний: человеческое ревью обсуждает контекст и помогает команде понимать систему. В агентских комментариях эти функции почти отсутствуют. Долгосрочный эффект для роста junior пока неизвестен. В ресёрче я разбираю, что исследования уже показывают о пользе AI-ревью, поведении людей и исправлениях после мерджа. И объясняю, как меняю собственную проверку под выросший поток PR и какие последствия ещё предстоит измерить. // Если прочитали — поделитесь, пожалуйста, обратной связью, был ли вам полезен и интересен ресёрч. Хочу сделать будущие публикации лучше :)

Новый сезон Podlodka Teamlead Crew: Системный подход к AI в работе тимлида Команда активно использует AI. А есть ли с него толк? Поменялось ли что-то в работе команды, кроме набора новых инструментов? В этом вопросе пытаются разобраться коллеги в рамках нового сезона Podlodka Teamlead Crew о системном подходе к AI в работе тимлида. Конференция посвящена переходу от «каждый сам по себе» к «мы договорились и выработали общие подходы» и оценить эффект внедрения AI для команды. Внутри вас ждут доклады, воркшопы и круглые столы на тему применения AI в разработке. Вот несколько крутых и интересных мне тем: ➡️ Марина Орешина — доклад «Не начинайте с AI: как найти настоящее ограничение инженерной системы». Как посмотреть на путь от идеи до релиза и найти реальное ограничение, ведь ускорение написания кода может не сократить Time to Market, а увеличить очереди дальше по процессу. ➡️ Евгений Никитин — воркшоп «Пишем свой harness тимлида». Будут реальные кейсы агентов для управленческой рутины, грабли и разбор задач участников: выбор архитектуры, оценка пользы и стоимости, определение владельца. ➡️ Григорий Скобелев, Артем Арюткин, Сергей Воробьев — круглый стол «Как подобрать метрики эффективности AI?». Какие показатели можно считать на своей команде, а какие просто создают видимость эффекта? Как обосновать цифры перед бизнесом? В прошлом году я сам выступал в качестве спикера на Podlodka Teamlead Crew и вспоминаю этот опыт с теплотой. Подлодка — это не просто доклад и пару вопросиков, а ещё и «курилка не под запись» после доклада, активное общение со спикерами в чате и многое другое. А по моему промокоду ulshin вы получите дополнительную скидку на билеты 🔥 🗓 19–23 октября 2026 года, онлайн. Утром 10:00–11:00, вечером 19:00–21:00 по Москве. 📎 Программа и билеты доступны по ссылке

Тридцать замечаний LLM ради одного нужного вопроса Вопросы от бездушного железного болванчика люди воспринимают спокойнее. Я на это и рассчитывал, когда подключал LLM к аналитике: пусть бездушная машина душнит, ищет противоречия, неотвеченные вопросы и делает допущения явными. Почему аналитика? Неясное поведение затрудняет декомпозицию, оценку и тестирование. А уточнение фичи после реализации может стоить очень-очень дорого. О том, почему полезно душнить над деталями, я уже писал ранее. Конечно же, раннее уточнение тоже требует времени. Какие-то неизвестные вещи всегда вылезут только при реализации, и если слишком сильно увлечься аналитикой, то можно потерять больше времени, чем сэкономить. Поэтому здесь нужно подходить с умом. Например, недавно я провёл анализ фичи и получил от LLM-ки 30 замечаний, из которых всего лишь одно было полезным -- но если бы мы его пропустили, то переделка по моей оценке стоила бы 3-4 дня разработки (а у меня на ревью минут 30 ушло). Для начала достаточно вгрузить аналитику в контекст и попросить модель проверить, какие вопросы остались без ответа. Например:: ➡️ Что должно произойти, если операция выполнена лишь частично? ➡️ Одинаково ли описано поведение для разных участников и компонентов? ➡️ Какой результат позволит однозначно проверить, что эта фича работает? Задачу лучше обозначить прямо: "Найти противоречия, допущения, неявные границы и неотвеченные вопросы, Пробелы своими догадками не заполнять". Но не забывайте, что критиковать модельки умеют прекрасно, поэтому замечаний будет много. Каждое замечание всё равно должен оценить инженер: влияет ли оно на поведение продукта, тестирование или риск переделки? Количество замечаний само по себе не показывает пользу процесса Напоследок я предлагаю вам провести реальный эксперимент: взять одну фичу, дать модели имеющееся описание и попросить найти неясности, не заполняя пробелы своими догадками. После этого зафиксируйте, сколько усилий вам потребовалось на то, чтобы разобрать замечания, и нашла ли модель что-то, что было бы ощутимо дороже переделать после того, как вы бы реализовали фичу без этого требования. // А если вы уже используете LLM-ки для аналитики, то делитесь своими лайфхаками в комментариях

Я наконец-то собрал свой блог За несколько лет ведения канала у меня накопились посты, лонгриды, исследования, выступления и эссе. Теперь всё это собрано на ulshin.tech. Я давно хотел это сделать по нескольким причинам: ➡️ Мне не нравится, что мой контент живёт только в ТГ. Внезапная блокировка — и придётся срочно-срочно поднимать альтернативную площадку. ➡️ Некоторые форматы (например, лонгриды или эссе) откровенно не лезут в формат ТГ-поста. Я уже попробовал выложить одно эссе в md-разметке — было очень грустно и некрасиво. ➡️ Материала накопилось много, и темы часто пересекаются. В блоге удобнее связывать тексты между собой, чтобы можно было идти от одной мысли к другой. Поэтому последние две недели я по вечерам потихоньку вайбкодил блог: поднимал его, делал дизайн и работал над накопившимися за эти годы заметками. Некоторые из них я в итоге объединил в отменные лонгриды. Приглашаю вас посмотреть блог и сохранить его себе. А чтобы вам было вдвойне интересно — на выходных я написал продолжение эссе «Почему не все интересные идеи влияют на жизнь» под названием «Признаки трансформационной идеи», в котором разбираюсь, чем идеи, которые меня действительно изменили, отличаются от тех, над которыми было просто приятно подумать. 📎Сохраните адрес блога, если хотите возвращаться к моим материалам. Приятного чтения!

В последнее время на вопрос "Как у тебя дела?" я отвечаю: "Как в альбоме Пневмослона" 😇 Один из моих любимых музыкантов, кстати.

Как я понял, что пора внедрять агентов в разработку Меня долго беспокоил простой вопрос: как ограничивать агентов и вести с ними продолжительную командную работу над большим проектом? Поэтому с внедрением я не спешил. Но продолжал наблюдать, что меняется. Опыт — это палка о двух концах. С одной стороны, опыт помогает принимать хорошие и качественные решения. Но с другой стороны, тот же опыт может мешать внедрению инноваций в работу и в итоге замедлять её. Так получилось и с агентами. Бум разработки с AI начался ещё год назад (даже чуть больше). Тем не менее я не спешил тащить агентов куда-то в продакшн, потому что открытых вопросов было очень много и опыт рекомендовал не торопиться. Но я продолжал наблюдать. Больше всего меня беспокоило отсутствие нормальных инструментов для ограничения работы агентов и для продолжительной командной работы над большим проектом. Поэтому я с большим интересом наблюдал за тем, как агенты писали говнокод и дропали базы в проде. В итоге индустрия ответила — появились SDD, гардрейлы, сендбоксинг и ещё много чего. Работа с агентами стала более безопасной, а сам процесс разработки обогатился подходящей методологией и созданием полезных артефактов на будущее. Когда это произошло — я понял, что пришла пора активно внедрять агентов в разработку, и начал свой коварный процесс (пробить всем аккаунты Клода, показать пару личных примеров, скинуть интересный скилл в чат и прочая пропаганда). Изменений практик в индустрии оказалось достаточно, чтобы я переключился из наблюдения в действие. В этом для меня смысл слежки за индустрией: замечать, когда снимаются ограничения, из-за которых я раньше откладывал внедрение. И быть готовым пересмотреть своё решение. Отсидеться на жопе ровно в нашей индустрии не получится. // Какое ограничение вам нужно снять, чтобы активнее использовать агентов в команде?

Озвученная дата автоматически становится обязательством Иногда «примерные даты» на роадмапе неожиданно становятся обязательством. Причём это может произойти даже без явного намерения человека, эти даты изначально написавшего. Причина тому проста: для читателя документа опубликованная дата уже выглядит согласованной. Происходит это обычно так: ➡️ Продакт прикидывает фичи и сроки на некоторый период вперёд. ➡️ Показывает предварительный план бизнесу. ➡️ Бизнес видит конкретные даты и начинает считать их согласованными. ➡️ В разработку дата возвращается уже не как ориентир, а как обязательство. ➡️ Разработка впервые проверяет обязательство на выполнимость и закономерно негодует. С такой же ситуацией я столкнулся несколько месяцев назад. В статусных материалах появились конкретные даты, которые не согласовали с разработкой. Когда мы сверили их с реальными возможностями, выяснилось, что заложенный объём работ в эти сроки не влезает. В итоге мне пришлось долго и упорно откусывать от скоупа каждую лишнюю фичу, чтобы обещание стало выполнимым. Проблема заключается именно в показанных датах. Читатели уже начали строить вокруг них свои планы, поэтому последующее уточнение воспринимается не как завершение оценки, а как перенос срока. Впоследствии часто оказывается, что треугольничек «сроки — объём — доступные ресурсы» не складывается и чем-то надо жертвовать прямо на ходу. Поэтому приходится резать требования, создавать технический долг или пытаться наковырять где-то у соседей ресурсы «на полставочки», но это отдельные переговоры, а не гарантированное решение проблемы. Хороший роадмап — это не красивая картинка со сроками и графиком клюшкой, а точка согласования возможностей и обязательств тех сторон, которые этот роадмап будут выполнять. Нельзя просто взять и проверить дату: всё написанное в роадмапе нужно хотя бы примерно оценить на выполнимость и приоритезировать. Оценка не должна быть хирургически точной, но стоит хотя бы минимально провалидировать её с разработкой. Дата в презентации уже выглядит обещанием результата, поэтому публиковать её стоит только после сверки планов с реальными возможностями разработки. // Доводилось ли вам так случайно коммититься на дату, когда вы этого даже близко не планировали?

Технофитнес: как эффективно прокачивать hard skills Наконец-то в паблике появилась запись моего доклада с HolyJS 2025 Autumn о том, как разработчику эффективно качать свои харды. Этот доклад я готовил почти год и несколько раз обкатывал по частям на митапах, тестируя тезисы. Несколько раз я его кардинально перерабатывал, и в итоге получилась конфетка. Сам доклад — это история моей боли. После перехода в менеджмент я ощутил, что сильно выпадаю из технички, и старался не потерять профессиональную опору. Я пытался компенсировать просадку книгами и курсами, но ничего не получалось — сил уходило много, результата было мало. И тогда я начал разбираться в вопросе. Что интересного есть в докладе: ➡️ заблуждения о развитии hard skills, которые усиливают тревогу; ➡️ принципы выбора навыков и построения образовательной траектории; ➡️ конкретные способы получать больше технического роста из рабочих задач; ➡️ работа с книгами, статьями, конференциями и LLM без бесконечного потребления информации. С того дня, когда я рассказывал этот доклад, прошел уже почти год. И мне кажется, что он стал только более актуальным — технологии в очередной раз совершают скачок, и многие мои знакомые тимлиды страдают от того, что выпадают из агентной разработки. Сейчас я разве что немного поправил бы построение образовательного трека — LLM-ки за год успели серьёзно качнуться. 🎞 Доклад 📎 Дополнительные материалы Приятного просмотра!

«Масштабированный скрам. Как организовать гибкую разработку в крупной компании», Крэг Ларман, Бас Водде Одна из моих текущих задач — выстраивание процесса разработки на несколько команд в одном продукте с последующим масштабированием этих практик на все остальные продукты, разработкой которых я управляю. В прошлый раз при решении этой задачи я умудрился переизобрести LeSS (Large-Scale Scrum). В этот раз я не стал мудрить и решил использовать те практики, которые уже хорошо себя зарекомендовали. Книгу я взял, чтобы вспомнить, из чего вообще строится LeSS и как его аккуратно внедрить, когда команда уже в разгаре разработки. Но ответа на второй вопрос я не нашёл. Вместо алгоритма внедрения получил россыпь моделей, практик и теорий. ⭐️ О чём книга Книга посвящена тому, как внедрить LeSS в большой организации. Авторы фокусируются на моделях мышления, которые нужны для успешного внедрения подхода, и дают кучу идей и практик, которые читателю рекомендуется попробовать. Много внимания в книге уделяется инструментам мышления и анализа, которые позволяют эффективно управлять работами. ⭐️ Три идеи, которые я забрал себе 🟡При масштабировании делить нужно работу, а не продукт. LeSS предполагает, что все команды работают в едином продуктовом бэклоге и едином ритме, а с требованиями помогает справиться единый владелец бэклога. Такой подход помогает не превратить команды в отдельные «мини-продукты со своим миром». Меня эта идея зацепила тем, что при масштабировании очень легко неосознанно размножить локальные бэклоги и получить несколько правильных приоритетов одновременно. Общий бэклог заставляет выбирать, что важнее для продукта целиком. 🟡В LeSS менеджер становится не просто «передастом» работы, а учителем. Задача менеджера — распространять правильные паттерны мышления и по сути выращивать культуру организации. Поэтому от менеджеров в LeSS ожидается, что они будут целенаправленно уделять время обучению и коучингу своих людей. Это та работа, которая (по моим личным ощущениям) даёт огромный профит с точки зрения человеческих ресурсов: сотрудники получают положительное внимание и растут. 🟡Задача команды — поставить фичу клиенту. Фича — это единица ценной функциональности. Здесь речь уже о границе ответственности. В функционально разделённых организациях я многократно встречал ситуацию: бэкенд закончил свою часть, передал работу дальше и формально всё сделал правильно, только клиент ценности не получил. При этом за фичу целиком уже никто не отвечает. ⭐️ Мои впечатления Недавно в комментариях была просьба написать пост о книгах, на которые было зря потрачено время. Пожалуй, этой книгой можно открыть список. В книге смешались в кучу кони, люди, Дао Тойота, ТОС, теория массового обслуживания и ещё невесть что. При чтении книга показалась мне несвязной и слабо структурированной. К счастью, навыки предварительного анализа и скимминга сэкономили мне кучу времени. Проблема не в самих темах. Они реально полезны при работе с большой организацией. Проблема в том, что авторы постоянно прыгают между моделями мышления, оргдизайном, метриками и отдельными практиками, но не собирают их в последовательный ответ на вопрос «что делать завтра». Как руководство по внедрению LeSS книга для меня не сработала. Не повторяйте моих ошибок. Если вам вдруг нужно внедрить LeSS (или вы просто хотите познакомиться с ним) — вот два замечательных ресурса: ➡️ LeSS Brochure — краткое, но ёмкое и наглядное описание LeSS в 8 страниц. ➡️ LeSS Rules — буквально шпаргалка по LeSS. Если нужно быстро познакомиться с LeSS или освежить его устройство, книгу можно спокойно пропустить. Пригодиться она может тем, кто уже знает основы LeSS и хочет покопаться в лежащих под ним моделях мышления. Но как точку входа я её не рекомендую. Все мои обзоры книг доступны по тегу #обзор_книги и в этом посте. ➡ А для тех, кто хочет читать с большей пользой, у меня есть практикум «ИнфоСушка», в котором мы полностью меняем подход к чтению и делаем его эффективным. ➖➖➖➖➖➖➖➖➖➖➖ 📝 @ulshinblog

Как я возвращаю паузы, которые у меня отнял ИИ Недавно я писал, что ИИ убрал из моей работы передышки. Тогда я только описал проблему, а теперь придумал простое правило, которое помогает мне не сдыхать. Я стараюсь убирать руки от компа, как только запустил задачу в ИИ. Вместо «ещё одной задачи» я предпочитаю встать и размяться (и даже подумываю купить себе гирю). Ожидание ответа агента ощущается как «свободное время, которое можно потратить на продуктивную эффективность». Руки сами тянутся открыть ещё одну вкладку и запустить там чего-нибудь поработать, не теряя ни секунды. Такая работа ощущается очень эффективной: ИИ жжёт токены, вкалывает человек. При таком режиме работы можно сделать больше за небольшой промежуток времени. Но силы начинают уходить как будто в чёрную дыру. По ощущениям это напоминает бег: можно сильно разогнаться на старте, но долго в таком темпе не побегаешь. Я решил привязать новое поведение к уже существующему (спасибо книжке «Атомные привычки»). Поэтому при запуске чего-либо в генерацию агента я физически убираю руки от компа и встаю размяться. Задача этого правила — не выжать побольше из каждой минуты времени, а сохранить рабочее состояние на протяжении дня (и недели). В эти минуты я просто встаю из-за компа: разминаюсь, делаю пяток бёрпи, жмякаю кота или приседаю с дочкой на руках. Теперь вот думаю купить гирю — махи хорошо подходят для такой короткой паузы. Это не универсальная методика, а моё правило под мой режим работы. Оно помогает не путать занятость каждой отдельной минуты с нормальной продуктивностью на дистанции. ИИ должен экономить мои силы, а не помогать мне эффективнее их сжечь. // А вы сразу запускаете нового агента или используете это время как паузу?

Почему не все интересные идеи влияют на жизнь Я люблю читать книги. В детстве меня поглощали миры и ситуации, придуманные талантливыми авторами. В более взрослом возрасте я плотно подсел на «нон-фикшн»: меня восхищали новые, яркие идеи, написанные умными людьми в разное время и в разных частях нашей планеты. Эти идеи дарили мне радость долгое время, однако в какой-то момент я заметил, что в мою жизнь они проникают не очень-то активно. Лишь некоторые книги дали такую пищу для размышлений, что я по-новому взглянул на мир. Идеи из этих книг глубоко проникли в мою голову и изменили мировоззрение. Момент времени, в который я осознал это, стал переломным. Меня больше не радовали новые интересные идеи сами по себе, потому что найти их довольно просто (достаточно оглядеться вокруг и немного подумать). Предметом моего любопытства теперь стала трансформация мышления и мировоззрения через усвоение чужих идей. ⭐️ Что такое «усвоенная идея»? Прежде чем мы двинемся дальше, я бы хотел дать своё определение термину «усвоенная идея», поскольку дальше мы им будем оперировать постоянно. Для меня «усвоенная идея» – это идея, которая настолько прочно встроилась в мою голову, мышление и систему ценностей, что начала влиять на моё поведение, решения и мировоззрение. По сути, это идея, ставшая частью меня самого. Примером такой усвоенной идеи являются «толстые хвосты» из творчества Нассима Талеба. В своих книгах он часто говорит о нелинейной природе вероятности, а «толстыми хвостами» называет маловероятные события (находящиеся слева/справа на кривой нормального распределения) с аномально мощными последствиями. Переварив эту идею, я перестал смотреть на маловероятные события только с точки зрения вероятности их наступления и начал задумываться ещё и о рисках, которые они создают (въедливый читатель тут к месту упомянет «чёрных лебедей» и будет прав, но это эссе не о теории вероятности в жизни). Усвоение этой идеи поменяло мой взгляд на применение теории вероятности в реальном мире, сделало его шире и богаче. Подобное изменение в мышлении напоминает фарш в мясорубке – его невозможно обернуть вспять. После усвоения идеи начинаешь видеть мир иначе раз и навсегда. ⭐️ Область усвоения идей Я довольно долго экспериментировал с различными методиками усвоения идей. Я работал над техниками обработки информации, учился писать заметки (и даже практиковался в мини-эссе), применял различные мнемотехники и даже попробовал скорочтение, но толку было немного. Процесс усвоения идей по-прежнему оставался для меня окутанным мраком случайности и везения. Тогда я задумался: а что же кардинально отличало те идеи, которые залетели мне в голову и крепко там засели? Ответ пришёл в виде книги Оливера Беркмана «Четыре тысячи недель на всё», которая внезапно потрясла меня и дала возможность поискать ответ на вопрос выше. Ведь потрясение не на ровном месте произошло. Крепко подумав над этой ситуацией, я пришёл к выводу, что книга Беркмана на самом деле попала в то напряжение, которое у меня в жизни уже было. Я долго страдал от ощущения, что я ничего не успеваю и во всём, что делаю, недостаточно хорош. Идеи Беркмана дали мне не готовое решение, но достойную пищу для размышлений, которая не отпускала меня несколько дней. Из этой ситуации я вывел следующую гипотезу: усваиваются только те мысли и идеи, которые попадают в существующее напряжение в жизни. Этим напряжением может быть сильная личная потребность найти ответы, дискомфорт, боль, затруднение, недопонимание. Но главная отличительная черта напряжения – высокая степень личной значимости. В первую очередь мы усваиваем идеи в областях, которые нам сильно небезразличны. Однако это не гарантирует, что идея усвоится. Но о поиске идей с сильным потенциалом усвоения – в следующем эссе. // Неплохо я развлекаюсь на выходных, да? :)

Итоги курса «Руководитель отдела» Вот и подошли к концу 4 месяца интенсивного обучения на курсе Стратоплана «Руководитель отдела». Этим постом я хочу подвести итоги обучения. На курс я шёл, потому что чувствовал потребность в фундаментальном и системном обучении менеджменту. С ростом масштаба моих задач становилось всё больше вопросов и всё меньше готовых ответов. Курс оказался для меня полезным, однако его главная ценность для меня была не в количестве новой информации. Раз за разом на лекциях я с удивлением обнаруживал, что всё делал правильно, но скорее интуитивно. Курс помог мне дать имена этим подходам, разложить их по полочкам в голове и понять границы их применения. Обнаружились и области, где моего набора инструментов было недостаточно. Я узнал много нового об управлении изменениями, работе с финансами, реализации инженерной стратегии и масштабном people-менеджменте. ⭐️ Три самых сильных инсайта, которые я вытащил из обучения ➡️ Осознанность сильнее интуиции. Когда понимаешь, почему инструмент работает, его легче применять, передавать другим и замечать ситуации, в которых он не подходит. ➡️ Теория без практики не имеет ценности. Я об этом давно пишу, и обучение лишь подтвердило мой взгляд на вещи. Максимум пользы давали кейсы, групповая работа и попытки применить инструменты на свои задачи. ➡️ С ростом масштаба меняются сами инструменты управления. То, что работает для команды или небольшого числа людей, начинает ломаться на уровне отдела. Например, регулярные 1-1 уже нельзя считать всей системой people-менеджмента. Самая сильная сторона курса — это постоянная плотная практика на управленческих кейсах и большое количество групповой работы. Но к концу курса из-за этой плотности и высокой нагрузки я ощутимо устал. Но зато я чувствую, что реально потыкал новые инструменты (а что-то сразу утаскивал в работу). Есть у курса и недостатки. Во-первых, восприятие материала сильно зависит от преподавателя (например, я не люблю излишне многословных людей, а кому-то, наоборот, только такие и нужны). Во-вторых, AI-вставки были очень базовыми для моего уровня и оказались скорее бесполезными в большинстве своём. Но это мелочи на общем фоне. По моим ощущениям, курс подойдёт, если у вас уже реально есть подходящие управленческие задачи. Материал рассчитан на цикл «понять — попробовать — применить в работе» и не годится для накопления информации «на вырост». Это было интересное приключение. А теперь нужно передохнуть, разобрать накопленное и продолжать применять то, что я утащил с обучения.

«Не знаю» больше не значит «не могу» С развитием LLM-ок фраза «я не знаю» перестала означать «я не могу это сделать». Благодаря бездушной железяке я могу спокойно зайти в плохо знакомую (или даже совсем незнакомую) область и начать в ней действовать, даже не имея глубокой экспертизы (но только до границы, за которой я уже не способен проверить результат). Раньше это было намного сложнее. Чтобы сделать что-то для себя новое, мне приходилось читать доки или форумы, смотреть видосы, пытаться повторить, ошибаться, материться и не понимать, что происходит. Либо же приходилось искать того, кто знает. Теперь я могу разбирать с агентом конкретную задачу и получать достаточно контекста для следующего шага, не погружаясь предварительно во всю область. Например, я всегда плохо знал Bash: пользовался им редко, каждый раз погружался заново, поэтому даже простой скрипт мог занимать несколько часов. Теперь же я простые баш-скрипты спокойно пишу агентом, а моих базовых знаний вполне хватает для их валидации. Благодаря этому я перестал прокрастинировать многие задачи на автоматизацию. Например, я наконец-то поигрался с DevEx на пет-проекте и теперь у меня нормально запускаются интеграционные тесты в монорепе с микросервисами (а раньше я это прокрастинировал, потому что "опять в баш лезть"). Этот пример не делает меня универсальным специалистом, а показывает, насколько дешевле стало осваивать соседние инструменты. Также человек всё ещё должен поставить задачу, заметить чушь, проверить корректность результата и принять за него ответственность. Я могу делегировать агенту Bash, потому что моих знаний хватает понять, делает ли скрипт то, что нужно, и не снесёт ли он полсистемы. Если я не способен проверить результат, «я не знаю» снова становится проблемой. Конечно, глубоко заменить все соседние профессии один человек не сможет. Реальный рычаг ИИ гораздо скромнее (и важнее): Т-шейпиться теперь стало гораздо проще. Агенты помогают выходить за рамки своей специализации, но фундаментом специалистпо по-прежнему остаётся глубокая компетенция в своей области. // Какую незнакомую задачу вы уже готовы отдать агенту, а какую не возьмёте, потому что не сможете проверить результат?

Из находки ИИ-радаров вырос лонгрид для Хабра В понедельник оба моих ИИ-радара зацепились за одну гипотезу: агенты ускоряют написание кода быстрее, а проверка и выпуск начинают отставать. Я пошёл её проверять и вместо короткого продолжения написал полноценный лонгрид для Хабра. Самую интересную цифру я вынес в заголовок: агенты дали оценённый рост коммитов до 240%, проектов до 80%, релизов только до 30%. Это не прямая конверсия коммитов в релизы, но разрыв хорошо показывает проблему: агенты ускоряют написание кода гораздо сильнее, чем выпуск изменений, и новое узкое место возникает во всём остальном SDLC. Код писать стало дешевле, но ревью, тестирование, архитектурный контроль и релизы не ускорились вслед за клепанием коммитов. После исследования я стал увереннее в исходной гипотезе. Когда команда переходит от личного помощника к нескольким автономным агентам, важнее становится качество системы вокруг модели — спецификации, общий контекст, ограничения, автоматические проверки, история решений и обратная связь после релиза. В лонгриде разбираю, где застревает поток AI-кода, какую обвязку уже строят LinkedIn и Atlassian и какими метриками искать новое ограничение. Приглашаю вас почитать и поддержать мою работу ❤️ Приятного чтения! ➖➖➖➖➖➖➖➖➖➖➖ 📝 @ulshinblog