Атишей Гойал (Atishay Goyal) поделился опытом, как переделывал внутреннюю систему для государственной организации в ОАЭ. А мы извлекли из его статьи самое главное.
Проблема
Система, которую предстояло переделать, была нужна, чтобы рассматривать некие заявки от населения. На разработку предыдущей версии были потрачены миллионы долларов, у нее был красивый дизайн, но, поскольку никакие исследования пользователей не проводились, она была очень неудобной и практически бесполезной для них. Несмотря на наличие системы, обработка заявок была связана с большим количеством бумажной работы. На обработку одной заявки уходило несколько десятков дней, они накапливались в системе быстрее, чем их успевали обработать. Кроме того, у руководство не было никаких инструментов, чтобы оценить продуктивность работы конкретного сотрудника. Атишей Гойал должен был решить эти и многие другие проблемы.
Решение
Что сделал Атишей Гойал:
- изучил работу сотрудников организации, контекст, в котором они находятся, даже стиль жизни и культурные особенности;
- собрал требования к функциональности новой системы, которая должна была облегчить все этапы обработки заявок;
- описал Персоны, для которых будет предназначена новая система;
- разработал прототипы новой системы;
- провел юзабилити-тестирования и собрал обратную связь от пользователей.
- тщательно спланировал процесс внедрения обновленной системы: в один момент времени обновленную систему получал только один департамент, а не вся организация сразу.
Результат
После того, как новая система была выпущена, время обработки заявки уменьшилось на 60% — в основном потому что многое из того, что раньше делалось вручную, было автоматизировано. Количество необработанных заявлений начало уменьшаться на 8% каждую неделю. 87% сотрудников используют исключительно новую систему, хотя старая им по-прежнему доступна. Для контроля продуктивности внедрена система геймификации — списки лидеров и вознаграждение самых продуктивных сотрудников.
Выводы
Почему проект был успешен? Мы выделили из статьи несколько важных рекомендаций и выводов:
- Огромную роль в успехе проекта сыграло исследование пользователей. На результатах исследования строились требования к функциональности новой системы.
- Важно знать психологию пользователей. Например, оказалось, что из-за культурных особенностей ввести систему прямого контроля за продуктивностью невозможно: это вызвало бы отторжение у сотрудников. Поэтому пришлось искать обходные пути и представлять систему контроля и поощрений в геймифицированном виде.
- Разные сотрудники обрабатывают заявки по-разному, хотя и по одному протоколу. Чтобы всем было удобно, у них должна быть возможность персонализировать систему: использовать виджеты, фильтры, менять под себя таблицы и т.п.
- Какой бы плохой ни была старая система, пользователи к ней привыкли. Поэтому нужно сохранить максимальную преемственность как в плане визуального дизайна, так и в некоторых процессах — если что-то работало хорошо, лучше это сохранить, а не переделывать только ради переделки.
- Старая система функционировала параллельно с новой, потому что в редких случаях некоторые заявки через новую систему обработать было невозможно. Если бы старую систему убрали сразу после внедрения новой, часть заявок осталась бы необработанной.
- Какой бы хорошей и интуитивной ни была новая система, важно провести обучение и показать пользователям ее возможности: интерфейс, функции, настройки, сочетания клавиш и т.п.
- Один из секретов успеха — постепенный процесс внедрения новой системы. Новая система выкатывалась на один департамент за один раз. В течение недели разработчики собирали обратную связь о юзабилити-проблемах и багах в системе, исправляли их и после этого переходили к следующему департаменту.
- Хитрость, которая позволила снизить нагрузку на службу поддержки, получать только значимый фидбэк от пользователей и сделать более эффективную систему обучения пользователей: в каждом отделении был назначен “евангелист” системы из числа сотрудников, которые быстрее, чем остальные, освоили работу с ней. “Евангелист” отвечал на вопросы коллег, помогал разобраться с системой, некоторые серьезные вопросы передавал разработчикам.
Читайте весь кейс тут, несмотря на немного специфичный английский автора, он очень подробный и полезный.