Это перевод первой части цикла из четырех статей о разработке и производстве физических продуктов. Автор, источник: Ben Einstein.
Зачастую разница между компанией, приносящей миллиарды, и компанией-банкротом – в умении создать продукт, который полюбят клиенты. Но с учётом стоимостных и временных затрат в промышленном секторе, у стартапов по большому счету есть только один шанс вывести товар на рынок. У них нет возможности заниматься итеративной разработкой или позволить себе выпустить недоработанный продукт, в отличие от стартапов, разрабатывающих программное обеспечение.
Но если создание по-настоящему хорошего продукта так важно, то почему большинство промышленных стартапов при разработке продукта пренебрегают выстраиванием правильных процессов?
Эта серия статей расскажет о том, какими могут быть качественные процессы разработки физических продуктов.
Рис. 1. Типичный процесс разработки ПО
Да, процессы важны!
Похоже, что у стартапов аллергическая реакция на всё, что имеет отношение к порядку. Однако большинство стартапов, разрабатывающих ПО, поддерживает внедрение концепции «Бережливого стартапа», популяризированной Эриком Рисом.
Данный цикл «создать-оценить-научиться» укоренился в культуре ПО-стартапов, но не является исчерпывающим для продуктовых. Большинство из них понимают под процессом разработки продукта нечто подобное:
Рис. 2. Типичный процесс разработки физического продукта
Большинство стартапов полагает, что подход «у нас горят все сроки» – быстрее, поскольку он менее затратен, но в долгосрочной перспективе это далеко не так.
Рис. 3. Процесс разработки аппаратных продуктов сложнее ПО
Разработка физических продуктов требует более детального планирования, чем разработка ПО. Это объясняется огромным количеством операций, которые нужно выполнить перед запуском продукта на рынок. У большинства из них долгое время выполнения и высокая цена ошибки. Крошечный недочет в дизайне или неисправная деталь, миновавшая контроль качества, могут привести к вашему банкротству.
Процессы
Процесс, который мы используем в нашей компании BOLT – это сочетание жестких процессов производственных компаний и лёгких процессов, используемых профессиональными дизайнерами. Он делится на 4 основных стадии: формирование идеи, дизайн, конструирование и валидация.
Рис. 4. Полный цикл разработки продуктов
Для иллюстрации мы проследим за разработкой продукта DipJar по этой методологии.
Рис. 5. Первая версия DipJar
DipJar – это молодая компания с простым продуктом для сбора пожертвований и чаевых с банковской карты. Клиенты DipJar ежемесячно платят фиксированную сумму, и компания получает небольшой процент с каждой операции.
Райдер Кесслер и Джордан Бар Ам основали компанию в Нью-Йорке и подняли относительно небольшие инвестиции. При этом они успешно отгрузили много продуктов клиентам и показали хорошее соответствие продукт/рынок. Большая часть их быстрых успехов прямо связана с фокусом на итеративную разработку и интересы потребителей при разработке продукта.
ЧАСТЬ 1: ФОРМИРОВАНИЕ ИДЕИ
Рис. 6. Первый этап разработки продуктов
Формирование идеи начинается с четкого определения проблемы, которую решает продукт (problem research) и заканчивается прототипом проверки концепции (proof-of-concept prototype). Выделив достаточно времени на этот этап, вы сможете заложить прочный фундамент для дальнейшей разработки продукта.
Рис. 7. Исследование проблемы
На каждой иллюстрации показано, где мы относительно разработки продукта (сверху слева) и прошедшее времени (сверху справа).
Очень часто инженеры-основатели сразу начинают создавать продукт, не определив проблему, над которой они работают. Поймите проблему через опрос будущих клиентов.
Во время общения с потенциальными клиентами:
- Не старайтесь направить беседу в какое-либо русло. Пусть общение развивается естественно.
- Не говорите о вашем продукте или решении.
- Детально фиксируйте услышанное письменно или на диктофон для создания базы данных.
- Создайте как минимум три образа целевой аудитории (customer personas).
- Обращайте внимание не только на то, что говорят люди, но и на то, как они говорят.
Рис. 8. Найди свой момент озарения
Практически каждая компания начинается с момента «озарения» – истории, связывающей жизненный опыт основателей компании с проблемой, которую они решают. Для DipJar такой момент произошел в кофейне. Будучи студентом, Райдер часто посещал Старбакс и подружился с бариста. Как-то раз день в кофейне выдался особенно многолюдным, чему они не были рады. «По крайней мере, вы получаете больше чаевых», – заметил Райдер. Но вот какой ответ он получил: «На самом деле, никто их больше не оставляет из-за кредиток. Лучше бы вообще никто не приходил».
Всё больше общаясь с людьми, Райдер понял, что не только бариста страдают из-за уменьшения наличного оборота. Он разговаривал с уличными музыкантами, парикмахерами и благотворительными организациями (включая Армию Спасения и Children’s Miracle Network, ставшими одними из первых покупателей DipJar).
Рис. 9. Думай о портрете клиента
Такое общение служит основой для создания портретов клиентов (customer personas), обобщенных, придуманных образов ваших идеальных пользователей. Частое общение обеспечит вас данными, полезными для использования при разработке продукта.
Рис. 10. Портрет на рисунке справа лучше, так как он показывает глубину анализа проблемы.
Обычно хорошее исследование проблемы в выполнении этого чек-листа:
- Если это B2B-клиенты: вы знаете, какие люди в компании принимают решения, как они приобретают продукты, такие как ваш, и почему проблема, которую вы хотите решить – это «топ-3» проблема в их бизнесе.
- Если это B2C: вы знаете, с какими брендами они себя идентифицируют, на какой «маркетинговой территории» они проживают, понимаете их привычки.
- Вы изучили, сколько они готовы заплатить за ваш продукт.
- Вы определили размер целевой аудитории.
- Если вы планируете привлечь венчурный капитал, вы можете показать, как эти цифры принесут 100 миллионов прибыли через 5 лет.
- Если вы решили все эти задачи, вы готовы приступить к поиску решения проблемы.
Прототип проверки концепции (PoC, Proof-of-Concept)
Рис. 11. Прототип проверки концепции Proof of Concept
Суть прототипов проверки концепции – в подтверждении главных гипотез, которые выявило ваше исследование проблемы. В случае DipJar, команда должна была ответить на следующие вопросы:
- Могут ли люди понять за 5 секунд, пока они расплачиваются на кассе, как использовать DipJar?
- Важна ли возможность также собирать наличные?
- Согласны ли владельцы магазинов/работники разместить DipJar у кассы?
Рис. 12. Первые прототипы продукта
Эти вопросы крайне важны для оценки жизнеспособности DipJar как бизнеса. Команда быстро создала несколько прототипов для проверки этих гипотез. Три прототипа (на фото сверху) были созданы за несколько дней из готовых деталей (Ардуино, инфракрасные датчики, кусок алюминиевой трубы и пластиковая часть, окрашенная баллончиком)
Несмотря на то, что основной целью DipJar является списание денег с банковской карты, у команды не было времени реализовать этот функционал (и это не было важно для тестирования рабочих гипотез). Поэтому у этих прототипов даже не было кардридера. В них просто стояли датчики, подсчитывающие сколько раз люди вставляли банковскую карту.
Рис. 13. Прототипирование
Команда отнесла прототипы нескольким целевым клиентам и оставила их на один день. А потом забрала их обратно для оценки эффективности.
Выводы оценки:
- Люди сразу понимали, что такое DipJar и как им пользоваться;
- В большинстве мест наличные собирали в уже имеющиеся контейнеры – поэтому от секции для сбора наличных отказались на стадии прототипа;
- Владельцы и работники были не против выделить немного места у кассы, чтобы получить больше чаевых.
Любой процесс прототипирования является итерационным. Несколько советов, как сделать его более эффективным:
- Прежде чем что-то конструировать, сгенерируйте много идей и выберите лучшие для создания прототипа. Для этого некоторые люди предпочитают пользоваться формальными подходами: ментальные карты, мозговой штурм и т.д. По моему опыту, они уступают в эффективности неформальным: общению с людьми, макетированию, поиску похожих технических решений.
- Сконцентрируйтесь на проверке гипотез.
- Отдайте приоритет скорости, а не качеству (это сложно для инженеров, но на данном шаге скорость гораздо важнее).
- Используйте готовые детали, а не их создание с эскиза.
Теперь у вас есть хорошее понимание проблемы, и вы знаете, как ее решить. Время оптимизировать ваш продукт для использования клиентами.
Это перевод, выполненный командой фаблаба FABINKA, первой части цикла из четырех статей о разработке и производстве физических продуктов. Автор, источник: Ben Einstein. Прочитать перевод второй части.
