Привет всем, я Андрей.
Год назад мы с командой начали строить инкубатор гаджет-стартапов, в котором мы разрабатываем продукты от идеи до массового производства.
Мы фокусируемся на создании гаджетов, которые по-новому решают известную проблему.
В этой статье я хочу поделиться своим опытом и рассказать, как мы стараемся организовать процесс разработки, чтобы двигаться максимально быстро и в правильном направлении.
О процессе я расскажу на примере продукта, который совсем скоро отправится первым покупателям — берушей Veer с регулируемым уровнем шумоизоляции для тех, кто устал от постоянного шума.
За год мы преодолели немало препятствий и добились определенного прогресса.
Одно изделие доведено до запуска серийного производства( getsilence.com ), второй перед финализацией конструкции ( Tribrush.co ), третье следует отложить до волевого решения ( easymusic.club ), а также убило около 15 потенциальных продуктов на разных стадиях.
Сейчас параллельно с производством мы разрабатываем несколько концепций новой продукции.
С чего все начинается: поиск идеи
У нас идет целый процесс поиска, об этом можно было бы написать отдельную статью, но некоторые идеи рождаются почти случайно.
Например, проект Veer появился, когда мы поняли, что в нашем офисе всегда очень шумно – люди что-то обсуждают, ходят туда-сюда, фрезеруют, пилят, работают с компрессором и т. д. В таких условиях сложно сконцентрироваться на интеллектуальной деятельности.
, поэтому многие члены команды начали носить беруши.
Здесь возникли новые проблемы: когда нужно перекинуться парой слов с коллегой, а это случается часто, приходится вынимать беруши, а затем вставлять их обратно.
Процесс немного раздражает. Так возникла идея сделать беруши с регулируемой громкостью.
Мы нашли пару подобных проектов на Kickstarter, но ни один из них пока не вышел на рынок.
Учитывая, что краудфандинг часто заканчивается на стадии идеи, мы решили попробовать.
Определить, стоит ли вообще браться за проект
У нас есть ряд фильтров, которые помогают определить, стоит ли брать продукт в разработку.Первое – это компетентность.
Мы не беремся за разработку продуктов, для которых у нашей команды недостаточно компетенций ( или компетенции трудно получить) .
Второе – технологическая сложность.
У нас есть субъективная десятибалльная шкала, где 1 — лопата, а 10 — холодный ядерный синтез.
Оно сверхсубъективно и служит скорее для синхронизации восприятия.
Как правило, мы не берёмся за проекты сложность 5 и выше.
Veer по нашей шкале равен 3. Вот, например, проекты, от которых мы отказались из-за высокой сложности:
- Лапомойка .
Для владельцев крупных собак: привел собаку с прогулки, гаджет помыл ей лапы и высушил.
Существующие продукты не решают задачу полностью, мы набросали свою концепцию, но по сложности продукта идея оказалась на 6. Больше, чем хотелось бы, поэтому мы от нее отказались.
- Кошачьи отходы .
Похожая история: хотели сделать роботизированный лоток без наполнителя, который сразу после того, как кошка закончит все свои дела, будет убирать отходы в герметичный контейнер и выкатывать из лотка.
Ни запаха, ни грязи - все хорошо, но сложность не ниже 5. Тоже отказались.
для другой статьи.
Принципы дизайна
Мы часто делаем дела, которые сложно спланировать, поэтому придерживаемся двух основных принципов:- Разработчик должен выполнять самую важную задачу в каждый момент времени (речь идет не о тирании, а о приоритетах).
- Работу следует организовать разумно короткими итерациями.
Для определения наиболее важной задачи на каждом этапе имеются свои артефакты, о которых речь пойдет ниже.
Например, на старте разработки у нас было два важных требования к берушам:
- Необходимо предусмотреть возможность регулирования уровня громкости проникающего звука;
- Минимальный уровень шумоподавления – не более 5 дБ (чтобы был слышен нормальный разговор), максимальный уровень шумоподавления – от 40 дБ (чтобы наши беруши по эффективности не уступали лучшим поролоновым).
Артефакты процессов: на чем все построено?
Чтобы как-то спрогнозировать и структурировать процесс разработки, мы используем четыре документа.
Документ 1: описание задачи
В нем менеджер по продукту описывает следующие моменты:
- Какой продукт мы производим?
- Кто наши пользователи;
- Какие у них проблемы;
- Зачем им наш продукт?
- В каких случаях и как будет использоваться продукт;
- Какими свойствами должен обладать продукт?
- Какие есть конкуренты, чем они хороши и чем плохи?
- Какие свойства критичны, а какими можно пренебречь.
Затем описание можно настроить в соответствии с нашими ограничениями.
Мы используем его для оценки рисков, продумывания концепции и т. д.
Документ 2: план работы
Как правило, это диаграмма Ганта, которая отвечает на вопросы, что нужно сделать, в каком порядке это делать, что на что влияет, когда примерно проект Может быть завершенный.На этапе разработки такой план — это не какой-то документ с четкими задачами и сроками выполнения, а скорее абстракция, помогающая получить общее представление о том, что нас ждет. Здесь важнее сам процесс планирования, когда мы структурируем идею проекта, задачи, риски.
Для производства мы делаем отдельный Гант — там план становится критически важным: на его основе мы согласовываем с покупателями определенные сроки.
Здесь мы стараемся учитывать реальные риски и перезакладывание, хотя все же не можем учесть все риски.
Например, для беруш мы заказали амбушюры у китайских партнеров.
Мы обо всем договорились, назначили даты отгрузки, отсчитали оставшиеся этапы от этих дат и объявили предзаказ.
Кликабельно: 
Через две недели китайцы вернулись со словами: «Так не получится, давайте по-другому».
«По-другому» они нам не подошли, пришлось неделю искать альтернативу, платить за нее в два раза больше — в результате время доставки резко увеличилось.
Документ 3: Журнал разработки
Это приоритетный список задач, из которого мы формируем еженедельные итерации.Мы стараемся формулировать задачи так, чтобы их описание отвечало на вопрос «Какое важное свойство получит продукт, если мы выполним эту задачуЭ» Бэклог особенно актуален на этапе разработки, когда нам нужно четко понимать, что и зачем мы делаем.
Основой приоритезации задач являются потребности пользователей: чем критичнее свойство продукта для клиента, тем критичнее оно для нас.
Беруши — отличный пример, поскольку их ключевые характеристики очевидны.
Приоритеты здесь основаны на количественных, качественных исследованиях и здравом смысле: регулировка громкости, затем звуковые пороги, затем комфорт и так далее.
Делим задачи в бэклоге на требующие исследования и другие.
Например, «Анодируйте корпус беруши в черный цвет» — здесь можно использовать известные технологии; для решения проблемы не требуется никаких исследований.
И здесь " Обеспечить снижение шума на 5-40 дБ" - исследовать.
Амбушюры сильно сужают слуховой проход, поэтому для достижения нижнего порога шумоподавления в 5 дБ пришлось придумать специальную конструкцию и протестировать несколько подходов.
Документ 4: Список гипотез
Это эксперименты, которые необходимо провести для решения каждой исследовательской задачи, расположенные в приоритетном порядке.С таким списком мы работаем по HADI-подобной схеме; список составляем практически так же:
- Отбрасываем все возможные гипотезы;
- Оцениваем сложность тестирования каждого из них (отдельно для тестирования и производства);
- Мы оцениваем нашу «веру в успех» гипотезы: насколько вероятно, что она решит проблему в рамках наших ограничений;
- Общий скоринговый балл рассчитываем по формуле: время проверить гипотезу * сложность * вероятность.
По результатам важнейших тестов, если проблема не решена, переходим к следующему.
Вместо заключения
На каждом этапе разработки существует огромное количество рисков, связанных с взаимозависимостью элементов системы, а на производстве - с технологичностью изделия, подрядчиками и т. д. Каждый раз, когда возникает риск, мы учитываем его в плане в чтобы понять, где сейчас узкое место «и как меняется дата финиша.Баланса между подходами мы не нашли» давайте умножим все слагаемые на 10, тогда точно уложимся " И " Мы обязательно закончим через 27,5 дней.
«Вот почему мы всегда стараемся делать самые важные вещи за короткие итерации.
Итак, нам кажется, что мы быстрее реагируем на риски, а значит, и в целом движемся быстрее.
Будем рады, если наш опыт окажется полезным.
Пишите, если вам интересно узнать о чем-то подробнее.
Подробнее о берушах можно прочитать на официальном сайте проекта, а здесь можно оформить предзаказ со скидкой: getsilence.com Подпишитесь на нашу канал , здесь мы говорим о боли и страданиях аппаратного производства беруш Veer. Теги: #Разработка стартапа #стартап #Управление продуктом #разработка продукта
-
Как Избежать Проблем С Медицинскими Счетами
19 Oct, 24 -
Мировая Экономика
19 Oct, 24 -
Покупка Серверных Стоек Онлайн
19 Oct, 24 -
Haiku Получает Bluetooth И Beserved
19 Oct, 24 -
Ссылка Открыта!
19 Oct, 24
