Управление продуктом *

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

Помните, как вы внедряли Jira, Asana или Trello? Казалось, что это и есть цифровая зрелость: задачи поставлены, коммуникация прозрачна, все удобно.

Но есть один момент, который компании осознают по мере роста: эта связка хорошо работает ровно до тех пор, пока ваша компания не перешагивает порог в 100-150 сотрудников.

Дальше начинается цифровая энтропия: растет количество зависимостей, процессы усложняются, а инструменты, которые раньше помогали, начинают тормозить. Мы в Диасофт прошли через это — от активного использования внешних трекеров до попыток адаптировать их под растущий масштаб.

Эта статья — не призыв срочно менять инструменты. Она о том, с какими архитектурными ограничениями мы столкнулись при росте, как их решали — через методологию, автоматизацию и, да, в итоге через создание собственной платформы.

Хочу рассказать о конфигурации AI-агента для полного цикла разработки (SDLC), которую я обкатал на паре своих pet-проектов. Суть: цепочка из пяти команд — от черновика фичи до готового к ревью кода — где каждый этап выполняет AI, а я контролирую и корректирую результат между этапами.

За вечер (3-4 часа) в таком режиме AI выкатывает фичу, ручная разработка которой “по вечерам” занимала бы неделю (15-20 часов). Никаких откровений тут нет — всё, что описывается, обсуждалось тысячи раз. Новизна в том, что из общеизвестных кубиков получилось собрать работающий конвейер, которым удобно пользоваться каждый день.

Привет, меня зовут Янина. Днем я управляю продуктами и проектами. Вечером — сижу в Jitsi с ребятами из IT и обсуждаю, почему у кого-то не полетел A/B-тест, как считать retention и что вообще считать ценностью в продукте. Мой разговорный клуб давно перестал быть просто поболтать на английском.

Раньше основой домашек были подкасты про какую-то боль в аналитике. Но в какой-то момент я поймала себя на мысли, что про аналитику очень сложно слушать. Ее лучше видеть (дашборд, cjm и тд). Поэтому в клуб пришли воркшопы и лекции из YouTube. И сегодня делюсь каналами, которые у нас в итоге прижились.

Если хотите, чтобы просмотр видео был максимально полезным для вашего английского, то:

В статье представлены результаты анализа национальных стандартов, закрепляющих требования к последовательности работ по созданию ИТ‑продуктов, составу, видам, наименованию, комплектности, обозначению, содержанию и оформлению проектной документации, а также к последовательности приемки разработанного ИТ‑продукта.

Актуальность: критическое осмысление требований позволило установить, что национальные стандарты не учитывают правовые и технологические особенности создания ИТ‑продуктов в рамках выполнения ИТ‑проектов (например, включение в текст контракта существенных условий, переход исключительных прав на ИТ‑продукт, подготовка программного кода в процессе выполнения служебного задания и др.).

Цель: анализ структуры проектной и юридической документации в области информационных технологий.

Результаты: установлено, что юридическая и проектная документация должна рассматриваться как единый набор документов, так как трудоустройство работников и разработка ИТ‑продукта не представляются возможными без заключения контрактов. Также была усовершенствована структура проектной документации, закрепленной в ГОСТ Р 59853. Среди основных преимуществ данной модернизации необходимо отметить возможность определения степени освоения ИТ‑субъектами требований, декларирующих документальное сопровождение процесса создания ИТ‑продуктов. Например, если ИТ‑субъект не оценивает последствия принятых управленческих решений, затраченные ресурсы, коммерческий эффект, то это может свидетельствовать об отсутствии у него внутренних стандартов по управлению ИТ‑проектами. Важно отметить, что отсутствие стандартизации негативно сказывается на создании ИТ‑продуктов, так как ИТ‑субъектам вновь и вновь необходимо будет искать оптимальное управленческое решение для проблемы, которая возможно была решена ранее в других ИТ‑проектах.

Банк как игровая площадка: обзор геймификации в российском банкинге.

Первый материал из серии обзорных статей «Геймификация по отраслям»

Рано или поздно каждый сеньор просыпается с мыслью: хочу быть тимлидом. Ну или нет. Но если вас эта мысль все-таки посетила... А оно вам надо?

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

Привет, Хабр! На связи Владимир Сыропятов, Senior Analyst в Garage Eight. Я несколько лет занимаюсь антифродом, и за это время научился строить модели, писать SQL в три часа ночи при инцидентах и читать паттерны там, где другие видят шум. Но об одном навыке мне никто не сказал. Ни на одном курсе, ни в одной книге. Именно поэтому пришлось наступать на грабли — дорогие грабли — и прокачивать его самому.

Речь о коммуникации с требовательными стейкхолдерами в условиях неопределенности.

Несколько лет назад мы иронизировали над «имитацией работы», когда рынки росли, а бюджеты казались бесконечными. Сегодня индустрию лихорадит от оптимизаций, но парадокс в том, что корпоративная мимикрия никуда не делась.

Назовем это явление «бюрократический атлетизм» и попробуем разобраться, чем он отличается от soft skills, корпоративной этики и обычной профессиональной сдержанности.

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

«Атлет» выбирает тактику минимального взаимодействия, где главная цель — сделать так, чтобы от него отстали, сохранив при этом статус незаменимого винтика в системе.

Беда в том, что у руководства к нему вопросов нет, он рисует безупречные отчеты. Но в индустрии, где все держится на работающем коде, избыточная вежливость в ответ на непрофессионализм — это не воспитание, а соучастие в саботаже. 

Расскажем, как открытый API Kaiten позволил металлообрабатывающему заводу ПФ-ФОРУМ интегрировать ChatGPT и сократить время на постановку задач

