Как стать автором
Обновить

Как 10 лет разрабатывать электронику по контракту и не загнуться

Уровень сложностиПростой
Время на прочтение13 мин
Количество просмотров18K
Всего голосов 106: ↑105 и ↓1+104
Комментарии52

Комментарии 52

Образ формируется материалом визитки, машиной, ручкой, уверенным взглядом, приятным рукопожатием. В общем, важны все сигналы внешнему миру.

Какая машина?

автомобиль, хотя ноутбук тоже подходит

Адрес следующего митапа - Питер или Красногорск?)

Спасибо, интересно было почитать.

По ссылке там "Санкт-Петербург
Красногорск, ул. Согласия 13"

Внимание. Мероприятие не может принять всех, надо предварительно регистрироваться, просто так прийти не получится.

третий оказался лишним

Баба с возу - кобыле легче

перешли на модель T&M (Time & Materials - модель с оплатой за потраченное время и материалы).

Расскажите, пожалуйста, подробнее про этот момент. Допустим, к вам приходит заказчик и просит что-то разработать. Вы говорите ему: "Ок, человеко-час стоит N денег. Поехали"?

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

А если заказчик приходит с готовым ТЗ? Или просит сперва разработать его? Мне казалось, что наоборот - только большим компаниям свойственно отдавать заказы на почасовую оплату, потому что бюджеты у них большие, а требования могут меняться, а, как раз, для мелких заказов важно, чтобы бюджет не переполнил int32.

>Допустим, к вам приходит заказчик и просит что-то разработать

Часто просят что-то вроде "Прошу указать стоимость и срок изготовления", при том, что нет даже простого словесного описания устройства. Бывает, присылают просто фотографии плат, иногда горелых. Или название прибора-конкурента.

Подробно оценивать каждый такой запрос никакого времени не хватит. Поэтому одной из первых тем на переговорах идёт обсуждение модели взаимодействия. Если заказчик не готов к ценообразованию по T&M - может дальше и "ехать" не стоит.

А если согласен на почасовую, но имеет ограничение по бюджету? Вы даёте какое-то ограничение сверху на конечную стоимость проекта?

Заказчик довольно легко может ограничить стоимость проекта - не внеся предоплату за следующий месяц

Такое ощущение, что вы не можете сказать "нет". То, что вы не будете работать, если нет дерег, вполне очевидно. Вопрос-то в другом. Если вы не решили эту проблему, но нормально сказать "мы не предоставляем никаких гарантий по поводу конечной стоимости проекта". Просто интересно стало, как это делают другие. Для себя я решил этот вопрос следующим образом. Предлагаю работать или строго по ТЗ без малейшего шага в сторону, либо по почасовой оплате. В первом случае я полностью беру риски на себя, но лишаю заказчика вообще каких бы то ни было возможностей маневрировать. Почти никто на такое не соглашается. В случае повременной оплаты я либо не гарантирую конечную стоимость вообще, либо гарантирую в пределах чётко сформулированных задач. При этом любые изменения изначальной постановки в старую оценку времени не входят. Таким образом интересы всех сторон учитываются и риски получаются минимальными. И такой вариант выбирает большинство. Честно говоря, на месте заказчика я бы очень напрягся, если бы мне сказали: "Хорошо, мы сделаем тебе устройство, но фиг знает, сколько это займёт по времени". При таких условиях, как минимум, тяжело просчитать рентабельность будущего продукта.

>Такое ощущение, что вы не можете сказать "нет"

Между "нет" и "да" - выбор только "да" )

Я для себя решил этот вопрос следующим образом: если кто-то говорит, что у него ограничение по бюджету 200 тысяч, это не значит, что он не может заплатить 2 млн, если ценность достаточно высокая.

