Как вы разбирались в незнакомом домене, где эксперты говорили разными терминами?
Признал незнание явно и превратил его в преимущество, с первого дня вёл живой Domain Glossary с разграничением омонимов по ролям, наблюдал за реальной работой экспертов и верифицировал понимание через paraphrasing после каждого объяснения.
Ситуация
Меня поставили на проект автоматизации процессов торговли деривативами — область, в которой я не разбирался вообще. Эксперты говорили на смеси финансового жаргона, биржевых терминов и внутреннего сленга компании. Слово «позиция» означало разные вещи у трейдера, риск-менеджера и бухгалтера.
Шаг 1: Признать незнание явно и превратить его в преимущество
Я не делал вид, что понимаю. На первой встрече сказал: «Я буду задавать много базовых вопросов. Если вам кажется, что это слишком просто — это нормально. Мне нужно понять, как вы думаете об этих процессах, а не только что вы делаете». Это сняло напряжение и открыло людей.
Новичок в домене имеет одно преимущество: он задаёт вопросы, которые эксперты перестали задавать. «Почему именно так?» — часто вскрывает assumption, которые никто не проверял годами.
Шаг 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)Шаг 3: Show Don't Tell — наблюдение за работой
Я попросил разрешения «тихо посидеть» рядом с трейдером в течение двух часов во время торговой сессии — без вопросов, просто наблюдать. Это дало мне контекст, который невозможно получить из интервью: что они реально делают руками, на что смотрят, что вызывает стресс. После этого вопросы стали намного конкретнее.
Шаг 4: Верификация понимания через paraphrasing
После каждого объяснения я проговаривал своими словами: «Правильно ли я понимаю: X происходит, когда Y, и это отличается от Z тем, что...?» Эксперты исправляли неточности немедленно. Это быстрее, чем писать требования, отдавать на review и получать «нет, вы неправильно поняли» через неделю.
Шаг 5: Найти внутренних союзников
В каждом домене есть человек, которому нравится объяснять. Я нашёл такого в команде риск-менеджмента — junior-аналитик, которая недавно сама изучала эту область и помнила, что было непонятно. Она стала моим «переводчиком» на первые две недели.
Подводные камни
- Делать вид, что понимаешь, когда не понимаешь: это накапливает misunderstanding, которое взрывается при review требований.
- Не строить глоссарий: одинаковые слова у разных ролей означают разное — это источник критических ошибок в требованиях.
- Полагаться только на интервью: наблюдение за реальной работой даёт контекст, недоступный через вопросы.
- Не валидировать понимание немедленно: «уточню потом» превращается в «забыл уточнить».
- Игнорировать документацию, написанную самими экспертами: внутренние инструкции, training materials, old specs — это первичный источник домейн-знаний.
- Пытаться стать экспертом домена самому: цель BA — понять процесс достаточно, чтобы правильно описать требования, а не стать трейдером.
What hurts your answer
- Притворяться, что всё понятно.
- Использовать термины разных экспертов как синонимы без проверки.
- Не вести glossary или domain model.
What they're listening for
- Быстро строит domain model.
- Проверяет термины примерами.
- Не боится уточнять базовые вещи.