Всем привет, я Андрей.

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

В этой статье хочу поделиться опытом и рассказать, как мы стараемся организовать процесс разработки, чтобы двигаться максимально быстро и в верном направлении. Рассказывать о процессе буду на примере продукта, который совсем скоро будет отгружен первым покупателям – беруши Veer с регулировкой уровня шумолизоляции для тех, кто устал от постоянного шума. 


За год мы набили приличное количество шишек и добились определённого прогресса. Один продукт довели до запуска серийного производства (getsilence.com), второй до финализации конструктива (tribrush.co),  третий до волевого решения отложить (easymusic.club), а ещё убили на разных стадиях около 15 потенциальных продуктов. Сейчас мы, параллельно с производством, разрабатываем несколько концепций по новым продуктам.

С чего всё начинается: поиск идеи

У нас есть целый процесс поиска, об этом можно написать отдельную статью, но некоторые идеи рождаются почти случайно. Например, проект Veer появился, когда мы поняли, что в нашем офисе всегда очень шумно – люди что-то обсуждают, ходят туда-сюда, фрезеруют, пилят, работают с компрессором и т. д. Сосредоточиться на интеллектуальной деятельности в таких условиях сложно, поэтому многие из команды начали носить беруши. Тут возникли новые проблемы: когда тебе надо перекинуться парой слов с коллегой, а это бывает часто, приходится вынимать беруши, потом вставлять обратно. Процесс немного раздражает.

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

Определяем, стоит ли вообще браться за проект

У нас есть ряд фильтров, который помогает определить, брать ли в разработку продукт. Первый — компетенции. Мы не берём в разработку продукты, для которых в нашей команде недостаточно компетенций (или компетенции труднодоступны). Второй — технологическая сложность. У нас есть субъективная десятибалльная шкала, где 1 — лопата, а 10 — холодный ядерный синтез. Она супер-субъективна и служит скорее для синхронизации восприятия. Как правило, мы не берёмся за проекты, сложность которых 5 и выше. 

Veer по нашей шкале – это 3. Вот, например, проекты, от которых мы отказались из-за высокой сложности:

• Лапомойка. Для владельцев крупных собак: привёл пса с прогулки, гаджет помыл ему лапы и просушил. Существующие продукты проблему целиком не решают, мы набросали свою концепцию, но по сложности продукта идея получилась на 6. Больше, чем нам хотелось бы, поэтому отказались.
• Кошачий туалет. Похожая история: хотели сделать роботизированный лоток без наполнителя, который сразу после того, как кот закончит все свои дела, будет убирать отходы в герметичный контейнер и выкатывать его из лотка. Ни запаха, ни грязи – всё хорошо, но сложность не меньше 5. Также отказались.

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

Принципы разработки

Мы часто делаем то, что сложно спланировать, поэтому придерживаемся двух базовых принципов:

1. Разработчик в каждый момент времени должен делать наиболее важную задачу (это не про тиранию, а про приоритеты).
2. Работа должна быть организована разумно-короткими итерациями.

Самая важная задача, как правило, та, которая обеспечивает основную пользовательскую характеристику и/или определяет основной риск — в зависимости от детализации и этапа, на котором находится разработка. Для определения наиболее важной задачи на каждом этапе есть свои артефакты, о них будет ниже.  

Например, к берушам на старте разработки у нас было два важных требования:

1. Нужно обеспечить возможность регулировать уровень громкости проникающего звука;
2. Минимальный уровень шумоглушения – не больше 5 дБ (чтобы был слышен обычный разговор), максимальный уровень шумоглушения – от 40 дБ (чтобы по эффективности наши беруши были не хуже, чем лучшие пенные).

Именно эти задачи мы закрывали в первых прототипах, а только потом уже думали об остальных задачах/рисках — как вписаться в себестоимость и размер, сможем ли мы обеспечить хороший пользовательский опыт…

Артефакты процесса: на чём всё строится?

Чтобы хоть как-то спрогнозировать и структурировать процесс разработки, мы используем четыре документа. 

