Бережливый стартап или как мы используем концепцию Lean Startup в своих проектах

Создание чего-то нового — дело всегда рискованное. Как и многие люди до вас, вы пишете бизнес-план, предлагаете его инвесторам (либо роетесь в собственном кошельке), набираете людей, начинаете разрабатывать продукт, тратите тысячи человеко-часов. А потом, спустя месяцы разработки (а иногда и годы) получается, что вы всё это время усиленно делали продукт, который никому не нужен. Вот вообще. А деньги и время уже потратили.

Как понять, что ваш продукт не будет успешен, не затрачивая при этом значительные материальные ресурсы и не теряя годы на его разработку? Вы наверняка слышали о бережливом стартапе как удачном способе реализовать слабую (читай — не очень обоснованную), но перспективную идею. Концепция бережливого стартапа, lean startup — это когда вы запускаете собственную модель бизнеса без огромных трат на старте

В этом посте расскажем, как мы в компании «Автомакон» применяем успешные практики из Lean Startup (несмотря на то, что многие наши проекты вполне сформировались и устоялись), с какими проблемами сталкиваемся и как с ними справляемся.

У «ВкусВилл» есть книжный клуб для сотрудников, в рамках которого часто обсуждаются те или иные книги. И нас часто приглашают поучаствовать в нем. На одном из таких собраний обсуждалась книга Эрика Риса «Бизнес с нуля. Метод Lean Startup для быстрого тестирования идей и выбора бизнес-модели».



Как раз в то время мы строили совместно с «ВкусВилл» новую продуктовую платформу: «Тилси», она должна была соединить магазины и поставщиков продуктов с коротким сроком годности, объединить функционал для конечного потребителя, логистов, дистрибьютора, производителей, склада в одном месте.

Работа по классике

С самого начала проекта «Тилси» началось выстраивание платформы с космическими требованиями:

• Высоконагруженная система;
• Всё пишем на Golang;
• Создание теоретических бизнес-процессов.

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

Прикинув в теории все возможные плюсы от разработки продуктовой платформы по lean-модели, мы поняли, что надо смотреть в эту сторону, и сменили подход.

Работа по линам

Вот что сделали:

• Отказались от всего, что сделали ранее. На коленке сделали в CMS самые примитивные, но работающие процессы. За месяц сделали MVP и запустили для проверки гипотез и начали получать первых пользователей: магазины, поставщики, конечные покупатели.
• Затем пытались тестировать разные гипотезы. Протестировали много чего, но гипотезу ценности не подтвердили. Пытались сделать вираж, но все же в определенный момент приняли решение закрыть проект в текущем виде.
• Итого нам удалось потратить не так много денег и времени (порядка 1 млн. и 2 месяца), а главное — вовремя понять, что проект не взлетит, и сфокусироваться на другом.

Кроме этого мы использовали подход Lean Startup в «Зеленой линии», совместном проекте «ВкусВилла» и «Перекрестка» по запуску новой линейки натуральных молочных продуктов с ультракоротким сроком годности. Он так и назывался, «Маркет. Зеленая Линия» В рамках проекта мы протестировали много гипотез. Подтвержденные гипотезы ценности позволили сэкономить кучу денег и времени, а неподтвержденные — не тратить ресурсы на тупиковые направления.

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

С экономией по времени и ресурсам подходим теперь и к вопросу автоматизации. Какие-то вещи не автоматизируем совсем, собираемся и думаем, как в короткий срок (скажем, за день) сделать новый сервис. Например, раньше многие возвраты в системе оформлялись вручную, и подобные функции перекладывались на поддержку. Если таких обращений у вас в компании мало, раз-два и обчелся, тратить силы на их автоматизацию не стоит, проще руками. А вот если статистика говорит, что обращений по конкретной проблеме уже много, тогда ту или иную функцию есть смысл автоматизировать.

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

На чём стоит Lean Startup

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

Поэтому «Дешево, быстро, хорошо» оказывается штукой, которую можно написать в тексте, но нельзя увидеть в работе. Если у вас большая компания, у которой более чем достаточно ресурсов, причем как материальных, так и временных, то для вас отлично подойдет триада Тёмы Лебедева, которую мы бы процитировали, но нас за нее забанят.
А если у вас стартап в принципе, или же стартапная разработка продуктов внутри большой компании, то бюджет и время надо считать.

Не дешево, а экономно

Lean-концепция предлагает тратить лишь необходимое количество денег. Причем подобное бережливое отношение тут распространяется не только на деньги, но и на остальные ресурсы компании — на сотрудников и на время.

Каждый рубль, каждый час сотрудника должны тратиться с умом. Здесь не получится взять и бросить команду на создание какой-то части продукта, сжечь пару КАМАЗов денег в процессе, а через полгода понять, что не взлетело. И пойти делать новый продукт.

Суть подхода

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

Это важно, ведь это касается интереса людей к продукту, его нужности, как следствие — спроса. Вы можете сделать великолепный по своим ТТХ смартфон. Открыть кофейню с лучшим кофе в мире.

