Эстимирование дизайна

Меня зовут Илона, я Senior Experience Designer в EPAM. Работа для меня удачно совпадает с хобби — в EPAM я проектирую интерфейсы для зарубежных заказчиков, читаю лекции для сотрудников и студентов лабы, менторю дизайнеров. В свободное время преподаю проектирование интерфейсов в магистратуре Университета ИТМО и веду Телеграм-канал о UX-дизайне.

Эстимирование — процесс оценки работы до её выполнения. Это одна из самых важных и болезненных тем для любого специалиста, будь то программист, тестировщик, менеджер или дизайнер. У вас всегда просят как можно более точные оценки, чтобы спланировать работу. Но эстимейты — это лишь гипотеза, которая может разойтись с реальностью. И чем менее ясная задача, тем больше это расхождение.

В этой статье я хочу поделиться спецификой оценки работы по дизайну и подходом, который помог нашей дизайн-команде в одном из проектов EPAM.

Проект и дизайн-команда

Проект, на котором мы работаем — крупная e-commerce платформа с большой командой (80+ разработчиков, менеджеров, аналитиков, тестировщиков) и быстро меняющимися требованиями. На таком крупном проекте логично образовалась дизайн-команда из 4 ролей:

UX-дизайнер, задача которого выяснить требования и сгенерировать наиболее удобное пользователям решение.
UI-дизайнер (в EPAM эта роль также именуется «Visual-дизайнер»), который отвечает за то, чтобы интерфейс был красивым, эстетичным, хорошо смотрелся на разных разрешениях, соответствовал концепции бренда и возможностям разработки.
Юзабилити-специалист, который регулярно проводит тестирования дизайна с настоящими пользователями системы, интерпретирует результаты и составляет список рекомендаций по улучшениям.
Team Lead, который налаживает процессы и решает оргвопросы, обеспечивает команде комфортные условия работы и также занимается UX-дизайном.

Процессы в проекте построены вокруг Scrum: планирование спринта с оценкой задач, двухнедельный спринт, ревью и ретроспектива. Задачи команда оценивала в часах: сколько по времени успеваем — столько и берём в следующий спринт. Звучит просто, но оценка в часах вызывала большие трудности у дизайн-команды.

В целом, задачи на дизайн сложно оценивать в силу нескольких причин:

Требования на дизайн, как правило, наиболее неформализованные и приходят в виде «сделайте чтобы было хорошо». Это нормально, но трудно в часах оценить время на поиск и проверку решения. А нужно ещё успеть его отрисовать и подготовить к разработке.
В ходе работы приходится тратить время на обсуждение и мозговой штурм некоторых задач внутри проекта или с заказчиками. У людей разная доступность, временные возможности и даже часовые пояса. Процесс может откладываться, затягиваться, а задача — «висеть».
Каждую идею нужно проверить и утвердить с заказчиком. И не так просто понять, сколько времени это займёт и как результат обсуждения повлияет на работу дизайнера.
Дизайн должен быть верифицирован командой разработки. Если предложенное решение технически невозможно реализовать в срок, дизайн нужно дорабатывать. Трудно предсказать заранее, случится ли это и сколько может занять.

Вот некоторые цитаты из ретроспектив, которые мы проводили внутри дизайн-команды:

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

Относительная оценка сложности

Звучит довольно… сложно. Я постараюсь сильно не углубляться в принципы Scrum, а лишь проиллюстрирую подход на примере работы нашей команды.

Согласно Scrum, для оценки задач используется абстрактная единица Story point. В одной команде ею могут измеряться часы, в другой дни, в третьей что-то ещё. Кому как удобно.

В нашей команде 1 Story point был равен 4 часам. И нам, по перечисленным ранее причинам, было крайне тяжело оценивать работу в таких Story points. Поэтому я решила наделить Story point другой мерой — сложность.

Сложность (complexity) — количество усилий, необходимых для выполнения задачи.

В нашем случае оценка сложности в Story points оказалась гораздо эффективнее, чем оценка часов, потому что:

