За годы контрактной разработки электроники и работы в “КЕДР Солюшенс” я видел сотни проектов, некоторые из которых пошли не по плану. И многие факапы, из-за которых горят сроки, лопаются бюджеты, а готовые прототипы отправляются в мусорное ведро, совершают... сами разработчики. Причем часто из самых лучших побуждений: из-за инженерного перфекционизма или желания сэкономить деньги клиента.

Я собрал 10 типовых причин, почему проваливаются проекты по разработке электроники. Проверьте себя и свои проекты, пока не стало слишком поздно!

1. Размытое или неполное техническое задание

Что я считаю неполным или размытым ТЗ:

• нет словаря терминов;

• расплывчатые формулировки;

• перепутаны функциональные и нефункциональные требования;

• нет юзкейсов (сценариев использования продукта);

• не прописано назначение продукта;

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

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

Что же может случиться, если ТЗ будет расплывчатым?

1) Пострадает взаимопонимание между заказчиком и инженерами

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

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

2) Оценка проекта окажется неверной или завышенной

На основе требований, перечисленных в техническом задании, разработчик производит предварительную оценку стоимости и продолжительности проекта. Чем точнее ТЗ, тем точнее будут цифры. А если требования размыты или неполны? 

Вариант 1: исполнитель закладывает в бюджет огромные риски, из-за чего бюджет проекта заметно разувается. 

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

3) Не будет критериев приемки проекта

В техническом задании содержатся параметры, на основе которых проект можно признать состоявшимся или нет. Заказчик может точно оценить, соответствует ли разработанное решение его требованиям, а разработчик точно понимает, к каким характеристикам он должен стремиться при проектировании. И никаких разночтений. Если в документе написано “Задержка должна быть не более 10 мс”, а в действительности у нас задержка 8 мс, то никаких претензий тут быть не может. 

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

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

2. Недооцениваются реальные условия применения устройства и сертификация 

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

• диапазон рабочих температур;

• влаго- и пылезащищенность;

• устойчивость к вибрациям;

• электромагнитная совместимость;

• защищенность от электростатических разрядов.

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

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

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

Подробнее об этом можно почитать в серии наших статей о сертификации электроники на Дзене. 

3. Разрастание объема работ вследствие плохого планирования 

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

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

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

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

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

Разумеется, далеко не каждое изменение вызывает подобные лавины. Но чтобы не рисковать, следует определиться с функционалом устройства еще “на берегу” и постараться воздержаться от значительных корректив в ходе проекта. 

4. Игнорирование жизненного цикла компонентов и логистических рисков 

Устройство редко проектируется “в вакууме”. Оно будет выпускаться на заводе, поставляться в магазины или на предприятия. И если ошибиться при выборе компонентов или их поставщиков сегодня, через полгода производство может встать намертво. 

Типовые ошибки

• Выбор компонентов, жизненный цикл которых подходит к концу

Допустим, в каталоге есть компонент, который идеально подходит для проекта. Но у него статус – “Not Recommended for New Designs” (“Не рекомендовано для новых проектов”), то есть его скоро снимут с производства. Да, обидно, но придется искать альтернативу – разве что команда проектирует единичное изделие не для массового рынка.

• Выбор поставщиков, которых не заменить

Не стоит полагаться на уникальные компоненты, которые выпускает только один завод в мире. Что если там случится пожар, наводнение, забастовка, революция? Проект или выпуск продукции остановится. 

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

5. Отказ показывать промежуточные результаты

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

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

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

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

6. Отсутствие координации между разными командами

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

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

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

7. Слабое тестирование

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

Почему команда может пренебречь тестированием? Часто это следствие сжатых сроков или желания заказчика сэкономить на “невидимой” для него работе. Но в “железе” цена ненайденного бага растет экспоненциально с каждым этапом: от копеечной правки в схемотехнике в начале проекта до отзыва всей партии из магазинов после его завершения. Так что важно уметь отстаивать этот этап разработки.

К числу типовых испытаний в ходе разработки встроенной электроники относятся:

• симуляции работы схем и компонентов;

• функциональное тестирование;

