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

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

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

руководитель проекта старается увеличить свой бюджет за счёт другого —--> можно не правильно понять, станет грустно, или всеж правильно....

Тут ключ ко всему фраза "тратится времени". Значит, учитывать надо время. Значит, куда то его надо списывать. Значит, должен быть объект списания с необходимой аналитикой. Плодить сущности - зло. Значит, списание это должно не сильно отличаться от обычного. Если обычно время списывается на задачи, значит, надо совещание заводить как задачу. Если совещание по проекту - с аналитикой проекта. Если совещание межпроектное - с другой аналитикой, которая необходима. Собственно, как то-так и делали. Вариантов мало других, вроде.

Сложность наступает с продуктовой разработкой. Эту задачу мы в своё время так и не придумали как решать. Если есть некоторая большая функциональность, которая нужна одному заказчику продукта, а второму нет. Кладём на заказчика 1. А на следующий день впариваем это второму заказчику - как делить? Как считать "степень нужности", монетизируемость по определённому заказчику, и как положить это в объекты рабочего процесса и вести отчётность; как мотивировать РП проталкивать своим заказчикам более полезные фичи, которые возможно переиспользовать у других заказчиков - вопросы нерешенные.

Тут ключ ко всему фраза "тратится времени". Значит, учитывать надо время. Значит, куда то его надо списывать. Значит, должен быть объект списания с необходимой аналитикой. Плодить сущности - зло. Значит, списание это должно не сильно отличаться от обычного. Если обычно время списывается на задачи, значит, надо совещание заводить как задачу. Если совещание по проекту - с аналитикой проекта. Если совещание межпроектное - с другой аналитикой, которая необходима. Собственно, как то-так и делали. Вариантов мало других, вроде.

Сложность наступает с продуктовой разработкой. Эту задачу мы в своё время так и не придумали как решать. Если есть некоторая большая функциональность, которая нужна одному заказчику продукта, а второму нет. Кладём на заказчика 1. А на следующий день впариваем это второму заказчику - как делить? Как считать "степень нужности", монетизируемость по определённому заказчику, и как положить это в объекты рабочего процесса и вести отчётность; как мотивировать РП проталкивать своим заказчикам более полезные фичи, которые возможно переиспользовать у других заказчиков - вопросы нерешенные.

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

обучение кого? менеджера? для этого должен быть внутренний проект - обучение

Молчал, молчал, но не выдержал. Встряну.

Цель учета времени совещаний какая? Не учет же ради учета. Делаю вывод, что совещания занимают много рабочего времени и, соответственно, малоэффективны.
Поэтому, если вообще такая задача (учет времени совещаний) возникает, то пора принять управленческое решение и начать бороться с неэффективностью совещаний. Как-то так.