Как нечеткие цели на старте проекта и плохая работа с заинтересованными сторонами привели к переделкам на миллионы долларов. Часть 2.

Если вы не читали первую часть данной статьи, то предлагаем ознакомиться здесь: Перейти


3. Противоречия между техническими возможностями и ожиданиями

Поставленные цели не учитывали реальных технических возможностей.

Например:

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

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

3.1. Нереалистичные сроки.

Ожидания:

•  Проект стартовал в начале 2010 год. Белый дом и политические лидеры настаивали на запуске платформы 1 октября 2013 года, чтобы соблюсти сроки реализации программы Affordable Care Act (ACA).

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

Реальность:

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

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

3.2. Нагрузка на систему и масштабируемость. 

Ожидания:

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

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

Реальность:

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

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

3.3. Интеграция с внешними системами. 

Ожидания:

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

•  Ожидалось, что интеграция будет бесшовной, быстрой и надежной.

Реальность:

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

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

3.4. Постоянное изменение требований (scope creep)

Ожидания:

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

•  Ожидалось, что изменения не повлияют на сроки и бюджет.

Реальность:

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

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

3.5. Недостаток тестирования

Ожидания:

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

•   Считалось, что процесс тестирования выявит и устранит все критические ошибки.

Реальность:

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

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

4. Недостаточная фокусировка на конечных пользователях

Цели не учитывали потребности конечных пользователей, таких как:

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

•  Простота процесса регистрации и выбора страховки.

 Как проблема проявлялась на практике?

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

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

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

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

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

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

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

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

Что пошло не так?

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

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

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

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

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

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

Резюме

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

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