• HIL-тестирование (Hardware-in-the-Loop), когда прошивка работает на реальном контроллере, но внешние сигналы имитируются стендом;

• полевые испытания в реальных условиях эксплуатации;

• статический анализ кода;

• модульные тесты и др.

8. Слабое ведение документации

Ведение документации – это зона ответственности контрактного разработчика электроники. Если в ТЗ не прописан состав и стандарты документации, исполнитель делает только необходимый минимум “для себя” – особенно если сроки поджимают. И, казалось бы, кому какое дело? Но если по какой-то причине заказчик захочет сменить команду, он рискует остаться с “черным ящиком” на руках. То же может случиться с самой командой, если в середине проекта из нее уйдет один из ключевых разработчиков. Тогда проект превращается в археологические раскопки в чужом коде и схемах, перетекая в проект по реверс-инжинирингу. 

В зависимости от выполненных в рамках проекта работ, команда готовит и передает клиенту: 

• блок-схемы системы;

• принципиальные электрические схемы;

• перечень компонентов (Bill of Materials, или BOM);

• файлы с топологией печатной платы; 

• 3D-модели платы;

• сборочные чертежи;

• исходный код встроенного и прикладного ПО;

• инструкция по развертыванию среды;

• описание логики работы устройства; 

• описание методик тестирования устройства для производстве;

• инструкции по обновлению прошивки и др.

9. Медлить с выходом на рынок

Владелец продукта часто думает: “А давайте добавим еще Wi-Fi, датчик освещенности, голосовое управление и беспроводную зарядку”. Звучит, конечно, круто, но в современном мире большую роль играет скорость выхода продукта на рынок. Чем больше фич, тем дольше разрабатывать первую версию устройства и тем дороже она будет. И в этом как минимум две проблемы.

Во-первых, есть вероятность прогадать с гипотезой. Разработчики и заказчик могут думать, что какой-нибудь автоматический подогрев, на который ушло 3 месяца и $10 000 бюджета, – это очень полезная функция. Продукт выходит на рынок, и оказывается, что людям эта фича вообще не нужна. А вот дисплей побольше они бы хотели. Деньги и время потрачены впустую.

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

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

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

10. Пытаться сделать дешевле чем у конкурента

Аргумент кажется очевидным: если у конкурентов прибор стоит $100, а деталей там на $15, то мы можем разработать свою плату, выставить цену $50 и захватить рынок. Но низкая себестоимость – это не главный залог коммерческого успеха. Да, если вы конкурируете со стартапом, который только выпустил первую версию продукта, то сделать свой прибор дешевле можно. Но вы здесь в роли догоняющего. А в большинстве случаев конкурировать по цене с другим производителями и вовсе невозможно. 

Эффект масштаба

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

Борьба с брендами

Бывают и исключения. Например, конкурент накручивает цену за счет бренда. Тогда сделать дешевле можно, но придется соревноваться с чужим брендом, который уже зарекомендовал себя на рынке. В итоге сэкономленные на разработке деньги придется влить в маркетинг. Конечный клиент неохотно покупает ноунейм-электронику, даже если она дешевле. Бренд – это доверие, гарантия, сервис и предсказуемость. Чтобы убедить пользователя купить твое устройство, придется потратить огромные бюджеты на рекламу, ломая его скепсис. \

Скрытые затраты и регуляторика

А еще в некоторых отраслях бывают “закрытые клубы” со своими стандартами и правилами игры, которые приняты на уровне законодательства. Это медицина, авиация, автопром, взрывозащищенное оборудование, промышленное оборудование и др. 

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

Заключение

Разработка электроники – это всегда поиск компромисса между идеальной инженерной мыслью и суровой коммерческой реальностью. Главное – помнить, что вы создаете не просто крутую плату, а продукт, который должен работать в реальных (и порой экстремальных) условиях, приносить деньги заказчику и решать конкретную боль пользователя. Большинства фатальных ошибок можно избежать еще “на берегу”. Не бойтесь задавать клиенту “глупые” вопросы на этапе ТЗ, не затягивайте с показом промежуточных результатов, тестируйте устройство так, будто его собираются запустить в космос, и трезво оценивайте рынок.