Start-up development
Personnel Management
Manufacture and development of electronics
IOT
29 April 2019

Приключения железного стартапа в России: сбор команды

image

Коллеги, доброго времени суток.

Осенью 2018 года ваш покорный слуга в одиночку запустил hardware-стартап. Это был тщеславный и необдуманный поступок. Не было профильного образования. Опыт в разработке железа – по нулям. Инженерная команда и деньги на контрактную разработку отсутствовали. Спустя 9 месяцев проект живее всех живых: железка работает и развивается, начались продажи, развернут публичный стенд в HSEinc, а команда насчитывает девять боевых единиц.

Команда работает автономно, ребятам уже не нужны советы, напутствия или пинки. Они замкнулись на технического директора и пашут. Перепроектируют платы и корпус, собирают первую серию, пишут бэк для сайта. Что остается делать основателю? Продавать? Нежиться в теплом бризе из надвигающейся «долины смерти»? Нет. Воспользовавшись моментом, уставший основатель сбегает на Хабр. Он надеется излить душу и получить здесь несколько бесценных советов.

Это мой первый пост на Хабре. В нем планирую рассказать о самом дорогом – о ребятах, о сборе команды. По ходу повествования постараюсь ответить на вопросы, которые мучали меня на всем пути существования проекта:

  • стоит ли hardware-стартапу на старте собирать команду инженеров, или можно обойтись контрактной разработкой?
  • какие минимальные технические компетенции, и в какой последовательности нужны для создания простого hardware-продукта?
  • в каком омуте искать, и на что ловить инженеров?
  • с какими проблемами и рисками сталкивается «железная» команда?

То, что написано ниже – не история успеха (мы в глубоких минусах), не божественное откровение и не результат долгого научного исследования. Это просто опыт, полученный за 9 месяцев ежедневной борьбы за проект. Приглашаю всех пинать ногами. Ошибки и нарушения правил обещаю оперативно исправлять.

Контекст


О себе. 30 лет, специалитет госуправления НИУ ВШЭ, кандидат экономических наук. По стечению обстоятельств пришел проджектом в дочку Ростелекома и трудился там 4 года. Потом открыл свою компанию по разработке IT-решений для госорганов. Много работаю с Минцифрой, Ростелекомом, промышленными и оборонными ведомствами. В какой-то момент понял, что, если продолжу трудиться только в этой сфере – поеду кукушкой совсем перегорю. Решил погрузиться в неизведанную область разработки электроники для людей. Так родился проект ClimateGuard.

О проекте. С технической стороны проект очень прост. 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-проекта


Специфика железного проекта заключается в том, что к стандартному набору технарей «разработчик + дизайнер» добавляется еще орда инженеров. Отсюда растут следующие риски:

  1. У нас в команде девять человек, а том числе шесть технарей и два РП (аналитика). Все заняты делом. Далее в проект нужно будет добавлять профильных специалистов по работе с клиентами, контентом, продажами. Однако инвесторы уже смотрят на нас очень подозрительно и каждый раз переспрашивают: «Что, 9 человек? Зачем столько, чем они заняты? Что за работа такая – проектирование плат? Вы серьезно хотите взять еще людей?». В мире софтовых стартапов все слишком привыкли к командам из трех человек. И объяснить необходимость специализации и многоаспектный характер проекта очень сложно.
  2. Команду нужно кормить, или отпускать на вольные хлеба. Большую команду стартапом прокормить невозможно. Фултайм (хоть и бесплатно) сейчас работают только двое – основатель и технический директор. Остальные для обеспечения семей вынуждены иметь источник постоянного дохода. И при этом уделять проекту от двух до четырех часов в день.
  3. Инженеры на цикле RnD образуют производственную цепочку «проектирование плат – проектирование корпуса – закупка компонентов – сборка – написание прошивки – тестирование». Если кто-то из команды получает долгожданную командировку в Австралию, решает съездить в отпуск или провести выходные с семьей – работа тормозится, а технический директор впадает в депрессию. Все звезды, все незаменимы на краткосрочном периоде.
  4. Ходит упорный и весьма достоверный слух, что в успешном hardware-стартапе на одного технаря должно приходиться три маркетолога. А это значит, у нас есть два пути: найти 18 маньяков-гуманитариев, готовых на старте трудиться бесплатно и способных продавать продукт с десятикратной накруткой, или отдавать продажи внешним подрядчикам – интеграторам. Первый вариант фантастичен, а второй сильно ограничивает возможности роста проекта и накладывает на него массу обязательств.

Своя команда VS контрактная разработка


В начале «железного» пути автор имел неудачный опыт контрактной разработки и зарекся не связываться с ней в дальнейшем. Долгие 9 месяцев формирования и управления командой инженеров пошатнули его уверенность. Вплоть до «Надо было отдать производство в Китай и забыть, как страшный сон». Фактически каждый из способов имеет свои преимущества и недостатки. Если отбросить очевидные вещи, сравнение выглядит следующим образом.

Контрактная разработка


