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

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

... большинство фирм специализируются на разработке цифровой и силовой электроники.

Цифровая или аналоговая электроника сильно разная и в такой оценке, как у вас, кроется большая проблема. Одно дело сделать плату на микроконтроллере и на это способно много компаний. Другой дело разработать и произвести плату на CPU или на FPGA, а на это способна не каждая компания из вашего списка и не только из вашего. Другими словами ваша статистика по специализации компаний не отображает реальность.

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

Вообще, со статистикой по рынку контрактной разработки есть определенные проблемы. До недавнего времени цифр по объему рынка, специализиации компаний, средней выручке почти не было. В статье приведены данные из материалов конференции “Контрактная разработка электроники 2022”. Автор доклада приводит именно такую статистику.

со статистикой по рынку контрактной разработки есть определенные проблемы.

Проблемы действительно есть. В этой статистике отсутствуют продуктовые компании, которые занимаются кастомизацией изделий под заказчика. По сути это тоже является заказной разработкой.
Добровольного анкетирования компаний входящих в АРПЭ, к сожалению, не достаточно, так как существуют компании, которые в ассоциации не состоят. Нужно использовать другие способы оценки объёма рынка.

Абсолютно согласен – статистика неполная и многого не учитывает. Увы, на данный момент другой нет. Будем надеяться, что в скором времени нам будет доступна более полная информация.

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

Заказчик на старте озвучивает бюджет и срок, и команда решает, стоит ли браться. Провал — смотря чья вина: если устройство изначально неработоспособно (вечный двигатель) — это риски заказчика; если же команда не справилась с работой — например, не смогли нарисовать дорожки так, чтобы заработала DDR-3 память — то заказчик не платит.

Вот только не бывает таких крайностей. Обычно бывает сразу несколько проблем и каждая из которых может быть на разных сторонах ответственности. Из-за чего становится сложно "найти крайнего" в провале проекта.

Заказчик в договоре точно не припишет критерий приемки, так как у него может не быть компетенции. Исполнитель делает как умеет.

если же команда не справилась с работой — например, не смогли нарисовать дорожки так, чтобы заработала DDR-3 память — то заказчик не платит.

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

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

Красиво пишите..

Ну, что есть, то есть. )

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

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

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

А вообще, вы подсказали любопытную тему. Возможно, стоит написать об этом отдельный материал. Спасибо :)

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

Публикации