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

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

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

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

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

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

Вопрос:

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

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

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

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

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

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


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

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

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


© 2013 Ведисофт
Москва: +7 (499) 703-04-23
Екатеринбург: +7 (343) 236-60-96
Почта: info_at_vedisoft_dot_info