Отдайте AI рутинное, верните человеку — человеческое

Весь стек за один день: от идеи до работающего бота

Контекст

День 1 проекта «Дневники навигация». Исследовательское агентство готовится запустить дневниковое исследование: 32 респондента в течение 7 дней будут фиксировать каждую поездку по городу в Telegram-группах. Методология сложная, команда распределённая, данных будет много.

Руководитель проекта — не разработчик. Опыт с кодом: нулевой. Инструмент: Cursor (IDE с AI-ассистентом). Задача: за один день собрать рабочую инфраструктуру, которая будет работать всю неделю поля.

---

Что было на старте

• Голосовое сообщение с описанием задачи: «хочу, чтобы был ботик в Телеге, который отвечает по методологии из базы знаний»
• Папка на Google Drive с методологией
• Ни одной строки кода
• Ни одного настроенного сервиса

Что было через 8 часов

• Telegram-бот, отвечающий на вопросы по методологии (/kb)
• Бот, собирающий записи дневников из чатов (текст, фото, аудио, кружочки)
• Автоматическая транскрипция голосовых сообщений
• Сохранение всего на Google Drive в структурированные папки
• Синхронизация дневников с локальным компьютером
• Автообновление базы знаний по расписанию
• Деплой на Render с автодеплоем из GitHub
• Система быстрых команд для управления всем этим

Как это стало возможным

Весь диалог — это ~5800 строк переписки в Cursor. Руководитель проекта описывала задачи голосовыми и текстом, AI-ассистент писал код, объяснял каждый шаг, дебажил ошибки по скриншотам и логам. Каждое решение принималось совместно: AI предлагал варианты, человек выбирал.

Ключевые принципы, которые сложились в процессе:

• «Всё, что можешь создать сам — создавай сам» — человек даёт только секреты (токены, ключи), AI делает остальное
• Пошаговое ведение — каждый скриншот пользователя → объяснение → следующий шаг
• Сначала commit + push, потом deploy — правило, которое родилось после путаницы с порядком действий

---

Зачем этот кейс

Это не история про то, как программист написал бота. Это история про то, как исследователь, никогда не писавший код, за один день получил рабочую инфраструктуру для полевого этапа.

Создали бота-базу знаний по методологии

Проблема

Методология дневникового исследования — это десятки страниц: как описывать проблемы и драйверы, что говорить на установочной встрече, как фиксировать находки, форматы записей, чек-листы, примеры и анти-примеры. Команда распределённая: исследователи, рекрутеры, заказчик.

Что было неудобно:

• Чтобы вспомнить формат описания проблемы, нужно открыть Google Drive, найти нужный файл, найти нужный раздел
• Исследователь в поле не будет этого делать — он спросит в чате и получит приблизительный ответ от коллеги
• Нет единого места, где можно быстро получить точную выдержку из методологии
• Новые участники команды вынуждены читать всё целиком

Что нужно:

• Бот в Telegram, которому можно задать вопрос на естественном языке
• Ответ из базы знаний, а не выдумка AI
• Ссылка на конкретный раздел/документ

---

Что мы сделали

Архитектура:

• Telegram Bot (BotFather → токен)
• FastAPI backend на Python
• OpenAI Responses API + vector store с методологией
• Команда /kb <вопрос> → ответ из базы знаний

Выбор модели: gpt-4.1-mini. Для FAQ-бота с retrieval — достаточно. Можно переключить одной строкой позже.

---

Зачем это нужно

Исследователям — спросить «как описываем барьер?» и получить точную выдержку из методологии за 3 секунды, не открывая Google Drive.

Руководителю проекта — не отвечать на одни и те же вопросы. Бот отвечает точнее, потому что цитирует документ, а не пересказывает по памяти.

Задеплоили бота: от «что такое GitHub» до работающего сервиса

Проблема

Код бота написан, но он лежит на локальном компьютере. Руководитель проекта никогда не деплоила приложения, не работала с GitHub.

Что мы сделали

Пошаговый процесс: GitHub → Git config → Push → Render → Webhook → Дебаг. Два бага решились за минуты (старая версия SDK, неоплаченный API).

Решение: Render Free. Задержки при пробуждении не критичны для исследовательского бота.

Настроили синхронизацию файлов между Google Drive и локальным диском

Google Drive for Desktop для методологии (двусторонняя синхронизация) + rclone для дневников (Drive → локальный диск, только копирование).

Научили бота собирать дневники из Telegram

Автоматический сбор всего контента из 32 чатов: текст, фото, аудио, видео → Google Drive в структурированные папки. Транскрипция через Whisper.

Выстроили систему команд и задокументировали пайплайн

Две ключевые команды: «я обновила методологию» и «синхронизируй дневники». Пайплайн-памятка для команды.

Научили бота собирать дневники из Telegram

Проблема

32 респондента будут вести дневники в Telegram-группах: текст, голосовые сообщения, фото, видео-кружочки. Каждый — в отдельном чате с исследователем. Это ~150–200 записей в день, раскиданных по 32 группам.

Что было неудобно:

• Информация живёт только в Telegram — если не сохранить, потеряется в потоке сообщений
• Ручное сохранение невозможно: 32 группы × 7 дней = сотни файлов
• Голосовые нужно переслушивать — нет текстовой расшифровки
• Нет структуры: где запись от конкретного респондента за конкретный день?

Что нужно:

• Автоматический сбор всего контента из чатов
• Сохранение на Google Drive в структурированные папки по респондентам и датам
• Автоматическая транскрипция аудио и кружочков
• Структурированные имена файлов

---

Варианты, которые рассматривали

1. Бот опрашивает историю чата 3 раза в день

Плюсы: можно задать расписание, ничего не пропустишь. Минусы: Telegram API не позволяет боту читать историю чата. Бот получает только то, что приходит в реальном времени через webhook.

Решение: отклонено. Это ограничение Telegram API — бот видит только новые сообщения.

2. Сбор в реальном времени через webhook (выбрали)

Плюсы: ничего не теряется, каждое сообщение обрабатывается сразу. Минусы: если сервер упал — сообщения потеряны (Telegram повторяет webhook несколько раз, но не бесконечно).

---

Проблема с Google Drive: «Мой диск» vs «Компьютеры»

Неожиданная трудность: сервисный аккаунт Google видит только «Мой диск», а Google Drive for Desktop синхронизирует файлы в раздел «Компьютеры». Это разные места.

Руководитель удивилась: «Бот, который у нас работает, он же будет нести на Google Диск, на мой диск, правильно?» — правильно, но не в «Компьютеры», а в «Мой диск».

Решение: создать папку для дневников в «Мой диск», расшарить её с сервисным аккаунтом. Но сервисный аккаунт не мог писать в личный Drive (нет Shared Drive на бесплатном аккаунте).

Финальное решение: OAuth-доступ вместо сервисного аккаунта. Получили refresh_token через скрипт авторизации, добавили в Render.

---

Что мы сделали

1. Отключили Privacy Mode В BotFather: /setprivacy → Disable. Без этого бот видит только команды (/kb), а обычные сообщения игнорирует.

2. Создали структуру папок 33 папки: по одной на каждого респондента + тестовая. Латиницей — кириллица вызывала ошибки. Подпапки с датами создаются автоматически при первом сообщении.

3. Настроили сбор всех форматов

Формат	Что делает бот	Что сохраняется
Текст	Сохраняет как .md	файл с текстом записи
Фото	Скачивает файл	фото в формате .jpg
Голосовое	Скачивает + транскрибирует	аудио + текстовый транскрипт
Кружочек	Скачивает + транскрибирует аудиодорожку	видео + текстовый транскрипт
Видео	Скачивает файл	видео в формате .mp4

Транскрипция — OpenAI Whisper (whisper-1).

4. Эволюция формата в процессе

• Первая версия: JSON. Руководитель: «формат JSON — наилучший для наших задач?» → нет, для исследователей нужен человекочитаемый формат
• Вторая версия: .txt. Руководитель: «txt мне не нравится, давай markdown»
• Финальная версия: .md для текста и транскриптов, медиа как есть

5. Нейминг файлов Первая версия: message_1.md, message_2.md. Руководитель попросила: «сначала имя респондента, потом дата, номер и время». Итог: структурированные имена с идентификатором респондента, датой и временем.

---

Тестирование

Тестировали на тестовой группе, где руководитель была «респондентом»:

1. Отправили текст → появилась папка с датой, но файлы пустые → логи → ошибка записи в Drive → OAuth не настроен → настроили → заработало
2. Отправили аудио → файл + транскрипт сохранились
3. Проверили кружочек → сохраняется

---

Как это работает

1. Респондент пишет в Telegram-группу (текст/фото/аудио/кружочек)
        ↓
2. Telegram отправляет webhook на Render
        ↓
3. Бот определяет респондента по chat_id
        ↓
4. Создаёт папку дня, если её нет
        ↓
5. Скачивает медиа-файл с серверов Telegram
        ↓
6. Если аудио/видео → отправляет в Whisper → сохраняет транскрипт
        ↓
7. Загружает всё в Google Drive в папку респондента
        ↓
8. По команде «синхронизируй дневники» → rclone копирует на локальный диск

---

Зачем это нужно

Исследователям — все записи респондента в одной папке, с транскрипциями. Не нужно переслушивать голосовые — текст уже есть.

Руководителю проекта — структурированный архив для анализа. Каждая поездка — в файле с понятным именем.

Для анализа — на основе этих данных потом будут строиться карточки мониторинга, таблица трекинга поездок и аналитические сводки.

Передача контекста между AI-сессиями

Проблема

К концу первого дня контекстное окно AI-ассистента в Cursor заполнилось: ~5800 строк диалога. Ассистент начал «забывать» ранние договорённости. Нужно было открыть новую сессию — но как передать ей всё, что было сделано?

Что мы сделали

Структурированное summary из 7 блоков: база знаний, бот, дневники, Render ENV, OAuth, rclone, правила. Руководитель скопировала summary в начало нового диалога — и новый агент сразу понял контекст.

