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

В процессе разработки продукта подход больших партий все еще остается основным. Разработка происходит на чем-то вроде виртуального конвейера. Продукт-менеджеры выясняют, какие опции могут понравиться клиентам. Затем разработчики продукта выясняют, как должны выглядеть эти опции и какие ощущения вызывать у пользователя. На основе получившихся проектов создается новый продукт или модифицируется существующий. И уже он передается тем, кто проверяет, работает ли он именно так, как представляли себе продукт-менеджеры и разработчики. Для таких продуктов, как iPhone, эта внутренняя проверка может проводиться раз в месяц или раз в квартал.

Давайте еще раз вспомним пример с конвертами. Как можно более эффективно решить эту задачу?

В IMVU мы пытались проектировать, разрабатывать и создавать новые опции по очереди, используя все преимущества работы небольшими партиями. Вот как мы это делали.

С самого начала конструкторы и разработчики совместно трудились над каждой из опций. Когда опция была готова к тестированию с участием клиентов, выпускалась новая версия продукта. Она была доступна на нашем сайте относительно небольшому числу пользователей. Видя реакцию клиентов, команда могла быстро оценить результаты своей работы и решить, что делать дальше. Если изменения были незначительными, этот цикл мог повторяться несколько раз в день. В целом каждый день IMVU вводила в продукт в среднем около 50 изменений

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

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

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

Если наша иммунная система обнаруживает проблему, тут же происходит следующее:

1. Угрожающие изменения автоматически удаляются.

2. Все члены команды, допустившей ошибку, получают уведомление о проблеме.

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

В IMVU мы назвали этот метод непрерывным развертыванием, и даже в очень динамичном мире разработки программного обеспечения он до сих пор считается спорным. Но движение «экономичный стартап» набирает обороты, и этот метод все чаще берут на вооружение. Среди последних примеров — компания Wealthfront, вираж которой был описан в главе 8. Используя непрерывное развертывание, она проводит каждый день более десятка проверок новых опций с участием пользователей.

Непрерывное развертывание в разных отраслях

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

1. Аппаратные средства превращаются в программное обеспечение. Давайте вспомним, что произошло в сфере бытовой электроники. Самые современные телефоны и планшеты — это просто экраны, соединенные с Интернетом. Почти вся их ценность заключается в программном обеспечении. Даже ценность продуктов «старой школы», например автомобилей сегодня во многом определяется программным обеспечением, которое есть у них внутри и управляет всем — от музыкального центра до двигателя и тормозной системы. А возможности программного обеспечения можно изменить намного быстрее, чем механические устройства.