Не про человечество сейчас, а про 600 человек всего лишь :)

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

Никак не общаются, увы

Общаюсь я с ними, и мне очень тяжко...

"А кому сейчас легко?"

Так вот как сделать так, чтобы они коммуницировали при ОТСУТСТВИИ единого понятийного аппарата?

Раз мы за практику, скажите, пожалуйста, как это сделать?

Я не понял проблемы.

Есть команда/подразделение Т, которая работает со своим понятийным аппаратом. отличающимся от общего.
Люди которые приходят в команду Т знакомятся с этой практикой и учат этот понятийный аппарат  T(D).
Людям которые не приходят в команду Т понятийный аппарат команды Т(D) может быть не нужен.
Они общаются в пределах существующего пересекающегося аппарата.

В пределах той же компании есть команда/подразделение W. У них другие задачи, они используют другой аппарат, общаться с T им не очень надо, скорее по поводу релизов и фич, и это осуществляется, ну пусть, через общие описания фич и интерфейсов.

При этом у команд T и W всё равно есть расхождения. Им нужно общее только на том стыке где они собственно пересекаются.

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

А что в таком случае мешает, при наличии времени и ресурсов индуктивно отработать "знакомятся с практикой и учат понятийный аппарат" на все остальные команды?
Тем самым получив искомый понятийный аппарат общий для организации. Не для всего мира, о чём тут кажется никто ни разу не просил.
Но если мы можем онбордить в команде 1 работника в день/неделю/месяц, имеем запас средств и желание/необходимость, мы можем провксти эту операцию для остальных участников из других команд, предварительно выбрав конкретный аппарат, хоть T, хоть W

А зогчем оно нужно?

Подразделение T 10 лет работает без этого общего опарата, подразделение W тоже без него лет 5 работает. Они пересекаются через какую-то вообще третью систему CDB, из которого W вызывает данные которые положило туда T.  Как софт от T обрабатывает эти данные W не знает и не интересуется. T немножко интересуют случаи использования этих данных, но именно случаи использования, а не понятийный аппарат команды W. W отвечает за GUI часть и немножко за клиентское API. У T нет GUI вообще, и своё API, которое с API W не пересекается вообще никак.

Для материализации аналогии (упрощая): допустим, T заносит в базу данных регистрацию авто и ДТП или другие неприятности с ними происходящие. W работает над клиентом, который эти данные достаёт и показывает информацию по конкретному номеру — владелец, история владения, попадал ли он в ДТП или другие происшествия.

Какие-то общие понятия у них будут, но унификация до чего-то совсем общего им нужна как рыбке зонтик.

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

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

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

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

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

Единую стратегию тестирования для разных команд в разных областях (API, Web, Mobile) я вообще не представляю. Мобильщикам нужны интерфейс гайдлайны, бэкэндщикам они не нужны. Перфоманс у тех и тех разный.

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

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

> но может пригодится

Есть такой принцип YAGNI

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

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

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

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

Конвенции именования в разных языках могут быть разные.
В рамках разных библиотек запросто могут быть разные понятия, а у интерфейсов и подавно.