В холдинге «Актион-МЦФЭР» существует несколько крупных линеек интернет-продуктов. Это так называемые профильные сайты (самый яркий пример: www.glavbukh.ru), электронные журналы (например, e.glavbukh.ru) и справочные системы (например, www.1gl.ru).
Так исторически сложилось, что каждая из этих линеек разрабатывается на своих технологиях, разными командами, по разным процессам. Одна из команд даже в отдельном от остальных офисе сидит.
Но в последнее время все чаще возникают задачи по интеграции систем из разных линеек.
В простейшем случае – для обмена контентом. В чуть более сложном – на одних сайтах использовать функционал других. Или в совсем сложном – интегрировать самостоятельные системы аутентификации и авторизации, чтобы на любом сайте холдинга Пользователь мог находиться со своей родной учеткой, независимо от того, где он ее получил. Но при этом все равно оставить системы аутентификации и авторизации раздельными, так как за многие годы самобытного развития они обросли гигантским объемом функционала, интегрировать который, во-первых, видится слишком дорогим, а во-вторых, не очень-то и нужно.
Работая над такими задачами, команды разработки постоянно сталкиваются с новыми для себя вызовами.
Одно, когда продукт делается одним разработчиком или очень маленькой (2–3 человека) командой. Легко ездить на автомобиле по пустому аэродрому.
Совсем другое, когда в интеграционную задачу вовлечено сразу 2–3 команды, и количество непосредственно занятых на задаче участников (разработчиков, тестировщиков, менеджеров) возрастает до 5–8. Вместо пустого аэродрома мы оказываемся в оживленном трафике крупного города, и для вождения автомобиля нужно уже гораздо больше навыков.
Чему мы учимся, работая на интеграционных проектах:
- Работа над задачей должна планироваться совместно участниками всех команд. Ну или хотя бы менеджерами от каждой команды. Минимум, о чем нужно договориться на старте, – это ключевые вехи совместного проекта.
- Если команды не набрали достаточного опыта совместной работы, для мало-мальски сложной задачи нужно обязательно выделять фазу проектирования. Во время нее команды должны решить как инфраструктурные вопросы (адреса сервисов, интерфейсы, протоколы и т. д.), так и договориться о водоразделах: изолировать модули, разграничить зоны ответственности. Рисовать ли при этом диаграммы или ограничиться словесными описаниями – зависит от традиций и привычек каждой команды.
- Отдельно проговаривается предсказуемая работа (или предсказуемая неработа) функционала в случае, если отвалилась любая из точек интеграции.
- Команды могут жить по своим расписаниям, в разные сроки внедрять системы в продакшен. Необходимо явно определить, кто, кого и где ждет. Ждущая сторона должна озаботиться необходимым набором заглушек на время ожидания.
- Тестирование. Неправильно, когда каждая команда тестирует только свой кусок. Обязательно должны быть тесты на полный сценарий, задействующий всех участников.
- Совместный разбор проблем. Команды должны заранее договориться, к кому первому идет заказчик, когда у него что-то не работает, и по какой цепочке выполняются дальнейшие проверки. Заявить «проблема не на моей стороне» в этой ситуации мало. Это нужно еще и доказать.
Ну и наконец, иногда случается, что для какого-то суперкритичного сценария использования правильнее разработать функционал самостоятельно. Даже если у соседа уже есть почти такой же.