Вы подписали большой контракт с подрядчиком на разработку корпоративного софта и ждете MVP в течение трех месяцев. Чтобы все прошло совсем гладко и быстро даже отправили подробнейшее техническое задание аж на 75 страниц. И все равно подрядчик не успел. Кажется, пришло время ругаться. Или нет, и всему виной действительно какие-то интеграции, на которые жалуются программисты?
В этой статье мы поговорим, что нужно знать и сделать, чтобы видеть риски заранее и сохранить бюджет.
Даже если у вас есть подробное ТЗ, самое главное — знать количество систем для интеграций перед стартом проекта.
Почему важно: Если интеграций много, нужно запланировать создание централизованной системы, чтобы агрегировать и передавать данные другим системам. Это похоже на Apache Kafka, но у нас был пример с S7 Airlines, где продукт собирал данные с 20 систем и передавал их дальше.
Но если интеграций мало, такой хаб не требуется. Если создать такой хаб нет возможности, нужно позаботиться, чтобы интегрируемые системы могли работать с новым софтом, тогда не придется разрабатывать сервисы в процессе работы подрядчика. В противном случае подрядчик не уложиться в сроки, потому что будет ждать пока эти сервисы появятся на стороне заказчика.
Как узнать: Для продакта достаточно сформулировать конечную бизнес-цель и разделить ее на задачи, если заказчик не понимает реальное число.
Пример: У S7 Airlines была цель — перевести бумажные накладные в электронный формат (данные из 1С).
Этапы:
Получилось 4 интеграции — две с 1С, одна с приложением и одна с другими системами, хотя сначала казалось, что интеграция систем одна.
Предоставьте разработчикам документацию по этим системам. Пусть они подпишут NDA или распишутся кровью, если придется, но им необходима эта информация.
Почему это важно: Есть системы, где интерфейсы для API-взаимодействия уже предусмотрены, и интеграция с ними проходит легко. А есть системы, у которых API по умолчанию нет. Часто бывает, когда разработчики начали работу над продуктом, а внешние сервисы не готовы. Именно это приводит к задержкам на месяц и больше, и в итоге недовольны все.
Что нужно сделать: Продакт-менеджер должен пройтись по всем системам, с которыми будут интеграции, и убедиться, что уже есть готовый интерфейс, откуда разработчики будут принимать данные или сохранять их. Если этих интерфейсов нет, ему нужно отправить соответствующий запрос владельцам этих систем.
Кто должен сделать: API должны разрабатывать владельцы этих систем и их команда разработчиков, либо они могут их купить. Главное — убедиться, что есть нужные интерфейсы. И всё это очень важно. В идеальной картине мира это нужно делать до старта разработки нового продукта. Иначе 100% будут задержки, проблемы, большие затраты, потому что подрядчик не может отправить ждущих программистов в неоплачиваемый отпуск — они уволятся.
Как это сделать: владелец продукта должен найти команду или владельца системы, с которой предстоит интегрироваться. Для S7 мы провели интеграции с 20 различными системами, и, как сказал их владелец продукта, иногда найти ответственных за эти системы было очень сложно.
Но даже если вы нашли владельца системы, вам все еще предстоит найти её разработчиков. Потому что человек, принимающий решения о том, что должно быть в системе, — не тот, кто будет это реализовывать на практике.
Когда вы нашли команду разработчиков разных систем для интеграций, начните с описания бизнес-потребности, избегая технических терминов, чтобы все было понятно.
Чем подробнее вы обсудите эти детали, тем яснее станет картина. Иногда у системы уже есть готовые решения для таких запросов, которые уже использовались, и тогда часть проблем сразу отпадает, а сроки разработки сокращаются.
Это нужно, потому что в веб-сервисах может не хватить информации для создания вашего будущего проекта, а это случается очень часто.
Как получить: Подойдите к этому вопросу с позиции бизнес-процесса: как данные появляются, как они обновляются, в какие моменты могут измениться или исчезнуть, какие есть исключения и особенности.
Чем глубже вы погрузитесь в логику данных, тем проще будет формулировать требования для разработчиков и описывать тест-кейсы. Это также поможет избежать множества возвратов задачи на доработку после тестирования.
Если инфы нет: Если есть проблемы с текущим источником, можно поискать альтернативные. А если нет документации у смежных систем, иногда приходится садится и писать ее вместе с разработчиками самостоятельно.
Мы должны узнать, есть ли у команды тестовое окружение, готовы ли они выделить нам специалистов для проверки, или, возможно, они предоставят доступ к своей тестовой базе, чтобы мы могли проверять интеграцию самостоятельно.
На одном из предыдущих проектов в S7 не создавали новую интеграцию, а рефакторили уже существующую. Перед выпуском они проверили, что все работает на их стороне, смежники проверили у себя — казалось, все в порядке. Но после выхода в продакшн некоторым пользователям из-за сбоя начислили по несколько тысяч миль, а это убытки для компании
В компании это быстро заметили и откатили изменения, но урок в том, что важно заранее продумать и согласовать процесс тестирования, а лучше прогнать его вместе с командой смежников.
Это нужно, чтобы обезопасить конфиденциальность данных пользователей.
Пример: Если у вас есть онлайн-магазин игрушек, для вас тестовая среда не критична. Но если вы разрабатываете программное обеспечение, которое знает информацию обо всех пассажирах самолета, вопрос безопасности супер важен, особенно это актуально в финансовых системах.
Вот представьте, если утечет база данных ВИЧ-инфицированных, а злоумышленники воспользуются этим и начнут распространять это третьим лицам. Эти люди могут сильно пострадать.
Но обеспечить полную конфиденциальность в интересах самого подрядчика. Я — руководитель организации, и у меня везде в контрактах прописано: «Валера, если что-то от нас утечет, ты будешь нашим рабом до конца жизни».
Что делать: Когда мы получаем доступ к данным, важно заранее определить, как мы будем их хранить и использовать. После разработки API-интерфейсов нужно убедиться, что вы предоставили всю необходимую документацию с четкими требованиями и инструкциями по работе с данными.
Как продакт-менеджер, я должен проверить два момента: во-первых, чтобы разработчикам не присылали лишние данные, и во-вторых, чтобы все необходимые данные были на месте. Бывает, подрядчику предоставляют API, но в нем содержится только половина нужной информации. В итоге заказчик уверен, что всё нужное прописано, а разработчики остаются без полного набора данных для работы.
Даже если вы дали документацию на REST API или WebSocket-сервисы, предоставьте сопутствующую документацию, где объясняется терминология компании или специфического бизнеса.
Пример: в авиаперевозках есть термин deadhead (англ. «мертвая голова»), и это совсем не труп, а вполне живой человек, но он не является ни пассажиром, ни работающим членом экипажа, поэтому такое название.
Без сопутствующей документации разработчик бы потратил кучу времени поиск условий для хранения этой deadhead. Или возьмем наш другой кейс. В РЖД, например, вся внутренняя коммуникация строится на сокращениях и без сопутствующей документации в этом не разобраться. И вам не помогут ни хороший бизнес-аналитик, ни чат GPT.
Все эти нюансы нужно помочь понять разработчикам, иначе процесс работы затянется.
Проконтролируйте, чтобы команда разработчиков вашего нового продукта наладила коммуникацию со службой безопасности.
Почему это важно: В большинстве случаев невысокая скорость разработки связана именно с требованиеями службы безопасности. Подрядчик должен узнать, какие у них требования.
Пример: Разработчики могут написать огромную систему с использованием MVC, а потом окажется, что каждый метод контроллера должен логировать действия пользователя. И если они использовали фреймворк, ничего страшного, но самописными решениями могут быть огромные проблемы
Если вы продакт, системный аналитик или просто руководитель направления, важно знать, какие интеграции будут и в зависимости от этого выбрать правильный язык программирования.
Часто это решение доверяют разработчикам даже в компаниях с большим архитектурным комитетом. Но важно понимать, что есть асинхронные языки и есть синхронные. Разница между ними в том, что синхронные языки в большинстве случаев выполняют операции последовательно.
Например, пришел пользователь, и синхронный язык сначала его идентифицирует, затем выясняет, какие у него есть доступы, и наконец, завершает операцию. То есть идет последовательное выполнение всех операций, скрипты выполняются друг за другом.
Асинхронные языки работают иначе: пользователь приходит, и асинхронный язык одновременно выясняет, кто это, какие у него уровни доступа, и что ему нужно предоставить. Даже в моем объяснении уже ясно, что асинхронные языки программирования ускоряют обработку запроса в минимум в три раза.
Если вы выбираете асинхронный режим программирования, вам подойдут Java, Go, TypeScript,.NET.
Если это интеграция с какой-то одной 1С-кой, которая хранит себе информацию о товарах и не требует в режиме реального времени получения актуальных данных, нам вполне подойдет синхронный режим взаимодействия и такие языки, как PHP, Python.
Если вы разрабатываете real-time-систему, например, это может быть финансовый продукт, биржевой продукт, банковский продукт или онлайн-чат, вам нужно понять это заранее.
Вы должны сами догадаться, что если заказчику нужен чат и получение каких-то биржевых котировок, то с помощью Rest API-сервисов вы этого не сделаете. Примерно через 10 тысяч пользователей продукту уже не хватит физических серверов, чтобы обслуживать все запросы. Это надо понимать. Поэтому всегда задаем вопрос заказчику на этапе аналитики: есть ли необходимость real-time взаимодействия.
Но это платформа, где люди торгуются и должны в режиме реального времени получать информацию, что их ставки перебили. Что здесь нужно? Правильно, WebSocket, а не Rest API-сервис.
Первое — пытаемся понять, сколько всего будет интеграций. Затем выясняем, если ли у этих систем апишки. Если да — круто, работаем дальше. Если нет, просим владельцев этих систем их разработать. Далее просим документацию на эти системы, чтобы все-все нужное для проекта было прописано. И не забываем про сопутствующую документацию — она поможет понять специфику бизнеса и процессов в компании: значения сокращений, странных наименований — вы поняли.
Спросите, есть ли среда с обезличенными данными и подружите подрядчика со службой безопасности, чтобы программисты учитывали все их требования. И не забудьте разобраться в синхронных и асинхронных языках программирования — ну так, на всякий случай.
Более подробно об интеграциях мы поговорили с Ольгой Лукьяновой — владельцем мобильного приложения для бортпроводников» S7 Airlines. Вспомнили, какие есть еще нюансы и обсудили, что делать в проблемных ситуациях.
Все
Технологии
Ликбез
Места
HowTo
Стартапы
Новости
Сервисы
Приложения
