Всё пошло не по плану.

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

Сейчас в преддверии нового года, когда появляется обманчивая мотивация начать что-то делать с нового года, хочу напомнить про серию публикаций "Войти в IT".

Начните задумываться о новом, не дожидаясь нового года!
Да прибудет с вами сила!)

Лонгрид на тему проектирования процессов

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

Вперёд за новыми нейронными связями в публикацию https://vc.ru/life/948641-proektirovanie-processov

Продолжение следует...

Всем привет, через 4 дня в субботу(28 сентября) состоится онлайн-конференция.
Подписчики приглашаются со скидкой 15% от весьма демократичной цены.

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

Если надо еще больше
скидок то до завтра у коллег действует акция -25% от стоимости за репост. Подробнее в чате конференции.
Подключайтесь!

Анонс конференции от организаторов.

Analyst Marathon #11. ЭФФЕКТИВНЫЕ TOOLS & TECHNIQUE BA/SA

Нас ждёт приятная и несложная онлайн-конференция, на которой спикеры-практики BA/SA из ведущих компаний поделятся своими секретами, используемыми подходами и инструментами, бесценными советами и опытом.

Некоторые темы докладов:
✔️Оптимальный набор типовых инструментов для работы аналитика
✔️Как аналитику говорить с командой на одном языке
✔️Как воспитать стейкхолдеров
✔️Проектирование ИС через моделирование: как сохранить целостность и не утонуть в деталях
✔️Эффективные 1 то 1 встречи для руководителя и сотрудника
✔️Самокоучинг и Самооценка
Программа целиком

Где проходит: онлайн
Когда: 28 сентября, с 10 до 17 ч.
Сколько стоит: 2500 – 3500 руб. (до 24.09.2024 скидка 25% за репост)
Что потом: видеозаписи, презентации, материалы докладов.

В чате конференции: представление спикеров, информация об акциях и подробности

Ждем Вас на мероприятии!

Как приоритизировать задачи (метод RICE)

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

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

Что такое метод RICE?

RICE — это аббревиатура, которая расшифровывается как:
- Reach (охват) — сколько пользователей затронет ваша задача за определённый период?
- Impact (влияние) — как сильно задача повлияет на ваш продукт?
- Confidence (уверенность) — насколько вы уверены в ваших оценках?
- Effort (затраты) — сколько ресурсов потребуется для выполнения задачи?

Формула выглядит так:
RICE = Reach × Impact × Confidence / Effort

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

Шаги для использования метода RICE

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

2. Оцените каждую задачу по четырём критериям.
Reach (Охват):
Оцените, сколько пользователей затронет задача за определённый период (например, месяц). Например:
- 100 пользователей в день = 3000 в месяц.
- 50 пользователей в день = 1500 в месяц.

Impact (Влияние):
Оцените, насколько заметно задача повлияет на пользователя. Используйте шкалу:
- 3 — Высокое влияние.
- 2 — Среднее влияние.
- 1 — Низкое влияние.
- 0.5 — Незначительное влияние.
Но можете придумать и свою шкалу.

Confidence (Уверенность):
Насколько вы уверены в своих оценках Reach и Impact?
- 100% — Полная уверенность.
- 80% — Уверен, но есть сомнения.
- 50% — Низкая уверенность.

Effort (Затраты):
Сколько времени или ресурсов потребуется на выполнение задачи? Оцените это в "человеко-днях".
Например:
- 1 неделя работы одного человека = 5.
- Команда из 3 человек, работающая 2 недели = 3×2×5 = 30.

Подставим необходимые данные в формулу и получим скоринговый балл (RICE Score). Чем выше балл, тем выше приоритет задачи.

3. Составьте список приоритетов.
Отсортируйте задачи по убыванию RICE Score. Это поможет определить, что стоит делать в первую очередь.

Пример использования метода RICE

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

1. Добавить новую функцию чата.
- Reach: 5000 пользователей в месяц.
- Impact: 2 (Среднее влияние).
- Confidence: 80%.
- Effort: 10 (человеко-недель). Для простоты не будем переводить в человеко дни.

RICE = 5000 × 2 × 0.8 / 10 = 800