Оценка сложности помогает сконцентрироваться на создании ценности, а не погоне за временем. Мы перестали пытаться «успеть хоть что-то в заявленные сроки».
Проще включить обсуждения, подтверждения и брейнштормы в итоговую оценку.
Заказчик лучше воспримет: «задача очень сложная», чем «мне нужно в два раза больше времени на выполнение задачи».
Исключаются обсуждения в формате «Я бы сделал эту работу быстрее».
Обычно мы тратим много времени на споры, сколько времени нужно для выполнения задачи, потому что время — это очень личная мера. Мне нужно 5 часов, а моему коллеге может понадобиться 8. Оценка сложности не такая персональная и люди легче приходят к единой оценке.

Возможно, эти причины будут актуальны и для вашей работы.

Параметры сложности

Сложность — комплексная мера, и трудно сходу сказать, что это значит. Для удобства дизайн-команды я разделила сложность на 4 параметра*:

Зависимости от других людей
Навыки дизайнера
Количество коммуникации в рамках задачи
Согласованность нового дизайн-решения с уже существующими

_*_{хотя параметры описывают работу дизайнера, я думаю, они будут актуальны и для других специалистов.}

Для каждого параметра я подобрала шкалы от 1 до 4. Например, оценка параметра Зависимость (Dependency) выглядит так:

1 (нет сложности) — никто кроме дизайнера не вовлечён в работу, нет зависимости от других людей;

2 (низкая сложность) — 1 человек вовлечён и немного работы с стороны;

3 (средняя сложность) — 2-3 человека и/или много работы со стороны;

4 (высокая сложность) — более 3 человек и/или невозможно определить количество работы со стороны.

Подробные шкалы по всем четырём параметрам сложности можно найти в моём докладе для конференции Design Z Day:

Как понять, что сложно, а что нет

Всё познается в сравнении. ©

Если время можно определить конкретно (например, «два часа»), то с оценкой сложности возникают проблемы. Что значит «сложно»? Где грань между «сложно» и «очень сложно»?

Секрет — относительная оценка. Задачи оцениваются не в вакууме, а относительно друг друга, в сравнении.

Чтобы измерить сложность задачи в абстрактных Story Points, нужно сравнить две задачи и понять, насколько одна сложнее другой.

Например, задача №1 — переделать форму входа на сайт. Задача №2 — переименовать кнопки на странице регистрации. Задача №1 явно сложнее задачи №2, при этом нам не обязательно решать, сколько времени займёт выполнение каждой из них.

Процесс сравнения всегда основан на опыте конкретной команды. Поэтому оценки каждой команды уникальны.

Как наша команда начала использовать относительную оценку сложности

Нам было сложно перестроиться с абсолютной оценки часов на относительную оценку сложности.

Для начала я описала все параметры сложности во внутренней документации, привела примеры оценки. Мы обсудили это с командой. Далее мы проделали следующее упражнение:

Из прошлого спринта, который мы оценивали в часах, взяли 3 задачи. Мы их уже выполнили, поэтому всё про них знали. Для каждой задачи мы последовательно прошлись по 4 параметрам сложности (зависимости, навыки, коммуникация, согласованность) и дали новые оценки в относительных Story Points. Это было непросто, мы долго обсуждали каждую оценку и приходили к единой цифре. Вот что у нас получилось:

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

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

Результаты перехода на относительную оценку сложности

Хочу поделиться отзывами команды о первых спринтах с новым подходом — относительной оценкой сложности.

Работа стала более предсказуемой и комфортной. Мы тратим меньше времени на оценки, и с каждой оценочной сессией становится всё легче и легче. Ушли проблемы оценки затрат на коммуникацию, споры и личностный фактор скорости работы. Команда сфокусировалась на ценности, которую приносит задача, и перестала пытаться «хоть что-то успеть».

Важные результаты для нашей дизайн-команды:

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

Как итог, меньше стрессов, переутомления и неприятных сюрпризов.

Больше о проектировании интерфейсов и UX можно почитать в моём телеграм-канале «Поясни за UX».

Let’s block ads! (Why?)