Бэклог

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

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

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

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

Перейдем к формированию верхнеуровневого бэклога. Рассмотрим этот процесс на основе опыта автора при проведении рефакторинга одной из дизайн-систем.

Соответствуем принципу «Технологичная»

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

№ 1. Составить список используемого ПО и защитить его перед руководством

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

№ 2. Отдать технический долг по версиям зависимостей

Раз есть тех. долг по зависимостям, значит есть шанс, что и все остальное в плохом состоянии.

№ 3. Проанализировать и оценить оставшийся тех. долг

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

№ 4. Взять на карандаш дизайн-долг

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

№ 5. Сформулировать экономическое обоснование дизайн-системы

№ 6. Внедрить agile-разработку в дизайн-систему

№ 7. Отрефакторить компоненты

№ 8. Поднять сайт с документацией

№ 9. Поднять статистику использования компонентов в Фигме и коде: вывести все на единый дашборд

№ 10. Прикрутить типограф для документации, Фигмы и форм на сайте

№ 11. Автоматизировать визуальное тестирование компонентов и историй

№ 12. Настроить автоматический бэкап всех данных дизайн-сообщества: файлы в Фигме и прочие артефакты

№ 13. Поднять кликстрим: Кликхаус + Даталенс

№ 14. Написать редполитику и разместить на сайте

№ 15. Дополнить дизайн-систему паттернами

Соответствуем принципу «Доступная»

№ 16. Определить наличие квалификации по внедрению доступности у команды

№ 17. Определить уровень поддерживаемой доступности

№ 18. Разработать план внедрения доступности и отрефакторить все компоненты

Соответствуем принципу «Открытая»

№ 19. Убедиться, что у всех стейкхолдеров есть доступ к дизайнерской документации: гайдам, витринам компонентов, метрикам, бэклогу

№ 20. Разработать регламент внесения изменений

№ 21. Настроить сбор данных об обновлениях, публикацию Release Notes и донесения информации до конечного пользователя

Заведение задач

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

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

Для фиксации задач нужен трекер. Мы будем использовать Github, но вы можете взять любой современный хостинг репозиториев в котором есть встроенный трекер. Важно чтобы сервис был основан на системе контроля версий Git. В следующих главах вы поймете причину такого выбора: здесь будет вся основная совместная работа, контроль изменений, хранение и автоматизация.

Заведите аккаунт на Github. Перейдите на вкладку Repositories и создайте новый публичный репозиторий по кнопке New, со следующими параметрами:

Создание репозитория Главная страница пустого репозитория

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

Заводить задачи может любой член команды дизайн-системы, не зацикливайте все на себе. Чтобы дать права на заведение, перейдите в настройки репозитория и добавьте участников дизайн-системы:

Команда

В Github все задачи живут в разделе Issues, перейдите в него и заведите наши задачи по кнопке New issue:

Список задач

Настройка окружения

В Github есть несколько способов группировки задач: Labels и Milestones. Это поможет объединять задачи по смыслу и давать ссылки на конкретные группы.

Labels

Метки — это один из способов группировки задач по тем или иным признакам. У нас будет несколько групп меток:

Список задач

По платформам: помогают быстро понять в какой репозиторий вносятся изменения:

По компонентам: помогают быстро понять в какой компонент вносятся изменения. Этих меток будет много, дайте им один цвет:

По типу:

Прочие:

Milestones

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

Milestone