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

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

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

Канбан

Таблицы перехода из одной фазы в другую

(В корзине не может быть больше трех проектов одновременно.)

Таблица 1

Исходные данные	Создание	Завершение	Проверка
А	D	F
B	E
C

Работа над А начинается. D и Е находятся в фазе создания. F ждет проверки.

Таблица 2

Исходные данные	Создание	Завершение	Проверка
G		D	F
H	B	E
I	C	A

F проверяется. D и Е ждут проверки. G, Н, I — новые задачи, которые нужно выполнить. В и С в фазе создания. А в фазе завершения.

Таблица 3

Исходные данные	Создание	Завершение	Проверка
	G	D	F
H->	B->	E
I->	C->	A

Опции В и С уже созданы, но по правилу канбан их нельзя переместить в следующую корзину, в стадию проверки, пока не пройдут проверку А, D и Е. Нельзя начать работу над опциями Н и I, пока не освободится место в следующей корзине.

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

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

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

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

Тестирование гипотезы в Grockit

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