Контролируйте поток внедрения новых элементов

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

Для этого отлично подойдет такой инструмент, как доска Канбан[1] (Kanban), называемая также визуальной доской.

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

На рисунке 13-2 изображена простейшая доска Канбан с разбивкой на три группы.

Рисунок 13‑ 2. Простейшая доска Канбан

Общая идея заключается в следующем6 новый элемент/характеристика появляется в левой части доски и проходит через все стадии разработки продукта и клиента, пока не переходит в состояние «Закончено».

[1] Система планирования Канбан (Kanban) была разработана Таичи Оно (Taiichi Ohno), отцом производственной системы Toyota. Система Канбан говорит вам что необходимо производить, когда это производить, и в каком количестве. (Английский текст цитируется по https://en.wikipedia.org/wiki/Kanban).

Кратко рассмотрим три основных этапа процесса, изображенного на рисунке 13-2.

1. Очередь

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

• Улучшение существующих элементов (например, адаптация процесса подписки)
• Запросы пользователей
• Ваши пожелания (например, из отложенных ранее «желательных» характеристик)

Прежде чем двигаться дальше, необходимо пояснить разницу между минимальным значимым элементом, МЗЭ (minimal marketable feature, MMF) и небольшой правкой/исправлением ошибок. Термин МЗЭ впервые был введен в книге Software by Numbers, написанной Марком Денном и Джейн Клиланд-Хуан (Marc Denne, Jane Cleland-Huang, Prentice Hall) и определялся как наименьшая работа, дающая ощутимое преимущество для пользователя (таким образом, речь идет о любых характеристиках, значимых с точки зрения маркетинга).

Говоря о «характеристиках» или «элементах», я всегда имею в виду МЗЭ. В качестве теста на то, является ли новый элемент МЗЭ, спросите себя – будете ли вы анонсировать его появление у себя в блоге или журнале? Если он слишком мелок для упоминания, это – не МЗЭ.

МЗЭ обычно состоит из более мелких задач, которые, если вы практикуете систему Непрерывного Внедрения, составляют ваши минимальные порции для внедрения. Небольшие правки и исправления ошибок обычно входят в состав таких мелких задач.

Я использую доску Канбан только для отслеживания МЗЭ, а для задач более мелкого масштаба – облегченный инструмент мониторинга (типа Pivotal Tracker).

1. В работе

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

Ключевой принцип Канбан, позволяющий контролировать процесс внедрения, состоит в том, что вы ограничиваете максимальное число элементов, одновременно находящихся в процессе внедрения. Это позволяет вам максимизировать полезный выход и минимизировать нерациональную трату ресурсов. Тех, кому интересна технология этого процесса в деталях, я отошлю к книге Дональда Рейнертсена (Donald Reinertsen) The Principles of Product Development Flow (Celeritas Publishing), где всё это очень понятно и глубоко изучено.

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

1. Закончено

Когда внедрение нового элемента завершено, он перемещается в группу «Закончено». Статус «Закончено» не совсем однозначен и разные группы разработчиков могут вкладывать в это совсем разное – от «кодирование завершено», до «протестировано» или «внедрено».

В терминах Рационального Стартапа, однако, статус «Закончено» присваивается только тому элементу, по которому вы получили ясную обратную связь от потребителя.

Рисунок 13‑ 3. Получение обратной связи по внедренным характеристикам

По этой причине Эрик Рийс предлагает либо внести получение обратной связи в определение фазы «Закончено», либо добавить для этого отдельную, четвертую группу обработки. Как мы увидим дальше, я пользуюсь промежуточным решением и провожу двухступенчатую проверку внедренного элемента: сначала качественную, потом – количественную.

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