▫️Process Mining – специфический способ анализа процессов

#посмотреть

▫️Данные о событиях должны считаться объектами первого класса
▫️Журналы должны извлекаться в соответствии с предметными вопросами
▫️Необходимость поддержки операторов параллелизма, выбора и других базовых элементов моделей потока управления
▫️События должны соотноситься с элементами модели
▫️Модели следует рассматривать как целенаправленные абстракции реальности
▫️Process Mining должен быть непрерывным

⏱Смотреть видео на YouTube ⏱1 час

Чемпионат продактов. Вместо тошных тестов по компетенциям - соревнование по бизнес-кейсам

#почитать

Профессиональный уровень продакта объективно оценить весьма трудно, потому что:
▫️уровень знаний не говорит об уровне в профессии
▫️ожидания стейкхолдеров не сформулированы явно
▫️сложно добиться объективности

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

⏱Читать статью

Наследие прошлых разработчиков. Что делать с легаси-проектом (создать 3 спецкоманды)

#почитать

Типичное:
▫️Документации нет
▫️«Что-то» находится у другого исполнителя
▫️Защищенный периметр, сложно обмениваться кодом
▫️Решение не работает или работает некорректно

Что делать:
Одним из вариантов эффективного управления командой разработки на легаси-проектах могут быть выделенные команды.
▫️1. Support Team. Основная задача: поддержание стабильности проекта и оперативное устранение ошибок.
▫️2. Refactoring Team. Основная задача: оптимизация, реорганизация и модернизация кода.
▫️3. Feature Team. Основная задача: разработка и добавление новых функциональностей, которые будут актуальными для проекта в будущем.

⏱Читать статью

▫️Спорный вопрос: можно ли отказаться от фуллстек-аналитиков. Обсуждение на Analyst Days

#посмотреть

По крайней мере в X5 Tech отказались, и ничего не случилось.

⏱Смотреть видео на YouTube ⏱25 минут

Откажитесь от формата Историй. Они себя изжили. Пользователя привлекает контент, а не "сторис"

#почитать

▫️"Расскажу вам, как мы реализовали проект «Истории»: опишу вдохновение, разочарования, запуск и метрики, и отвечу на вопрос — должны ли истории умереть (да). Эта информация может пригодится тем, кто планирует запускать такой или похожий проект в своём продукте, или думает о том, как решить похожие задачи.

▫️Первое, с чего мы начали — пошли советоваться с теми, у кого в продуктах уже работают истории для бизнеса. И сразу напоролись на мнение о том, что истории себя изжили, это прошлый век, нужно придумывать что-то новое. Мне понравилась эта мысль, но я думал (ошибался), что время историй ещё не прошло.

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

▫️Коменты на Хабре традиционно ещё ярче чем статья: "Как же бесит этот тренд на истории. Большинство использует истории для одного - разложить усталый мозг за просмотром незатейливых тупых историй. Всё. Кто, скажите мне, кто придумал позиционировать истории как полезный инструмент? Тот же, кто начал лепить везде в таблицах админкок бесконечный скролл вместо паджинации?"

⏱Читать статью

🟡Дайджест полезных материалов по project и product менеджменту за неделю c 4 по 10 декабря

🔖 Почитать:

▪️Важное на старте нового проекта
▪️История методологий. Что дальше? LLM-модели и безработица
▪️Уточнение требований. Вопросы закрытые и открытые
▪️Карта пути клиента на примере покупки Tesla
▪️Выполнение задач можно прогнозировать с вероятностью 80-90%
▪️Когда проект растет — надо менять подходы
▪️Есть такой стиль лидерства — служение
▪️Дневник эмоций и эмоциональная безопасность
▪️Полное руководство по фидбеку
▪️Нетворкинг и личный бренд реально влияют на ЗП. Просто у этих вещей есть плохие названия
▪️Я добился успеха как ПМ вообще без негатива
▪️Тирания маргинального юзера. Почему всё вокруг становится примитивнее (крайне субъективная точка зрения, тем не менее заслуживающая обсуждения)

👀 Посмотреть:

🌐 Счастливый заказчик и счастливая команда ⏱30 минут
🌐 Продуктовая революция ⏱30 минут
🌐 Как работают со стейкхолдерами в Спортмастере ⏱45 минут
🌐 Лекция про исследование клиентского и пользовательского опыта ⏱50 минут

⏱Подробный дайджест с описаниями

Хорошего дня!

Эффективная командная работа: рецепты Яндекса для командиров проектов

#почитать

▫️Определитесь с целью
▫️Выберите неформального лидера
▫️Договоритесь о базовых принципах взаимодействия
▫️Обсудите и добавьте ритуалы
▫️Говорите и слушайте — это помогает!

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

⏱Читать статью

Деды были правы: делай что-то одно и делай это хорошо

#почитать

▫️40 лет назад два идеолога, две легенды computer science Брайан Керниган и Роб Пайк опубликовали радикальный манифест… ну, или что-то вроде того. Сформулировали в книге Program Design in the UNIX Environment паттерн архитектуры ПО, за сохранение которого оба боролись долгие годы. Как и следовало ожидать от манифеста, в нём два этих канадских инженера максимально решительны.

