Депеши, карточки и паранойя: как мы совмещали Waterfall и Agile в проекте для РЖД. Часть вторая
Переходим к продукту
В первой части я рассказывал о юридической конструкции проекта, защите команды и попытке внедрить гибкие практики в среду, где формально всё должно было идти по Waterfall. Теперь - о самом продукте, его архитектуре, интеграциях и ежедневной борьбе с ограничениями большой корпоративной системы.
Проект задумывался как полноценная цифровая экосистема для пассажиров. Не отдельное приложение с расписанием и билетами, а единый сервис, объединяющий развлечения, навигацию, покупки, питание, справочную информацию и программы лояльности.
На презентациях это выглядело как цифровой космолёт. На практике же нам предстояло собрать его поверх сложной легаси-инфраструктуры, связать десятки компонентов, договориться с несколькими командами и обеспечить стабильную работу в условиях ограниченного доступа к внутренним системам.
Сразу оговорюсь: описываемые события относятся к периоду 2019-2020 годов и основаны на личном опыте автора. Названия организаций, брендов, технические параметры и отдельные детали изменены или обезличены. Материал отражает частное мнение и не претендует на оценку деятельности конкретных компаний.
Что должно было оказаться в "проде"
Первоначальный перечень возможностей впечатлял даже людей, привыкших к крупным интеграционным проектам. В состав решения планировалось включить:
- видеотеку с фильмами и сериалами;
- музыку, подкасты и аудиокниги;
- электронную библиотеку;
- партнёрские текстовые материалы;
- покупку билетов;
- трёхмерные туры по вагонам;
- выбор конкретного места в салоне;
- заказ еды из вагона-ресторана;
- уведомления для сотрудников кухни;
- маркетплейс с товарами партнёров;
- доставку заказа на платформу или в гостиницу;
- карту движения поезда в реальном времени;
- аудиогид;
- рекламную платформу;
- личный кабинет пассажира;
- программу лояльности;
- справочный центр;
- идентификацию пользователя при подключении к бортовой сети.
Каждый пункт сам по себе мог стать отдельным продуктом. Но здесь всё требовалось объединить под одной оболочкой, с общим пользовательским сценарием, единой авторизацией и согласованными правилами обмена данными.
Особую сложность представляла работа в поезде. Пользователь мог находиться в зоне нестабильного соединения, а часть сервисов должна была функционировать даже при ограниченном доступе к внешней сети. Поэтому обычная модель "мобильное приложение обращается к облачному API" здесь не подходила. Нужно было учитывать бортовую инфраструктуру, локальное кэширование, синхронизацию и временную недоступность отдельных систем.
Архитектура и распределённая ответственность
Под капотом находился не один монолит, а набор сервисов, принадлежащих разным владельцам. Одни системы отвечали за билеты, другие - за пассажирские данные, третьи - за контент, четвёртые - за оплату и партнёрские предложения.
Главная проблема заключалась не в количестве компонентов как таковом. Сложность возникала на стыках между ними. Каждая команда использовала собственные форматы данных, правила авторизации, сроки выпуска и подходы к обработке ошибок.
Где-то API проектировался как стабильный контракт. Где-то документация существовала только в виде старых схем и переписки. В некоторых случаях интеграторам приходилось восстанавливать поведение системы экспериментальным путём: отправлять запрос, анализировать ответ, проверять пограничные сценарии и фиксировать фактическое поведение.
Для пассажира всё должно было выглядеть просто: открыть сервис, выбрать нужную функцию и получить результат. Для команды это означало десятки внутренних проверок - доступен ли поезд, подтверждён ли пользователь, есть ли свободное место, разрешена ли продажа, прошла ли оплата, можно ли доставить заказ и что делать, если один из компонентов временно не отвечает.
Почему API стало отдельной задачей
В идеальном проекте API описывается заранее, согласуется между командами, покрывается тестами и затем меняется только по понятной процедуре. В реальности мы часто получали промежуточные версии контрактов, которые продолжали уточняться уже во время разработки.
Это создавало каскадные последствия. Изменение одного поля могло повлиять на мобильный клиент, серверную часть, систему аналитики, тестовые стенды и документацию. Если обязательное поле неожиданно становилось необязательным, ломалась логика валидации. Если менялся формат даты или код ошибки, начинали расходиться ожидания разных команд.
Мы старались разделять контракт и реализацию. Для каждого метода фиксировали назначение, параметры, типы данных, возможные ответы и сценарии ошибок. Отдельно описывали идемпотентность операций, правила повторной отправки запросов и поведение при частичной недоступности систем.
Особенно важными оказались негативные сценарии. Пользователь может дважды нажать кнопку оплаты, поезд может потерять связь, билет может оказаться уже забронированным, а сервис партнёра - вернуть техническую ошибку. Если заранее не договориться о таких ситуациях, команда неизбежно будет принимать решения прямо во время инцидента.
Сторонние сервисы и эффект домино
В проекте использовались внешние поставщики контента, платёжные решения, картографические данные, сервисы уведомлений и партнёрские каталоги. Каждый такой компонент добавлял функциональность, но одновременно увеличивал количество точек отказа.
У внешних поставщиков были собственные графики релизов, ограничения по нагрузке и требования к безопасности. Нельзя было просто попросить изменить API к нужной дате. Иногда приходилось адаптировать свою архитектуру, добавлять промежуточный слой или реализовывать временное решение.
Для защиты от нестабильности применялись тайм-ауты, повторные запросы с ограничением количества попыток, кэширование и circuit breaker-подход. Ошибка внешнего сервиса не должна была превращаться в падение всей платформы. Если недоступна карта, пользователь всё равно должен иметь возможность открыть билет. Если временно не загружается каталог товаров, это не должно блокировать просмотр справочной информации.
Как Agile ехал по рельсам Waterfall
Формально проект требовал последовательного прохождения этапов: требования, проектирование, разработка, тестирование, сдача. Но продукт с таким количеством неизвестных невозможно качественно создать без коротких циклов обратной связи.
Поэтому внутри формального Waterfall мы организовали собственный Agile-контур. Большие задачи разбивали на небольшие карточки, проводили короткие планирования, регулярно показывали промежуточный результат и отдельно обсуждали риски.
Такой подход позволял не спорить с методологией на уровне терминов. Внешне сохранялись необходимые документы и контрольные точки, а внутри команды работа шла итерационно. Мы не пытались переделать всю систему управления проектом - вместо этого создавали гибкость там, где она не противоречила обязательным процедурам.
Самым полезным инструментом стали ранние демонстрации. Если ждать полного завершения большого блока, ошибка в предположениях обнаружится слишком поздно. Рабочий прототип, показанный через несколько недель, позволял быстро понять, что именно нужно изменить.
Компромиссы внутри команды
Помимо технических сложностей, значительную роль играли различия между командами. У каждой стороны были собственные цели, метрики и представление о приоритетах. Разработчики думали о качестве и поддерживаемости, бизнес - о сроках и эффекте, интегратор - о выполнении договора, владельцы внутренних систем - о безопасности и контроле изменений.
В таких условиях задача руководителя или технического координатора состоит не только в распределении работ. Нужно переводить требования с языка одной стороны на язык другой, фиксировать договорённости и не позволять критичным вопросам растворяться в переписке.
Мы старались документировать решения сразу после встреч. У каждого спорного пункта должны были появиться ответственный, срок и критерий готовности. Это казалось бюрократией, но именно такие записи помогали разбирать конфликтные ситуации и не возвращаться к одним и тем же обсуждениям.
Безопасность и доступы
Отдельный пласт проблем был связан с доступом к тестовым средам и данным. Для проекта требовались реалистичные сценарии, но использовать настоящие персональные сведения было нельзя. Приходилось обезличивать данные, создавать тестовые профили и моделировать различные состояния пассажиров.
Важно было проверить не только успешный вход, но и попытки повторной авторизации, истечение сессии, смену устройства, потерю связи и обращение к данным другого пользователя. В интеграционной платформе уязвимость часто возникает не внутри одного сервиса, а на границе между ними.
Поэтому мы уделяли внимание минимальным правам, журналированию операций, разделению тестовых и рабочих контуров и контролю передачи данных между системами. Чем больше участников имеет доступ к процессу, тем важнее не только технические средства, но и понятная матрица ответственности.
Что успели сделать за восемь месяцев
За восемь месяцев удалось пройти значительную часть пути: согласовать ключевые сценарии, собрать интеграционный контур, подготовить основные пользовательские функции, настроить взаимодействие с партнёрскими сервисами и провести серию проверок на тестовых данных.
Не всё было доведено до окончательного запуска. Часть функций осталась в виде прототипов, некоторые интеграции требовали дополнительной стабилизации, а отдельные решения пришлось отложить из-за внешних ограничений.
Проект остановился не потому, что команда перестала работать или продукт оказался технически несостоятельным. В больших программах на результат влияют бюджет, изменения приоритетов, регуляторные требования, договорные обстоятельства и решения, которые находятся за пределами конкретной команды.
Десять правил интеграционных проектов
1. Фиксируйте договорённости письменно. Устные обещания не заменяют контракт и протокол решения.
2. Не ждите идеальной документации. Проверяйте фактическое поведение систем на тестовом контуре.
3. Прорабатывайте ошибки заранее. Успешный сценарий - только половина интеграции.
4. Разделяйте обязательное и желательное. Иначе проект утонет в бесконечном списке функций.
5. Показывайте результат как можно раньше. Ранний прототип дешевле поздней переделки.
6. Не связывайте все сервисы напрямую. Промежуточные слои снижают связанность и упрощают изменения.
7. Закладывайте нестабильность внешних систем. Тайм-ауты, повторные попытки и кэширование должны быть частью дизайна.
8. Держите единый словарь терминов. Одинаковые слова должны означать одинаковые сущности.
9. Отделяйте технические риски от организационных. Они требуют разных способов управления.
10. Сохраняйте фокус на пассажире. Даже сложная архитектура оценивается конечным пользовательским опытом.
Главный вывод оказался простым: гибкие практики можно применять даже в жёсткой корпоративной среде, если не превращать методологию в религию. Waterfall помогает управлять формальными обязательствами и контрольными точками, а Agile - справляться с неопределённостью внутри разработки.
Но ни один подход не заменит ясных контрактов, честной оценки рисков и способности команд договариваться. В интеграционных проектах побеждает не тот, кто написал больше кода, а тот, кто сумел связать разрозненные системы, интересы и ограничения в работающий пользовательский сценарий.
