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

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

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

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

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

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

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

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

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

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

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

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

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

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

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