Ответ.

История вопроса:

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

Проблема:

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

Решение:

• Системный аналитик инициирует создание глоссария на старте проекта, собирая терминологию от всех стейкхолдеров (бизнес, ИТ, подрядчики, поддержка).
• Каждый термин фиксируется с кратким пояснением, примером применения и указанием "владельца" термина.
• Обеспечивается единая площадка хранения (Confluence, Wiki, корпоративный портал) с правами на просмотр/редактирование для всех участников.
• В gлоссарий вносятся актуальные изменения при каждом обновлении требований или появлении новых сущностей.
• В документации и коммуникациях к каждому бизнес- или техническому термину всегда добавляется ссылка на определение.
• Ответственный назначается на поддержание актуальности глоссария (либо аналитик, либо специально назначенный "keeper").

Ключевые особенности:

• Вовлечение всех участников проекта в наполнение глоссария
• Принудительное внедрение ссылок на термины из документации
• Постоянная ревизия и модерация спорных терминов с участием бизнеса и ИТ

Вопросы с подвохом.

Можно ли использовать готовый глоссарий из другого проекта и дополнять в процессе?

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

Часто считают, что глоссарий — это задача только бизнес-аналитика или лингвиста. Это верно?

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

Можно ли держать глоссарий только в виде отдельного документа на диске и не обновлять его?

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

Типовые ошибки и анти-паттерны

• Глоссарий откладывается "на потом", из-за чего в канву всех документов попадают дублирующие или неформализованные определения
• Отсутствие ответственного за ведение глоссария
• Игнорирование необходимости использовать гиперссылки на термины в проектных документах

Пример из жизни

Негативный кейс

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

Плюсы:

• Экономия времени на старте

Минусы:

• Дебаты между командами, трата времени на выяснения
• Рост числа инцидентов и доработок

Положительный кейс

В новом продукте с первого дня был создан wiki-глоссарий, дорабатываемый в процессе. Подрядчики и внутренний ИТ-отдел постоянно обновляли свои определения, а устаревшие термины удаляли или переносили.

Плюсы:

• Высокая скорость согласования
• Минимум споров и багов из-за терминоразночтений

Минусы:

• Требуется периодическая модерация и поддержание структуры глоссария