На ретро можно услышать, что все сроки упущены, потому что на старте плохо проработали требования. Наш кейс как раз про это и не про это одновременно. Для нас внезапно отсутствие аналитики на старте оказалось не самым плохим решением. И сейчас мы закрываем проект с крутым результатом, планом на развитие и маленьким техдолгом, вместо того, чтобы потратить год на аналитику, рассчитать стоимость и получить от ворот поворот от стейкхолдеров.
Меня зовут Наталия Поломошнова, менеджер разработки Центра внедрения информационно-технологических решений. Расскажу, как мы в Уральском банке реконструкции и развития (УБРиР) работали над приложением доставки.
Имитация длиной в 12 месяцев
Началось все с того, что мы попросили всех участников ручного процесса доставки записать скринкаст своих действий на всех этапах. Доставка пластика похожа на выдачу карты в отделении: мы готовим для клиента пакет документов на оформление карты. Туда входят договор на банковское обслуживание, анкета-заявление, где обозначен продукт, который клиент хочет получить, а также документы, без которых мы не можем работать с клиентом. Например, согласие на обработку персональных данных.
В отделении сотрудник сначала внес бы ваши данные в SAP CRM и завел профиль клиента по паспортным данным, потом распечатал нужные документы, а после получения клиентской подписи проставил бы нужные галочки в CRM, модуле учета карт и других системах.
Смотрите, весь процесс поместился в одно предложение! Вот мы оценили его в 3 месяца, решив, что можем просто имитировать программно действия сотрудника точки продаж. Сразу спойлер: это оказались не три месяца, а год. Год за который мы успели собрать дрим тим и начать возить по 10 000+ карт в месяц в более чем 100 городов.
Не вся роботизация одинаково полезна
Наша ошибка была в том, что для нас оказался неактуальным процесс роботизации действий сотрудников. Роботизация, как выяснилось, была дороже в сопровождении, требовала покупки лицензий, а главное — не меняла текущий бизнес-процесс. Ручной процесс доставки не соответствовал действительности, потому что сначала реализовывалась проводка (подключение счета и услуг), а затем происходило событие — выдача карты. И если в точке продаж два этих события разделяются по времени минутами, то в доставке заявка оформлялась в один день, а сама доставка происходила на следующий. Поэтому единственным решением для доставки оказалась полная автоматизация обновленного под текущую реальность бизнес-процесса. С одной стороны, это требовало больше времени и ресурсов, с другой — мы приобретали возможности неограниченного масштабирования и делали все по уму.
Архитектор нарисовал в Camunda процесс, и разработчики приступили к написанию первых сервисов нашего приложения. Клиенты оставляли заявки на доставку на посадочной странице или в колл-центре, заявки агрегировались в CRM-системе, откуда мы уже вытягивали их в приложение. С данными по заявке и данными о клиенте мы планировали получить из SAP CRM пакет документов, и вот уже можно везти карту.
Самый большой фейл на проекте
Оказалось, чтобы документы по заявке сформировались, необходима не только заявка в CRM, но и “продуктовая заявка”, которая содержит в себе информацию о номере счета, подключаемых услугах и тех документах, которые банк уже подписывал с клиентом ранее. Мы не знали этого, потому что на старте проекта с нами не было никого, кто хорошо ориентировался в бизнес-процессе банка. За создание “продуктовых заявок” отвечала другая команда, она реализовала для нас базу, в которую раз в два часа приходят нужные нам данные по продуктовой заявке. Эти данные обновляются с помощью загрузчика продуктовых услуг, он запускается вручную, поэтому некоторые процессы доставки теперь привязаны к циклам загрузчика.
Теперь мы, наконец, смогли подойти к шагу, когда готовы везти карту. Но у собственных курьеров банка зона покрытия только Екатеринбург, поэтому для доставок в других городах мы хотели воспользоваться услугами партнеров. Перед нами встали две задачи: во-первых, передать пакет документов и номер карты партнеру, во-вторых, организовать верификацию документов после встречи с банковскими сотрудниками.
Обе этих проблемы мы решали параллельно. Разработчики вместе с заказчиками придумывали интерфейс и делали его на jsp в том же приложении, где бэкенд. Отсутствие навыков ui-проектирования в команде до сих пор нам аукается. Нарисованные в Excel интерфейсы с кнопками типа “удалить/редактировать” стали страшным сном для сопровождения, а пользовательское поведение до сих пор не перестает нас удивлять. Но мы не забили, и планируем не просто выделить фронт в отдельное приложение и переписать его на чем-то приличном, но и добавить распознавание текста с документов и обновление информации о клиенте в CRM одной кнопкой.
Один партнер – это хорошо, а три – сложная поддержка API
Партнерские интеграции тоже не дались команде легко. Сначала для каждого из трех партнеров мы сделали отдельные интеграции. Но администрирование разных API оказалось для бизнеса проблемой. Поэтому мы оставили через API минимальный обмен заявками, документами и статусами, а часть процесса по отчетности осталась в ручном режиме, когда партнеры ежедневно отправляли таблицу с отчетом по статусам заявок. Разрулить эту проблему мы смогли через полгода. Она потребовала большого объема аналитики, потому что кто-то из партнеров обходится минимальным количеством статусов и причин, а кто-то готов заспамить банк информацией, что клиент был не в настроении получать карту сегодня, а завтра не готов, а потом ему еще пять раз не дозвонились.
Спустя 6 месяцев после старта разработки мы запустили автоматизацию и отвезли первую карту. Из 100 штук только 20 проходили по "зеленой ветке", а остальные 80 шли по отлаженному, но не целевому ручному процессу. То есть сотрудники сами готовят документы, передают их партнеру по электронной почте и таким же образом получают фото в ответ.
Выводы, фиксы и режим промышленной эксплуатации
Релиз позволил снять напряжение, команда выдохнула и пошла фиксить баги. Мы собрали все шишки, свойственные стартапу, который должен присосаться к большому легаси. Эти ошибки годами копились в банке и решались вручную сотрудниками… все это стало нашей проблемой. Например, всем клиентам банка подключаются SMS по два раза, просто в точке сразу килляют лишний тариф. Естественно, у такого бага есть ограниченный срок фикса — пока не списались деньги с клиента, а интерес у починки этой истории есть только в доставке, ведь всех остальных устраивало жить с ручным решением этой проблемы.
Но самой большой бедой оказалось отсутствие актуального тестового ландшафта. Шансы на быстрое его поднятие были ничтожными настолько, что мы решились на режим промышленной эксплуатации. После конца рабочего дня в Екатеринбурге, когда сотрудники-верификаторы шли по домам, мы накатывали на прод обнову, пробегались по тестовым кейсам и откатывались, чтобы пофиксить баги.
На этом этапе у доставки опять сменилась команда. Ребята из аутстафа, которые были на проекте с самого начала, разошлись по другим проектам, а доставка стала обрастать своей командой. В один день в команду добавился менеджер и ораклист, буквально через неделю сменились два джависта. Закончился онбординг у аналитика, и через пару месяцев добавился еще один. А главное, появился умудренный опытом, но достаточно смелый техлид внутри банка!
Из проекта мы вынесли один большой минус аутстафа. Хоть ребята и отрабатывали свое время, они не ориентировали заказчика в принятии решений по работам и срокам. Нам нужен был фидбэк, чтобы нас затормозили, объяснили и приземлили. Рисковые ребята, готовые реализовать любое желание, — это классно и нужно, но мы платим за компетенции по принятию решений тоже, а в доставке мы этого не получили.
Мы дофиксили баги, перестали работать по ночам и даже начали делать какие-то милые фичи, например, бот в Телеграме, который шлет алерт, если в городе доставки осталось мало карт. Мы, наконец, научились оценивать и перестали срывать сроки поставок.
Если бы мы ждали, когда сделаем аналитику, соберем команду, мы бы жили без решения до сих пор. Велика вероятность, что нас могли зарубить на старте, если бы мы сначала просто считали бюджет на аналитику, а потом пошли оценивать разработку. Но мы все время показывали результат, поэтому мы здесь. Наш следующий шаг — пилот своей курьерской службы. Но это история, которую нам только предстоит рассказать.
