Бизнес с нуля. Метод Lean Startup для быстрого тестирования идей и выбора бизнес-модели

Чтобы добиться научной чистоты эксперимента, оба каталога должны содержать одни и те же товары. Отличаться должен только дизайн. Чтобы выяснить, какой дизайн лучше, достаточно просто отслеживать объемы продаж для обеих групп клиентов. (Этот метод иногда называют A/B-тестированием, потому что каждой из версий каталога присваивалась та или другая буква.) Часто считается, что сплит-тестирование можно использовать только в маркетинге (или даже только в директ-маркетинге). Но в системе «экономичный стартап» оно включено в процесс разработки продукта.

Такие изменения сразу же позволили Фарбу взглянуть на свой бизнес по-новому. Сплит-тестирование иногда помогает выяснить удивительные вещи. Например, многие цифры, которые улучшают продукт в глазах разработчиков и дизайнеров, никак не влияют на поведение потребителей. Так произошло и в Grockit, и во всех остальных компаниях, использовавших этот метод, которые я наблюдал. Работать, проводя сплит-тестирование, кажется, труднее, потому что это требует дополнительного учета и показателей, позволяющих отслеживать каждое изменение. Но этот метод почти всегда позволяет сэкономить время, устраняя все, что не имеет значения для клиентов.

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

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

Канбан

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

Правило канбан гласит, что в каждой из четырех фаз может находиться только определенное количество историй. По мере того как истории переходят из одной фазы в другую, корзины заполняются. Если корзина заполнена, в нее не положишь еще одну историю. Только после проверки истории ее можно удалить с доски канбан. Если проверка показывает, что история неудачна, соответствующая опция удаляется (см. табл. 1, 2, 3).

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

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