Продуктовое мышление / от ProductSense

Не обязательно ждать конференцию, чтобы оставаться в контексте развития менеджмента продуктов Развитие компетенций не стоит делать рывками: иногда больше дают маленькие регулярные шаги — посмотреть один доклад, сделать один разбор кейса, изучить одну статью и сразу применить знания в рабоче проекте. Каждый год команда ProductSense тщательно отбирает экспертов и актуальные темы для своих конференций, но на протяжении года мы также хотим оставаться с вами на связи. И можем делать это с помощью нашей обновленной Академии — через микрокурсы, эфиры, записи, подборки и материалы, к которым удобно возвращаться. Академия ProductSense — это способ встроить профессиональное развитие в обычную неделю и регулярно возвращаться к темам, которые важны именно сейчас: в продукте, управлении, стратегии, исследованиях, метриках, процессах и работе с командами. На платформе есть выступления, микрокурсы, эфиры и подборки — 800+ материалов от продуктовых экспертов. Есть несколько форматов подписки: 1️⃣ Академия ProductSense с конференцией Для тех, кто хочет совместить годовой доступ к Академии с очным участием в одной конференции ProductSense или PeopleSense по билету «Лично: Программа». 39 900 руб. в год 2️⃣ Академия ProductSense с эфирами Для тех, кто хочет не только изучать материалы, но и смотреть онлайн-эфиры конференций ProductSense и PeopleSense в течение года. 19 900 руб. в год 3️⃣ Академия ProductSense Для тех, кто хочет смотреть записи, микрокурсы, вебинары, подборки и практические материалы в удобное время. 12 900 руб. в год Так можно не ждать следующего большого события, а начать спокойнее: выбрать тему, посмотреть доклад, забрать одну идею и вернуться к материалам через неделю. Подробности о форматах подписки можно изучить на сайте. @productmindset

Сделали конференцию ProductSense’26 доступнее! Мы запустили новый формат — «Академия ProductSense с конференцией». Это более доступный способ приехать на конференцию очно, попасть на программу и нетворкинг, а после — возвращаться к эфирам, записям, микрокурсам и материалам Академии в течение года. Как это работает: вы получаете годовой доступ к Академии ProductSense и очное участие в одной конференции ProductSense или PeopleSense по билету «Лично: Программа». В формат входит: — очное участие в одной конференции ProductSense или PeopleSense; — доступ к программе, нетворкингу и кофе-брейкам на площадке; — онлайн-эфиры конференций ProductSense / PeopleSense в течение года; — записи докладов и мастер-классов после публикации; — микрокурсы, вебинары, подборки и практические материалы Академии. Это формат для тех, кто хочет быть на конференции лично: слушать доклады, участвовать в обсуждениях, знакомиться с участниками и спикерами, — но не брать полный офлайн-пакет с обедами и вечерней частью. Для сравнения, сейчас есть несколько вариантов участия офлайн: «Лично» — полный офлайн-формат с программой, питанием и вечерней частью. Сейчас: 59 000 ₽ С 1 июля: 65 000 ₽ «Лично: Программа» — очное участие в программе и нетворкинге без обедов и вечеринки (кофе-брейки входят в программу). Сейчас: 47 000 ₽ С 1 июля: 53 000 ₽ «Академия ProductSense с конференцией» — годовой доступ к Академии и очное участие в одной конференции по формату «Лично: Программа». 39 900 ₽ в год Если вам важно не просто приехать на два дня, а регулярно возвращаться к опыту индустрии, смотреть эфиры, разбирать доклады и забирать практики в работу, новый формат с Академией может быть самым удобным способом сделать это и достичь ваших целей. О том, как работает сама Академия, мы расскажем в наших следующих постах. А больше информации о билетах, участии для команд и предстоящей конференции ProductSense'26 — уже на нашем сайте. @productmindset

