Обновить
256K+

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

Учимся управлять продуктом

451,83
Рейтинг
Сначала показывать
Порог рейтинга

Картонный короб едет от теплицы до магазина один раз. Пластиковый ящик ездит по кругу и в пересчёте на рейс выходит дешевле, но овощи всё равно возят в картоне.

Поговорил со Степаном Грабиновым, бизнес-аналитиком Цифрового СИБУРа. Полгода он с командой разбирался, как устроено производство тепличных помидоров и огурцов и где там можно применять полимеры. Вот что рассказал:

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

Контактов в промышленном овощеводстве у нас не было, поэтому звонили вхолодную и писали на общие почты. Один раз попали на пост охраны, и охранник не мог понять, чего мы хотим и при чём тут какие-то ящики. Через несколько недель дозвонились до логиста одного из крупнейших производителей.

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

Отгрузка в картонном коробе в один конец стоит 30–40 рублей, а рейс полимерного ящика в пулинге обходится на 30–40% дешевле.

Провал на предзащите

С этой экономикой мы пошли на предзащиту. Директор дивизиона сказал:

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

Переделать подход надо было за месяц.

Почему теплицы стеклянные, а рассада в матах

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

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

Что нашлось в тендерах

В нейросетях мы ничего толком не нашли, зато процесс восстановили по тендерам предприятия.

В тендере на клипсы, которыми фиксируют кисти и побеги, посекундно расписана норма агронома: сколько штук он должен прикрепить за единицу времени. Если клипса медленнее защёлкивается или выскальзывает, агроном не выполняет норму, а следом и весь участок. Отлить пластиковую клипсу несложно. 

Сделать такую, которая защёлкивается за нужное время и не ломается, — это инженерная задача.

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

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

Вернулись к ящикам

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

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

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

Подписывайтесь на наш тг-канал. Он полезен айтишникам, которые хотят понять, что реально происходит в промышленном ИТ.

Теги:
+1
Комментарии2

Про нестандартные решения и продуктовых инженеров

Мы тут обсуждаем в наших командах, как строить разработку в новых условиях и возможностях. Так чтобы это и не вайбкодинг, но и не эджайл по-советски. Понятно, что сквозная агентная инженерия, спеки, харнесс, подписки, все дела... Но пока продакт и инженер-билдер это не один человек, проблемы в коммуникации и сквозных бизнес-процессах неизбежны. Это просто как преамбула.

***

Думаю, вы понимаете, что в одиночку единорога уже можно конечно пробовать, но пока это скорее ошибка выжившего, как и в целом с успехом. Как правильно -- все знают. В теории.

Так вот, мы по-прежнему командами работаем. Небольшими командами. Может быть расскажу как-нибудь об этом подробнее.

Но сегодня о другом.

Обновили и утвердили очередную методологию процесса разработки. В моменте все счастливы. Но вы думаете она нас сделает успешными? Ну нет конечно.

Успешными людей и компании делают нестандартные решения.

И что интересно, способность принимать такие решения часто возникает с двух противоположных концов опыта.

Либо вы дурак или новичок, что в данном случае практически равноценно, и просто еще не знаете, что так нельзя.

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

Все, кто посередине, обычно лучше всех знают, как правильно

Давайте признаемся, что мы все плюс-минус посередине. Поэтому рассчитывать на спасительное незнание правил или гениальность огромного опыта нам не приходится. Придется включать голову и сознательно учиться делать иначе.

И вот тут начинается самое интересное. Можно сколько угодно улучшать спеки, чистить контекст и описывать процесс, но в реальной разработке инженер все равно постоянно будет сталкиваться с противоречиями, пропущенными сценариями, решениями, которые на бумаге выглядели разумно, а в коде внезапно перестали быть таковыми.

И в этот момент у него есть два варианта. Непрерывно итерировать в агентских циклах строго по PRD и дельтам или глубоко понимать что и для кого он делает, чтобы самому, или совместно с продактом, принимать нестандартные решения там, где закончилась спецификация, а продукт еще не случился.

