На интервью (обследование или тестовая эксплуатация) пользователь часто сразу показывает решение, а не описывает проблему, с которой столкнулся.
Например, он говорит:
Здесь нужна отдельная кнопка.
Это поле надо сделать обязательным.
Нужен еще один отчет.
Такие пожелания удобно записывать. Они понятны, привязаны к конкретной форме и уже похожи на готовые требования.
Но не стоит торопиться, потому что после нескольких вопросов может выясниться, что кнопка нужна потому, что сотрудник каждый раз вручную определяет следующего участника процесса. Обязательное поле предлагают добавить, хотя никто не договорился, кто и когда должен его заполнять. А отчет хотят построить по данным, которые сейчас вообще не фиксируются (конкретно по отчетам такие требования встречаются очень часто).
В таких случаях доработка сделает привычный обходной путь немного удобнее, но сама проблема останется.
Бывает и обратная ситуация. Аналитик долго ищет недостаток процесса, хотя порядок работы уже понятен, ответственность распределена, а пользователь действительно открывает четыре формы ради одного частого действия.
Поэтому на интервью я стараюсь не решать заранее, что передо мной: плохой процесс или неудобный интерфейс. Сначала нужно восстановить реальную работу и посмотреть, в какой точке она начинает ломаться.
Пользователь рассказывает о том, что видит
Сотрудник работает не с «процессом» как с абстрактной схемой. Он видит карточку, список, задачу, кнопку и сообщение об ошибке.
Если документ несколько дней не двигается, пользователь может попросить кнопку «Напомнить». Если он не понимает, кому передавать заявку, предложит команду «Отправить дальше». Если руководителю не хватает информации, запрос будет звучать как «Давайте сделаем отчет».
Это нормальный способ описания проблемы. От пользователя не требуется самостоятельно проводить обследование и искать первопричину.
Задача аналитика — не спорить с предложением, а понять, какая рабочая ситуация за ним стоит.
Где проходит граница
Процессная проблема связана с самим порядком работы. Например, не определен ответственный, несколько подразделений повторно вводят одни и те же сведения или участники по-разному понимают, что считается завершением задачи.
К этой же группе относятся лишние согласования, отсутствие правил для исключительных случаев и ситуации, когда сотрудник не получает данные, без которых не может продолжить работу.
Интерфейсная проблема выглядит иначе. Порядок понятен, но система мешает выполнить уже определенное действие:
- нужная команда спрятана слишком глубоко;
- форма перегружена полями, которыми никто не пользуется;
- статус операции не виден;
- одни и те же сведения приходится выбирать повторно;
- сообщение об ошибке не объясняет, что нужно исправить;
- простая ежедневная операция требует множества переходов.
На практике граница не всегда очевидна.
Например, сотрудник долго выбирает согласующего. Возможно, список действительно неудобен. Но может оказаться, что в компании нет единого правила: один руководитель выбирает согласующего по сумме, другой — по виду договора, третий каждый раз решает вручную.
В первом случае стоит менять форму. Во втором сначала придется договориться о процессе.
Начинать лучше не с пожелания, а с последнего случая
Вопрос «Что вы хотите изменить в системе?» почти сразу уводит разговор к кнопкам, полям и цветам.
Мне больше помогает другая формулировка:
Покажите последнюю заявку, с которой возникла проблема. Что произошло?
Дальше мы восстанавливаем события по порядку. Кто начал работу? Какие сведения у него были? Что он сделал в системе? Кому перешел объект? В какой момент стало понятно, что процесс пошел не так?
Обязательно спрашиваю, что пришлось делать дополнительно: писать в чат, звонить руководителю, пересылать файл по почте, вести отдельную таблицу.
Именно обходной путь часто показывает реальную причину.
Фраза «форма неудобная» дает мало информации. А рассказ о том, что сотрудник сначала открывает отчет, затем копирует номер договора в Excel и только потом ищет карточку, уже позволяет разбирать конкретную ситуацию.
Сначала нужен обычный сценарий
До обсуждения ошибок полезно понять, как процесс должен работать в нормальной ситуации.
Возьмем заявку на оплату. Я бы уточнила:
- откуда появляется основание для заявки;
- кто вводит сведения;
- кто их проверяет;
- кто принимает решение;
- что происходит после согласования;
- по какому признаку работа считается завершенной.
Если участники описывают этот путь по-разному, проблема уже не сводится к форме.
Один сотрудник сначала направляет заявку бухгалтеру. Другой — сразу руководителю. Третий перед запуском согласования дополнительно пересылает файл по почте.
В этой ситуации нельзя просто выбрать один вариант и закрепить его новой кнопкой. Сначала владелец процесса должен подтвердить, какой порядок считается правильным.
Просить показать, а не пересказать
Часть привычных действий пользователи вообще не упоминают. Для них нормально скопировать значение в блокнот, проверить данные в другом отчете или уточнить что-то в мессенджере.
Поэтому, когда есть возможность, я прошу выполнить реальную операцию. И в ходе такой демонстрации часто обнаруживается разница между инструкцией и реальной работой.
Например, по регламенту вид документа выбирают по содержанию. На практике сотрудники используют два первых пункта списка, потому что названия остальных слишком похожи, а искать нужный вариант долго.
Здесь уже смешиваются две причины: неудачная классификация и неудобный выбор на форме.
Пример: пользователю нужна большая кнопка «Согласовать»
Сотрудник просит вынести запуск согласования на основную форму договора.
Начинаем разбирать последний случай. Оказывается, перед запуском он:
- создает карточку договора;
- пытается определить маршрут;
- пишет руководителю в мессенджере;
- получает список согласующих;
- возвращается в 1С;
- вручную заполняет участников;
- только после этого запускает процесс.
Кнопку, возможно, действительно стоит сделать заметнее. Но основное время уходит не на ее поиск.
Проблема в том, что маршрут существует только в голове у нескольких сотрудников. Нужно выяснить, можно ли определять его по виду договора, сумме, подразделению или другим условиям.
После этого отдельная кнопка может и не понадобиться. Пользователь запускает стандартную команду, а система подбирает участников по согласованному правилу.
Пример: обязательная причина переноса срока
Руководитель хочет сделать обязательным поле «Причина изменения срока». Цель понятна: видеть, почему задачи постоянно переносятся.
Но во время интервью выясняется, что даты меняют разные люди. Иногда исполнитель не успевает закончить работу. Иногда руководитель меняет приоритет. Иногда срок сдвигается из-за задержки предыдущего этапа.
Возникают вопросы. Кто должен указать причину? В момент изменения даты или позже? Что делать, если срок перенес руководитель, а задача находится у исполнителя?
Если эти правила не определить, обязательное поле быстро заполнится значениями «Другое», «По согласованию» и формальными комментариями.
Форма будет заполнена, но анализировать такие данные нельзя.
Здесь запрос выглядит как небольшая интерфейсная доработка, хотя сначала нужно договориться о видах переноса и ответственности за заполнение.
Пример: договор невозможно найти
Пользователь говорит, что поиск в системе неудобный.
Сначала прошу найти конкретный договор привычным способом.
Если сотрудник знает контрагента, номер и вид документа, но для поиска вынужден открывать несколько списков и каждый раз заново настраивать отборы, проблема действительно похожа на интерфейсную.
Но иногда выясняется другое:
- темы договоров заполняются произвольно;
- номер документа указывают не всегда;
- один договор создают несколько раз;
- виды документов используют по-разному;
- часть файлов остается на сетевом диске.
В такой базе даже хороший поиск не даст надежного результата.
Сначала нужно привести в порядок правила регистрации и данные. И только потом решать, каких отборов, колонок и вариантов поиска не хватает.
На что указывает процессная проблема
Во время интервью я особенно настораживаюсь, если слышу, что:
- сотрудники выполняют одну операцию по-разному;
- следующий шаг каждый раз определяет конкретный руководитель;
- объект есть в системе, но работу продолжают по почте или в чате;
- пользователь не понимает, что произойдет после его действия;
- одни и те же данные заполняют несколько подразделений;
- «исключения» встречаются чаще обычного сценария;
- поле предлагают сделать обязательным, но никто не может объяснить, как потом использовать его значение.
Это не доказательство, но хороший повод проверить процесс до постановки задачи на разработку.
Когда проблема, скорее всего, в интерфейсе
Интерфейсная причина более вероятна, когда участники одинаково описывают порядок работы, понимают свои роли и используют одни и те же данные.
При этом затруднение возникает в конкретной точке: долго открывается связанный файл, неудобно выбирать значение, не видно текущего статуса или частая команда спрятана в меню.
Еще один важный признак: после выполнения действия процесс продолжается правильно. Пользователь знает, что делать, но система заставляет его тратить лишнее время.
Например, сотрудник точно понимает, какой договор открыть и какую версию посмотреть, но до файла приходится добираться через несколько связанных списков. Сокращение этого пути не меняет ни полномочия, ни процесс. Это нормальная задача на улучшение интерфейса.
Причина может быть смешанной
Довольно часто приходится исправлять и процесс, и форму.
Допустим, заявки распределяются вручную. Основное правило уже известно: обращения по оборудованию направляются одной группе, по доступам — другой. Но при выборе исполнителя система показывает всех пользователей компании.
Тогда нужно решить две задачи:
- закрепить правило распределения;
- ограничить список подходящими сотрудниками или назначать группу автоматически.
Если изменить только форму, пользователь продолжит вручную принимать решение, которое уже можно формализовать. Если ограничиться описанием процесса, люди будут ошибаться в длинном списке.
Не искать решение во время первого рассказа
Когда пользователь показывает затруднение, легко сразу предложить вкладку, кнопку или автоматическое заполнение.
После этого разговор начинает вращаться вокруг первой идеи. Другие причины уже почти не обсуждаются.
На интервью я сначала фиксирую саму ситуацию:
- контекст;
- текущий путь;
- участников;
- место, где возникло затруднение;
- обходной способ;
- последствия;
- частоту повторения.
Решения обсуждаем позже, когда понятны границы проблемы и есть подтверждение от других участников.
Как записать результат интервью
Не стоит сразу превращать просьбу пользователя в требование.
Вместо формулировки:
Добавить кнопку выбора исполнителя на основную форму.
Лучше записать так:
При передаче заявки сотрудник выбирает исполнителя из общего списка пользователей и периодически направляет ее в другое подразделение. Из-за этого заявку возвращают, а срок обработки увеличивается.
Затем нужно добавить контекст: как часто выполняется операция, от чего зависит выбор исполнителя, какие данные уже есть в карточке и кто сейчас определяет маршрут.
После этого можно сравнивать варианты. Ограничить список. Автоматически назначать группу. Показывать рекомендуемого исполнителя. Или полностью изменить порядок распределения заявок.
Что чаще всего портит интервью
Готовое решение сразу записывают как требование. За кнопкой может скрываться проблема маршрута или ответственности.
Обсуждают только форму. Причина могла появиться на предыдущем этапе, а интерфейс лишь показывает ее последствия.
Интервью проводят только с руководителем. Он знает, как работа должна быть устроена, но не всегда видит ежедневные обходные действия исполнителей.
Аналитик защищает типовой функционал. Фраза «это уже есть в системе» не объясняет, почему сотрудники не используют возможность.
Пытаются автоматизировать неопределенность. Если участники не договорились о правиле, система не сможет надежно принять решение вместо них.
Итог интервью — рабочая ситуация, а не список пожеланий
После встречи должно быть понятно, какую работу пользователь выполняет, какой результат ему нужен и где именно появляется затруднение.
Также нужно увидеть обходной путь и последствия: несколько лишних минут, возврат заявки, потерянный срок или недостоверные данные.
Только после этого можно выбирать решение.
Иногда нужна более заметная кнопка. Иногда — автоматический маршрут. Иногда — единое правило между подразделениями, которое сначала придется согласовать без доработки 1С.
Перед тем как переносить пожелание в требования, я бы проверила три вещи:
Какую работу пользователь пытается выполнить?
Что именно ему мешает?
Останется ли проблема, если изменить только форму?
Эти вопросы помогают не автоматизировать обходной путь и не делать симптом удобнее, оставляя причину на месте.