Почему hardware-проекты срываются, даже когда всё идёт по плану

Почти каждый hardware-проект начинается довольно оптимистично. Есть концепция продукта, команда, бюджет и красивая диаграмма Ганта с PoC, EVT, DVT, PVT и долгожданной серией где-то справа. На бумаге всё выглядит логично: разработать электронику, сделать механику, написать прошивку, собрать прототип, провести испытания — и через условные девять месяцев получить продукт.

А потом двигатель начинает перегреваться в реальном цикле нагрузки, плата не проходит EMC, редуктор показывает слишком большой люфт, батарея внезапно не обеспечивает расчётную автономность, а нужный компонент оказывается с lead time в 40 недель. Обычно в этот момент говорят: «Ну, это же R&D. Возникли непредвиденные проблемы».

Но большая часть этих проблем не была непредвиденной. Мы просто слишком рано приняли предположение за факт. Решили, что выбранный двигатель потянет нужный режим, хотя проверили его только на стенде. Посчитали себестоимость по предварительному BOM. Зафиксировали корпус до проверки теплового режима. Пообещали дату DVT, хотя критическая архитектура ещё не прошла EVT.

Само по себе незнание не является проблемой. R&D существует именно потому, что в начале проекта мы очень многого не знаем. Проблема начинается тогда, когда на основании этого незнания мы начинаем принимать дорогие решения.

На PoC отказаться от неработающего технического принципа неприятно, но относительно дёшево. После EVT изменение архитектуры уже тянет за собой новую ревизию платы, механику и повторную интеграцию. После DVT можно приехать к переделке оснастки и повторной сертификации. А в серии ошибка превращается в rework, сервис, списание устройств или отзыв продукта.

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

Отсюда довольно простой взгляд на управление Hardware R&D: прогресс проекта — это не количество закрытых задач, а количество критических предположений, которые мы успели заменить доказательствами.

Обычный backlog отвечает на вопрос, что команда должна сделать: развести плату, заказать детали, собрать двадцать образцов, написать firmware, провести тест. Но рядом должен существовать второй список, который отвечает на гораздо более важный вопрос: что мы пока не знаем?

Например, выдержит ли тепловой контур максимальную нагрузку при +40 °C, получится ли стабильно выдерживать нужный допуск в серийном производстве, доступен ли выбранный IMU в нужных объёмах, действительно ли пользователь готов заряжать устройство каждый день и получится ли вообще удержать BOM в целевой себестоимости.

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

Например, фраза «есть риск перегрева» почти бесполезна. Гораздо полезнее сформулировать вопрос так: «Неизвестно, удержит ли система температуру двигателя ниже допустимого предела при максимальной нагрузке и температуре окружающей среды +40 °C. До фиксации корпуса нужно провести нагрузочный тест интегрированного образца».

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

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

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

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

И если эксперимент доказал, что выбранная архитектура не работает, это не провал R&D. Если мы выяснили это на PoC за две недели и несколько тысяч долларов вместо того, чтобы узнать то же самое после DVT-партии и заказа оснастки, эксперимент отработал идеально.

Отсюда же вытекает ещё одна проблема hardware-разработки. EVT, DVT и PVT часто постепенно превращаются просто в названия партий: наступил октябрь — значит делаем EVT, наступил декабрь — пора DVT, производитель забронировал окно — значит запускаем PVT.

Хотя смысл этих этапов вообще не в календаре. Каждый следующий этап должен подтверждать определённый уровень знания о продукте. PoC должен доказать, что критический технический принцип вообще работает. EVT — что интегрированная инженерная система выполняет основные функции. DVT — что близкая к финальной конструкция действительно соответствует требованиям. PVT — что выбранный производственный процесс способен повторяемо выпускать этот продукт. А серия должна показать, что качество и экономика сохраняются уже в реальном объёме.

То есть контрольная точка должна отвечать не на вопрос «всё ли мы сделали по плану?», а на вопрос «достаточно ли мы уже знаем, чтобы принять следующее дорогое решение?».

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

Заказывать дорогую оснастку до подтверждения геометрии только потому, что «иначе потеряем две недели», — это не ускорение проекта. Это покупка двух недель ценой потенциально очень дорогой ставки на ещё не проверенное предположение.

Я очень люблю диаграммы Ганта. Они прекрасно показывают известные работы, зависимости, поставки, производство и испытания. Проблема начинается, когда диаграмму Ганта начинают использовать как модель самой реальности.

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

Одна красивая линия от сегодняшней даты до Mass Production всего этого просто не показывает. Поэтому хороший R&D-план со временем должен становиться точнее: на старте есть диапазоны и основные развилки, после PoC вариантов становится намного меньше, после EVT появляется довольно уверенный план, а после DVT можно строить практически детерминированный производственный график.

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

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

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

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

И, пожалуй, самое важное: за плохой результат хорошего эксперимента нельзя наказывать. Если система требует от инженеров только подтверждать уже обещанный план, довольно быстро появляются удобные режимы испытаний, зелёные статусы и фраза «думаю, должно работать». А потом наступает DVT.

Главная задача управления Hardware R&D не в том, чтобы заставить проект любой ценой следовать первоначальному графику. Она в том, чтобы ошибочные предположения становились видимыми раньше, чем превращаются в дорогие необратимые решения.

Поэтому зрелость проекта я бы измерял не процентом выполненных задач, а тем, насколько далеко команда успела пройти путь от «мы думаем, что это работает» до «мы это проверили — и вот данные».