Экспертиза и Консалтинг

Вы заказали сложную разработку в области электроники/софта?

Вы не уверены в правильности решений, которые Вам предлагают?

Вас смущает стоимость предстоящего контракта?

Альянс-Электроникс (AE Ltd.) предоставит Вам компетентное «второе мнение» по данным вопросам!

Экспертиза и Консалтинг в области разработки электроники.

Области компетенции

Мы занимаемся экспертизой только в тех областях, в которых команды Альянс-Электроникс (AE Ltd.) обладают большим набором знаний и умений. Если Ваши вопросы вне нашей компетенции, мы сразу сообщим Вам об этом и постараемся связать Вас с соответствующими специалистами.

Области нашей компетенции вы можете посмотреть в разделе Разработка.

Экспертное «второе мнение»

Альянс-Электроникс (AE Ltd.) осуществляет всестороннюю экспертизу по вопросам
разработки электроники, программных комплексов и облачных/серверных решений.

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

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

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

Как правило и отдельные устройства и системы проходят несколько жизненных циклов/версий.
В случае успеха разработки у клиентов, требуются все новые и новые улучшенные версии,
новый функционал, интеграция с другими экосистемами. Однако подчас, разработанная система (даже при корректно выбранной архитектуре) хотя и прекрасно работает, но не имеет значительного потенциала для развития, что снова потребует заново начать разработку и понести значительные затраты.
Адекватна ли цена разработки?
Часто компании предлагают как завышенные цены для совсем простых разработок (пользуясь
незнанием заказчика), так и излишне заниженные цены с целью любой ценой получить нужный
контракт, а потом потребовать значительные средства за каждую мелкую доработку (пользуясь недостаточно проработанным Техническим заданием). Также заниженные цены могут встречаться при неверной оценке сложности контракта и перспектив его дальнейшего развития.

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

Техническое задание

При контрактной разработке электроники Техническое задание (ТЗ) является основным рабочим
документом. В идеале, это совершенный документ, который в деталях описывает все нюансы
функционирования будущей системы/устройства – как с точки зрения Разработчика, так и с
точки зрения конечных Пользователей и Заказчика. В реальности же, составление такого
качественного документа может занять 1-3-6-12 месяцев, что в условиях стремительного
развития является категорически неприемлемым. Кроме того, подчас современные системы
настолько сложны, что зачастую Заказчик может лишь в самых общих чертах сформулировать
свои требования (если у него нет собственных технических специалистов). А для крупных
систем необходимо четко понимать особенности самых разных отраслей современной электроники и программного обеспечения, их взаимосвязи, закономерности и тенденции.

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

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

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

— с нежеланием и/или невозможностью для Заказчика тратить время на согласование ТЗ, когда Заказчик желает сосредоточится на бизнес-вопросах будущего проекта.

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

Альянс-Электроникс (AE Ltd.) предлагает вам услуги быстрого и качественного написания ТЗ
и согласования его с вашим Разработчиком. Являясь третьей стороной, мы незаинтересованны
в сокрытии/недостаточной проработке ТЗ, можем взглянуть на разработку под другим углом,
выявить сильные/слабые стороны предлагаемых Вам решений, указать на скрытые возможности,
которые нужно проработать или потенциально уязвимые места в технической части будущего проекта.

Сосредоточьтесь на продвижении Вашего продукта! Предоставьте проработку ТЗ нам!

Аудит внутренних разработок Вашей компании

Многие компании имеют собственные отделы разработок (R&D департаменты) – как исключительно софтверные команды, так и отделы, выполняющие полный стек аппаратно-программных разработок.

Достаточно часто возникают следующие ситуации:

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

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

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

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

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

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

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

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

Мы верим, что непрерывное развитие и познавание нового – залог успеха при разработке электроники и программного обеспечения!