Бот для сводки рабочих чатов: статусы и риски проекта без ручного чтения

Коротко

Что делает бот-сводка для руководителя проекта?

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

Я собрал такого бота и подключил к своим рабочим чатам: десять чатов, двадцать потоков, если считать темы форумных групп отдельно. Перед сборкой я прикидывал около двухсот сообщений в сутки. Замер за десять дней показал 57,7 в среднем, то есть втрое меньше, а двести с лишним набиралось только в пиковый день.

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

Карточка выглядит так:

• Требует внимания. По проекту А вопрос по макету висит без ответа вторые сутки. Ссылка на сообщение.
• Обещания. Текст к пятнице был обещан, срок прошёл. Ссылка на сообщение.
• Пересказ дня по каждому потоку, свёрнутым списком.

Голосовые бот тоже расшифровывает и кладёт в поток наравне с текстом. Иначе часть решений осталась бы за кадром.

Что из работы проджекта можно отдать нейросети?

Самый точный сигнал риска вообще не требует нейросети. «На прямой вопрос не ответили больше суток» - это разница двух отметок времени. Код не фантазирует, поэтому блок «требует внимания» у меня собирается без единого вызова модели, а порог тишины задан в настройках.

Разделение обязанностей получилось таким:

Обещания работают в две ступени. Модель один раз вытаскивает из сообщения запись «кто обещал, что, кому, к какому сроку», запись ложится в базу, а дальше просрочку каждое утро считает код. Та же логика хорошо работает и для встреч: как превращать разговор в список задач, я разбирал в материале о том, как запись встречи превращается в задачи.

Какие сигналы риска видны в переписке?

Надёжные опираются на факты, которые есть в переписке буквально. Вопрос коллеге висит без ответа двадцать часов. Обещали «сделаю к четвергу», а четверг прошёл молча. Такой сигнал проверяется за секунду по исходному сообщению.

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

Ещё один класс ошибок даёт контекст вне чата. «Дизайнер второй день молчит» звучит как риск, а дизайнер в отпуске. Такие ложные тревоги неизбежны, и продукт должен уметь их гасить.

Три ложные тревоги - и бота выключат

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

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

Вторая защита - кнопка «это не риск» под каждым пунктом. Нажал - и это основание больше не поднимается в следующие дни. Гашение привязано к конкретному сообщению, а не к сигналу, который пересобирается каждое утро.

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

Как объявить команде, что в чате появился бот?

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

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

Порядок, который я заложил в продукт:

1. Сказать до подключения

   Сообщение в чат от руководителя: зачем бот, что читает, кто видит сводку, сколько хранятся сообщения.

2. Назвать объект наблюдения

   Бот следит за задачами и обещаниями проекта. Оценок людей в карточке нет, рейтинга «кто молчит чаще» тоже.

3. Показать пользу команде

   Зависший вопрос, подсвеченный лидеру, - это вопрос, на который исполнитель наконец получит ответ.

4. Записать дату

   Дата уведомления фиксируется в настройках потока. Без неё бот чат не слушает.

Про страхи людей перед новым инструментом я писал в статье о трёх барьерах внедрения ИИ в команде.

Что делать с персональными данными в переписке?

Для такого бота чужая переписка и есть сырьё продукта. Поэтому вопрос данных решается в архитектуре до первой строки кода.

Что у меня уходит в модель и что не уходит никогда:

• Участники чата уходят обезличенными метками вида [USER_7]. Таблица «метка - человек» живёт только в базе бота.
• Третьи лица в тексте («позвони Ивановой») заменяются пронумерованными метками. Живые имена подставляются обратно только в карточку лидеру.
• Телефоны, почты, номера карт, вложения и ключи не уходят наружу ни в каком виде.
• Сырой текст хранится в базе на российском сервере в зашифрованном виде и удаляется по расписанию, когда выходит срок хранения.

Важная оговорка. Замена имён метками с возможностью вернуть имя - это псевдонимизация: ключ подстановки у тебя, и по закону данные остаются персональными. Поставщик модели не видит ни одного имени, но аргумент «у нас обезличено» на этом не построить.

Про хостинг и 152-ФЗ для такого продукта - в материале о том, что делать после прототипа.

Анонимайзер для чата: где он ошибается

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

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

Я собрал анонимайзер для бота на открытых библиотеках, три слоя распознавания работают вместе. Индикативная точность около 96%, и остаток я принял осознанно: бот читает только мои чаты. Выход на чужие чаты - повод пересмотреть решение. Учти и то, что открытые модели для русского языка обычно обучены на новостях, а рабочий чат написан совсем иначе.

Что вылезло на живой переписке:

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

Частые вопросы

Главный вывод

Полезная сводка по рабочим чатам собирается из скучных вещей: отметки времени, ссылки на сообщения, кнопка «это не риск», дата уведомления команды.

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

А в твоих проектах команда знает, кто и зачем читает рабочий чат?