Темы  /  Лучшие практики

Основные этапы проектирования сервиса от авторов GOV.UK

8 августа 2013
Gov.uk

Веб-сайт pronauku.com разместил перевод статьи об основных этапах разработки электронного сервиса от авторов gov.uk, – образцового портала е-услуг. Статья может быть полезной всем разработчикам госсайтов, т.к. рассказывает о стадиях исследования, альфа- и бета-версии и эксплуатации сайта. E-gov.by публикует полную версию  перевода.

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

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

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

Этап исследования

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

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

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

Цели

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

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

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

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

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

  • Семинаров
  • Простых моделей
  • Бумажных прототипов
  • Множества диаграмм
  • Команда

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

Фаза не должна занимать больше 4-8 недель.

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

По завершении исследовательской фазы у вас должны быть:

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

 

Этап альфа-версии

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

Разработайте прототип, протестируйте и учтите ошибки.

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

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

Цель альфа-версии

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

  • Лучшего анализа сервиса
  • Тестирования отдельных технологий
  • Формирования команды
  • Коллективного осмысления сервиса на уровне интеграции и кодирования
  • Понимания того, что необходимо или кто необходим для разработки бета-версии

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

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

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

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

Что должно быть в альфа-версии

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

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

Как много времени это займет?

Фаза альфа это еще одна относительно короткая фаза. В Государственной электронной службе (GDS) мы стараемся ограничить эту фазу двумя месяцами, работая недельными спринтами в течение 6-8 недель.

Кто мне нужен?

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

Каковы результаты?

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

Этап бета-версии

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

Расширение и релиз

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

Что является целью бета-версии?

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

Это достигается путем внесения пользовательских историй в бэклог во время этапа альфа-версии.

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

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

Также у вас будет возможность протестировать систему помощи при использовании вашего сервиса. Можно протестировать один или несколько вариантов, разработанных на этапе альфа-версии.

Как много времени это займет?

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

Кто мне нужен?

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

Каковы результаты:

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

Этап поддержки

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

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

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

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

Что значит «этап поддержки»?

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

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

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

Что же дальше?

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

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

  • Отслеживать работу системы
  • Оптимизировать код
  • Обеспечить безопасность ресурса

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

Кто мне необходим?

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

Выход из эксплуатации

Даже лучшие сервисы порой списываются со счетов. К этому нужно относиться с такой же ответственностью и вниманием как к запуску и поддержке сервиса.

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

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

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

Узнайте о том, что делать, когда сервис вышел из эксплуатации и готовится к закрытию

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

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

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

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

Что же дальше?

Оповестите своих пользователей.

Как только Вы узнали, что сервис планируется закрыть, необходимо связаться с командой сайта GOV.UK и убедиться, что путь перехода на страницы изменен с соответствующим оповещением, так как большинство пользователей начинает и заканчивает свои перемещения через сайт GOV.UK.

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

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

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

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

План переадресации потока

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

Когда мы закрывали DirectGov, Business Link и другие государственные сервисы, мы потратили много усилий на соотнесение содержания этих страниц с содержанием сайта GOV.UK. Мы связали столько URL-адресов старого сайта с соответствующими URL-адресами на сайте GOV.UK, сколько смогли, а также снабдили страницы, которые нельзя переадресовать, ссылками на Национальный архив. Этот процесс описан в статье «Не оставляя ни единой ссылки».

Данные

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

Перевод сайта pronauku.com

Оригинал статьи “Service design phases”

Мнения:

Метки

Книги