Как вы разбирались в незнакомом домене, где эксперты говорили разными терминами?

Шаг 2: Glossary как живой документ

С первого дня я завёл Confluence-страницу «Domain Glossary». Правила:

• Каждый термин — кто его использует (роль), что он означает в этом контексте, синонимы и омонимы
• Обновляю после каждой встречи прямо во время неё (ноутбук открыт)
• Ссылаюсь на глоссарий в user stories — «позиция (см. glossary, определение для risk manager)»

# Domain Glossary: Derivatives Trading

## Position
- Trader's definition: current open contract volume for an instrument
- Risk Manager's definition: net exposure across all instruments for a counterparty  
- Accounting's definition: booked P&L entry
- NOTE: These are DIFFERENT concepts. Context determines meaning.

## Settlement
- Physical settlement: actual delivery of the underlying asset
- Cash settlement: net cash payment of difference
- Settlement date vs. value date: NOT the same (common confusion)

## Mark-to-Market (MTM)
- Daily revaluation of open positions at current market price
- Used for: margin calls, P&L reporting
- NOT used for: tax accounting (uses trade price)

Ситуация

Меня поставили на проект автоматизации процессов торговли деривативами — область, в которой я не разбирался вообще. Эксперты говорили на смеси финансового жаргона, биржевых терминов и внутреннего сленга компании. Слово «позиция» означало разные вещи у трейдера, риск-менеджера и бухгалтера.

Шаг 1: Признать незнание явно и превратить его в преимущество

Я не делал вид, что понимаю. На первой встрече сказал: «Я буду задавать много базовых вопросов. Если вам кажется, что это слишком просто — это нормально. Мне нужно понять, как вы думаете об этих процессах, а не только что вы делаете». Это сняло напряжение и открыло людей.

Новичок в домене имеет одно преимущество: он задаёт вопросы, которые эксперты перестали задавать. «Почему именно так?» — часто вскрывает assumption, которые никто не проверял годами.

Шаг 3: Show Don't Tell — наблюдение за работой

Я попросил разрешения «тихо посидеть» рядом с трейдером в течение двух часов во время торговой сессии — без вопросов, просто наблюдать. Это дало мне контекст, который невозможно получить из интервью: что они реально делают руками, на что смотрят, что вызывает стресс. После этого вопросы стали намного конкретнее.

Шаг 4: Верификация понимания через paraphrasing

После каждого объяснения я проговаривал своими словами: «Правильно ли я понимаю: X происходит, когда Y, и это отличается от Z тем, что...?» Эксперты исправляли неточности немедленно. Это быстрее, чем писать требования, отдавать на review и получать «нет, вы неправильно поняли» через неделю.

Шаг 5: Найти внутренних союзников

В каждом домене есть человек, которому нравится объяснять. Я нашёл такого в команде риск-менеджмента — junior-аналитик, которая недавно сама изучала эту область и помнила, что было непонятно. Она стала моим «переводчиком» на первые две недели.

Подводные камни

• Делать вид, что понимаешь, когда не понимаешь: это накапливает misunderstanding, которое взрывается при review требований.
• Не строить глоссарий: одинаковые слова у разных ролей означают разное — это источник критических ошибок в требованиях.
• Полагаться только на интервью: наблюдение за реальной работой даёт контекст, недоступный через вопросы.
• Не валидировать понимание немедленно: «уточню потом» превращается в «забыл уточнить».
• Игнорировать документацию, написанную самими экспертами: внутренние инструкции, training materials, old specs — это первичный источник домейн-знаний.
• Пытаться стать экспертом домена самому: цель BA — понять процесс достаточно, чтобы правильно описать требования, а не стать трейдером.

• Притворяться, что всё понятно.
• Использовать термины разных экспертов как синонимы без проверки.
• Не вести glossary или domain model.

• Быстро строит domain model.
• Проверяет термины примерами.
• Не боится уточнять базовые вещи.