Подход небольших партий в IMVU

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

Возьмите свой мобильный телефон. Скорее всего, это не самая первая модель в своей категории. Даже такие новаторские компании, как Apple, каждый год создают новые модели. Обычно в новинке присутствуют десятки новых опций (в версии iPhone 4 было более 1500 изменений).

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

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

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

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

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

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

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

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

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

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

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

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

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