# Как это сделано ## Предпосылки и подход За несколько лет по Элли накопилось много исследований, пользовательских болей и наблюдений, но инфа была распределена по разным местам: отдельным документам, Figma/Miro, записям исследований, Яндекс Трекеру и другим артефактам. Поэтому мы начали собирать все боли в отдельную очередь в Трекере [https://tracker.yandex.ru/PMALLY](https://tracker.yandex.ru/PMALLY) Одна таска в этой очереди = одна пользовательская боль с цитатами, ссылкой на исследования, сырые данные, расшифровки и т.д. Если есть несколько источников в разное время, но проблематика одна — всё агрегируется в одной карточке боли. При проведении исследований приходилось расшифровывать боли и вручную заводить их в Трекер. Но теперь все боли автоматом создаются на сервере при расшифровке, а затем улетают в Трекер. Таким образом, все набранные ранее боли перенесены из Трекера на сервер, а все новые боли изначально создаются на сервере и отправляются в Трекер, чтобы обе базы были актуальны. С болями на сервере можно работать через агента. Боли в трекере привязываются как Эпик к произволственным тикетам в Трекере. ## Что находится внутри ### 1. Исследования Каждое исследование хранится отдельным `.md`-файлом в: `docs/ux/researches/` В карточке исследования могут быть: - контекст и потребность; - цели; - дизайн исследования; - метод; - гипотезы; - респонденты; - результаты и находки; - исходные материалы; - артефакты результата; - принятые решения; - следующие действия; - связанные исследования; - роли и другие сущности базы. Дополнительно фиксируются метаданные: период, тип исследования, платформы, роли, подразделения, типы торговых точек и другие параметры, если они известны. ### 2. Боли Пользовательские боли вынесены из исследований в отдельные карточки: `docs/ux/pains/` Каждая пользовательская боль хранится отдельной карточкой. Мы стараемся фиксировать не только саму формулировку проблемы, но и контекст, силу подтверждения и связь с продуктовыми изменениями. По каждой боли собираем: - **ID и ссылку на Яндекс Трекер** — чтобы связать Markdown-карточку с рабочей карточкой боли в Трекере. Внутренний числовой ID совпадает с номером `PMALLY`-задачи. - **Категорию** — собственно боль, идея или наблюдение. Это помогает не смешивать пользовательскую проблему с предложенным решением или просто зафиксированным фактом поведения. - **Статус боли** — открыта, в работе, на проверке, решена или больше не актуальна. Статус относится именно к пользовательской проблеме, а не к связанной продуктовой задаче. - **Дату последнего обновления** — чтобы понимать свежесть информации. - **Контекст возникновения**: для каких ролей проблема подтверждена, для каких типов торговых точек, на какой платформе и в какой продуктовой области она возникает. Боль не распространяется автоматически на другие роли или платформы только потому, что сценарии похожи. - **Темы** — например, «Графики», «Расхождения», «Окна», «Прогноз». Они нужны для группировки и поиска проблем по предметным областям. - **Частоту / распространённость** — насколько часто проблема встречается у конкретной роли или когорты, если это вообще удалось определить. - **Эмоциональность** — насколько сильно пользователи переживают или эмоционально реагируют на проблему, если такие данные есть. Частота и эмоциональность хранятся отдельно: редкая проблема может быть очень болезненной, а частая — восприниматься спокойно. Структура этих полей заложена непосредственно в шаблон карточки боли. - **Описание боли** — сама проблема пользователя, без подмены её предполагаемым решением. - **Цитату пользователя**, если сохранилось первичное свидетельство. - **Подтверждение** — что именно позволяет считать проблему существующей: например, сколько участников исследования её отметили, была ли она найдена в одном или нескольких исследованиях, есть ли количественные данные. Наличие нескольких источников усиливает подтверждение, но само по себе ещё не означает известную распространённость проблемы. - **Источники** — откуда вообще появилась боль: исследование, интервью, личное сообщение, стратегическая сессия, наблюдение и т. д. Для источника по возможности сохраняем исследование, дату, респондента, ссылку на расшифровку или запись и таймкод. - **Связанные продуктовые задачи** — что уже делалось или планируется сделать в продукте в ответ на проблему. При этом закрытая задача не означает автоматически, что сама боль решена: решение могло закрыть её только частично или у одной боли может быть несколько связанных задач. Например, для боли «Неудобный список Окон» в базе отдельно зафиксированы роли Старшего продавца и Старшего кассира-комплектовщика, типы ТТ, только веб-платформа, тема «Окна», описание проблемы, подтверждение от пяти участников исследования и две связанные продуктовые задачи. Таким образом, карточка боли отвечает не только на вопрос **«что неудобно?»**, но и на более важные: **У кого возникает проблема? В каком контексте? Чем она подтверждена? Насколько она распространена? Откуда мы это знаем? Что с ней уже делали?** Да — кроме `pains` и `researches` у вас база уже содержит ещё три смысловых слоя и один служебный файл. Я бы описала это в статье так: ### 3. Подразделения Сейчас в базе есть: - Розница; - Последняя миля; - Горячая линия; - Бэкофис. Подразделение нужно, чтобы понимать более широкий контекст: где работает пользователь, к какому контуру относятся его сценарии и исследования. ### 4. Роли пользователей Каждая карточка роли описывает тип пользователя Элли и его реальный рабочий контекст. В карточке роли могут храниться: - ID роли внутри базы; - системный код роли в Элли; - тип роли — менеджерская или линейная; - альтернативные названия и сокращения; - подразделение; - применимые типы торговых точек; - используемые платформы; - количество пользователей; - права в Элли; - описание рабочего контекста. Это позволяет анализировать исследования не абстрактно «по сотрудникам», а понимать, **кто именно сталкивается с конкретной проблемой и какие возможности у него есть в системе**. Отдельно учитываются альтернативные названия. Например, сокращение `СП` можно сопоставить со Старшим продавцом, а не создавать ещё одну сущность только потому, что в одном исследовании роль названа сокращённо. Есть и специальные агрегирующие роли — например, `Сотрудник` для линейных сотрудников торговых точек в целом. Она используется, когда знание относится сразу к широкой группе и перечислять все конкретные роли отдельно не имеет смысла. --- ### 5. Типы торговых точек Это важно, потому что одна и та же роль или процесс может работать по-разному в разных форматах ТТ. Например, боль может быть подтверждена только для даркстора, только для вайтстора или сразу для обоих. Также здесь хранятся разные варианты названий. Например, `Вайт`, `Вайт стор`, `white store`, `whitestore` и `ВС` могут быть сопоставлены с одной сущностью `Вайтстор`. Это особенно полезно для старых исследований, где терминология была не унифицирована. --- ### 6. Правила работы с базой `AGENTS.md` По сути, это инструкция для AI-агентов: словарь + модель данных + правила интерпретации. В ней описано: - какие сущности есть в базе; - как они связаны; - что означают роли, подразделения, типы ТТ, платформы и боли; - какие значения считаются допустимыми; - как интерпретировать wikilinks; - какие данные нельзя автоматически переносить между ролями, платформами или подразделениями; - как отличать боль от идеи, наблюдения и продуктовой задачи; - как работать с историческими исследованиями; - как трактовать неполные или неизвестные данные. ## Связи в базе Все сущности хранятся обычными Markdown-файлами. При этом они связаны между собой через wikilinks — ссылки вида: `[[roles/starshiy-prodavetc|Старший продавец]]` или: `[[pains/103|Боль 103]]` Поэтому в совокупности получается не просто набор документов, а **граф знаний**. Исследование может ссылаться на роль и боль, боль — на исследование и пользователя, а обратные ссылки позволяют посмотреть на эту же связь с другой стороны. Например: `Исследование → нашло боль → боль относится к Старшему → подтверждается ещё двумя исследованиями` Связи должны быть явными: база специально запрещает автоматически приписывать исследованию роль, подразделение или проблему только потому, что такая связь кажется логичной. Итого структура сейчас такая: ``` docs/ux/ ├── divisions/ — подразделения и операционный контекст ├── pains/ — отдельные пользовательские боли ├── researches/ — исследования и их результаты ├── roles/ — роли пользователей, права и рабочий контекст ├── shop-types/ — типы торговых точек └── AGENTS.md — правила понимания и обработки всей базы ``` ## Чем это полезно **Главный эффект базы — переход от архива исследований к накопительной системе знаний.** Раньше исследование в основном отвечало на вопрос: > Что мы узнали в этом конкретном проекте? Теперь можно задавать вопросы уровнем выше. Например: > Какие боли Старших повторяются в разных исследованиях? > Какие проблемы подтверждены несколькими независимыми источниками? > Что мы уже знаем про работу с расхождениями? > Какие боли Окон возможностей остаются нерешёнными? > Есть ли исследования, которые противоречат друг другу? > Какие роли исследованы хорошо, а про какие у нас почти нет данных? > Какие проблемы встречаются и в мобильном приложении, и в вебе? > Что мы уже знаем по теме, прежде чем запускать новое исследование? **Для исследователя** база сокращает ручной поиск по старым материалам и помогает не исследовать повторно то, что уже известно. **Для продуктовой команды** позволяет пройти от конкретной боли назад к доказательствам и понять, насколько хорошо она подтверждена. **Для новых участников команды** становится картой уже накопленного знания об Элли. **Для AI-агентов** Markdown и явные связи позволяют работать сразу со всем массивом знаний: искать паттерны, сопоставлять исследования, находить противоречия, собирать срезы по ролям или темам и при этом возвращаться к конкретным источникам. По сути мы сохраняем исследования не только как историю проведённой работы, а превращаем их в **переиспользуемую память продуктовой и исследовательской команды**.