Решил об этом не в командных чатах, а с трибуны, как Владимир Ильич. Может кому тоже полезно будет. 

Неотправленный пост моим командам:

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

Методология для нас по сути побочный продукт накопленного опыта. Она должна помогать нам двигаться быстрее и совершать меньше повторяющихся ошибок.

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

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

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

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

Так что продуктовый контекст и методология не должны заменять мышление.

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

Другими словами, включает голову, по полной.

Теги:
+1
Комментарии0

В Tencent представили открытый проект BrowserSkill, который подключает ИИ‑агентов к актуальному пользовательскому браузеру со всеми доступами и аккаунтами:

  • обычно ИИ получает «чистый» браузер, а все доступы и входы нужно предоставлять отдельно;

  • сервис BrowserSkill позволяет Codex, Claude Code, Cursor, Hermes и другим агентам работать на сайтах, где пользователь уже авторизован;

  • при этом ИИ‑агент действует в отдельном окне. Если ему нужна открытая рабочая вкладка, то он запросит разрешение. Все капчи и окна подтверждения также передаются пользователю, а затем работа продолжается;

  • работает с любым агентом, выполняющим команды в терминале;

  • поддерживает Windows, macOS, Linux.

Теги:
+2
Комментарии0

SimpleOne WTM 1.4.0: регулярные карточки трудозатрат избавят от рутины при заполнении табеля

В новой версии инструмента управления временем и трудозатратами (WTM) появилась функциональность регулярных карточек трудозатрат — теперь повторяющиеся активности не нужно каждый раз вносить в табель вручную.

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

Настройки в любой момент можно изменить или отменить повторение через меню карточки в табеле.

Теги:
0
Комментарии0

Цифровая трансформация

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

Актуальный свод знаний по бизнес процессам (CBOK 4) дает три разных определения термина:

1. The Enterprise Project: “Цифровая трансформация — это интеграция цифровых технологий со всеми составляющими бизнеса, коренным образом меняющая то, как бизнес организован и как он создает ценность для потребителей.”

Это прям идеальный пример основания для волшебного мышления, мол “а давайте всё покрасим в коричневый и тогда у нас всё получится!” Что… почему… как это будет работать и за счет чего принесет пользу - вообще не понятно - просто красивый лозунг. Более того тут и зло закопано в виде не универсальности, т.к. не для абсолютно любой ситуации это применимо так, чтобы обязательно стало лучше.

2.… второе определение от George Westerman - даже приводить не буду… там одна сплошная эмоция без каких-либо оснований

3. Salesforce: “Цифровая трансформация — это процесс использования цифровых технологий для создания новых или изменения существующих бизнес-процессов, культуры, клиентского опыта в ответ на меняющиеся требования бизнеса и рынка.”

Из трех - это самое вменяемое определение, хотя оно лишь констатирует факт происходящего и не дает понимания о том, в чём же суть пользы.

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

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

Если всю эту сложность мы свяжем через интернет и будем автоматически переводить на английский - эффективность работы очевидно и радикально возрастет!

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

Получается, что цифровая трансформация - это переход на единый протокол взаимодействия всех элементов рабочей системы… как разнокалиберные шестеренки смазать правильным маслом.

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

И для всего этого вовсе не обязательно менять всю бизнес модель.

Теги:
+1
Комментарии0

Пользователь настраивал систему потокового видеовещания OBS Studio с помощью GPT-6 Astra, но в какой‑то момент отвлёкся и перестал отвечать нейросети. ИИ посмотрела на него через камеру и зафиксировала, что человек не обращает на неё внимания и смотрит куда‑то вниз. В этом случае нейросеть сама включила звук на Mac и привлекла внимание пользователя для продолжения работы с ИИ.

Теги:
+1
Комментарии2

