Как мы в Acronis вели базу 2 года, и почему разочаровались
Года полтора назад и ещё десять раз потом я ссылался на статьи Tomer Sharon про базу инсайтов, примерно тогда же мы сделали свою в Airtable, потом забили, потом начали опять, и сейчас, наконец, она начинает приносить пользу. Расскажу, как работает, и почему теперь я сомневаюсь в том, что она нужна).

Работает просто (если чётко понимаете, как у Шерона, можно скипать) - у нас есть таблица с кучей атомарных (понятных и ценных вне контекста) инсайтов, размеченных тегами. Когда кто-то хочет понять, как работает онбординг, как устроена обычная сессия работы с продуктом, или какие проблемы есть у раздела настроек, я могу по тегам найти нужные инсайты и сделать отчёт прямо в Airtable - он позволяет создавать и шарить кастомные view с преднастроенными фильтрами и отображением, более наглядные для широкой публики, чем стандартная таблица.

Можно сделать отдельные view для каждой продуктовой команды, а ещё отдельный для маркетинга, с упором на purchase motivation инсайты. Они будут играть роль дашбордов для качественных данных (view динамически обновляются, если вы добавляете в базу новые данные, которые попадают под фильтры). Это всё работает и действительно помогает быстрее отвечать на некоторые вопросы о пользователях.

Что ещё круто:
- Кроме скорости база даёт необычные ракурсы - можно увидеть, какие проблемы возникают, например, именно у профессиональных пользователей, или именно в маленьких компаниях, сделав общий срез для нескольких исследований.
- Теперь понятно, куда девать все нецелевые проблемы, которые вы получили "между делом", и которые не хочется терять, но прямо сейчас не к месту.
- База держится на идее атомарных инсайтов, которые должны хорошо восприниматься вне контекста отчёта, в том числе человеком, который про изначальное исследование вообще не знает. Это учит описывать проблемы более чётко.

Теперь минусы:
- Базу тегов для поиска довольно утомительно поддерживать. Пока наше решение - избыточность. Если пишу про проблемы алёртов, то ставлю теги "alerts", "troubleshooting" и ещё парочку, в зависимости от контекста, чтобы нужное точно нашлось. Из-за этого во view может попасть много нерелевантных инсайтов по теме, но они легко отсекаются сужением фильтров.
- Чтобы по тегам могли искать, нужно, чтобы у команды был общий язык для элементов интерфейса и сценариев. Формального процесса для создания общего языка нет, пока работает само. Новичкам может быть сложно, потому что они общепринятых терминов ещё не усвоили.
- На базу очень легко забить, особенно пока данных для нормальных срезов недостаточно и работать "по запросу" она не может. Чтобы этого не случилось, мы постарались использовать её для создания отчётов, которые не требуют красивой презентации, так мотивации заполнять больше.
- Не развалится ли это всё при масштабировании, когда людей, команд и инсайтов будет больше? Не знаю:)

Несмотря на плюсы, я теперь сомневаюсь, что базу стоит вести регулярно, поделюсь сочинениями чуть позже.
#Process #Processing #Research_repo