13 ноября в Казахстане прошла крупная IT-конференция Kolesa Conf’21 — 35 спикеров, 5 направлений: Administration & Infrastructure, Mobile, Data Science, Management и Web.
Амбассадором KazanExpress стал Frontend Tech Lead компании Карен Каспаров. Он рассказывал о Functional Flow — способе моделирования бизнес-процессов, который недавно начали применять в KazanExpress. Поговорили с Кареном и рассказываем, зачем понадобился этот метод, как его внедряли в работу и какие минусы еще предстоит решить.
В чем была проблема?
KazanExpress быстро растет. За последний год штат увеличился более чем в 10 раз — теперь нас 4 000. Раньше, когда команда была небольшой, обсуждать проекты, вносить доработки было легко. Как говорит Карен, «просто повернись к дизайнеру интерфейса и попроси что-то изменить». Сейчас проектов в работе гораздо больше, команда огромная. Постоянно отрывать человека от задач, просить его возвращаться к решенным кейсам — трата драгоценного времени. Это первая причина, почему понадобился структурированный метод работы с бизнес-задачами, который позволил бы избежать доработок.
Вторая причина связана с некачественным описанием задач, когда учтены не все механики пользовательских действий. Дизайнер может продумать не все решения, и в этом случае разработчику не хватает информации для кодирования. «Представим, что нам понадобилось внедрить новый этап в отлаженный процесс приемки товаров. Например, после того как вы отсканировали штрихкод и до того как товар положили в ячейку, нужно проверить код в системе ОКВЭД и удостовериться, что он верный. Это значит, что мы должны учесть все нюансы: а что будет, если код неверный? а если его перепутали? а если нет кода? и так далее. Нельзя просто взять и встроить новую фичу в существующий флоу — система сломается», — говорит Карен.
Почему именно Functional Flow?
Functional Flow — старый метод моделирования бизнес-процессов. Его придумали в 1921 году. Это огромная детальная схема, состоящая из множества блоков, которая учитывает все пользовательские решения — с прописанными к ним условиями. Напоминает внутреннее устройство чатов техподдержки. Выглядит это так:
Выбирали метод после тщательного анализа, ведь существует не только Functional Flow. Все схемы, которые сегодня используют в дизайн-процессе, закрывают определенные задачи. И идеальной нет. Например, Business Flow нужен, чтобы изложить суть задачи, схема там очень простая. User Flow помогает понять, оптимально ли решаются задачи через созданный интерфейс, это уже немного более сложная структура. Functional Flow отличается детализацией. Этот метод учитывает больше решений, и он очень гибкий — позволяет детализировать только часть задачи, а остальное оставить на следующую итерацию.
Как все это работает?
В KazanExpress метод впервые испытали на WMS — эту систему создали два года назад для управления складом и пунктами выдачи заказов. На одном из кейсов — фильтрации сотрудников — Карен иллюстрирует, как работает Functional Flow.
«В системе WMS есть страница со списком: ФИО, должность, некоторые персональные данные. Для начала нужно выделить все элементы интерфейса, с которыми пользователь будет взаимодействовать. Здесь они такие: кнопка добавления нового сотрудника, поле для поиска, поле для фильтра, переключатель отображения уволенных сотрудников и строка сотрудника в таблице. Расположение этих элементов на одном уровне в схеме говорит о том, что взаимодействие с ними может происходить параллельно.
Далее нужно найти элементы интерфейса, которые зависят от каких-либо обстоятельств. В схему их нужно вносить, прописывая условия. В моем примере это чипсы выбранных фильтров. Они отображаются только тогда, когда выбран хотя бы один из независимых элементов, о которых я говорил выше.
Оставшиеся ветки нужно детализировать по аналогии. В итоге получается большая схема, описывающая, как устроен интерфейс. Благодаря конкретизации каждого кейса, разработчик видит картину целиком. Он может предусмотреть все варианты действий пользователя и минимизировать его негативный опыт, то есть bad user experience».
В Functional Flow используется несколько геометрических форм, каждая из которых обозначает свое. Параллелограмм применяется для обозначения интерактивных элементов — тех, с которыми пользователь может как-то взаимодействовать. Прямоугольник нужен для указания обратных реакций на действия пользователя. Ромб описывает условия.
А если задача небольшая, стоит ли заморачиваться?
Карен уверен, что стоит. При составлении схемы неизбежно появляется много вопросов, и дизайнеру приходится возвращаться к заказчику за разъяснениями. Такой подход помогает вносить правки на начальных уровнях работы, идея визуализируется, упрощается разработка.
Главный минус — время. Даже на небольшую задачу его уходит ощутимо больше, чем хотелось бы тратить любому специалисту или бизнесу. Но, по словам Карена, «возможность в дальнейшем минимизировать негативный опыт побеждает».
На каком этапе внедрить Functional Flow и кто рисует схему?
Functional Flow применяется в самом конце дизайн-процесса, уже после исследования, User Flow, прототипа, дизайна и интерактивного прототипа интерфейса. Как говорит Карен, делать Functional Flow до User Flow не имеет смысла, так как User Flow — часть Functional Flow. До прототипа составлять неудобно, потому что иногда прототип раскрывает какие-то детали, и тогда всю схему придется переделывать.
В KazanExpress этим в основном занимается дизайнер интерфейсов. Он глубже всех погружен в задачу и формирует итоговые требования к функционалу. Но это не значит, что остальная часть команды не принимает участия в составлении схемы. Карен уверен: «Самая полезная схема — та, в которую вкомментились все участники конкретной задачи». Бизнес-заказчику это нужно, чтобы четче донести желаемый результат. Дизайнеру — чтобы рассказать, как та или иная часть интерфейса реагирует на действия пользователя. Разработчику Functional Flow помогает сделать решение более гибким, учитывающим большинство кейсов. Тестировщику важно погрузиться в проект, чтобы проверить реализацию в деле и сравнить с изначальной задумкой.
Что в итоге мы получили?
Метод помогает увидеть, не упущены ли какие-либо решения — до того, как команда приступит к разработке или вовсе сдаст проект. Также с Functional Flow легче определить объем работы и установить дедлайн. Теперь в KazanExpress, отмечает Карен, «спринты закрываются практически без долгов». Кроме того, схема хорошо визуализирует идею — это помогает продумывать проект глубже и не возвращать задачу на доработку.
«Сотрудники стали более подробно вникать в продукт, повысилась вовлеченность. Разработка стала в разы приятнее, потому что не приходится тратить время на доработки. Команда действует более слаженно, каждый участник понимает, для чего нужна та или иная фича. Мы смогли убрать из интерфейса все лишнее. Построив всю схему, увидели, какие элементы не соприкасаются с пользователем, а значит не нужны. Поэтому совет — экспериментируйте с процессами и делайте свою работу приятнее», — подытоживает Карен.
Пока что Functional Flow внедрили как эксперимент. Если метод покажет эффективность, оставят. Если нет — попробуют другие способы моделирования. Например, кроме Functional Flow, Карен с командой рассматривали BPMN, он даже более детальный. Сейчас, на этапе эксперимента, он показался слишком громоздким. Но Карен допускает переход на него — после того, как будут оценены итоги эксперимента с Functional Flow.
