Первая статья из цикла «Аналитик в чужом процессе»
Мне дали две недели и выгрузку из системы задач.
Выгрузка содержала почти 146 тысяч обращений за несколько лет. Никакой документации. Никаких схем процессов. Администратор системы уволился, дашбордов нет, руководитель поддержки работает в режиме постоянного пожаротушения.
Задача звучала просто: «Разберись с бэклогом. Посмотри что там».
Я посмотрел. К третьему дню был уверен: система в глубоком кризисе, процесс сломан, данные это подтверждают.
Потом поговорил с одним сотрудником первой линии.
И пришлось переписать анализатор с нуля.
День первый. Начинаю считать
Первое, что делает аналитик, получив данные — начинает считать. Я тоже начал.
issues = get_all_issues('project in (...) ORDER BY created ASC')print(len(issues))# 145850
Выгрузка шла несколько часов. Пока ждал, листал первые сотни задач вручную.
Картина складывалась тревожная. Задачи в промежуточных статусах — месяцами. Один и тот же статус появляется в истории одной задачи по пять-шесть раз подряд. Задачи периодически уходят в состояние «не назначен» — и непонятно, куда потом. Приоритеты меняются уже после того, как работа начата. Среди открытых задач — сотни старше 90 дней, десятки старше года.
В тот вечер я был абсолютно уверен, что нашёл доказательство глубокого кризиса.
Это было слишком быстро. Но я об этом ещё не знал.
День третий. 86 937 кандидатов на проблему
Написал анализатор. Логика казалась очевидной: собрать все признаки аномального поведения задачи и пометить такие задачи как «проблемные».
Критерии первой версии:
-
статус не менялся больше 30 дней
-
задача возвращалась в один статус больше трёх раз
-
переходы через состояние «не назначен»
-
приоритет менялся уже после начала работы
-
задача старше 90 дней
Запустил. Получил 86 937 задач-кандидатов — почти 60% всей базы.
Я смотрел на эту цифру и думал: ну вот, я был прав. Всё плохо.
Потом я поймал себя на простой мысли.
60% задач — проблемные? Если в системе сломано 60% процессов, она бы просто не работала. А компания работает. Клиенты получают услуги. Операции проводятся. Сотрудники каждый день открывают эту систему и что-то в ней делают.
Значит, что-то не так с моими критериями, а не с системой.
Это был первый момент настоящего сомнения. Хороший момент — он заставил меня сделать то, что нужно было сделать с самого начала, ещё до написания первой строки кода.
День пятый. Разговор с опытным специалистом
Один из опытных специалистов первой линии поддержки. За время исследования именно она чаще всего поправляла мои представления о том, как процесс устроен на самом деле.
Я попросил о коротком звонке — «буквально двадцать минут, несколько вопросов». Получил сорок минут, которые перевернули всю мою аналитику.
Про статус, который встречался в истории задачи по пять раз:
— Огромное количество задач многократно возвращается в один и тот же промежуточный статус. Иногда по пять-шесть раз. Это нормально?
— Ну да, нормально. Это наш способ сказать команде «посмотри сюда». Когда задача в этом статусе — значит по ней нужно что-то сделать. Пришла новая задача — она сразу туда попадает. Клиент написал комментарий — переводим обратно. Задача вышла из ожидания — тоже. Это просто сигнал.
— То есть это не статус в обычном смысле, а флаг «требует внимания»?
— Именно.
Первый критерий анализатора оказался ложным. Тысячи «аномалий» исчезли.
Про переходы через «не назначен»:
— Когда задача проходит через состояние «не назначен» — это потеря ответственности?
— Нет, это техническое. Когда меняешь группу, система снимает исполнителя автоматически. Потом в новой группе кто-то берёт задачу на себя. Так работает.
Второй критерий тоже оказался ложным.
Про приоритеты:
— У вас очень много задач с самым низким приоритетом. Это специально занижают?
— Нет, это просто дефолт. При создании проставляется автоматически. Большинство не меняют, если задача несрочная.
К концу разговора три из пяти критериев оказались ложными.
Не потому что они были неправильными в теории. Потому что они описывали отклонения от того, как процесс, по моему мнению, должен был работать — а не от того, как он работает на самом деле.
Я пришёл со своей картиной «правильного» процесса. И начал искать отклонения от этой картины. Нашёл 87 000 отклонений. Но проблема была в картине, а не в процессе.
Большие данные сами по себе ничего не объясняют. Они лишь очень убедительно подтверждают те ошибки, которые аналитик уже успел совершить.
День шестой. Переписываю с нуля
Новая логика: аномалия — это не отклонение от учебника. Аномалия — это отклонение от реального процесса этой конкретной команды.
Несколько конкретных замен. Вместо «задача возвращалась в один статус больше трёх раз» — «задача находится в нём дольше, чем 95% похожих задач». Вместо «был переход через не назначен» — «задача застряла в этом состоянии дольше типичного времени переназначения». Вместо «приоритет менялся» — «приоритет повышался экстренно после того, как задача уже долго лежала без движения».
К вечеру анализатор был переписан.
19 321 кандидат.
Разница в 4,5 раза — это не улучшение алгоритма. Это разница между «я считаю по своим представлениям» и «я считаю по реальности».
И теперь, в отличие от 87 тысяч, эти задачи было действительно интересно исследовать. Именно теперь начали проявляться реальные паттерны, которые раньше были скрыты за ложными аномалиями.
Что изменилось
Именно тогда я понял, что следующие дни будут уже не про поиск ошибок в системе задач. Они будут про попытку понять, как этот процесс на самом деле живёт.
Компьютер умеет находить закономерности. Но только человек способен понять, какие из них имеют смысл.
Аналитик ошибается не потому что плохо считает. Аналитик ошибается потому что начинает считать раньше, чем понимает процесс.
ссылка на оригинал статьи https://habr.com/ru/articles/1059196/