Только это вообще не выстрелит, если у вас смартфон работает на проприетарной ОСи, в магазине которой 10 приложений и дичайший вендор-лок, не дающий сделать вообще ничего. А кофейня стоит на острове, где из посетителей только смотритель маяка, которому врач кофе запретил.

В общем, примеров много, вы наверняка вспомните, как какая-то компания пыталась что-то выводить на рынок. Вроде и неплохое, но просто не нужно. Вот это «не нужно» и должно отлавливаться на самом старте.

Итак, вы изучили рынок и нужды потребителей, провели эксперимент. Теперь у вас есть собранные количественные и качественные результаты, которые позволят ответить на 5 ключевых вопросов.

Соответствует ли продукт нуждам потребителей?

На самом деле он нужен, или команда убеждает себя в этом и делает неправильные выводы? Тут нужно подходить к делу максимально объективно, абстрагируясь от своего отношения к продукту.

Как потребители решали подобную проблему раньше?

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

Какие издержки потребители сегодня несут из-за этой проблемы?

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

Нужно ли адаптировать или изменить ваш продукт?

Отдельным пунктом небольшое следствие из ответов на все предыдущие пункты. Вот вы оценили соответствие продукта потребностям. Присмотрелись к аналогам. Разобрались в том, как люди жили до появления вашего продукта. Теперь вопрос — учитывая все это, вы оставите свой продукт в первоначальном виде или, возможно, стоит внести пару правок?

Если точно всё ОК, то переходим к пятому вопросу.

Готовы ли вы масштабировать его?

Допустим, все здорово, и у вас или сразу получилось что-то отличное, или вы вовремя допили продукт до такого состояния. Надо быть готовым к масштабированию — продукт-то успешный (если вы честно ответили на вопросы выше). Значит, спрос будет. И он будет увеличиваться.

Осилит ли компания масштабирование? Хватит ли времени и денег, рук разработчиков, потянет ли инфраструктура возросшую нагрузку?

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

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

Один из важных принципов Lean. Вы же не думали, что можно просто запустить какой-то отличный продукт, выдать всем премии и пойти смотреть, как оно все само по себе работает, оставаясь таким же отличным?

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

Поэтому тут необходимы непрерывность инноваций и постоянное совершенствование. Собственно, все как в жизни.

Гибкость

В книге есть хорошая аналогия про гибкость и про ее важность для вашего продукта. Запуск ракеты в космос против поездки на авто.

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

С авто попроще. Пошел дождик — включил дворники. Пробка на дороге — поехал немного в объезд. Позвонил кто-то не очень интересный — заехал в тоннель, где связи нет.

Вот с продуктом такая же история, как с авто. Вы постоянно оцениваете окружение, смотрите на действия других участников процесса, подстраиваетесь под ситуация и не выпускаете руль.

Если подходить к созданию продукта как к запуску ракеты, а многие компании так делают, то вы рискуете передать его по наследству в виде наброска. Он получится у вас только чудом, когда все переменные внезапно совпадут. Потому что тут вы отталкиваетесь от предположений, которые не факт что вообще случатся.

А руль дает вам возможность подстроиться под то, что уже точно случилось

— Погодите, это же постоянный MVP

Это постоянно развивающийся MVP. Вы сделали первую версию MVP, она сработала, приносит людям пользу, бизнесу деньги, а вам — обратную связь от пользователей. И благодаря обратной связи (а ее получение это постоянный процесс) вы все время фиксируете соответствие вашего продукта ожиданиям. Если какие-то добавочные гипотезы не подтверждаются в процессе использования продукта — отказывайтесь от них. Не тратьте деньги компании и время сотрудников на то, чтобы поддерживать фичу, которая не нужна.

Это и есть бережливость.

Что еще важно

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

Работайте с обратной связью. Это постоянный статус вашего проекта.

Эксперименты. Не бойтесь проводить их снова и снова. Посмотрите, сколько больших компаний вокруг используют A\B-тестирование. Вспомните, сколько разных версий интерфейса Facebook прямо сейчас показывается различным сегментам пользователей. Это все эксперименты, это все проверки тех или иных гипотез.

Это постоянные инновации, которые обеспечивают постоянный прогресс.

Итого

Настоятельно рекомендуем обратить внимание на концепцию Lean Startup. Из IT вы или нет, большие у вас бюджеты или собственные сбережения на продукт, методология пригодится.

Вот наши выводы от использования подхода на практике:

• Лины работают. И работают хорошо.
• Но лины не панацея, подход не поможет поднять любой проект. Скорее, наоборот — концепция поможет быстрее закрыть тупиковый проект, а не жить в иллюзии, что он клёвый. Что тоже очень полезно.
• Ограниченное трактование линов может завести в другую крайность — все процессы будут строиться на MVP. Зачем рефакторить, ведь все и так работает. Но есть большой риск, что в определенный момент это все может рухнуть. Поэтому использовать лины надо грамотно. Запустили MVP, подтвердили гипотезу ценности, дальше проанализировали — надо ли делать нормальный продукт.

Кстати, мы сейчас активно расширяем команду, которая активно применяет Lean-подход. Вот тут можно посмотреть полный перечень вакансий — hh.ru / наш карьерный сайт

Будем рады ответить на ваши вопросы.