6 Выполнение человеко-ориентированного проекта

6.1 Общая информация

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

  1. понимание и определение условий использования (см. 6.2);
  2. определение требований пользователей (см. 6.3);
  3. разработка проектных решений (см. 6.4);
  4. оценка проекта (см. 6.5).

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

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

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

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

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

Рисунок 1 — Взаимосвязь этапов человеко-ориентированного проектирования

Цикл HCD

6.2 Понимание и определение контекста использования

6.2.1 Общая информация

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

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

Примечание 1 — Для описания условий использования может быть использовано описание существующих или планируемых условий для использования.

Примечание 2 — В ISO/TR 16982 приведена информация о методах сбора и передачи информации об условиях использования.

6.2.2 Определение контекста использования

Контекст использования должен включать в себя описание:

  1. a) Пользователей и других заинтересованных сторон. Может существовать несколько различных групп пользователей, а также других заинтересованных сторон, чьи нужды должны быть учтены. Такие группы и заинтересованные стороны должны быть определены, а их связь с процессом проектирования описана с позиции ключевых целей и ограничений.
  2. b) Характеристики пользователей или групп пользователей. Важные характеристики пользователей должны быть определены. Они могут включать знания, навыки, опыт, образование, подготовку, физические характеристики, привычки, предпочтения и возможности пользователей. При необходимости должны быть определены характеристики различных групп пользователей, например, пользователей с разными уровнями опыта или физических возможностей. В целях обеспечения общедоступности продукта, системы или услуги должны быть разработаны таким образом, чтобы их могли использовать люди из предполагаемой совокупности пользователей с самым широким диапазоном возможностей. Во многих странах этого требует закон.

Примечание — В ISO/IEC/TR 29138-1 установлен диапазон потребностей пользователей, который необходимо учитывать для обеспечения доступности изделий для людей с ограниченными возможностями.

  1. c) Цели и задачи пользователей. Цели пользователей и общие цели системы должны быть определены. Характеристики задач, которые могут повлиять на юзабилити и общедоступность системы, должны быть описаны (например, наиболее распространенный способ выполнения пользователями задачи, частота и продолжительность работы, взаимосвязь параллельно выполняемых действий). Если существуют неблагоприятные последствия для здоровья и безопасности (например, чрезмерная рабочая нагрузка), или риск неверного выполнения задачи (например, совершена ошибка при покупке), это также должно быть определено. Описание задач не должно ограничиваться описанием функций или свойств продукта или системы.
  2. d) Среда(ы) использования системы. Техническая среда, включая аппаратное обеспечение, программное обеспечение и материалы, должна быть определена. Кроме того, должны быть описаны важные характеристики физической, социальной и культурной среды. Физические факторы включают температурные условия, освещение, пространственное размещение и меблировку и т.п. Социальные и культурные аспекты среды включают организационную структуру, принятые подходы и порядок выполнения работы.

6.2.3 Существенные детали для поддержки проектирования

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

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

6.2.4 Установленный контекст использования

Контекст использования системы, определенный для разработки проекта (т.е. условия, в которых система будет использоваться), должен быть указан в спецификации требований пользователей. Дополнительная информация о контексте использования приведена в ИСО 9241-11, а информация о контексте использования изделий повседневного использования приведена в ИСО 20282-1.

6.3 Определение требований пользователей

6.3.1 Общие положения

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

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

6.3.2 Определение потребностей пользователей и других заинтересованных сторон

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

6.3.3 Описание требований пользователей

Описание требований пользователей должно включать:

  1. a) предполагаемый контекст использования;
  2. b) требования, полученные на основе потребностей пользователей и условий использования — например, может существовать требование к уличному использованию продукта;
  3. c) требования, установленные с учетом эргономических требований, требований пользовательских интерфейсов, стандартов и т.п. (например, требования к доступности, приведенные в ИСО 9241-20 и ИСО 9241-171);
  4. d) требования и цели юзабилити, включающие критерии производительности и удовлетворенности пользователя в определенных условиях использования — например, целью может быть успешное переключение входящего звонка на голосовую почту 90% пользователей, или эстетичный дизайн интернет-страницы для получения необходимой оценки удовлетворенности пользователя;
  5. e) требования, установленные на основе организационных требований, влияющих на пользователя — например, система центра обработки звонков может требовать, чтобы ответ на звонки производился в пределах определенного периода времени.

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

Требования пользователей разрабатывают вместе с общими требованиями к интерактивной системе.

6.3.4 Устранение противоречий в требованиях пользователей

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

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

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

6.3.5 Требования к спецификации требований пользователей

Спецификация требований пользователей должна быть:

  1. составлена с учетом возможности проведения испытаний на более поздних стадиях проектирования;
  2. верифицирована важными заинтересованными сторонами;
  3. внутренне последовательной;
  4. обновляемой по мере необходимости в процессе проектирования.

6.4 Разработка дизайн-решений

6.4.1 Общие положения

Дизайн-решения существенно зависят от опыта пользователя. Человеко-ориентированное проектирование позволяет учесть опыт пользователя в процессе проектирования (см. 4.6).

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

