Тим

Как правильно релизиться в больших компаниях?

То что ты описал указывает на слабое планирование. Должен быть менеджер проекта который организует процесс планирования в котором будет участвовать Продакт Овнер, Тимлиды всех групп и он сам. Результатом планирования должна получится диаграмма ганта или Roadmap в котором будут учитываться взаимосвязи и будут заложены адекватные риски. Я это делаю всегда, и у меня на проектах почти никогда не бывает таких вот блокеров как ты описываешь.

По поводу релизиться есть разные методики.
Версионность это хорошо если вы работаете через API, а если у вас несколько команд бекенда которые пилят один и тот же монолит то нужно внедрять практику GitFlow и ставить техлида который будет заниматься мержами веток в релизы и правильно построит адекватный GitFlow.

Версионность апи это отличная практика, ей нужно учиться и не слушать тех кто говорит что это сложно. Это не сложно. А версионность позволит релизить бекенд не дожидаясь фронтенд и не ломая его на продакшене.

Что бы релизы проходили плавно нужно погрузить себя в книжки по Continues Delivery и занятся докеризацией своих сервисов или монолита.

Назовите его хоть куском дерьма. Главное что бы внутри было то чего хочет ваш руководитель.

Что значит по должности?

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

Если в проекте нет маркетинг офицера либо ПМ выше его, то это провал. Любой продукт который нацелен на заработок средств управляется маркетингом.

Если ПМ со своей сворой профессионалов считает, что маркетинг предлагает глупые фичи то вся эта свора идет лесом, так как в 99% ситуаций у маркетинга идет проработка по бизнес моделям и все что они предлагают имплементировать это результат анализа, продумываний. Конечно с долей риска и шансами, но это хоть какой то анализ в отличии от частых рекомендаций команды исполнителя основываясь на вкусовщине.

Для версий использую Git.
Для задач Trello.
Для мониторинга кода и сборок использую Jenkins.
Время трекают в доку в гугл драйве.

Не люблю большие системы с прочей интеграцией. Полетит одно и заденет всё остальное.

Если минимально эффективную:
Менеджер-аналитик ― ресерчит, собирает требования, пишет доки, оформляет инфу в понятном для всех виде, проектирует интерфейсы, планирует работу в рамках бюджета и сроков, организовывает работу, занимается коммуникациями, контролирует ход работ, ищет замены, ведет связи с всеми за пределами команды.
Разработчик-тимлид-сисадмин ― определяет фреймворк, технологии, настраивает сервак, разворачивает проект, проектирует базу, пишет код, проверяет код других, верстает

далее больше,
просто-разработчик ― заходит на готовый, развернутый проект. читает доки, запускает все на локали, слушает морали от первых двух ролей, получает задачи на время, пилит, заливает, фиксит, верстает
фронтенд-разработчик ― верстает дизайн, отдает кодерам, тянет проект локально, фиксит стили и все что едет на фронте, подключает плагины, кастомизирует их, меняет конфиги, оформляет сео
тестер ― читает доки, проверяет функционал на работоспособность, ищет баги, проверяет проект на соответствие требованиям в доках, дает подтверждение что весь функционал рабочий и проект можно релизить
аналитик ― забирает у менеджера все техдоки, проектирование интерфейса, пишет новые доки, курит госты, рисует диаграммы под сложные требования, продумывает как что накрутить в соотв. к бизнес логике и требованиям от заказчика
СЕО ― врывается в проект, наводит шухер, кричит что все пропало, уходит

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

Спросите на прямую у своих менеджеров.

От себя могу поведать так.
Как ПМ могу ответить, что перед постановкой задач на разработку я составляю список фич.
Разбиваю проект на модули или компоненты и каждый модуль набиваю фичами.
Выглядит это примерно так:

Пользователи:
Создание пользователя
Удаление пользователя
Деактивация пользователя

И так на каждый модуль. В итоге в зависимости от проекта собирается от 50 до 200 фич.

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

Попробуй составлять отчет в виде какая фича переделывалась или делалась с нуля и сколько было затрачено на это времени.