Отчуждаемый IT-контур: признаки

Так выглядит неотчуждаемый контур

• Каждый разработчик на вес золота и обладает уникальным и непередаваемым набором знаний по проекту. Отпуск, увольнение, смена пула задач каждого разработчика становится проблемой для нормальной работы по проекту.
• Все сервисы или микросервисы, задействованные в проекте, сильно связаны. Ошибки или перегрузки в любом из них блокируют работу всех сервисов.
• Передача дел между менеджерами проектов — долгий и неочевидный процесс. Даже если есть технология передачи, она меняется от проекта к проекту. Новый менеджер проекта некоторое время продолжает задавать вопросы предшественнику (если это возможно).
• Архитектура монолитная, даже если выглядит как сервисная или микросервисная. Все элементы сильно связаны.
• Продакт-оунеры остаются частично или полностью блокирующими друг для друга при формировании списка задач. Для утверждения задач приходится «играть в политику» и совместно корректировать приоритеты.
• Point-to-point интеграции между сервисами написаны кодом и нуждаются в постоянной поддержке разработчика.

А так — отчуждаемый контур

• Легко добавить и убрать разработчика из проекта.
• Ошибка реализации в одной части бизнес-процесса не влияет на скорость изменения в других бизнес-процессах.
• Легко поставить нового менеджера проекта за счёт простоты каждого из проектов.
• Архитектура состоит из большого количества небольших сервисов.
• Продукт-оунеры и руководители департаментов могут управлять своим списком задач независимо от списка задач других.
• Интеграции между сервисами используют low-code или no-code инструменты интеграции (ESB, iPaaS)

Если вы построили отчуждаемый IT-контур, то:

• Вы всегда понимаете, что происходит с проектом.
• Вы формируете команду НЕ на основе того, кто в курсе «внутренностей» проекта, а исходя из своих управленческих задач.
• Вы независимы от конкретного исполнителя или подрядчика.
• Замену и модернизацию любого сервиса можно произвести в любой момент.

‍