Хм. Много лет занимаюсь тем же самым. В общем доволен. Делаю все на 90% сам. Иногда нанимаю кого-то на какие то отдельные задачи. Не согласен с утверждением что надо разделять разработку софта и железа. Именно то что я сам делаю и то и другое дает мне возможность все время балансировать проект, на ходу решая что я делаю железом, а что программно. Это дает возможность упростить и ускорить разработку. Как только идет разделение начается- электронщик сделал как ему проще, а программисту тут теперь на год работы, и наоборот программист посчитал что железо должно выдавать ему что то, но это не реализуемо нормально в железе.

У кого-то есть умение управлять проектами и балансировать нагрузку, у кого-то нет. В каждом случае, разный потолок. Если бы всё человечество принадлежало ко второму типу, то мы бы сейчас вряд ли могли оставлять здесь эти комментарии.

Скажите, сколько цепей и сколько выводов в ваших типовых платах?

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

главное rx-tx не перепутать)

НЛО прилетело и опубликовало эту надпись здесь

Верно, мы используем Agile подход в разработке Embedded. Это требует постоянной синхронизации с заказчиком, что как раз хорошо получается на T&M.

НЛО прилетело и опубликовало эту надпись здесь

Тест на внимательность.

Видимо программист тот, который паяльник за жало держит...

Да, а инженер дошиками питается)

Хорошая попытка. Но нет.

Заначка нашего отдела

Обычно народ в кафе/столовую/ресторан на обед ходит, но иногда хочется чего-нибудь эдакого...

Иван, Ваша статья -бальзам на душу инженера, особенно электронщика! Мы таки рулим )) Удачи Вам и всем Коллегам!

Спасибо за статью, надеюсь у вас всё хорошо и сейчас и на горизонте

НЛО прилетело и опубликовало эту надпись здесь

Спасибо за пост.
Чем контрактная разработка электроники отличается от outsorce компаний?

В целом - ни чем. Думаю, что термин мигрировал из "контрактного производства"

 Периодически мы берём увлечённых студентов на стажировку, часть из них остаётся работать в компании, становясь очень сильными сотрудниками.

Где проходит водораздел между Juniur/ Middle/ Senior Embedded разработчиком?

Там же где у обычного:

  • junior иногда может запрограммировать алгоритм используя известные языки и библиотеки. Требует надзора

  • middle может написать программу и изучить новые языки и библиотеки похожие на известные. Не требует наздора

  • senior может решить проблему

Для мотивации команды очень помогают внутренние проекты. В них нас никто не ограничивает, мы можем пощупать новые, модные технологии и просто творчески поделать что-то интересное. Сейчас, например, делаем двухместный экспедиционный каяк с электронной системой управления и автопилотом.


У Вас отличный внутренний проект Пастильда. Надо только слегка доделать плату. Прошивку я могу предоставить свою https://habr.com/ru/post/706470/

Да, целевая аудитория очень узкая (всякие гики). Надо лишь придумать способ найти аудиторию.

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

Да, приятный пост. Никогда не думали о том, чтобы перейти на следующий уровень: не разрабатывать чужое, а проанализировать: что, где, для чего, почём — будет нужно. После чего — разработать продукт/линейку продуктов для решения этой потребности. И начать производить серийно?


Вопрос не праздный, постоянно занимаюсь таким исследованием:-) Потому что всегда было интересно "физическое воплощение" идеи, которое можно потрогать. А не только нечто виртуальное, которое крутится "где то там, в сетях".

Никогда не думали о том, чтобы перейти на следующий уровень: не разрабатывать чужое, а проанализировать: что, где, для чего, почём — будет нужно. После чего — разработать продукт/линейку продуктов для решения этой потребности. И начать производить серийно?

Любой новый электронный продукт это часто решение какой-то проблемы или задачи. Какую проблему Вы хотите решить с помощью электронного прибора?
Плюс реальность в том, что у российского населения в большинстве нет свободных денег для покупки B2C электроники.

Для старта продуктовой компании надо идти на еще больший риск, чем для старта outsource компании. Надо очень мощное маркетинговое исследование.

