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

Представьте: вы придумали классное решение внутри своего продукта, которое в разы упростит жизнь клиентам. Анонсировали в СМИ коллаборацию с известной компанией, пилите интеграцию и готовитесь успешно выкатить релиз. Но внезапно выясняется, что при разработке потерялось важное бизнес-требование. Теперь проект висит на волоске, вы рискуете потерять репутацию, доверие общественности и партнеров, а еще затянуть проект минимум на полгода. Ситуация патовая.  

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

Привет 👋🏻 Меня зовут Аркадий Кашковский, я CEO системного интегратора LAND PRO. Мы делаем интеграции для разных компаний и сервисов, а еще помогаем автоматизировать внутренние процессы.

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

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

Ситуация: к нам обратился гигант рынка доставки с просьбой интегрировать к ним другой крупный сервис

Как это часто бывает, лучшие кейсы лежат под NDA. Именно поэтому попытаюсь рассказать историю, не раскрывая имен, паролей и явок. Объясню, как можно выстроить процессы разработки и управления проектом, чтобы было удобно и вашей команде, и заказчику. А теперь возвращаемся к контексту 👇🏻

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

Мы договорились создать решение, которое легко интегрирует оба сервиса. Ударили по рукам и приступили к разработке концепции. Тем временем обе компании объявили о коллаборации, отправили в СМИ пресс-релизы и предвкушали, как жизнь их клиентов станет еще удобнее.

Разработали процессную карту интеграции 

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

При этом представителям бизнеса важно понимать, как будут работать процессы внутри нового решения. Но возникает еще одна трудность: часто у клиента нет времени разбираться в деталях нотации. Максимум он один раз посмотрит BPMN, скажет, что примерно всё ок, и убежит решать другие горящие задачи. В этом случае есть риск упустить важные требования и не учесть значимые бизнес-цели. В результате придется потратить много времени, сил и денег на доработку или исправление ошибок. Это не нужно ни заказчику, ни команде на аутсорсе.

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

В процессной карте мы учли:

✅ сценарии — например, «Успешная доставка заказа» или «Возврат заказа»;

✅ роли — кто участвует в процессе доставки; 

✅ описание шага — сценарий состоит из шагов, для каждого из них мы прописали механику действий: с техническими подробностями, но на понятном для бизнеса языке;

✅ описание интеграции — вписали методы, которые будем использовать для интеграции, и ожидаемый ответ;

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

✅ комментарии и вопросы — описали все моменты, которые нужно дополнительно проговорить. Как только находили решение, переносили пункт в другую колонку таблицы. 

Проработали архитектуру проекта

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

Архитектуру описали при помощи схемы инфопотоков и концептуальной модели данных. Продумали детали технического взаимодействия. Для этого сделали две большие схемы:

1️⃣ синхронизация пунктов выдачи;

2️⃣ синхронизация заказов. 

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

Решили «есть слона по кусочкам»

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

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

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

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

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

Декомпозировали проект на эпики

Мы работали над эпиками в соответствии со следующим воркфлоу:

✅ Статус open — эпик получает его, когда он только создан, то есть любая новая фича попадает в него.

✅ Статус business requirements — детализировали функциональные требования к эпику в виде юзкейсов, а также учли нефункциональные.

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

✅ Статус agreement — оценили все эпики, обновили страницу версии, зафиксировали условия проекта. 

✅ Статус to do — когда эпик согласован с заказчиком, отдаем его в работу проджект-менеджеру. 

Итак, мы разделили интеграцию на части и приступили к первому эпику. Перевели его в статус декомпозиции, который следует за статусом to do. Этап, который весит от 100 до 300 часов, или три месяца работы одного человека, мы разбили на стори, которые довели до ума после груминга. Для каждой стори уже есть черновое описание, которое помогает понять границы функциональности и общую логику.

С головой окунулись в разработку

Наш процесс разработки интегрирован между тремя системами: Jira, Confluence и GitLab. Это позволяет проджект-менеджеру видеть реальную картину проекта в таск-трекере и управлять процессами прямо из него. Такая система удобна и для заказчика. Обычно его интересуют два типа задач: новые фичи и фикс ошибок. Именно поэтому у нас есть доска, по которой едут эпики и баги.  

Все задачи привязаны к странице в Confluence, описание там приоритетнее остальных платформ. Каждое составляется в формате юзкейса — с детализацией до методов,  параметров и конкретных полей в базе данных. Пишем это всё в таблице Requirements на странице эпика. 

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

Все этапы разработки связаны с GitLab, а именно:

• эпик поехал в работу — создалась ветка эпика от мастера;

• стори поехала в разработку — делаем ветку стори от эпика;

• стори прошла код-ревью — ее вмержили в эпик и отдали на тестирование;

• все стори протестировали — эпик готов, но ветку не закрываем.

Как только все стори протестировали, эпик переходит в Jira в статус Preprod Development. На основании этого проджект-менеджер может собирать релиз.

Дальше от мастера в нашем GitLab создается релизная ветка. В нее вливаются все ветки, которые пойдут в релиз. Здесь начинается магия: за счет интеграции с Git-системой клиента релизная ветка попадает на preprod клиента, а в Jira задачи получают статус Ready to preprod QA.

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

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

Конечно, для дебага доступы предоставляются, но только к логам, мониторингам и UI приклада. Остальное администрирование передается в команду эксплуатации заказчика.

Отдали клиенту готовое решение, но обнаружили потерю важного требования

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

Объясню на примере: по задумке магазина человек приходит в рандомный пункт и отправляет товар получателю. Но на стороне доставки это требование оказалось невозможным. Сервис в принципе не мог поддержать такое решение, а на реализацию сценария потребовалось бы еще 3–6 месяцев. И это в ситуации, когда обе компании уже выпустили пресс-релизы и анонсировали коллаборацию. Намечалась катастрофа. 

Вместе с 10 командами клиента придумали, как спасти интеграцию

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

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

Вот к какому алгоритму пришли совместными усилиями:

1️⃣ Заказ из магазина сначала прилетает в наше промежуточное прокси — софт, который мы разрабатываем.

2️⃣ В этом софте он останавливается и временно не идет в сервис доставки.

3️⃣ Человек приходит в любой из ПВЗ, где сотрудник пункта вбивает номер заказа.

4️⃣ Запрос из ПВЗ летит к нам, и точно в этот момент мы создаем доставку на стороне клиента. 

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

А что в итоге с доставкой?

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

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

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

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

• оставляем как есть — бледно-серый шрифт;

• убираем — зачеркнутый шрифт;

• добавляем — обычный шрифт.

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

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

Решение сработало, мы запустили интеграцию и спасли клиента от потери бизнес-партнера, клиентов и денег. Ни один пресс-релиз не пострадал 🙂 Сейчас у компании 100% трафика и 1,5 миллиона заказов в месяц, которые обслуживает наша интеграция. 

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

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