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

1. Тактическое управление
продуктами: все еще
недостающее звено
Максим Гапонов
QIWI

2. Максим Гапонов
Agile Coach, Luxoft
Agile/Lean-коуч. В ИТ более 10 лет. Работал в должностях
разработчика, менеджера проектов, владельца продуктов,
технического директора. Имею опыт работы как в стартапах,
так и крупных международных компаниях. Один из
основателей сообщества Agile Russia.
Professional Scrum Master, Certified Scrum Product Owner, ICAgile
Certified Professional – Agile Fundamentals, ICAgile Certified
Professional – Business Value Analysis, ICAgile Certified
Professional – Agile Coaching.
Ну, и психотерапевт.

3. А, собственно,
О чем речь?

4. Итак, у вас есть понимание рынка, стратегия, roadmap и вот
это вот все.
Требуется понять как это сделать, обеспечить фокус для
сотрудников, довести идеи до прода и оценить, что из
задуманного получилось.
Все перечисленное - быстро и не делая лишней работы.
WTF тактическое управление продуктами?

5. Чем на самом деле
управляют продакты?

7. Групповые аспекты
Отсутствие общего
понимания
Нечеткие договоренности об
ожидаемых результатах
Сложности встречи с
итогами работ
Что к этому приводит?
Индивидуальные аспекты
Преждевременное погружение
в деятельность
Недостаток понимания границ
своей работы
Страх осуждения

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

9. Пытайтесь повторить это
дома, ешьте кактусы и
учитесь на своих
ошибках

10. Немного о принципах
и ценностях

11. Output vs. Outcome
(С) Jeff Patton

12. Stop starting, start finishing
Единственная вещь, которая приносит удовлетворение и
повышает мотивацию — это завершение работ
Единственная вещь, которая позволит вам понять, движетесь
ли в верном направлении — это завершение работ
Чем меньше вы делаете одновременно, тем быстрее что?
Верно, завершение работ

13. Optimize the whole
Для того, чтобы понимать, что вам мешает завершать работу,
требуется управление сквозным процессом от идеи до прода
Применение локальных оптимизаций приводит к тому, что
проблема перемещается в другую стадию процесса,
но не исчезает
Не забывайте об окружающей среде — вы меняетесь внутри,
она тоже меняется, часто намного динамичнее

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

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

16. Заказчик: отдел продаж регионального импортера
Бизнес-задача: связать импортера автомобилей с дилерскими
центрами единым процессом и управлять эффективностью
продаж
Зачем: импортер обязуется перед производителем продать
определенное количество автомобилей, а дилерские центры
продают, как умеют
Жил-был один автоконцерн…

17. Кроме описания бизнес-задачи и примерного представления
необходимого процесса продаж, нет ничего
Есть 3 недели, за которые необходимо сделать рабочий
прототип, с которым будут обучать сотрудников дилерских
центров
Если через 3 недели прототип не готов, бизнес превращается
в тыкву
Особенности

18. Design thinking

19. Что сделали
Выделили основных
пользователей системы:
продавец, руководитель
отдела продаж, сотрудник
импортера
Персоны, как применяли
Зачем?
Все они пользуются одной и той
же функциональностью, но с
разными целями, следова-
тельно, реализация для
каждой персоны — разная

20. Narrative Journey Map

21. Narrative Journey Map, как применяли
Что сделали
Выяснили, что авторы про-
цесса продаж ни одной
машины сами не продали
Собрали продавцов и выясни-
ли, как они работают на
самом деле
Зачем?
Снижение риска поставки бес-
полезного решения
Определение ключевых
сложностей, требующих
первоочередной автоматизации

22. Story Mapping

23. Story Mapping, как применяли
Что сделали
Спроектировали ключевые
цепочки использования
Выбрали самые «топорные»
варианты реализации
Согласовали с заказчиком
на бумажных прототипах
Зачем?
Обеспечение полноты покрытия
рабочих процессов разных ролей
Общее понимание результата
работ с заказчиком
Понимание границ задач для
сотрудников