Понимаю. Проблем множество на самом деле- стоит только оглядеться ;-). Говорю не голословно — сам веду разработку нескольких одновременно.

Никогда не думали о том, чтобы перейти на следующий уровень: не разрабатывать чужое, а проанализировать: что, где, для чего, почём — будет нужно. После чего — разработать продукт/линейку продуктов для решения этой потребности. И начать производить серийно?



Плюс Западу не очень-то понравится появление новых продуктовых Hi tech компании в восточной Европе. Они там уже определили нам судьбу сырьевого придатка (древесина, человеко-часы, газ). Будут палки в колеса совать.

Достаточно вспомнить американский сериал "кремниевая долина", где американец, основатель Пегово Дудочника орал на парня из ВМК МГУ, что в "этом мире инновации делаем только мы(англосаксы)!"


Насчёт Запада… Смотря кто является потребителем продукта. Если его рынок — Россия или скажем, Китай — я бы их вообще игнорировал в принципе. Да даже если и Европа и США являются потребителями — тоже игнорировал, с определёнными оговорками (продукт не требует скажем перемещения через их границы, оплата поступает через криптовалюты).

Спасибо!

В моём понимании продуктовая модель-это не следующий уровень, а другая модель. Со своими плюсами и минусами. Сейчас у нас есть продукт - Robster, решение для систем функционального тестирования на производстве электроники. Если есть желание сделать что-то вместе-пишите в личку.

Третий Пин располагает экспертизой для создания электроники на FPGA?

На первом фото, судя по выражению лиц, слева - директор, справа - главный инженер :)

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

Спасибо за статью!

Подскажите, пожалуйста, много ли среди Embedded-инженеров тех, кто не занимался этим с «детства» и не учился на профильных направлениях, а, хотя-бы, на смежных (например, информационные системы, разработка на высокоуровневых языках). Самоучки, в общем. Я не столько о программистах, больше об универсалах (программистах-системотехниках). По теме разработки на Java, например, таких случаев много.

Не знаю статистики, но я сам не с детства этим занимаюсь. Да и направление тоже совсем не в embedded- электротехника, электромеханика и электротехнологии. Удачно попал на практику к хорошим людям, загорелся всеми этими микроконтроллерами)

Благодарю за ответ!

В b2b электронике, как мне кажется, нужно роль железа и его разработку сводить к минимуму, и стараться переходить к подписной модели. Железо уже всё давно разработано и стоит дёшево, в отличие от его разработки с нуля. А вот saas или что-то подобное на базе готовой электроники - это уже про большой бизнес.

Очень часто контрактную разработку заказывают, чтобы не зависеть от текущего поставщика. Имхо, не взлетит b2b подписка.

Я имею в виду, создавать такие решения, где клиент от подписной модели получает больше, чем от голого железа. Брать на себя контроль, серверные функции, наращивание и модификация функционала без ревизии железа, либо с заменой доступных типовых модулей. Просто я работаю в такой компании, которая перешла с чистой электроники в b2b на подписное серверное обслуживание. Хотя, казалось бы, железо никуда не делось. И получается так, что теперь одно решение подходит с небольшими вариациями для многих клиентов всего лишь за счёт программных изменений. А электроника практически унифицирована.

Наверняка могут быть случаи, когда это сработает, но по моему опыту чаще нет.


  1. В крупносерийных изделиях гонятся за каждым центом, оставлять вычислительные мощности и периферию на вырост никто не захочет. Мелкосерийка делается менее впритирку, но вместо М3 ставить А55 с мыслью "а вдруг?" никто не будет.
  2. Встраиваемая техника часто идет под задачу, причем одну конкретную. Т.е. поставил — и не трогаешь, тем более если железка в глубине техпроцесса. Эксплуатируется пока не помрет или пока техпроцесс не сменится.

Больше всего предлагаемое вами похоже на АСУТП, там достаточно часто собирают из типовых модулей и при нужде масштабируют вширь.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории