Заключение | Дизайн и искусство

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

Но его главная задача определяется высшей целью общественного производства — наиболее полного удовлетворения материальных и культурных потребностей людей. В условиях построения развитого социалистического общества перед дизайном и технической эстетикой как его теорией встают практические вопросы: соотнесения социалистического образа жизни и материальной среды, в которой она протекает, реального улучшения труда и быта людей, формирования разумных потребностей и высокого вкуса, без чего нельзя достичь подлинной цивилизованности. Это означает, что дизайнеры-практики и все, кто входит в дизайнерские проектные коллективы, концентрируют свое внимание на всестороннем повышении качества промышленной продукции и окружающей среды, совершенствовании ассортимента товаров и необходимой для их выпуска производственной базы. Этому способствует единая государственная система дизайна, созданная в нашей стране в начале 60-х годов с головным институтом — ВНИИТЭ: Государство высоко подняло престиж дизайнеров и дало им большие права. Они участвуют в составлении крупных народнохозяйственных программ, в государственной аттестации качества промышленной продукции. Без их положительной оценки не может быть присужден Государственный знак качества.

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

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

Сегодня дизайн более раскован в художественном, стилистическом плане. Он объединяет экспериментальное футурологическое проектирование, работу над отдельными конкретными изделиями, долгосрочные дизайн-программы. В теории дизайна и в исследованиях но технической эстетике в центре внимания стоит выявление творческих, внутренних ресурсов дизайна как профессии, его интеграции с другими видами проектно-творческой деятельности, изменения традиционных методов проектирования в связи с массовым переходом к укрупненным задачам и усложнением структуры проектируемых объектов.

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

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

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

Выводы за 5 лет продуктовой работы дизайнером — Дизайн на vc.ru

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

3825 просмотров

1. В продукте платят значительно больше
Начнем с самого важного. Это ни для кого не секрет, ведь чаще всего в студиях зарплаты формируются за счет крупных B2B (студия-бизнес) клиентов. А в этом сегменте мало платящих клиентов, относительно рынка B2C. В продуктовых же компаниях клиенты чаще всего это обычные люди, иногда не очень обычные, но их значительно больше, есть прогнозируемый горизонт, соответственно меньше рисков платить высокую зарплату. Про ИТ гигантов я вообще молчу, у них уже система из прибыльных продуктов, которые друг друга могут страховать.

2. В большинстве компаний не занимаются всякими JTBD, ux research, да даже до кастдева доходит редко.

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

3. Дружите с каждым членом команды и после увольнения.
Нетворк сила. Мой канал в телеграме дает мне 90% связей, могу за 10 минут найти любого человека, в услугах которого я нуждаюсь. Если у вас нет канала, то собирайте коллег в адресную книгу, они вам обязательно пригодятся.

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

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

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

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

7. Можно вообще не общаться с разработкой, а можно каждый день с утра до вечера сидеть на созвонах.
Решать вам, тут важны только процессы и ваше желание. Обычно 1-2 коммуникаций в неделю хватает для того, чтобы закрыть все вопросы.

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

9. Дизайн система не всегда нужна.
Даже компоненты. Это наблюдение, которое было прошито тонкой нитью через все места моей работы. Решение о дизайн системе принимает чаще всего дизайнер. Если не хотите — не надо. Но учтите, что при масштабировании макетов, а не продукта, количество разношерстных элементов могут замедлить вашу работу и вызвать у разработки легкий приступ бешенства, так как ничего не понятно и все пляшет. Лучше всего добавлять компоненты по чуть чуть и там, где уверены.

10. Если не любите цифры и математику, то будет сложнее.

Data driven подход даже в работе дизайнера дает вам железные аргументы ваших решений. Всегда приятно сказать: я переделал этот экран, потому что увидел что на нем churn rate 50%, а не потому что он не подходит под нашу стилистику

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

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

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

Элементы управления дизайном | FDA

• Цели инспекции
• Блок-схема принятия решений
• Рассказ

Средства контроля проекта

