Подход, который помог нам точно оценить трудозатраты на разработку дизайн-системы

4adbd39ba5c4dd83d18081c053174ed2.jpg

При планировании проекта команде дизайна приходится отвечать на много вопросов. Главные — что делать, как долго и сколько это будет стоить. Ответы есть не всегда и точно не у дизайнеров, которые занимаются отдельными задачами и не видят картину в целом.

Меня зовут Александр Самсонов, я руководитель отдела UX в СберТехе. Вместе с командой работаю над продуктом Platform V UK Kit — дизайн-системой React-компонентов корпоративного масштаба. Расскажу, как мы начали оценивать затраты ресурсов при разработке дизайн-системы, и как метод помог нам лучше планировать работу, точно отвечать на вопросы и не выглядеть в глазах бизнеса нервными белыми воронами в чёрных толстовках.

Зачем вообще оценивать время на разработку

Вернёмся ненадолго к вопросам заинтересованных лиц. Чаще всего вопросы можно разбить на три группы:

Про время:

— Сколько времени нужно на создание дизайн-системы?

— Когда будет готово?

— Почему так долго?

Про объём:

— Что уже сделано?

— Что ещё надо сделать?

— Что можно не делать?

— Почему этого нельзя не делать?

Про стоимость:

— Сколько стоит?

— Сколько-сколько? Почему?!

На первые две группы вопросов почти всегда может ответить проектировщик, так как он владеет практически всей информацией. А вот третья группа обычно вызывает затруднения и у проектировщика, и у дизайнера. Как вообще рассчитать, во сколько обойдётся разработка радиокнопки с точки зрения ресурсов и денег?

Наша команда столкнулась с этими вопросами, когда приступила к разработке дизайн-системы. В СберТехе десятки продуктов: одни разрабатываются и развиваются не один год, другие находятся поддержке с перспективой замены на новые продукты. Нужно было привести пользовательские интерфейсы продуктов к единому внешнему виду и поведению, то есть перевести на общую дизайн систему. Для компании это означало не только наведение порядка во внешнем виде, но и экономию ресурсов за счёт того, что команды перестанут раз за разом создавать одни и те же компоненты для продуктов.

При этом и бизнесу, и разработчикам нужна была точная оценка времени и стоимости, чтобы правильно планировать последовательность работы над продуктами и вовремя реализовывать важные фичи. Никакой системы оценки не было — и мы начали создавать её для себя с нуля.

Немного теории про дизайн-систему

Поскольку все дальнейшие расчёты ведутся в рамках проекта дизайн-системы, в этой главе я дам немного теории про дизайн-системы вообще. Если вы и так знаете, зачем нужны ДС, как они разрабатываются, и кем поддерживаются — листайте сразу к расчётам.

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

Базовые примитивы:

Айдентику:

Элементы взаимодействия:

  • компоненты;

  • шаблоны;

  • сценарии.

Документацию:

Ресурсы для разработчиков:

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

Делать с нуля или взять готовое решение

При планировании состава компонентов новой дизайн-системы можно ориентироваться на уже существующие ДС. Например, на Ant, в которую сейчас входит около 70 типовых компонентов взаимодействия.

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

Делать с нуля дольше и сложнее: разработчикам придётся ждать, когда в библиотеке соберётся необходимый минимум компонентов, а пользователям может показаться, что продукт остановился в развитии. Зато своя разработка снимает правовые риски и убирает вероятность того, что изменения в корневой дизайн-системе повлекут за собой проблемы в вашем продукте.

Мы решили писать свою дизайн-систему после того, как провели внутреннее исследование и посмотрели, как и с чем работают другие команды в СберТехе. С прицелом на долгосрочную перспективу победила разработка с нуля, так как нам важно было обеспечить независимость от чужой системы.

Как считать время и что такое дизайн-час

Чтобы рассчитать время, нужна понятная единица измерения. Для оценки работы проектировщиков и дизайнеров мы решили использовать условную единицу под названием дизайн-час. Он не равен астрономическому часу, но переводится в него. Преобразование дизайн-часа в астрономические часы и плановые даты завершения работы выполняется через коэффициенты:

  • загруженности;

  • эффективности используемого инструмента;

  • продуктивности сотрудника или его группы. 

Например, опытный дизайнер Петя может проанализировать потребность, сделать черновой вариант, протестировать, скорректировать и выпустить компонент за один рабочий день = 15 дизайн-часов. А джун Вася только погружается в процессы, и ему на эту же работу и те же 15 дизайн-часов потребуется 5 рабочих дней. То есть один дизайн-час для Пети и для Васи в реальности будет занимать разное количество времени из-за разницы опыта.

