Судя по материалам раздела непрерывная разработка обеспечивается в том числе за счет нарезки работ по разработке системы на маленькие части.
Тут сразу возникают вопросы по каким принципам надо нарезать, и насколько мелко. Например, чтобы не замучится потом во время интеграции этих маленьких частей.
При разработке проектов строительства есть устоявшаяся схема разбивки на разделы, которые в свою очередь могут разбиваться на подразделы, которыми занимаются отдельные роли.
С разбиением на инкременты чуть сложнее, но тут скорее вопрос не в разработке, а в регулировании, которое подразумевает получение всевозможных разрешений поэтапно.
Сложность магистральной разработки ОКС заключается в том, что в 2D-чертежах, проверку на интеграционные ошибки очень сложно автоматизировать, а 3D-модели до сих пор “поднимаются” - то есть сначала проектировщики делают чертежи, а потом моделеры по этим чертежам поднимают модель, и чаще всего чертежи успевают измениться за то время, которое уходит на подъем моделей.
Если идти по цепочке создания, то для формирования команды, которая будет заниматься проектированием (или в нашем случае проектным сопровождением), инкрементальная разработка будет полезной, тут главное разобраться как управлять этими постоянно вводимыми изменениями.
Сложности “бюджетной” стройки
Мне видится основной проблемой - отсутствие или слабая коммуникация между участниками проекта: решение о запуске проекта принимают одни люди, деньги на проект выделяют другие, пользоваться объектом будут третьи, и обслуживать ещё кто-то. При этом участники разделены этапами работы. Такое ощущение, что тут цепочка будет даже по длиннее, чем при инженерии требований.
Если в курсе речь о том, что нужно постоянно держать руку на пульсе, чтобы отслеживать постоянно меняющиеся потребности и условия, то у нас по факту оказывается, что никто не знает что именно надо, для какой цели. Иногда мне кажется, что вообще нет исполнителя, который принимает ответственные решения.
Так что у нас даже не ошибки в постановке задачи, у нас сначала надо найти того, кто отвечает за постановку задачи и что там действительно надо запроектировать и построить.
Так как у нас не инвестор, а распорядитель бюджета, то у нас сразу провал в части где польза от эксплуатации строительство объекта должна быть больше, чем ресурсы потраченные на проектирование и стройку. Не могу найти в нашем проекте роль, которая представляет эти интересы.
Чтобы понять, что нам делать в рамках своей услуги, пишем отдельное задание, в котором на основе не очень внятного ТЗ пытаемся сформулировать свои задачи. Из хорошего - получилось донести, что наше задание будет постоянно дополняться и уточняться, команда (даже юристы) с этим согласилась.
В дальнейшем хотелось опираться на концепции использования, но пока хотя бы так.
Проектное сопровождение
Ключевая идея нашей новой услуги как раз заключается в “сдвиге влево”. То есть смотрим не готовый проект (экспертиза проектной документации), а рассматриваем информационные контейнеры (инкременты) по ходу разработки проекта. При этом смотрим проверяем, что разработанные решения должны быть безопасными. То есть работаем только с одной характеристикой. При этом осуществляет надзор за проектировщиком, но схема воздействия какая-то очень сложная.
Как мне кажется это один из вариантов дальнейшего развития услуги: брать на себя функции архитектора - организовывать проектировщиков, принимать архитектурные решения не только в части безопасности.