Меня зовут Кристина Павлив, я руководитель продукта в МТС: с нуля прорабатывала идею и развиваю приложение МТС Field, которым пользуются наши полевые инженеры.

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

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

Откуда взялось столько приложений?

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

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

Со стороны клиента, которому нужен интернет, все выглядело просто:

1. он оформляет заявку на подключение или устранение аварии;

2. диспетчерский центр связывается с ним для уточнения деталей и подтверждения времени визита;

3. к нему приезжают в назначенное время и подключают или чинят интернет.

Со стороны инженера процесс больше был похож на прохождение квеста «найди нужное окно». Для выполнения заказа он должен был:

1. зайти в одно приложение и узнать маршрут на день;

2. сделать заявку в другом, чтобы перед поездкой взять со склада оборудование: роутер, провода и разные материалы;

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

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

5. списать в другом приложении использованные материалы;

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

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

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

Придумываем альтернативу сразу нескольким системам

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

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

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

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

В итоге мы все вместе смогли договориться и придумали план, как реализовать единое окно для полевого инженера и при этом переиспользовать все наработки. Так и родилась концепция МТС Field!

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

Погружаемся в нюансы полевой работы

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

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

Так мы поняли, что вышло хорошо, а что нужно доработать. Уже через месяц мы расширились до трехсот пользователей. От них мы получили множество новых идей, которые фиксировали и реализовывали практически в онлайне. В конце масштабировали приложение на оставшихся 2 200 человек. Сейчас с МТС Field работает около 2 500 полевых инженеров — весь B2C-сегмент во всех регионах, кроме Москвы.

После перевода в МТС Field всех пользователей мы провели опрос удовлетворенности. Почти половина поставила нам 8–10 — самую высокую оценку:

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

Если честно о проблемах

При каждом запуске нового продукта важную роль имеет фактор везения. На этапе масштабирования МТС Field нам показалось, что удача нас временно покинула…

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

Мы начали искать ошибку и… дело было в массовых сбоях, когда легла половина сервисов в Рунете. Наши пользователи были заняты делом, а не чтением новостей, поэтому не знали об этой проблеме. У них создалось впечатление, что во всем виноват МТС Field!

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

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

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

Кроме того, было сложно обеспечить баланс между внутренними регламентами и удобством работы. Иногда просили сделать что-то, идущее в разрез с действующими в компании процедурами. Много предложений было отклонено руководителями бизнес-подразделений. Например, не стали добавлять возможность брать несколько задач в работу одновременно. Это иногда бывает нужно инженерам, но по бизнес-процессам запрещено из-за рисков фрода. Или заблокировали возможность менять время и адрес заявки, так как это может сделать только клиент, позвонив в диспетчерский центр.

Однако в ряде случаев нашей команде удалось повлиять на изменение сложившихся «исторически» процессов, что позволило действительно их улучшить. Например, раньше при отмене заявок абонентами инженер оставался без работы с почти пустым расписанием на день. Теперь они могут предложить перенос другому клиенту, ожидавшему специалиста в более поздние даты, с помощью «Биржи нарядов». Так клиент получает сервис раньше, а у инженера меньше перерывов в работе. Благодаря этой фиче производительность сотрудников увеличилась на 15%. 

Что мы имеем в итоге

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

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

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