Вас не должны повышать до Senior Повышение — это не награда за то, что вы давно работаете и хорошо закрываете задачи. Чтобы его получить, нужно показать руководителю и команде, что вы правда выросли: через зоны ответственности, принятые решения, уровень влияния и результаты. Senior-менеджер продуктов — это сотрудник, которому можно отдать неоднозначную область и ожидать, что он сам разберется: где проблема, какой в ней скрыт бизнес-смысл, кого нужно вовлечь, от чего отказаться и как довести решение до результата. Разберем разницу между Middle- и Senior-менеджером продуктов на нескольких примерах. Выход из «сделать фичу хорошо» в «принести явную ценность бизнесу» Представим, что команда делает новый экран онбординга. Middle-менеджер продуктов соберет требования, согласует макеты, проследит за разработкой, протестирует сценарии и доведет экран до релиза. Senior-менеджер продуктов посмотрит на задачу еще шире: разберется, какую проблему решает онбординг, где пользователи отваливаются, как это влияет на активацию и какой результат команда ожидает после запуска. Middle чаще отвечает за корректный запуск решения. Senior — за то, чтобы решение изменило нужную метрику. Бизнес-оптика Допустим, пользователи жалуются на сложную форму заявки. Middle-менеджер продуктов может сформулировать это как UX-проблему: «Форма неудобная, нужно упростить поля и сделать интерфейс понятнее». Senior-менеджер продуктов разложит проблему детальнее: «На этом шаге мы теряем 30% заявок. Часть пользователей уходит, часть пишет в поддержку, часть оформляет заявку вручную через менеджера. Это влияет на конверсию, нагрузку на операционную команду и стоимость обработки заявки. Поэтому нужно изменить весь путь подачи заявки». Дальше меняется и способ обсуждения: «Если мы упростим этот шаг, то можем увеличить конверсию в оплату, снизить количество обращений в поддержку и уменьшить ручную обработку. Полчается, что задача не только на изменение формы, но и на повышение конверсии на всех шагах воронки». Senior связывает пользовательскую боль с бизнес-результатом. Именно эту связь должен видеть руководитель. Влияние без полномочий Представим, что команда разработки не хочет брать задачу в спринт: есть техдолг, архитектурный риск и уже забитый план. Middle-менеджер продуктов приходит с аргументом: «Задача важная, она стоит в роадмапе, бизнес ждет запуск». Senior-менеджер продуктов сначала разбирается, где реальный риск, что можно упростить и какую часть гипотезы нужно проверить сейчас. Дальше он переводит разговор из спора за приоритет в совместный выбор: «Я вижу риски и ограничения. Давайте не будем сразу делать полное решение. Возьмем MVP на один сценарий, проверим гипотезу на части пользователей и заранее договоримся, при каком результате идем дальше, а при каком закрываем инициативу». Такой продакт не продавливает задачу через руководителя. Он помогает команде увидеть безопасный способ движения и принять решение без эскалации. 🔰Мини-чеклист Чтобы проверить, находитесь ли вы на уровне, близком к Senior, задайте себе вопросы: — Я могу объяснить свою работу через бизнес-метрики, а не только через список фич? — У меня есть понятная продуктовая ставка на квартал? — Я понимаю, от каких задач мы сознательно отказались и почему? — Я знаю, как мой продукт зарабатывает или экономит деньги? — Я отслеживаю эффект после релиза? — Я умею влиять на соседние команды без эскалации? — Меня зовут в обсуждения до того, как решение уже принято? — Команда может принимать часть решений без меня, потому что у нее есть контекст? Если большинство ответов «нет» или «частично», проблема может быть не в том, что вас недооценивают. Возможно, вы много делаете, но пока показываете компании не Senior-сигналы, а сильный исполнительский Middle-уровень. @productmindset

