Коллеги, доброго времени суток.
Осенью 2018 года ваш покорный слуга в одиночку запустил hardware-стартап. Это был тщеславный и необдуманный поступок. Не было профильного образования. Опыт в разработке железа – по нулям. Инженерная команда и деньги на контрактную разработку отсутствовали. Спустя 9 месяцев проект живее всех живых: железка работает и развивается, начались продажи, развернут публичный стенд в HSEinc, а команда насчитывает девять боевых единиц.
Команда работает автономно, ребятам уже не нужны советы, напутствия или пинки. Они замкнулись на технического директора и пашут. Перепроектируют платы и корпус, собирают первую серию, пишут бэк для сайта. Что остается делать основателю? Продавать? Нежиться в теплом бризе из надвигающейся «долины смерти»? Нет. Воспользовавшись моментом, уставший основатель сбегает на Хабр. Он надеется излить душу и получить здесь несколько бесценных советов.
Это мой первый пост на Хабре. В нем планирую рассказать о самом дорогом – о ребятах, о сборе команды. По ходу повествования постараюсь ответить на вопросы, которые мучали меня на всем пути существования проекта:
- стоит ли hardware-стартапу на старте собирать команду инженеров, или можно обойтись контрактной разработкой?
- какие минимальные технические компетенции, и в какой последовательности нужны для создания простого hardware-продукта?
- в каком омуте искать, и на что ловить инженеров?
- с какими проблемами и рисками сталкивается «железная» команда?
То, что написано ниже – не история успеха (мы в глубоких минусах), не божественное откровение и не результат долгого научного исследования. Это просто опыт, полученный за 9 месяцев ежедневной борьбы за проект. Приглашаю всех пинать ногами. Ошибки и нарушения правил обещаю оперативно исправлять.
Контекст
О себе. 30 лет, специалитет госуправления НИУ ВШЭ, кандидат экономических наук. По стечению обстоятельств пришел проджектом в дочку Ростелекома и трудился там 4 года. Потом открыл свою компанию по разработке IT-решений для госорганов. Много работаю с Минцифрой, Ростелекомом, промышленными и оборонными ведомствами. В какой-то момент понял, что, если продолжу трудиться только в этой сфере –
О проекте. С технической стороны проект очень прост. ClimateGuard — это зонд для измерения качества окружающей среды и оповещения владельца об угрозах, очередной «умный нос». Основные отличия от аналогов – честное и точное измерение 10 параметров климата (не только воздуха), гибкое серверное API и возможность кастомизации под заказчика. На Хабре уже много раз обозревались похожие коммерческие продукты вот, вот, вот, вот, вот, вот и т.д., а также самоделки вот, вот, вот и т.д.
О ресурсах. Из семейного бюджета на проект оставалось 30-50 тыс. рублей в месяц. Среди знакомых технарей были только разработчики, инженеров и ардуинщиков видел в голливудском кино. Не имел ни малейшего понятия, из какого холодильника берутся радиокомпоненты и платы. Оборудование для работы с электроникой и создания корпусов отсутствовало. Знания и опыт в области электроники ограничивались починкой утюга.
Сбор команды фанатиков технарей
Шаг 1. Промышленный дизайнер
Дано. В команде двое – основатель и аналитик. Аналитик благородно примерил на себя личину технического директора и ходит с покерфейсом. В головах есть смутное понимание продукта.
Задача. Оформить продукт в виде рисунков и 3D-моделей, которые можно показывать клиентам и акселераторам.
Решение. У аналитика нашелся хороший друг, занимающийся проектированием оборудования в одном из московских НИИ. Работа эта, по всей видимости, была скучной и не мотивировала на трудовые подвиги. Проектировщик с большим энтузиазмом воспринял предложение поучаствовать в стартапе. В отличие от НИИ, здесь у него появилась возможность самостоятельно, с нуля определять структуру и внешний вид «реального» продукта.
Почему мы взяли проектировщика, а не обычного дизайнера? На первом этапе не важно, насколько эстетически привлекательной будет выглядеть «железка». Главное понять, что ты можешь ее создать, и как это сделать. Нужны чертежи и 3D-модели.
Результат. За три часа мозгоштурма, гугления и рисования на салфетках в кафе нам удалось определить общую концепцию внешнего вида корпуса. На Ali нашли приблизительный набор датчиков, которые будут использоваться в устройстве. Через неделю была готова первая 3D-модель!
Шаг 2. Дизайнер
Дано. В команде трое, все без чувства прекрасного.
Задача. Найти специалиста, который разработает лого (стартапу без лого никак), а в последствии сможет рисовать web- и mobile-интерфейсы. Звучит как смешение теплого с мягким. Но зачем терять время на поиск разных специалистов, если можно один раз найти и работать с талантливым дизайнером, включив его в процесс.
Решение. Автор позвал в команду дизайнера, с которым работал на регулярной основе по другим проектам.
Результат. Появилось лого и наброски UI. А вместе с ними — море безумного креатива от дизайнера.
Шаг 3. Радиоэлектронщик
Дано. В команде четверо, но ни один не умеет собирать электронику и писать прошивки. Есть понимание внешнего вида и компонентов устройства.
Задача. Найти электронщика-универсала, который соберет прототип и будет развивать его до продукта.
Решение. Это была боль. Опрашивал всех знакомых, поднимал контакты одноклассников, писал на форумы и в профильные чаты. Затем сформировал ТЗ, которое публиковал и рассылал на агрегаторах фрилансеров. Встречались следующие типы персонажей:
- мечтатели — «Круто, умею, сделаю, поехали… Только потом, через месяцок, когда-нибудь. Сейчас занят.»;
- студенты – «Извини, братуха, бьюсь уже 2 недели, не получается… Зато я виртуозно умею «плисы». Давай замутим на «плисах» что-нибудь?»;
- старпёры – «А что такое стартап? У тебя вообще заказ есть? Мы на заводе по 3 года такие штуковины проектировали. Главное – правильно документацию на НИОКР оформить. Сначала придумай как сертифицировать, потом приходи»;
- контрактники — «150 тыс. рублей аванс, 150 тыс. рублей по факту, через 3 месяца получишь один работающий MVP. Найдешь еще денег и сформируешь бэклог – буду дорабатывать».
Ни один из этих вариантов нам для быстрого старта не подходил. Потеряли уйму времени и сильно приуныли.
Но тут случилось чудо – к нам пришел Дядя Стёпа. Дяде Стёпе 24 года, он закончил Бауманку, собранный и ответственный, умеет проектировать платы, читать даташиты, паять, «собирать быстро» и «собирать хорошо». У него есть свой 3D-принтер. Ему интересен проект, а не деньги. И приступить он может сегодня.
Знаете, откуда к нам пришел Дядя Стёпа? Никогда не догадаетесь. С youdo! Не с фриланса, не с форумов электронщиков. На youdo лежало объявление «собрать MVP» за 10 000 рублей, к которому было приложено одностраничное ТЗ с картинками. Данный материал не является партнеркой. Но своим существованием стартап обязан именно площадке youdo.
Результат. Согласовали с электронщиком набор компонентов. Купили в ЧипДипе. Через 3 недели был готов прототип. Еще через месяц – первый вариант собственных плат, сенсорных кнопок и куча прочих ништяков.
Шаг 4. Технический директор
Дано. В команде пятеро. Появился прототип, который нужно развивать. Нашлись первые последователи, желающие тестировать устройство. Внутри стартапа возникают организационные и бизнесовые задачи. Основатель не успевает «продавать», ходить на тусовки в акселераторы, общаться с технарями и зарабатывать деньги на дальнейшее развитие проекта.
Задача. Найти технического директора. Он должен координировать работы остальных технарей, аккумулировать информацию о проекте, а в кризисных ситуациях — занимать место у станка.
Решение. Задача решилась быстро, но с губительными для кармы последствиями. Технический директор был уведен из дружественного hardware-проекта. Для этого были использованы следующие приемы:
- Автор надувал щеки и разными способами демонстрировал, какой он хороший бизнесмен и как легко сможет отправить проект в космос при наличии хорошего CTO. Это была ложь.
- Будущему техническому директору был приобретен 3D-принтер, а в последствии – паяльная станция. Это был подкуп.
- Жертве была продемонстрирована команда крутых спецов, которыми он должен руководить. Это была игра на человеческом тщеславии.
- Сейчас технический директор понимает, что без него на проекте настанет хаос. Это эксплуатация чувства ответственности.
До сих пор очень стыдно и перед основателем дружественного стартапа, и перед самим техническим директором. Но с точки зрения бизнеса оно того стоило.
Результат. Получили в команду молодого фанатичного парня, с высочайшей личной мотивацией, опытом, умеющего все – от общения с заказчиками до написания прошивок и пайки. Самое главное – он готов работать над проектом от 14 до 20 часов в день, бесплатно. А автор помимо прочих пятен в карму получил злейшего врага в лице «второй половинки» технического директора и клеймо рабовладельца.
Шаг 5. Веб-разработчик
Дано. В команде шестеро. Продукт развивается.
Задача. Найти разработчика для создания серверной части и web-интерфейса портала.
Решение. Разработчик уведён из того же дружественного стартапа. Алгоритм хантинга повторен 1 в 1. Вместо 3D-принтера разработчику куплен ноутбук.
Профессионально ли то, что за бэк и фронт отвечает один разработчик? Для «железного» стартапа ранней стадии – да. Нас уже 7 человек. Продаж нет. «Долина смерти» все ближе.
Результат. Разработан прототип бэка и пользовательского интерфейса, создано api. Доработка портала продолжается.
Шаг 6. Евангелист
Дано. В команде семеро. Продукт еще не завершен. Деньги заканчиваются. Нужны отзывы пользователей и продажи.
Задача. Найти человека, который приведет ранних последователей. Сможет подменить ленивого основателя на переговорах, съездить вместо него в Питер или за границу за свой счет. Возьмет на себя часть административных задач.
Решение. В ходе проекта мы пытались своими силами вести информационную кампанию. Получалось хаотично и неэффективно. Но в результате удавалось получать отзывы от экспертов, бизнес-ангелов, людей, неравнодушных к вопросам экологии. Один из них предложил войти в команду и помогать нам с информационными и административными задачами.
Результат. Евангелист, который просит, чтобы его называли «бизнес-инженером», взял на себя львиную долю административных задач, привлек нескольких значимых клиентов и усилил нашу PR-кампанию. Само собой, бесплатно.
Шаг 7. Пайщик
Дано. В команде 8 человек. Появились первые клиенты, желающие приобрести устройство. Растет очередь компаний, просящих дать устройство на тестирование. Фактическая производительность команды – 1-2 устройства в месяц. На RnD, развитие продукта и оптимизацию прошивки времени категорически не хватает.
Задача. Найти ответственного специалиста, готового взять на себя работы по закупке рассыпухи, напайке компонентов на платы и сборке устройств.
Решение. Уже совсем просто. Евангелист кидает клич по своим каналам. Вызываются несколько желающих. Среди них проводится отбор по четырем критериям: наличие опыта, активность, интерес к проекту и готовность работать за идею. Выбирается один. Остальные отправляются в резерв.
Результат. Скорость создания устройств повысилась до 3 штук в неделю.
Кто на новенького?
Сейчас группа разработки продукта сформирована. Нужно кричать и продавать. Поэтому начинаем искать гуманитариев – продажника и PR-щика. Лучше девушек… Вот только есть ли среди них фанатики, готовые на старте работать за интерес – для автора остается под вопросом. Время покажет.
Риски команды hardware-проекта
Специфика железного проекта заключается в том, что к стандартному набору технарей «разработчик + дизайнер» добавляется еще орда инженеров. Отсюда растут следующие риски:
- У нас в команде девять человек, а том числе шесть технарей и два РП (аналитика). Все заняты делом. Далее в проект нужно будет добавлять профильных специалистов по работе с клиентами, контентом, продажами. Однако инвесторы уже смотрят на нас очень подозрительно и каждый раз переспрашивают: «Что, 9 человек? Зачем столько, чем они заняты? Что за работа такая – проектирование плат? Вы серьезно хотите взять еще людей?». В мире софтовых стартапов все слишком привыкли к командам из трех человек. И объяснить необходимость специализации и многоаспектный характер проекта очень сложно.
- Команду нужно кормить, или отпускать на вольные хлеба. Большую команду стартапом прокормить невозможно. Фултайм (хоть и бесплатно) сейчас работают только двое – основатель и технический директор. Остальные для обеспечения семей вынуждены иметь источник постоянного дохода. И при этом уделять проекту от двух до четырех часов в день.
- Инженеры на цикле RnD образуют производственную цепочку «проектирование плат – проектирование корпуса – закупка компонентов – сборка – написание прошивки – тестирование». Если кто-то из команды получает долгожданную командировку в Австралию, решает съездить в отпуск или провести выходные с семьей – работа тормозится, а технический директор впадает в депрессию. Все звезды, все незаменимы на краткосрочном периоде.
- Ходит упорный и весьма достоверный слух, что в успешном hardware-стартапе на одного технаря должно приходиться три маркетолога. А это значит, у нас есть два пути: найти 18 маньяков-гуманитариев, готовых на старте трудиться бесплатно и способных продавать продукт с десятикратной накруткой, или отдавать продажи внешним подрядчикам – интеграторам. Первый вариант фантастичен, а второй сильно ограничивает возможности роста проекта и накладывает на него массу обязательств.
Своя команда VS контрактная разработка
В начале «железного» пути автор имел неудачный опыт контрактной разработки и зарекся не связываться с ней в дальнейшем. Долгие 9 месяцев формирования и управления командой инженеров пошатнули его уверенность. Вплоть до «Надо было отдать производство в Китай и забыть, как страшный сон». Фактически каждый из способов имеет свои преимущества и недостатки. Если отбросить очевидные вещи, сравнение выглядит следующим образом.
Контрактная разработка
Преимущества:
- Не нужно по крупицам собирать команду инженеров.
- Можно подать на вход простейшее ТЗ или даже картинку.
- Можно жестко спрашивать «за результат», абстрагируясь от личных проблем инженеров и собственных просчетов.
- Можно получить высокую скорость разработки и возможность быстрого масштабирования.
- Это идеальный вариант для быстрой проверки множества гипотез: «заплатил — получил прототип – оттестировал прототип на рынке – подтвердил/опроверг гипотезу».
Минусы:
- Стоимость. Контрактная разработка не просто стоит денег, но является очень дорогой. Найти дешевого и талантливого фрилансера под «железные» задачи гораздо сложнее, чем под задачи классического IT.
- Долгая контрактация, долгая передача задачи в работу.
- Сложность в осуществлении промежуточного контроля. Нельзя позвонить инженеру вечером воскресения и сказать: «Максим, срочно дай отчет по двум предыдущим часам работы и плану на ближайшие 7 часов. И не забудь, что сегодня ты спишь не больше 3 часов. А с утра ты в одно жало идешь на объект к Заказчику.»;
- Невозможность влиять на процесс, оперативно корректировать ход разработки.
- Ограниченные возможности использования результатов разработки. По итогам цикла RnD вы получаете прототип или мелкую серию из 5-20 устройств. Как они работают – непонятно. Сможет ли дорабатывать проект другая команда – непонятно. Как оперативно починить устройство в случае сбоя – непонятно.
Своя команда
Преимущества:
- Опыт. Это самое главное. Только работая внутри команды и прочувствовав разработку изнутри, вы можете разобраться в продукте и процессе – этапах производства, багах продукта, направлениях дальнейшего развития.
- Экономия средств. Зная каждого члена команды, вы можете создать для него в проекте немонетарную ценность. Или, как минимум, сократить объем расходуемых ресурсов.
- Контроль проекта. Вы видите процесс изнутри, четко понимаете сроки, производительность, потенциал и приоритеты каждого члены команды.
- Возможность быстрой смены курса. Для стартапа на ранних стадиях жизненно важно иметь возможность в любой момент времени сделать пивот.
- Возможность получить единомышленников, с которыми можно смело начинать новый проект в случае неудачи текущего.
Минусы:
- Для прохождения квеста по сбору команды нужно неожиданно много тупого, непробиваемого упорства и чудо (как у нас в случае с Дядей Степой). Команду необходимо постоянно мотивировать, отслеживать проблемы коммуникации. Потеря каждого члена команды останавливает движение проекта.
- Необходимо приобретать оборудование, стоимость которого повышается с каждым циклом RnD.
- Уже на стадии RnD необходимо искать поставщиков (оборудования, плат, компонентов, рассыпухи), решать проблемы брака, задержки поставок, несовместимости компонентов.
Таким образом, выбор контрактной разработки является оптимальным в случае, если вы хорошо знакомы с процессом создания «железа», есть четкое понимание конечного продукта, сильный технический директор и достаточные финансовые ресурсы. Если же, как в нашем случае, вы только открываете для себя сферу hardware, нет ни денег, ни четкого ТЗ – лучше собирать свою команду и разделять с ней все печали и радости стартаперской жизни.
Команда hardware-стартапа в сухом остатке
Обобщим все выше описанное в 5 тезисах.
- Быстро понять особенности реализации «железного» проекта поможет только своя команда инженеров.
- Одним инженером не обойтись, даже если он богатенький Илон Маск.
- Найти в стартап инженера гораздо сложнее, чем классического разработчика.
- Инженеры очень дисциплинированы, преданы своему делу до фанатизма, готовы работать за идею, любят новые игрушки.
- Для внешнего наблюдателя (инвестора) инженеры – балласт команды, не создающий дополнительную ценность для продукта и проекта в целом.
За пределами команды
Автор пытается не задаваться вопросом «Почему, в отличие от гуманитариев и разработчиков, все эти инженеры в команде работают много и бесплатно?..». А когда задумывается – вспоминает Пушкина, Сказку о попе и о работнике его Балде. И тревожится.
Но встречается на нашем пути кое-что еще чудесатее. Разработка продукта постоянно выходит за пределы команды. И нам безвозмездно оказывают помощь внешние по отношению к проекту товарищи:
- разрабатывают рабочие прототипы интерфейса (привет Вадим из доблестной команды «Хемуль IT»);
- создают telegram-бота (привет Артем);
- рисуют первые рендеры устройства и макеты портала (привет Ася);
- предлагают свои решения по датчикам и платам (привет Дима);
- печатают экспериментальные корпуса и дают расходники к принтеру (привет Вадим из РК Гаджет);
- дают рекомендации по устранению косяков печати (привет Balats из rk3dpro);
- снижают цены на комплектующие и принимают брак по истечении гарантийного периода (привет Эдуард из duino);
- тестируют устройства (привет Максим);
- снимают для нас видео (привет София).
Автор не понимает, почему так происходит. И очень благодарен всем друзьям и последователям проекта. ClimateGuard не забудет вашу помощь! #climatematters