Создание дизайн-решений может включать следующую деятельность:

  1. разработку задач пользователя, взаимодействия пользователя и системы и пользовательского интерфейса с учетом требований и опыта пользователя;
  2. детализацию дизайн-решений (например, с помощью использования сценариев, моделирования, прототипов или макетов);
  3. внесение изменений в дизайн-решения на основе оценок и отзывов (информация об оценке проекта приведена в 6.5);
  4. передачу дизайн-решений ответственным за их осуществление.

6.4.2 Разработка пользовательских задач взаимодействия человек-система и пользовательского интерфейса с учетом требований и опыта пользователей

6.4.2.1 Принципы проектирования

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

При разработке интерактивных систем необходимо учитывать следующие принципы (по ИСО 9241-110):

  1. пригодность для выполнения задачи;
  2. информативность;
  3. соответствие ожиданиям пользователей;
  4. пригодность для обучения;
  5. управляемость;
  6. устойчивость к ошибкам;
  7. пригодность для индивидуализации.

Примечание 1 — «Информативность» [b)] означает, что пользователь понимает, на каком этапе диалога он находится, какие действия и каким образом он может предпринять.

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

6.4.2.2 Проектирование задач и взаимодействия пользователя с системой

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

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

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

Проектирование взаимодействия должно включать:

  1. принятие высокоуровневых решений (например, концепции проекта, определения важных целей);
  2. определение задач и подзадач;
  3. распределение задач и подзадач между пользователем и другими частями системы;
  4. определение объектов взаимодействия, необходимых для выполнения задач;
  5. определение и выбор способов организации диалога (см. ИСО 9241-12, ИСО 9241-13, ИСО 9241-14, ИСО 9241-15, ИСО 9241-16 и ИСО 9241-17);
  6. разработку последовательности и времени (динамики) взаимодействия;
  7. разработку информационной архитектуры пользовательского интерфейса интерактивной системы для обеспечения эффективного доступа к объектам взаимодействия.

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

6.4.2.3 Проектирование пользовательского интерфейса

В области проектирования пользовательского интерфейса существует большое количество информации, стандартов и руководств, которые должны быть использованы при разработке аппаратных и программных элементов пользовательского интерфейса. В стандартах серии ИСО 9241 установлены требования, относящиеся к дисплеям, устройствам ввода, принципам диалога, меню, представлению информации, руководству пользователя. Могут быть использованы и другие руководства по разработке пользовательского интерфейса и обеспечению доступности системы. У многих организаций существуют внутренние руководства по стилю пользовательского интерфейса, необходимой информации о продукте, предполагаемых пользователях и других аспектах условий использования, таких как ожидания пользователей (см. ИСО 1503) и стереотипы их поведения. Стандарты серии ИСО 9241 приведены в приложении А.

6.4.3 Детализация дизайн-решений

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

В результате:

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

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

Большие затраты времени или средств на создание детализированного прототипа могут быть неоправданными и привести к нежеланию вносить изменения в дизайн.

6.4.4 Изменение дизайн-решений на основе оценок и отзывов

Отзывы и оценки должны быть использованы для изменения и совершенствования системы (см. 6.5).

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

Затраты и положительные стороны предлагаемых изменений следует оценить и учесть при принятии и объяснении решений об изменениях.

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

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

План проекта должен отводить достаточно времени для внесения изменений на основе отзывов.

6.4.5 Передача дизайн-решений ответственным за их реализацию

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

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

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

6.5 Оценка проекта

6.5.1 Общие положения

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

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

Оценка дизайна пользователем также может быть использована для:

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

6.5.2 Выполнение оценки дизайна пользователем (юзабилити-тестирование)

Для оценки дизайна пользователями должно быть предусмотрено:

  1. выделение ресурсов для получения отзывов на ранних этапах разработки проекта с целью улучшения дизайна, и на более поздних этапах — для проверки выполнения требований;
  2. планирование человеко-ориентированной оценки в соответствии с графиком разработки проекта;
  3. проведение всесторонних испытаний для получения данных о системе в целом;
  4. анализ результатов оценки, ранжирование проблем и представление решений;
  5. передача решений для эффективного использования группой проектирования.

6.5.3 Ориентированные на пользователя методы оценки дизайна

Существует большое количество ориентированных на пользователя методов, которые могут быть использованы для оценки дизайна. Руководство по методам оценки юзабилити и выбору наиболее подходящего метода или набора методов приведено в ISO/TR 16982.

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

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

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

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

Двумя распространенными способами оценки дизайна с позиции пользователя являются:

  • испытания с участием пользователей (юзабилити-тестирование);
  • оценка на основе проверки выполнения требований юзабилити и общедоступности и соответствующих руководств.

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

6.5.4 Испытания с участием пользователей (юзабилити-тестирование)

Ориентированные на пользователя испытания могут быть проведены на любом этапе проектирования.

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

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

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

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

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

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

6.5.5 Проверка выполнения требований юзабилити

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

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

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

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

6.5.6 Мониторинг в процессе эксплуатации

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

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

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

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

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

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

Комментарии

комментариев