Вышел подробное руководство по GPT-6 Astra — разработчики из OpenAI показали, как работать с нейросетью наиболее продуктивно. Astra работает иначе, чем другие модели, поэтому обычные промпты ей не подойдут. Также опубликован запрос, который позволяет проверить GPT-6 по гайду.

"На основе статьи ниже проверь AGENTS.md и Skills на настройки, которые могут приводить к лишней работе, конфликтам инструкций или ненужным ожиданиям. Объясни причины и предложи минимальные изменения: https://developers.openai.com/blog/rethinking-skills-and-prompts-for-gpt-6-astra".

Теги:
0
Комментарии0

Прощай vibe coding. Здравствуй deep crafting

Андрей Бадин, основатель Product Lab, придумал название для подхода к работе с ИИ, которым занимался уже давно.

Он назвал его дипкрафтингом (deep crafting).

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

Андрей Бадин тоже экспериментировал с вайбкодингом, но понял, что его интересует другое.

Сначала он называл этот подход vibe creation, или вайб-творчеством, но название не прижилось.

Вайбкодинг, по определению Андрея Карпатого — это способ программирования, где человек может отдать часть работы ИИ и не разбираться в каждой детали. Для небольших проектов и быстрых экспериментов такой подход работает.

Но дипкрафтинг устроен иначе.

Если давать определение, то дипкрафтинг – это создание нового вместе с ИИ, в котором роли между человеком и моделью разведены и не смешиваются.

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

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

Само слово собрано из двух частей, и каждая отвечает за свою половину процесса. Deep – это про то, как глубоко ты разбираешь предмет, до самых его оснований. Craft – это про то, как ты собираешь его обратно, и здесь важно, что речь идет о ручной работе, а не о сборке из готовых блоков: ты снимаешь все лишнее до тех пор, пока не останется только то, что держит форму. По-русски все вместе и получается глубокое создание. За время практики схема сложилась в четыре режима.

1. Мета-уровень

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

2. Первоосновы

На этом этапе никакая методология не принимается как данность.Будь то JTBD, ТРИЗ или другой подход, задача — понять, на чем он действительно основан.ИИ помогает искать исследования и источники, но все приходится перепроверять: модель может ошибаться, придумывать ссылки и делать неверные выводы.После разбора до базовых элементов становится видно, что является основой, а что только внешней оболочкой.

3. Новая система

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

4. Методология

Последний этап — сделать новую систему понятной для других.

Для этого нужны простые формулировки, структура и новые слова. Здесь ИИ помогает искать варианты упрощения и упаковки, но окончательное решение остается за человеком.

Андрей Бадин пришел к этой идее во время работы над книгой, выпуск которой постоянно откладывает. Причина в том, что он сам занимается дипкрафтингом: разрабатывает новую методологию создания продуктов в эпоху ИИ.

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

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

Сегодня часть этой работы можно ускорить до недель или даже дней.

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

Теги:
+1
Комментарии6

Летний ТехФест 2026: главные итоги

Мы объехали офисы партнёров, встретились с коллегами и обсудили самое актуальное: AI в разработке, продуктовые циклы, управление изменениями и не только. На практических сессиях разбирали реальные кейсы, а на дискуссиях искали ответы на сложные вопросы.

Собрали цифры нашего фестиваля, чтобы показать масштаб:

  • 5 площадок

  • 5 компаний организаторов

  • Более 600 участников

  • 10 докладов от экспертов отрасли

  • 3 активности — мастермайнд, круглый стол и практикум с живыми кейсами

  • 12 экспертов и спикеров

  • 5 кейсов решено на практикуме по инженерной оптимизации.

Отдельное спасибо организаторам — вы сделали эту неделю незабываемой. Увидимся в следующем году!

Финальный день: как это было.

Ещё больше о мероприятиях — в нашем TG-канале.

Теги:
0
Комментарии0

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

Очередная типа умная инфографика
Очередная типа умная инфографика

Что мешает сюда включить еще два пункта “Красный” и “Кислый”? А двух крокодилов, которые один зеленый, а другой на север?

