«Срез» и «Радар»

Проблема

Городские пресс-службы, штабы, продуктовые команды и журналисты работают в мире, где обсуждения важной для них темы происходят одновременно в десятках источников. Telegram-каналы, VK-сообщества, комментарии, отраслевые форумы, локальные паблики, GitHub Issues. Чтобы понять что происходит, нужно следить вручную или нанимать аналитика. И то и другое медленно и дорого.

Параллельно у тех же команд нет инструмента, который умел бы подстроиться под их задачу. Городской мониторинг и продуктовая разведка по разговорам пользователей формально разные задачи, но по сути это одно и то же — слушать публичные обсуждения, размечать смысл, делать выводы. Существующие решения сделаны под одну нишу.

Моя роль

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

Отвечаю за продуктовую логику, набор типов отчётов и гибкость движка под новые ниши без переписывания.

Какие продуктовые решения определили платформу

• Параметризация вместо переписывания. Решение, что для нового применения (другой город, другой продукт) меняются источники, темы и набор типов отчётов через конфигурацию, а сам движок не переписывается. Это превращает работу с новой задачей из многонедельной разработки в настройку.
• Развитие функциональности по запросам пользователей. В первой версии было два типа отчётов: повестка недели и разбор обсуждений. Дальше добавлялись типы по запросу пользователей, с которыми работала на конкретных задачах. Карта связей между ключевыми игроками. Срочные алерты по триггерным событиям. Шаблоны ответов в помощь командам, которые работают с инфоповесткой. Каждый новый тип отчёта приходил из реальной потребности, а не из плана.
• Разные виды отчётов под разные роли пользователя. Решение, что городская пресс-служба и продуктовый менеджер — разные роли с разной задачей. Городу нужны повестка, игроки, карта связей, план работы. Продукту — топ-боли, топ-фичи, баг-репорты, конкуренты, рекомендации. Один движок, но разные шаблоны отчётов под каждую роль, без попытки сделать универсальный отчёт.
• Демо на реальных данных как способ показать продукт. Решение, что лучшее доказательство движка — открытый публичный отчёт, по которому можно кликать. Не презентация, не скрин, а работающий на реальных данных продукт. Три применения доступны как живые демо.

Три применения одного движка

Три применения доступны как живые публичные отчёты на реальных данных. Кликабельны, можно посмотреть структуру и логику.