Преимущества:

  • Не нужно по крупицам собирать команду инженеров.
  • Можно подать на вход простейшее ТЗ или даже картинку.
  • Можно жестко спрашивать «за результат», абстрагируясь от личных проблем инженеров и собственных просчетов.
  • Можно получить высокую скорость разработки и возможность быстрого масштабирования.
  • Это идеальный вариант для быстрой проверки множества гипотез: «заплатил — получил прототип – оттестировал прототип на рынке – подтвердил/опроверг гипотезу».

Минусы:

  • Стоимость. Контрактная разработка не просто стоит денег, но является очень дорогой. Найти дешевого и талантливого фрилансера под «железные» задачи гораздо сложнее, чем под задачи классического IT.
  • Долгая контрактация, долгая передача задачи в работу.
  • Сложность в осуществлении промежуточного контроля. Нельзя позвонить инженеру вечером воскресения и сказать: «Максим, срочно дай отчет по двум предыдущим часам работы и плану на ближайшие 7 часов. И не забудь, что сегодня ты спишь не больше 3 часов. А с утра ты в одно жало идешь на объект к Заказчику.»;
  • Невозможность влиять на процесс, оперативно корректировать ход разработки.
  • Ограниченные возможности использования результатов разработки. По итогам цикла RnD вы получаете прототип или мелкую серию из 5-20 устройств. Как они работают – непонятно. Сможет ли дорабатывать проект другая команда – непонятно. Как оперативно починить устройство в случае сбоя – непонятно.

Своя команда


Преимущества:

  • Опыт. Это самое главное. Только работая внутри команды и прочувствовав разработку изнутри, вы можете разобраться в продукте и процессе – этапах производства, багах продукта, направлениях дальнейшего развития.
  • Экономия средств. Зная каждого члена команды, вы можете создать для него в проекте немонетарную ценность. Или, как минимум, сократить объем расходуемых ресурсов.
  • Контроль проекта. Вы видите процесс изнутри, четко понимаете сроки, производительность, потенциал и приоритеты каждого члены команды.
  • Возможность быстрой смены курса. Для стартапа на ранних стадиях жизненно важно иметь возможность в любой момент времени сделать пивот.
  • Возможность получить единомышленников, с которыми можно смело начинать новый проект в случае неудачи текущего.

Минусы:

  • Для прохождения квеста по сбору команды нужно неожиданно много тупого, непробиваемого упорства и чудо (как у нас в случае с Дядей Степой). Команду необходимо постоянно мотивировать, отслеживать проблемы коммуникации. Потеря каждого члена команды останавливает движение проекта.
  • Необходимо приобретать оборудование, стоимость которого повышается с каждым циклом RnD.
  • Уже на стадии RnD необходимо искать поставщиков (оборудования, плат, компонентов, рассыпухи), решать проблемы брака, задержки поставок, несовместимости компонентов.

Таким образом, выбор контрактной разработки является оптимальным в случае, если вы хорошо знакомы с процессом создания «железа», есть четкое понимание конечного продукта, сильный технический директор и достаточные финансовые ресурсы. Если же, как в нашем случае, вы только открываете для себя сферу hardware, нет ни денег, ни четкого ТЗ – лучше собирать свою команду и разделять с ней все печали и радости стартаперской жизни.

Команда hardware-стартапа в сухом остатке


Обобщим все выше описанное в 5 тезисах.

  1. Быстро понять особенности реализации «железного» проекта поможет только своя команда инженеров.
  2. Одним инженером не обойтись, даже если он богатенький Илон Маск.
  3. Найти в стартап инженера гораздо сложнее, чем классического разработчика.
  4. Инженеры очень дисциплинированы, преданы своему делу до фанатизма, готовы работать за идею, любят новые игрушки.
  5. Для внешнего наблюдателя (инвестора) инженеры – балласт команды, не создающий дополнительную ценность для продукта и проекта в целом.

За пределами команды


Автор пытается не задаваться вопросом «Почему, в отличие от гуманитариев и разработчиков, все эти инженеры в команде работают много и бесплатно?..». А когда задумывается – вспоминает Пушкина, Сказку о попе и о работнике его Балде. И тревожится.

Но встречается на нашем пути кое-что еще чудесатее. Разработка продукта постоянно выходит за пределы команды. И нам безвозмездно оказывают помощь внешние по отношению к проекту товарищи:

  • разрабатывают рабочие прототипы интерфейса (привет Вадим из доблестной команды «Хемуль IT»);
  • создают telegram-бота (привет Артем);
  • рисуют первые рендеры устройства и макеты портала (привет Ася);
  • предлагают свои решения по датчикам и платам (привет Дима);
  • печатают экспериментальные корпуса и дают расходники к принтеру (привет Вадим из РК Гаджет);
  • дают рекомендации по устранению косяков печати (привет Balats из rk3dpro);
  • снижают цены на комплектующие и принимают брак по истечении гарантийного периода (привет Эдуард из duino);
  • тестируют устройства (привет Максим);
  • снимают для нас видео (привет София).

Автор не понимает, почему так происходит. И очень благодарен всем друзьям и последователям проекта. ClimateGuard не забудет вашу помощь! #climatematters

+11
7.6k 54
Comments 94
Top of the day