Этот паттерн «передачи смены» позже превратился в постоянную систему: файл MEMORY.md (загружается автоматически при каждой сессии Claude Code) и CLAUDE.md (инструкции проекта).

Починили сбор дневников: 4 бага, 4 коммита

4 последовательных коммита, каждый по конкретной ошибке из логов Render:

1. JSON вместо MD на Drive
2. Фото/аудио игнорируются
3. UnboundLocalError: media_paths
4. Whisper: Invalid file format

Весь цикл «баг → фикс → деплой → проверка» занимал 3–5 минут на каждый баг.

Задержки на бесплатном Render: осознанный выбор «не чинить»

Решение «не чинить сейчас» сэкономило время для более важных задач. Три варианта оптимизации были готовы, но вместо того чтобы усложнять архитектуру заранее, выбрали мониторинг (YAGNI).

Переход из Cursor в Claude Code: новые горизонты дирижёра

В Cursor руководитель была оператором: AI говорил «нажми сюда», она нажимала. В Claude Code руководитель стала дирижёром: она говорит «обнови мониторинг» — и всё происходит.

Аспект	Cursor	Claude Code
Коммит и пуш	AI пишет код, просит сделать commit	AI делает commit + push сам
Запуск скриптов	«Вставь эту команду в PowerShell»	AI запускает скрипт напрямую
Контекст между сессиями	Ручное копирование summary	MEMORY.md загружается автоматически

Автор: руководитель проекта + Claude Code (Opus 4.6)

---

Проблема

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

Что было неудобно:

• Решения «берём / не берём» принимались по ощущению — рекрутер смотрел анкету и давал рекомендацию интуитивно
• Когда кандидатов много, критерии начинают плавать: первых оцениваешь строго, к двадцатому — устаёшь и пропускаешь нюансы
• Нет зафиксированного обоснования: если заказчик спрашивает «почему этого взяли, а того нет?» — ответ только в голове у рекрутера
• Ошибки классификации: рекрутер записала Пермь и Ростов в «крупные города» — по ощущению они большие, но по сетке проекта это «средние». Без формализации такие ошибки не ловятся
• Результаты оценки нигде не хранились структурированно — невозможно вернуться и сравнить кандидатов

Что нужно:

• Формализованная рубрика: что именно оцениваем, по какой шкале, с каким весом
• Автоматический расчёт баллов по данным анкеты
• Текстовое обоснование по каждому кандидату — разбивка по критериям
• Результаты в таблице расписания интервью: рекрутер и руководитель видят балл, рекомендацию и комментарий прямо в рабочем документе

---

Варианты, которые рассматривали

1. Ручная оценка рекрутером

Плюсы: быстро, не нужны инструменты. Опытный рекрутер чувствует «своего» кандидата. Минусы: невоспроизводимо (два рекрутера оценят одного человека по-разному), нет обоснования для заказчика, ошибки классификации не ловятся, усталость при большом потоке.

Решение: отклонено как единственный метод. Но живая экспертиза рекрутера сохраняется на следующих этапах (дозвон).

2. Балльная рубрика + скрипт автоматического скоринга (выбрали)

Плюсы:

• Каждый кандидат оценивается по одним и тем же критериям с одними и теми же порогами
• Числовой балл + текстовое обоснование — можно показать заказчику
• Скринеры (ходоки, профессиональное использование, конфликт интересов) проверяются автоматически — ни один не проскочит
• Ошибки классификации ловятся: скрипт знает, что Пермь = «средний», и не пропустит
• Результаты записываются в Excel — рекрутер видит их в привычном рабочем документе

Минусы: нужно время на разработку рубрики и скрипта. Скрипт не видит того, что видит живой рекрутер (интонацию, мотивацию, нюансы). Поэтому это дополнение к рекрутеру, а не замена.

---

Что мы сделали

1. Разработали 25-балльную рубрику из 8 критериев

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

Ключевое решение: ситуативные пользователи (используют инструмент не всегда, а в зависимости от контекста) получают максимальный балл по поведенческому профилю. Не «всегда» (предсказуемый, без барьеров) и не «никогда» (мало материала), а именно тот, кто иногда включает, иногда нет. У него самые интересные переключения и триггеры.

2. Написали скрипт автоматического скоринга

Скрипт на Python (+ openpyxl):

• Читает анкеты из Excel
• Применяет все 8 критериев
• Проверяет жёсткие скринеры: профессиональные панелисты, профессиональное использование предмета исследования, сотрудники заказчика, неготовность к формату
• Записывает в Excel три колонки: комментарий (разбивка по критериям), рекомендацию, балл

Пороги: >=18 = рекомендован, 15–17 = условно (уточнить при звонке), <15 = не рекомендован.

3. Перенесли результаты в таблицу расписания интервью

Через скрипты обновления результаты скоринга записывались в рабочую таблицу рекрутера — файл расписания интервью. Пять колонок: ГЕО-сегмент, квота, комментарий с обоснованием, рекомендация, числовой балл. Рекрутер открывает привычный документ и видит по каждому кандидату: почему он получил такой балл, на что обратить внимание при звонке.

4. Связали автоматику с живой экспертизой

Скоринг — это первый фильтр. Дальше рекрутер звонит кандидатам из зон «рекомендован» и «условно» и проверяет то, что скрипт не поймает:

• Совпадает ли анкета с тем, что человек рассказывает голосом
• Мотивация: интересен опыт или только вознаграждение
• Артикулированность: может ли описать свой опыт своими словами

Если скоринг пометил что-то как «уточнить при звонке» — рекрутер целенаправленно проясняет именно это.

---

Зачем это нужно

1. Рекрутеру — не гадать «берём или нет», а видеть числовой ориентир и конкретные флаги для дозвона. Фокусировать время на кандидатах из зоны «условно», а не пересматривать всех.
2. Руководителю проекта — объяснить заказчику, почему выборка выглядит именно так. Показать рубрику, баллы, обоснования — вместо «мы считаем, что эти подходят».
3. Проекту — ловить ошибки классификации (города, поведенческие паттерны) до того, как кандидат попадёт в выборку. Одна такая ошибка = сломанная квота.
4. Команде — единый язык: «рекомендован 21/25» понятнее, чем «вроде норм».

---

Как это работает

1. Кандидат заполняет скрининговую анкету
        ↓
2. Данные попадают в Excel (Предварительный отбор)
        ↓
3. Скрипт прогоняет 8 критериев + скринеры
        ↓
4. В Excel записываются: балл, рекомендация, комментарий по критериям
        ↓
5. Результаты переносятся в таблицу расписания интервью
        ↓
6. Рекрутер видит балл и флаги → звонит кандидату с конкретными вопросами
        ↓
7. Финальное решение: скоринг + впечатление рекрутера от звонка

Автор: руководитель проекта + Claude Code (Opus 4.6)

---

Проблема

На второй день полевого этапа исследования у нас 6 активных респондентов (+ 1 тестовый), каждый из которых фиксирует по 1–5 поездок в день. За неделю это ~150–200 записей в Telegram-группах.

Что было неудобно:

• Записи разбросаны по 32 отдельным Telegram-группам
• Чтобы понять, что происходит с конкретным респондентом, нужно перечитать все его сообщения за все дни
• Нет единого места, где исследователь видит картину по респонденту: что уже поняли, что нового за день, что стоит доспросить
• Руководитель проекта не может быстро оценить прогресс по всем респондентам
• Подготовка к глубинному интервью требует ручной сводки по каждому человеку

Что нужно:

• Компактная карточка по каждому респонденту, обновляемая ежедневно
• Видны паттерны, барьеры, драйверы, расхождения с квотой
• Привязка к бизнес-задачам исследования
• Вопросы для интервью — конкретные, с привязкой к поездкам
• Доступ для всей команды, но закрытый от посторонних

---

Варианты, которые рассматривали

1. Автоматическая генерация на сервере (GPT-4.1-mini на Render)

Плюсы: полностью автоматически, без участия человека. Минусы: GPT-4.1-mini слишком слабая модель для качественного исследовательского анализа. Поверхностные выводы, нет глубины, не выловит тонкие паттерны. Нужен как минимум GPT-4 или Claude Opus — а это требует API-ключ и дополнительные расходы.

Решение: отложено. Не тот уровень качества для исследовательского анализа.

2. Claude API на сервере (Anthropic API на Render)

Плюсы: высокое качество анализа (Claude Opus), автоматически по расписанию. Минусы: нужен API-ключ Anthropic (отдельная оплата), настройка промптов, дополнительные расходы на каждый запрос.

Решение: отложено. Нет API-ключа, и на данном этапе это избыточно.

3. Claude Code на компьютере исследователя (выбрали)

Плюсы:

• Максимальное качество анализа (Claude Opus 4.6 — самая сильная модель)
• Никаких дополнительных расходов (входит в подписку Claude)
• Полный контроль: человек видит и может поправить результат
• Гибкость: можно запросить анализ по одному респонденту или по всем

Минусы: не полностью автоматически — нужно запустить руками. Но это 1 минута: открыть Claude Code → написать «обнови мониторинг» → готово.

Хранение карточек: Google Drive vs Git

Изначально планировали загружать карточки на Google Drive. Но сервисный аккаунт Google не может создавать файлы (нет квоты хранилища).

Итоговое решение: карточки хранятся в репозитории бота, при пуше в main Render автоматически деплоит обновлённый сайт. Дополнительно копия сохраняется локально.

---

Что мы сделали

1. Расширили скилл UX-аналитика (7 → 9 режимов)

Добавлены два новых режима:

• Режим 8 — Карточка мониторинга респондента. Компактный живой документ: кто это, что видим (паттерны, барьеры, драйверы, расхождения), что значит для бизнеса, что доспросить, хронология поездок. Обновляется ежедневно, каждое обновление = дельта.