📢 Известны первые спикеры конференции ProductSense'26 Лето — это жара, выходные за городом и встречи с семьей, а также время подготовки к нашей основной конференции ProductSense'26. 10-11 сентября мы вновь соберемся в Москве в ЦМТ и в онлайне, чтобы ответить на вопрос: «Что в продуктовой работе действительно остается, а что уже требует пересборки?» Обсудим реальные рабочие кейсы со всеми текущими сложностями и ограничениями. И разберем практические рекомендации, как двигаться дальше. Тема конференции этого года — «Фундамент и эволюция: как меняется продуктовая работа». Будем говорить об этом в рамках трех треков: — Инструменты и границы их применимости — Системы, процессы и организационные контуры — Практические мастер-классы А сегодня предлагаем познакомиться с темами выступлений и спикерами: 🤩Максим Кайнер, руководитель продукта в СДЭК «Здоровые границы в управлении продуктом: как найти, очертить и зафиксировать зону ответственности» 🤩Никита Дубко, старший руководитель продуктов в Яндекс Контест «Когнитивные искажения в работе продуктового менеджера и ИИ-помощники, которые помогут их избежать» 🤩Дарья Маткина,эксперт клиентского опыта «Проклятие опыта: как эволюционировать из эксперта в исследователя» 🤩Сергей Синяков, руководитель продуктов безопасной разработки в Positive Technologies «Стресс-тест продуктовых гипотез с помощью агентных ИИ-систем» 🤩Сергей Павлин, руководитель офиса управления продуктом в Авито «Автоматизация продуктовых процессов: ИИ-ассистенты, боли, эволюция» 🤩Таслима Сагдиева, руководитель продуктового направления в Skyro «Дерево метрик: как не быть заложником интуиции и выстроить понятную систему принятия решений» Подробнее о треках конференции и других спикерах — на сайте. Также готовим все подробности о том, какие форматы участия будут в этом году, включайте уведомления и следите за новостями в канале. @productmindset

9 материалов, чтобы держать продуктовое мышление в тонусе Смотреть на задачи под другим углом и лучше ориентироваться в актуальной повестке помогает возвращение к базе — такое наблюдение мы сделали, просмотрев список полезных ресурсов из нашего ежегодного исследования продуктового сообщества. Участники рекомендовали книги, подкасты, курсы и статьи, которые помогли им в работе и расширении кругозора в прошлом году. Из них мы выбрали 9 материалов, которые помогут освежить базовые знания, чтобы наложить на них свой опыт и экспертизу и получить идеи для решения ваших задач. Сохраните подборку, чтобы вернуться к ней перед планированием, исследованием, обсуждением метрик или разговором про AI в продукте. 🧠 Продуктовое мышление: вспоминаем базу 1. The Foundation of Product (англ)* О том, что такое продуктовая работа, почему сильной команде важно давать не только задачи, но и право искать решения, и почему продакт — это не менеджер задач. * – ресурс открывается с использованием vpn. 2. Как придумывать и челленджить гипотезы Материал про один из ключевых навыков менеджера продукта: не влюбляться в идею, а проверять ее до того, как команда потратила месяц разработки. 3. A 4-step framework for building delightful products (англ) Как делать продукт не просто функциональным, а по-настоящему приятным и ценным для пользователя через поиск эмоциональных мотиваторов и проверку идей, которые могут усилить удержание и лояльность. 4. Что такое кастдев на самом деле Мы думаем, что исследуем пользователя, а на деле подводим его к нужному нам ответу. Что делать, чтобы этого избежать и какие книги и методологии стоит изучить. 📊 Метрики, цели и экономика 5. OKR, дерево метрик и North Star Metric Как связать цели, метрики и фокус команды в одну систему, а не держать набор красивых, но разрозненных чисел. 6. Юнит-экономика — это просто. Объясняем в 30 словах Короткая база, которую важно понимать каждому менеджеру продукта: где продукт создает деньги, где теряет и почему рост не всегда означает здоровую экономику. 🤖 ИИ в продуктовой работе 7. Building effective agents (англ) О том, как осознанно подходить к AI-агентам и почему эффективные LLM-агенты чаще строятся не на сложных фреймворках, а на простых и понятных паттернах, которые можно комбинировать под конкретную задачу. 8. “AI” is NOT going to fix Product Management. But you can (англ)* Трезвый взгляд на ИИ в работе менеджера продуктов: сам по себе он не решит проблемы менеджмента. Продактам и лидерам все равно нужно лучше выбирать задачи, выстраивать процессы и переосмыслять работу команд. * – ресурс открывается с использованием vpn. 9. State of AI Report 2025 Большой годовой срез AI-индустрии. Удобный видеоразбор индустрии, интересно сравнить данные, актуальные на конец 2025 года и то, что мы видим сейчас, в середине 2026 года. @productmindset

