Как за 2 месяца разработать шлюз приема электронных данных

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

Состав команды: 

• 1 Team Lead.
• 2 Frontend Developers.
• 2 Backend Developers.
• 1 DBA.

Реализация

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

• Отсутствие данных для транзита из-за единовременного старта работ.

Работа над проектом началась одновременно по трем фронтам: БД, backend и frontend. Когда backend- и frontend-разработчики входят в проект последовательно, последние сразу могут приступить к работе над транзитом данных. Здесь же Java-программистам, отвечающим за транзит данных на уровень UI, передавать было нечего.

Решение: Java-программистам в контроллерах приходилось создавать фейковые данные, чтобы UI-программисты могли начать работать. В дальнейшем по мере того как в базе создавались реальные сущности, в Java дописывались контроллеры, и затем UI становился реальным.

• Синхронизация баз данных.

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

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

• Координация работ с учетом других сервисов.

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

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

• Сжатые сроки.

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

Решение: вся команда состояла из опытных разработчиков middle+. Когда работы ведутся не последовательно, а параллельно сразу по нескольким направлениям, ежедневно появляются новые данные, возникают нестыковки. Для успешной реализации работ мы выбрали проактивную позицию в коммуникации с крупным интегратором и другими проектными командами. Режим работы 24/7, ежедневные разноуровневые конференц-коллы, четкая синхронизация действий позволили нам сдать работы в срок.