Цели проверки

1. Выберите один проект дизайна.

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

2. Для выбранного проекта убедитесь, что процедуры контроля проектирования, отвечающие требованиям Раздела 820.30 регламента, определены и задокументированы.
3. Просмотрите план проектирования для выбранного проекта, чтобы понять структуру действий по проектированию и разработке, включая назначенные обязанности и интерфейсы.

Примечание. Оцените проведение фирмой анализа рисков, проводя оценку системы контроля проектирования фирмы.

4. Подтвердите, что входные данные для проекта были установлены.
5. Убедитесь, что проектные выходные данные, необходимые для правильного функционирования устройства, определены.
6. Подтвердите, что критерии приемки были установлены до выполнения действий по проверке и валидации.
7. Определите, подтвердила ли проверка проекта, что выходные данные проекта соответствуют входным требованиям проекта.
8. Подтвердите, что данные проверки проекта показывают, что утвержденный проект соответствует заранее определенным потребностям пользователя и предполагаемому использованию.
9. Подтвердите, что завершенная проверка проекта не оставила неустраненных несоответствий.
10. Если устройство содержит программное обеспечение, убедитесь, что оно проверено.
11. Подтвердите выполнение анализа рисков.
12. Определите, была ли проверка конструкции выполнена с использованием первоначальных серийных устройств или их эквивалентов.
13. Подтверждение того, что изменения контролировались, включая проверку или, при необходимости, проверку.
14. Определите, проводились ли обзоры проекта.
15. Определите, правильно ли был передан дизайн.

Элементы управления проектированием

Описание

Назначение/важность

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

1. Выберите один дизайн-проект.

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

Требования к контролю конструкции раздела 820.30 регламента применяются к конструкции медицинских устройств класса II и III, а также к избранной группе устройств класса I. Регулирование очень гибкое в области контроля конструкции. Тип системы управления проектированием и точные детали реализации оставлены на усмотрение каждой фирмы в зависимости от сложности и рисков, связанных с их устройствами.

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

Не проверяйте устройство, на которое распространяются требования контроля конструкции, чтобы определить, была ли конструкция подходящей, безопасной и эффективной. Это запрещено в соответствии с разделом 520(f)(1)(A) Закона. Однако, если на основе информации, полученной в ходе оценки средств контроля конструкции фирмы, выясняется, что устройство небезопасно или неэффективно, сообщите об этих выводах в EIR.

Требование проверки программного обеспечения включено в Раздел 820.30(g) Проверка проекта. Однако, если выбранный проект включает в себя устройство, содержащее программное обеспечение, рассмотрите возможность проверки валидации программного обеспечения при проведении оценки системы контроля проектирования фирмы.

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

2. Для выбранного проектного проекта убедитесь, что процедуры контроля проектирования, отвечающие требованиям Раздела 820.30 регламента, определены и задокументированы.

Фирмы, в том числе малые фирмы и те, кто разрабатывает простые устройства, на которые распространяется Раздел 820.30 регламента, должны определить и задокументировать в письменной или электронной форме процедуры, отвечающие требованиям регламента. Эти процедуры служат для установления структуры системы контроля проектирования фирмы.

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

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

Чтобы определить, были ли внедрены процедуры контроля проектирования фирмы, используйте выбранный дизайн-проект для проверки процедур фирмы и достижения следующих целей.

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

Примечание. Оцените проведение фирмой анализа рисков, проводя оценку системы контроля проектирования фирмы.

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

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

Хотя требование о проведении анализа рисков содержится в Разделе 820.30(g) «Проверка проекта», фирма не должна ждать, пока они проведут проверку проекта, чтобы начать анализ риска. Анализ рисков следует рассматривать в плане проектирования, а риски следует учитывать на протяжении всего процесса проектирования. Анализ рисков должен быть завершен при проверке проекта.

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

Общие инструменты, используемые фирмами для проведения анализа рисков, включают анализ дерева отказов (FTA) и анализ видов и последствий отказов (FMEA).

