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

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

Максим Гапонов

QIWI

Максим ГапоновAgile Coach, QIWI

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.Ну, и психотерапевт.

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

Итак, у вас есть понимание рынка, стратегия, roadmap и вотэто вот все.

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

Все перечисленное - быстро и не делая лишней работы.

WTF тактическое управление продуктами?

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

Групповые аспекты

Отсутствие общегопонимания

Нечеткие договоренности обожидаемых результатах

Сложности встречи ситогами работ

Что к этому приводит?

Индивидуальные аспекты

Преждевременное погружениев деятельность

Недостаток понимания границсвоей работы

Страх осуждения

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

Не будет имен, названий компаний и некоторых подробностей,которые могли бы их идентифицировать

В каждом случае делалось большое количество других вещей,но фокус этого рассказа — на тактических процессах

Мое мнение может не совпадать с мнением клиентов

Перед тем, как мы начнем

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

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

Output vs. Outcome

(С) Jeff Patton

Stop starting, start finishing

Единственная вещь, которая приносит удовлетворение иповышает мотивацию — это завершение работ

Единственная вещь, которая позволит вам понять, движетесьли в верном направлении — это завершение работ

Чем меньше вы делаете одновременно, тем быстрее что?Верно, завершение работ

Optimize the whole

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

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

Не забывайте об окружающей среде — вы меняетесь внутри,она тоже меняется, часто намного динамичнее

Facе the reality

Невозможно выстроить идеальный процесс и жить с ним,вы только развиваете адаптирующуюся систему, точка

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

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

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

Заказчик: отдел продаж регионального импортера

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

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

Жил-был один автоконцерн…

Кроме описания бизнес-задачи и примерного представлениянеобходимого процесса продаж, нет ничего

Есть 3 недели, за которые необходимо сделать рабочийпрототип, с которым будут обучать сотрудников дилерскихцентров

Если через 3 недели прототип не готов, бизнес превращаетсяв тыкву

Особенности

Design thinking

Что сделали

Выделили основныхпользователей системы:продавец, руководительотдела продаж, сотрудникимпортера

Персоны, как применяли

Зачем?

Все они пользуются одной и тойже функциональностью, но с разными целями, следова-тельно, реализация для каждой персоны — разная

Narrative Journey Map

Narrative Journey Map, как применяли


Выяснили, что авторы про-цесса продаж ни одноймашины сами не продали

Собрали продавцов и выясни-ли, как они работают насамом деле

Зачем?

Снижение риска поставки бес-полезного решения

Определение ключевыхсложностей, требующихпервоочередной автоматизации

Story Mapping

Story Mapping, как применяли


Спроектировали ключевыецепочки использования

Выбрали самые «топорные»варианты реализации

Согласовали с заказчикомна бумажных прототипах

Зачем?

Обеспечение полноты покрытиярабочих процессов разных ролей

Общее понимание результатаработ с заказчиком

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

Скептическое отношение конкурентов, допиливающихстандартное «общее» решение

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

Однодневные итерации, 16-18 часовой рабочий день :)

С чем сталкивались

Изменили мнение заказчика о том, что требовалось разработать

Разработали инструмент, полностью покрывающий необходимые процессы (у некоторых дилеров до сих пор в бою прототип)

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

Что получилось

Случай в телекоме

Заказчик: рабочая группа стратегического маркетинга

Бизнес-задача: разработать набор продуктов на основаниисобираемых из различных систем данных

Зачем: создание новых источников прибыли и оптимизацияимеющихся бизнес-процессов

Разрозненное понимание того, что и для кого необходимо разработать

Отсутствие каких-либо осязаемых результатов в проде запродолжительный период времени

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


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

Масштабирование, как применяли


Выделили роли CPO, TPO исинхронизирующей команды

Составили RACI-матрицутого, кто за что отвечает

Разделили сотрудников напродуктовые команды

Зачем?

Обеспечение трассировки целейна разных уровнях управления

Понимание сотрудниками границсвоей ответственности

Снижение перегрузки сотрудни-ков и бардака

Kanban, как применяли


Проанализировали заказ-чиков, источники неудовлет-воренности, work items,workflow по ним

Создали сквозной процесс:стадии, политики, WIP-лими-ты, структура совещаний

Зачем?

«Разморозка» работ благодарясокращению количествазаказчиков

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

Impact Mapping

Impact Mapping, как применяли


Выделили основные направ-ления работ, построили покаждому карту

Удивились :)

Пересобрали бэклоги

Зачем?

Обеспечение фокусировкикоманд и реализуемости планов

Проявление «скрытых» объемовработ

Практически, ничего не двигалось до тех пор, пока невстретились с тем, что ничего не можем закончить

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

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


«Разморозили» исследовательскую работу и выяснение того,какие продукты можно построить

Пересобрали команду и построили сквозной продуктовыйпроцесс

Запустили процесс непрерывного улучшения/адаптации


Или, вот, инвестиционный банк

Заказчик: рабочая группа внутренней автоматизации

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

Зачем: повышение качества и скорости обработки документов

Две компании (заказчик и исполнитель), наличиесотрудников одинаковых ролей в каждой из них

Много разных ролей, слабая синхронизация

Две локации разработки, разные культуры

Высокий прессинг по срокам и требуемому объему работ


User Story Canvas

User Story Canvas, как применяли


Договорились о том, в какиемоменты работ заполняемкакие зоны, и кто за какие изних отвечает

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

Зачем?

Разграничение зон ответствен-ности при сохранении полнотыработ

Фокусировка совещаний

Внутреннее управлениеожиданиями

Модель зрелости, как применяли


Разработали модель зрелостина основании ролей, артефак-тов и событий

Проводили еженедельныйаудит

Зачем?

Обеспечить системный взглядна развитие команды

Наладить бесшовную интег-рацию между discovery иdelivery

Метрики, как применяли


Внедрили измерение kanban-процесса: CFD, spectral

Внедрили enhanced burndown-чарты для релизов

Зачем?

Возможность анализа эффек-тивности сквозного процесса(разработка — blackbox)

Обоснование для принятиярешений по реприоритезации

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

Несколько раз пересматривали схему распределения ответственности между аналитиками — искали наиболееоптимальную

Наличие метрик не обеспечивает принятия реальности :)


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

Построили измеримый сквозной процесс, интегрирующий всю цепочку discovery-delivery

Научились опережать разработку в подготовке требований


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

Это требует определенного устройства организации иочень зрелой культуры.

Возможно, я расскажу о таком опыте на AgileDays ;)

Тем временем в параллельной вселенной…

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

Что пока почитать [1]

User Story Mapping book by Jeff Patton

Impact Mapping book by Gojko Adzic

Design Thinking method (Stanfrod d.school):http://dschool.stanford.edu/dgift/

Narrative Journey Maps:http://blog.caplin.com/2010/03/04/narrative-journey-maps/

Что пока почитать [2]

The New User Story Backlog is a Map: http://jpattonassociates.com/the-new-backlog/

LeSS (Large-Scale Scrum):http://less.works

User Story Canvas: http://www.slideshare.net/_Olf/user-story-canvas-60076701

That’s all,Peace!