Или любое из других красивых слов, типа “Цели”, “Мотивация”, “Системы”, “Согласованность”…

Мой любимые вопросы:

  1. а это десять из скольких возможных?

  2. а почему именно десять?

Переводя разговор в практическое русло - приведенная схема, как и тысячи подобных - пытаются сделать черных лебедей в черном ящике белыми, ручными и предсказуемыми. Но когда нет понимания о составе скотного двора внутри объема остается только наугад выхватывать красивые слова и красиво их оформлять в виде красивой инфографики.

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

Теги:
+1
Комментарии5

Как «Страна Девелопмент» перевела всю ИТ‑инфраструктуру в облако и ускорила проектирование

🏭Что за компания
«Страна Девелопмент» — федеральный девелопер с 17‑летним опытом, который строит жилую и коммерческую недвижимость в Тюмени, Екатеринбурге, Новосибирске, Санкт‑Петербурге, Москве и Подмосковье. Компания закрывает полный цикл — проектирование, строительные и подрядные работы, технический надзор, продажи, гарантийное обслуживание и управление недвижимостью. Параллельно с этим компания разрабатывает собственные отраслевые ИТ‑продукты.

⚡ Задача
Инфраструктура была разделена между собственными физическими серверами и облаком сторонней площадки, где не хватало ни запаса ресурсов, ни набора сервисов, ни нормальной поддержки контейнеризации. Отдельной проблемой были рабочие места проектировщиков: на видеокартах T4 крупные BIM‑модели приводили к «черному экрану», результаты работы терялись, схемы прорисовывались медленно. Бизнес требовал не менее 50 новых удаленных рабочих мест в месяц, но скорость проектирования падала из-за медленной коммуникации (сотрудники были разбросаны по разным городам) и нехватки компьютеров.

☁️ Что сделали
Сначала девелопер протестировал платформы Облако VMware и Cloud.ru Advanced, построил сетевой канал до дата‑центра и примерно за два месяца ушел с локальных серверов и от прежнего провайдера. Потом в виртуальный ЦОД переехали standalone‑приложения, 1С и внутренние продукты — со временем это выросло до 120 серверов, с резервным копированием и объектным хранилищем S3. Разработку вынесли на Cloud.ru Advanced: сервис контроля качества и сроков работы подрядчиков собрали на Cloud Container Engine (Kubernetes), пропускную способность обеспечили распределенным брокером сообщений Kafka, туда же перенесли корпоративный портал и подключили защиту от DDoS. После развернули VDI с GPU под проектировщиков: 18‑ядерные процессоры от 3 ГГц, карты A40, высокочастотная DDR4 и сертифицированные инженеры VMware на стороне провайдера обеспечили удобство работы и высокую скорость миграции. Первые 200 рабочих мест из 600 запланированных настроили уже за первые две недели, при плане рассчитанном на два месяца.

🦾 Что получили в итоге
Вся ИТ‑инфраструктура девелопера теперь работает в облаке Cloud.ru. Оно держит растущую нагрузку и остается отказоустойчивым, SLA и обслуживание оборудования перешли к провайдеру: внутренняя команда больше не тратит время на железо и обновления. Cloud.ru Advanced стал платформой для новых продуктов компании, часть из которых регистрируется в реестре отечественного ПО Минцифры. Сейчас девелопер арендует 850 виртуальных рабочих мест с A40: архитекторы со всех уголков страны работают в единой инфраструктуре и подключаются к моделям прямо на Revit‑серверах, не выкачивая их на локальные машины. Производительность специалистов выросла на 30%, что дает до десяти дополнительных объектов в проектировании за год, а гибкая тарификация снизила расходы на инфраструктуру. Дальше в планах — Managed Arenadata DB для задач big data, пилот платформы Cloud.ru Evolution и новые типы виртуальных рабочих мест, в том числе сессионные.

Читайте подробнее на сайте.

Теги:
0
Комментарии0

Как собрать ИИ-агента под свои рабочие задачи — тренинг от Практикума

