функционирования самих создаваемых ИТ-решений.
Как уже отмечалось, идеология развития программного обеспечения с открытым исходным кодом, создания решений на его основе позволили существенно увеличить цепочки разделения труда в сфере ИТ, что обеспечило кардинальное повышение эффективности реализации новых информационных систем. При этом при увеличении степени разделения труда растут риски отдельных участников цепочки, которые зависят от все большего числа поставщиков и потребителей. Данная тенденция характерна и для ИТ. Представим себе ситуацию, что информационную систему А разрабатывает команда из 100 человек. Но эти 100 человек не работают в одном офисе, выполняя заранее согласованные и спланированные блоки работ. Коллектив разбит на 10 команд по 10 специалистов, при этом каждая команда создает свой собственный блок функционала. Между блоками присутствуют зависимости как интеграционного (взаимодействие в рамках процессов обменов информацией), так и встраиваемого характера. Под последним традиционно понимается возможность включения результатов работы одной команды в рабочие блоки, создаваемые другой командой, в формате библиотеки. Современные технологии в части ИТ позволяют проводить тестирование функционала с помощью механизма «заглушек», эмулирующих функционал контрагентов, но указанный способ тестирования имеет известные пределы. Пример описываемой ситуации представлен на Рисунке 12.
Компоненты на Рисунке 12 показаны обезличено, чтобы не дополнять сложность распределенной структуры команды разработки сложностью предметной области. При этом Рисунок 12 является наглядной иллюстрацией растущих рисков каждой команды, участвующей в процессе разработки программного обеспечения, в рамках распределенной структуры, а также всего создаваемого решения: неготовность каждого блока функционала ставит под угрозу возможность изготовления всех блоков, с ним связанных, что в свою очередь отражается на реализации всего программного комплекса. Отметим, что принудительная синхронизация всех блоков работ между собой может привести к лавинообразному росту числа непроизводительных управленческих задач. Последнее прямо противоречит идеологии гибкой разработки, формулируемой в соответствии с манифестом Agile.
Рисунок 12. Распределенная команда разработки программного обеспечения
Решение представленной проблемы лежит не в плоскости управления, а в плоскости архитектуры. Конечно, возможно построить дорожную карту реализации всех компонентов, осуществлять контроль всех сроков исполнения, учитывая результаты итераций разработки, а также получаемую обратную связь от пользователей. Но указанный подход в последние годы получил негативную смысловую окраску, заслужив присвоение ему термина «микроменеджмент». Кроме того, подобный подход исключает возможность работы самоорганизующихся команд, противореча
