Agile в стартапе — антишаблон

Несколько парней в гараже программируют день и ночь, останавливаясь только для того, чтобы поесть пиццу и поиграть в World of Tanks. Это ваша ментальная модель для стартапа? Это такой стартап, в котором основатели считают свою идею фантастической, настолько фантастической, что их самая большая проблема заключается в том, чтобы реализовать свою большую идею быстрее, чтобы они могли представить ее с большой помпой на большой вечеринке в честь запуска. Стартап, думающий таким образом, может принять Agile-подход к разработке в надежде на более быстрое строительство или, по крайней мере, получить представление о том, насколько быстро на самом деле работает команда. Но будете ли вы успешны?

Большинство стартапов основаны на открытиях

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

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

Модель бережливого стартапа

1. Опишите нашу большую идею продукта (но признайте, что это гипотеза, мы не можем предполагать, что людям это нужно)

2. Определите самые рискованные предположения, скрытые в нашей идее продукта (предположения о том, кто наши клиенты и их потребности, а также предположения о том, как они будут ценить и использовать наш продукт).

3. Выделите несколько самых больших предположений (те, которые погубили бы ваш продукт, если бы были неверными).

4. Определите подход к проверке этих предположений — тест минимального жизнеспособного продукта (клиенты, с которыми вы могли бы поговорить, и, возможно, прототипы или примеры, с которыми они могли бы работать для проверки ваших предположений).

5. Создайте свой простой прототип (и напишите несколько заметок о том, как вы будете взаимодействовать с клиентами, чтобы проверить свои предположения).

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

7. Осмыслите то, что вы узнали, и переосмыслите свою большую идею продукта

Повторяйте шаги 2–7, пока не будете уверены, что определили самый маленький продукт, который вам действительно нужно создать, или пока у вас не закончатся деньги.

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

Приведем пример как работает команда в инновационной лаборатории Nordstrom (www.nordstrominnovationlab.com).

Обратите внимание, что в Nordstrom Lab по-прежнему используются временные рамки, в данном случае 1 неделя. Но они не начинали отсчет времени, предсказывая, сколько они сделают, а имея в виду цели обучения. Затем они повторяют цикл «создание-измерение-обучение» так быстро, как только могут.

То, что в итоге получилось у команды Nordstrom, было не совсем «высококачественным программным обеспечением» — это был скорее прототип, который работал достаточно хорошо, чтобы они могли оставить его и измерить то, что имело наибольшее значение: действительно ли покупатели использовали приложение? Они на самом деле продали больше в результате? И понравился ли клиентам Nordstrom опыт покупки таким образом? Обратите внимание, что вы не увидите это приложение работающим в ближайшем к вам магазине Nordstrom. Но это не провал. Это обучение.

В чем же разница между провалом и обучением?

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

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

Сохраняйте дух Agile и игнорируйте догмы

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

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

Вернитесь к первоначальным ценностям и принципам Agile. Помните, что Scrum и экстремальное программирование — хорошие подходы к использованию Agile-мышления, но не единственные подходы. Как команда, часто задавайте себе следующие вопросы:

- Работаем ли мы вместе как команда, слаженно и эффективно?

- Делаем ли мы наши идеи видимыми быстро, чтобы мы могли быстро учиться, будь то работающее программное обеспечение или простой бумажный прототип?

- Узнаем ли мы напрямую от наших реальных клиентов, людей, которые будут покупать и использовать наш продукт?

- Часто ли мы останавливаемся, чтобы подвести итоги?

Так вы быстрее начнете обучаться, и agile-подход станет для вас не ужасным и выматывающим, а удобным и интересным.