От метрики к решению: 8 шагов проектирования продуктового дашборда В первой части мы говорили о типовых ошибках при проектировании дашборда. В этой части разберем, как связать дашборд с решением, пользователем и контекстом. Если дашборд должен помогать принимать решения, проектировать его нужно не как отчет, а как путь от вопроса к действию. Поэтому полезно разложить его на цепочку шагов. Сама цепочка может выглядеть так: Решение → пользователь → контекст → вопрос → метрика → сравнение → визуализация → действие 1. Решение Сначала формулируем не метрику, а управленческое решение. Хороший пример: «раз в неделю руководитель продукта на основе данных должен понять, где проседает рост: в привлечении, активации, повторном использовании, монетизации или качестве». 2. Пользователь Один и тот же дашборд не может одинаково хорошо отвечать всем. Для нас важно сразу определить, для кого дашборд. Генеральный директор: нужно видеть здоровье бизнеса, стратегические отклонения, риск для целей. Руководитель продукта: нужны продуктовые драйверы, узкие места, приоритеты. Маркетинг: нужны каналы, качество трафика, стоимость привлечения, конверсии. Операции: нужны очереди, скорость ответа, сбои, ручные вмешательства. Саппорт: нужны темы обращений, нагрузка, качество решения. 3. Контекст действия Нужно понять, когда человек смотрит на дашборд, потому что от контекста зависит уровень детализации: Ежедневно утром — нужен мониторинг отклонений и срочные действия. Раз в неделю — нужна динамика, причины изменений, приоритеты. Раз в месяц — нужна стратегическая картина, тренды, эффективность инициатив. После релиза — нужен impact review. Во время инцидента — нужен real-time status и диагностика. Перед planning — нужны возможности и узкие места. 4. Вопрос Каждый блок дашборда должен отвечать на конкретный вопрос. Не «показать retention», а: — удержание растет или падает относительно цели? — какая когорта изменилась? — какое действие мы должны предпринять? Если у графика нет вопроса, скорее всего, он лишний. 5. Метрика Метрика выбирается после вопроса. Например: для вопроса «Пользователи доходят до ценности?» можно использовать метрики: процент активации, время до получения первой ценности. А для вопроса «Является ли видимый нами рост качественным?» подойдут метрики LTV/CAC (соотношение пожизненной ценности клиента к стоимости привлечения), отток, процент возвратов. 6. Сравнение Без сравнения дашборд слабый: именно сравнение превращает данные в сигнал к действию. Поэтому рекомендуем добавить такие сравнения, как — план / факт; — месяц к месяцу; — до / после релиза; — сегмент A / сегмент B; — новые / старые пользователи и так далее. 7. Визуализация Визуализация выбирается не по красоте, а по типу решения. Для динамики подойдет линейный график. Для сравнения сегментов — столбчатые диаграммы. Для воронки — диаграмма с абсолютными значениями и конверсией между шагами. Для когорт — тепловая карта. Для диагностики отклонений — таблица с сортировкой по размеру проблемы. Не нужно использовать разные типы графиков ради разнообразия. Обычно рекомендуется избегать визуального разнообразия ради самого разнообразия и не использовать графики, которые искажают восприятие. 8. Действие Финальный тест: «что человек сделает иначе после просмотра?» Если ответ: «Ну, он просто будет знать», — это слабый блок. Здесь можно ориентироваться на следующие действия: — проверить гипотезу; — отключить канал; — откатить релиз; — поменять приоритет; — поставить задачу команде; — сравнить сегменты и так далее. Главная цель для любого дашборда: дать ответ на вопрос «какое действие будет предпринято после всех шагов?» В таком случае он помогает увидеть отклонение, понять масштаб, локализовать причину, выбрать действие и потом проверить эффект. И кстати, если тема вам интересна — о практическом применении этих шагов можно прочитать в статье в нашем блоге. @productmindset

