Третий не лишний
В этой статье я расскажу о проблеме, с которой хоть не часто, но все же регулярно год из года сталкиваюсь.
Исходные данные:
- Есть Заказчик, у которого есть две информационные системы. Эти две системы должны быть синтегрированы друг с другом. Заказчик – просто мечта: он знает абсолютно точно, что он хочет получить, и готов за это заплатить.
- Есть Подрядчик №1, который устанавливает, настраивает первую систему Заказчика. Подрядчик №1 - профессионал, знаток своего дела, выполняет свою работу качественно и в срок.
- Есть Подрядчик №2, который тоже даже очень ничего и занимается второй системой Заказчика.
Что на выходе:
- Сроки интеграции сорваны безнадежно.
- Заказчик весь в расстроенных чувствах и питает лютую ненависть к обоим Подрядчикам.
- Два замученных подрядчика, которые потратили в 2 раза больше запланированного времени и не раз уже пожалели, что ввязались во всю эту историю.
Вопрос:
- Как же это все получилось?
Как же это все получилось?
- Заказчик согласовал требования с каждым из Подрячиков.
- Подрядчик №1 сделал свои работы исправно и в срок. Подрядчик №1 ожидает слов благодарности от Заказчика за сделанную работу, подписанный акт и вознаграждение.
- Подрядчик №2 - аналогично Подрядчику №1
- В день запуска интеграции выясняется, что ничего не работает. Подрядчик №1 заверяет, что у него все сделано согласно оговоренным требованиям, показывает исправную работу в своей системе, показывает логи и вообще говорит очень убедительно, впрочем ни Заказчик, ни Подрядчик №2 особо всем этим не интересуются, так как мало, что понимают во внутренней кухне первой системы.
- Подрядчик №2 – аналогично Подрядчику №1
- Заказчик разводит руки и самоустраняется со словами: «ребят, ну вы там сами разберитесь, кто там что делает не так. Желательно к завтрашнему дню».
- Проходит первый день. Проходит второй... Проходит какой-то еще день. Наконец, с горем пополам, но все заработало.
Почему это происходит?
- Когда делается интеграция между двумя системами – это не два самостоятельных проекта, а... три: проект по подготовке к интеграции системы №1, аналогичный проекта по системе №2, непосредственно сам проект интеграции. Запуск интеграции – это отдельный самостоятельный проект. Как у любого другого проекта – у проекта интеграции должен быть свой руководитель проекта.
- Подрядчики не могут самостоятельно руководить проектом интеграции, у них нет никакого морального права заставлять друг друга что-либо делать, менять, дорабатывать в системе, они не очень понимают предметную область чужой системы, и не очень-то стремятся разбираться в ней. Подрядчики искренне считают, что их задача - исправно сделать свою часть интеграции, и это не их дело, что там работает или не работает в другой системе.
- Заказчик также не стремится с головой окунаться во внутреннее взаимодействие систем. Заказчик привык принимать работу у каждого из Подрядчиков по отдельности. Как правило, эти работы всегда можно было "пощупать" руками (увидеть новое окошко, нажать на новую кнопку), а тут какая-то интеграция, невидимая глазу.
- Нет возможности самостоятельно без Подрядчика-исполнителя проверить корректность выполнения им задачи по интеграции.
- Бывают непродуманные или даже ошибочные требования в технических заданиях на интеграцию (неточности могут быть в любом ТЗ, вероятность неточности в ТЗ на интеграцию в разы больше).
Как этого избежать?
Все очень просто - должен быть один ответственный, который будет отвечать за запуск интеграции. Этот человек, должен быть:- мотивирован на запуск интеграции (и желательно на запуск к вполне определенному сроку)
- у него должно быть право оказывать влияние на подрядчиков: запрашивать логи, просить о проведении дополнительных тестов, запрашивать корректировки в работе
- у него должна быть возможность проверить корректность работы каждой из систем по отдельности и самостоятельно
- у него должно быть выделенное время на занятие этой интеграции
Оговорюсь, что вся эта история неактуальна:
- если работы по интеграции крайне простые
- если для интеграции нужны корректировки только в одной системе, а в другой системе гарантировано не требуется никаких доработок
- одну из систем Заказчик поддерживает и дорабатывает своими силами