В прошлый раз я рассказывал о внутренней кухне контрактной разработки в команде КЕДР Solutions, затронул такие темы, как подготовка к проекту, сбор требований и др. В этот раз я решил написать о том, как происходит оплата услуг контрактной разработки электроники. 

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

• Фиксированный бюджет (Fixed Price, Fixed Budget);

• Почасовая оплата, или время и материалы (Time & Material);

• Выделенная команда (Dedicated Team);

• Аутстаф (Outstaffing).

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

Поехали! 

Фиксированный бюджет

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

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

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

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

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

Пример из практики 

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

Получился компактный прибор с двумя платами: одна отвечает за работу портов Ethernet и RS-485, индикаторов и кнопок, а на другой мы разместили сильноточные реле, блок питания, схему измерения тока и ножевые разъемы. В отличие от оригинала, данные о токе ионизации у нас обрабатываются программно, так что работу прибора можно адаптировать под текущие условия, не прибегая к паяльнику. Мы также запилили непрерывный мониторинг внешней нагрузки в реальном времени – если что-то отвалится, контроллер об этом тут же сигнализирует. Такого даже у Siemens нет!

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

Если все-таки нужно внести изменения

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

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

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

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

Идем дальше. 

Почасовая оплата

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

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

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

В таких проектах высока доля исследовательской работы – тестирований, проверок концепций. И тут нереально предсказать, сколько времени на нее уйдет. 

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

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

Пример из практики

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

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

Ключевые особенности проектов по разработке электроники

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

Форс-мажоры

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

Характеристики компонентов не соответствуют заявленным

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

В одной из публикаций я упоминал такой случай. Выбрали для проекта модуль. В даташите было написано, что он умеет получать координаты GPS и передавать данные по GSM. Но когда собрали прототип, мы так и не смогли заставить его делать это одновременно. Связались с разработчиком – оказалось, модуль может работать только в одном режиме за раз, а чтобы переключиться на другой, нужна перезагрузка. 

Чтобы придумать, как обойти такую проблему, или найти и купить альтернативный компонент, требуется дополнительное время. 

Логистические проблемы 

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

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

Меняется стоимость компонентов

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

Сложнее тестировать на конечных пользователях 

В софтовых проектах протестировать прототип решения – даже на множестве пользователей – гораздо легче, чем в хардварных. 

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

Во-вторых, накатить программный апдейт несложно. А если проблема обнаружилась в “железе” у нескольких десятков пользователей? Даже если нужно всего лишь обрезать дорожку или припаять проводульку, придется отзывать устройства, исправлять каждое из них и отправлять на новые испытания. 

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

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

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

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

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

То есть до некоторой степени допиливать “железо” можно. Но рано или поздно потребуется новая печатная плата, потому что в старую перестанет влезать прошивка или она не будет успевать отрабатывать. 

Стоимость изменений может быть очень высокой

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

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

Гибридные модели оплаты

Фиксированный бюджет на каждый новый этап

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

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

Получается такой полу-agile. У модели сохраняется некоторая гибкость (в любой момент можно сменить направление или остановиться), и в то же время есть некоторая определенность относительно стоимости и сроков. 

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

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

Исследовательский этап + фиксированный бюджет

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

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

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

Пример из практики

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

Фиксированный бюджет + почасовая оплата

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

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

Теперь рассмотрим оставшиеся две модели оплаты.

Выделенная команда

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

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

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

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

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

Выделенная команда в проектах по разработке электроники

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

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

Пример из практики

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

На проект были выделены: техлид, три разработчика и тестировщик на полную занятость, а также по мере надобности подключался схемотехник (когда появлялись задачи по “железу”) и ПМ. Мы должны были реализовать пользовательские сценарии, работу с облаком, с обновлениями по воздуху, с фирменным датчиком протечки и электроуправляемыми кранами заказчика, а также со сторонними датчиками Zigbee. Мы также спроектировали испытательный стенд. Проект пилили почти 1,5 года без перерывов, так что выбранная модель сотрудничества оказалась более чем уместна.

Аутстаф

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

Аутстаф в проектах по разработке электроники

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

Аутстафом мы в своей практике пользовались, но исключительно для софтовых проектов.

Пример из практики

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

Подытожим

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

• Разработка электроники больше зависит от внешних факторов и подвержена различным форс-мажорам.

• “Железо” нельзя допиливать бесконечно. Рано или поздно придется делать новую аппаратную платформу. 

• Цена внесения изменений в решение может сильно отличаться от таковой у софтовых проектов. 

• “Железо” сложнее тестировать и дорабатывать.

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

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