📊 Проблема не в графиках: почему продуктовые дашборды часто бесполезны Посмотрим на классическое определение того, что такое дашборд: это визуальное отображение самой важной информации, нужной для достижения одной или нескольких целей, собранное на одном экране так, чтобы ее можно было понять с первого взгляда. В этом определении важны не «метрики» и не «графики», а цель, важность и быстрое понимание. Но иногда команды об этом забывают. Сегодня тезисно разберем, почему дашборды становятся бесполезными для принятия решений, и порассуждаем, как это можно исправить. Часть 1. Почему дашборды становятся бесполезными 1. Дашборд строят от метрик, а не от решений У команды есть много данных: события, таблицы, KPI и так далее. В процессе возникает соблазн «вывести все важное на экран». Делаем так — получаем не инструмент принятия решений, а витрину данных. Человек смотрит на цифры, но не понимает: — что изменилось; — почему это важно; — какое действие нужно сделать дальше. Хороший принцип: «число без сравнения — это факт, число с бенчмарком — уже инсайт». Поэтому графикам нужны план, прошлый период, целевое значение, сегмент или референс. 2. Дашборд не привязан к роли пользователя Один и тот же дашборд пытаются сделать «для всех»: CEO, руководителя продукта, маркетолога, аналитика, саппорта. Делаем так — каждый видит часть полезного, но никто не получает полноценный инструмент. CEO не нужны все разрезы по кнопкам, менеджеру продукта не хватает диагностических разрезов, операционному менеджеру не хватает сигналов «что чинить сегодня». Один и тот же показатель для разных ролей означает разные действия. Например, когда конверсия в заказ падает: — для CEO — вопрос к стратегии роста; — для руководителя продукта — вопрос к приоритетам и воронке; — для менеджера продукта — вопрос к гипотезам, экрану, сегменту, релизу; — для маркетолога — вопрос к качеству трафика; — для саппорта — вопрос к частотным проблемам пользователей. Что можно сделать: начать проектирование дашборда не с вопроса «какие метрики показать?», а с вопроса: «кто смотрит, зачем смотрит и какое решение принимает?» 3. Метрика становится целью и начинает искажать поведение Часто дашборд используют не только для наблюдения, но и для контроля. Как только метрика становится целевой, люди начинают оптимизировать поведение под нее. Как итог — команда отлично улучшает метрику, но может незаметно для себя ухудшать продуктовый результат. Частый пример: качество саппорта оценивают по скорости ответа — команда отвечает быстро, но поверхностно. Или менеджера продукта оценивают по количеству релизов, а не по ценности для клиента и бизнеса Как можно исправить: показывать не одну «главную» метрику, а систему: результат, драйверы, ограничители и контрольные метрики. 4. Дашборд показывает состояние, но не помогает найти причину Допустим, дашборд привязан к решениям, адаптирован под роли, метрики сбалансированы. Но есть проблема: дашборд показывает, ЧТО происходит, но не помогает понять, ПОЧЕМУ. И в итоге команда делает еще одну итерацию с аналитиком, собирает встречи, ищет показатели, которые помогут выявить корневую причину. Например: на дашборде видим сигнал — «у нас упал ретеншн». Но план действий можно сформулировать только после диагностики: в каком сегменте? После какого релиза? В каком канале привлечения? На каком шаге? У новых или старых пользователей? у платящих или бесплатных? Поэтому рекомендуют придерживаться следующей цепочки: увидеть отклонение → понять масштаб → локализовать источник → выбрать действие → проверить эффект Во второй части разберем, как проектировать дашборд наоборот: не от списка метрик, а от решения, пользователя и ситуации, в которой человек должен понять, что делать дальше. @productmindset

