Канбан для управления продуктом

В данной статье мы поговорим о Канбане. Меня зовут Алексей, и я, вероятно, не первый, кто принес Канбан Метод в Россию. Но, возможно, тот, кто больше всего способствовал его развитию здесь.

Важно отметить, что существует два различных Канбана. Первый – это тот, который используют IT-специалисты, включая разработчиков на платформе 1С. Второй – тот, который применяется в производственных системах, таких как Toyota Production System и бережливое производство. Это два независимых разных инструмента. Сегодня мы сосредоточимся на первом подходе, который зародился относительно недавно в компании Microsoft.

Канбан и управление продуктом

Начнем с некоторого нарратива. Существует наука управления продуктом и даже профессия продакт-менеджеров (менеджер по управлению продуктом). Возникает вопрос: при чем здесь Канбан, если у продакт-менеджеров есть множество других инструментов, таких как customer development, глубинные интервью, юнит-экономика и так далее. Дело в том, что профессия названа хитро. Если бы мы назвали программистов код-менеджерами, а аналитиков – менеджерами требований, то возник бы вопрос, зачем нужны тимлиды, наука менеджмента и наука управления проектами. Здесь та же самая история.

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

Диалог с продакт-менеджером

Общаясь с продакт-менеджером одной из крупных компаний, я услышал вопрос: «Алексей, зачем мне вообще этот Канбан?».

– А как вы работаете сейчас? – спросил я.

– У нас есть бэклог, и мы его приоритезируем, используя подход RICE.

– RICE – это же четыре цифры? Чтобы получить эти цифры, нужно что-то сделать?

– Да, это так, – подтвердил он.

– Бывает так, что, получив одну из этих цифр, понимаешь, что дальнейшие цифры получать смысла нет?

– Конечно, бывает.

– Бывает и так, что какие-то из этих цифр получаешь не ты, а твой коллега?

– Да, бывает.

И тут уже выстраивается целый процесс работы.

Сквозной поток создания ценности

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

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

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

Точка принятия обязательств

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

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

Отсев идей в процессе реализации

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

Если рассматривать схему глобально, то слева находится процесс, в котором нужно понять, что конкретно сделать, а справа – процесс, в котором мы понимаем, как это сделать. Левый процесс называется Product Discovery, а правый – Product Delivery.

Метрика Discard Rate

Существует метрика, которая называется Discard Rate (дискард-рейт). Это процент запросов, которые вошли в какую-то часть производственной системы, относительно тех, которые вышли. В левой части, в Product Discovery, дискард-рейт должен быть достаточно большим – 90-95%. Почему? Потому что директор по продукту хочет, чтобы мы рассмотрели максимум идей, но выбрали из них только самые ценные. В процессе Product Delivery этот процент отвала идей должен быть маленьким. Если он будет большим, это значит, что мы растрачиваем деньги впустую.

Дискард-рейт может быть большим, например, если вы все делаете через A/B-тесты. По сути, вы одну и ту же идею реализуете двумя разными способами, от одного из которых потом отказываетесь. Условно говоря, в самом простом приближении это значит, что вы тратите очень много денег.

Shift Left в разработке

В разработке существует концепция shift left, когда мы пытаемся сдвинуть определенные процессы влево по воронке. Здесь та же самая история. Чем лучше работает продакт-менеджмент, чем лучше работает процесс Product Discovery, тем меньше ненужных идей проходит через точку принятия обязательств, и тем меньше их отсеивается уже на этапе непосредственной разработки.

Метрика time-to-market

С точки зрения метрик мы можем представить процесс от момента захвата идеи до момента решения проблемы клиента. Эта метрика известна как time-to-market. Часто ошибочно говорят, что time-to-market нужно увеличить, хотя на самом деле все хотят его снизить, чтобы идеи реализовывались как можно быстрее.

По точке принятия обязательств time-to-market можно разбить на две части:

1. Время от точки принятия обязательств до реализации потребности клиента. Это время называется временем производства или lead time.

2. Время от возникновения идеи, ее проработки до принятия решения о реализации. Это время называется time to discover или time to decision. В разных источниках можно встретить разные названия.

Процесс Product Discovery

Теперь, когда я нарисовал всю картину, можно сказать, что процесс Product Delivery, который справа, нам не нужен. Мы сосредоточимся на левой части – Product Discovery. Здесь очень важно понять, какие знания нужно получить, чтобы определить, что должно быть сделано, а что делать не нужно.

Можно задать простые вопросы людям, задействованным в процессе управления продуктом. Например: «Что нужно сделать, чтобы понять, что эту фичу нужно реализовать?» Ответы могут включать уточнение потребностей клиента, расчет экономики, обсуждение с IT-специалистами для оценки реализуемости на платформе, учет зависимостей, расчет и утверждение бюджета на комитете. Все это порождает множество активностей.

Чтобы не ограничивать вас этими активностями, я просто удалю их, оставив пустые стикеры.

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

Понятие триажа

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

Процесс триажа

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

1. Оперировать срочно: этот человек должен быть прооперирован неотлагательно.

2. Оперировать позже: этого человека можно прооперировать позже, сейчас не обязательно им заниматься. Его можно даже отвезти в какой-то удаленный госпиталь в тыл, и он даже может сам на своих двоих туда дойти.

