Интеграция с внешними системами (сторонними приложениями) часто становится «палочкой-выручалочкой» при разработке продукта. Такой подход ускоряет время и экономит бюджет, если создание собственного решения дороже. Без интеграции не обойтись и когда необходимо подключить стороннее приложение для выполнения требований законодательства, например, в зарегулированных нишах.
А еще, интеграция с внешними системами — это своеобразный челлендж. Коммуникация, документация, техническая часть — никогда не знаешь, что может пойти не так. В статье собрали три ярких примера.
Кейс 1. Отличное общение — неудачный запуск
Создавали приложение для пользователей устройств Huawei. Чтобы его полноценно запустить, нужна была интеграция с AppGallery.
Вышли на связь с менеджерами AppGallery, объяснили им ситуацию. Их технические специалисты скачали с Play Market наше приложение и сделали реверс-инжиниринг. Затем прислали нам список того, что нужно изменить и подробную инструкцию. Также был созвон AppGallery и наших разработчиков, на котором обсудили детали.
Примерно за четыре недели (по плану было три) были внесены все необходимые изменения и приложение отправили на модерацию. С первого раза нас не пропустил бот. Долго искали причину, а она оказалась в первом экране. На нем был список стран, где Гонконг мы написали отдельно от Китая, а по правилам AppGallery должны были указать в качестве региона Поднебесной.
В итоге технические специалисты AppGallery посоветовали просто добавить фразу «страны и регионы». После внесения изменений приложение пропустили, но мы потеряли еще неделю и сорвали запланированные сроки запуска.
По результатам можем сказать, что технический этап интеграции мы прошли «на ура» благодаря хорошей коммуникации со специалистами AppGallery. А вот запуск приложения «пробуксовали» из-за незнания нюанса с формальным определением Гонконга на платформе. Всегда нужно уточнять подобные моменты перед стартом интеграции.
Кейс 2. Хорошая готовая библиотека, если б не один нюанс
Проводили интеграцию приложения с Google Faces, чтобы была возможность изменять лицо, а точнее форму бровей, в AR-приложении.
Специалисты в команде заэстимейтили техническую часть на 3 недели, так как планировали использовать уже готовые библиотеки. Когда же начали процесс интеграции, оказалось, что на тот момент Google Faces не умела распознавать ту область лица, которая нужна для приложения (форму бровей изменить так и не удалось). В результате сроки затянули примерно в четыре раза, клиент был жутко недоволен, а проект в целом убыточен.
Ошибка была допущена на этапе проектирования. Мы не до конца изучили технические возможности Google Faces, что и привело к неприятным последствиям. В интеграции с внешними системами любая деталь может сыграть роковую роль, поэтому нужно внимательно все проверять еще на этапе выбора стороннего решения. Например, можно взять готовую библиотеку, написать кусочек кода и сразу проверить все ли ОК.
Кейс 3. Не учли риск, потеряли прибыль
Клиент поставил задачу по интеграции регионального банкинг-сервиса.
С технической точки зрения проблем не было, но в какой-то момент банк поднял сумму комиссии за транзакцию. Что делать? На тот момент на том региональном рынке было еще два игрока, с которыми можно было провести интеграцию. В итоге так и сделали, но заняло это примерно месяц, в течение которого мы проработали почти в минус из-за низкой маржинальности бизнеса. Прицел был на обслуживании большого количества людей, а из-за подъема комиссии банком «съедалась» почти вся прибыль.
Мы изначально не учли риск, связанный с ценами на услуги банка. В итоге потеряли месяц и ощутимую сумму денег. Следует помнить, что при интеграции внешней системы многие вещи невозможно контролировать. Поэтому еще на моменте проектирования важно продумывать все возможные риски и план реагирования на них.
4 совета, чтобы интеграция прошла хорошо
- Тщательно изучите документацию. Перед подключением стороннего решения внимательно изучите всю информацию о нем, даже между строк (особенно техническую часть). Отнеситесь к ней словно это юридический договор, где неверно прописанная или понятая фраза может серьезно «аукнуться» в итоге. Аналогично поступайте и с документацией с вашей стороны. Она должна быть понятной и максимально полной — это серьезно упрощает работу над интеграцией любого продукта.
- Заранее продумайте менеджмент доступов. Беспорядок в этом вопросе может привести не только к неудобству работы команды, но и к проблемам в безопасности проекта. В любой момент ваш проект может покинуть кто-то из команды или сменится ответственный со стороны клиента/партнера. Следовательно возможна утечка информации. Поэтому не раздавайте всем подряд доступы, не храните их в переписках и обязательно продумывайте вариант быстрого отключения вышедших из процесса. Для этого у вас должен быть не только доступ ко всем аккаунтам, но и контроль за ними. Для удобства можете использовать сторонние сервисы по типу Vault и подобные.
- Правильно рассчитайте стоимость. Прежде чем решиться на интеграцию внешней системы, распишите все плюсы и минусы. Есть вероятность, что после расчета вы начнете разрабатывать свое решение. В долгосрочной перспективе собственное решение может быть выгодным не только по деньгам, но и в других аспектах: поддержке, возможностях апгрейда, безопасности.
- Проверьте стабильность сервиса. Убедитесь в работоспособности стороннего решения (например, через Statuspage). Если что-то не так, но альтернативы нет, при интеграции продумайте резервные варианты и failover-механизмы.
Внешняя система помогает сэкономить деньги или быстро запустить продукт. А скорость в IT играет решающую роль. Чем быстрее пользователи получат возможность взаимодействовать с продуктом, тем выше вероятность успеха. Полностью избавиться от подключения сторонних решений вряд ли получится. Дата-провайдеры, mls, какие-то специфические базы данных — без интеграции с ними сложно представить разработку любого продукта. Главное, делать все грамотно и систематически углублять свою техническую экспертизу.