Технологическое подразделение правительства США опубликовало U.S. Digital Services Playbook – манифест с 13 принципами разработки государственных сайтов и сервисов. Основные критерии связаны с принципами открытой разработки, приоритетом пользовательских потребностей, важностью пошагового движения и другими принципами Agile-разработки. Мы расскажем более подробно о каждом из них.
Поделитесь этой новостью/ фото с друзьями в социальных сетях.
Критерий № 1. Понять, что нужно людям
Создание новых сервисов должно отталкиваться от потребностей людей, которые эти сервисы будут использовать, а также от того, как именно эти сервисы впишутся в их повседневную жизнь. Если пользователями сервиса будут только государственные служащие, при этом все равно необходимо включать реальных людей в процесс проектирования с самого начала.
Технические и дизайнерские решения должны исходить из потребностей людей, а не от возможностей государственных структур.
Необходимо постоянно тестировать результаты на реальных пользователях, чтобы оставаться честными с самими собой, определяя, что именно важно на самом деле.
Ключевые вопросы, на которые стоит обратить внимание в процессе работы над сервисом или сайтом:
- Для каких потребностей людей создан этот сервис?
- Почему пользователь будет пользоваться этим сервисом?
- Кто является ключевым пользователем сервиса?
- Какая группа людей будет испытывать наибольшие сложности при работе с сервисом?
- Какие методы исследования были использованы?
- Какие ключевые моменты были отмечены в пользовательском опыте?
- Как часто проводятся тестирования с реальными пользователями?
Критерий № 2. Продумать весь путь взаимодействия
Создавать цифровые сервисы необходимо с четким пониманием того, как именно пользователь будет взаимодействовать с сервисом и какие действия он будет при этом совершать, включая не только веб-версии, но и мобильные приложения, и личное общение. Каждое взаимодействие с сервисом должно продвигать пользователя к решению – как онлайн, так и офлайн.
Ключевые вопросы:
- Как сейчас люди борются с проблемой, для решения которой создается новый сервис?
- Где в этом существующем решении есть болевые точки для пользователя?
- Как новый сервис встроится в список других услуг, которые предлагаются пользователю?
- Какие метрики анализа эффективности сервиса подойдут лучше всего?
Критерий № 3. Сделать все простым и интуитивно понятным
Для пользователя использование сервиса или получение государственной услуги не должно быть стрессом. Процесс взаимодействия с сервисом не должен быть сложным и запутанным – пользователь с первого раза должен разобраться интуитивно, без посторонней помощи.
Ключевые вопросы:
- Какие первоочередные задачи пользователь пытается решить?
- Насколько сложным языком представлена информация?
- На каких языках будет работать сервис?
- Если пользователь нуждается в помощи при использовании услуги, как он сможет ее получить?
- Насколько дизайн этого сервиса сопоставим с дизайном сайтов и сервисов других государственных услуг?
Критерий № 4. Использовать Agile- и итерационные методологии
Необходимо использовать поэтапный стиль разработки программного обеспечения, чтобы снизить риски отказа или ошибок, предоставляя команде разработчиков возможность быстро корректировать требования и планы развития, исходя из того, как используются прототипы и сервисы в реальном времени, а также как изменяется взаимодействие самих пользователей с сервисом.
Следование Agile-методологии является оптимальной практикой создания цифровых услуг, которые будут соответствовать потребностям пользователей.
Ключевые вопросы:
- Сколько потребуется времени, чтобы запустить минимально жизнеспособный продукт?
- Сколько времени потребуется на установку и развертывание рабочей версии?
- Сколько дней составляет одна итерация/спринт?
- Какая система контроля версии кода используется?
- Какая система используется для отслеживания ошибок?
- Как собирается обратная связь от пользователей и как она улучшает работу сервиса?
- Какие потребности и нерешенные проблемы пользователей всплывают при каждом этапе usability-теста?
Критерий № 5. Структурировать бюджет и контракты
Для улучшения шансов на успех при заключении договоров на разработку сервиса необходимо взаимодействовать только с проверенными контракторами. При работе с третьими лицами правильно составленный договор может обеспечить эффективную работу, например, на стадии прототипа или при создании альтернатив с открытым исходным кодом, когда важность ключевых этапов разработки высока.
Ключевые вопросы:
- Как часто изначально оговорены этапы разработки?
- Каковы показатели эффективности, определенные в договоре?
Критерий № 6. Всегда назначать ответственное лицо
Необходимо, чтобы при разработке сервиса было назначено ответственное лицо (так называемый Product Owner – владелец продукта), которое будет иметь полномочия влиять на работу команды, а также нести ответственность за успехи и провалы всех участников создания сервиса. Такой человек полностью отвечает за этапы разработки и отставание в этапах создания сервиса.
Ключевые вопросы:
- Кто является ответственным лицом?
- Какие организационные изменения были внесены для того, чтобы владелец продукта имел достаточные полномочия для поддержки проекта?
- Что необходимо сделать владельцу продукта, чтобы добавить или удалить одну из функций сервиса?
Критерий № 7. Приглашать только опытные команды
Для создания качественных сервисов необходимы специалисты, которые из личного опыта знают, как функционируют государственные органы и как можно и нужно применять современные цифровые технологии и дизайн. Для того чтобы быть уверенными в компетентности сторонних разработчиков, необходимо понимать, как оценивать эффективность их работы.
Критерий № 8. Выбрать современный набор технологий
Для того чтобы принимать правильные решения, необходимо, чтобы команды разработчиков делали свою работу наиболее эффективно, давая возможность сервису легко масштабироваться. Так, выбор хостинга, баз данных, программного обеспечения, языков программирования и остальных технологических частей должен не основываться на стандартных и привычных решениях, а исходить из того, что успешные потребительские и корпоративные компании выбрали бы сегодня.
В частности, цифровые услуги команды должны иметь возможность использования открытого источника, облачных вычислений и готовых технологических решений, которые уже имеют широкое распространение и поддержку успешных компаний.
Ключевые вопросы:
- Какие технологии и ресурсы вы выбрали и почему?
- Какая база данных используется и почему?
- Сколько времени займет у нового члена команды установка нового программного окружения для разработки?
Критерий № 9. Быть готовым к изменениям в нагрузке на сервер
При создании сервиса необходимо быть готовым к увеличению спроса к сервису со стороны пользователей. Для этого нужно использовать гибкие технологии и облачные решения, которые не потребуют от вас управления серверами на аппаратном уровне и смогут справиться с увеличением нагрузки.
Использование ненадежных и устаревших решений приведет только лишь к увеличению расходов и затратам времени на восстановление данных в аварийных ситуациях.
Ключевые вопросы:
- Какие технологии и ресурсы вы выбрали и почему?
- Где размещен сервер?
- На каком оборудовании работает сервер?
- Какой ресурс нагрузки у сервера?
- Что случится с сервисом, если резко возрастет трафик и нагрузка?
- Как был разработан сервис с точки зрения масштабирования?
- Как оплачивается хостинг ежеминутно, ежечасно, ежедневно, ежемесячно?
- Расположены ли ваши серверы в разных регионах?
- При чрезвычайной ситуации сколько времени потребуется на восстановление работы сервиса?
- Как часто нужно связываться с хостинг-провайдером, чтобы получить ресурсы или устранить проблему?
Критерий № 10. Автоматизировать тестирование и установку
Сегодня разработчики пишут автоматические скрипты, которые могут выполнить проверку тысяч сценариев в минуту, а затем развернуть обновленный код в рабочем сервисе несколько раз в день. Они используют автоматизированные тесты производительности, которые имитируют изменения в трафике, чтобы определить проблемные места в производительности сервиса.
В то время как ручное тестирование и обеспечение качества по-прежнему необходимо, автоматизированные тесты обеспечивают постоянную и надежную защиту от спада и дают возможность разработчикам выпускать частые обновления.
Ключевые вопросы:
- Какой процент от всего кода тестируется автоматически?
- Сколько времени нужно, чтобы создать, протестировать и исправить ошибку?
- Какие инструменты для тестирования используются?
- Какова стратегия масштабирования при увеличении трафика?
Критерий № 11. Управлять безопасностью и конфиденциальностью
Очень важно, чтобы сервисы защищали конфиденциальную информацию и поддерживали систему в безопасности. Это, как правило, процесс непрерывного улучшения, который должен быть встроен в службы сервиса. Вопросами безопасности информации необходимо заниматься с самого начала работы над созданием сервиса.
Постоянная вовлеченность специалиста по безопасности сможет гарантировать, что личные данные будут защищены надлежащим образом. Кроме того, ключевой процесс для построения безопасного обслуживания – это всестороннее тестирование и сертификация компонентов.
Ключевые вопросы:
- Собирает ли служба личную информацию от пользователя? Как уведомляют об этом пользователя?
- Собирается ли больше информации, чем требуется для решения поставленной перед сервисом задачи? Есть ли данные, использование которых не ожидается пользователями?
- Как и с кем пользователь может связаться по вопросу об удалении или исправлении личной информации о нем?
- Будет ли информация, хранящаяся в системе, доступна другим пользователям или сервисам?
Каким образом и как часто служба проверяет на наличие уязвимостей?
Критерий № 12. Принимать решения на основе данных
На всех этапах проектирования необходимо оценивать, насколько хорошо сервис работает для пользователей. Это включает в себя измерение эффективности работы самой системы и того, как пользователи взаимодействуют с системой в режиме реального времени. В дополнение к инструментам мониторинга должен быть механизм получения обратной связи, который поможет сообщить о проблемах напрямую.
Ключевые вопросы:
- Каковы ключевые показатели для сервиса?
- Какие системы мониторинга используются?
- Что такое целевое среднее время отклика для вашей службы?
- Как команда получает автоматические сигналы тревоги при возникновении инцидентов?
- Какие инструменты используются для измерения поведения пользователей?
- Какие инструменты используются для A/B-тестирования?
- Как измеряется удовлетворенность ваших пользователей?
Критерий № 13. Быть открытыми по умолчанию
Для того чтобы улучшить деятельность государственных служб, необходимо быть открытыми и публиковать данные. Более открыто подходя к созданию самого сервиса, можно упростить доступ общественности к государственным услугам и информации, что позволит людям быстрее найти решение для своих проблем и задач. Также открытые данные в дальнейшем могут быть использованы предпринимателями и некоммерческими организациями.
Ключевые вопросы:
- Как вы собираете обратную связь от пользователей?
- Есть ли у вас API, какие возможности он предоставляет? Кто использует его?
- Какие компоненты сервиса с открытым исходным кодом?
- Какие данные доступны публично?