Важно, что дизайн-час может быть только целым, не делится на более мелкие части. То есть на любую работу уйдёт минимум 1 дизайн-час, даже если опытный Петя сделает это за 10 минут. А так как в продуктовом проектировании и дизайне практически не бывает типовых задач, привести эту единицу измерения к нормативу не получится.

Оценка времени на разработку базовых примитивов

Теперь, имея среднюю временную единицу с учётом коэффициента опыта дизайнера, мы можем перевести её в количество часов. А количество часов — в стоимость разработки, исходя из зарплаты этого сотрудника.

Например, базовые примитивы — палитры, шрифты, плашки и тени — мы считали так. Сначала прикинули все компоненты работы:

  • Количество и наименования (семейства) гарнитур (обычно одна‑две, редко три и больше).

  • Количество стилей текста (для европейских языков может хватить 5–10 стилей, для поддержки азиатских потребуется ещё 5–7).

  • Количество цветов и оттенков каждого цвета (единицы или максимум два десятка цветов, единицы или десятки оттенков каждого).

  • Число плашек, степени прозрачности фона и радиусы скругления их углов (если это требуется).

  • Количество уровней теней (3–7 уровней).

  • Направление и скорость анимации (вывод форм, проявление теней).

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

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

Айдентика

Работу над пиктограммами оценивали так: за один дизайн-час можно подготовить 5–10 пиктограмм, если постановка задачи понятна и образ утвержден. А вот с иллюстрациями и фонами ситуация иная, здесь детализация выше и масштаб работы гораздо больше. В нашем случае одна иллюстрация занимает не меньше двух дизайн-часов.

Вариант выбрать и купить готовый набор допустим только на первом этапе, потом всё равно придётся доделывать и дорисовывать. Мы, например, просто не нашли настолько полного набора пиктограмм, фонов и иллюстраций, который сразу устроил бы все продуктовые команды, поэтому, опять же, делали с нуля.

Компоненты взаимодействия

Компоненты также делятся на базовые и составные: флаг (чек-бокс) — базовый компонент, а радиокнопка — составной. Чек-бокс без сопровождающей подписи может быть использован в интерфейсе, например, в первой колонке записи для её выбора, а радиокнопка без подписи смысла не имеет и применяться не может. Соответственно, времени на разработку компонента чек-бокса без сопровождающей подписи понадобится меньше, чем на радиокнопку с подписью.

Примеры оценки простого компонента

Строго говоря, все базовые компоненты содержат в себе как минимум два примитива: цвет и плашку, цвет и шрифт или цвет и пиктограмму. Оценка сложности компонента равна произведению удвоенного количества входящих в него примитивов и других компонентов (без учёта вариантов) на количество возможных состояний и размеров создаваемого компонента (вариантов). При этом повторные вхождения компонентов или примитивов не считаем. Например, если в компоненте две пиктограммы, считаем её за одну единицу и т. п.

Формула подсчёта простых компонентов выглядит так:

Простой компонент = количество примитивов × 2 × (количество состояний × количество размеров и тем / 2)

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

  1. Флаг (чек-бокс)

Составляющие:  

  • плашка (активна, неактивна);

  • цвет (при наведении, при выборе);

  • пиктограммы рамки, галочки и неполного выбора (есть, нет);

  • подпись.

Итого три элемента для варианта без подписи или четыре с подписью.

Состояния:

  • неактивен (сброшен);

  • неактивен (выбран);

  • активен (сброшен);

  • активен (выбран).

Всего четыре штуки.

Для создания и описания компонента «с нуля» потребуется:

  1. Радиокнопка

Составляющие:

  • плашка (активна, неактивна);

  • цвет (при наведении, при выборе);

  • пиктограммы рамки и точки (есть, нет);

  • подпись.

Всего четыре элемента.

Состояния:

  • активна (не выбрана);

  • активна (выбрана);

  • неактивна (не выбрана);

  • неактивна (вся).

Всего четыре штуки.

Итого, для создания и описания компонента «с нуля» потребуется: 4×2×2 = 16 дизайн-часов.

Оценка сложности составных компонентов

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

Сложный компонент = количество компонентов × 2 × (количество состояний × количество вариантов × количество размеров и тем / 2)

На простейший компонент нужно отводить не менее двух дизайн-часов, потому что при подготовке каждого компонента придётся явно или неявно пройти следующие этапы:

  • Анализ потребности.

  • Анализ состава (это сложность компонента, ее минимум мы уже умеем считать).

  • Составление списка свойств (название и тип).

  • Подготовка рабочего варианта.

  • Коммуникации с коллегами.

  • Тестирование (самостоятельное или с помощью коллеги).

  • Создание дополнительных вариантов (например, размеров или цветовых тем).

  • Подготовка или обновление сопроводительной документации.