3. Не стоит заниматься: этот человек ранен настолько, что мы только потратим лишние силы, пытаясь его спасти. Доктор сказал «в морг», значит, в морг.

Триаж в управлении продуктом

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

Эволюция бэклога

Давайте вспомним, чем обычно оперируют. Обычно используется планарный список, который называется бэклог. Однако бэклог – это просто огромное количество знаний и целый процесс, спрятанный в черной дыре. Бэклог – это прекрасная идея, но только для начала 2000-х годов, когда было хорошо собрать все клиентские запросы в один планарный список и создать механизм сортировки, при котором что-то поднимется наверх. К середине 2015-2016 годов это обернулось тем, что у многих бэклог содержит 300-800 рабочих элементов, которые никогда не будут реализованы. Продакт-менеджеры даже не задумываются о прочистке этого бэклога и удалении оттуда чего-либо.

Я хочу, чтобы эта концепция была пересмотрена. Рассматривайте процесс работы с продуктовыми идеями не как бэклог, а как целый процесс.

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

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

Например, если идея по первичной оценке экономики принесет 10 миллионов, а наша стратегия отбрасывает все идеи, которые приносят менее 50 миллионов, то такая идея отбрасывается. Если же расчет показывает 70 миллионов, значит, идея достойна дальнейшего рассмотрения.

Гибкость процессов в Product Discovery

Есть еще одна важная вещь, которая сильно отличает процесс управления в части Product Discovery от Product Delivery. В Product Delivery менять этапы местами очень сложно, практически невозможно. Представьте процесс: анализ, разработка, тестирование. Поставить тестирование перед анализом будет сложно. В Product Management с этим чуть проще.

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

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

Визуализация процесса

Это не бэклог, а доска с набором активностей. Причем раструб воронки большой, и его нужно свести к параметрам производственной системы. То есть дать добро большему количеству рабочих элементов, чем может быть теоретически пропущено через ваши delivery-команды. Это значит, что у вас где-то в середине производственного процесса есть буфер, в котором скапливается огромное количество работы. Time-to-market растет из-за этого, работа скапливается, а вы не получаете никакой прибыли. Time-to-market становится непредсказуемым.

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

В Канбан Методе есть такой инструмент как ограничение количества незавершенной работы. Вы, возможно, слышали о нем. Он называется WIP-лимит (Work In Progress limit). Такой способ отображения этих лимитов получил название виртуальный Канбан.

Если мы можем понять, можно ли какую-то работу куда-то двигать, путем вычитания количества карточек в какой-то активности из цифры, которая написана над этой активностью, то мы получаем сигнал о том, что можем взять еще что-то в проработку, анализ экономики, обсуждение с IT-командой или на продуктовый комитет. Однако есть одна проблема: люди, задействованные в процессе Product Discovery, также участвуют и в процессе Product Delivery. Например, продакт-менеджеры могут ходить к IT-специалистам в правую часть воронки, заниматься приемкой и разъяснительными действиями, объясняя, что и зачем делается, так как у IT-специалистов может быть много вопросов.

Эти IT-специалисты также должны приходить в левую часть воронки, так как некоторые активности требуют общения с ними по поводу времени, необходимого для выполнения работы, зависимостей, технических рисков реализации и возможных альтернативных способов реализации. С этой точки зрения, если посмотреть на Канбан Метод, он работает следующим образом: самая приоритетная работа находится как можно правее на доске. То есть реализация того, что уже готово к разработке, гораздо важнее, чем взятие какой-то идеи с рынка.

Возникает вопрос: что делать, если продакт-менеджеры ушли заниматься приемкой в Delivery-командах, а работа на этапах Product Discovery застряла? То есть новая работа не добавляется, IT-специалисты набирают себе работу, и внезапно IT-команды остаются без задач.

Проблема распределения ресурсов

Для нас это очень стрессовая ситуация, когда IT-команда останавливается из-за отсутствия требований на реализацию. Это неправильная ситуация, и нам нужно правило, по которому продакт-менеджер будет сигнализирован о том, что ему нужно бросить приемку и вернуться в процесс Product Discovery, чтобы подготовить данные. То же самое касается IT-специалистов: у них должен быть сигнал, по которому они должны прийти в правую часть и что-то там решить.

Здесь также есть большое отличие в лимитах, которые мы используем для визуализации того, что что-то может быть взято в этап. В процессе Product Discovery эти лимиты диапазонные.

Во-первых, диапазон позволяет разбить какую-то продуктовую идею на несколько гипотез. То есть количество гипотез из какой-то идеи может быть множественным. Поэтому здесь есть верхний лимит. А нижний лимит – это сигнал к тому, что человек должен бросить работу в процессе Delivery, прийти в процесс Discovery и выполнить работу там.

Резюме: ключевые выводы

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

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

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

3. Параметры этого триажа мы должны брать из продуктовой стратегии. Возможно, это будет соотноситься с теми OKR-ами, которые вы ставите, или KPI-ами, которые у вас спускаются. То есть это должно быть связано с реализацией продуктовой стратегии.

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

*************

Статья написана по итогам доклада (видео), прочитанного на конференции Анализ & Управление в ИТ-проектах.