Лет так десять назад делал ремонт в квартире. Договорился с бригадой делать именно по этапам. После разводки проводки пришел проверить. Посмотрел, померял и понял, что розетка под телевизор в гостиной окажется закрыта шкафом. Немного поругались, но переделали. Если бы я решил принять работы только в конце ремонта, пришлось бы снимать обои и штробить по новой. Да, конечно, в суде я был бы прав, но ремонт не сделан, денег нет, суды тянутся. Такая себе альтернатива.
Или вот несколько раз приходилось отдавать авто на ремонт арок и порогов, плюс несколько кап. ремонтов двигателей. Сроки исполнения и результат были очень разные. Пару раз приходилось ждать прям долго. Один раз сделали быстро (пороги). Как выяснилось через пару лет, сделали сравнительно плохо, найти исполнителя я уже не смог.
За 3-4 года до этого другие ребята делали арки пару месяцев. Арки продержались дольше порогов. Плохо затянутый болт на шкиве двигателя обнаружили спустя 3 года после “капиталки”, когда ремни внезапно слетели, а посторонний звук был сразу, но его списали на некачественный гидрокомпенсатор, который я им привез, а не они сами купили.
Если смотреть на конечный результат, то он сравнительно одинаковый. Мелкие косяки поправят сразу и без проблем. Большая часть проблем будет потом.
Так вот, жизненные выводы - проверять как можно чаще, что делают, а не то с каким умным видом рассказывают. Если не хотят показывать, то либо ничего не делали, либо сделали то, что надо скрыть.
Возвращаясь к проектам по электронике. Если заказчик настаивает на фиксированной оплате в конце проекта и не хочет проверять/принимать этапы, то это его право. Но стоимость такого проекта будет эдак в 1,5-3 раза выше, чем могла бы быть. Именно потому, что все риски берет на себя исполнитель. И сроки там будут заметно больше, чем могли бы быть. Так исполнитель гарантирует для себя, что проект будет сделан и его примут, даже если возникнут какие-то непредвиденные трудности.
Большая часть наших заказчиков технически компетентна в разработке электроники, но есть и заказчики из других отраслей. С первыми работать легче, но я бы не сказал, что вторым нельзя обращаться за контрактной разработкой. Иногда вторая категория заказчиков действительно использует дополнительных консультантов для аудита проекта.
Если рассматривать сотрудничество заказчик-исполнитель с точки зрения, что кто-то будет лукавить, то любая модель оплаты может быть использована для махинаций. )) В статье я рассмотрел вопрос только с позиции Win-Win. В отдельной статье могу написать несколько кейсов, когда заказчики нам под тем или иным предлогом отказывались платить, хитрили, спекулировали формулировками из документов, пытались заставить доделывать функционал, которого вообще не фигурировало в ТЗ, обосновывая свою позицию формулировкой “нувыжеспециалисты”. ))
Если проект не фиксированный и заказчик сам точно не знает, каким должен быть продукт, то, конечно, на нем значительная доля ответственности. Подрядчик обязан оценить пожелания заказчика и предупредить о возможных сложностях в плане стоимости, сроков разработки, реализуемости и т.д. Но последнее слово за клиентом. Модель также подразумевает, что результат этапа или нескольких этапов можно проверить и оценить за короткий промежуток времени.
Если видение продукта четкое, то лучше подходит фиксированная оплата. Тогда все риски берет на себя исполнитель. И да, в договоре должны быть четко прописаны критерии приемки продукта. Разбивку проектов на этапы придумали еще задолго до нас (ГОСТ Р 53736-2009 - один из самых свежих). В некоторых случаях заказчики сами просят это сделать. Проконтролировать исполнителя и поправить недочеты всегда проще по ходу разработки, нежели в самом конце требовать возврат денег за отсутствие требуемых результатов. Макеты и прототипы как раз и делаются для проверки гипотез и принятых проектных решений. На мой взгляд (уже как потребителя/заказчика), стоит как раз опасаться ситуации, когда вам отказывают в промежуточных демонстрациях и этапах.
Когда нужна узкая экспертиза, возможны варианты. Если такого опыта нет, честно говорим заказчику: мы не умеем, но можем попробовать и будем учиться за ваш счет. Если клиенту норм, то работаем так. Аутсорс – тоже вариант. Мы на постоянке работаем с проверенными спецами, с ними проблем не возникало.
По поводу компонентов, когда имеем дело с незнакомыми, то паспортным характеристикам не доверяем. Уже обжигались с этим, и не раз. Вопрос про тестирование очень объемный. Смогу ответить только частично. Моделированием активно пользуемся, разброс параметров при этом тоже учитываем. Также проводим испытания опытных образцов. Разрабатываем методики и стенды для тестирования при производстве как отдельных модулей в составе устройств, так и устройств целиком.
Вероятно, да. Рост отрасли подразумевает приход в нее дополнительных трудовых ресурсов. Государство активно продвигает обучение IT специалистов и инженеров, но насколько эти усилия успешны – это другой вопрос. Мне кажется, интерес молодежи к высшему образованию сейчас не слишком высок.
На данный момент был разработан рабочий прототип для серийного производства. Мы использовали nRF вместе с ESP32, так как для устройства требовалась одновременная работа WiFi и BLE. Также в перспективе планируется реализация поддержки ZigBee и OpenThread, для чего также проще использовать отдельный микроконтроллер nRF.
Грамотно составленное ТЗ абсолютно не противоречит Agile подходу. Во всем нужен баланс. Да, работающий продукт важнее скрупулезно подготовленной документации, но, согласитесь, вы не можете работать над масштабным проектом, не имея вообще никакого плана.
Здесь речь идет о ТЗ не как о пошаговой инструкции, а как о некой канве проекта, которая одинаково важна и разработчикам, и заказчику.
Клиент видит, за что он платит деньги, когда и на каком этапе будут промежуточные результаты. Плюс здесь же он документирует свои видения и пожелания.
Разработчикам нужно ТЗ, чтобы собрать воедино как видение заказчика, так и соображения своих хардовых/софтовых команд. По итогу все может сильно отличаться от намеченного (и, скорее всего, так и будет), но без ТЗ как стартовой точки, не обойтись.
Понятно, что если проект типовой, из разряда “делали такое сто раз”, то расписывать все нет смысла. Но вот если клиент пришел с супер идеей (“хочу, чтоб девайс плавал, летал и крестиком вышивал”), то уж тут никак без ТЗ.
Абсолютно согласен – статистика неполная и многого не учитывает. Увы, на данный момент другой нет. Будем надеяться, что в скором времени нам будет доступна более полная информация.
Как правило, критерии оценки уже прописаны в техническом задании. Кроме того, если заказчик не является специалистом, он будет, скорее, смотреть на соответствие изделия функциональным требованиям. Специалист же еще на стадии согласования проекта пропишет технические характеристики, которым должно соответствовать устройство. Они и будут критерием оценки.
Так или иначе, все это должно оговариваться еще до подписания контракта, а значит, ответственность лежит на нас. Если мы наобещали заказчику с три короба, но не справились, вина на нас. Если же изначально неясно, можно ли сделать устройство или сделать его таким, как хочет клиент, то давать какие-то гарантии себе дороже.
В таких случаях мы настаиваем на проведении исследовательского этапа. И уже на основании результатов исследования мы можем либо дать гарантии, что концепция реализуема, либо убедить заказчика, что концепция нуждается в изменениях, либо отказаться от проекта как от слишком рискованного.
А вообще, вы подсказали любопытную тему. Возможно, стоит написать об этом отдельный материал. Спасибо :)
Если то или иное направление сложное, то специализирующихся на нем компаний будет меньше по сравнению с другими направлениями, что и отражается на графике.
Вообще, со статистикой по рынку контрактной разработки есть определенные проблемы. До недавнего времени цифр по объему рынка, специализиации компаний, средней выручке почти не было. В статье приведены данные из материалов конференции “Контрактная разработка электроники 2022”. Автор доклада приводит именно такую статистику.
Лет так десять назад делал ремонт в квартире. Договорился с бригадой делать именно по этапам. После разводки проводки пришел проверить. Посмотрел, померял и понял, что розетка под телевизор в гостиной окажется закрыта шкафом. Немного поругались, но переделали. Если бы я решил принять работы только в конце ремонта, пришлось бы снимать обои и штробить по новой. Да, конечно, в суде я был бы прав, но ремонт не сделан, денег нет, суды тянутся. Такая себе альтернатива.
Или вот несколько раз приходилось отдавать авто на ремонт арок и порогов, плюс несколько кап. ремонтов двигателей. Сроки исполнения и результат были очень разные. Пару раз приходилось ждать прям долго. Один раз сделали быстро (пороги). Как выяснилось через пару лет, сделали сравнительно плохо, найти исполнителя я уже не смог.
За 3-4 года до этого другие ребята делали арки пару месяцев. Арки продержались дольше порогов. Плохо затянутый болт на шкиве двигателя обнаружили спустя 3 года после “капиталки”, когда ремни внезапно слетели, а посторонний звук был сразу, но его списали на некачественный гидрокомпенсатор, который я им привез, а не они сами купили.
Если смотреть на конечный результат, то он сравнительно одинаковый. Мелкие косяки поправят сразу и без проблем. Большая часть проблем будет потом.
Так вот, жизненные выводы - проверять как можно чаще, что делают, а не то с каким умным видом рассказывают. Если не хотят показывать, то либо ничего не делали, либо сделали то, что надо скрыть.
Возвращаясь к проектам по электронике. Если заказчик настаивает на фиксированной оплате в конце проекта и не хочет проверять/принимать этапы, то это его право. Но стоимость такого проекта будет эдак в 1,5-3 раза выше, чем могла бы быть. Именно потому, что все риски берет на себя исполнитель. И сроки там будут заметно больше, чем могли бы быть. Так исполнитель гарантирует для себя, что проект будет сделан и его примут, даже если возникнут какие-то непредвиденные трудности.
Большая часть наших заказчиков технически компетентна в разработке электроники, но есть и заказчики из других отраслей. С первыми работать легче, но я бы не сказал, что вторым нельзя обращаться за контрактной разработкой. Иногда вторая категория заказчиков действительно использует дополнительных консультантов для аудита проекта.
Если рассматривать сотрудничество заказчик-исполнитель с точки зрения, что кто-то будет лукавить, то любая модель оплаты может быть использована для махинаций. )) В статье я рассмотрел вопрос только с позиции Win-Win. В отдельной статье могу написать несколько кейсов, когда заказчики нам под тем или иным предлогом отказывались платить, хитрили, спекулировали формулировками из документов, пытались заставить доделывать функционал, которого вообще не фигурировало в ТЗ, обосновывая свою позицию формулировкой “нувыжеспециалисты”. ))
Если проект не фиксированный и заказчик сам точно не знает, каким должен быть продукт, то, конечно, на нем значительная доля ответственности. Подрядчик обязан оценить пожелания заказчика и предупредить о возможных сложностях в плане стоимости, сроков разработки, реализуемости и т.д. Но последнее слово за клиентом. Модель также подразумевает, что результат этапа или нескольких этапов можно проверить и оценить за короткий промежуток времени.
Если видение продукта четкое, то лучше подходит фиксированная оплата. Тогда все риски берет на себя исполнитель. И да, в договоре должны быть четко прописаны критерии приемки продукта. Разбивку проектов на этапы придумали еще задолго до нас (ГОСТ Р 53736-2009 - один из самых свежих). В некоторых случаях заказчики сами просят это сделать. Проконтролировать исполнителя и поправить недочеты всегда проще по ходу разработки, нежели в самом конце требовать возврат денег за отсутствие требуемых результатов. Макеты и прототипы как раз и делаются для проверки гипотез и принятых проектных решений. На мой взгляд (уже как потребителя/заказчика), стоит как раз опасаться ситуации, когда вам отказывают в промежуточных демонстрациях и этапах.
спасибо)
Спасибо!
Спасибо!
Это довольно интимный вопрос ))
Когда нужна узкая экспертиза, возможны варианты. Если такого опыта нет, честно говорим заказчику: мы не умеем, но можем попробовать и будем учиться за ваш счет. Если клиенту норм, то работаем так. Аутсорс – тоже вариант. Мы на постоянке работаем с проверенными спецами, с ними проблем не возникало.
По поводу компонентов, когда имеем дело с незнакомыми, то паспортным характеристикам не доверяем. Уже обжигались с этим, и не раз. Вопрос про тестирование очень объемный. Смогу ответить только частично. Моделированием активно пользуемся, разброс параметров при этом тоже учитываем. Также проводим испытания опытных образцов. Разрабатываем методики и стенды для тестирования при производстве как отдельных модулей в составе устройств, так и устройств целиком.
Спасибо большое за внимательность. Поправили.
Во втором эпизоде про SCADA общаемся со Станиславом Павловским из Атомик сфот. Хотите посмотреть?
Можем расшифровку подкаста добавить
Вероятно, да. Рост отрасли подразумевает приход в нее дополнительных трудовых ресурсов. Государство активно продвигает обучение IT специалистов и инженеров, но насколько эти усилия успешны – это другой вопрос. Мне кажется, интерес молодежи к высшему образованию сейчас не слишком высок.
На данный момент был разработан рабочий прототип для серийного производства. Мы использовали nRF вместе с ESP32, так как для устройства требовалась одновременная работа WiFi и BLE. Также в перспективе планируется реализация поддержки ZigBee и OpenThread, для чего также проще использовать отдельный микроконтроллер nRF.
Грамотно составленное ТЗ абсолютно не противоречит Agile подходу. Во всем нужен баланс. Да, работающий продукт важнее скрупулезно подготовленной документации, но, согласитесь, вы не можете работать над масштабным проектом, не имея вообще никакого плана.
Здесь речь идет о ТЗ не как о пошаговой инструкции, а как о некой канве проекта, которая одинаково важна и разработчикам, и заказчику.
Клиент видит, за что он платит деньги, когда и на каком этапе будут промежуточные результаты. Плюс здесь же он документирует свои видения и пожелания.
Разработчикам нужно ТЗ, чтобы собрать воедино как видение заказчика, так и соображения своих хардовых/софтовых команд. По итогу все может сильно отличаться от намеченного (и, скорее всего, так и будет), но без ТЗ как стартовой точки, не обойтись.
Понятно, что если проект типовой, из разряда “делали такое сто раз”, то расписывать все нет смысла. Но вот если клиент пришел с супер идеей (“хочу, чтоб девайс плавал, летал и крестиком вышивал”), то уж тут никак без ТЗ.
Абсолютно согласен – статистика неполная и многого не учитывает. Увы, на данный момент другой нет. Будем надеяться, что в скором времени нам будет доступна более полная информация.
Как правило, критерии оценки уже прописаны в техническом задании. Кроме того, если заказчик не является специалистом, он будет, скорее, смотреть на соответствие изделия функциональным требованиям. Специалист же еще на стадии согласования проекта пропишет технические характеристики, которым должно соответствовать устройство. Они и будут критерием оценки.
Так или иначе, все это должно оговариваться еще до подписания контракта, а значит, ответственность лежит на нас. Если мы наобещали заказчику с три короба, но не справились, вина на нас. Если же изначально неясно, можно ли сделать устройство или сделать его таким, как хочет клиент, то давать какие-то гарантии себе дороже.
В таких случаях мы настаиваем на проведении исследовательского этапа. И уже на основании результатов исследования мы можем либо дать гарантии, что концепция реализуема, либо убедить заказчика, что концепция нуждается в изменениях, либо отказаться от проекта как от слишком рискованного.
А вообще, вы подсказали любопытную тему. Возможно, стоит написать об этом отдельный материал. Спасибо :)
Если то или иное направление сложное, то специализирующихся на нем компаний будет меньше по сравнению с другими направлениями, что и отражается на графике.
Вообще, со статистикой по рынку контрактной разработки есть определенные проблемы. До недавнего времени цифр по объему рынка, специализиации компаний, средней выручке почти не было. В статье приведены данные из материалов конференции “Контрактная разработка электроники 2022”. Автор доклада приводит именно такую статистику.