24. Скептическое отношение конкурентов, допиливающих
стандартное «общее» решение
Сопротивление заказчика к режиму работы, в котором
необходимо постоянное сотрудничество, предоставление
сотрудников на воркшопы
Однодневные итерации, 16-18 часовой рабочий день :)
С чем сталкивались

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

26. Случай в телекоме
Заказчик: рабочая группа стратегического маркетинга
Бизнес-задача: разработать набор продуктов на основании
собираемых из различных систем данных
Зачем: создание новых источников прибыли и оптимизация
имеющихся бизнес-процессов

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

28. Масштабирование

29. Масштабирование, как применяли
Что сделали
Выделили роли CPO, TPO и
синхронизирующей команды
Составили RACI-матрицу
того, кто за что отвечает
Разделили сотрудников на
продуктовые команды
Зачем?
Обеспечение трассировки целей
на разных уровнях управления
Понимание сотрудниками границ
своей ответственности
Снижение перегрузки сотрудни-
ков и бардака

30. Kanban, как применяли
Что сделали
Проанализировали заказ-
чиков, источники неудовлет-
воренности, work items,
workflow по ним
Создали сквозной процесс:
стадии, политики, WIP-лими-
ты, структура совещаний
Зачем?
«Разморозка» работ благодаря
сокращению количества
заказчиков
Получение общей картины дви-
жения работ, возможность из-
мерений и управления

31. Impact Mapping

32. Impact Mapping, как применяли
Что сделали
Выделили основные направ-
ления работ, построили по
каждому карту
Удивились :)
Пересобрали бэклоги
Зачем?
Обеспечение фокусировки
команд и реализуемости планов
Проявление «скрытых» объемов
работ

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

34. «Разморозили» исследовательскую работу и выяснение того,
какие продукты можно построить
Пересобрали команду и построили сквозной продуктовый
процесс
Запустили процесс непрерывного улучшения/адаптации
Что получилось

35. Или, вот, инвестиционный банк
Заказчик: рабочая группа внутренней автоматизации
Бизнес-задача: переработка системы ведения и версионного
контроля документов
Зачем: повышение качества и скорости обработки документов

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

37. User Story Canvas

38. User Story Canvas, как применяли
Что сделали
Договорились о том, в какие
моменты работ заполняем
какие зоны, и кто за какие из
них отвечает
Построили систему совещаний
вокруг обсуждения различных
зон
Зачем?
Разграничение зон ответствен-
ности при сохранении полноты
работ
Фокусировка совещаний
Внутреннее управление
ожиданиями

39. Модель зрелости, как применяли
Что сделали
Разработали модель зрелости
на основании ролей, артефак-
тов и событий
Проводили еженедельный
аудит
Зачем?
Обеспечить системный взгляд
на развитие команды
Наладить бесшовную интег-
рацию между discovery и
delivery

40. Метрики, как применяли
Что сделали
Внедрили измерение kanban-
процесса: CFD, spectral
Внедрили enhanced burndown-
чарты для релизов
Зачем?
Возможность анализа эффек-
тивности сквозного процесса
(разработка — blackbox)
Обоснование для принятия
решений по реприоритезации

41. Управление коммуникациями в условиях распределенной
команды требует значительных усилий на фасилитацию и
поддержание границ
Несколько раз пересматривали схему распределения
ответственности между аналитиками — искали наиболее
оптимальную
Наличие метрик не обеспечивает принятия реальности :)
С чем сталкивались

42. Выровняли коммуникации между заказчиком и поставщиком,
интегрировали сотрудников заказчика в команду продукта
Построили измеримый сквозной процесс, интегрирующий всю
цепочку discovery-delivery
Научились опережать разработку в подготовке требований
Что получилось

43. А вообще еще бывают истории распределенного управления
продуктами, когда у вас нет выделенных продактов, но есть
владельцы отдельных фич, а дальше оно как-то само.
Это требует определенного устройства организации и
очень зрелой культуры.
Возможно, я расскажу о таком опыте на AgileDays ;)
Тем временем в параллельной вселенной…

44. Книжку про это хотите?

45. Что пока почитать
Текст слайда Текст слайда

46. That’s all,
Peace!