Потому что только нач эксплуатации может двигать сейчас это направление, чтоб оно смогло сформироваться в какую то боевую единицу) да и эксплуатация на самом деле у нас там же, где и разработчики (один босс)

В общем у нас оч специфическая структура, так что логики искать в ней не нужно)

Это эксперимент, как оно вообще впишется у нас

мне кажется "пайплайн" отличное слово само по себе

Трубопровод вот правильное слово

покрытие замеряете?

Не доросли )

А вот на ИС @DitriXNew говорил что это самое важное ) задумайся )

Будем есть слона по частям )

С бивней не начните, их сложно грызть

Самое важное это хотя бы начать двигаться в нужную сторону) а остальное уже детали.

Правильно. Потому что я привык, что все врут :)
Тестировщик врет, програмист врет, а тестировщик-программист - врет втройне.
Вопрос - как контролировать их?
Вот на этот вопрос покрытие и отвечает. Пусть и не на 100%, но лабуду пропустить точно не даст

Централизующий аналитик, который держит в голове примерный  прогноз укрупненных тасков на полгода вперед.

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

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

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

Функциональный архитектор, ага

Как ни назови)

Ща как Лустина призовете - он все на места расставит)

Повезло работать на проекте с таким. Это прям маст хэв при активной разработке

Жаль, что ушла :(

Имхо, это маст хев даже в компании, где вообще нет ИТ.

Это базовая задача специальности "бизнес аналитик". Жаль, что вместо этого людей на рынке учат типовым коробкам

Одно дело бизнес аналитик по блоку. Другое дело по системе целиком)