Заведите себе глоссарий (необходимость говорить на одном языке)

Есть такая поговорка: "С кем поведешься, от того и наберешься". Это к рассмотрению ситуации, когда в отдел, например, тестирования приходит новый сотрудник. Он начинает общаться с коллегами и в процессе работы начинает говорить, писать (описывая ситуации, возникающие во время тестирования) так, как принято среди тестировщиков. Это нормально. То же самое происходит и в отделе, например, разработки документации. В пределах одного отдела все друг друга понимают практически без проблем (опустим ситуации, когда новый сотрудник совсем новый:)). Но вот когда коммуникации затрагивают несколько отделов такого понимания может и не быть. Ничего удивительного. Просто одни привыкли называть так, а другие- иначе. И оба варианта используются сотрудниками различных отделов различных организаций, то есть никто ничего нового не выдумывал. Хорошо, если ситуаций, где можно найти такие варианты различий, не много. (ну, допустим, характер софта такой). А если только в пределах одного направления разработки таких вариантов масса? Да к тому же существует разбивка как минимум на 3 отдела (документации, разработки, тестирования), а часто больше чем на 3. Наложим на все это распределенную на несколько стран разработку. Соответственно добавляются варианты, которые предлагаются иностранным языком. Но ведь английский русских разработчиков и английский разработчиков, например, из индии- 2 большие разницы. В итоге получаем столько определений одних и тех же вещей, с которыми не так-то просто и разобраться, не говоря уже о том, что временных задержек на это не должно быть вообще. Не трудно представить, сколько лишнего времени уходит на то, чтобы разобраться с баг репортом, понять суть бага. Чтобы избегать таких ситуаций, необходимо вывести некий глоссарий и в соответствии с ним называть вещи своими "уникальными" именами. За основу можно взять общепринятые понятия, которые наиболее часто встречаются уже (в переписке, в системе баг репорта и тд), на данный момент. Если разработка распределенная- то на английском языке. Как правило, наборы готовых требований к разрабатываемому софту уже содержат большинство понятий и определений. Этим стоит воспользоваться и принять за основу.
К чему это все? Коммуникации должны быть эффективными. С точки зрения тестирования это своевременный, точный, однозначный отчет\репорт о положении дел. Если это баг репорт- то он должен быть абсолютно понятен всем участникам разработки. Не должно быть отсылки бага обратно автору за подробностями. Пусть вновь пришедшие сотрудники сделают несколько репортов под присмотром более опытных. Пусть в открытом доступе хранится некий глоссарий, который можно использовать, редактировать. Это сэкономит кучу времени в будущем.