Никита Ульшин про 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 не снимает ответственности за результат работы. Человек, который пишет требования, должен чётко и полно их осознавать, а не просто скидывать свою работу на машину.