Один подрядчик или несколько в разработке электроники

Почему заказчики дробят проект на несколько подрядчиков

Дробление проекта на нескольких подрядчиков возникает, когда заказчик считает, что каждая часть устройства требует отдельной узкой экспертизы, недостижимой у одной команды. Чаще всего это происходит в проектах, где готовый прибор объединяет разные инженерные дисциплины — например, корпус, электронную начинку и встроенное программное обеспечение. По наблюдению Kedr Solutions, разработка прибора редко ограничивается только платой и вычислительным модулем: в проект вполне может входить механическая часть и внешнее программное обеспечение, взаимодействующее с оборудованием. Оценивайте необходимость каждого отдельного подрядчика по реальному набору компетенций проекта, а не по привычке разносить риски.

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

Подробный разбор системных ошибок заказчиков на старте проекта — в статье 7 ошибок заказчиков при контрактной разработке электроники.

Какие зоны ответственности обычно делят между подрядчиками

Зоны ответственности в проекте разработки электронного устройства обычно распределяют между четырьмя направлениями: промышленный дизайн, механика, электроника и программное обеспечение. Такое деление применяют, когда заказчику нужен готовый потребительский продукт, а не только плата или модуль, — тогда внешний вид, механическая конструкция и электронная начинка требуют разных инженерных подходов. В практике Kedr Solutions встречались проекты, где эти четыре направления вели действительно разные подрядчики — но с чётко прописанными зонами стыка между ними. Делите проект по этим направлениям только если у вас нет одного исполнителя, закрывающего сразу несколько из них.

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

Кто виноват, если ничего не работает?

Отсутствие единой ответственности — главная проблема схемы с несколькими подрядчиками: когда устройство не работает, каждая команда указывает на соседнюю, а не на себя. Ситуация типична для проектов, где аппаратную часть и встроенное программное обеспечение делают разные компании без общего протокола диагностики сбоев. По наблюдению Kedr Solutions, классический сценарий выглядит так: начинаются разборки, проблема на стороне аппаратной части или на стороне программной, — и если это разные подрядчики, есть шанс, что каждый будет утверждать, что проблем на его стороне нет. Пока стороны спорят, кто виноват, проект фактически стоит на месте и не движется вперёд. Заранее договоритесь с каждым подрядчиком о едином формате диагностики сбоев и совместных тестах на стыке компетенций.

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

Почему растёт нагрузка на менеджера заказчика при нескольких подрядчиках

Нагрузка на менеджера заказчика растёт пропорционально числу подрядчиков, потому что координировать работу нескольких независимых команд сложнее, чем контролировать одного исполнителя. Проблема проявляется в проектах, где на стороне заказчика выделен один человек, отвечающий за приёмку и синхронизацию сразу нескольких договоров. По наблюдению Kedr Solutions, чем больше подрядчиков у заказчика, тем больше реальная нагрузка на выделенных на его стороне менеджеров — нужно координировать работу у всех этих команд и очень четко разделять зоны стыка между ними. Если у заказчика нет отдельного технического координатора, минимизируйте число независимых подрядчиков в проекте.

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

Пример из практики: подрядчики в разных часовых поясах

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

Разница во времени особенно ощутима на этапах, требующих быстрой обратной связи — например, при разборе сбоя на стыке аппаратной и программной части. Практический подход к выбору исполнителя с учётом таких рисков описан в статье Как выбрать контрактного разработчика электроники.

Один подрядчик или несколько: как выбрать модель

Правильная модель зависит от количества объективно разных компетенций в проекте, а не от желания разложить риски по нескольким компаниям. Один подрядчик с внутренними специалистами по электронике, механике и встроенному ПО удобен тем, что у заказчика остаётся одна точка входа — менеджер проекта, который сам координирует стыки внутри своей компании. По практике Kedr Solutions, удобно, когда есть одна точка входа на стороне исполнителя, при этом заказчик сохраняет возможность прямого общения с профильными специалистами — техлидами, схемотехниками, топологами, программистами. Егор Гутеров прямо называет делегирование всего на одного исполнителя без контроля и избыточное дробление между большим количеством подрядчиков двумя частыми ошибками заказчиков.

Практический вывод: делите проект между подрядчиками ровно по числу направлений, которые объективно требуют разной экспертизы, и не больше. Для каждого дополнительного подрядчика заранее считайте не только стоимость его работ, но и стоимость координации — время менеджера заказчика, риски на стыках и формат отчётности. Если такого ресурса на стороне заказчика нет, предпочтительнее один подрядчик с полным набором внутренних компетенций.