• Режим 9 — Дневная сводка инсайтов. Telegram-пост для команды: кросс-респондентный анализ за день, ключевые находки, тренды, задачи для исследователей. (Пока не реализован технически, формат готов.)

2. Создали утилиты мониторинга

Скрипт для мониторинга:

• Синхронизация дневников с Google Drive
• Чтение записей по респонденту и дате
• Сохранение карточек в два места (локально + для веб-сайта)
• CLI-интерфейс для отладки

3. Создали веб-страницу мониторинга

Защищённая страница мониторинга:

• Вход по паролю (отдельный от пароля респондентов)
• Вкладки по респондентам: «R-01, пешеход, Воронеж»
• Карточки отрендерены из Markdown в HTML
• Адаптивный дизайн для мобильных
• Прямая ссылка на респондента по идентификатору

4. Сгенерировали карточки для респондентов

У каждого респондента — своя карточка мониторинга. В ней: профиль, накопленные паттерны, барьеры и драйверы, ключевые инсайты за каждый день и вопросы для глубинного интервью. Карточки обновляются ежедневно по мере поступления новых записей.

---

Зачем это нужно

1. Исследователям — видеть накопленное понимание по респонденту перед тем, как задавать вопросы. Не перечитывать все записи заново, а открыть карточку и за 2 минуты понять картину.

2. Руководителю проекта — быстро оценить прогресс: у кого интересные паттерны, у кого мало данных, где расхождения с квотой.

3. Подготовка к интервью — блок «Что доспросить» с привязкой к конкретным поездкам = готовая основа для гайда глубинного интервью.

4. Для заказчика — блок в каждой карточке показывает, что находки значат для продукта.

---

Как это работает (техническая цепочка)

1. Респонденты пишут в Telegram-группы
        ↓
2. Бот сохраняет записи на Google Drive
        ↓
3. Claude Code синхронизирует дневники на локальный компьютер
        ↓
4. Claude Code (Opus 4.6) читает записи и генерирует/обновляет карточки
        ↓
5. Карточки сохраняются локально и в репозитории для сайта
        ↓
6. Git push → Render автодеплой → сайт обновлён
        ↓
7. Команда открывает страницу мониторинга

Создали таблицу трекинга поездок в Google Sheets

Проблема

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

Что было неудобно:

• Нет единого хранилища, где каждая поездка — отдельная строка с полным контекстом
• Нельзя быстро отфильтровать: «покажи все поездки без навигации на знакомых маршрутах» или «покажи все барьеры»
• Информация по одной поездке может накапливаться 1–2 дня (респондент записал поездку, исследователь задал вопросы, респондент ответил на следующее утро) — негде это собрать воедино
• Исследователи не могут видеть аналитику и оставлять комментарии в одном месте
• Нет структурированного аналитического слоя: тип инсайта, сила влияния, группа функционала, вопросы к интервью

Что нужно:

• Таблица с полными данными каждой поездки + аналитическим слоем
• Фильтрация по любому параметру (тип маршрута, навигация да/нет, приложение, тип инсайта)
• Доступ для исследователей с возможностью комментирования
• Ежедневное обновление: новые поездки, дополнения к старым, обработка комментариев
• Колонка «Полный текст» — ВСЯ информация по поездке без сокращений

---

Варианты, которые рассматривали

1. Локальный Excel/CSV

Плюсы: просто создать, привычный формат. Минусы: нет совместного доступа, исследователи не видят и не могут комментировать. Нужно пересылать файл после каждого обновления.

Решение: не подходит. Командная работа важнее.

2. Google Sheets с ручным заполнением

Плюсы: совместный доступ, комментарии, фильтры. Минусы: ручное заполнение ~30 колонок на каждую поездку — нереалистично при 5–10 поездках в день. Аналитический слой требует экспертного заполнения по таксономии.

Решение: не подходит. Слишком трудоёмко вручную.

3. Google Sheets + автоматическое заполнение через Claude Code (выбрали)

Плюсы:

• Совместный доступ для команды (комментарии)
• Автоматическое заполнение из сырых дневников (Claude Code читает записи, разбирает на поездки, заполняет все колонки)
• Аналитический слой заполняется по таксономии инсайтов (8 типов) с привязкой к аналитической рамке проекта
• Ежедневное обновление одной командой: «трекай таблицу»
• Комментарии исследователей обрабатываются интерактивно

Минусы: заполнение не полностью автоматическое — нужно запустить руками. Но это та же модель, что и с мониторингом: команда → результат.

---

Что мы сделали

Создали отдельный скилл Claude Code (diary-tracking)

Скилл отделён от аналитического — разные роли, разные ритмы. Аналитик глубоко разбирает записи. Data-инженер структурирует их в таблицу.

Три режима работы:

• Режим 1 — Первичное создание вкладки респондента (один раз)
• Режим 2 — Ежедневное обновление (~12:00 МСК): новые поездки + дополнения + комментарии
• Режим 3 — Подготовка к интервью (конец недели): финализация сводки, расхождения, приоритетные вопросы

Спроектировали структуру таблицы

Одна вкладка = один респондент. Три зоны на вкладке:

Зона	Колонки	Что содержит
Портрет (sidebar)	A–D	Карточка респондента: сегмент, город, квота, стиль, исследователь
Таблица поездок	E–V	18 колонок: маршрут, цель, контекст, навигация, транскрипция, полный текст
Аналитический слой	W–AD	8 колонок: тип инсайта, формулировка, сила, группа функционала, вопрос к интервью

Плюс сводка по респонденту (паттерны, барьеры, драйверы, расхождения) — в отдельных колонках справа.

Протестировали на одном респонденте

• 2 дня дневника, 7 поездок
• 51 файл записей (текст, голосовые транскрипции, диалоги с исследователем)
• Все данные разобраны и записаны в таблицу, включая полные тексты голосовых

Итерировали лейаут по обратной связи

Первый вариант: портрет вверху (10 строк), потом пустые строки, потом таблица. Проблема: таблица не помещается на экране, неудобно.

Второй вариант: портрет — компактный сайдбар слева (колонки A–D, закреплены). Таблица поездок начинается с первой строки. Строка заголовков с фильтрами закреплена. Всё видно сразу при открытии.

Оповестили команду

Отправили в командный чат инструкцию: что в таблице, как устроена, как оставлять комментарии, порядок ежедневного обновления.

---

Как это работает

1. Респонденты пишут в Telegram → бот сохраняет на Google Drive
2. Claude Code синхронизирует дневники на локальный компьютер
3. Claude Code читает записи, разбирает на поездки (шаблон 9 пунктов + голосовые + диалоги)
4. Каждая поездка → строка в Google Sheets (все 26 колонок)
5. Аналитический слой заполняется по таксономии инсайтов проекта
6. Исследователи открывают таблицу, фильтруют, оставляют комментарии
7. При следующем обновлении комментарии обрабатываются интерактивно (руководитель проекта решает, что с каждым делать)

Ежедневный цикл (~12:00 МСК):

• Команда «трекай таблицу» → синхронизация дневников → разбор новых поездок → обновление строк (включая дополнения к старым поездкам) → обновление аналитики → обработка комментариев → отчёт

---

Зачем это нужно

Для финального отчёта — структурированные данные по каждой поездке с аналитическим слоем. Не нужно перечитывать 500+ сообщений — всё в одной таблице с фильтрами.

Для подготовки к интервью — сводка по респонденту + приоритизированные вопросы с привязкой к конкретным поездкам. Открыл вкладку — готов к интервью.

Для исследователей — возможность видеть аналитику и влиять на неё через комментарии. Не «чёрный ящик», а совместная работа.

Для кросс-респондентного анализа — одинаковая структура по всем респондентам позволит в конце проекта сравнивать, группировать и строить типологии.

Отличие от мониторинга — мониторинг даёт быструю картину «что происходит». Таблица даёт полные данные «что именно и почему» — для глубокого анализа и отчёта.

Автор: руководитель проекта + Claude Code (Opus 4.6)

---

Проблема

На четвёртый день полевого этапа запущено 16 из 32 дневников. Рекрутеры набирают респондентов по квотной матрице с несколькими измерениями — целевое число респондентов в каждой ячейке.

Что было неудобно:

• Чтобы понять текущее состояние квот, нужно открыть файл «Профили респондентов», вручную посчитать, сколько человек в каждой ячейке матрицы, и сравнить с целевыми числами
• У рекрутеров нет быстрого способа узнать, кого не хватает — нужно спрашивать руководителя
• Скоринг кандидатов (25-балльная система, 8 критериев) делался скриптом один раз на этапе отбора. Оценить нового кандидата на лету невозможно — нужно поднимать скрипт, разбираться в колонках Excel
• Создание профиля нового респондента — ручная работа: найти данные в Excel, заполнить шаблон, обновить сводную таблицу, пересчитать квоты
• Нет проверки, что для каждого запущенного дневника есть профиль (и наоборот)

Что нужно:

• Мгновенный отчёт о квотах по команде — в Telegram, для всей команды
• Возможность оценить кандидата по 8 критериям за 1 минуту
• Автоматизация создания профилей и обновления квотного контроля
• Кросс-проверка: папки дневников ↔ профили ↔ таблица трекинга

---

Варианты, которые рассматривали

1. Только команда бота /квоты

Плюсы: быстро реализовать, доступно всей команде в Telegram, не требует Claude Code. Минусы: показывает только текущее состояние. Не помогает оценить кандидата, создать профиль или найти расхождения. Отчёт статичный — парсит готовый файл, не анализирует.

Решение: частично — реализовали как быстрый инструмент для команды.

2. Только Claude Code скилл

Плюсы: глубокий анализ, скоринг, создание профилей, кросс-проверка — всё в одном месте. Минусы: доступен только тому, у кого запущен Claude Code. Рекрутеры и администраторы не увидят отчёт без руководителя.

Решение: частично — реализовали для аналитических задач.

3. Команда бота + Claude Code скилл (выбрали)

Плюсы:

