Бизнес с нуля: Метод Lean Startup для быстрого тестирования идей и выбора бизнес-модели.
Шрифт:
Быстро перенастраивать станки — непростая задача. В процессе перехода к методам бережливого производства существующие системы и инструменты часто приходится настраивать заново, специально для работы небольшими партиями. На первых фабриках Toyota Сигео Синго ввел систему быстрой переналадки («Замени за одну минуту или умри!»). Он увлеченно искал новые методы производства и в конце концов понял, как можно сократить время переналадки станков. Раньше она занимала часы, а теперь — меньше 10 минут. При этом рабочим не нужно было работать быстрее. Достаточно было по-новому организовать процесс. Каждое вложение в новые инструменты и процессы приносило преимущества с точки зрения сокращения размера партий.
Благодаря
Главное преимущество подхода небольших партий заключается в том, что он позволяет намного быстрее обнаруживать проблемы качества. Так на фабриках Toyota появился знаменитый «андон» [16] , позволяющий любому рабочему попросить помощи, если он заметил какую-то проблему, например брак детали, и даже остановить всю поточную линию, если его невозможно устранить немедленно. Это еще одна весьма парадоксальная практика. Конвейер работает лучше всего, когда он движется плавно, доставляя к концу линии автомобиль за автомобилем. Но андон прерывает плавное движение, и конвейер часто останавливается. Однако, как ни странно, способность быстро замечать и устранять брак повышает эффективность работы конвейера. Такой процесс непрерывного устранения дефектов оказался выгодным и для компании Toyota, и для потребителей. Именно благодаря ему Toyota поддерживает традиционно высокое качество своих автомобилей и низкие цены.
16
Андон (в переводе с японского «лампа») — это инструмент визуального менеджмента, позволяющий с одного взгляда определить состояние операций в какой-либо зоне и предупреждающий о возникновении любых отклонений. Это может быть цветная лампа, панель с кодами рабочих мест и станков или монитор. — Прим. ред.
Когда я рассказываю предпринимателям об этом методе, то часто начинаю с историй из сферы производства. Очень скоро я замечаю в аудитории вопросительные взгляды: какое отношение все это имеет к моему стартапу? Подход, лежащий в основе успеха компании Toyota, можно использовать для того, чтобы стартап мог гораздо быстрее приобретать знания, основанные на фактах.
Компания Toyota обнаружила, что благодаря подходу небольших партий ее заводы стали работать намного эффективнее. Но суть системы «экономичный стартап» заключается не в том, чтобы эффективнее производить больше товаров, а в том, чтобы как можно быстрее выяснить, как создать жизнеспособный бизнес.
Вернемся к примеру, который я уже приводил. Что, если клиенту вдруг оказался не нужен продукт, который мы производим? Эту новость нельзя назвать приятной, но лучше узнать ее раньше, чем позже. Работа небольшими партиями гарантирует, что в такой ситуации стартап может свести к минимуму потери времени, денег и сил.
В IMVU мы тоже применяли методы из сферы производства. Обычно новые версии продуктов, подобных нашему, выпускаются на рынок каждый месяц, каждый квартал или каждый год.
Возьмите свой мобильный телефон. Скорее всего, это не самая
Технологические товары часто делают на сверхсовременных предприятиях, следующих последним открытиям в сфере бережливого производства, включая работу небольшими партиями и потоками единичных изделий. Однако процесс, который используется для разработки продукта, все еще застрял в эпохе массового производства. Например, все 1500 изменений в новой версии iPhone представляют потребителям в одной гигантской партии.
В процессе разработки продукта подход больших партий все еще остается основным. Разработка происходит на чем-то вроде виртуального конвейера. Продукт-менеджеры выясняют, какие опции могут понравиться клиентам. Затем разработчики продукта выясняют, как должны выглядеть эти опции и какие ощущения вызывать у пользователя. На основе получившихся проектов создается новый продукт или модифицируется существующий. И уже он передается тем, кто проверяет, работает ли он именно так, как представляли себе продукт-менеджеры и разработчики. Для таких продуктов, как iPhone, эта внутренняя проверка может проводиться раз в месяц или раз в квартал.
Давайте еще раз вспомним пример с конвертами. Как можно более эффективно решить эту задачу?
В IMVU мы пытались проектировать, разрабатывать и создавать новые опции по очереди, используя все преимущества работы небольшими партиями. Вот как мы это делали.
С самого начала конструкторы и разработчики совместно трудились над каждой из опций. Когда опция была готова к тестированию с участием клиентов, выпускалась новая версия продукта. Она была доступна на нашем сайте относительно небольшому числу пользователей. Видя реакцию клиентов, команда могла быстро оценить результаты своей работы и решить, что делать дальше. Если изменения были незначительными, этот цикл мог повторяться несколько раз в день. В целом каждый день IMVU вводила в продукт в среднем около 50 изменений.
Как и в производственной системе Toyota, чтобы действовать с такой скоростью, нужно как можно быстрее замечать дефекты, предотвращая тем самым серьезные проблемы в будущем. Например, у нас был большой набор автоматизированных тестов, которые подтверждали, что после каждого изменения продукт все еще работает так, как нужно. Но что будет, если разработчик случайно удалит важную опцию, например кнопку «Оплатить» на одной из страниц нашего электронного магазина? Без этой кнопки пользователи ничего не смогут у нас купить. И компания тут же превратится из бизнеса в хобби. Подобно андону на заводах Toyota, в IMVU мы использовали тщательно продуманный набор защитных механизмов, которые не позволяли разработчикам случайно удалить что-то важное.
Мы назвали эти механизмы иммунной системой продукта, ведь такая автоматическая защита не просто обеспечивала нормальную работу — она позволяла держать под контролем «здоровье» всего нашего бизнеса. При этом ошибки обнаруживались и устранялись автоматически.
Возвращаясь к примеру, когда бизнес превращается в хобби, потому что с сайта пропала кнопка «Оплатить», давайте сделаем его немного более наглядным. Предположим, что разработчик не удалил кнопку, а случайно изменил ее цвет, и на сайте она стала белой на белом фоне. С точки зрения автоматизированных функциональных тестов, кнопка осталась на месте, и все работает как надо. Но пользователь не видит ее и поэтому не может ничего приобрести. Такие проблемы трудно обнаружить только с помощью автоматизированной проверки, но они грозят катастрофическими последствиями. Иммунная система IMVU запрограммирована так, чтобы быстро обнаруживать такие ошибки и автоматически приводить в действие наш аналог андона.