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

Это вы к чему?

Не претендовал на точность.

Итак простыня :))
Допустим я должен наполнить себе систему/апк теми или иными данными и разработать под эти данные функционал силами своих рабочих групп, для дальнейших работ над этими данными - организовать
поток разных данных из разных источников и обрабатывать потом его же в своей системе.
Перед совещаловкой я уже собрал\получил и обсудил\согласовал список UC\US:
1. Ищу нужные мне данные, в ландшафте ит систем своей организации, через отделы архитекторов, релиз-менеджеров и аналитиков.
2. Созваниваюсь с руководителем нужного подразделения и знакомлюсь. Обозначаю свой интерес к тем данным, которые у подразделения есть/могут быть и предлагаю поговорить очно или по почте,
обозначаю дальнейший интерес к совещаловке. Если канал коммуникаций в почте достаточен, всем все понятно, и мне готовы предоставить запрашиваемые данные - ок, совещаловка не требуется, а
если нет и нужны пояснения какие либо - то грядет совещаловка. Договариваемся о намерении собраться и поговорить коллективами. Я прорабатываю совещаловку.
3. Созваниваюсь со специалистами этого подразделения и обсуждаю данные, которые есть у подразделения, изучаю er-модель базы данных, иногда до 5бд прихолится прочитывать, вычленяя нужные
мне строки и описания, моделируя тем самым уже свою бд, естественно вычитывание происходит на пару с тимлидом из каждой целевой рабочей группы, потом совместно обсуждаем и
вызвания/выписывая программиста подразделения-владельца данных приходим к договоренности, что именно эти ячейки нам нужны для нашей задачи. Часть совещаловки уже подготовлена таким образом.
4. Согласую даты совещания с руководителем, бизнес-аналитиком и релиз-менеджером подразделения владельца данных и с их руководителем, или это делает сам руководитель, у меня в практике
оба варианта были.
5. Я бронирую переговорку. В переговорочном приглашении(есть спец софт по бронировке переговорок) я приглашаю всех участников, указываю почту и всем приходит приглашалка.
Указываю Общую тему и ниже детализирую по пунктам что мне нужно от ребят, что уже обсуждалось, что еще не обсуждалось. Совещаловку надо проводить так, чтобы не более двух в день
было у всех участников. Например 8 пунктов, из них организационные вещи, финансовые вещи, технические вещи, по коммуникациям особенности и перечисляю список согласованных уже интересующих
меня полей. Если надо что приложить из документов - тоже прикладываю.
6. Протокол веду сам, согласовываю его сам же со всеми, в конце оставляю время, 10 минут, на согласование протокола, оформление, распечатку его и подпись тут же всеми участниками.
Или уговариваемся о том, что все это можно сделать по почте, (при определенном уровне развития проектного офиса, уровне мотивации с моей стороны и "высоте заседания" куратора моего
проекта или общей регулярной стимуляции всех и вся и такое возможно) и формальности нам не нужны.
7. Завожу RFC и описываю все что нужно в нем, с привлечением архитекторов, аналитиков и всех кому надо знать и согласовывать. Отдельно: Список согласующих работы формирую и список наблюдающих.
Составляю БФТ,ТЗ\ЧТЗ, SLA и возможность по повышению SLA заложить или еще что... и прикладываю. Далее идет процесс обсуждения до указанных дат в обсуждении\чате при этом же RFC.
Обсудить сопровождение и коммуникации по этому поводу.В итоге я получаю КП от подрядчика подразделения владельца-данных.
8. КП согласовываю и защищаю перед руководителем моего подразделения-заказчика на еженедельной совещаловке и потом все проплачивается, я отслеживаю процесс оплаты по КП
и по мере оплаты начинаю мерно пинать подрядчиков.
9. По мере реализации работ подрядчиками я организую обработку нового потока данных. отрисовываю примерный интерфейс сам и согласовываю с Закакзчиком, отдаю тимлиду РГ и
парни уже парсят данные и отрисовывают кнопочки и поля, по моим же запросам под каждой кнопкой. Запросы сам составляю и предварительно в багтреккере\почте обсуждаю с тимлидами.
Идет подготовка и калькуляция работ для КП на следующее допсоглашение к основному контракту., все сам стимулирую и подписываю с защитой перед руководствами.

10. Иногда приходится заниматься и инфраструктурными работами, когда нужно сделать еще и oracle standby, когда наши выгрузки мешаю коммерсантам и у них все ложится - тогда
несколько иная песня, но тоже очень интересная...поиск и закупки железок всяких, поставки пинать надо, сервера перевыгрузки, оптику кладем и сети разворачиваем с сетевым
оборудованием, авторизации всякие...итд Тут еще стоит упомянуть целый список работ по инфраструктуре надо согласовывать с инфраструктурщиками и сетевиками, но там все относительно просто.
11. После всего я должен оформить красиво каждое RFC, обучить техподдержку и ввести в курс как именно надо поддерживать комплекс, потоки данных, научить составлять RFI, как
занудно контроллировать потоки данных и оформлять ругательства по почте и в RFI, а иногда и с эскалацией наверхний уровень дерекции заказчика с просьбой повлиять...и составить
подробное описание функционала и дать все контакты.
12. По мере продвижения работ по новому функционалу или инфраструктурных работ вношу все в багтреккер и в проджекте оформляю соответственно.
13. По мере разработки все тестирую сам пару раз, на разных стендах, потом пилотную группу Заказчика заставляю тестировать неделю.
14. Потом идет приемка на местах - основной массе потребителей моих уже данных, устраиваю недельное тестирование, далее нет\не вижу смысла, принимаю их замечания и если есть нечно
сильное - то небольшая доработка, если нет - в рамках сопровождения работы проводятся.
15. От всех подрядчиков по всем работам я должен принять работу в полном объеме, с тестами и согласовать все описания по всем работам для дальнейшего оформления всего этого барахла
в "hi level design"(HLD, своего рода библиотека проектов и активностей или LL)
16. Потом все это надо внести в свой архив проектов и отчитаться коммерции\руководителю направления о проделанной работе.
Наверняка что-то забыл  написать

Иногда они необходимы. Краткие, по делу и с четкой, заранее определенной повесткой

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

И что вы делаете, если главный топик упирается в решение других топиков? А те тянут за собой обсуждение третьих, а те - в давние счёты подразделений между собой?)

Счета между подразделениями? Они все оплачены, давно, всегда.

При конфликтах надо на уровень выше выходить. Но не часто, иначе можно получить - , за неумение договариваться.

👍

Еще на переговорах надо учитывать то, что ты даешь и что просишь. Нельзя только дать или только взять. Баланс важен.

Коллеги, к чему эти банальности? )) Кто, вообще, говорит о переговорах? У нас совещание. И кто ты, блин, такой, чтобы мирить CFO и CIO? Переговорщик тут нашелся ))

Это - не единственная проблема, друг. Основная в том, что тема запутанная. Плохие отношения лишь ухудшают ситуацию

Серебрянной пули нету. Все решает кейс менеджмент. Самые крутые переговорщики - это те кто с террористами переговоры ведет. Это реально навык и опыт психологии и принятие решений за доли секунды)

Я и не собирался мирить никого, всего лишь по проблеме высказался.  Задача помирить - задача гендира или владельца или совета директоров. Приоритизация kpi и проектов это их задача

Посмотри вот это:  https://m.youtube.com/watch?v=NYlNgr5jiJU

Потихонечку всех пинать, пока не будет результата

+1
win-win

Ну да