• Два уровня: быстрый (бот, /квоты → HTML-отчёт за 3 секунды) и глубокий (скилл, 5 режимов анализа)
• Бот доступен всем 6 членам команды в Telegram
• Скилл решает задачи, которые бот не может: скоринг, профилирование, кросс-проверка
• Единый источник данных — файл «Профили респондентов.md» на Google Drive

Минусы: два инструмента вместо одного — нужно помнить, когда что использовать.

---

Что мы сделали

1. Команда бота /квоты

Новый модуль для Telegram-бота:

• Скачивает «Профили респондентов.md» с Google Drive (file_id из конфига)
• Парсит Markdown-таблицу: RESP, ФИО, сегмент, город, ГЕО, квота, статус
• Сравнивает с целевой матрицей (12 ячеек: 2×2×3)
• Генерирует HTML-отчёт с эмодзи, цветовой индикацией (зелёный / жёлтый / красный) и списком дефицитов
• Отправляет в чат, откуда вызвана команда

Изменены 5 существующих файлов: обработчик команды, распознавание команды, конфиг Google Drive, метод скачивания, зависимости (openpyxl).

2. Скилл recruitment-analyst (5 режимов)

Режим	Триггер	Что делает
1. Скоринг кандидата	«оцени кандидата»	8 критериев из скорингового скрипта, таблица баллов, рекомендация по порогам
2. Анализ квот	«проверь квоты»	Парсит профили, сопоставляет с матрицей, находит дефициты и перекосы
3. Создание профиля	«создай профиль»	Берёт данные из Excel/рекрутера, заполняет шаблон, обновляет квотный контроль
4. Кросс-проверка	«кросс-проверка»	Сверяет папки дневников с профилями: кто есть, кого нет
5. Генерация поста	«напиши пост для рекрутеров»	Человечный HTML-пост для командного чата

4 reference-файла: скоринговая система (25-балльная), квотная матрица (целевая), шаблон профиля, структура Excel-файлов.

3. Подключение скилла write-case-study

Обнаружили, что скилл для написания кейсов лежал в корне проекта, а не в .claude/skills/. Переместили — скилл подхватился автоматически.

4. Обновление справочника команд

Таблица команд расширена с 5 до 10 строк + отдельная секция команд Telegram-бота.

---

Зачем это нужно

1. Рекрутерам — видеть дефициты квот прямо в Telegram за 3 секунды (/квоты), без доступа к Claude Code.
2. Руководителю проекта — оценивать новых кандидатов по 8 критериям за 1 минуту вместо ручного анализа Excel.
3. Исследователям — кросс-проверка: быстро найти респондентов без профиля или профили без записей.
4. Команде — единый справочник из 10 команд + 5 команд бота. Не нужно помнить, что где — достаточно сказать «напомни команды».

---

Как это работает

/квоты в Telegram

1. Член команды пишет /квоты в командный чат
        ↓
2. Бот скачивает «Профили респондентов.md» с Google Drive
        ↓
3. Парсит таблицу, классифицирует по квотной матрице
        ↓
4. Генерирует HTML-отчёт с дефицитами
        ↓
5. Отправляет в чат (3 секунды)

Скилл рекрутера в Claude Code

1. Руководитель говорит «оцени кандидата» / «проверь квоты» / ...
        ↓
2. Claude Code подгружает скилл recruitment-analyst
        ↓
3. Читает данные из Excel / профилей / папок дневников
        ↓
4. Применяет 25-балльный скоринг / квотную матрицу / шаблон профиля
        ↓
5. Выдаёт структурированный результат

Экспресс-анализ кандидатов рекрутера

Проблема

День 4 полевого этапа. Рекрутер присылает в рабочий чат список из 8 кандидатов с просьбой проверить, «все ли гео подходят». Кажется простым — но на деле нужно одновременно держать в голове:

Что сложно сделать вручную:

• Вспомнить, какие города считаются «крупными» по нашей сетке
• Посчитать, сколько слотов свободно в каждой из 6 ячеек квотной матрицы для пешеходов
• Проверить географический баланс: из каких городов уже есть респонденты, где перебор, где пусто
• Сформулировать чёткую рекомендацию: кого берём, кого нет, что ещё нужно найти

Оценка трудозатрат: ~30 минут ручной работы — открыть профили, квотную матрицу, портрет ЦА, посчитать, перепроверить, написать ответ.

---

Варианты, которые рассматривали

1. Ответить «на глаз» из головы

Плюсы: мгновенно, не нужны инструменты. Минусы: легко ошибиться. Именно так рекрутер записала Пермь и Ростов в «крупные» — по ощущению они большие. Ошибки в классификации ведут к перекосу квот, который обнаружится только в конце.

Решение: отклонено. Слишком высокий риск ошибки при 12 ячейках и 16 переменных.

2. Ручной анализ: открыть все документы, посчитать

Плюсы: точно, надёжно. Минусы: ~30 минут работы. Руководитель проекта тратит время на механическую работу вместо исследовательской.

Решение: так делали до этого момента.

3. Claude Code: загрузить контекст и получить анализ (выбрали)

Плюсы:

• Весь контекст проекта уже в рабочей директории: квотная матрица, профили, портрет ЦА
• Анализ за 5 минут вместо 30
• Находит неочевидные конфликты (дубль по городу, конкуренция за один слот)
• Сразу формулирует пост для рекрутера

Минусы: нужно проверить результат — AI может ошибиться в нюансах. Но проверить готовый анализ быстрее, чем делать с нуля.

---

Что мы сделали

1. Попросили Claude Code проанализировать список кандидатов

Скопировали сообщение рекрутера из Telegram в Claude Code: «Посмотри на респондентов, дай рекомендацию».

Claude Code автоматически:

• Прочитал квотную матрицу из модуля квот
• Прочитал текущие профили из файла профилей
• Прочитал портрет ЦА из базы знаний
• Посчитал заполнение каждой ячейки
• Классифицировал города кандидатов
• Нашёл конфликты

2. Обнаружили ошибку классификации

Рекрутер записала всех четырёх кандидатов на «крупный город» — но двое по нашей сетке попадают в «средний/малый». Это не интуитивно: оба города — миллионники.

Без проверки: 4 кандидата ушли бы в одну ячейку, 2 из них — в неправильную.

3. Человеческий мозг обогащает AI: гендер и возраст

После того как анализ был готов и посты отправлены, руководитель рекрутинга обратила внимание на то, что AI не предусмотрел: гендерный и возрастной баланс выборки.

Формально в договорённости с заказчиком нет требования к равному распределению по полу и возрасту. Поэтому ни квотная матрица, ни скилл рекрутера, ни Claude Code этот параметр не отслеживали. Но руководитель рекрутинга — опытный рекрутер — заметила перекос интуитивно.

Что показала проверка:

В текущей выборке был заметный перекос по гендеру — значительное преобладание одного пола. По возрасту: одна возрастная группа не была представлена вообще, а другая была перепредставлена.

Это не ошибка — так сложилось по скринингу. Но если не следить, перекос будет нарастать.

Claude Code быстро нашёл возрасты всех 8 кандидатов в скрининговом Excel и построил прогноз.

Что изменилось в рекомендации:

Один из запасных респондентов поднялся до рассмотрения, так как он попадал в уникальную квотную ячейку, которая до этого не была представлена в выборке.

Почему это важно для кейса:

AI отработал задачу в рамках формализованных критериев (квоты, гео, ячейки). Но человек — руководитель рекрутинга — увидел то, что не было в ТЗ: демографический баланс. Это классический пример того, как человеческий мозг задаёт направление, а AI ускоряет исполнение. Без руководителя рекрутинга мы бы не посмотрели на пол и возраст. Без Claude Code проверка заняла бы ещё 30 минут вместо 5.

---

Зачем это нужно

1. Руководителю проекта — 5 минут вместо 30 на анализ батча кандидатов. Время уходит на проверку результата, а не на механический подсчёт.
2. Рекрутеру — понятный ответ: кого берём, кого нет, почему. Плюс обучающий пост про классификацию городов — ошибка больше не повторится.
3. Проекту — предотвращена ошибка квотирования. Два кандидата из средних городов не попали в ячейку «крупный» — квоты остались валидными.
4. Команде — замечание руководителя рекрутинга про гендер и возраст вскрыло слепое пятно: формализованные критерии не покрывают все аспекты качества выборки.

---

Как это работает

1. Рекрутер присылает список кандидатов в рабочий чат
        ↓
2. Руководитель копирует сообщение в Claude Code
        ↓
3. Claude Code читает квотную матрицу + профили + портрет ЦА
        ↓
4. Анализ: классификация городов, подсчёт слотов, поиск конфликтов
        ↓
5. Руководитель проверяет и корректирует рекомендации
        ↓
6. Команда дополняет: гендер, возраст, другие неформализованные критерии
        ↓
7. Готовые посты отправляются в рабочий чат

---

Метрики (интервью 2026-02-16)

━━━ Расчёт D4-EXPRESS ━━━━━━━━━━━━━━━━━━━━━━━━━━━

  Было:  ~35 мин × 3 батча = 105 мин ≈ 1.75 ч (исследователь)
  Стало: ~5 мин × 3 батча = 15 мин = 0.25 ч (руководитель + Claude Code)
  Частота: 3 раза за проект

  Экономия: 1.75 - 0.25 = 1.5 ч
  Бонус: поймана ошибка классификации городов,
         которую вручную бы пропустили.

  → HRS saved: 1.5 ч
  → PPL involved: 1 (исследователь — освобождён)
  → Confidence: high

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Дневная аналитическая сводка (режим 9)

Проблема

14 респондентов ведут дневники 1–2 дня. Карточки мониторинга обновлены, таблица трекинга заполнена. Но у команды нет общей картины: что происходит в исследовании в целом, какие паттерны формируются, что это значит для продукта.

Что было неудобно:

• Нет регулярной аналитической сводки по всем респондентам — только отдельные карточки
• Руководитель видит детали, но команда не видит кросс-респондентные выводы
• Непонятно, какой уровень уверенности уместен на ранних днях (гипотеза vs тенденция)
• Рекомендации исследователям дублируются в разных местах