Любой инструмент можно сделать полезным. Главное — знать как Развитие команды должно помогать работе, а не становиться отдельной нагрузкой для руководителя. Но на практике часто выходит иначе. Курсы проходят “для общего развития”, воркшопы быстро забываются, книжные клубы держатся на энтузиазме нескольких человек, а руководитель снова думает, как превратить обучение в реальную пользу для команды и бизнеса. Проблема не всегда в формате. Иногда привычный инструмент просто нужно переосмыслить: связать его с рабочими задачами, сделать полезным для участников и убрать ощущение обязательной активности ради активности. О том, как можно адаптировать привычный инструмент для менеджеров продуктов и проектов — новая статья от Жени Крупиной в нашем блоге. Читать статью →

Чему не учат руководителей: как управлять собой, чтобы легко управлять людьми Спикер: Мария Фаустова В карьерном росте руководителя есть как минимум два перехода, которые в корне меняют работу менеджера. Первый — из исполнителя в руководителя. Второй — выход на стратегический уровень. И именно он часто оказывается самым сложным. Рассмотрим пример первого перехода из исполнителя в руководители: сотрудница пришла оператором в колл-центр, через несколько месяцев стала супервайзером и совершила первый скачок — из роли исполнителя в роль руководителя. Здесь нужно полностью пересмотреть набор навыков, которые вы будете применять в рабочих задачах. Сложность нового этапа — в том, что теперь вы отвечаете не только за себя и достигаете целей не своими руками. Поэтому вам необходимы новые навыки: делегирование, управление людьми, лидерство, работа с командной динамикой. На этом этапе я рекомендую вам ответить себе на два ключевых вопроса: — Каким лидером я буду? — За что и почему именно меня сделали руководителем? Пройдя первый переход, человек на самом деле осваивает новую профессию — профессию руководителя — и может менять сферы, оставаясь при этом профессионалом в области управления людьми. Второй переход — выход на уровень стратегического менеджмента. На этом уровне добавляется не только работа с командой, но и ответственность за долгосрочную стратегию развития бизнеса, продуктовую стратегию, контроль ресурсов, постановку долгосрочных целей и определение стратегии их достижения. Если коротко сравнить, то у линейного менеджера четко заданы цели. А от стратегического менеджера ждут, что он сам определит цели и, более того, сможет показать, что будет с бизнесом, если эти цели будут достигнуты или же не будут достигнуты. Здесь решения принимаются на уровне больших ставок, а спросить, как правильно, часто не у кого. Да и готового правильного ответа обычно не существует. Переход на стратегический уровень можно сравнить с переходом через пролив Дрейка: тестируются выносливость, умение справляться с неопределенностью и то, как вы работаете с внутренней уверенностью. На первых порах такое количество неопределенности пугает. А еще в этот момент нужно перестать решать новые задачи старыми инструментами. В какие ловушки часто попадают новоиспеченные руководители на втором переходе и как из них выходят: — Мы начинаем срочно подтягивать hard skills и пытаемся стать самым сильным экспертом в комнате. Но здесь нужно изучать контекст и учиться гибко адаптировать план. И это тоже можно прокачать как навык. — Пытаемся использовать директивное управление. Здесь это не работает, потому что ваша цель — собрать вокруг себя команду крутых экспертов, которым можно задавать направление. Не нужно говорить им, как именно делать работу. — Погружаемся в операционные задачи и микроменеджмент. Так проще и привычнее. Но на этом уровне стоит тратить силы и ресурсы на стратегию и понимание, как действовать в неопределенности. Отсутствие операционных задач не сделает вас ненужными. Управлять собой — значит знать эти ловушки, отслеживать их, вовремя замечать и возвращать себя к задачам нового уровня. Это значит помочь себе хотя бы на переходный период: стать себе ментором, обеспечить процесс развития и сфокусироваться на том, что ваш ресурс — самый важный и ценный. Что для этого нужно: — Осознать переходный период. — Спланировать свое развитие. — Задать стандарты команды. — Тренировать навык принятия решений. Самое удивительное — вы узнаете, правильным было решение или нет, только когда оно реализуется. — Обеспечить управленческую гигиену: сон, восстановление, фокус, границы и регулярную рефлексию. На стратегическом уровне руководитель уже не может выигрывать только за счет экспертизы и скорости. Приходится учиться выдерживать неопределенность, принимать решения без полной картины и управлять собой так же внимательно, как и командой. @pplsense

