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

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

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

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

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

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

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

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

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

А что вы стали бы измерять первым, если новый процесс выглядит быстрее, но непривычно?