#про_управление

Сетапы ДС. Внутреняя контрибьюция, она же «партизанская разработка»

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

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

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

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

Сравните с опенсорс проектами: там добровольная контрибьюция работает в силу массовости проекта. К примеру в ant.design 440к пользователей, из них 2 тысячи контрибьюторов. Это менее половины процента! Сколько у вас в компании разработчиков? Допустим 1000. Сколько из них будут стабильно контрибьютить? 5-10. И это не фуллтайм, в лучшем случае вы можете рассчитывать, что вашей дизайн-системе будут уделять пару часов в неделю.

продолжение в следующем посте