2. Улучшить скорость загрузки приложения.
- Reach: 10,000 пользователей в месяц.
- Impact: 3 (Высокое влияние).
- Confidence: 90%.
- Effort: 20 (человеко-недель).

RICE = 10000 × 3 × 0.9 / 20 = 1350

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

Преимущества метода RICE

1. Объективность: Вы принимаете решения на основе чисел, а не интуиции.
2. Прозрачность: Легко объяснить команде, почему выбрана одна задача, а не другая.
3. Гибкость: Метод можно адаптировать для разных проектов и команд.

Советы по применению

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

Метод RICE помогает расставить приоритеты в условиях ограниченных ресурсов. Попробуйте его в своей работе, чтобы сосредоточиться на действительно значимых задачах!

Как ИИ трансформирует продуктовый менеджмент

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

Погрузитесь в мир инноваций и откройте для себя практические кейсы из IT-проектов, где ИИ стал незаменимым инструментом для продакт-менеджеров. Читайте полный лонгрид по ссылке!

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

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

Мы выбрали формат очень похожий на документ "Концепции и границ" из книги "Разработка требований к программному обеспечению" К. Вигерса. Естественно откорректированного для наших нужд по содержанию, одно из таких изменений - добавление описания бизнес-процесса.

Это послужило тому, что я стряхнул пыль с своих наработок и всё таки закончил материал. Про паттерны проектирования и нотацию BPMN можно прочитать по ссылке!

Управление рисками. Как не переживать из-за того на что нет влияния

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

Давайте разберёмся на конкретном примере.

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

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

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

Тут выбор предстоит сделать вам. Но как это сделать?

Принять верное решение, по снижению или принятию риска, продакту помогают два вопроса:

1. Какая частотность возникновения риска?
2. Какая вероятность срабатывания риска?
3. Насколько серьёзными будут последствия срабатывания риска?

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

Подытожим

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

Анонс, текст в понедельник!

Почему продактам важно управлять рисками?

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

Фреймворк «Оценка вероятности и возможности»

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

Как применять:

1. Составьте список рисков: Включите все потенциальные риски, связанные с запуском или развитием продукта.
2. Оцените вероятность: Используйте шкалу от 1 (маловероятно) до 5 (очень вероятно).
3. Оцените потенциальный ущерб: Также используйте шкалу от 1 (незначительный ущерб) до 5 (критичный ущерб).
4. Постройте матрицу рисков: Разместите риски на матрице, выделив зоны высокой, средней и низкой критичности.
5. Определите действия: Составьте план мероприятий по управлению самыми критичными рисками.

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

SWOT-анализ для оценки рисков продукта

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

Как применять:

1. Определите сильные стороны продукта (Strengths): В чём ваш продукт превосходит конкурентов?
2. Выявите слабые стороны (Weaknesses): Определите внутренние ограничения продукта или команды.
3. Определите возможности (Opportunities): Анализируйте рынок и тренды, которые могут дать продукту преимущества.
4. Выявите угрозы (Threats): Какие внешние факторы могут негативно повлиять на продукт?
5. Сформируйте стратегию: Используйте сильные стороны и возможности, чтобы минимизировать слабости и угрозы.

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

Design Thinking в управлении рисками

Design Thinking особенно полезен продактам, работающим в условиях неопределённости, поскольку его основа — эмпатия, исследование и постоянные итерации.

Как применять:

1. Эмпатия: Проведите глубокие интервью и наблюдения за пользователями, чтобы понять их реальные потребности и выявить скрытые риски.
2. Определение проблемы: Сформулируйте чёткое определение выявленных рисков и неопределенностей.
3. Генерация идей: Проведите командную сессию брейнсторминга для поиска решений выявленных рисков.
4. Прототипирование: Создайте простые прототипы предложенных решений.
5. Тестирование: Проверьте прототипы на реальных пользователях, собирайте обратную связь и адаптируйте решения.

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

Подведём итог

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

Таким образом, если вы хотите использовать риски как источник роста и инноваций, Design Thinking станет вашим лучшим помощником.

AI-инструменты становятся нормой — особенно в продуктовой работе.

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

Ozon генерирует карточки товаров через AI, Сбер внедряет ML в BI-дашборды, Wildberries экспериментирует с персонализацией через нейросети, а команды внутри VK используют AI для скоринга гипотез.

