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

Главное

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

Почему изменения требований — это нормально в долгих проектах?

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

Агрегация требований против итеративного подхода

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

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

Как рынок может измениться за время разработки электроники?

Рынок электроники способен существенно измениться за срок, который занимает типичный проект — от полугода до нескольких лет. Ключевая ошибка в оценке спроса — рассматривать рынок только «здесь и сейчас», хотя продукт выйдет в серию через год или позже, и внешнее окружение к этому моменту может стать другим. Егор Гутеров формулирует это так: «нам надо мыслить категориями будущего. А будет ли он востребован, когда мы его сделаем и поставим в серию?» — и уточняет, что за год «очень много может чего поменяться во внешнем окружении», как в целом на рынке, так и в конкретном сегменте. Оценивайте продукт не только по текущему спросу, но и по прогнозу того, каким рынок станет к моменту серийного запуска.

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

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

Пример: мониторинг глюкозы и вторая версия продукта

Проект по непрерывному мониторингу глюкозы в крови для диабетиков стал для Kedr Solutions наглядным примером того, как рынок опережает разработку. Устройство крепится на руку пациента и непрерывно считывает показатели глюкозы; разработка не была технически сложной, но заняла заметное время, в течение которого на рынок вышли конкуренты с гораздо более миниатюрными решениями. По словам Гутерова, первая версия продукта была сделана «в более крупном размере», а затем на рынке появилось «более миниатюрное решение», из-за чего продукт в исходном виде «не пошёл в серию». Заказчик вовремя оценил ситуацию и не остановил проект, а заказал вторую версию с уменьшенным размером и сниженной себестоимостью.

Что изменилось во второй версии продукта

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

Как выстроить процесс, чтобы изменения не ломали проект?

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

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

Оформление изменений: дополнительные соглашения к договору

Дополнительное соглашение к договору — стандартный юридический инструмент, которым в Kedr Solutions фиксируют любые изменения требований, возникшие в процессе разработки. Механизм применяется при базовом договоре на оказание услуг, когда объём или содержание работ меняется относительно исходного технического задания. Гутеров формулирует правило прямо: «если какие-то появляются изменения в процессе разработки, новые требования, естественно, все оформляется дополнительным соглашением к договору», а техническое задание, если оно существует, «также прикладывается к договору» и становится его неотъемлемой частью в виде приложения. Фиксируйте каждое существенное изменение отдельным документом, а не устной договорённостью в переписке.

Часто задаваемые вопросы

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

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

Как рынок может измениться за время разработки электроники?

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

Что делать, если конкуренты обошли продукт ещё во время разработки?

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

Как правильно оформлять изменения требований в договоре?

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

Можно ли избежать изменений, агрегировав все требования в начале проекта?

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

Итоги

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