Я волком бы выгрыз бюрократизм.
К мандатам почтения нету.
К любым чертям с матерями катись
любая бумажка. Но эту…
Это был хук, не лишенный смысла, ниже поймете 👇
Где-то год назад в компании созрел запрос на снижение временных затрат на разработку.
Одним из решений было создать свою дизайн-систему.
Я занимался дизайн-системами в
Мегафоне и в Магните, поэтому вписался в эту тему со стороны Android, а чуть позже взял лидерство на себя в зоне Android.Вместе со мной в эту тему впрягся мой хороший товарищ с iOS, который покинул пост и отправился за «золотыми яблочками» (я не могу это осуждать, хотя… 😁). Вот ссылочка на его канал: @technolexa
Первое, что нам предстояло решить, – это как мы будем развивать ДС с ограниченным ресурсом: два разработчика (по одному на платформе) и один дизайнер и все это не отказываясь от бизнес-задач.
Мы со стороны разработки построили флоу (прикрепил скринчик), когда вместо «завода», выпускающего по тонне компонентов, у нас будет система, при которой каждый разработчик будет вовлечен в процесс.
Когда в ДС появляется новый компонент, то он идет не отдельной задачей, а линкуется к фиче, в которой будет использоваться.
Это позволяет распределить разработку ДС на всех разработчиков и одновременно познакомить их с тем, как это работает изнутри. При этом никто не запрещает брать разработку компонентов вне фичи.
Чтобы разработчик мог взять компонент в разработку должны
1. у компонента должен быть паспорт (спецификация в которой описано поведение компонента и его состояния). Без этого документа разработчик не может приступить к разработке.
2. разработчик ознакомлен с требованиями к компоненту ДС.
3. у разработчика должно быть желание и время кодить компонент.
«Складно стелишь, Серега» – можете возразить вы 😏 Откуда у разработчика должна появиться дополнительная мотивация делать что-то вне прямых обязанностей?
Тут я могу рассказать, как Додо внутри открыто к инициативе и что у нас куча ребят, которые делают разные классные вещи.
Но чего верить словам, приходите и сами убедитесь 😉
Ладно, разумеется, есть еще техлид команды, через которого можно повысить приоритет у задачи 😈
Так что же делать, когда все первоочередные условия выполнены?
Разрабатывать! 👨💻
– либо весь компонент полностью;
– либо необходимые состояния для фичи.
Если времени на реализацию крупного компонента нет, то мы договариваемся, что разработчик добьет его в техспринт, либо ответственные за ДС добьют сами и катнут в прод.
Цельный флоу выглядит так:
1. Дизайнеры находят паттерн. Когда в макетах фичи появляется повторяющийся элемент, дизайнеры и разработчики, ответственные за ДС, решают: «Пора в систему».
2. Паспорт компонента. Лид ДС готовит спецификацию.
3. Разработка через практику. Когда фича падает разработчику, он берёт паспорт компонента и сам внедряет его в ДС параллельно с фичей.
Получилось слишком много букв, поэтому в следующем посте продолжу рассказывать про дизайн-систему.
Спасибо тем кто дочитал до конца 🧡