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

Сегодня мы поделимся тем, как мы организуем работу после утверждения ТЗ, и раскроем каждый этап, чтобы вы понимали, что происходит «за кулисами» разработки.

1. Планирование и запуск проекта

После того как ТЗ подписано и утверждено, мы формируем рабочую группу: разработчики, тестировщики (QA), проектный менеджер, аналитик.

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

На этом этапе мы:

  • Определяем общий график проекта.

  • Разбиваем его на спринты — короткие рабочие циклы по 1–2 недели.

  • Фиксируем приоритеты задач: что нужно сделать в первую очередь, что можно отложить на потом.

2. Разработка и сборка функционала

Когда план готов, команда приступает к написанию кода.

Разработчики работают по задачам, зафиксированным в ТЗ и разбитым по спринтам.

Что делаем на этом этапе:

  • Настраиваем архитектуру, чтобы решение было масштабируемым и легко дорабатывалось в будущем.

  • Настраиваем интеграцию с внешними системами (через API, webhooks, SDK).

  • Реализуем внутренние модули CRM, которые обрабатывают и хранят данные.

  • Разрабатываем и реализуем дружелюбный для пользователя интерфейс, если он необходим.

  • Пишем скрипты для автоматизации процессов (например, автоматическая отправка писем или уведомлений).

Пример:В интеграции с amoCRM и API банка мы настраиваем так, чтобы система «понимала» каждый ответ от банка и обновляла карточки сделок без участия менеджера.

3. Документирование кода

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

Зачем это нужно:

  • Любой разработчик, подключившийся к проекту в будущем, сможет быстро разобраться в коде.

  • У клиента будет понятная инструкция для обслуживания и масштабирования решения.

4. Внутреннее тестирование

Как только блок кода готов, он отправляется на тестирование. Здесь проверяем:

  • Работает ли функционал так, как описано в ТЗ.

  • Корректно ли система обрабатывает нестандартные сценарии.

  • Есть ли ошибки при обмене данными между системами.

Методы тестирования:

  • Функциональное тестирование — это проверка того, что система выполняет именно те задачи, для которых она предназначена.

  • Нагрузочное тестирование — чтобы убедиться, что система выдержит реальную нагрузку.

  • Интеграционное тестирование — проверка взаимодействия всех модулей.

5. Пилотный запуск

Когда решение проходит внутренние тесты, мы переносим его в тестовую среду клиента.

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

  • Смотрим, как решение ведёт себя в окружении клиента.

  • Исправляем мелкие баги, которые могли остаться незамеченными в лабораторных условиях.

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

6. Боевой релиз

После пилотного тестирования и финальных правок мы переносим решение в рабочую среду.

Что делаем:

  • Подключаем к базам данных.

  • Проверяем каждый процесс в реальном времени.

  • Убеждаемся, что все интеграции отрабатывают корректно под нагрузкой.

7. Обучение и передача документации

Мы всегда проводим обучение команды клиента:

  • Проводим онлайн-сессии или личные встречи.

  • Записываем видеоинструкции.

  • Передаём документацию, чтобы команда могла самостоятельно обслуживать решение.

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

8. Поддержка и развитие

После релиза мы остаёмся на связи:

  • Мониторим работу интеграции в первые дни.

  • При необходимости устраняем неполадки.

  • Обсуждаем дальнейшее развитие и новые функции.

Часто после запуска у клиента появляются новые идеи, и мы начинаем новый цикл: анализ, ТЗ, разработка.

Заключение

Разработка интеграции — это не «быстро написать код». Это многоэтапный процесс, где каждый шаг важен для качества и надёжности результата.

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

ИнтеграцииРуководство