Что нужно:

• Ежедневный пост с кросс-респондентным анализом для команды
• Формат, откалиброванный под стадию исследования (дни 1–3 vs дни 5–7)
• Привязка к бизнес-задачам исследования, а не просто перечисление поездок

---

Что мы сделали

Запустили режим 9 и прошли 4 итерации правок с руководителем

Итерация	Было	Стало	Принцип
1	«дни 1–3»	«дни 1–2 дневников»	Точность: день проекта ≠ день дневников
2	Блок «Тенденции»	«Первые наблюдения и гипотезы»	На 1–2 день данных мало для тенденций
3	«Расхождение квот — системное»	«Понятие навигации размыто»	Фрейминг: инсайт, а не проблема
4	Блок «На заметку исследователям»	Ссылка на мониторинг	Не дублировать карточки

Зафиксировали 3 новых принципа в промпте:

• Калибровка уверенности: дни 1–3 = гипотезы, дни 4–5 = подтверждается, дни 6–7 = устойчивый паттерн
• Фрейминг под аудиторию: одна и та же находка может звучать как проблема или как инсайт — выбирай фрейм, который передаёт суть
• Не дублировать мониторинг: рекомендации по респондентам — в карточках на сайте, в пост — только ссылка

Обновлён промпт для режима дневной сводки: шаблон формата, секция «Первые дни», принципы №6–8.

---

Зачем это нужно

Команде — видеть общую картину исследования каждый день за 3 минуты чтения.

Руководителю — 10 минут на ревью сводки вместо 60 минут на написание. Правила калибровки зафиксированы — следующие сводки точнее сразу.

Для проекта — единый ритм коммуникации: ежедневная сводка + мгновенный доступ к ресурсам.

Команды быстрого доступа для бота

Проблема

Закрепов в рабочем чате накопилось столько, что найти нужную ссылку (таблицу, инструкцию, расписание) — квест. Пароли от сайта, ссылки на Google Drive документы, роли — всё разбросано по переписке.

Что нужно:

• Мгновенный доступ к любой ссылке проекта по команде бота
• Безопасность: внутренние ссылки и пароли не должны попасть в группы респондентов

---

Что мы сделали

5 новых команд бота — простые, без обращений к API, отдают статический HTML.

Ограничение по безопасности: команды работают только в рабочем чате. В группах респондентов бот их молча игнорирует — пароли и внутренние ссылки не утекут.

---

Зачем это нужно

Всей команде — получить любую ссылку проекта за 3 секунды прямо в Telegram вместо поиска в закрепах.

Для безопасности — пароли от мониторинга и внутренние документы доступны только в рабочем чате, не в группах респондентов.

Итого в боте: 6 команд для команды + 3 служебные.

Источник правды — как мы проверяли, опираемся ли на надёжные данные

Проблема

На пятый день полевого этапа рекрутер сообщил, что квота одного из респондентов не совпадает с тем, что у нас в системе.

Начали разбираться и обнаружили системную проблему: мы брали квоты из одной колонки, но эта колонка заполнялась до голосового скрининга. После звонка данные обновлялись на другом листе, а колонка оставалась старой.

Гипотеза: часть наших квот была основана на предварительных, а не финальных данных.

---

Варианты, которые рассматривали

1. Доверять нашему алгоритму скоринга

Плюсы: алгоритм объективен, работает по формулам из анкетных данных. Минусы: алгоритм анализирует текст анкеты, а не живой разговор. Навигационное поведение — не бинарная характеристика: человек может искренне ответить по-разному в зависимости от формулировки.

Решение: отвергнут — алгоритм полезен для первичного скрининга, но не может быть источником правды.

2. Доверять колонке от рекрутера

Плюсы: данные в структурированном виде, легко парсить. Минусы: заполняется до голосового скрининга. Руководитель рекрутинга прямо сказала: «эту колонку я заполняла до скрина, она ненадёжна».

Решение: отвергнут.

3. Лист «Квотирование» как единственный источник правды (выбрали)

Плюсы: заполняется после финального голосового скрининга, отражает итоговое решение рекрутера. Структурирован по квотным ячейкам — сразу видно, кто в какой группе. Минусы: нужно каждый раз открывать Excel и сверять вручную.

Решение: приняли. Формализовали правило и встроили в пайплайн.

---

Что мы сделали

Аудит всех 26 респондентов. Сверили квоты каждого запущенного с листом квотирования.

Каскадное обновление. Исправили квоты во всех местах, где они хранятся.

Формализовали правило. В конфигурацию проекта и скилл добавлен раздел «Источник правды»:

• При создании профиля нового респондента → найти ФИО на листе квотирования → взять квоту оттуда
• Если ФИО не найдено → сообщить руководителю

---

Зачем это нужно

Для достоверности данных — квота респондента определяет, в какую аналитическую группу он попадает. Неправильная квота → неправильная интерпретация его поведения в дневнике.

Для команды — теперь у каждого, кто работает с квотами, есть однозначный ответ: «где посмотреть правильную квоту?» Не нужно гадать, какой из трёх источников актуален.

Для будущих проектов — урок: в рекрутинге данные проходят несколько стадий (анкета → предварительный анализ → голосовой скрининг → финальное решение). На каждой стадии оценка может измениться. Нужно точно знать, на какой стадии фиксируется «правда».

---

Как это работает

1. Рекрутер проводит голосовой скрининг кандидата
2. По итогам заполняет лист «Квотирование» в файле расписания интервью
3. При создании профиля респондента Claude Code читает лист «Квотирование» через openpyxl
4. Квота из листа → профиль → карточка мониторинга → таблица трекинга
5. Периодическая сверка: профили ↔ лист квотирования (ручная или по запросу)

Карта фича-реквестов из дневников — как извлечь продуктовые запросы из качественных данных

Проблема

На третий день полевого этапа (26 респондентов, ~100+ записей о поездках) в данных накапливаются неявные запросы на функциональность: люди описывают неудобства, обходные пути, переключения между приложениями — но эти сигналы разбросаны по записям.

• Фича-реквесты не формулируются явно — респондент описывает поездку, а запрос на фичу подразумевается
• Записи 26 респондентов в 26 разных дневниках — невозможно увидеть, какие запросы повторяются
• Нет разделения: что нужно разработать, а что уже есть, но пользователь не знает
• Контекст теряется
• У команды нет единого места для аналитических материалов (мониторинг = по респондентам, а не по темам)

---

Варианты, которые рассматривали

1. Ручной анализ исследователями

Плюсы: глубокое понимание контекста каждого респондента. Минусы: при 26 респондентах и ~100 записях — дни работы. Сложно удержать кросс-респондентную картину.

Решение: отвергнут. Слишком трудоёмко для промежуточного среза на 3-й день поля.

2. GPT-анализ на сервере (автоматически)

Плюсы: без участия человека, по расписанию. Минусы: GPT-4.1-mini не справляется с тонкой классификацией (фича-реквест vs проблема vs барьер). Не видит контекст скрининга. Не может отделить «незнание ценности» от реального запроса.

Решение: отвергнут. Качество анализа критично — это идёт заказчику.

3. Claude Code + страница анализа на сайте (выбрали)

Плюсы: максимальное качество анализа (Claude Opus), привязка к профилям и скринингу, гибкий формат (markdown → HTML с табами), масштабируемость (новый .md = новый таб). Минусы: запуск вручную. Но анализ — не ежедневная задача, а по запросу.

---

Что мы сделали

Извлекли фича-реквесты из всех дневников. Параллельно проанализированы дневники 26 респондентов (5 агентов, ~370 файлов). Для каждого запроса: кто, что хочет, зачем, что без этого, цитата.

Кластеризовали в 15 тем.

