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

Маленький семейный бизнес в Max Итак, в прошлом посте я обещался рассказать вам про один из моих текущих проектов. Проект представляет из себя два паблика в Max: 💬 Основной, на 7к подписчиков, тематика — рецепты 💬 Сателлит на 400 подписчиков, который мы только начали развивать, тематика — лайфхаки для дома Первый паблик существует уже где-то полгода, но серьёзно заниматься им и вкладывать деньги в продвижение мы начали где-то 2 месяца назад (когда немножко пришли в себя после рождения дочери). Модель монетизации — рекламная (между контентом продаются рекламные слоты, как у меня в канале). То, как эти паблики появились в нашей жизни, заслуживает отдельного поста. Если в двух словах, то мы с женой долго искали, чем бы она могла заниматься параллельно с ребёнком (чтобы кукухой не поехать и из любимого дела не выпасть). В какой-то момент она принесла мне MVP: небольшой паблик, в котором уже продавалась реклама. Я быстро навайбкодил калькулятор для медиаканала и охренел от цифр. Мы поняли, что этот проект интересен с точки зрения окупаемости и потенциала масштабирования (а ещё он довольно прост в реализации), и начали более активно им заниматься. На начало ноября имеем следующие цифры: ➡️ Общая аудитория: 7400 подписчиков ➡️ Выручка за октябрь: 22 000 р. ➡️ Заполняемость рекламных слотов: 35% (сбой Яндекса сильно подпортил малину) ➡️ Расходы на рекламу за октябрь: 27 000 р. ➡️ Средний CAC: 15 р. ➡️ CAC октября: 9 р. С учётом закупки проект сейчас работает в небольшой минус, что нормально для проекта на старте. По прошлому опыту пабликов в ВК (расскажу отдельным постом), для выхода в ноль (относительно затрат на рекламу) нужно 3–4 месяца работы. Основное время и усилия в таком проекте уходят на закупку рекламы: подбор площадок, тестирование креативов и анализ результатов. Контент почти полностью автоматизирован. Закупками занимается моя жена, на мне — техническая составляющая и автоматизации (у родителей 3-месячной крохи не то чтобы очень много свободного времени). Проект сейчас ещё маленький, но уже показывает интересные результаты. Планы на ноябрь у нас следующие: ➡️ Наращиваем закупку рекламы (у нас большой запас прочности по CAC) ➡️ Увеличиваем заполняемость рекламных слотов (целевой показатель — 50% хотя бы) ➡️ Начинаем закупку рекламы в паблик-сателлит ➡️ Тестируем ещё одну площадку, чтобы диверсифицироваться от Max (был неприятный опыт с ВК) Интересными результатами обещаю делиться в блоге 😉 А ещё для управления всей этой балалайкой и автоматизации рутины я навайбкодил целый сервис, который через некоторое время тоже попробую монетизировать. Расскажу о нём отдельно, только подготовлюсь, чтобы вы мне его не хабранули 😂 // Пишите в комментариях, о чём вам интересно было бы узнать подробнее — это определит темы следующих постов

В разработке есть простое правило: если процесс завязан на одного человека или одну команду, рано или поздно он упрётся в потолок масштабирования. С похожей проблемой, только на уровне всей компании, столкнулся крупный телеком-оператор. 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 или задача плохо декомпозирована. Но для меня главный критерий — чёткое понимание того, как новая функциональность будет интегрирована в существующую систему и как она будет обрабатывать пограничные случаи. Если спор упирается в то, как встроить функциональность в систему или обработать пограничный случай, я возвращаю задачу на проработку. Договариваться о числе имеет смысл после того, как разобрались с этим вопросом. // По каким признакам вы понимаете, что пора остановить оценку и вернуть задачу на проработку?