Это может быть кто угодно, от тимлида разработки, до директора

Надо вам организовывать управление релизами и изменениями.

да, примерно это и пытаются сейчас вроде сделать, но я уже не там)

идея витала в воздухе и предлагалась не раз, но так и не была реализована длительное время

Понимаю вас, Анастасия.. а ещё когда доработку можно реализовать в нескольких системах, начинается весёлый процесс перекидывания задачи из команды в команду.

Есть мнение, что такие процессы не аналитик должен выстраивать. а если он за это берется, то он должен обладать соответствующем знананием

И полномочиями

Само собой)

Есть такое понятие Software product line. На Secr-е был коротенький доклад по нему. Когда продуктов много, а части у них общие, то начинают делать разработку не по продуктам, а по модулям, а потом из модулей собирать продукты.

Если для одного продукта нужно изменение какого-то модуля, то нужно отследить, чтобы это изменение не повлияло на другие продукты, содержащие эти модули

За этим кто-то должен следить. Хорошо, когда аналитики есть и на каждый продукт и на каждый модуль. И еще координирует их кто-то

У Касперского, насколько я понимаю, похожая структура. Можно их спросить, как они справляются.

Если я верно понял, то в нашей организации в ближайшие месяцы запланирован переход на нее. Правда, в презентации концепта, она называлась платформенная разработка.

Не совсем. Я спрашивала у Иры. У них продукты независимы друг от друга.

Они же вроде на какие-то базовые сервисы завязаны. И изменение сервиса влияет на все продукты. А требования по изменениям от продуктов могут прийти

Хотел тоже Иру попытать про это, но забыл

Надо сюда призвать Иру :)

Доброе утро, коллеги. Хорошего понедельника и недели всем.

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

>количество версий модулей уже подбирается к двум тысячам.

жесть ((