Третий не лишний

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

Исходные данные:

• Есть Заказчик, у которого есть две информационные системы. Эти две системы должны быть синтегрированы друг с другом. Заказчик – просто мечта: он знает абсолютно точно, что он хочет получить, и готов за это заплатить.
• Есть Подрядчик №1, который устанавливает, настраивает первую систему Заказчика. Подрядчик №1 - профессионал, знаток своего дела, выполняет свою работу качественно и в срок.
• Есть Подрядчик №2, который тоже даже очень ничего и занимается второй системой Заказчика.

Что на выходе:

• Сроки интеграции сорваны безнадежно.
• Заказчик весь в расстроенных чувствах и питает лютую ненависть к обоим Подрядчикам.
• Два замученных подрядчика, которые потратили в 2 раза больше запланированного времени и не раз уже пожалели, что ввязались во всю эту историю.

Вопрос:

• Как же это все получилось?

Как же это все получилось?

• Заказчик согласовал требования с каждым из Подрячиков.
• Подрядчик №1 сделал свои работы исправно и в срок. Подрядчик №1 ожидает слов благодарности от Заказчика за сделанную работу, подписанный акт и вознаграждение.
• Подрядчик №2 - аналогично Подрядчику №1
• В день запуска интеграции выясняется, что ничего не работает. Подрядчик №1 заверяет, что у него все сделано согласно оговоренным требованиям, показывает исправную работу в своей системе, показывает логи и вообще говорит очень убедительно, впрочем ни Заказчик, ни Подрядчик №2 особо всем этим не интересуются, так как мало, что понимают во внутренней кухне первой системы.
• Подрядчик №2 – аналогично Подрядчику №1
• Заказчик разводит руки и самоустраняется со словами: «ребят, ну вы там сами разберитесь, кто там что делает не так. Желательно к завтрашнему дню».
• Проходит первый день. Проходит второй... Проходит какой-то еще день. Наконец, с горем пополам, но все заработало.

Почему это происходит?

• Когда делается интеграция между двумя системами – это не два самостоятельных проекта, а... три: проект по подготовке к интеграции системы №1, аналогичный проекта по системе №2, непосредственно сам проект интеграции. Запуск интеграции – это отдельный самостоятельный проект. Как у любого другого проекта – у проекта интеграции должен быть свой руководитель проекта.
• Подрядчики не могут самостоятельно руководить проектом интеграции, у них нет никакого морального права заставлять друг друга что-либо делать, менять, дорабатывать в системе, они не очень понимают предметную область чужой системы, и не очень-то стремятся разбираться в ней. Подрядчики искренне считают, что их задача - исправно сделать свою часть интеграции, и это не их дело, что там работает или не работает в другой системе.
• Заказчик также не стремится с головой окунаться во внутреннее взаимодействие систем. Заказчик привык принимать работу у каждого из Подрядчиков по отдельности. Как правило, эти работы всегда можно было "пощупать" руками (увидеть новое окошко, нажать на новую кнопку), а тут какая-то интеграция, невидимая глазу.
• Нет возможности самостоятельно без Подрядчика-исполнителя проверить корректность выполнения им задачи по интеграции.
• Бывают непродуманные или даже ошибочные требования в технических заданиях на интеграцию (неточности могут быть в любом ТЗ, вероятность неточности в ТЗ на интеграцию в разы больше).

Как этого избежать?

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

Оговорюсь, что вся эта история неактуальна:

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