Два месяца назад я пришел работать в компанию-девелопер, в дирекцию по цифровой ипотеке. Область для меня новая: ни со стройкой, ни с финансовыми продуктами я раньше не работал. Нужно разбираться.

«Разобраться» для меня означает следующие шаги:

1. Навести «грубую сетку» домена — понять, где мы вообще. «К черту подробности, город какой?»
2. Понять свое место в рамках домена — детализировать «сетку» в важных для проектов областях
3. Углубиться в изучение этих важных частей, разобраться в них до нужного уровня, чтобы предсказуемо планировать и реализовывать изменения.

Еще про грубую сетку в посте «Как читать сложную книгу»

Первое, что я сделал — навел «грубую сетку» предметной области. Без этого действия любые факты и детали, относящиеся к предметке, как бы повисают в неопределенности: ну вот они есть, а куда и как их сложить — непонятно. Чтобы такого не было, нужно завести какое-то небольшое количество условных смысловых коробочек и начать факты с деталями раскладывать по ним. Качество этих коробочек изначально будет плохим — это не страшно, потом переделаем как надо. Но сначала надо понять, а как же надо.

Грубой сетки достаточно, чтобы понять общие очертания объектов в домене

Грубую сетку я себе построил путем чтения статей и просмотра видосов на тему ипотеки и всяких сопутствующих штук — их в рунете навалом.

Сложилась вот такая картинка:

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

Изучив и поняв вышеописанное, я сформулировал для себя задачу дирекции: сделать процесс покупки квартиры в ипотеку максимально удобным для клиента и максимально прибыльным для компании.

Прикидка по системным уровням

Дальше пошла более подробная работа над доменом. Для нее я использую несколько инструментов.

1. Три списка — Факты, Оценки, Термины.
   В «Факты» попадают факты и наблюдения, которые мне встречаются на созвонах или в переписке. К примеру, из фразы «комиссия у зеленого банка охереть высокая!» можно выделить два факта: «комиссия зеленого банка N%» и «комиссия у зеленого банка выше, чем у других». Составление списка фактов помогает понять, какие события и явления в рамках домена значимы, а какие — нет.
   В список «Оценки» попадают оценки некоторых фактов, выраженные членами команды или внешними людьми. Сочетание одного факта и набора разных оценок к этому факту помогает понять, какие есть конфликты и в чем их причины, а также примерные роли тех, кто эти оценки высказывает. Пример: из высказывания «М. сказала: комиссия у зеленого банка охереть высокая!» м можем сделать предположение о роли М. и о важных для нее вещах.
   В список «Термины» я пишу все слова, словосочетания и устойчивые выражения, которые встречаю на встречах или вычитываю из разных источников.
   Списки составлять просто: услышал новый факт или незнакомое словосочетание — записал в список. Перечитал журнал, увидел там термин — переписал в список.
   Периодически списки нужно перечитывать и грумить — убирать оттуда нерелевантные термины, дописывать пояснения. Рано или поздно начнут прорисовываться понятные связи между некоторыми элементами списков, туман войны начнет рассеиваться.

2. Еще один список — люди. Кто, чем занимается, в каких проектах задействован. Не относится к домену, но помогает не потеряться в новом проекте и не задалбывать коллег повторяющимися вопросами вроде «а кто там у нас за эти лендосы отвечает?». Встретили нового человека, который работает на вашем или соседнем проекте — записали в табличку.

3. Третий важный артефакт — схемы событий. В любом домене существуют устойчивые процессы, которые помогают понять границы и основные свойства домена. Покупка жилья в ипотеку, в целом, и есть процесс — у него понятные шаги и этапы, понятные «альфы», которые изменяются. Можно даже сказать так: оформление ипотеки — это процесс пошагового заполнения и утверждения набора документов. Накидав и провалидировав такой процесс, можно рисовать CJMы и прочие клиентоцентричные штуки.
   По схемам у меня простой подход: набросок схемы я рисую как угодно и чем угодно (ручкой в блокноте, стилусом в ремаркабле, мышкой в Миро или Фигджеме). Потом переношу схему в Миро/Фигджем и там довожу до ума — дорисовываю нужные этапы, детализирую, распутываю запутавшиеся связи. Когда я доволен схемой — перевожу ее в Мермейд (см. пост про схемы) или табличный формат.
   Использую три основных типа схем: диаграммы сущностей — что есть в домене/субдомене, как связано; карты процессов — этапы, роли, артефакты; диаграммы систем — какие системы, как связаны. Для нормального понимания домена мне удобно сначала прикинуть процесс, потом на этапы процесса накинуть роли и акторов: кто что делает, чтобы дело двигалось. Дальше на роль можно повесить модуль — софт, оргединицу и т. п. На такой схеме удобно думать про точки улучшения сервиса и делать сравнение «как сейчас — как будет».

Схема процесса в одном из проектов

В итоге я пришел к простой базовой мета-модели по этому проекту:

Базовая мета-модель в проекте с партнерским банком

«Актор» — участник процесса
«Шаг процесса» — некое действие, цель которого создать или развить РП
«Рабочий продукт» — артефакт, который должен быть создан для продвижения или завершения процесса
«Инструмент» — то, что используется на определенном шаге или в отношении РП акторами

4. Журнал. Каждый день я пишу, с какими людьми о чем поговорил, что узнал и о чем подумал, какие идеи пришли в голову. Журнал служит инбоксом: потом из него можно выписать людей, термины и факты, какие-то задачки оформить. Еще журнал помогает сохранять контекст, в котором я эту информацию получил.
   Журнал надо перечитывать: каждый день узнаешь что-то новое, и это новое помогает увидеть другие смыслы в ранних записях.

Скриншот записи из журнала

5. Альфы OMG Essence — проектные объекты и области, которые нужно отслеживать. Про фреймворк я рассказывал на конференции пять лет назад.
   Факты, люди и термины вполне естественно раскладываются по альфам и подальфам проекта. Структурирование проектной информации по альфам помогает хранить описание в компактной форме, быстро понимать проектные проблемы и принимать меры.

Вот такая у меня стратегия изучения новых доменов. Достигнув результата и развеяв туман войны, можно приступать к планированию изменений осознанно и рационально.