Пришла заявка от пользователя о проблеме: об ошибках, которые мешают сотруднику выполнять свои ежедневные задачи.
Когда ошибки единичные, пользователь отправляет их в техподдержку. Техподдержка исправляет что может — обычно последствия.
Когда ошибки становятся постоянными и большими (занимают много времени поддержки и пользователя), тогда приходит время исправлять не последствия, а причины. Тогда привлекают аналитиков.
Аналитик беседует с пользователем. Узнаёт, в чём проблема.
- Расспрашивает, что пользователь делает,
- зачем он это делает,
- как делает.
Задает перечень вопросов про то,
- сколько времени уходит на исправление ошибок,
- как часто она возникает,
- кто ещё с ней сталкивался,
- когда она появилась,
- на кого влияет,
- после чего она появилась, —
в общем, выясняет первые вещи, чтобы понять, окупят ли себя затраты на поиск причин и их исправление. Или пусть пользователь и дальше с ними мучается.
Вот реальный пример схемы, которая составлена после 9 часов анализа поставленной задачи. Это время ушло на беседы с пользователем, выяснение подробностей, воспроизведение ошибки, анализ информации, соображения, как же её визуально разместить.
Как мы уже рассказывали в других статьях, проблемы чаще всего возникают на границе между информационными системами (ИС) при передаче данных. Так и в этом случае. При передаче информации из ИС в ИС внутри компании что-то нарушено.
Посмотрим на схему: слева у нас чёрными прямоугольниками и кружочками обозначены действия человека: процессы, которые человек производит вручную.
Справа, голубым цветом, обозначены процессы, происходящие автоматически. Мы сейчас их не знаем, и только предполагаем исходя из характера ошибок, какие это процессы.
Затем мы опять встречаемся с пользователем и проверяем, правильно ли мы поняли процесс работы. Проходим по схеме, получаем дополнительную информацию. Пользователь, само собой, замечает ошибки в порядке действий — что они не так происходят, а немножко по-другому. Так мы выясняем новые закономерности и новые нюансы. Фиксируем эти беседы в видеозаписях, к которым ещё не раз вернёмся.
К примеру, когда специалист рассказывает и показывает свои действия, то 10 минут его речи (с демонстрацией экрана) занимают 2-3 часа аналитика. Это время уходит на фиксацию слов в документальный вид, в схему.
Если мы поговорили со специалистом полчаса, то у нас уйдёт 8-9 часов на то, чтобы разложить эти слова в схему, сделать иллюстрации, обозначить все выявленные проблемы.
Потому что аналитик – не специалист в той сфере, в которой работает пользователь. Но аналитик должен вникнуть в суть работы специалиста за очень короткий промежуток времени, чтобы сообразить, что происходит:
- как работает пользователь,
- что он делает,
- почему он делает,
- для чего,
- в каком порядке,
- когда он делает так,
- когда он делает по-другому.
После второго подхода наша схема преобразилась. Теперь она дополненная, улучшенная. Мы подробнее описали действия человека: уточнили процессы и их порядок. Появились дополнительные вопросы к автоматизированным путям передачи данных. На это ушло 5,5 часов.
Следующий шаг — обращаемся к специалистам, к экспертам, которые знают, как работает автоматизированная передача данных между информационными системами.
Хорошо, если есть документация, но чаще бывает, что документации нет или она устарела, или она написана непонятно. А ещё мало кто рисует схемы — обычно пишут процессы словами, что совершенно ненаглядно и тяжело в понимании.
Этот шаг выглядит так:
- Эксперт (разработчик) рассказывает, как устроена система передачи данных от ИС к ИС, какой там порядок действий.
- Аналитик сопоставляет эти сведения с известными ему проблемами.
- Прорисовывает схему передачи данных.
- И отмечает, где, возможно, находятся проблемные точки, где происходит ошибка, которая мешает работать пользователям.
- Спрашивает других специалистов.
- Поднимает архивы и изучает историю ошибки.
- Сопоставляет «накопанные» ошибки между собой.
Часто пользователи, не обращают внимания на одни ошибки (им они кажутся не относящимися к делу) и «подсвечивают» другие (хотя они совсем другого рода).
Но это не дело пользователя разбираться в ошибках, а это дело как раз аналитика: разложить всё по пунктам.
После третьего подхода схема знатно «раздобрела». Обозначены возможные места ошибок, обозначены критические вопросы, обозначены неясности, в которых нужно дополнительно разобраться.
Подготовлена документация со скриншотами, которая фиксирует и описывает проблему. Аналитик воспроизвёл ошибку, зафиксировал подробно всё, что сумел «раскопать» исходя из своих доступов, исходя из своих возможностей, учитывая, что он не разработчик и не лезет в код.
Аналитик подготовил подробный иллюстративный материал для разработчиков. И на это ушло ещё 9,5 часов.
На этом этапе аналитик готов передать задачу разработчику. Задача сформулирована, люди расспрошены, материалы сформированы — всё проиллюстрировано.
В итоге на аналитику ушло 24 часа. Мы сделали подробную схему: документацию с фиксацией ошибок, отсылками к предыдущим задачам, подобным ошибкам и иной подходящей информации (вроде «где найти того, кто это настраивал»).
Задача передана разработчику.
Аналитик переходит к другим задачам и ждёт, когда разработчик принесёт новую информацию и можно будет думать, каким образом решать проблему.