Контрактная разработка электроники. Расчёт проекта

Каждый месяц к нам приходят десятки заявок на разработку электроники. И каждый потенциальный заказчик желает узнать стоимость решения своей проблемы, вне зависимости от того, насколько хорошо он сам её понимает. Может ли контрактный разработчик угодить всем? Как заранее отсеять «бесперспективных»? Как оценить те проекты, которые имеют шансы на развитие? Об этом наша новая статья.

Какие проекты считать не надо

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


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

Что нам надо спросить, чтобы оценить шансы проекта на успех?

1. Почему организации нужно данное изделие (цели создания изделия)? Нам нужно выяснить максимально точную формулировку бизнес-задачи.Так мы отсеиваем мечтателей с очередной «гениальной идеей» автоматизированного коврика для ванной, с блютусом и мобильным приложением.
2. Кто является инициатором проекта (ЛПР)? Выясняем, кто отвечает за технику, и кто выделяет бюджет. Обычно это разные люди, и к ним требуются разные подходы с точки зрения продаж.
3. Кто конечный пользователь изделия (целевой пользователь)?
4. Кто еще будет пользоваться. Пример: служба поддержки, оператор, регулятор, сам заказчик и т.д?
5. Какие имеются проблемы у каждой из групп конечных пользователей (проблемы могут быть разные и независимые, формулируются цитированием)?
   Нам нужно максимально прояснить все роли и все сценарии использования будущего изделия. Так можно определить, насколько глубоко Заказчик продумал проект в целом, какие требования в его задании избыточны, а каких не хватает.
6. Как существующие проблемы решаются в настоящий момент (описать решение)? Выясняем специфику и контекст, получаем представление о том, сколько эта проблема стоит, и получит ли Заказчик экономический эффект в результате разработки нового продукта. «Не делать ничего» тоже может быть решением проблемы =)
7. Какие дополнительные возможности дает решение проблемы (фичи и т.д., если они есть)?
8. Есть ли уже существующие аналоги?
   
   
   • Если ответ — ДА:
     
     1. Что за аналоги (названия, ссылки)?
     2. Почему они не подходят?
     3. В чем уникальность нового решения (УТП), чем оно должно отличаться от аналогов? Было ли оно опробовано где-либо? Какой был фидбек?
   • Если ответ — НЕТ: Высока вероятность неудачи. Нам выпало жить в эпоху, когда так или иначе уже решены все основные базовые проблемы людей, а на рынке присутствуют решения для почти всего на свете. Если задумка Заказчика «не имеет аналогов», вполне возможно, она не имеет и рынка.
   • Осуществлялся ли поиск существующих решений? Как? Могут ли быть предоставлены результаты? Если ответ НЕТ — крайне высока вероятность неудачи.
9. Требуется ли интеграция с другой системой? Если ответ — да:
   • Какие системы (названия, ссылки)?
   • Какие протоколы (названия, ссылки)?
   • Возможно ли предоставить все проприетарные протоколы при их наличии и пользовательскую документацию?
   • При наличие сторонних аппаратных частей системы, будут ли они предоставлены и когда?
   • Как предполагается проводить приемку разрабатываемого изделия (на имитаторах или в составе системы)?
10. Какие вехи (сроки) разработки уже существуют (и причина их возникновения)? Все хотят «вчера», но это далеко не всегда чем-то обусловлено. Разбираемся в реалиях Заказчика, рассказываем ему анекдот про 9 месяцев.
11. Какая серийность изделия? Идеальный Заказчик в ответ на этот вопрос сообщает желаемое количество образцов на каждом этапе, размер первой партии и предполагаемую потребность в год. Остальным рассказываем, почему так важно знать размер серии, если задумал серийное производство.
12. Какая целевая себестоимость изделия (плата, корпусированное изделие, коробочная версия изделия, акссессуары)? Обычно в ответ звучит «мы думали, вы нам скажете». Но на самом деле у Заказчика чаще всего есть представление о целевой себестоимости, на основе цены конкурентов или собственных бизнес-требований.
13. Кто осуществляет последующее производство серийных изделий? Вариантов ответов обычно три: сам Заказчик, контрактное производство или разработчик.
14. Требуется ли налаживать процесс серийного выпуска изделий с постановкой на производство? Даже если Заказчик будет производить изделие на собственных мощностях – ему может потребоваться помощь в постановке на производство и в тестировании.
15. Требуется ли сертификация? Какая именно сертификация необходима (добровольная, СИ, ЕАС, РЭС, СЕ). Сертификатов может быть несколько. Чьими силами она осуществляется?
16. Требуется ли проверка патентной чистоты на разрабатываемое изделие? Чьими силами она осуществляется?
17. Требуется ли помощь в правовой защите (патенты, товарные знаки, авторское право)?
18. Предполагается ли после этапа внедрения заключать соглашение об уровне обслуживания? Для самых серьёзных ребят.

