Банк собирался заменить старую систему на новую, чтобы повысить эффективность работы операторов:
- облегчить восприятие информации;
- уменьшить число действий, необходимых для выполнения каждой операции;
- снизить число и вероятность возникновения ошибок;
- сократить срок обучения новых сотрудников и переучивания опытных операторов при переходе на новую систему.
Мы могли помочь в достижении этой цели благодаря своему опыту работы на аналогичных проектах и знанию методологии HCD, поэтому нас и выбрали в качестве внешних специалистов.
Изначально планировалось, что проект будет выглядеть примерно так:
- мы изучаем работу операторов системы и формулируем требования к новому интерфейсу;
- в соответствии с полученными требованиями разрабатываем концептуальные, а затем и детализированные прототипы новой системы;
- тестируем систему, корректируем прототип;
- оцениваем потенциальную эффективность новых интерфейсов по методу GOMS;
- дизайнеры Тинькофф Банка отрисовывают экраны новой системы в соответствии с нашими прототипами;
- команда разработчиков Тинькофф Банка воплощает новую систему в коде.
Однако на определенном этапе проект пошел не так, как мы планировали изначально, и только благодаря слаженной работе руководителей проектов с обеих сторон критическая ситуация была разрешена практически в момент ее зарождения, а проект успешно завершен.
Проблема: конкуренция двух команд
Проблема, с которой мы столкнулись, на самом деле была связана с позитивным явлением: неравнодушием команды заказчика и ее большим желанием участвовать в реализации проекта.
На первых этапах проекта мы изучили работу сотрудников контакт-центра и разработали требования к интерфейсу новой системы и его функциональным возможностям. После этого мы подготовили концепцию системы и презентовали ее заказчику. Однако оказалось, что команда дизайнеров Тинькофф Банка настолько вдохновилась нашей концепцией, что решила включиться в проект прямо «на лету». На очередной встрече с представителями бизнеса они презентовали собственные дизайн-макеты тех же экранов, прототипы которых готовили мы, и это было совершенно неожиданно для нас.
Подготовленные дизайнерами экраны выглядели выигрышно на фоне наших черно-белых макетов, поскольку были оформлены в фирменном стиле банка. Однако на них появились элементы, которых не было на наших макетах и которые, по нашему экспертному мнению, не всегда удачно вписывались в рабочий процесс будущих пользователей. Возник конфликт. Вместо того, чтобы продолжать работать над макетами, две команды спорили о том, насколько удобным для пользователя будет то или иное решение и можно ли решить бизнес-задачу, не добавляя на экран новые информационные блоки.
Фрагмент переписки с заказчиком
Выход: сотрудничество двух команд
Сложная ситуация во взаимодействии между проектировщиками USABILITYLAB и дизайнерами Тинькофф Банка заключалась в том, что и те, и другие пытались выполнить одну и ту же задачу: подготовить макеты экранов, опираясь на результаты проведенного командой USABILITYLAB исследования и свой опыт. Поэтому, чтобы выйти из тупика, мы договорились с руководителем проекта со стороны банка о разделении обязанностей между нами и дизайнерами. Мы стали отвечать за компоновку всех информационных блоков на экране и за общую концепцию, а дизайнеры — за визуализацию этой концепции. Готовые экраны мы вместе должны были представлять представителям руководства Тинькофф Банка каждую неделю. Таким образом, «команда USABILITYLAB» и «команда дизайнеров Тинькофф Банка» исчезли: мы стали единым целым с общим заказчиком и общими целями.
Фрагмент переписки с заказчиком, в которой были зафиксированы договоренности по новому формату работы
Работая по такой схеме, мы каждый день созванивались с дизайнерами и обсуждали: что было сделано за день, в чем возникли проблемы и что будет делаться дальше. Для созвонов и обмена файлами мы использовали Skype, а достигнутые договоренности записывали в Google Docs. Мы создали единый документ, в котором для каждого созвона фиксировали дату, вопросы, которые обсудили и задачи, которые надо было решить. Для каждой задачи обязательно прописывался ответственный в лице конкретного сотрудника.
Пример фиксации итогов созвона
На еженедельных созвонах с заказчиком мы согласовывали подготовленные за неделю экраны. По итогам встречи мы составляли документ с резюме и общим списком правок для обеих команд, а также готовили список задач на следующую неделю.
Благодаря такой схеме работы, нам удалось наладить продуктивную работу. Мы отказались от этапа детального проектирования, поскольку детализацией наших макетов стали заниматься дизайнеры. За счет этого нам удалось проработать больше пользовательских сценариев, чем это было заложено планом проекта. Банку, в свою очередь, удалось значительно сократить общее время проекта, потому что разработка дизайна шла одновременно с подготовкой прототипов, а не после, как это обычно бывает.
Результат проекта
В результате проекта мы создали спецификацию системы, где описали вид, последовательность, наполнение и поведение экранов системы, которые видит оператор, обрабатывая сообщения, связанные с продуктами и услугами банка. Подавляющее большинство экранов системы строится по одному и тому же шаблону, что облегчает пользователям работу с системой и уменьшает время обучения.
Концептуальная схема строения основных экранов системы
Одним из главных инструментов работы оператора стала «умная» поисковая строка, куда оператору достаточно ввести лишь несколько букв, чтобы найти нужную информацию или выполнить определенную процедуру. Система умеет выдавать нужный оператору результат по разным синонимам и ключевым словам.
Пример работы «умной» поисковой строки
Основная рабочая область оператора — центральная зона экрана. Ее содержимое может меняться в зависимости от того, какое обращение клиента обрабатывается. Например, там могут быть определенные скрипты, список продуктов, которыми пользуются клиент, наглядно представленные графики выплата кредитов, кнопки для перевода звонка в другие отделы и т.п. Каждый такой экран мы разрабатывали, опираясь на знания, полученные из интервью с реальными операторами контакт-центра банка и наблюдений за их работой.
Пример рабочей области основного экрана системы для входящего звонка с неизвестного номера
По нашей предварительной оценке, выполненной по методу GOMS, работа с новой системой может позволить сократить время обработки одного обращения примерно в 2-4 раза, а в некоторых случаях даже почти в 6 раз, за счет сокращения числа действий, которые оператор совершает в системе.
Отрывок из отчета о предварительной оценке системы. Оценивается «чистое» время работы оператора в боевой системе и в прототипе, т.е. оценка времени посчитана без учета разговора с клиентом, поскольку длительность реплик клиента контролировать невозможно. Также в оценку не входило время отклика системы, т.к. в случае прототипа отклик заведомо быстрее, поскольку не происходит обращений в базу данных, как в боевой системе.
Совместная работа двух команд как фактор успеха проекта
Тщательно проведенное исследование пользователей и наш опыт в проектировании подобного рода систем стали одной из причин успеха проекта. Но успех был бы невозможен, если бы руководители проекта со стороны нашей компании и со стороны команды дизайнеров Тинькофф Банка не наладили бы продуктивную совместную работу. По итогам проекта мы сделали для себя некоторые важные практические выводы:
- Менеджеры проекта, тимлиды и другие представители обеих команд должны быть постоянно на связи друг с другом и держать друг друга в курсе решаемых задач, ожидаемых результатов и возникающих проблем. Это обеспечивает системность выполняемой работы.
- Зоны ответственности каждой команды должны быть четко зафиксированы. Все должны понимать кто, что и когда делает — это обеспечивает командность.
- Как бы странно это ни звучало, но в быстро развивающихся проектах нужно забыть что такое «план проекта». Конечно, важно спланировать работу и тайминг, а после следовать плану, но задачи внутри этого плана должны быть гибкими и меняться согласно новым требованиям заказчика и уже проделанной работы. Сами цели должны корректироваться еженедельно, а задачи для достижения целей должны корректироваться ежедневно для достижения наилучшего результата — это обеспечивает гибкость и позволяет достигать высокого показателя эффективности проекта.
Заключение
По нашему опыту, основанному на нескольких аналогичных проектах, описанная в статье схема ведения проекта — одна из самых эффективных при взаимодействии нескольких команд. Благодаря еженедельным созвонам заказчик оказывается максимально вовлечен в проект: он постоянно в курсе происходящего и может быстро корректировать направление развития проекта, давая комментарии или упущенные в силу каких-либо обстоятельств новые вводные. А благодаря постоянному участию в проекте команды дизайнеров мы можем быть уверены, что все наши рекомендации правильно поняты и внедрены оптимальным образом. Не менее полезно бывает, когда такое же активное участие в проекте принимают разработчики — тогда еще на этапе концепции мы можем оценить сложность технической реализации наших рекомендаций. Но главный залог успеха заключается в том, чтобы разделение на «заказчика» и «аутсорсера» исчезло и появилась новая, единая, команда, работающая на достижение общей цели.
Если вы хотите, чтобы мы спроектировали для вас интерфейс, оставьте заявку на сайте.
Подписывайтесь на наш Телеграм, чтобы не пропустить выход новых полезных статей!
