Оценка проекта контрактной разработки электроники

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

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

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

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

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

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

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

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

На основе личного опыта нами были сформированы подробные вопросы для подготовки технического задания:

1. Какая цель создания продукта? Перед составлением ТЗ и разработкой проекта нам необходимо понять точную формулировку бизнес-задачи. Таким способом мы отсеиваем «гениальные» идеи очередного автоматизированного коврика для ванной, оснащенного мобильным приложением и Bluetooth.
2. Кто принимает решение по проекту? Как правило, за технику и бюджет отвечают разные люди, к которым необходим индивидуальный подход с точки зрения продажи услуги.
3. Для кого предназначено разрабатываемое электронное устройство? Кто еще будет им пользоваться? Например, оператор, служба поддержки или заказчик.
4. Какие проблемы существуют у каждой группы конечных потребителей? Так мы определяем, отвечают ли заложенные требования разрабатываемого продукта потребностям целевой аудитории. Насколько полно заказчик продумал проект. Каких условий в нем избыточны или недостаточны?
5. Как решаются текущие проблемы целевой аудитории? Какая будет экономическая выгода при разработке нового продукта?
6. Дает ли решение дополнительные возможности и уникальные преимущества?
7. Существуют ли аналоги разрабатываемого электронного устройства? Почему они не подходят для реализации проекта? Чем новое оборудование будет отличаться от аналога? Было ли опробовано существующее решение? Какие результаты исследования и обратная связь были получены? Если идея заказчика не имеет аналогов, то вероятно, что реализуемый проект не найдет потребителя на рынке.
8. Требуется ли интеграция разрабатываемого продукта с другой системой? Возможно ли предоставить пользовательскую документацию, сторонние аппаратные части для внедрения оборудования и проприетарные протоколы? Как планируется проводить приемку готового изделия — в составе системы или на имитаторе?
9. Какие запланированы сроки разработки? Определяем реальный период реализации продукта в зависимости от технического задания заказчика.
10. Сколько образцов изделия планируют заказать на каждом этапе проекта? Какой размер первой партии и предполагаемая годовая потребность продукта?
11. Какая планируется целевая себестоимость? Чаще заказчик еще на стадии формирования идеи знает цену конкурентов и определяет собственные требования к стоимости готового изделия.
12. Кто будет проводить серийное производство — разработчик, компания на аутсорсинге или сам клиент?
13. Потребуется ли помощь в настройке процесса массового изготовления продукта?
14. Необходима ли добровольная или обязательная сертификация готового изделия?
15. Требуется ли помощь в получении авторского права и товарного знака? Должна ли проводиться проверка патентной чистоты на разработку электронного устройства?
16. Потребуется ли техническое обслуживание после производства и внедрения готового продукта?

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

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

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

Задачей каждого участника «Ванга-клуба» является просчитать условия, при которых возможно будет удовлетворить требованиям заказчика. Менеджер стремится учесть риски, чтобы выполнить проект в соответствии со сметой, сроками и в полном объеме. Инженеры могут не взять реализацию простого и «неинтересного» задания. Задача руководителя проекта — провести расчет рентабельности, а менеджера по продажам — знать, как составить КП, которое заинтересует клиента.

Собрание «Ванга-клуба» начинается с обсуждения поставленных задач и формирования единого понимания у всех участников. В ходе дискуссии для проекта строится иерархическая структура работ WBS (Work Breakdown Structure). Для одиночного электронного устройства выделяют программные и аппаратные части. Для корректной работы системы добавляют имитаторы, серверное оборудование, тестовое ПО.

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

Единая задача «написать встроенное ПО для электронного устройства» должна разбиваться на конкретные задания:

• «поднять проект»;
• «схема ЭЗ»;
• «MCU драйвер I2C».

Сформулированным задачам методом экспертной оценки присваивают трудоемкость из ряда степеней в геометрической прогрессии: 2, 4, 8, 16, 32 и т. д. Задания с объемом работ, равным и больше 128 часов, считаются нереализуемыми. Для повторного уточнения требований по проекту потребуется дополнительная проверка применимости выбранных технологий производства. По нашему опыту для повышения точности оценки стоит запрашивать мнение инженеров-разработчиков, которые непосредственно будут работать над заданием.

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

Обсуждение проекта командой специалистов занимает не меньше часа. Обычно оно сопровождается горячими дискуссиями и поиском вариантов оптимального решения поставленных задач. С учетом подготовки к совещанию предварительная оценка занимает у ведущих специалистов от 5 до 20 часов.

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

Итоговые показатели оценки мы заносим в Redmine. Для быстрого добавления задач используем плагин Easy WBS.

Чтобы определить сроки разработки, мы выстраиваем задачи по hardware в каскадные цепочки по принципу водопада. В итоге получаем вот такую диаграмму Ганта:

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

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

Узнать больше информации о том, как наши коллеги оценивают задачи на примере одного запроса можно в статье об аналитике двенадцати КП.

Все проекты заказчиков мы предварительно анализируем и проверяем на рентабельность. К сожалению, для внутренних задач зачастую оценка не выполняется, что приводит к срыву сроков и потраченным ресурсам. Ознакомиться с реализованными проектами компании «Третий пин» можно в разделе «Портфолио».