Подготовка рабочего варианта, коммуникации и тестирование фактически представляют собой запас времени для исправления ошибок. Если вы умеете делать всё сразу «набело» — повезло, справитесь ещё быстрее!

Примеры расчёта оценки составного компонента

Здесь мы считаем, что все входящие базовые компоненты уже сделаны. Используем вторую формулу расчёта.

  1. График

Составляющие:

  • плашка (базовый, при наведении);

  • цвет (при наведении, при выборе, цвета сегмента для обозначения параметра);

  • изображения (заглушка при отсутствии данных и окружность, разделённая на сегменты);

  • пиктограммы;

  • флаги (чек‑боксы);

  • текст (заголовок, подписи и примечания).

Всего шесть элементов.

Состояния:

Всего три штуки.

Итого, для создания компонента нам потребуется: 6^2×(3/2) = 54 дизайн-часа.

  1. Карточка

Составляющие:

  • плашка (активна, неактивна);

  • цвет (при наведении, при выборе);

  • пиктограммы;

  • Флаги (чек‑боксы);

  • метки (теги, чипсы);

  • раскрываемое меню действий;

  • текст (заголовок, подзаголовок, основное содержание, примечание или дата);

  • график (считаем готовым, на составляющие не делим);

  • кнопка.

Всего девять элементов.

Состояния:

  • активна (выбрана);

  • при наведении;

  • перемещение (перетаскивание на другое место);

  • неактивна.

Всего четыре штуки.

Следовательно, для создания компонента нам потребуется: 9^2×(4/2) = 162 дизайн-часа.

Пример расчёта оценки сложности таблицы

Таблица — самый насыщенный и сложный по составу компонент дизайн-системы, поэтому пример его расчёта приведу отдельно.

Отдельные компоненты таблицы — это:

  • плашка;

  • цвета (фоны для заголовка, записей, разделительных линий, панели информирования, выделенных ячеек и колонок);

  • кнопки;

  • раскрываемые меню;

  • группирующий элемент (аккордеон);

  • поля ввода;

  • флаги (чек‑боксы);

  • радио‑кнопки;

  • пиктограммы;

  • ссылка;

  • метка (теги, чипсы);

  • текст;

  • разбиение на страницы.

Всего 13 элементов

Состояния:

  • ячейка активна;

  • ячейка неактивна;

  • ячейка подсвечена;

  • при наведении;

  • перемещение (изменение порядка записей вручную);

  • при выборе.

Всего шесть штук.

Варианты верстки:

  • строками;

  • колонками.

Всего две штуки.

Размеры:

  • малый;

  • средний;

  • крупный.

Всего три штуки.

Количество тем:

  • светлая;

  • тёмная.

Всего две штуки.

Следовательно, для создания компонента нам потребуется: 13 × 2 × (6 × 3 × (2 + 2) / 2) = 2448 дизайн-часов.

Если какого-то компонента не хватает, к этому числу придётся добавить ещё время на его изготовление.

Результаты в нашей команде

На этапе планирования дизайн-системы нам удалось уйти от приблизительных оценок, которых было достаточно для выполнения работы, к конкретным числам. Такой метод расчёта помогает с точностью до 90% спрогнозировать стоимость и время на разработку каждого элемента дизайн-системы.

Дополнительно к этому:

  • Работа стала более предсказуемой и комфортной благодаря более точным оценкам времени.

  • Экономим ресурсы команд благодаря учёту работы в целом и переиспользованию отдельных компонентов.

  • Оптимизируем трудозатраты, снижаем стресс и неприятные сюрпризы, потому что всегда точно знаем, сколько сил и времени нужно на каждую задачу.

Наработки, которые мы получили в результате работы над дизайн-системой, перенесли в продукт Platform V UI Kit. Сейчас он представляет собой развитую дизайн-систему корпоративного масштаба с возможностью быстрой и гибкой настройки внешнего вида. По сути, это готовое решение для проектов любого масштаба, позволяющее создавать пользовательские интерфейсы и не тратить на это огромное количество ресурсов проектировщиков, дизайнеров или разработчиков. Инструмент подходит командам и приложениям, для которых важны скорость разработки, быстро и качественное прототипирование и создание UI-макетов.

На этом у меня всё. Буду рад ответить на вопросы и комментарии!

© Habrahabr.ru