Ванга-клуб

Итак, клиент и проект отвечают всем требованиям, начинаем оценку. Оценка бывает неточной и негодной. Если у нас пока нет ТЗ, мы получаем негодную оценку с большим разбросом. Написали ТЗ – получили неточную оценку. Без ТЗ оценка имеет допуск ±400% и более. Вот это называется конус неопределённости:


График про интерфейсы, но суть на разных проектах одна и та же. Чем больше мы знаем, тем меньше неопределённость. Не жалейте времени и сил на ТЗ.

Собрания по оценке проектов у нас имеют неофициальное название «Ванга-клуб». Участники заранее знакомятся с материалами по проекту. В назначенный час в Клуб приходят: коммерсант, руководитель проекта, ведущий схемотехник, ведущий программист. Иногда приглашаются дополнительные специалисты с узкой экспертизой, а также представители подрядчиков. Столько людей нужны для всестороннего рассмотрения проекта. Коммерсант рад своей удаче и стремится удовлетворить клиента, упрощая требования. Менеджер проекта должен будет воплотить проект в жизнь, ему отвечать за сроки, стоимость и объём работ. Его стремление – заложить запас, учесть риски. Инженеры хотят делать лучше, чем вчера. Они могут запросто отказаться от простого, но «неинтересного» варианта. Без руководителя проектов можно взять недооцененный заказ, ведь коммерсант бывает очень красноречив. Без коммерсанта можно насчитать так много, что клиент даже не ответит на письмо.



Встреча начинается с общего обсуждения задачи для формирования одинакового понимания всеми участниками. Затем для проекта строится иерархическая структура работ (ИСР, WBS).
Для одинокого устройства выделяются части software и hardware. Для системы добавляются разные части вроде тестового ПО, имитаторов, серверной части и т.д. Полученные части дробятся на части поменьше, например, hardware ветвится на две ревизии PCB и Конструкцию. Следующая стадия – разбить части на отдельные задачи. Если с реализацией всё ясно – задачи должны быть небольшими. Задача «Написать встроенное ПО» категорически не подходит. Нормальными считаем конкретные задачи с небольшими оценками, например: «MCU Драйвер I2C», «Поднять проект», «Схема Э3».
Не стоит оценивать трудоёмкость задач раньше времени, ведь их комплексность и взаимосвязи прояснятся только тогда, когда все они будут записаны на доске.

Всем задачам присваивается трудоёмкость в часах. Метод – экспертная оценка. Часы могут принимать значения из ряда степеней двойки: 2, 4, 8, 16, 32, 64, 128 … Задачи с оценкой 128 часов и более появляются, когда реализация не ясна. Это значит, стоит провести работы по уточнению требований, проверке применимости технологий, а иногда даже просто разойтись и покурить погуглить.
По моим наблюдениям, можно повысить точность оценки, в первую очередь запрашивая мнение менее опытных разработчиков. Так они быстрее учатся оценивать задачи самостоятельно. Если авторитетный инженер уже высказался, все остальные склонны просто согласиться с его мнением. А когда начнутся работы на проекте, задачи, скорее всего, решать будет уже не он, а те, кто промолчал. Их оценку мы всё равно услышим, но не вовремя.
Когда все задачи оценены, мы суммируем результаты и добавляем 30% к ПО на отладку и ещё 30% на тестирование ПО. Эти цифры взяты из статистики по законченным проектам.
В итоге, на доске получается вот такая картина:



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

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

Полученные от Ванга-клуба оценки мы заносим в Redmine. Для быстрого добавления задач в наглядной форме подходит easyWBS:




Для определения сроков разработки выстраиваем задачи по железу в цепочки (waterfall). Получаем вот такого Гантта:



Для софта мы делим трудоёмкость на производительность того количества людей, которое может быть задействовано в проекте одновременно. Как известно, то, что один программист сделает за месяц, два программиста сделают за два месяца. Так что учитывать весь свой кадровый ресурс при расчёте не стоит. Так же, не в каждом проекте программисты могут начать работы с самого старта. Бывает, нужно дождаться железа, своего или покупного. Такая же задержка может возникнуть на стыке этапов и ревизий железа.
Для информирования заказчика полученные сроки брать нельзя. Разве что с приставкой «оптимистичный прогноз». Лучше дать небольшой запас. Он пригодится.

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



Прекрасное коммерческое предложение для заказчика.pdf мы создаём прямо отсюда.

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

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

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

А теперь — айда обсуждать в комментариях ваши подходы к оценке проектов!