Команда

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

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

Дизайн-система это фулл-тайм. Это полноценный продукт с выделенной командой. Именно о ней мы и поговорим в этой главе.

Принципы команды

Команду дизайн-системы можно сравнить с локомотивом, который задает темп и тянет всех за собой. Чтобы стать таким локомотивом, комада должна быть хорошо настроена, замотивирована и умна.

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

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

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

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

Знания

В основе документа описание базовых настроек дизайнера дизайн-системы: кто он, что умеет, кого читал, за кем следит:Продуктовый дизайнер в Контуре

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

Ценности

Это верхнеуровневая история, более абстрактная, но формирующая отношение дизайнера к делу. Кодекс бюрошника

Во главе ценностей конечно же пользователь:

Уважаем членов своей команды и ценим их время:

Профессионально делаем свою работу:

DoR

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

Зачем нужен

Все банально, он нужен, чтобы экономить деньги компании:

Когда нужен

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

Что внутри

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

Задача прошла по чек-листу проектировщика, учтены и продуманы: Постановка задач по методике SMART

Подготовлены критерии Definition of Done.

Проведена декомпозиция и оценка трудозатрат.

DoD

Все члены команды должны одинаково понимать критерии готовности задачи к релизу, для этого придумали скрамовский артефакт — Definition of Done.

Что внутри

Задача протестирована самостоятельно и соответствует требованиям

Код-ревью пройден

Дизайн-ревью пройден

Pull Requests связаны с задачами и согласованы

Описание компонента добавлено в Storybook

Тесты написаны

Кроссплатформенное тестирование проведено

Производительность в норме: время загрузки, рендеринг, память

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