Привет, меня зовут Иван Ларионов. В 2011 году мы вместе с братом основали компанию «Третий пин». Я хочу поделиться своей историей эволюции из инженера-фрилансера в руководителя компании, занимающейся контрактной разработкой электроники. Как и почему удалось не обанкротиться, не закрыться и не выгореть, а нарастить мощности и сохранить кураж.
Важно. это не набор рекомендаций, не призыв к действию, а только лишь личный опыт. Это скорее ретроспектива и попытка понять, почему всё так вышло. Многие вещи кажутся очевидными из текущей точки, но я-то знаю, что совсем недавно я мыслил иначе.
Хотя мы работаем в достаточно узкой отрасли, многие вещи могут откликнуться и будут полезны всем, кто работает на себя и думает над тем, что пора двигаться дальше и становиться предпринимателем.
Откуда берутся CEO-инженеры
"Помни, фрилансер. Одно неловкое движение и ты - предприниматель."
После института я проектировал печатные платы и корпуса измерительных приборов, брат писал встроенный софт для торпедных аппаратов подводных лодок в большом КБ. В свободное время мы брали небольшие заказы на фрилансе: я паял, рисовал схемы и конструировал платы, брат писал к ним прошивки, иногда так случалось, что мы вместе выпускали и отлаживали образцы. Офиса у нас не было, переговоры о проектах вели в маршрутке. В 2011 году юрлицам было проще, чем физлицам, закупать электронные компоненты у дистрибьюторов и производить печатные платы, поэтому мы открыли под это дело фирму. Так появился «Третий пин».
Это мы с братом перед подачей документов на регистрацию компании
Вскоре я уволился с работы и пошёл по собеседованиям. Было несколько интересных мест, но нигде не хотели брать меня на парт-тайм, а я хотел продолжать делать проекты как фрилансер. Поэтому я решил никуда не устраиваться, а посвятить всё своё время фрилансу. Брат продолжал работать в КБ.
Для поиска клиентов я постил предложения о разработке на заказ на форуме electronix.ru, смотрел объявления с запросами и брал мелкие работы тут и там. Сарафан тоже работал, например, один интересный проект был от бывшего работодателя.
Средний заработок не сильно отличался от работы по найму, в целом всё шло неплохо. Но, к сожалению, люди не воспринимают тебя серьёзно, если ты не обернулся абстракцией в виде "Компании". Сейчас я думаю, что фрилансерство - это такое же предпринимательство, только без перспектив нормальной жизни. Если фрилансер хочет развиваться и брать интересные
проекты большого размера, хорошо справляется, то он вынужден нанимать людей и в конце концов стать руководителем, а не инженером.
У нас этот период "фриланса с юрлицом за пазухой" закончился первым заказом на пару миллионов рублей, когда удалось убедить заказчика, что я теперь не я, а целая компания.
Брат Паша бросил торпеды. Сняли прямо в своём доме офис, и начали нанимать сотрудников и купили кофемашину.
Постепенно заказов на контрактную разработку становилось всё больше, обороты фирмы росли. Ну, или нам так казалось. Часть заказчиков, готовая работать только с фрилансерами, отвалилась, часть осталась и кормила нас̶ п̶о̶т̶о̶к̶о̶м̶ ручейком мелких заказов.
И вроде бы, казалось, вот он - успех, которого мы так долго ждали?
Все выглядело просто:
-
вот задача, вот деньги, мы знаем, как достичь результата - и это называется бизнес.
-
зарплату себе можно пока сделать пониже, чем была, ведь у нас теперь будут дивиденды! (спойлер: их не было ещё много лет).
-
наши текущие заказчики - это только начало, вокруг полно таких же, они нас ждут, мы всем нужны, сейчас полетим! (спойлер: рынок подобных услуг в России на тот момент ещё даже не приобрёл названия)
Но всё оказалось чуть сложнее.
Почему инженеру трудно продавать и как с этим жить?
У инженера есть такое чувство, что продажи - это что-то низкое. Нужно просто разрабатывать получше и будешь востребован. Поэтому в первое время мы совсем не занимались продажами, рассчитывая на существующих заказчиков и сарафанное радио. Но каждое лето повторялась одна и та же ситуация. Старые клиенты долго не звонили, потому что «тихий сезон», а новые не приходили, потому что неоткуда. На горизонте маячила беда под
названием «кассовый разрыв». Для фрилансеров затишье - не проблема, ведь есть основная работа и можно просто временно сократить собственные расходы. Но теперь помимо нас были другие сотрудники, которым нужно было платить зарплату.
Обычно нам помогало чудо, например удавалось договориться об оплате работы вперед. Но так не могло продолжаться вечно. В какой-то момент, когда, чтобы вместо зарплат не выдавать чупа-чупсы, мы взяли кредит, пришло понимание, что нужно обеспечить поток заказов для прогнозируемой загрузки ресурсов. Нужно что-то менять. Причём менять в первую очередь в своей голове. И пока эти вещи в голове не улеглись, нанимать продавца бесполезно. Да и инженера, да и уборщицу.
Вот несколько ментальных блоков, с которыми я столкнулся.
Несерьезное отношение к себе и своей компании
Это история произошла в самом начале создания компании. Мы с братом пошли на корабельную выставку (наш основной заказчик был из этой отрасли), где я подошёл на стенд крупной компании и начал теребить какой-то пульт. Ко мне подошёл технический директор и спросил, что мне тут надо на стенде (странное поведение наших соотечественников на
выставках достойно освещения в отдельной заметке). Я рассказал ему, что занимаюсь контрактной разработкой и был бы рад видеть его своим заказчиком. По итогу мы даже не обменялись визитками. У меня её не было, а он мне свою не предложил. Когда мы пошли дальше, Паша сказал: "для начала нам надо научиться не смеяться при произношении названия нашей компании".
Вывод: если ты не будешь относиться к своему делу серьезно, то и другие
будут делать так же.
Неумение выставить цену. Неумение продавать
Способ ценообразования от затрат мы почерпнули у своего первого клиента с большими заказами. Это было госпредприятие, и к КП полагалась калькуляция. В сметах весь расчёт делается от затрат. Зарплата, материалы, накладные расходы и, конечно же, прибыль. Помню как я переживал, не слишком ли большие у нас накладные расходы (30%)... Прибыль в таком документе должна была выглядеть "приемлемой", трудозатраты - обоснованными. Добавим к этому абсолютную неосведомленность в проектном управлении и в итоге получаем КП на проект без резервов по времени и финансам, с голой себестоимостью времени сотрудников. Это всё конечно «справедливо» и «честно», но не рыночно и не про бизнес. Цена определяется балансом спроса и предложения, а не затратами на получение блага.
Важный момент про деньги. RND - это создание интеллектуальной собственности, которую в будущем можно монетизировать. Когда мы закончим проект, мы отдадим заказчику результаты, и он сможет на них заработать. А мы нет. Поэтому если мы тоже хотим заработать, то сделать это нужно во время разработки. Некоторые заказчики пытаются манипулировать, обещая будущие совместные проекты или крупные партии производства, но в 99% случаев - это чрезмерный оптимизм или просто блеф. И самое печальное, что ни одна сторона на самом деле от этого не выигрывает.
Даже ГК говорит, что риски невыполнения ОКР должны лежать только на заказчике.
Внешний вид и образ
Всю жизнь я не запаривался по поводу одежды и внешнего вида. Моим выбором всегда была флисовая кофта от какого-нибудь известного спортивного бренда и я носил её везде, и в офис и на встречи. Оказалось, зря. Костюм - как боевой доспех, вселяет в людей вокруг уверенность в вас одним своим видом. Это действительно работает, проверено не раз. Например, можно идти вдвоем сквозь пропускной пункт на выставку, я в костюме с красивым кожаным портфелем, а Паша в футболке с каким-нибудь мемом. Я просто прохожу как нож сквозь масло, Паша же - будет остановлен и досмотрен. И так во всём. Людям нравятся люди в красивой одежде, надо этим пользоваться. После выставки можно снять всё это и
надеть любимую протертую флиску, кайф.
Образ формируется материалом визитки, машиной, ручкой, уверенным взглядом, приятным рукопожатием. В общем, важны все сигналы внешнему миру.
Хотя, иногда нужно менять образ, чтобы привлечь более молодую аудиторию. Например, когда идешь вербовать студентов бросить всё и заняться электроникой.
А еще, красный - цвет лидера. How do you do fellow kids?
Самый важный - неумение делегировать
В начале развития компании момент продажами занимался только я. Я сам общался со всеми клиентами от приёма задачи до сдачи работ. Плюс параллельно делал большую часть работы по схемотехнике. Однажды другому Паше, в тот момент нашему инженеру-конструктору, наскучила разработка, и он решил бросить всё и уехать в лес (в прямом смысле).
Через полгода, чуть не начав разговаривать с деревьями, вернулся и сказал: «В топку инженерию, давай буду коммерсантом!». Звучит странно, но так совпало, что до конструкторских дел он работал в одной из компаний большой четверки. То есть, доносить информацию, объяснять сложные вещи и убеждать он умел на "отлично". И мы решили попробовать.
Чудесное преображение из лесника в коммерческого директора. Вот, что электроника делает с людьми.
В итоге он на 80% снял всю работу, связанную с поиском и общением с клиентами, что позволило сконцентрироваться на других вещах - развитии процессов, стратегическом планировании и прочем. С управлением проектами была такая же история: приход Александра, состоявшегося руководителя проектов, сильно улучшил нашу работу и продвинул компанию вперёд.
Как не работать бесплатно и в стол
Открою вам секрет: большая часть контрактных разработчиков убыточна. К примеру, на нашей конференции Контрактная разработка электроники был баттл на тему "может ли контрактная разработка быть самостоятельным бизнесом?", на котором многие контрактные разработчики отстаивали позицию "нет". Я стоял на стороне "да", вот несколько вещей, которые я понял:
Предварительно оценивать компанию, а не только проект
Когда к нам приходит новый лид, мы всегда обращаем внимание на несколько
вещей:
-
На чем компания зарабатывает, какие у нее показатели. Первичный скоринг помогает определить, сможет ли компания потянуть свою разработку или нет. Для этого помогают базы, вроде Rusprofile или специализированные телеграм боты.
-
Есть ли опыт управления проектами по разработке или понимание, как это работает. Если этого опыта нет, то будет сложнее, надо готовиться к недоверию и оверкоммуникации. Выяснить это можно только при личном общении с командой заказчика.
-
Насколько заказчик интересен с точки зрения будущего PR'а. Конечно, здесь остается большая доля неопределенности, потому что сложно угадать, как закончится проект.
-
Есть ли финансовые и репутационные риски. У нас уже был негативный опыт с одним из проектов, который мог закончиться очень плохо.
Проект оценивать всё-таки тоже надо
Самый главный критерий - проект должен мотивировать команду. Если команда работает над штукой, которая кажется бесполезной или непонятной, то это не идет на пользу работе. Люди не роботы, им важно чувствовать причастность и важность своей работы. Поэтому мы всегда стараемся отказываться от мутных проектов с непонятным будущим или непонятной
идеей.
Так, например, один из партнеров, предлагал нам лида, который разрабатывал современную версию «заряжателя воды» с AI на борту и хотел продавать всё это американским богачам. С точки зрения экономики все сходилось. Там были деньги, канал продаж и даже аудитория (!), но этическая часть проекта сильно хромала. В итоге мы отказались.
Бороться с убыточностью и фиксированным прайсом
В разработке электроники основная проблема - неопределенность, особенно в части разработки встроенного ПО, где очень сложно правильно и точно сформулировать требования к системе в самом начале работы. Из-за этого и технических рисков практически невозможно точно предсказать стоимость и сроки будущего проекта.
Раньше мы думали, что просто плохо считаем и нужно больше думать и тщательнее просчитывать на ранних этапах. На самом деле, наши представления о содержании проекта сильно эволюционируют во времени, и в процессе выполнения работ становятся понятны новые задачи, а некоторые из начальных теряют свой первоначальный смысл.
Мы фиксировали стоимость и гарантировали результат вовремя. Но всегда оставался риск, что что-то пойдет не так и кто-то должен за этот риск платить. Мы брали риск на себя и оценивали его. Обычно это было от 100% сверху до умножения на Pi. Дальше до смерти торговались с клиентом и договаривались о какой-то сумме и сроках. И мы надеялись, что риск не сыграет. Но чаще всего не угадывали...
Постоянные ошибки в оценке проектов и кредитование клиентов приводили к большим финансовым потерям и кассовым разрывам.
Помимо ошибок оценки проектов, у классического ОКР по фиксу есть ещё ряд пороков. Оплата, как правило, разбивается на этапы. Это значит, что оплата происходит довольно редко - перерывы 3-9 месяцев. Прибыль на этапе выплачивается по сдаче этапа, там же происходит авансирование следующего. Или не происходит, если заказчик передумал доделывать свой
проект. Расход средств происходит практически линейно, поэтому временами денег становится много, потом они долго-долго расходуются. Если сдать этап вовремя по каким-то причинам не получается (часто это зависит и от заказчика), проект уходит в минус. Если есть деньги с других проектов - начинается пирамида софинансирования. В случае, если сроки и бюджет
поджимают, а работы ещё много - единственный инструмент управления в руках Менеджера Проектов - объем работ, т.е. качество. Вся эта модель отношений толкает подрядчика к упрощению и срезанию углов, где только можно. Мы так не любим делать. В общем, это очень неустойчивая модель, как с точки зрения финансов, так и с точки зрения долгосрочной стратегии нас, как контрактного разработчика электроники.
Мы приняли новое правило: фиксированный прайс подходит только к госзаказам или тендерам, больше нигде. И перешли на модель T&M (Time & Materials - модель с оплатой за потраченное время и материалы). Это позволило сгладить поступление финансов и гибко управлять проектом, пуская клиента гораздо глубже в наши процессы.
Не фиксировать объём проекта
Теперь мы сразу объясняем, что финальная стоимость будет понятна только в конце проекта. Потом берём рейты и умножаем на трудозатраты. Получаем плановую стоимость проекта по модели T&M.
Считаем всё: загрузку, закупки, соисполнители и т. д. Есть внутренняя система управления проектами на базе Easyredmine. Кроме управления проектами, её же используем как систему управления финансами.
Да, мы делаем укрупненную оценку на основе требований, но это нужно только для понимания бюджета, чтобы клиент понял, сколько вообще на это будет нужно денег. Безусловно, это не самая популярная модель и заказчики думают, что исполнитель пытается снять с себя ответственность. Наша главная ответственность - предоставить хорошо организованную команду профессионалов, способных решить задачу. Но только в таком
случае, мы можем быть уверены, что наши затраты отобьются.
Вообще, если сравнивать затраты на разработку и её влияние на дальнейшую судьбу продукта, получается удивительная вещь: экономия на разработке всегда приведёт к непропорциональным потерям на следующих этапах (производстве, продажах, поддержке). Можно, например, дольше разрабатывать, чтобы не тратить деньги так быстро. Но сдвигается не просто окончание работ, сдвигается и производство и сбыт, а это упущенная прибыль за всё это время. Можно сэкономить на этапе оптимизации дизайна, а потом производить 10 лет чересчур дорогой девайс, проигрывая по марже конкурентам.
Инженер не виноват?
Почему нельзя оставаться просто группой универсальных разработчиков
Обычно электронщик воспринимается как человек, который может и плату развести, написать прошивку, и спроектировать интерфейс GUI на QT или даже веб-сервис. В общем, электронщик умеет всё. Это хорошо работает на маленьких проектах, простых устройствах с простым функционалом, но когда проект растет, или проектов много, или нужно делать быстро - то так уже не работает. Приходится разделять.
Такая же история с проектами разработки. Когда проектов мало или они живут автономно друг от друга, достаточно иметь ответственных специалистов с навыками самоконтроля. Но вот масштаб увеличивается, и уже появляется необходимость во внешнем управлении.
Если не обращать на это внимание и пытаться тянуть всё, как раньше, то компания никогда не выйдет на новый уровень.
Для этого разделить и не смешивать
Мы четко разделили функционал наших специалистов:
-
Программисты занимаются только софтом, железячники - проектированием железа. Да, по роду деятельности, все они понимают в смежной дисциплине, но используют это очень мало, только на этапе стыковки работы. Тут есть куда развиваться дальше, с ростом компании появляется возможность формировать всё более узкоспециализированно разделённую команду.
Тест на внимательность. Где железячник, а где программист?
-
Появился проджект-менеджер, но не как часть функционала, а как отдельный специалист.
-
Мы внедрили популярные практики: проектное управление, митапы, ревью и т. д. У многих компаний в нашей сфере (bare metal embedded) код до сих пор пишется разными людьми на
личных компьютерах, никаких систем контроля версий и прочих инструментов распределенной разработки не используется. Это все влияет на качество. -
Мы, как основатели, почти перестали работать как разработчики на проектах. Паша стал
техническим директором, а я сосредоточился на бизнесе и публичной деятельности. Конечно, совмещение функций всё ещё присутствует, с увеличением размера команды этого будет
становиться меньше.
Растить специалистов внутри компании
Сейчас в нашей компании 15 человек, 5 менеджеров и 10 разработчиков. На рынке почти невозможно найти готового специалиста. Тех, кто пишет код и проектирует, много, а тех, кто мыслит инженерно - единицы. Периодически мы берём увлечённых студентов на стажировку, часть из них остаётся работать в компании, становясь очень сильными сотрудниками. Если хочешь пожать - то посей(с). Инвестируем время и деньги, зато получаем специалистов, которые готовы к контрактной разработке. Часто слышим мнение, что маленьким конторам так делать нельзя. Но мы делаем - и это работает.
По результатам той стажировки к нам попали два потрясных программиста!
Поддерживать хобби-проекты
Для мотивации команды очень помогают внутренние проекты. В них нас никто не ограничивает, мы можем пощупать новые, модные технологии и просто творчески поделать что-то интересное. Сейчас, например, делаем двухместный экспедиционный каяк с электронной системой управления и автопилотом.
Почему просто разработка не решает бизнес-задачу
Когда мы начинали свой путь, рынок контрактной разработки электроники в России отсутствовал вовсе. В соседней Белоруссии уже было несколько известных компаний, которые продавали за рубеж, а в России разработки велись инхаус или одиночками-фрилансерами. С тех пор рынок не сильно эволюционировал и по-прежнему находится в стадии формирования.
До сих пор на рынке отсутствуют общепринятые представления о контрактной разработке: как оценить стоимость и по каким критериям проверить результат. Нет агентств или рейтингов, позволяющих сравнивать подрядчиков между собой, в отличие, например, от рынка разработки веб-сайтов, где всё это появилось уже давно.
В таких условиях частая проблема - завышенные ожидания и кредит недоверия к потенциальному подрядчику, вплоть до тестовых заданий и предложений разработать что-то бесплатно.
Почти каждый новый заказчик требует прилично времени на обучение и притирку. Часть заказчиков приходят с негативным опытом.
Важно увидеть и решить проблему
Контрактную разработку чаще всего рассматривают именно как инженерную работу. Поэтому в первую очередь ищут инженеров и не думают про всё остальное. В итоге идеальный подрядчик, по мнению заказчика, - это много умных инженеров, которые быстро и без ошибок все проектируют и не задают вопросов.
По факту, пока проект доходит до этой стадии, где инженеры радостно разрабатывают, нужно сделать много аналитической, архитектурной и другой работы. Она очень важна и влияет на результат.
Раньше успешный проект у нас выглядел так:
Разрабатываем по ТЗ → Устройство готово → Мы молодцы
Но потом клиент берёт это устройство и не может его никому продать, потому что требования изначально были неправильно сформированы, и оно получилось дороже, чем надо, а чтобы сделать дешевле нужно переделывать заново.
Теперь, когда заказчик приходит с запросом, мы смотрим предысторию и делаем прогнозы. Мы решаем задачу целиком, чтобы получился успешный проект для нас и для заказчика.
Для этого мы:
-
Делаем не просто разработку, а полноценную поставку и внедрение.
-
Можем выступить генподрядчиком, найти специалистов на другие задачи, поставить им задание, управлять.
-
Смотрим глубже и пытаемся понять, что действительно нужно, а что лишнее.
-
Подключаемся к проекту с разных сторон: разработка, консалтинг, аутстаф.
-
Инвестируем в свои собственные продукты, которые можем использовать
в проектах напрямую или косвенно.
Вывод. Стоит ли этим заниматься?
Предпринимательство - это круто. Возможно, контрактная разработка электроники - не самый разумный вариант приложения своих сил с точки зрения бизнеса, но определённо мне здесь интересно и весело. А что может быть важнее, чем любовь к делу, которым занят? Разве что предчувстие больших свершений и необыкновенных инсайтов!
п.с. Кстати, мы собираем таких же сумасшедших - увлечённых электроникой людей на неформальные душевные митапы в Embedded bar. Присоединяйтесь.
Автор: Иван Ларионов
