Контрактная разработка электроники: 7 ошибок, которые дорого обходятся заказчикам

Команда “КЕДР Солюшенс” выполнила более 300 проектов в качестве контрактного разработчика электроники. Наш опыт показывает, что многие проблемы в проектах, приводящие к дополнительным затратам, связаны не со сложностью инженерных задач, а с просчетами в организации работы со стороны заказчика. Такие ошибки не всегда приводят к провалу всего проекта, но из-за них смещаются сроки и разрастается бюджет.


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

Ошибка №1: Сразу делать финальный продукт

Если заказчик хорошо понимает рынок

Успех нового продукта определяется тем, насколько он соответствует потребностям рынка. Обычно идея продукта не возникает на пустом месте. Заказчик разработки либо целенаправленно исследует рынок в поиске определенной ниши, либо напрямую связан с рынком и потому видит потребности его участников. 

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

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

Однако представление заказчика о целевом рынке и его потребностях не всегда оказывается достаточно точным.

Новый рынок или инновационный продукт 

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

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

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

MVP и обратная связь от рынка

Более безопасный подход – собирать обратную связь от рынка еще до того, как появится финальный продукт, уже на стадии готовности минимально жизнеспособного продукта (MVP), в котором реализованы только базовые функции. 
 

Для проверки продуктовых гипотез заказчик может применять разные методы в зависимости от отрасли и типа продукта:

• Демонстрировать прототип на выставках и отраслевых мероприятиях. 
• Проводить кастдев-интервью с потенциальными пользователями. 
• Показывать прототип текущим клиентам.
• Собрать одностраничный сайт с информацией о продукте (в том числе о тех функциях, которые только планируется реализовать) и продвигать его через контекстную рекламу, чтобы оценить объем заявок и, соответственно, потенциальный спрос. Этот метод подходит для продуктов, ориентированных на массовый рынок. 
• Воспользоваться краудфандинговыми платформами, которые позволяют не только собрать средства на разработку, но и проверить интерес потенциальных покупателей к продукту. Стоит, однако, помнить, что такие платформы больше распространены за рубежом и преимущественно ориентированы на сегмент B2C.

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

Ошибка №2: Полностью перекладывать формирование требований на подрядчика

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

С точки зрения распределения ответственности требования можно разделить на следующие категории:

• Требования, определяемые заказчиком
  Это прежде всего бизнес-требования и требования, касающиеся сертификации продукта, его вывода на рынок, форматов испытаний изделия, требования к документам на продукт и другие, где нужна рыночная экспертиза клиента.
• Требования, определяемые исполнителем
  Сюда относятся требования, связанные преимущественно с технической стороной проекта, в том числе требования к надежности и ремонтопригодности устройства, к обслуживанию или будущему производству. 
• Требования, формируемые совместно
  В этом случае заказчик формулирует требование с позиции бизнеса, а исполнитель помогает “перевести” его на технический язык. 

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

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

Ошибка №3: Начинать основную разработку, не сняв ключевые технические риски 

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

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

Исследовательский этап позволяет заранее понять:

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

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

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

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

Ошибка №4: Игнорировать промежуточные результаты проекта

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

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

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

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

Проверяя работу команды в конце каждого этапа, заказчик может:

• выявить разночтения в понимании тех или иных пунктов ТЗ;
• убедиться, что проект движется в соответствии с ожиданиями;
• обнаружить технические ограничения, которые не были учтены на старте;
• сформулировать новые предложения или требования и своевременно оценить возможность их включения в проект.

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

Если внутри компании нет нужных компетенций
В последнем случае рекомендуется заранее, еще в начале проекта, составить программу и методику испытаний – документ, в котором прописано, как будет осуществляться приемка продукта, какие тесты он должен пройти, какие режимы работы продемонстрировать, каким характеристикам, нагрузкам или допускам он должен соответствовать. ПМИ дополняет техническое задание: понимая, по каким параметрам будет оцениваться результат, команда разработки сможет точнее учитывать требования заказчика на протяжении всего проекта. 

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

Ошибка №5: Избыточно разделять работу между несколькими подрядчиками

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

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

• На поиск нескольких подрядчиков уходит больше времени и ресурсов, чем на поиск одного или двух.
• Роль интегратора, который координирует работу всех исполнителей, приходится брать на себя заказчику или его сотруднику. Либо приходится нанимать интегратора со стороны. 
• Могут возникать проблемы с интеграцией всех элементов: например, приложение и устройство могут корректно работать по отдельности, но при их взаимодействии возникнет ошибка. При этом потребуется дополнительное время, чтобы определить источник проблемы.
• Ответственность размывается между участниками проекта: каждая команда уверяет, что проблемы на стороне другого подрядчика.

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