4. Подтвердите, что входные данные проекта были установлены.

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

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

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

Важными взаимосвязями, которые следует учитывать, являются разделы 820. 80 «Приемка, приемка в процессе и готовое устройство», 820.120 «Маркировка устройства» и 820.130 «Упаковка устройства».

Дизайн-проекты могут производить большой объем записей. Не все записи, созданные в ходе проекта, являются выходными данными проекта, и поэтому их не нужно сохранять в файле истории проекта. Необходимо сохранить только утвержденные результаты.

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

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

6. Подтвердить, что критерии приемлемости были установлены до выполнения действий по проверке и валидации.

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

7. Определите, подтвердила ли проверка проекта, что выходные данные проекта соответствуют входным требованиям проекта.

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

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

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

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

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

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

9. Подтвердите, что завершенная проверка проекта не оставила неустраненных несоответствий.

Проверка конструкции может выявить несоответствия между техническими характеристиками устройства (выходными данными) и потребностями пользователя или предполагаемым использованием (ями) устройства. Все несоответствия должны быть рассмотрены и разрешены фирмой. Это может быть достигнуто за счет изменения выходных данных проекта или изменения потребностей пользователя или предполагаемого использования.

10. Если устройство содержит программное обеспечение, убедитесь, что оно проверено.

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

11. Подтвердите выполнение анализа рисков.

Как отмечалось ранее, анализ рисков должен быть выполнен при проверке конструкции.

12. Определите, выполнялась ли проверка конструкции с использованием первоначальных серийных устройств или их эквивалентов.

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

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

13. Подтвердите, что изменения контролировались, включая проверку или, при необходимости, проверку.

Управление изменениями не является новым требованием. Раздел 820.100 (a) (2) правил GMP 1978 года требовал одобрения изменений, внесенных в спецификации после окончательной передачи проекта (постпроизводственные изменения). Постановление о системе качества разъяснило и переместило требование в Раздел 820. 30(i). Он расширил требование, чтобы включить изменения, внесенные в процессе проектирования (предварительные изменения).

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

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

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

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

Раздел управления изменениями конструкции связан с Разделом 820.70(b) «Изменения производства и процесса» и дублирует его.

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

Просмотр изменения дизайна перед производством и после производства.

14. Определите, проводились ли анализы проекта.

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

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

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

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

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

15. Определите, правильно ли был перенесен дизайн.

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

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

Искусство определения входных и выходных данных для проектирования

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

Если продукт, представленный на рынке, имеет проблемы, есть вероятность, что проблема может быть прослежена до исходных данных, определенных во время разработки продукта.

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

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

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

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

 

Исходные данные для проектирования. Терминология

Во-первых, позвольте мне потратить несколько минут на описание входных данных для проектирования.

Вот официальные правила FDA по контролю проектирования, относящиеся к проектным данным, как указано в Части 820.30(c):

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

ISO 13485:2016 также охватывает эту тему в разделе 7.3.3 Исходные данные для проектирования и разработки:

Должны быть определены исходные данные, относящиеся к требованиям к продукции, и должны вестись записи. Эти входные данные должны включать:

a) функциональные требования, требования к производительности и безопасности в соответствии с предполагаемым использованием,
b) применимые законодательные и нормативные требования,
c) где применимо, информацию, полученную из предыдущих аналогичных дизайн,
d) другие требования, необходимые для проектирования и разработки, и
e) результаты управления рисками

Эти входные данные должны быть рассмотрены и утверждены.

Требования должны быть полными, однозначными и не противоречащими друг другу.

Просто прочитав, что FDA и ISO должны сказать о входных данных для проектирования, вы увидите, что существует несколько взаимозаменяемых терминов, когда речь идет о входных данных для проектирования:

• Проектные данные
• Требования к конструкции
• Входные требования к проекту
• Требования к дизайну и разработке
• Требования к продукту

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

 

Исходные данные для проектирования — создание фундамента

Разработка изделий медицинского назначения должна представлять собой целостный процесс, который строится по мере продвижения проекта.

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

