Комментарии 17
Главная проблема нового проекта/стартапа/бизнеса — это поток клиентов. Но в статье не говориться о том, где его взять. Здесь идет речь о том, что стартап, типа уже автоматически равен потоку клиентов, которых и нужно анализировать. Но это не так. Сам проект, без мощного маркетинга не стоит ни чего, даже если в него вложили много денег. И многие интересные проекты так и умерли, не сумев найти своих клиентов в виду дороговизны и сложности их привлечения. Вся эта «методология», что в статье, по сути — вода. Переливание из пустого в порожнее. Если бизнес уже вышел на точку прибыльности, то я более чем уверен, что справиться с ростом он сможет самостоятельно и без «эффективных» менеджеров.
Поток клиентов — это отдельная большая и важная тема, заслуживающая отдельной статьи. Исходя из нашего опыта, главная причина того, что загибается или недостаточно быстро растет стартап — это недостаточный спрос; а он часто связан именно с тем, что продукт не совсем отвечает запросам клиентов (иначе можно было бы просто скупить весь релевантный онлайн трафик), поэтому люди, если его и покупают, то только из-за отсутвия в легкой доступности других альтернатив. Поэтому хотели раскрыть механиз поиска и создания востребованного продукта, а не масштабирование успеха. Возможно, будет интересно добавить Механизмы роста, но если не уходить в глубь, они могут показаться немного поверхностными, как считаете?
Согласно Lean методологии существует три механизма роста:
1) Механизм «липкого» роста. Для таких компаний важно следить за ушедшими от них потребителями. Основное правило звучит примерно так: если коэффициент привлечения новых клиентов превышает коэффициент потери, то ваш продукт растёт.
2) Механизм вирусного роста. Определяется по вирусному коэффициенту, который показывает, сколько может привести за собой каждый новый клиент. Например, если только 1 из 10 клиентов приведёт одного нового клиента, то цикл неэффективен.
3) Механизм оплаченного роста. Заключается в дифференциации способов «монетизации» определённой группы клиентов. Пример: компания IMVU, которая привлекла клиентов, которые были способны оплачивать покупки не только с банковских карт, а ещё с помощью мобильного телефона.
Согласно Lean методологии существует три механизма роста:
1) Механизм «липкого» роста. Для таких компаний важно следить за ушедшими от них потребителями. Основное правило звучит примерно так: если коэффициент привлечения новых клиентов превышает коэффициент потери, то ваш продукт растёт.
2) Механизм вирусного роста. Определяется по вирусному коэффициенту, который показывает, сколько может привести за собой каждый новый клиент. Например, если только 1 из 10 клиентов приведёт одного нового клиента, то цикл неэффективен.
3) Механизм оплаченного роста. Заключается в дифференциации способов «монетизации» определённой группы клиентов. Пример: компания IMVU, которая привлекла клиентов, которые были способны оплачивать покупки не только с банковских карт, а ещё с помощью мобильного телефона.
Наверное смешно, но читая данную статью я вижу ту методологию, по которой работаю я уже многие годы, а до меня — тысячи инженеров-проектировщиков. Она называется — как правильно подходить к разработке продукта, если у вас нифига нет. При этом не важно, что вы разрабатываете — автомобиль, ракету или телевизор — методов просрать бабло и в результате не получить ничего очень много, а вот методов разработки, которые работают и дают гарантированный результат, всего лишь пара вариантов в мире.
Но, похоже, IT-шники придумали для себя новое название колеса и очень этому радуются.
В который раз уже.
Буквально год назад Lyft предлагал революционную более дешевую замену такси:
Да-да, вы правильно прочитали, они переизобрели автобус.
Теперь вот переизобретают Waterfall, говоря о том, что надо сначала определиться с ТЗ, а потом начинать что-то по нему делать.
Буквально год назад Lyft предлагал революционную более дешевую замену такси:
Lyft Shuttle lets you pay a fixed rate along predetermined routes during commute hours. The routes have set pickup and drop-off locations. They will only stop at predetermined locations, not just anywhere. You select the shuttle option; walk to meet your driver; they drive you for a bit; then when they let you out, you walk the rest of the way to your final location. “Walk to stop. Hop in. Hop out. Walk to destination.
Да-да, вы правильно прочитали, они переизобрели автобус.
Теперь вот переизобретают Waterfall, говоря о том, что надо сначала определиться с ТЗ, а потом начинать что-то по нему делать.
Все верно, только в Lean обычно применяют разновидности Scram, а он очень существенно отличается от Waterfall…
Спасибо, что заметили опечатку и пояснили свою позицию.
Действительно, часто переизобретают существующие вещи, делая их более полезными или простыми, но то, что Scrum это переизобретение Waterfall не можем согласиться.
В Scrum идет разбивка проекта на значительно более мелкие этапы, каждый из которых проверяется в бою, а результаты и обратная связь от пользователей используются для изменения описания продукта до завешения разработки. То есть во главу ставится создание продукта в соответствие с реальными запросами конечных пользователей, а не представлениями о них в ТЗ.
Тогда как в Waterfall — главное выполнение ТЗ и соответствие финального продукта этому ТЗ, не редко в разрез здравому смыслу.
Действительно, часто переизобретают существующие вещи, делая их более полезными или простыми, но то, что Scrum это переизобретение Waterfall не можем согласиться.
В Scrum идет разбивка проекта на значительно более мелкие этапы, каждый из которых проверяется в бою, а результаты и обратная связь от пользователей используются для изменения описания продукта до завешения разработки. То есть во главу ставится создание продукта в соответствие с реальными запросами конечных пользователей, а не представлениями о них в ТЗ.
Тогда как в Waterfall — главное выполнение ТЗ и соответствие финального продукта этому ТЗ, не редко в разрез здравому смыслу.
В Scrum идет разбивка проекта на значительно более мелкие этапы, каждый из которых проверяется в бою, а результаты и обратная связь от пользователей используются для изменения описания продукта до завешения разработки
Проблема в том, что такое легко работает в software, что собственно и породило этот подход, но сейчас все больше и больше стартапов лезут в hardware — IoT и прочее и там так не получится (смотрите вторую картинку в комментариях ниже). Создавая автомобиль, надо разрабатывать двигатель, шасси, кузов, и только потом собирать автомобиль вместе, а не сначала разрабатывать скейтборд, потом велосипед, потом мопед, постоянно проверяя обратную связь от пользователей — так вы до автомобиля и не дойдете никогда, так как реальные запросы пользователей будут постоянно меняться, а деньги — таять.
И поэтому Lean startup пытается подвести IT-шников именно к этой мысле — проверь основные гипотезы, что другими словами означает "сделай внутреннее ТЗ", а потом уже начинай клепать продукт. Т.е определи сразу, что пользователи хотят все же автомобиль, а не велосипед и начинай делать его сразу же, пропустив скейтборды и мопеды.
Но тогда скрам фактически не нужен, так как обратная связь от пользователей больше не нужна до того, как появится первый экземпляр автомобиля — следовательно следующим изобретением lean startup станет waterfall.
но то, что Scrum это переизобретение Waterfall не можем согласитьсяЯ не говорил, что Scrum — это переизобретение Waterfall. Я имел в виду ровно то, о чем сказал уважаемый Lingvo — что, пытаясь переносить чисто софтварные практики в другие области, люди незаметно для самих себя возвращаются к «устаревшим в IT», но вполне пригодным (и иногда единственно возможным) в железе методикам.
В Scrum идет разбивка проекта на значительно более мелкие этапы, каждый из которых проверяется в бою, а результаты и обратная связь от пользователей используются для изменения описания продукта до завешения разработки. То есть во главу ставится создание продукта в соответствие с реальными запросами конечных пользователей
Простой пример из моей работы — разработки микросхем. Минимально возможная разбивка на «мелкие этапы, каждый из которых проверяется в бою» дает около девяти месяцев на каждый «мелкий этап». Половину времени при этом занимает собственно изготовление образцов, то есть три месяца — спринт дизайна, потом три месяца ждем результаты с фабрики, потом еще три месяца измеряем полученные образцы. На разработку от идеи до передачи продукта в серийное производство есть два года.
Как такое делать по Scrum? Правильно, никак.
Как такое делать по Lean? Правильно, с самого начала максимально точно понять требования пользователей, чтобы с первой же итерации получить то, что нужно, потом на второй исправить баги и орбратную связь пользователей по итогам первой итерации, и уйти в продакшен.
А что такое «с самого начала максимально точно понять требования пользователей»? Правильно — это называется «Техническое задание», оно же «а вот и ваш незаметный возврат к Waterfall».
Waterfall — главное выполнение ТЗ и соответствие финального продукта этому ТЗ, не редко в разрез здравому смыслу.Ну нет, сам Waterfall ни в чем не виноват, против здравого смысла идут люди, и таким людям никакой Scrum не помешает делать фигню вместо работы.
Ну да, а я начну смеяться, когда они переизобретут ROI и бизнес-план:
- Эй чувак, я ж говорил, что мы в минус уйдем, пока релиз 1.0 выпустим!
- Эээ, так а насколько в минус? Может надо было кредит взять?
- Ну да, а что теперь делать, когда разработчикам зарплаты платить больше нечем?
Так для США общественный транспорт это действительно инновация. Важно не что ты продаешь, а как…
Lean, вообще-то, начинался еще с Форда. Так что его инженерные корни вполне себе обоснованы.
интересно, как применять lean, если мой продукт, например, автомобиль
Главная проблема нового проекта/стартапа/бизнеса — это поток клиентов.
Это верно, но как одна сторона монеты. Есть у монеты «орел», да, эта сторона монеты важная. Но есть и «решка», это прямо противоположная по смыслу сторона монеты. Обе стороны — важные и нужные. При разговоре. Но экономический смысл имеет не наличие у монеты орла или решки, а сам металл, из которого монета сделана. Это пример разных «аспектов» (ISO 81346), для одного объекта. Для бизнеса установлено в этих же стандартах много иных «аспектов». Только один «аспект» — это все, что касается «потока клиентов». Есть еще масса иных аспектов. Примеры и детали — в модели GERAM (ISO 15704).
Пример из практики: хлеб из пророщенного зерна. Клиентов — куча. Все хотят купить. Но аспект «технология (инженерия)» и аспект «организация (поставки)» — сложные, пока не доработаны. Поэтому бизнес идет медленно.
Другой пример, из IT, разработка множества проектов краудфаундинговыми схемами. Покупатели — есть. Поставщики — куча. Контрактных производителей — еще больше. Но никак не запустят производство и все не свяжут. Причина: не хватает опыта управления проектами (организационный аспект).
Кстати, весь смысл статьи и подхода можно определить, как: расширенное и доработанное применение цикла Деминга — это хорошо и позволяет получать неплохие результаты в IT проектах. Для инженеров — это обычная практика. Описаны в книге
Wasim — Standards for engineering design and manufacturing. 2006. Обратите внимание на год выпуска, если что.
Плюс методы подстройки (бриколаж), они описаны у Николаса Талеба в книге «Антихрупкость».
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Береги свой бизнес смолоду или как создать бережливый стартап