Создали страницу анализа на сайте. Вход по паролю, вкладки-табы, адаптивный дизайн. Цветовая схема — teal (#0d9488). Автообнаружение: новый .md в директории анализа → новый таб.

Настроили workflow. Руководитель проекта просит проанализировать → Claude Code анализирует → показывает результат → если да → .md, коммит, пуш, автодеплой.

---

Зачем это нужно

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

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

Для финальных интервью — список фич для проверки «незнания ценности» (Блок 4 гайда).

Для руководителя — возможность быстро запросить анализ по любой теме и сразу получить результат на сайте.

---

Как это работает

1. Руководитель проекта: «проанализируй фича-реквесты / барьеры / паттерны»
2. Claude Code читает дневники всех респондентов (параллельно)
3. Кластеризация + привязка к контексту + цитаты
4. Результат в чате → руководитель проекта решает
5. Если да → .md в директорию анализа → git push → Render автодеплой → новый таб на странице анализа

Автор: руководитель проекта + Claude Code (Opus 4.6)

---

Проблема

На шестой день полевого этапа дневникового исследования 32 респондента ведут дневники поездок в 32 отдельных Telegram-группах. Дневник длится 7 календарных дней, но каждый респондент стартовал в свою дату. Через 1–2 дня первые начнут завершать — и нужно планировать отбор на глубинные интервью.

Что было неудобно:

• Непонятно, кто на каком дне дневника: 32 респондента с 5 разными датами старта, считать в голове невозможно
• Не видно, кто завершает завтра — а к ним нужно срочно готовить интервью
• Нет общей картины по количеству поездок — кто пишет активно, а кто молчит
• Трое респондентов вообще непонятно стартовали или нет
• Решение об отборе 24 из 32 на интервью нужно принимать за 1–2 дня до окончания дневника, а инструмента для этого нет
• Ручная проверка каждого — открыть Telegram-группу, пролистать записи, посчитать дни — занимает ~30 минут на респондента, 32 × 30 мин = 16 часов. С автоматизацией — ~20 минут

Что нужно:

• Один экран со статусом всех 32 респондентов: день дневника, количество поездок, дата окончания
• Автоматический подсчёт: кто завершает через 1–2 дня (срочно) vs через 3–5 дней (можно подождать)
• Детектор поездок: сколько реальных поездок зафиксировано, по дням
• Секция отбора на интервью: кто обязателен (единственный в квотном сегменте), кого можно выбирать
• Запуск одной командой, результат за 5 секунд

---

Варианты, которые рассматривали

1. Google Sheets с ручным обновлением

Плюсы: привычный формат, команда может редактировать. Минусы: нужно вручную считать дни и поездки для каждого респондента. При 32 людях это 2+ часа работы, причём каждый день заново. Человеческий фактор — легко ошибиться в подсчёте.

Решение: отклонено. Не масштабируется при 32 респондентах и ежедневном обновлении.

2. Python-скрипт с автоматическим сканированием дневников (выбрали)

Плюсы:

• Сканирует локальную папку с дневниками за 2–3 секунды
• Автоматически определяет день дневника, считает поездки, вычисляет дедлайны
• Секция отбора на интервью с квотной логикой — не нужно помнить, кто в каком сегменте
• Одна команда в терминале

Минусы: зависит от синхронизации дневников с Google Drive (нужно синкнуть перед запуском). Детектор поездок приблизительный (~80% точности) — считает на основе паттернов текста, не на основе ручной разметки.

---

Что мы сделали

1. Детектор поездок (три метода)

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

Реализовали три метода детекции, применяемых последовательно.

Точность: ~80%. Для задачи «общая картина прогресса» этого достаточно.

Ключевой инсайт от руководителя проекта: «Благодаря тому, что исследователи активно задавали дополнительные вопросы, даже на одной поездке удалось получить очень много важного контекста. Это полезно для целей исследования и целей бизнеса.»

2. Секция отбора на интервью

Из 32 респондентов нужно отобрать 24 на финальное глубинное интервью. Скрипт автоматически раскладывает по квотной сетке и определяет три уровня: кого нельзя отсеять (единственный в сегменте), кого лучше оставить, и где можно выбирать. Руководитель принимает решение, видя всю картину.

4. Формат вывода

Компактная ASCII-таблица в терминале: все 32 респондента на одном экране, сгруппированные по типу (пешеходы / водители). Колонки: код респондента, город, день N/7, количество поездок, дата окончания, осталось дней, поездки по дням.

Критически важное UX-решение: !! рядом с «осталось дней» для тех, кто завершает через ≤2 дня. Это визуальный маркер срочности.

---

Зачем это нужно

1. Руководителю проекта — видеть прогресс всех 32 респондентов за 5 секунд вместо 16 часов ручной проверки. Принимать решения об отборе на интервью, опираясь на данные.
2. Исследователям — понимать, кто завершает через 1–2 дня и к кому срочно готовить вопросы для интервью.
3. Админам групп — видеть, кто молчит (0 поездок за день) и кого нужно подтолкнуть.
4. Процессу отбора — квотная сетка автоматически показывает, кого нельзя отсеять. Без этого легко случайно убрать единственного представителя сегмента.

---

Как это работает

1. Синхронизация дневников с Google Drive → локальная папка
        ↓
2. Скрипт сканирует все подпапки респондентов
        ↓
3. Детектор поездок: шаблон нумерации → маркеры → keywords
        ↓
4. Определение Day 1: первый день с ≥1 поездкой
        ↓
5. Расчёт: день дневника, дата окончания, поездки по дням
        ↓
6. Квотная сетка: раскладка 32 респондентов по сегментам
        ↓
7. Вывод: ASCII-таблица + секция отбора на интервью

Автор: руководитель проекта + Claude Code (Opus 4.6)

---

Проблема

Дневниковое исследование навигации: 32 респондента ведут дневники 7 дней, из них 24 отбираем на финальные 70-минутные интервью. Формат интервью — детальный разбор конкретных поездок из дневника. Это значит, что отбирать нужно не «хороших респондентов», а тех, чьи дневники дадут максимум материала для продуктивного разговора.

Что было неудобно:

• Критерии отбора — в голове у руководителя, нет формализованной системы
• 32 респондента x 5-7 дней x 2-6 поездок/день = сотни записей. Невозможно удержать в памяти при сравнении
• Квотные ограничения (тип x гео x частота навигации) делают отбор нелинейным — нельзя просто взять top-24 по «качеству»
• Респонденты начинают дневники в разные даты. Те, кто начал позже, имеют меньше данных — несправедливое преимущество ранних
• Заказчику нужно прозрачное обоснование: почему именно этих 24, а не других

Что нужно:

• Формализованная система оценки: что именно мы оцениваем и по какой шкале
• Привязка каждого решения к задачам исследования, а не к абстрактному «качеству»
• Квотная логика: пропорциональный отбор с сохранением баланса по городам и частоте навигации
• Справедливость для респондентов с поздним стартом
• Обоснование для клиента по каждому включению и исключению

---

Варианты, которые рассматривали

1. Экспертный отбор без формализации

Плюсы: быстро, руководитель и так знает материал. Минусы: непрозрачно для заказчика.

Решение: отклонено. Заказчик ожидает аргументированное обоснование.

2. Простой рейтинг по количеству поездок

Плюсы: объективная метрика, легко посчитать. Минусы: количество != качество. 20 записей «всё нормально, доехала» бесполезнее, чем 5 записей с рефлексией и скриншотами. Не учитывает квоты — можно потерять целый сегмент. Штрафует «редко»-пользователей, которые ценны именно своим невключением навигации.

Решение: отклонено. Противоречит принципу «ценность для интервью > формальная активность».

3. 100-балльная система с квотной логикой и волновым скорингом (выбрали)

Плюсы:

• 5 измерений покрывают все аспекты ценности для интервью
• Квотная логика гарантирует сохранение выборки
• Калибровочные якоря обеспечивают стабильность оценок между сессиями
• Волновой скоринг (день 5+) устраняет несправедливость для «поздних»
• Результат — готовое обоснование для клиента

Минусы: трудоёмко — полный скоринг одного респондента занимает 5-10 минут. Нужна актуальная карточка мониторинга как входные данные.

---

Что мы сделали

1. Создали скилл с 5 измерениями оценки

100-балльная система, каждое измерение оценивает конкретный аспект ценности для интервью:

Измерение	Макс	Что оценивает
Активность	25	Сколько дней и поездок, стабильность ведения
Разнообразие поездок	20	Виды транспорта, цели, контексты, знакомость маршрутов
Качество комментариев	20	Рефлексия, «почему», эмоции, скриншоты, голосовые
Исследовательская ценность	25	Инсайты, барьеры, расхождения, фича-реквесты
Потенциал интервью	10	Материал для 70-минутного разбора: противоречия, гипотезы

Ключевое решение: исследовательская ценность весит столько же, сколько активность (25 баллов). Три глубокие записи с инсайтами ценнее двадцати формальных.

2. Встроили калибровочные якоря

Два респондента проскорены первыми — как якоря шкалы: верхний (высокая активность, много инсайтов) и нижний (минимум данных). Каждый последующий скоринг калибруется относительно этих двух.

3. Внедрили волновую логику «день 5+»

Правило: скорить респондента только когда он на 5-м дне дневника или дальше. 5 дней — достаточно для надёжной оценки, остаётся 2 дня запаса для планирования интервью.

4. Создали пост с методологией для команды

Описали 5 измерений, шкалу, логику принятия решений — простым языком, без внутренней кухни. Отправили в рабочий чат команды, чтобы все понимали, как работает отбор.

---

Зачем это нужно

1. Руководителю исследования — формализованная система вместо «я так чувствую». Можно делегировать скоринг, результат будет одинаковым.
2. Заказчику — прозрачное обоснование: каждое включение и исключение привязано к задачам исследования.
3. Команде проекта — понятные критерии: что значит «хороший дневник» и почему респондент с 1 поездкой может быть ценнее, чем с 20.
4. Респондентам (косвенно) — справедливость: поздний старт не означает автоматический проигрыш. Волновой скоринг уравнивает шансы.
5. Агентству — переиспользуемый скилл. На следующем дневниковом проекте не нужно заново придумывать систему отбора.

---

Как это работает

1. Карточка мониторинга обновлена (свежие данные дневника)
        |
2. Проверяем день дневника: >=5? Если нет — ждём
        |
3. Запускаем скоринг: «оцени респондента для интервью»
        |
4. Claude Code читает карточку + дневник + квотную сетку
        |
5. Оценивает по 5 измерениям, проверяет red flags
        |
6. Определяет квотную позицию (обязательный / конкурентный)
        |
7. Выдаёт карточку скоринга с баллом и решением
        |
8. Результат сохраняется в файл результатов
        |
9. Когда вся ячейка проскорена — финальный отсев по баллу

Автор: руководитель проекта + Claude Code (Opus 4.6)

---

Проблема

На 6-й день полевого этапа дневникового исследования (32 респондента, 32 Telegram-группы) бот перестал сохранять записи на Google Drive. Респонденты продолжали писать, но файлы не появлялись.

Что произошло:

• Запустили синк дневников — скачался 1 файл вместо ожидаемых десятков
• Проверка Google Drive показала: за весь день только 5 файлов (все до 04:00 утра)
• Telegram webhook отдавал 500 Internal Server Error
• 224 сообщения от респондентов застряли в очереди Telegram
• Логи сервера: RefreshError: invalid_grant: Token has been expired or revoked

Почему это критично:

• Telegram хранит очередь сообщений ~24 часа, потом удаляет — данные были под угрозой потери
• 32 респондента продолжали писать весь день, не подозревая о проблеме
• Полевой этап идёт 7 дней — потеря даже одного дня = невосполнимый ущерб

Корневая причина: OAuth consent screen в Google Cloud Console был в режиме "Testing". В этом режиме Google автоматически отзывает refresh token через 7 дней. Проект запущен неделю назад, токен протух ровно через 7 дней.

---

Варианты, которые рассматривали

1. Переключить бот на сервисный аккаунт вместо OAuth

Плюсы: сервисные аккаунты не требуют refresh token, не протухают. Минусы: сервисные аккаунты не имеют квоты хранения на Google Drive и не могут загружать файлы на личный диск пользователя. Получаем ошибку storageQuotaExceeded. Работает только с Shared Drives (Team Drives).

Решение: отклонено после попытки — получили 403 от Google Drive API.

2. Перегенерировать OAuth refresh token + опубликовать consent screen (выбрали)

Плюсы:

• Решает и текущую проблему (новый токен), и корневую причину (публикация = токен бессрочный)
• Не требует изменения архитектуры хранения
• Можно сделать за 10 минут

Минусы: нужен доступ к Google Cloud Console и хостинг-панели.

3. Перенести хранилище на Shared Drive

Плюсы: можно использовать сервисный аккаунт, токены не протухают. Минусы: нужно мигрировать ~2000 файлов, менять все скрипты (rclone, синк, бот), риск потери данных при миграции.

Решение: отложено. Непропорциональный объём работ для горящей ситуации.

---

Что мы сделали

1. Диагностика (5 минут)

Цепочка проверок:

• Синк дневников → только 1 новый файл → подозрение
• Проверка Google Drive → за день всего 5 файлов (все до 04:00) → проблема на стороне бота
• getWebhookInfo → 500 Internal Server Error, 224 pending updates → бот падает
• Логи сервера → RefreshError: invalid_grant → OAuth token expired

2. Код-фикс: fallback на сервисный аккаунт (2 минуты)

Обернули OAuth-авторизацию в try/except. При падении OAuth — бот логирует предупреждение и пробует сервисный аккаунт. Это страховка на будущее: если OAuth снова упадёт, бот не будет падать с 500, а попытается альтернативный путь.

try:
    if not creds.valid:
        creds.refresh(Request())
except Exception:
    logging.warning("OAuth refresh failed, falling back to service account")
    return None

3. Обнаружили ограничение сервисного аккаунта (3 минуты)

После деплоя кода с fallback'ом — получили новую ошибку: storageQuotaExceeded. Сервисные аккаунты не могут создавать файлы на личном Google Drive. Вариант 1 не работает — нужен OAuth.

4. Перегенерация OAuth token (5 минут)

Написали скрипт перегенерации токена:

• Поднимает локальный HTTP-сервер на порту 8090
• Открывает браузер для авторизации Google
• Перехватывает код авторизации через redirect
• Обменивает код на новый refresh token

Обновили переменную окружения на хостинге → Manual Deploy.

5. Публикация consent screen (1 минута)

В Google Cloud Console → OAuth consent screen → Audience → нажали "Publish App". Статус сменился с "Testing" на "In production". Теперь refresh token бессрочный.

6. Результат

Метрика	Значение
Время от обнаружения до фикса	~20 минут
Сообщений в очереди	224
Сообщений потеряно	0
Скорость разбора очереди	~30 сообщений/минуту
Очередь разобрана за	~7 минут

---

Зачем это нужно

1. Руководителю проекта — понимание типичного сценария отказа бота и алгоритм быстрой диагностики.
2. Инженеру — код-фикс с fallback'ом остаётся как страховка; скрипт перегенерации токена готов к повторному использованию.
3. Будущим проектам — чеклист при настройке Google OAuth: всегда публиковать consent screen до запуска полевого этапа.
4. Команде — данные за весь день восстановлены без потерь, респонденты ничего не заметили.

---

Как это работает

1. Обнаружение: синк показал 0 новых файлов
        |
2. Проверка Drive: файлов нет → проблема на стороне бота
        |
3. Проверка webhook: getWebhookInfo → 500, N pending
        |
4. Логи сервера: идентификация ошибки
        |
5. Фикс: перегенерация токена + деплой
        |
6. Telegram переотправляет очередь → файлы на Drive

Чеклист «OAuth для Google Drive»

1. При настройке проекта: Google Cloud Console → OAuth consent screen → опубликовать (Publish App). Не оставлять в Testing.
2. Переменные окружения: GOOGLE_OAUTH_CLIENT_ID, GOOGLE_OAUTH_CLIENT_SECRET, GOOGLE_OAUTH_REFRESH_TOKEN — все три нужны на сервере.
3. Если токен протух: запустить скрипт перегенерации токена → скопировать новый token → обновить на хостинге → Manual Deploy.
4. Мониторинг: getWebhookInfo — если pending_update_count > 0 и last_error_message содержит 500 — бот лежит.

Автор: руководитель проекта + Claude Code (Opus 4.6)

---

Проблема

Дедлайн: утверждение гайда финальных интервью с заказчиком. Первые интервью — на следующий день. В наличии — черновик гайда на 70 минут, 7 блоков, написанный в начале проекта. Но за неделю полевого этапа многое изменилось:

• Накопились данные 30 дневников (200+ поездок), которые меняют картину
• Заказчик не предоставил список фич продукта, и неясно, появится ли он
• В брифе — буквально пара гипотез, а дневники генерируют десятки
• Черновик содержал незакрытые TODO: «вставить список фич», «добавить гипотезы»
• Нет механизма приоритизации направлений развития (Задача 4 проекта) — а это ключевой ожидаемый результат

Что нужно: за выходные превратить черновик в рабочий инструмент, который гарантирует получение данных по ВСЕМ исследовательским задачам, и проверить его на реальном материале.

---

Варианты, которые рассматривали

1. Косметическая правка черновика

Плюсы: быстро, структура уже есть. Минусы: критические пробелы останутся. Без фич от заказчика блок 4 (ценность навигации) неработоспособен. Без приоритизации Задача 4 не закрыта. Вопросы не привязаны к данным дневников. Решение: отклонено.

2. Полностью переписать гайд

Плюсы: можно учесть всё, что знаем из дневников. Минусы: риск «ресёрчерского перфекционизма» — бесконечная доработка. Структура черновика рабочая — ломать её нет смысла. Нет времени. Решение: отклонено.

3. Системный review + точечная доработка + обкатка на данных (выбрали)

Плюсы:

• Review по 8 блокам выявляет именно те пробелы, которые критичны
• Точечные правки сохраняют рабочую структуру
• Данные дневников встраиваются в гайд как гипотезы и паттерны
• Обкатка на реальном дневнике проверяет, работает ли гайд до первого интервью
• Укладывается в выходные

Минусы: трудоёмко — нужно вытащить данные из 30 вкладок, провести review, доработать, протестировать. Но результат — проверенный инструмент.

---

Что мы сделали

Шаг 1: Системный review по 8 блокам

Использовали скилл review — оценка по 8 блокам (вводное слово, скрининг, связь с задачами, формулировки, структура, инструменты, хронометраж, пилот). Составили матрицу покрытия: исследовательские задачи x вопросы гайда.

Общая оценка: «Требует доработки».

Критические пробелы:

• Блок 4 (ценность навигации) построен «сверху вниз»: показать респонденту список фич → спросить «знаете ли?». Без списка фич от заказчика блок неработоспособен
• Нет механизма приоритизации - Нет разделения водители/пешеходы в вопросах
• Нет приоритетов внутри блоков (что обязательно, что при наличии времени)
• Гипотезы не сформулированы — TODO в тексте

Сильные стороны (сохранили):

• Привязка к конкретным поездкам из дневника
• 7-блочная структура с логичной воронкой
• Типовые вопросы по паттернам

Шаг 2: Решение проблемы «нет списка фич»

Это был ключевой вызов. Заказчик не предоставил список фич, и неизвестно, появится ли он. Первая версия блока 4 — мертва без этого списка.

Решение — перевернуть логику: вместо «сверху вниз» (фичи → респондент) идём «снизу вверх» (респондент → его ментальная модель):

1. Открытые вопросы о ценности навигации
2. Привязка к конкретным поездкам из дневника
3. Обсуждение результатов упражнения из последнего дня дневника
4. Сегментные углубления (IF TIME)

Так мы получаем ментальную модель респондента без подсказок — а потом сравниваем с реальными возможностями продукта при анализе.

Шаг 3: Вынос приоритизации в последний день дневника

Приоритизация направлений — важна, но съедает 15-20 минут интервью. При 70-минутном лимите это критично.

Решение: упражнение на приоритизацию выполняется в последний день дневника, НЕ на интервью:

• Респондент получает карточки с барьерами и ценностями
• Выбирает топ-3 в каждой категории, ранжирует
• На интервью — только короткое обсуждение результатов (5 мин вместо 20)

Карточки сформировали из реальных данных дневников, отдельно для водителей и пешеходов. Формулировки на языке респондентов, не исследовательском.

Шаг 4: Извлечение данных из 30 дневников

Для формулировки гипотез и карточек нужна консолидация данных всех 30 респондентов. Написали скрипт, который вытаскивает аналитический слой из трекинговой таблицы Google Sheets — паттерны, барьеры, драйверы, фича-реквесты, вопросы к интервью.

Результат: структурированный JSON с данными по 8 секциям x 30 респондентов. Из этих данных:

• Сформулировали 6 гипотез для блока 5
• Выявили 2 новых паттерна для блока 3
• Составили карточки барьеров и ценностей для упражнения

Шаг 5: Доработка гайда (v2.0)

Точечные правки по результатам review:

Блок	Что изменили
Блок 1 (разогрев)	Добавили запрос на запись, проверку времени
Блок 3	Маркеры MUST/IF TIME, убрали наводящие формулировки, добавили 2 паттерна из данных
Блок 4 (ценность)	Полная переделка: снизу вверх, 4 шага, привязка к упражнению
Блок 5 (гипотезы)	6 гипотез из дневников вместо пустого TODO. Три MUST, три IF TIME
Блок 7 (закрытие)	Добавили ключевой вопрос
Тайминг	Приоритеты по каждому блоку: что обязательно, что можно пропустить

Шаг 6: Виртуальное интервью — обкатка на реальных данных

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

Для каждого блока: какой вопрос задаём → что можем предсказать из дневника → чего нет и что даст только живое интервью.

Что показала обкатка:

• Гайд работает — генерирует данные по всем блокам
• Блок 3: все 4 ключевые поездки дают богатый материал для разбора
• Блок 4 (перевёрнутый): открытые вопросы применимы, привязки к поездкам есть
• Блок 5: 5 из 6 гипотез релевантны этому респонденту
• Блок 7: Q4 «по умолчанию» — ключевой вопрос, ответа в дневнике нет = именно это даст интервью

Что не покрывает гайд: обкатка выявила уникальные паттерны поведения, которые гайд не покрывает — они специфичны для конкретного респондента и идут в индивидуальную подготовку исследователя перед интервью.

Главный вывод: дневник даёт «что», интервью даст «почему» и «что если». Гайд работает именно на этот переход.

Шаг 7: Публикация и командная коммуникация

• Загрузили гайд v2.0 и виртуальное интервью на Google Drive
• Создали страницу на сайте проекта для удобного чтения
• Отправили 2 поста в чат команды:
  1. Гайд + виртуальное интервью + ссылки + просьба комментариев от исследователей
  2. Упражнение на приоритизацию: карточки барьеров и ценностей + просьба обратной связи

---

Зачем это нужно

1. Исследователям — рабочий инструмент с приоритетами (MUST/IF TIME), привязкой к данным дневников, готовыми гипотезами. Не нужно импровизировать
2. Руководителю — уверенность, что гайд покрывает ВСЕ исследовательские задачи. Матрица покрытия — доказательство
3. Заказчику — гайд основан на данных (30 дневников, 200+ поездок), а не на предположениях. Гипотезы — из реального поведения пользователей
4. Проекту — приоритизация решена без потери времени интервью. Данные собираются в дневнике, обсуждаются на интервью
5. Методологии — виртуальное интервью как метод тестирования гайда. Можно делать для каждого респондента перед живым интервью

Страница анализа: фича-реквесты + гипотезы для интервью

Автор: руководитель проекта + Claude Code (Opus 4.6)

---

Проблема

К 7-му дню проекта накопился большой объём аналитических данных из дневников 32 респондентов (~400+ поездок). Два ключевых артефакта — карта фича-реквестов и гипотезы для финальных интервью — существовали, но в разных местах:

• Фича-реквесты были на сайте, но устарели — написаны по данным первых дней, 26 респондентов. За оставшиеся дни появились новые кластеры, а существующие значительно пополнились.
• Гипотезы были вшиты внутрь гайда интервью — доступны только тем, кто читал гайд целиком. Отдельного документа с доказательной базой не было.
• Команда (исследователи) готовилась к пилотным интервью, и им нужен был быстрый доступ к обоим артефактам.

Что нужно: единая точка доступа к фича-реквестам и гипотезам, актуальная по всем 32 респондентам, с доказательной базой.

---

Варианты, которые рассматривали

1. Обновить фича-реквесты в текущем файле, гипотезы оставить в гайде

Плюсы: быстро, минимум изменений. Минусы: команда не увидит гипотезы без чтения 10-страничного гайда. Перед интервью нужен быстрый доступ. Решение: отклонено.

2. Создать два отдельных документа на сайте (выбрали)

Плюсы:

• Страница на сайте уже поддерживает авто-табы из .md файлов — достаточно положить второй файл
• Два таба: фича-реквесты и гипотезы — логически связаны, но читаются независимо
• Исследователи получают единую ссылку для подготовки к интервью

Минусы: трудоёмко — нужно пересмотреть данные всех 32 респондентов и 87 рабочих сессий.

---

Что сделали

Шаг 1. Обновили карту фича-реквестов.

Исходные данные: дневники 32 респондентов за 7 дней, карточки мониторинга, аналитический слой трекинговой таблицы, кросс-респондентные паттерны.

Результат:

• Было: 15 кластеров, 26 респондентов, первые дни, ~200+ поездок
• Стало: 20 кластеров, 32 респондента, все 7 дней, ~400+ поездок

Шаг 2. Создали файл гипотез.

Источники: гайд интервью v2.0, трекинговая таблица, карточки мониторинга, количественный слой.

10 гипотез с доказательной базой из полного дневникового этапа. Каждая гипотеза: суть, доказательная таблица, объяснение «почему важно», формулировка вопроса для интервью.

Шаг 3. Деплой и оповещение.

• Коммит + пуш → автодеплой на Render
• Пост в командный чат: что обновилось, где посмотреть, код доступа

---

Результат

Страница анализа на сайте проекта — два таба:

1. Карта фича-реквестов — 20 кластеров с цитатами, сводной матрицей и выводами
2. Гипотезы из дневниковых данных — 10 гипотез с доказательной базой и вопросами для интервью

Единая ссылка для команды к странице анализа на сайте проекта.

---

Что это дало

• Исследователям: подготовка к пилотным интервью — быстрый доступ к фича-реквестам и гипотезам с привязкой к конкретным респондентам
• Руководителю: актуальная картина потребностей пользователей по всем 32 респондентам
• Проекту: методологическая связка «дневник → таблица трекинга → фича-реквесты → гипотезы → интервью» замкнулась в единый пайплайн

Автор: руководитель проекта + Claude Code (Opus 4.6)

---

Проблема

Дневники заканчиваются - начинаются интервью. Исследователям нужно подготовиться: погрузиться в данные каждого респондента, понять его поведение, знать, что уточнять на интервью.

На входе — 7 дней дневниковых записей: десятки текстовых сообщений, голосовых, фото, скриншотов, диалогов с исследователем. Ни один исследователь не сможет прочитать всё за вечер перед интервью.

Мониторинговая карточка (которая уже существует на сайте) — хороший инструмент для ежедневного трекинга, но это структурированная сводка: паттерны, барьеры, драйверы, хронология. Для подготовки к интервью нужно другое — понимание человека: как он думает, почему так ездит, что стоит за цифрами. И конкретные цитаты, конкретные ситуации, конкретные вопросы.

Дальше — после интервью — нужно что-то для клиента. Не просто «респондент использует навигатор в 33% поездок», а ответ на вопрос: как поведение этого человека соотносится с целями бизнеса? Что работает, что не работает, и почему.

Что нужно: система создания аналитических статей про респондентов, которая работает на всех этапах исследования и переиспользуется между проектами.

---

Варианты, которые рассматривали

1. Расширить мониторинговую карточку

Добавить в существующий формат нарративный блок, цитаты, вопросы для интервью. Плюсы: один файл, одно место. Минусы: карточка станет огромной, смешаются два формата (структурированная сводка и нарратив), карточка обновляется ежедневно — нарратив будет мешать. Решение: отклонено.

2. Создать отдельные аналитические статьи по респондентам (выбрали)

Три отдельных файла в персональной папке респондента: нарративная аналитика, диалоги, зоны для интервью. После интервью — обогащение транскриптом + бизнес-статья. Плюсы: каждый артефакт — отдельный файл с понятным назначением, не загрязняет мониторинг, масштабируется. Минусы: больше файлов. Решение: выбрали.

3. Делать подготовку к интервью каждый раз вручную

Исследователь сам читает дневник, выписывает цитаты, формулирует вопросы. Плюсы: глубокое погружение. Минусы: 24 респондента × часы чтения = нереалистично при сжатых сроках. Каждый раз с нуля. Решение: отклонено.

---

Что сделали

1. Определили жанр — «Нарративная аналитика»

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

Фокус:

• Как человек перемещается в целом (A→B паттерны)
• Повторяющиеся действия и что на них меняется
• Разовые / уникальные действия

Длина — ровно такая, чтобы раскрыть поведение и его причины. Не 3 абзаца и не 30 — сколько нужно.

2. Создали структуру папок

32 персональных папки — по одной на каждого респондента. В каждой:

• Нарративная аналитика
• Диалоги исследователь↔респондент
• Зоны для копания на интервью

3. Написали пилотную статью

Источники: 177 файлов дневника (7 дней), мониторинговая карточка, аналитический слой из таблицы трекинга.

Результат — три файла:

• Нарративная аналитика — портрет респондента
• Диалоги — все значимые обмены исследователь↔респондент, организованные по дням и темам. Цитаты в оригинале.
• Зоны для интервью — 8 конкретных направлений

4. Спроектировали pipeline на весь жизненный цикл

Определили три этапа, которые применимы к любому исследовательскому проекту:

Этап	Когда	Что создаётся	Входные данные
Нарратив	До или после интервью	Нарративная аналитика	Дневник, и/или транскрипт
Подготовка	Перед интервью	Диалоги + зоны для копания	Любые pre-data
Бизнес	После нарратива	Бизнес-статья	Нарратив + цели бизнеса

Ключевое решение: скилл адаптируется к входным данным, а не к методу исследования. Одна команда покрывает:

• Дневниковый метод (нарратив из дневника → обогащение транскриптом)
• Глубинное интервью без pre-data (нарратив из транскрипта)
• Любой гибрид (что есть — из того и пишем)

Исследователь не выбирает «режим дневника» или «режим интервью». Он говорит: «напиши нарратив» — и скилл сам определяет, какие данные доступны.

---

Что это меняет

Для исследователей:

• Подготовка к интервью: вместо чтения 177 файлов — один нарративный документ + готовые зоны для копания
• После интервью: нарратив обогащается, не пишется заново
• Для отчёта: бизнес-статья маппит поведение респондента на цели бизнеса

Для проекта:

• 24 респондента идут на интервью. Для каждого можно подготовить такой же пакет
• Папки уже созданы. Транскрипты будут ложиться туда же
• Бизнес-статьи по всем 24 респондентам → собираются в общий vision для отчёта

Для будущих проектов:

• Pipeline не привязан к дневниковому методу. Работает для любого qual-исследования с интервью
• Жанр «нарративная аналитика» переиспользуем: аналитика через сюжет, а не сухая сводка
• Скилл (в разработке) будет в общих скиллах команды — подключается к любому проекту