Что это значит для нас, продактов и аналитиков:
Если вы ещё вручную пишете описания, составляете сегменты и тратите часы на отчёты — вы отстаете

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

В 2025 году не использовать AI — это как не уметь Excel в 2010-м.

Установка запаски. Или почему UX важен даже в багажнике?

Вчера впервые в жизни в автомобиле пробило колесо так, что автомобиль буквально сел диском на асфальт, еле успел свернуть на обочину. Никогда раньше такого не было, поэтому первая мысль — «надо звонить кому-то, вызывать эвакуатор».

Но через секунду вспомнил о дипломе инженера, почему бы не поменять колесо самому?

Открыл багажник, достал запаску и домкрат. Вопросы появились сразу: как раскрыть домкрат? Куда вообще его устанавливать? И тут началась магия UX, даже в таком банальном сценарии.

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

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

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

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

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

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

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

Возвращение в офисы

Компании в России начали возвращать сотрудников в офис. Вначале это были единичные новости, но сейчас всё сложнее найти вакансию с полной удалёнкой.

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

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

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

Но это не значит, что офис не нужен:

* Комфорт. Всё зависит от того, насколько работодатель реально заботится о пространстве. Удобные переговорные, кухня, спортзал? Хорошо продуманный офис работает как плюс. Плохо продуманный - как ежедневный стресс.
* Скорость решений. Иногда проще обсудить задачу при личной встрече - в «курилке» за 3 минуты, чем тянуть чат или созвон полдня. Часто нужная для решения информация всплывает именно в неформальном разговоре.
* Общий ритм. Спорный момент, особенно учитывая количество фреймворков, адаптированных под распределённые команды. Но ничто так не синхронизирует, как работа рядом.
* Командообразование. Совместные обеды, внутренние шутки, «коалиция против кондиционера» - всё это делает людей не просто коллегами, а командой.

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

Для современных работников «работа = офис» уже не аксиома. Вопрос теперь звучит иначе: в какой ситуации какой формат будет эффективнее для команды и бизнеса?

Пишите в комментариях своё мнение.

Моя подруга запускает канал про b2b-маркетинг Алина в B2B.

Она руководитель b2b-маркетинга с более чем 11-летним опытом. За её плечами Авито, АТОЛ, Huawei.

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

Будет особенно полезно продактам и PMM, которые работают с корпоративными клиентами или только начинают разбираться в B2B.

Пять лет в АТОЛ. Продукт, люди и решение идти дальше

Пять лет назад я пришёл в АТОЛ менеджером по продукту. Примерно через год возглавил направление Frontol. А сейчас мой путь в компании закончился.

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

Это нормально, просто способ измерить пройденное расстояние, как много изменилось и сколько всего произошло за это время.

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

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

Отдельная часть пути - люди.

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

Многому научился.

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

Наверное, именно возможность применять знания и было главным стимулом.

Решение уйти не появилось в один день. Оно постепенно накапливалось.
В какой-то момент я понял, что упёрся в потолок. Причём не только должностной.

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

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

Решил посмотреть на рынок. А рынок и до этого периодически смотрел на меня. В какой-то момент мы всё-таки встретились взглядами. Искра, буря, безумие.

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

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

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

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

Главная ценность этих пяти лет для меня - люди.

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

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

Anlog становится персональным

Когда я запускал этот канал, он был в основном про вход в IT, аналитику, профессии и инструменты.

За это время многое изменилось.

Я прошёл путь от продуктовой работы над платформой ЕБС до управления направлением Frontol в АТОЛ. Собирал и развивал команды, защищал инвестиционные решения, исследовал рынки, работал с B2B-клиентами и пытался связывать продуктовые решения не только с roadmap, но и с реальным результатом бизнеса.

Теперь начинается новый профессиональный этап, я выхожу на работу в МТС.

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

Поэтому меняю упаковку, но не начинаю всё заново.
Теперь это «Михаил Фокеев | Anlog» личный канал о продуктах, командах и бизнесе.

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

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

Адрес остаётся прежним @anlog. Архив тоже остаётся.

Просто теперь на вывеске будет понятно, кто здесь пишет.