Ошибка №6: Не закладывать ресурсы на переход от чертежей к реальному устройству 

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

• модель не полностью соответствует реальности;
• неточности и ошибки в документации компонентов;
• реальные характеристики компонентов отличаются от заявленных;
• компоненты становятся недоступны;
• проблемы с поставками;
• реальные условия эксплуатации отличаются от расчетных. 

Если у клиента мало опыта в контрактной разработке или производстве, возникновение таких проблем может создать впечатление, что проект развивается не по плану. Однако в действительности все эти трудности вполне решаемы и являются неизбежной частью процесса проектирования. Для этого разработчик закладывает несколько итераций устройства (обычно 2–3), подбирает возможные альтернативы компонентам и т.д. 

Ошибка №7: Выбирать подрядчика только по стоимости услуги

Желание оптимизировать стоимость разработки вполне понятно. Но выбор исполнителя должен основываться на множестве факторов, и цена – лишь один из них.

При выборе контрактного разработчика следует также учитывать:

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

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

Ниже приведены примеры вопросов, которые следует задать кандидату, а также ответы, которые указывают на добросовестность или недобросовестность команды. 

1. Что входит в стоимость разработки?
   Зрелая позиция: Подробный расчет по этапам. Отдельно указаны лицензионные или производственные расходы и риски. Возможные опции.
   Тревожный сигнал: Общая стоимость проекта без разбивки. Не расписаны дополнительные расходы.
2. Кто будет руководить проектом и кто основной контакт?
   Зрелая позиция: Конкретное имя и должность. Опыт руководства похожими проектами. Регулярное время общения.
   Тревожный сигнал: Постоянные смены ответственных. Нет закрепленного руководителя проекта. “Если что, мы напишем”.
3. Можно обсуждать проблемы напрямую с разработчиками?
   Зрелая позиция: Допускается прямой контакт с разработчиками, но он не подменяет менеджера проекта.
   Тревожный сигнал: Общение только через руководителя проекта или аккаунт-менеджера.
4. Как устроен процесс разработки?
   Зрелая позиция: Четко описанный процесс с этапами и результатами. Система контроля версий. Готовность прописать в договоре критерии приемки.
   Тревожный сигнал: Отсутствие фиксированных этапов или разбивка на слишком крупные блоки. Нет четкого контроля версий. Отказ обсуждать критерии приемки.
5. Как вы проводите верификацию и валидацию?
   Зрелая позиция: Готовность предоставить тест-планы и отчеты с результатами.
   Тревожный сигнал: Общие обещания типа “Мы пришлем, вы посмотрите”.
6. Какие гарантии и постпроектную поддержку вы обеспечиваете?
   Зрелая позиция: Гарантийные сроки и объем работ по поддержке и исправлениям прописаны в договоре.
   Тревожный сигнал: Отказ формализовать обещания. “После сдачи все на обсуждении”. Отказ от последующей поддержки.
7. Как вы строите коммуникацию и отчетность?
   Зрелая позиция: Регулярные отчеты, демо, доступ к прототипам в соответствии с договоренностями. Календарь встреч.
   Тревожный сигнал: Отказ демонстрировать промежуточные результаты.
8. Вы передаете права на интеллектуальную собственность?
   Зрелая позиция: В договоре прописана передача всех прав, прототипа и документации. В договор можно вносить правки.
   Тревожный сигнал: Отказ показать образец договора. Не согласны на правки в договоре. Уклончивые формулировки в договоре. Прямой отказ от передачи интеллектуальных прав. Скрытые положения о повторном использовании решений.

Вывод
Контрактная разработка – это скорее совместная работа клиента и исполнителя, чем передача проекта “под ключ”. Многие проблемы здесь возникают не по техническим причинам, а из-за слабой коммуникации и организации проекта, неясно сформулированных требований, недостаточно исследованного рынка. 

Поэтому перед тем как начинать проект, убедитесь, что вы готовы, смирившись с этим чек-листом:

• Учтены ли все факторы при выборе подрядчика?
• Проверен ли спрос на продукт?
• Определены ли специфические и отраслевые требования?
• Есть ли в проекте “узкие места”, требующие исследований?
• Есть ли в вашей команде компетентные люди для приемки результатов?
• Сведено ли к минимуму число команд?
• Вы готовы к неожиданностям в реальности?