Рынок труда переживает фундаментальные изменения, и старые подходы к поиску работы и карьерному развитию больше не работают. Сопротивление бесполезно – пора принять новые нормы. В этой статье мы разберем 4 ключевые тенденции, которые определяют современную карьеру: от изменившихся сроков трудоустройства и концепции портфельной карьеры до быстрых увольнений и важности психологической устойчивости. Узнайте, как адаптироваться к этим вызовам и использовать их как возможности.

Когда RuStore только запускался, мы строили дизайн на основе UI-кита от VK — удобно, практично, а главное помогло нам быстро вывести продукт на рынок. Но стор рос, интерфейсов становилось больше, дизайнеры — смелее, а требования — сложнее. И вот настал день, когда мы решили добавить тёмную тему. И всё сломалось. 

Именно тёмная тема вскрыла нашу главную проблему — ранняя структура цветовых токенов не готова к масштабируемости. Любое изменение запускало каскад правок и ломало синхронизацию между макетами и кодом. 

Под катом мы — Элина Шевченко, продуктовый дизайнер RuStore, и frontend-разработчик Андрей Едунов — расскажем историю, как мы полностью перестроили систему, не останавливая разработку, аккуратно вынесли всё из Figma в код и почему теперь можем масштабировать дизайн без драмы, даже если завтра понадобится не только тёмная тема, но и ностальгия по 2008-му, где primary — это чистый #000000, а secondary — оттенок тоски.

Делюсь разговором с AI/ML-командой Группы Т-Технологии. Это — Анатолий Потапов @anatolii-potapov, который руководит группой фундаментальных технологий LLM, и Даниил Гаврилов, возглавляющий исследования в AI. Получился подробный разбор того, чем занимается AI/ML-команда и Группа в целом в рамках данного направления.

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

Я думаю, что сейчас — именно такой момент для маркетинга.

Хотя маркетологи любят рассуждать про рынок и потребности, но мы сами не готовы препарировать нашу специализацию в этих терминах. А кто наш потребитель?

Давай честно, целевая аудитория маркетолога: 1. акционер, генеральный директор (CEO), 2. рынок. И если с CEO — все понятно, то про рынок не так очевидно. Важно понимать, что маркетинг — всегда такой, который нужен текущему состоянию рынка.

Состояние маркетинга прямо коррелирует с состоянием рынка.

Предмет моего размышления — это не критика маркетологов, а анализ причин, приведших к текущему состоянию профессии, а также прогноз ее будущего.

Дисклеймер: Я понимаю, что маркетинг — это объемное направление, по‑разному раскрывающееся в сегментах, отраслях, размерах, и осознанно обобщил информацию.

В сводной Таблице 1 вскрыт системный разрыв между запросами бизнеса и реальными действиями маркетинга: если в 2000-е маркетинг отвечал за продукт и прибыль, то к 2025 году он свёлся к генерации «вайба» для уставшего CEO, утратив связь с финансами, производством и долгосрочной стратегией.

Статья написана на основе интервью с Юлией Устимовой, владелицей цветочной студии Лесроз в Нижнем Новгороде

Я закончила Строительный университет с красным дипломом в 2013, пять лет проработала по специальности, а потом ушла в цветы.

Любовь к цветам у меня была, наверно, с рождения. В детстве я играла в цветочный магазин — собирала букетики в саду, раскладывала, продавала воображаемым покупателям. Это было так давно, что я почти забыла. Но трепет к цветам не исчезал никогда и в какой-то момент поняла: если никогда не попробую работать с цветами, буду жалеть всю жизнь.

У продуктовых дизайнеров есть странная ловушка: индустрия производит огромное количество контента про рост в профессии, но сам рост от этого почти не происходит. Можно годами смотреть референсы, читать разборы и ходить по курсам — а потом все равно теряться в работе с живым продуктом, где есть ограничения, метрики, конфликты и цена ошибки. 

Я это видел много раз — и в студии, и в больших командах. Поэтому ниже не советы в духе «потрать 10 000 часов», а разбор того, что реально ускоряет рост и почему стандартные пути часто тормозят и не помогают.

Разработчик уволился. Через полгода появился похожий продукт, бывший сотрудник открыл ИП и зарегистрировал программу на себя. Или команда ушла к конкуренту и унесла кодовую базу. Или компания вложила несколько миллионов в разработку, а в суде выяснилось, что доказать принадлежность кода некому.

Такие истории заканчиваются не быстро. Судебные разбирательства по правам на ПО, это от года до трёх лет, экспертизы исходных кодов, пяти- и шестизначные суммы судебных расходов. Итог зависит от того, что компания успела сделать до конфликта, а не после.

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

Поэтому три компромисса закладываются в дизайн исследования задолго до старта поля:

Сегодня поговорим о том, почему No-code в крупном бизнесе — это не волшебная палочка, а мощный инструмент, который без жесткой архитектурной дисциплины превращается в фиаско.

Меня зовут [неважно], я бизнес-аналитик. Моя работа — писать ТЗ, рисовать процессы в BPMN, ругаться с разработчиками из-за неправильно понятых требований и пить кофе на стендапах. За 5 лет в профессии я не написал ни одной строчки кода. Ни одной. Даже Hello World.

В начале 2026-го я поймал себя на мысли, которая наверняка посещала каждого бизнес-аналитика: «Я точно знаю, что нужно сделать. Я подробно описываю как это должно работать. Единственное, чего я не могу — написать код». А потом я прочитал очередной пост про то, как кто-то с помощью ИИ создал приложение за выходные, и подумал: а что если моя профессия — это и есть идеальная подготовка к работе с ИИ-ассистентами?

Спойлер: через 2 недели у меня было 2 приложения в RuStore, 0 рублей затрат и 14 скачиваний. Да, четырнадцать. Но обо всём по порядку.