Из найденного пока больше всего нравится Apache'вское решение.  https://directory.apache.org/studio/

не помню почему, но я  на нем остановился когда с ldap работал

Спасибо, глянем.

Я его юзал лет 7 назвал как gui клиента к openldap. В целом понравилось

год за два идет

Видимо, ищут гугловцев, которые с Borg работали

ищут путешественников во времени же ну

Мб это суммарно на целый отдел))

Я бы так сказал - если у вас на разработке появляется МП - дело видимо совсем худо и все катится под откос. Проблемы в координации, понимании клиентов, мотивации сотрудников и пр.. И тогда МП как некая дубина в силу своего понимания что любой бардак - это следствие плохой дисциплины, начинает вам помогать.  Обычно МП - вообще единственная "цементирующая" сила в аутсорс компаниях - так как собранную фиг знает каким способом ресурсную команд "наемников" и фрилансеров мало что связывает. С другой стороны - если команда самостоятельная и прокачанная - МП не нужен. Хватит и РП или даже РК .  Вообще тема формального и неформального разделения функций в Agile командах - очень сейчас динамически развиваемая тема. Посмотрите исследование Google и их понимание например роли и функций РК. Более подробно можно прочитать в недавно вышедшей книге, быстро поднявшейся в бестселлеры - про трансформацию внутренних топологий оргструктур ИТ компаний https://www.amazon.com/Team-Topologies-Organizing-Business-Technology-ebook/dp/B07NSF94PC

Простите, МП - это менеджер проекта или менеджер продукта? или еще кто-то?

если экономить по 14 символов каждый раз, когда пишешь МП - то можно сэкономить целых 30 секунд в день

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

Любителям С4 и Архимейта:
https://www.archimatetool.com/blog/2020/04/18/c4-model-architecture-viewpoint-and-archi-4-7/

Симпатично выглядит 👍 )) Полная капитуляция всех инструментов перед C4model продолжается ))

Красота))

С4 удобен, жаль только отсутствует в грамматике формальное определения интерфейса интеграции

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

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