Комментарии 9
Было бы очень здорово привести примеры конкретных требований для «классических» типов производства влияющих на процесс разработки. Или рассказать о своих граблях.
Нельзя закладывать в устройства позиции не имеющие аналогов или уже не закупленные в нужном количестве(в рамках серийного производства) Иногда бывает что достать 5-100 шт. элемента легко, а когда дело идет о серии 1000 шт. и более сроки поставки становятся от 8 недель…
Из опыта скажу, как только разработчик ПП сделал BOM (перечень элементов) — то по этому перечню обязательно нужно проверить возможность закупки на серию, и за частую после таковой проверки в ПП вноситься изменения — возможность установки 2 типов элементов (SMD / DIP элементы) или 2 типоразмеров. (к примеру конденсаторы)
Из опыта скажу, как только разработчик ПП сделал BOM (перечень элементов) — то по этому перечню обязательно нужно проверить возможность закупки на серию, и за частую после таковой проверки в ПП вноситься изменения — возможность установки 2 типов элементов (SMD / DIP элементы) или 2 типоразмеров. (к примеру конденсаторы)
Я не очень понимаю, что такое «классический» тип производства. А вот о граблях – это пожалуйста.
1. Самая первая моя разработка. Я не сделал отступ меди от контура платы. Даже не думал, что это надо делать. На производстве контур фрезеровался. При проходе фрезы по контуру образовалась «медная шуба». И даже в нескольких местах образовались КЗ. Вот так незнание технологий производства привело к не работоспособной плате. Кстати, такие глупые ошибки встречаются постоянно. И, как это ни странно, не только у начинающих разработчиков.
2. Более сложный пример. Разрабатывали сложное устройство. В частности корпус (речь пойдет о нем). По дизайну выходные разъемы устройства располагались по трем сторонам. К моменту разработки уже был накоплен достаточно большой опыт и была сильная команда разработчиков. Когда печатная плата и корпус были спроектированы, мы стали проводить моделирование на собираемость (компьютерное). По результатам редактировали модели деталей корпуса, пока на модели все стало «хорошо собираться». Получив хорошие результаты моделирования, мы сразу отдали устройство на производство. Выпустили пресс-форму (корпус должен был отливаться). Получили готовые детали. И при «живой сборке» не смогли ничего сделать. Там мешало какое-то маленькое ребро жесткости. Этого не заметили на моделировании. Пришлось дорабатывать пресс-форму, избавляться от брака – а ведь это очень дорого. Вот если бы до этапа производства мы отдали наши модели на выращивание и проверили все «вживую», то избежали бы потерь как по времени, так и финансовых.
1. Самая первая моя разработка. Я не сделал отступ меди от контура платы. Даже не думал, что это надо делать. На производстве контур фрезеровался. При проходе фрезы по контуру образовалась «медная шуба». И даже в нескольких местах образовались КЗ. Вот так незнание технологий производства привело к не работоспособной плате. Кстати, такие глупые ошибки встречаются постоянно. И, как это ни странно, не только у начинающих разработчиков.
2. Более сложный пример. Разрабатывали сложное устройство. В частности корпус (речь пойдет о нем). По дизайну выходные разъемы устройства располагались по трем сторонам. К моменту разработки уже был накоплен достаточно большой опыт и была сильная команда разработчиков. Когда печатная плата и корпус были спроектированы, мы стали проводить моделирование на собираемость (компьютерное). По результатам редактировали модели деталей корпуса, пока на модели все стало «хорошо собираться». Получив хорошие результаты моделирования, мы сразу отдали устройство на производство. Выпустили пресс-форму (корпус должен был отливаться). Получили готовые детали. И при «живой сборке» не смогли ничего сделать. Там мешало какое-то маленькое ребро жесткости. Этого не заметили на моделировании. Пришлось дорабатывать пресс-форму, избавляться от брака – а ведь это очень дорого. Вот если бы до этапа производства мы отдали наши модели на выращивание и проверили все «вживую», то избежали бы потерь как по времени, так и финансовых.
Выглядит как текст для робота. Ключевых слов много, смысла нет.
Уважаемый Amarao, предположу, что Вы ошиблись веткой или далеки от темы разработки и последующего производства, раз не увидели смысла. Возможно, Вы эксперт в отрасли, в таком случае, буду рад, если поделитесь своей практикой.
На самом деле, для тех, кто работает в теме разработки и последующего производства — сабж капитанский :) Подойдет для чтения свежеиспеченным руководителям проектов, хотя тут опять же очень мало конкретики(такой, как в вашем комменте выше). Обычно ведущий инженер разработки всегда держит в голове мысль «надо ничего не забыть и предусмотреть все, что возможно», однако на практике о чем-то он не знает, о чем-то забывает в запаре. И хотя в конечном итоге все фиксится перед постановкой на серию(если сроки не поджимают), но сроки разработки увеличиваются.
А еще очень важна вовлеченность сотрудников в процесс. Например, топологу ПП зачастую «влом» добиваться идеальной разводки — формально все ок, ну и пошел домой в 18.00. Тогда ведущий садится и думает, что и как разводить, используя затем тополога как интерфейс к cad'у. Аналогично и с моделированием — работник сделал, все ок. А проверять все равно ведущему. И у него голова будет болеть о всех недочетах, тогда как сотруднику условно — все равно. Ну допустил ошибку, с кем не бывает.
Ну а если кратко, то ваш пост можно заменить немножко подправленной вашей же фразой:
«Быстрое решение руководителем проекта всех возникающих в ходе проектирования вопросов — это один из основополагающих факторов, которые способствуют успешному завершению всего проекта.»
А еще очень важна вовлеченность сотрудников в процесс. Например, топологу ПП зачастую «влом» добиваться идеальной разводки — формально все ок, ну и пошел домой в 18.00. Тогда ведущий садится и думает, что и как разводить, используя затем тополога как интерфейс к cad'у. Аналогично и с моделированием — работник сделал, все ок. А проверять все равно ведущему. И у него голова будет болеть о всех недочетах, тогда как сотруднику условно — все равно. Ну допустил ошибку, с кем не бывает.
Ну а если кратко, то ваш пост можно заменить немножко подправленной вашей же фразой:
«Быстрое решение руководителем проекта всех возникающих в ходе проектирования вопросов — это один из основополагающих факторов, которые способствуют успешному завершению всего проекта.»
Я так понимаю, «капитанский» значит очевидный? В принципе любая тема, в которой разобрался – «капитанская» :). Вот только мне присылают на проверку много проектов, и на эти проекты «больно смотреть». И разработчики этих проектов совсем не начинающие, а очень даже опытные. Собственно стимулом для написания этой статьи стали 2 проекта, которые попали ко мне одновременно. Если вкратце: в одном из них был совершенно не оптимизированный BOM, во втором – какая-то невообразимо сложная структура ПП. Оба эти проекта мне принесли с вопросом: «Почему так дорого? И почему мы не можем это произвести?». Ну очевидно же…
Руководитель проекта – очень важная и ответственная работа, и область ответственности там намного шире, чем просто следить за разработчиками. Действительно, очень часто руководитель проекта, по сути, является разработчиком, а разработчики, как Вы удачно выразились, только интерфейсы к CAD’ам. И это, на мой взгляд, не совсем правильно. Намного лучше организовать процесс разработки так, чтоб каждый ее участник отвечал за свою часть работ.
Вопрос мотивации сотрудников – один из самых сложных и его надо решать. Я не видел, чтобы его «пристегивали» к принципам DFM. Разве что косвенно, при расчете себестоимости. Но идея интересная. Ведь качественно выполнить работу может только тот специалист, который хочет ее выполнить.
Про конкретику. Мне тоже очень хотелось бы получить универсальный набор правил. Выполнил все по пунктам – получил хорошее изделие. Но такого набора нет. И не может быть в принципе. Очень много переменных: разные задачи, разные инструменты, разные пути реализации, разное количество специалистов и т. д. Вопросов слишком много. Поэтому придумали принципы DFM. Принципы. Не правила!
Руководитель проекта – очень важная и ответственная работа, и область ответственности там намного шире, чем просто следить за разработчиками. Действительно, очень часто руководитель проекта, по сути, является разработчиком, а разработчики, как Вы удачно выразились, только интерфейсы к CAD’ам. И это, на мой взгляд, не совсем правильно. Намного лучше организовать процесс разработки так, чтоб каждый ее участник отвечал за свою часть работ.
Вопрос мотивации сотрудников – один из самых сложных и его надо решать. Я не видел, чтобы его «пристегивали» к принципам DFM. Разве что косвенно, при расчете себестоимости. Но идея интересная. Ведь качественно выполнить работу может только тот специалист, который хочет ее выполнить.
Про конкретику. Мне тоже очень хотелось бы получить универсальный набор правил. Выполнил все по пунктам – получил хорошее изделие. Но такого набора нет. И не может быть в принципе. Очень много переменных: разные задачи, разные инструменты, разные пути реализации, разное количество специалистов и т. д. Вопросов слишком много. Поэтому придумали принципы DFM. Принципы. Не правила!
DFM правила обычно используются при разработке топологии
интегральных схем. Выглядит это примерно так:
минимальное расстояние между проводниками равно, например, 40 нанометров,
рекомемендуемое расстояние — 60.
интегральных схем. Выглядит это примерно так:
минимальное расстояние между проводниками равно, например, 40 нанометров,
рекомемендуемое расстояние — 60.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как разработать электронное устройство по принципам DFM