Чтобы участники команды чувствовали себя её частью и принимали командные решения, такие решения должны ощущаться справедливыми
Справедливость во многом — это наличие явных правил принятия решений. Подходов к принятию решений много, расскажу про основные. Идеального, конечно, нет
Подходы обычно оценивают по нескольким параметрам:
* скорость принятия решения
* уровень вовлечённости участников
* прозрачность
Первый метод — автократический. Решение принимает один человек, показывая всем свою альфовость
Скорость быстрая, прозрачность околонулевая, никто обычно не вовлечён в принятие решения.
Апгрейд этого подхода — консультативный, когда есть советники
Другая сторона этого спектра — консенсус.
Вся команда должна согласиться с решением. Такой подход очень медленный, с кучей встреч и обсуждений, но коллективный и прозрачный.
Решения принятые консенсусом скорее всего не будут саботироваться
Вариант посередине — consent base или отсутствие возражений.
Он похож на консенсус, но с важной разницей. В консенсусе каждый участник может наложить вето на решение, а тут ищется вариант, который не будет вызывать критических возражений.
Скорость принятия решения увеличивается
Если я считаю, что мы должны найти консенсус, а мой коллега — что решения должны приниматься авторитарно, то мы будем саботировать друг друга.
В команде важно договориться, как принимаются решения и записать это. Этот вопрос можно поднять в любой момент, все скажут спасибо.
Пользуйтесь сайтом thedecider.app, чтобы выбрать вариант принятия решения, который подходит вашей команде
• • •
Missing some Tweet in this thread? You can try to
force a refresh
Дизайн-системы внедрять сложнее, чем библиотеки компонентов потому что количество людей, которые должны договориться на порядок выше
По моему опыту, дизайн-системы появляются у существующих бизнесов, когда накопилось понимание, как выглядят интерфейсы компании
Мне кажется странным делать дизайн-систему в компании с новым или единственным продуктом. Лучше взять готовую библиотеку компонентов
И дизайн-системы, и библиотеки компонентов решают несколько продуктовых задач. Чтобы объяснить пользу бизнесу, я использовал такие аргументы:
* готовые блоки ускоряют time-to-market продукта и новых фичей
* предоставляем похожий UI во всех продуктах
* уменьшается количество багов
Чтобы хоть как-то говорить про дизайн-системы, нужно определиться с терминологией. Мне кажется важным разделить два понятия: дизайн-система и библиотека компонентов (UI Kit)
Библиотека компонентов — это набор готовых строительных блоков для создания интерфейсов. Дизайнеры нарисовали, разработчики напрогали и переиспользуют.
Очень утилитарная штуковина для ускорения разработки интерфейсов
Дизайн-система — это инструмент для формирования общих подходов и паттернов проектирования интерфейсов в компании. Такой альманах, как нужно делать интерфейсы.
Она обычно включает в себя библиотеку компонентов, но может и не включать.