Всё работает, но команда не пользуется. Что я проверяю
Как найти причину, по которой команда возвращается к таблицам и переписке: разобрать рабочую задачу, убрать лишние шаги, проверить пользу AI и договориться об одном изменении.
Система запущена. Доступы выданы, инструкция написана, на демонстрации всё получилось. А через некоторое время выясняется: заявки снова ведут в таблице, ответы ищут в переписке, отчёт собирают вручную.
В такой ситуации я сначала хочу понять, какую задачу человек пытался выполнить и почему выбрал другой способ. Фраза «команда не хочет меняться» слишком рано закрывает этот разговор.
Удобство на демонстрации и удобство в рабочий день могут различаться. На демонстрации мы знаем, куда нажать, у нас подготовлены данные и никто не отвлекает. У сотрудника одновременно клиент, незаконченная задача и вопрос от коллеги. Именно в этих условиях решению предстоит приносить пользу.
В статье о поддержке проекта я разбирал, как договориться о помощи после запуска. Здесь следующий вопрос: что проверить, если исправная система так и не вошла в ежедневную работу.
Сначала уточняю, кто и в каких случаях должен пользоваться
«Никто не пользуется» стоит превратить в проверяемое наблюдение. Кто именно? Какую работу эти люди выполняют? Возникали ли у них задачи, для которых предназначен инструмент?
Если отчёт нужен руководителю перед ежемесячным разбором, отсутствие ежедневных входов ничего не говорит о его полезности. Если помощник рассчитан на типовые обращения, сложный нестандартный вопрос может обоснованно уйти к специалисту.
Я предлагаю выбрать конкретную роль и повторяющуюся задачу. Например: менеджер получает вопрос клиента, находит условия услуги, готовит ответ и сохраняет договорённость. Тогда можно посмотреть, где в этой последовательности должен помогать новый инструмент и что происходит на самом деле.
Ещё проверяю доступность: есть ли нужные права, открывается ли система на рабочем устройстве, понятен ли вход. Проверка под учётной записью администратора не показывает, что видит обычный сотрудник.
Прошу показать задачу от начала до результата
Мне полезнее увидеть один обычный рабочий случай, чем услышать общее «неудобно». Прошу сотрудника пройти привычным путём и объяснить места, где он принимает решение, ждёт или переключается в другой сервис.
Возьмём условный пример. Для отдела продаж подготовлен AI-помощник, который ищет информацию об услугах и предлагает черновик ответа. Но менеджер продолжает спрашивать опытного коллегу в чате.
При разборе может выясниться, что для помощника нужно отдельно открыть страницу, перенести вопрос клиента, добавить контекст, проверить ответ, а затем скопировать его обратно. Коллега уже видит переписку и понимает ситуацию. Формально помощник работает, но цена его использования для менеджера пока слишком высока.
Я смотрю на весь путь: от появления задачи до принятого результата. Записываю повторный ввод, ожидание, поиск данных, исправления и места возврата к старому способу. Наблюдение заранее обсуждаю с участником: что смотрим и зачем. Для разбора достаточно безопасного примера с сохранением рабочих шагов; ненужные клиентские данные собирать не требуется.
В руководстве GOV.UK по наблюдению за работой пользователей описан похожий принцип: привычная среда, устройства и повседневные ограничения помогают увидеть реальные барьеры. Для своего проекта я использую эту идею как способ проверить предположения о процессе.
Ищу конкретное препятствие
Одно и то же поведение — человек вернулся к таблице или чату — может иметь разные причины. Исправление должно соответствовать причине.
| Что наблюдаем | Что я уточняю | Что можно проверить первым |
|---|---|---|
| Сотрудник не начинает задачу в системе | Знает ли он, когда её использовать, и есть ли доступ | Понятный вход и один рабочий сценарий с его правами |
| Начинает, но уходит в другой инструмент | На каком шаге не хватает данных или возникает лишнее действие | Убрать конкретный перенос данных или исправить затрудняющий шаг |
| Каждый результат перепроверяет с нуля | Можно ли установить источник, заметить ошибку и исправить ответ | Сделать проверку результата понятной на выбранном сценарии |
| Ведёт и новую систему, и старую таблицу | Откуда руководитель действительно берёт данные для решений | Согласовать основное место работы и условия завершения дублирования |
| Пользуется только после напоминания | Есть ли подходящие задачи и ощутимая польза для этой роли | Сравнить полный рабочий путь с привычным способом |
Это список гипотез для разбора. По одной строке нельзя автоматически заключить, что человеку нужно обучение или системе — новая функция.
Если сотрудник не понимает действие, полезен короткий разбор на его задаче. Если действие понятно, но требует постоянно переносить одно и то же между окнами, ещё одна инструкция не уберёт эту работу.
Иногда проблема находится раньше самого инструмента: условия услуги не определены, документы противоречат друг другу, нет человека, который может подтвердить ответ. Тогда я сначала предлагаю разобраться с этими зависимостями.
Для AI отдельно проверяю стоимость проверки ответа
Красиво написанный текст ещё нужно использовать в конкретной ситуации. Менеджеру важно понять: откуда взялись условия, актуальны ли они, чего не хватает и кто отвечает за отправку клиенту.
В условном примере помощник может быстро составлять черновик, но заставлять сотрудника заново искать все исходные документы. Пока мы не посчитали эту проверку, говорить об экономии времени рано.
Я предлагаю определить, что именно человек проверяет перед использованием ответа. Для типового вопроса это могут быть источник, актуальная версия условий и отсутствие неподтверждённых обещаний. Для нестандартного запроса — понятная передача специалисту.
Ссылка на источник помогает найти основание ответа, но сама по себе не доказывает правильность вывода. Поэтому важно, чтобы сотрудник мог сопоставить ответ с материалом, поправить его или отказаться от подсказки. Если проверить результат практически невозможно, стоит пересмотреть сам сценарий применения AI.
Время поиска, чтения, правок и переноса результата я включаю в сравнение способов работы. Более высокая скорость генерации полезна лишь тогда, когда она улучшает весь процесс при нужном качестве.
Проверяю договорённости внутри команды
Допустим, сотрудники обновляют CRM, а руководитель на планёрке просит прислать знакомую таблицу. Тогда у команды есть практическая причина продолжать вести таблицу: именно по ней будут обсуждать работу.
Я уточняю, где принимают решения, какие данные считаются основными и кто поддерживает их актуальность. Если новый инструмент добавляет обязанность, полезно прямо назвать, какую прежнюю работу он позволяет убрать.
На переходном этапе дублирование может быть осознанной мерой проверки. В этом случае ему нужны цель, ответственный и условие завершения. Иначе временная сверка рискует стать постоянной дополнительной нагрузкой.
Старый способ я предлагаю отключать после проверки рабочего сценария, доступов, данных и порядка действий при сбое. Принудительное закрытие привычного пути может увеличить число входов в новую систему, но ещё не показывает, что команда стала лучше выполнять задачи.
Отдельно нужен человек, к которому можно прийти с вопросом: «В этой ситуации инструментом пользоваться или нет?» Подробно передачу знаний и ответственности я разбирал в статье о передаче AI-помощника команде. Здесь важно проверить, действуют ли эти договорённости после запуска.
Проверяю небольшое изменение на подходящих задачах
После наблюдения я предлагаю выбрать одно препятствие и ограниченный сценарий. Например, в условном отделе продаж — подготовку ответа на типовой вопрос по действующим условиям услуги.
До изменения фиксируем, как задача выполняется сейчас. Затем договариваемся, что меняем, кто участвует и когда обсуждаем результат. Период выбираем так, чтобы у команды действительно возникли подходящие обращения. Отсутствие задач нельзя записывать в отказ от использования.
Для такого разбора мне нужны несколько наблюдений:
- сколько было задач, для которых новый способ подходит;
- сколько из них начали и закончили с его помощью;
- где пришлось вернуться к прежнему способу и почему;
- сколько времени занял весь путь, включая проверку и исправления;
- соответствует ли итог согласованным требованиям к качеству.
В методике GOV.UK по завершению задач доля завершений считается относительно начатых попыток. В своём примере я дополнительно смотрю на все подходящие обращения: иначе мы не увидим тех, кто даже не начал пользоваться новым способом. Это две разные точки наблюдения.
Тестовые прогоны отделяю от обычной работы. Причины возврата разбираю вместе с сотрудниками, без рейтинга «лояльности к системе». Нам нужно понять препятствие и результат изменения. Если люди реже обращаются к помощнику, потому что стало меньше подходящих вопросов, это тоже должно быть видно.
Завершаю разбор решением о следующем шаге
Вместо общего «нужно активнее пользоваться» я хочу получить конкретную договорённость: какое препятствие проверяем, что меняем и по чему оценим результат.
Для условного примера она могла бы звучать так:
Проверяем помощника на типовых вопросах по действующим условиям услуги. В черновике показываем основание ответа и убираем повторный ввод уже доступного контекста. Менеджер проверяет условия и подтверждает отправку; нестандартные запросы передаёт специалисту. До начала сравнения согласуем период, ответственного и требования к качеству. После него разбираем завершённые задачи, возвраты к чату и полное время обработки.
Такую договорённость ещё нужно выполнить и проверить. Если изменение помогло, можно расширять использование на другие подходящие задачи. Если препятствие осталось, возвращаемся к наблюдениям. Иногда разумный итог — сузить роль инструмента или отказаться от сценария, в котором он не даёт пользы.
Для меня освоение системы видно по рабочему результату: человек понимает, когда она нужна, может закончить задачу и не вынужден незаметно делать ту же работу ещё раз. Именно это я проверяю прежде, чем предлагать очередное обучение или новую функцию.