Подойдёт руководителям, предпринимателям и всем, кто работает с информацией. Не нужны навыки программирования или опыт в IT.

В программе — теория и много практики:

  • Разберётесь в ИИ-агентах. Узнаете, чем они отличаются от чат-ботов и как работают автономные цепочки действий.

  • Поработаете с промптами. Научитесь формулировать эффективные запросы и управлять поведением ИИ с помощью инструкций, контекста и примеров.

  • Создадите базу знаний. Соберёте ИИ-помощника, который знает внутренние документы компании и отвечает на вопросы по ним.

  • Соберёте собственного ИИ-агента. Настроите его под свою профессиональную задачу, подключите документы или базу знаний и протестируете работу.

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

Тренинг проведёт Евгений Паточенко — академический руководитель магистерской программы «Аналитика больших данных» НИУ ВШЭ. Более 15 лет внедряет бизнес-приложения в крупнейших российских и международных компаниях, специализируется на применении ИИ в бизнесе.

Тренинг пройдёт онлайн и займёт около 5 часов с двумя перерывами по 20 минут. Во время обучения можно задавать вопросы эксперту в чате. Платные подписки на ИИ-инструменты не нужны — для практики можно использовать бесплатные.

→ Записаться на тренинг

Теги:
+1
Комментарии0

Ближайшие события

Пост выходного дня посвящу не столько профессиональным делам, сколько хобби)

Я занимаюсь фехтованием (HEMA, рапира) - и перед соревнованиями мы проводим спарринги по всем правилам, с таймером и подсчётом очков. Ещё в прошлом году я решил упростить работу судьи, собрал в Lovable простое одноэкранное веб-приложение, и испытал его на ближайшей же тренировке.

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

К счётчику очков/таймеру добавились:

  • ростер бойцов (уже на отдельном бэкенде);

  • хранение истории боёв;

  • статистика.

То есть вырос уже MVP для небольших клубов. И на этом я не останавливаюсь, планов ещё много)

Если меня вдруг читают фехтовальщики (а может и не только) - предлагаю оценить результат самостоятельно, поделиться с друзьями и накидать обратной связи (любая будет ценной!)

https://fencing-scorer.konbo.me 

Это по-прежнему веб-приложение, не требует установки. Но свёрстано сразу под телефоны, чтобы было всегда под рукой. Чтобы просто считать очки в спаррингах регистрация не требуется (она нужна только для истории и статистики) - можно просто нажать на "Быстрый бой" внизу.

Теги:
+3
Комментарии0

Как мы систематизировали анализ конкурентов

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

Пока команда занята своими задачами, у других игроков появляются новые функции и меняется фокус. Поэтому в Naumen Erudite решили дополнить разовые исследования регулярным мониторингом.

Как устроен процесс и что он изменил, рассказала Таня, продуктовый аналитик Naumen Erudite.

1️⃣ Зачем продуктовым аналитикам следить за конкурентами?

Для нас здесь три основные цели:

  1. Понимать, где находится наш продукт на рынке — какие тренды актуальны, в чем мы сильнее, а где есть точки для развития.

  2. Развивать насмотренность — чем больше решений видишь, тем проще находить идеи для развития своего продукта.

  3. Делиться информацией с командой — данные о конкурентах нужны не только аналитикам, но и руководителю продукта, пресейлам и проектным командам.

2️⃣ Почему решили менять прежний подход?

Информация о конкурентах хранилась в разных источниках — Google-таблицах, Jira, Miro, Confluence. Поэтому не всегда было понятно, где искать нужные данные и насколько они актуальны.

В таблице накопилось больше 50 компаний, которые мы анализировали и за которыми хотим следить. Ориентироваться в таком объеме становилось все сложнее.

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

3️⃣ Как удалось собрать все в систему?

Выбрали Miro как единую базу знаний: там храним краткую информацию о конкурентах, роадмап анализа и ссылки на подробные материалы — кейсы, проекты, скриншоты, презентации и видео с мистери-шоппинга.

