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

да, определенно согласен

вот тут кстати ваш случай идет как 9-й 😊

как 9 и 8 :)

Эклипс Папирус кто то использует?

не работает ?

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

После планирования, разработчики по каждой непонятной или неоднозначной задаче обсуждали её с бизнес-человеком или аналитиком (представителем конкретного бизнеса). Например, по скоррингу, с риск-менеджером, по маркетингу - с директором по маркетингу и т.д.

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

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

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

Опыт интересен. И какие предпосылки для выбора были

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

Papyrus это попытка сделать бесплатный клон Rational Software Architect.  Бесплатные тулы для моделирования нормально не работают.
Подойдет для студентов и написания научных статей

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

Иногда хочется сохранить "выгоревшую" команду с сильными инженерами. К сожалению без потерь и изменения структуры это невозможно.

Проекты, которые доведены до реанимации без орг. мер оживить невозможно, к несчастью.

1. Помогала ли при этом рокировка сотрудников между командами/доменами?
2. Какие ещё варианты сохранения штата и экспертизы хорошо работали при выгорании?
3. За счёт чего в основном происходило выгорание?
4. Равнодушных разработчиков совсем невозможно было зажечь (полная инертность) или был изначально выбран неправильный подход?
5. Кто в команде был центром компетенции в части соблюдения ритуалов общения с бизнесом и погружения разработчиков в предметку?

https://vc.ru/hr/98611-toksichnost-i-liderstvo-v-komandnoy-rabote?from=digest&date=311219 достаточно интересная, на мой взгляд, статья, про цикл изменений человека в процессе освоения нового. Думаю, многие инертные разработчики подпадают под определение "эксперт-бирюк" из этой статьи))

Я привожу обощённый опыт, разных проектов.

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

Кого-то удаётся сохранить в компаниях в том числе за счёт рокировок, но всех сохранить не получится никогда. Иногда люди даже из профессии уходят.

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

Это сложно, потому что люди постепенно утрачивают навыки коммуникаций и одновременно навыки самообучения.

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