▫️Самый резкий тейк в статье — это запомнившаяся многим строчка из аннотации: Старые программы покрываются коркой сомнительных фич.

▫️Суть статьи часто сводят к аббревиатуре DOTADIW, или «Do One Thing And Do It Well» («Делай что-то одно и делай это хорошо»).

▫️К сожалению, как и в случае с большинством манифестов, этот идеал не выдержал столкновения с реальностью. Прекрасная идея Кернигана и Пайка так никогда и не дала плодов.

▫️Керниган и Пайк были правы хотя бы в одном: что раздувание ПО является проблемой. Огромные приложения сложно изучать, трудно использовать и в них куча багов. Это и есть гниение платформ. Крупных платформ - монолитных платформ.

▫️Попыткой частичного решения DOTADIW стали микросервисы. Микросервисы должны «делать что-то одно и делать это хорошо».

▫️При разбиении сервисов на мелкие части мы получаем микросервисы, а при разбиении фронтендов — очевидно, микрофронтенды. Но на самом деле микрофронтенды являются ребрендингом старой идеи: апплетов.

▫️Простых ответов не существует, но повсюду можно найти подсказки. Чтобы подобрать идеальную структуру для сложного ПО, обратите внимание на структуры, пережившие миллиарды лет жесточайшей эволюции: атомы и молекулы, солнечные системы и галактики, наши собственные внутренние органы. Тракторы и камеры. Obsidian и VS Code. Все они созданы из маленьких однофункциональных блоков, как и задумывалось Керниганом и Пайком.

⏱Читать статью

Этапы поиска работы начинающего продакт-менеджера. Снимаем розовые очки. И действуем

#почитать

Привет, я Вова Ермилов из ОКейси (Senior PM YouTalk, CPO Eatagram, ex. Joom.com). Сегодня разберёмся, как начинающему продакт‑менеджеру не сойти с ума, листая вакансии, и научимся применять продуктовый подход к поиску работы.

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

Этап № 0: формирование гипотезы
Этап №1: поиск отправной точки
Этап №2: выбор компании
Этап №3: анализ рынка

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

⏱Читать статью

▫️ Методика Event Storming. Ускорение аналитических работ в ИТ-проекте. Из цикла Flow 2023

#посмотреть

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

Методика Event Storming позволяет существенно сократить сроки и трудоемкость аналитических работ за счет замены индивидуальных сессий работы и мучительных офлайновых согласований на контактную работу в формате специализированных очных или онлайн-семинаров.

Содержание:
1. Краткий обзор классического аналитического процесса
2. Сложности и проблемы классического процесса в 21-м веке
3. Ключевые идеи подхода Event Storming
4. Моделирование уровня Big Picture
5. Связь Event Storming с Agile, архитектурой микросервисов и EDA
6. Границы применимости подхода и рекомендации по внедрению

⏱Смотреть на YouTube ⏱45 минут

Универсальный алгоритм HADI-цикла - и как он помогает управлять техническим продуктом

#почитать

HADI - это алгоритм, который строится на цепочке «Гипотеза — Действие — Данные — Выводы».

▫️Зачем влиять на продукт
▫️Как управлять продуктом
▫️Шаг 1. Исследование
▫️Шаг 2. Проведение эксперимента
▫️Шаг 3. Управление изменениями
▫️Шаг 4. Оценка эффективности

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

⏱Читать статью

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

#посмотреть

Любая компания неизбежно сталкивается с кризисом роста. Вчерашний стартап, где слаженно трудились 10 человек, начинает расти до 30-50-100 человек… Стоп. Теперь, с одной стороны, у вас появились вопросы к продуктивности — она ПОЧЕМУ-ТО перестала расти, а с другой — как теперь управлять этой командой, где вы даже не знаете всех поименно?

⏱Смотреть видео на YouTube ⏱45 минут

🟡Дайджест полезных материалов по project и product менеджменту за неделю c 11 по 17 декабря

🔖 Почитать:

▪️Power skills - предлагается новое понимание soft skills
▪️Не хайп. Delivery Manager – новый тренд управления
▪️«Переключатель не срабатывает, но это решаемо» — советы по эффективности команды на удаленке
▪️Подход MAD (Масштаб-Действие-Направление) в управлении продуктом
▪️Коммуникация с заказчиком и PI-планирование
▪️Наведение порядка в процессах. Целевая модель
▪️Пиксельное руководство по ретроспективам
▪️Уволить, проигнорировать или завалить работой?
▪️Архитектурный кат. Отсекаем всё лишнее в Agile
▪️Как мы сервис крупного проекта коллегам из Индии передавали

👀 Посмотреть:

🌐 Мастер-класс: Работа с требованиями при автоматизации процессов планирования ⏱ 1 час 30 минут
🌐 Экосистемные сервисы. Особенности разработки требований ⏱ 35 минут
🌐 Надоело управлять проектами. Как и куда можно развиваться ⏱ 50 минут
🌐 BA Leadership Talks ⏱ 45 минут

⏱Подробный дайджест с описаниями

Хорошего дня!