В Miro сравниваем конкурентов по выручке, формату работы продукта и наличию функций. За подробностями можно перейти в Confluence, на сайт или в документацию компании.

4️⃣ Как сделали анализ регулярным?

Добавили повторяющиеся задачи: раз в две недели смотрим рассылки, Telegram-каналы и обновления продуктов, а раз в полгода пересматриваем роадмап анализа.

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

Мистери-шоппинг проводим, когда открытых источников недостаточно.

5️⃣ Почему недостаточно пересматривать всех конкурентов раз в год или два?

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

Регулярный мониторинг помогает замечать такие изменения раньше и экономить время. Если нужно изучить конкретную функциональность, мы уже примерно знаем, у кого она есть, и можем смотреть решения прицельно.

6️⃣ Как понять, кого анализировать в первую очередь?

Разделили конкурентов на четыре группы по степени влияния: высокий, средний и низкий уровень, а также косвенные конкуренты.

Для сравнения определили критерии: финансовую динамику, формат работы продукта — в облаке или инфраструктуре клиента — и наличие функций на базе LLM. Так проще ориентироваться среди 50+ компаний и выбирать, кого изучать подробнее.

7️⃣ Какие инструменты помогают следить за изменениями?

Для десяти ключевых конкурентов настроили Google Alerts — раз в неделю получаем подборку новостей о них. Еще подписались на Telegram-каналы и рассылки компаний, а раз в две недели выделяем час на просмотр источников.

8️⃣ Что изменилось после перестройки процесса?

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

Процесс продолжаем развивать. Сейчас тестируем автоматизацию анализа с помощью LLM: например, используем Claude для поиска информации в открытых источниках и ее систематизации в таблицах, которые раньше заполняли вручную.

Теги:
+2
Комментарии1

Почему мои оценки сроков всегда ошибались в одну сторону

Долго не мог понять один паттерн. Задачу оцениваю в три дня - выходит пять. Оцениваю в неделю - выходит две. Причём не случайно, а стабильно в одну сторону. Всегда дольше, никогда быстрее.

Потом разобрался. Дело не в том что я плохо оцениваю конкретную задачу. Дело в том что я оцениваю задачу в вакууме - без учёта всего остального что происходит параллельно.

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

Это называется ошибка планирования. Мозг фокусируется на сценарии где всё идёт по плану. Реальность всегда добавляет помехи которые в оценку не попали.

Два способа которые реально помогли.

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

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

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

Как вы решаете проблему с оценкой сроков - нашли что-то что работает лучше?

Теги:
+5
Комментарии2

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

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

Очень серьезные чечки бегают с большими молотками. Стартаперы — с креативным нечто «похожим на».

Есть ощущение — что нужная вещь! Кто‑то хвастается удачными попаданиями.

Умники уже даже занимаются улучшением молотка — то ручку длиннее сделают, то в новый цвет покрасят.

Вот только… гвоздей пока нет…

Такое ощущение :)

Теги:
+19
Комментарии5

Друзья!

Перед вами моя новая фантастическая повесть «Королев ИИ»: инженеры нооэры», которая родилась не на пустом месте. Она выросла из моей многолетней работы в сфере информационных технологий и бесценного опыта, который я получил во время работы над созданием Центра разработки и внедрения сильного и прикладного искусственного интеллекта МГТУ им. Н.Э. Баумана в 2021 году[1], а также из опыта работы над проектом создания научно-образовательной платформы «Королев ИИ».

Эта повесть выходит в преддверии важного события. В сентябре 2026 года в МГТУ им. Н.Э. Баумана стартует полноценное использование научно-образовательной платформы «Королев ИИ» для всех сотрудников, преподавателей и студентов. По нашей задумке, платформа должна стать, в некотором смысле, «фундаментом» нашего университета, в рамках реализации концепции «Университет 4.0» и будущей концепции, которую мы назвали «Нейроуниверситет» (над которой мы уже работаем). Сейчас, у нас большой потенциал и задел по ноу-хау, новым задачам и новым ИИ-сервисам для университета, по научным открытиям и публикациям полученных результатов, которые мы планируем реализовать в ближайшее время.  И, — это только начало.

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

