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

📈 Бесплатный гайд Яндекс Практикума по AI Adoption в компании

Компании покупают подписки на ИИ-сервисы, проводят обучение, запускают пилоты. А через пару месяцев выясняется, что инструментами пользуются единицы. 

Гайд Яндекс Практикума поможет пройти путь от покупки лицензий до системного внедрения ИИ. 

С ним вы:
✅Определите, на каком этапе AI Adoption вы находитесь сейчас
✅Разберётесь, как снять страхи и сопротивление команды
✅Запустите пилот на узком участке с проверяемым результатом
✅Перейдёте от отдельных экспериментов к масштабированию
Гайд пригодится руководителям и тимлидам, HR- и L&D-специалистам, продуктовым командам.

Забирайте бесплатно 👇

Реклама, ООО Яндекс, ИНН 7736207543, erid: 2VtzqwDnj34

🎯 10 готовых решений для повышения эффективности команды

В 2026 году бизнес фокусируется не на том, чтобы удержать любой ценой, а на том, чтобы сотрудники работали эффективнее. 

Яндекс Практикум собрал лучшие рекомендации из исследований Gallup, SHRM, ВЭФ и кейсов Т-Банка, «Магнита», Skyeng и Netflix — и упаковал в один гайд.

Внутри вы найдёте:

✅ Пошаговые планы — что делать завтра, на следующей неделе, через месяц
✅ Лучшие инструменты для развития, мотивации и удержания.
✅ Советы по внедрению ИИ, созданию безопасной среды и наведению порядка в процессах
✅ Готовые формулировки, чтобы изменения принимали без сопротивления

Забирайте гайд бесплатно👇

Реклама, ООО Яндекс, ИНН 7736207543, erid: 2VtzqxZTjGh

Как насчёт партии в Backend? 😴

Дело в чём: 17 ноября AvitoTech проводит Backend Roulette. Инженерные задачи там разложат как покерную партию: за каждым столом эксперт-крупье AvitoTech даст команде вводные, а по ходу игры добавит новые обстоятельства, чтобы перестроить решение.

Можно не садиться за стол и провести время на сайд-активностях или в разговорах с коллегами. После игры всех гостей ждёт афтерпати и нетворк.

И главное: покерный опыт совсем не нужен, достаточно круто провести вечер и понетворкать!

✅ Зарегистрироваться

Как разгрузить код-ревью и сохранить понимание системы

В обзоре small-change я упоминал, что хочу разобраться, как разные команды перестраивают ревью под агентскую разработку. И вот я закончил ресёрч на эту тему.

Напомню свою исходную проблему: с применением LLM в разработке количество PR и строк в них увеличивается, их становится тяжело читать. Но при этом хочется сохранить понимание систем внутри команд, которые за них отвечают.

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

⭐️ Интересные идеи

➡️ Часть ревью можно сделать до написания кода. Инженеры Honeycomb совместно прорабатывают планы и промпты, автор разбора отмечает лучшую общую осведомлённость. Но строгий процесс оказался тяжёлым, его используют выборочно.

➡️ Обязательный approval уже убирают для части изменений. У команды Claude Code число человеческих approvals зависит от риска. Но отказ от обязательного approval работает в определённых условиях: доверенные авторы, несколько слоёв проверки, CI и процесс выпуска.

➡️ Список тест-кейсов не позволяет проверить качество самих тестов. Входные данные могут не создавать нужную ситуацию, мок — скрывать поведение, assertion — не проверять обещанное. Я изначально думал, что можно не читать тесты, но исследование меня переубедило.

Из ресёрча я пришёл к выводу, что стоит сохранить код ревью в текущем виде, но поэкспериментировать с ревью спецификаций до разработки. Это позволит немного снизить восстановление принятых решений по готовому PR (вторым фактором снижения остаётся системная аналитика).

Приятного чтения!

➖➖➖➖➖➖➖➖➖➖➖
📝 @ulshinblog

«Сырой продукт» — удобная отмазка

В комментариях к посту про мой предпринимательский опыт был следующий вопрос: «Как найти баланс между „идеально и долго“ и „быстро и говно“?»

Из своей практики и общения с приятелями я заметил, что мало кому хочется публиковать первую версию, слепленную «из говна и палок». Поэтому автор продукта впадает в бесконечный цикл полировки: ещё одна фича, ещё один текст, ещё одно что угодно.

Я придерживаюсь позиции, что нужно как можно быстрее сделать первую версию продукта и запустить его в рынок, чтобы получить обратную связь. Этот урок мне преподал первый совместный проект, который мы с экс-коллегой делали лет 10 назад. В то время был бум CRM-систем, и мы решили запустить свою. Полтора года мы её вылизывали: отменный код, готовность к масштабированию, красивый кастомный дизайн... Система так и не вышла в рынок. Наш энтузиазм иссяк раньше, чем её увидел хоть один потенциальный клиент.

(А ещё несколько продуктов на моих прошлых местах работы так погорели.)

Отсутствие результата очень легко объяснить тем, что «продукт сырой», потому что решение очевидно — нужно его доделать! Но пока продукт не увидели потенциальные покупатели, мы даже не знаем, действительно ли проблема в его сырости.

Бесконечная разработка и полировка психологически удобнее проверки востребованности. Всегда страшно идти в рынок со своим продуктом, потому что можно узнать, что он особо никому не нужен (в моём случае зачастую оно так и бывает). Улучшайзинг приятнее и безопаснее: продукт становится лучше, задачи закрываются. Но пока его никто не пробует, вопрос о востребованности остаётся открытым.

Первая версия должна давать покупателю ключевую ценность и быть сделана достаточно хорошо. Иногда эта ценность заключается в удобстве или внешнем виде — и тогда затраты на полировку полностью оправданы. Но перед очередной доработкой стоит спросить: что именно без неё человек не сможет сделать?

// У вас было такое, что дорабатывали проект, пока самим не расхотелось его выпускать?