Задумайтесь об этом на мгновение. В 12-месячном проекте определение входных данных для проектирования может занять более 3 месяцев.

 

Искусство написания входных данных для дизайна

Написание хороших входных данных для дизайна, на мой взгляд, во многом является искусством.

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

Ваши цели при определении исходных данных для проектирования включают:

• Соблюдение всех функциональных требований, требований к производительности, безопасности и нормативных требований.
• Основываясь на потребностях пользователя и предполагаемом использовании.
• Убедитесь, что входные данные проекта ясны и объективны.
• Сформулируйте исходные данные таким образом, чтобы вы могли их подтвердить/опровергнуть.

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

 

Откуда поступают данные для проектирования?

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

Вам также следует рассмотреть всевозможные другие источники, которые помогут вам определить исходные данные для проектирования:

• Отраслевые стандарты
• Правила
• Предыдущие проекты/продукты
• Продукция конкурентов
• Конечные пользователи
• Прототипы

Это не полный список, но он дает представление о том, о чем идет речь.

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

Позже вам нужно будет доказать, что ваши проектные данные были учтены во время проверки проекта.

При вводе проектных данных всегда следует учитывать возможность проверки проекта. Это означает, что вы должны документировать свои входные данные таким образом, чтобы вы могли объективно доказать, что они были выполнены.

 

Объяснение выходных данных проекта

Выходные данные проекта часто понимают неправильно, и это может затруднить процесс их описания. Позвольте мне попытаться немного прояснить это, поделившись тем, что FDA 21 CFR Part 820.30 (d) и ISO 13485: 2016 7.3.4 говорят о результатах проектирования.

FDA 21 CFR Часть 820.30(d) гласит:

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

Вот руководство ISO 13485:2016 7.3.4 по результатам проектирования и разработки:

Результаты проектирования и разработки должны:

77 б) предоставлять соответствующую информацию о закупках, производстве и предоставлении услуг
c) содержать или ссылаться на критерии приемлемости продукта и
d) указывать характеристики продукта, необходимые для его безопасного и надлежащего использования.

Должны вестись записи результатов проектирования и разработки (см. 4.2.5).

ПРИМЕЧАНИЕ. Записи о результатах проектирования и разработки могут включать спецификации, производственные процедуры, инженерные чертежи и журналы инженерных или исследовательских работ.

 

Что такое выходные данные проекта?

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

Думай об этом так. Если бы вам поручили собрать медицинское устройство с нуля, какая документация вам понадобилась бы для этого? Вся эта документация, которая вам понадобится, — проектные результаты.

Выходные данные проекта, установленные во время разработки продукта, становятся основой основной записи устройства (DMR) при производстве.

 

DEVICE MASTER RECORD AND DESIGN OUTPUTS

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

Согласно FDA 21 CFR, часть 820.181:

Каждый производитель должен вести основные записи устройств (DMR). Каждый производитель должен обеспечить подготовку и утверждение каждого DMR в соответствии с 820.40.

Таким образом, DMR является примером требуемого результата проектирования. Оба, конечно, очень тесно связаны. Информация в вашем DMR будет использоваться для оценки вашего устройства на этапе проверки конструкции.

 

«Адекватная оценка» проектных результатов?

Выходные данные проекта должны содержать и/или ссылаться на «критерии приемлемости». Думайте о критериях приемлемости как о своего рода допуске. Для адекватной оценки результатов проектирования необходима верификация проекта. И эта оценка сравнивает результаты проектирования с входными данными проектирования.

Тесты НЕ являются результатами проектирования.

Создание твердых, объективных проектных данных является ключевым моментом. Хорошие исходные данные для проектирования облегчают создание результатов проектирования.

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

 

ЗАКЛЮЧИТЕЛЬНЫЕ МЫСЛИ

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

Система управления качеством медицинских устройств Greenlight Guru была специально разработана для обеспечения четкого и прослеживаемого документирования входных и выходных данных проекта.