ISO 9241-210. Планирование и внедрение Human-Centered Design
Из опроса в конце предыдущей статьи я узнал, что читателям интересны все три из предложенных аспектов Human-Centered Design (далее — HCD):
Стандарты,
Методология,
Внедрение.
В этой статье я расскажу, как использовать стандарт ISO 9241–210 для планирования и внедрения HCD-подхода. Также я покажу как HCD может дополнить две наиболее часто используемые модели разработки: Scrum и Waterfall.Если вы спросите специалиста Human-Centered Design об основных этапах в рамках HCD, скорее всего нарисует примерно такую картинку: 
Данная схема является краеугольным камнем стандарта ISO 9241–210. Он описывает этапы проектирования интерактивной системы в рамках HCD.
Прежде чем разбираться с каждым из этапов, давайте остановимся на принципах HCD, описываемых в стандарте.
Принципы HCDСтандарт ISO 9241–210 описывает 6 принципов, которые следует учитывать при создании продукта в рамках HCD: Проектирование должно быть основано на точном определении пользователей, их задач и среды. То есть нам надо знать, кто наши пользователи, какие задачи они будут решать и в каких условиях. Также здесь следует обратить внимание на фразу «основано на точном определении». Под этим понимается, что в рамках HCD, проектирование выполняется ни исходя из предположений отделов маркетинга или дизайна, а на основе данных полученных в результате исследований. О том, какие бывают типы исследований, и как их проводить, я расскажу в одной из следующих статей; Пользователи должны быть вовлечены в проектирование и разработку. Вовлечение пользователей в процесс разработки позволяет получить необходимую информацию о контексте использования, задачах и о том, насколько продукт будет принят пользователями после релиза; Проектирование должно быть основано на обратной связи от пользователей. Тем самым мы минимизируем риски того, что будущий продукт не будет соответствовать требованиям пользователей и/или организаций; Процесс должен быть итеративным. Не возможно заранее предсказать, какие из дизайнерских решений окажутся наиболее адекватными. Соответственно, такие итерации должны быть заложены как в календарный план проект, так и в бюджет; Чуть больше чем просто Usability. В оригинале это звучит как «The desing addresses the whole user experience». В ГОСТе это переведено, как «учет опыта пользователей», что, на мой взгляд, искажает значение фразы. Смысл в том, чтобы ориентироваться не только на простоту использования, но учитывать также такие аспекты, как удовлетворенность работой, отсутствие монотонности и т.д. Если кто-то сумеет предложить подходящий русский аналог для данного принципа, с удовольствием включу его в статью; Команда должна быть мультидисциплинарной. Теоретически здесь все просто — чем шире общий кругозор у команды-разработчика, тем больше аспектов HCD будет учтено. На практике следует иметь в виду, что у представителей различных профессий могут быть различные походы к решению одних и тех же задач, и разные системы ценностей (например, что важнее функционал или дизайн). Соответственно возможность таких разногласий следует предвидеть и заранее выбрать стратегии урегулирования. Теперь, когда мы разобрались с основными принципами, давайте перейдем к этапам в рамках HCD-процесса.Планирование HCD В рамках планирования HCD, стандарт ISO 9241–210 предлагает выполнять следующие действия: Определение подходящих методов и необходимых ресурсов. Я планирую посвятить методике подбора подходящих методов отдельную статью; Определение того, как вышеуказанные методы будут интегрированы с другими процессами разработки. HCD не должен висеть в воздухе. Это поможет избежать ситуаций, когда вы написали отличный отчет по Usability, но дизайнеры и разработчики его не используют, так как в проект уже сложно/дорого вносить предложенные вами изменения; Определение ответственных. Особенно важно, если команда или компания раньше на занимались HCD. В противном случае процесс будет пущен на самотек; Определение каналов коммуникации и методов разрешения противоречий. Вы написали классный отчет по Usability, проект находится еще в стадии дизайна. Цена изменений сравнительно низка, но дизайнеры, не знают о существовании вашего отчета. Или еще хуже. Дизайнеры читали ваш отчет, но считают ваш предложения ошибочными. Должны существовать процедура решения таких противоречий; Должны быть согласованны временныe рамки отдельных этапов HCD и их интеграция в общий план разработки. Сюда входят сроки итераций, периоды для внесения изменений в проект и т.д. После того, как все необходимы этапы были запланированы, мы можем перейти к спецификации контекста использования.Спецификация контекста использования Прежде всего, под контекстом использования подразумевается совокупность характеристик пользователей, их задач, а также организационного, технического и физического окружения, в котором используется или будет использоваться тот или иной продукт.Соответственно, стандарт ISO 9241–210 рекомендует выполнять следующие действия в рамках спецификации контекста использования:
Определить основные группы пользователей и заинтересованных лиц (stakeholders). В дальнейшем эти группы будут источниками требований для нашего проекта;
Определить цели и задачи вышеуказанных пользователей и заинтересованных лиц. Это позволит еще лучше понять логику работы будущего приложения и сформулировать более детальные требования;
Определить техническое, организационное и физическое окружение. Это также позволит нам лучше понять контекст использования и предоставит базис для описания требований к продукту.
После того, как контекст определен, мы можем вырабатывать требования к продукту исходя из этого контекста.Спецификация требований
В рамках процесса спецификации требований, стандарт рекомендует выполнять следующие действия: Описать требования к продукту. Требования должны быть описаны на основе предполагаемого контекста использования. Также при создании списка требований могут использоваться различные стандарты, требования бизнеса и надзорных организаций;
Разрешить противоречия между различными требованиями. При этом задокументировать обоснования для принятых решений. Это особенно актуально в больших организациях с высокой текучестью кадров;
Убедиться в качестве сформулированных требований. Требования должны быть
Сформулированы таким образом, чтобы в дальнейшем продукт можно было тестировать на соответствие этим требованиям;
Согласованы со всеми заинтересованными лицами;
Целостными. Надеюсь, что вы уже разрешили все внутренние противоречия в требованиях;
Актуальными и обновляемыми в течение жизни проекта. Устаревшие требования это как устаревший антивирус — дают обманчивое ощущение безопасности.
После того, как требования сформулированы, пришла пора перейти к проектированию.Проектирование
Для удобства скопировал сюда схему из начала статьи
Стандарт ISO 9241–210 рекомендует включать следующие действия в рамках этого этапа: Спроектировать задачи пользователя, взаимодействие пользователя и системы, а также интерфейс, так, чтобы они соответствовали требованиям, сформулированным в рамках предыдущей фазы. При этом мы говорим не просто о добавлении тех или иных функций, а исходим из того, что у пользователя есть некие цели. Для достижения этих целей пользователь выполняет те или иные действия. Например, пользователь-бухгалтер не хочет просто выполнять абстрактные арифметические операции. Он хочет максимально быстро закончить отчет для налоговой, чтобы избежать проблем с руководством.
Детализировать проектные решения. Здесь рекомендуется разрабатывать сразу несколько параллельных решений, чтобы иметь возможность проверить их на пользователях. Также рекомендуется закладывать время на несколько итераций проектирования — это позволит выработать более целостное решение.
Использовать обратную связь от пользователей для улучшения проектных решений;
Донести проектные решения до тех, кто будет заниматься разработкой/внедрением. В противном случае конечный продукт не будет целостным, даже если был спроектирован таковым.
В конце этого этапа мы обладаем целостным и детальным проектным решением. Пришло время оценить, на сколько наше решение работоспособно для реальных пользователей.Оценка соответствия требованиям
Проверка на соответствие преследует следующие цели: Получить новую информацию о пользователях. В процессе проектирования у вас возникали новые уточняющие вопросы. На часть из них вы получили ответ, на часть ответили исходя из своих предположений. В рамках данного этапа вы можете проверить свои предположения на практике;
Получить обратную связь о слабых и сильных сторонах дизайна. Это позволит расставить приоритеты для следующей итерации;
Установить критерии, относительно которых вы будете сравнивать текущую и следующую версии проекта.
Для достижения поставленных целей стандарт рекомендует выполнять следующие действия: Оценка решений на основе тестов с участием пользователей. Например, вы приглашаете пользователей и просите их выполнить те или иные действия в вашей программе;
Оценка решений на основе экспертного мнения. Вы приглашаете эксперта и он оценивает ваш продукт исходя из собственного опыта и общепринятых практик. Относительно дешевое решение, однако наиболее критические проблемы скорее всего будут упущены;
Длительный мониторинг. Анализ критических ситуаций, обращений в службу поддержки и т.д. После оценки вашего продукта пришло время выбора. Если вы обнаружили существенные недостатки и бюджет это позволяет, то вы возвращаетесь на одну из предыдущих стадий. Если все хорошо, или у вас кончаются деньги, вы выпускаете продукт.Это была теория, но как внедрить данный подход, например, в рамках Waterfall или Scrum моделей?
В данной статье я предполагаю, что читатель знаком с моделями Waterfall и Srum, поэтому не буду уделять много времени описанию особенностей каждого из подходов.Waterfall-модель
Ниже вы видите графическое представление модели Waterfall. Мы начинаем с формулирования требований, затем разрабатываем решение, согласно требованиям. Мы внедряем решение, оцениваем его и исправляем ошибки/недочеты.
Как мы можем применить HCD-подход в рамках этой модели?
Например, в рамках описания требований, мы можем выполнить фазы спецификации контекста использования и спецификации требований из HCD-подхода.
В рамках разработки мы можем включить фазу проектирования из HCD-подхода. Кроме того, мы можем частично включить сюда фазу оценки соответствия требованиям. Это позволит нам разработать более целостное решение и избежать «детских болезней». На схеме ниже я показал этот вариант пунктиром, потому что он предполагает итеративность процесса разработки, что может противоречить видению команды разработчиков.
Также фаза оценки соответствия требованиям может распространяться на этапы оценки и поддержки из модели Waterfall.
Предположу, что основной проблемой, с который вы столкнетесь при внедрении HCD-подхода в рамках модели Waterfall будет отсутствие итераций в рамках модели. Эту проблему можно нивелировать путем зацикливания модели Waterfall. Другой вопрос, на сколько такое зацикливание соотносится с предпочтениями и/или стратегическими целями вашего руководства.
Scrum-модель Более гибкая модель. К тому же в ней изначально заложена итеративность.Как HCD-подход может быть интегрирован в эту модель?
Прежде всего, результаты фаз спецификации контекста использования и спецификации требований могут служить источником информации для бэклога проекта. Также исследования в рамках HCD (например, интервью, опросы, dairy studies и другие) могут лечь в основу истории спринта (Sprint Story).
Оценка соответствия требованиям может, с одной стороны, помочь выбрать наиболее приоритетные задачи для следующего спринта; с другой, оценить результаты по окончании текущего спринта.
Фаза проектирования из HCD-подхода, соответственно, может быть внедрена в рамках текущего спринта.
Как вы видите, стандарт ISO 9241–210 предоставляет базу для планирования и управления процессами в рамках HCD. При этом он является достаточно абстрактным и может применяться практически в любых ситуациях.В ближайший год или два выйдет стандарт ISO 9241–220, который более детально будет описывать каждую из фаз HCD. Пока что он не доступен для широкой публики, однако его текст пару раз попадался мне в Интернете. Если кто-то из коллег найдет его и отправит мне ссылку, буду очень благодарен.
В следующий статье я планирую описать подход, позволяющий выбрать тот или иной HCD-метод в зависимости от текущей ситуации (бюджет, временные рамки, относительная сложность проекта и т.д.).