Документ 1: описание задачи

В нём продакт-менеджер расписывает следующие моменты:

• Что за продукт мы делаем;
• Кто наши пользователи;
• Какие у них проблемы;
• Зачем им наш продукт;
• В каких случаях и каким образом продукт будет использоваться;
• Какими свойствами продукт должен обладать;
• Какие есть конкуренты, чем они хороши и плохи;
• Какие свойства критически важны, а какими можно пренебречь.   

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

По нему же мы оцениваем риски, продумываем концепцию и т. д.

Документ 2: план работ

Как правило, это диаграмма Ганта, которая отвечает на вопросы, что вообще надо делать, в каком порядке это делать, что на что влияет, когда примерно проект может быть завершён.

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

Для производства мы делаем отдельного Ганта — там план становится критически важным: на его основе мы договариваемся на определённые сроки с покупателями. Тут мы стараемся учесть реалистичные риски и перезаложиться, хотя все риски мы всё равно учесть не можем. Например, для беруш мы заказали амбушюры у китайских партнёров. Всё согласовали, прописали даты отгрузки, от этих дат отсчитали остальные этапы и объявили предзаказ.

Кликабельно:

Через две недели китайцы вернулись со словами: «Так сделать не получится, давайте по-другому». Их «по-другому» нас не устроило, пришлось неделю искать альтернативу, заплатить за неё вдвое больше — в результате сроки отгрузки драматически выросли.

Документ 3: бэклог разработки

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

Бэклог особенно актуален на этапе разработки, когда нам нужно чётко понимать, что и зачем мы делаем. Основа для приоритизации задач – потребности пользователей: чем критичнее свойство продукта для клиента, тем критичнее оно для нас. Беруши – очень показательный пример, потому что их ключевые характеристики очевидны.

Приоритеты здесь расставлены на основе количественных, качественных исследований и здравого смысла: регулировка громкости, потом пороговые значения звука, потом комфорт и так далее.

Мы делим задачи в бэклоге на те, которые требуют исследований, и остальные. Например, «Анодировать корпус беруши чёрным цветом» – тут можно использовать известную технологию, каких-то исследований для решения задачи не нужно. А вот «Обеспечить шумодав 5-40 дБ» — исследовательская. Амбушюры сильно сужают слуховой канал, поэтому для обеспечения нижнего порога шумоподавления в 5 дБ нам пришлось придумать специальную конструкцию и протестировать несколько подходов.

Документ 4: Список гипотез

Это те эксперименты, которые надо провести для решения каждой исследовательской задачи, расположенные в приоритетном порядке. 

С таким списком мы работаем по HADI-подобному паттерну, составляем список почти так же:

1. Накидываем все возможные гипотезы;
2. Оцениваем сложность проверки каждой из них (отдельно для тестирования и производства);
3. Оцениваем нашу «веру в успех» гипотезы: насколько вероятно, что она решит задачу в наших ограничениях;
4. Считаем общий скоринговый балл по формуле: время на проверку гипотезы*сложность*вероятность.

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

Вместо заключения

На каждом этапе разработки есть огромное количество рисков, связанных с взаимозависимостью элементов системы, а в производстве — с технологичностью продукта, подрядчиками и т. д. Каждый раз, когда риск наступает, мы учитываем его в плане, чтобы понимать, где теперь «бутылочное горлышко» и как меняется дата финиша. Мы не нашли баланс между подходами «давайте умножать все сроки на 10, тогда точно впишемся» и «стопудово закончим через 27,5 дней», поэтому и стараемся всегда делать самое важное короткими итерациями. Так, нам кажется, мы быстрее реагируем на риски, а значит, и в целом двигаемся быстрее.  

Будем рады, если наш опыт окажется полезен. Пишите, если интересно узнать о чём-то подробнее. Про беруши можно почитать больше на официальном сайте проекта, здесь же можно оформить предзаказ со скидкой: getsilence.com

Подписывайтесь на наш канал, тут мы рассказываем про боль и страдания хардверного производства беруш Veer.