Эта повесть — моё приглашение к размышлению. К размышлению о сегодняшнем дне и о будущем нашей цивилизации.

Я посвящаю ее студентам и молодым учёным, изобретателям и энтузиастам. Я посвящаю ее сегодняшним людям завтрашнего дня. Тем, кто не боится мечтать и воплощать мечты в жизнь. Тем, кто своими руками, своим умом и своим упорством создаёт будущее.

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

2126 год начинается 1 сентября 2026 года.

Ваш Александр Чесалов.

Теги:
+6
Комментарии0

Почему коммерческие инициативы застревали между функциями

У каждой функции был собственный план. Команды были заняты, задачи двигались. И всё же коммерческие инициативы застревали между ними.

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

В такой ситуации легко добавить Scrum: новые роли, встречи, доску. Мы начали с менее эффектных вопросов. Кто имеет право поставить задачу в общий поток? Где определяется приоритет, если интересы функций расходятся? Сколько работы система вообще способна нести одновременно? Кто принимает компромиссное решение?

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

Время вывода инициатив сократилось примерно вдвое. Затем отдельная работа с узкими местами дала ещё около 20% ускорения. Предсказуемость выхода достигла 99%, объём незавершённой работы снизился на 40%.

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

С тех пор, когда каждая команда выполняет свой план, а клиент всё ещё ждёт, я смотрю не на дисциплину отдельных команд. Я ищу место, где между ними перестало приниматься решение.

Если узнаёте такую ситуацию, напишите «поток». Отправлю короткую диагностику из 10 вопросов: она помогает увидеть, где система теряет скорость, маржу и ответственность.

Теги:
+3
Комментарии0

12 открытых уроков для руководителей: команда, проекты, стратегия и ИИ

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

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

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

Управление командой

  • 9 сентября, 20:00. «Как тимлиду распределять ответственность и не становиться узким местом команды». Записаться

  • 16 сентября, 20:00. «Диагностика команды: как выявить проблемы до того, как они повлияют на результат». Записаться

  • 16 сентября, 20:00. «Сложные разговоры в команде: как давать обратную связь без эскалации». Записаться

Стратегия и развитие руководителя

  • 8 сентября, 20:00. «От технического лидера к CTO: как начать принимать решения на уровне бизнеса». Записаться

  • 22 сентября, 20:00. «Метрики CTO: показатели, которые действительно нужно контролировать». Записаться

Управление проектами и процессами

  • 1 сентября, 20:00. «Практическое применение нейросетей для моделирования процессов». Записаться

  • 14 сентября, 19:00. «Анти‑паттерны управления: Почему „помощь“ заказчиков убивает проекты и как вернуть контроль». Записаться

  • 17 сентября, 20:00. «Событийные подпроцессы в BPMN 2.0: как моделировать процессы, реагирующие на события». Записаться

  • 23 сентября, 20:00. «Как системному аналитику проводить архитектурное ревью и находить риски до начала разработки». Записаться

ИИ для руководителя

  • 3 сентября, 20:00. «Как руководителю внедрить ИИ в работу команды: от выбора процесса до рабочего сценария». Записаться

  • 21 сентября, 20:00. «Один рабочий день с ИИ: от писем и таблиц до готовой презентации для руководителя». Записаться

  • 24 сентября, 20:00. «PM + ИИ: собираем статус‑отчёт, реестр рисков и прогноз сроков за 40 минут». Записаться

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

ЧТО ПОЧИТАТЬ

Если хотите глубже разобраться в управлении командами, процессами и собственной управленческой траекторией, собрали ещё несколько материалов из блога:

Больше открытых уроков и практических занятий собрали в дайджесте.

Теги:
+6
Комментарии0
1
23 ...