Как ИИ и новые подходы к написанию кода изменили проектный менеджмент Спикер: Артем Трушин Долгое время в моей компании было тестовое задание, в котором был один разработчик по имени Патрик, и он плохо работал. Единственным верным решением кейса было уволить его. Так что давайте представим, что этот Патрик ушел в другую компанию и сам стал менеджером проектов. На что уходит его время ежедневно: — Статус-апдейты и отчеты — 25% — Административная рутина — 20% — Встречи с повесткой и без — 15% — Реальное управление — 40% До того как Патрик узнал про ИИ-агентов, его день выглядел примерно так: обзор задач, дейлики, сами задачи/ответы/уточнения (примерно часа два), подготовка к встречам со стейкхолдерами, анализ и планирование спринтов, отчеты. То есть если не работать до полуночи, то времени на свои стратегические задачи в этом расписании остается крайне мало. Что же делать? На помощь пришел ИИ и закрыл самые частые сценарии. 1. Планирование и декомпозиция Агент разбирает задачи, оценивает сроки по истории команды, строит графики зависимостей. 1–2 дня планирования сжались до 30 минут работы. 2. Подготовка стендапа из трекера Агент сам подтягивает задачи из трекера, актуализирует статусы, формирует сводку — на дейлик команда приходит уже с контекстом и вместо пересказа тикетов обсуждает блокеры. 3. Мониторинг рисков Агент непрерывно следит за прогрессом задач, загрузкой команды — и подсвечивает риски, когда их замечает. Проектный менеджер получает уведомление с конкретным риском и предложением, что с этим сделать. О риске становится известно за пару дней до того, как он превратится в проблему, а не на ретро. 4. Документация без усилий Агент расшифровывает встречи, собирает протоколы и решения, формирует базу знаний. Теперь агенту можно задать вопрос и получить ответ за минуту, а не тратить на поиски часы и дни. 5. Отчетность за 30 секунд Агент собирает данные из трекера, GitHub, мессенджеров, считает метрики спринта и формирует отчет под аудиторию. Менеджер получает готовый черновик с источниками — остается лишь проверить и отправить. 2 часа, чтобы собрать отчет → несколько минут на проверку. Теперь Патрик приходит на работу и решает те же задачи, но работает иначе: рутина уходит агентам, а в фокусе остаются стратегические вопросы. А самое главное — высвободилось время: примерно три часа в день. Как это получилось? В основе этих сценариев — не просто чат с ИИ, а агенты: системы, которые получают цель, сами собирают контекст, предлагают решение и помогают довести задачу до результата. И да, все это получилось не с первого раза и не по щелчку пальцев. Один из подходов — описание скиллов. Скилл — это кристаллизованная экспертиза: подробно описанный опыт, который агент может воспроизвести и применить автоматически. 4 набора скиллов, которые, по моему мнению, нужны каждому, кто работает с агентами: — Using superpower — проверяет, какой процессный скилл нужен сейчас, уменьшает риск галлюцинаций и ошибок. — Karpathy-guidelines — помогает делать гайдлайны, чтобы LLM допускала меньше ошибок. — Diagnose — помогает отлаживать процесс. — Grill-me — задает вопросы до тех пор, пока не будет достигнута полная ясность. И бонус: find-skills — это скилл, который сам находит компетенции, которые вам необходимы. Теперь Патрик превратился из исполнителя в дирижера, который управляет несколькими агентами, принимает решения и работает с тем самым helicopter view — видит полную картину происходящего, умеет заранее замечать скрытые риски и знает, где и когда требуется его вовлеченность для большего результата. А с чего начать вам, чтобы последовать примеру Патрика? 1. Выберите один процесс. 2. Запустите пилот на 2 недели. 3. Измерьте и масштабируйте. Затем найдите следующую рутину, которую можно автоматизировать Да, ИИ ошибается. Да, данные важно хранить безопасно. Да, нельзя перекладывать принятие решений на ИИ. Помним, что «ИИ ускоряет, а человек управляет», и используем его эффективно. @pplsense