0:00 Когда говорят дизайн-система, у большинства в голове всплывают кнопки, отступы и библиотека компонентов.
0:05 Но что если это не просто сервис, а настоящий продукт со своей командой, метриками, планированием и даже нейросетью, которая сам собирает интерфейсы.
0:21 Сегодня в гостях у тусовки Аля Чугунова, руководитель команды дизайн-системы во внутренних продуктах СБР.
0:26 Ее команда живет по всем законам продуктовой разработки.
0:30 В этом выпуске мы поговорим, как это работает изнутри, как считать эффективность дизайн-системы и зачем дизайнеру знать слово Джейсон.
0:39 Аль, мы когда с тобой созванивались до подкаста на некоторый брейншторм, ты сказала про то, что ваша команда дизайн-системы позиционирует себя как продуктовая команда.
0:49 Хотя обычно команда дизайн-системы - это больше сервис, в который поставляют какие-то задачи, эти задачи отдаются, ну, то есть обслуживание других продуктов.
0:57 Расскажи, пожалуйста, чем вообще твоя команда занимается и чем она отличается от сервисных дизайн-систем?
1:03 Мы действительно сейчас позиционируемся немножко как продуктовая команда, хотя изначально мы тоже начинали с сервисной команды дизайн-системы, как и все.
1:12 И в моей команде, например, даже не было дизайнера, у меня была только команда разработки, и дизайнер - это была отдельная команда сервисная, которая нам создавала дизайн-систему.
1:22 И это было немножко странно, раздрозненно, было кучу проблем с коммуникациями, хотя, казалось, работаем над чем-то одним.
1:29 И в какой-то момент я стала активно продавать идею, что мы тоже продукт, и что мы должны быть как продуктовая команда, все вместе, все в одной связке делать наши продукты качественнее, лучше и красивее, раз уж мы говорим про дизайн-системы, так у меня появилась полноценная команда с дизайнером, даже со своим исследователем, разработчиками, тестировщиками, что в принципе никак не отличается от любой продуктовой команды, которая есть в любой компании.
1:59 Ты так легко сказала, я захотела, и у меня получилось.
2:02 Но мы же понимаем, и слушатели, наверное, понимают, что это нелегко.
2:06 И мы дальше с тобой об этом поговорим.
2:08 Здесь есть определенный навык защиты перед бизнесом.
2:12 Ну окей, давай немножко раскрой: вот в чем все-таки отличие, состав людей понятен.
2:18 Если сравнить продуктовую команду и команду дизайн-систем, ну, вот классическая продуктовая команда, пилет фич.
2:24 Да, они исследуют, пытаются улучшить эволюционировать продукт.
2:29 Если это там Б2С, то, соответственно они ориентируются на метрики продаж.
2:33 Что здесь все-таки в чем отличие или в чем похожесть?
2:38 Да, я расскажу чуть, почему продуктовые.
2:42 Обычно сервис - это история, которая работает.
2:45 Ну, я говорю, по канбану, на самом деле, вот, как раз: к нам пришли потребность, мы это сделали.
2:51 То есть, у нас есть заказчики, команды продуктовые, мы просто делаем то, что они говорят: приоритизируя, расставляя приоритеты и идя вперед.
3:00 Мы же пошли чуть дальше.
3:02 Мы поняли, что как дизайн-системы можем предоставлять еще различные прикольные инструменты, дополнительные, которые помогут ребятам работать с ЮА-м.
3:11 Проще работать с дизайн-системой, например, как-то быстрее ее подключать к себе, проверять свои интерфейсы, писать автотесты, сделать продукты, например, доступными, а еще это потом как-то померить, и мы стали в параллель с тем, что мы действительно живем как сервисная команда: делать свои фичи, делать свои библиотеки, разрабатывать свои плагины, которые чуть упрощают жизнь на самом деле продуктовых команд, когда они начинают их использовать.
3:40 Из такого быстрого примера у нас есть библиотечка, которая прямо из кода генерирует видеоролики.
3:48 Такие как моушен дизайн - только нам дизайнер не нужен.
3:51 Мы делаем это прямо из кода, и это получаются эффектные ролики буквально за пару минут и пару кликов.
3:57 И вам не нужно знать всю вот эту сложную анимацию, автор-эффект и какие-нибудь видеоредакторы, в которых это потом все склеивать.
4:06 Хочу тогда понять, а как это относится к дизайн-системе?
4:09 Как оказалось, это может относиться напрямую, если быстро и цепочку дальше работы команды.
4:15 Ну, например, мы это делали для себя изначально, как и любая отчасти продуктовая команда.
4:20 Они думают, фичи, которые было бы круто добавить в их продукт.
4:23 И мы точно так же с командой садимся, бройнштормим, о чем можно крутого сделать и разработать еще.
4:29 И делаем подобные инструменты.
4:31 А потом находим их реальное применение для других команд и продуктов.
4:36 И здесь есть особенность отдельная: что наши инструменты доступны только в нашей дизайне-системе.
4:42 Их отдельно не подключишь, а значит, что продукты, которые работают с нашей дизайн-системой, могут воспользоваться нашими уникальными инструментами.
4:50 И вот это такая особенность, наверное, на которую мы подсаживаем удочку.
4:54 Продукты - почему они могут выбрать, например, нашу дизайн-систему.
4:58 Ничего, они без вас не могут, понятно.
5:01 Да, мы их немножко так подсадили.
5:04 Ты сказала, что ты протащила это решение.
5:08 что стоит за этим решением?
5:10 Первое - это сложность в целом доказать необходимость и эффективность дизайн-систем.
5:17 Они всегда появляются не сразу.
5:19 Сначала создаются продукты, а только потом дизайн-системы.
5:24 И здесь мы поняли, что мы настолько разрослись, что, во-первых, без дизайн-системы никуда.
5:30 И она отсюда вообще появилась и стала создаваться.
5:33 Создавалась, как у всех, мне кажется, на коленках: кто-нибудь договорился, скооперировался.
5:37 Но в какой-то момент мы поняли, что это сложно масштабировать и сложно поддерживать - как в нашем случае, на три платформы.
5:46 У многих, я думаю, есть это боль.
5:47 У кого-то это разрожненные команды, одни делают дизайн-систему под мобилку, вторые под веб.
5:53 У нас это одна команда, чтобы решить первую проблему - отсутствие консистентности между платформами.
6:00 Вторая история была о том, что чтобы доказать, что ты работаешь как продукт и ты можешь работать эффективно, для бизнеса это всегда цифры и метрики.
6:10 Вот им это нужно, им нужна выгода, им нужна экономия.
6:13 И продуктовая команда оказалась в этом плане выгоднее, чтобы доказать вашу эффективность.
6:20 В продуктовой команде всегда мерятся метрики.
6:23 И мы в своей команде дизайн-системы тоже уже рассматривали себя не как сервис, а как продукт, который должен стремиться к метрическим результатам.
6:31 Пусть это изначально было просто количество компонентов, но потом мы уже раскрутили всю эту историю, придумывали кастомных метрик, которые смогли как раз доказать ту самую эффективность.
6:43 А что вообще поменялось?
6:45 Вы стали мыслить как продукт?
6:48 Мышление точно поменялось, и поменялось оно, да, как в сторону продуктового, потому что мы стали работать как команда, и стали думать не как сервис, что к нам придет - вот такой продукт и попросит новую кнопку, а стали думать: как нам улучшить то, что у нас есть, чтобы это принесло пользу всем нашим потребителям и пользователям.
7:10 Мы стали рассматривать наши продуктовые команды как обычных пользователей, собирать с них оценки, собирать обратную связь, проводить интервью, коридорные исследования - прям вот по всей цепочке продуктов мы прошлись.
7:24 И это на самом деле дает совершенно другие результаты: дает больше инсайтов и дает больше понимания, о чем реально людям надо, и что реально нужно командам разработки, командам дизайна и менеджерам сверху, которые потом на все это еще и смотрят.
7:38 Ну а вы как команда можете влиять на другие продукты?
7:42 Если взять классическую команду дизайн-системы.
7:45 Они окружены продуктами.
7:47 Они приходят и говорят: дай вот компонент я собрал там.
7:49 Ну, либо дай компонент, либо мы законтрибью этот компонент, дай.
7:54 Они получают на выходе готовый компонент в библиотеке, там, фигми, пиксо, неважно, разработанный компонент, он положен в сторибук.
8:02 И вот тут, на этом моменте, связь с продуктовой командой и дизайн-системой она вот этот флоу обрывается, потому что одни не влияют на других.
8:12 Вот вы как продуктовая команда дизайн-системы можете ли влиять на решение тех продуктовых команд, которые затаскивают фичи какие-то?
8:20 Тут будет ответ: частично да, частично нет.
8:24 Нет, потому что у продукта есть продукт-онер, и есть свой менеджер, руководитель, который его развивает непосредственно.
8:31 Он знает, куда им надо расти, он знает свою аудиторию, куда ему наращивать метрики и двигать в целом продукт.
8:37 При этом мы для всех стали тем продуктом и тем инструментами, который им позволяет посмотреть на продукт с другой стороны, посмотреть и найти какие-то минусы в своем продукте, потому что у нас есть под это дополнительные инструменты.
8:52 Позволяет продуктам, например, заняться автотестированием, потому что мы это предоставляем из своей коробки в части кода.
8:59 У нас есть и такие фичи, не только для дизайнеров предоставляем различные плагины, с которыми они могут запустить и потестить свои продукты, увидеть какую-то аналитику, статистику, результаты этого тестирования.
9:11 Для них получается набор инсайтов, гипотез по дальнейшему улучшению и развитию продуктов.
9:18 Либо же, например, они не успевают разбирать всю обратную связь, потому что может ссыпаться довольно много, а мы можем суммаризировать и таким отчасти, конечно, экспертным мнением, где-то показать реально, где западающее место у продукта есть сейчас - ну, в части Юкса или УА.
9:35 И что ему стоит сделать, чтобы его пользователи ставили оценки выше, и удовлетворенность в целом росла.
9:41 Слушай, ты заговорила про метрики, ну и вот про протаскивание решений.
9:46 У нас же, как обычно, каждый первый дизайнер - вот кнопочка красивая или некрасивая, остальное как бы не важно.
9:54 Но для бизнеса все-таки бизнес умеет читать деньги, и он понимает, насколько дорогая команда сама по себе, которая поставляет компоненты, и здесь важно каким-то образом объяснить бизнесу, что команда дизайн-система - это вообще эффективность.
10:10 Вот здесь, наверное, я бы хотел несколько моментов раскрыть: во-первых, как ты затащила эту историю, а во-вторых, как вы вообще обосновываете свою работу на цифрах для бизнеса?
10:24 В принципе, будет логично начать - как раз с первого шага, когда мы в целом затащили эту историю как команду: это отдельная команда, это может стать продуктовой командой.
10:33 Первое, на что я решила, что мне надо давить - это деньги.
10:39 Самое, мне кажется, больное для бизнеса и самое важное для бизнеса.
10:44 Что я сделала, я посчитала эффективность команды и продукты дизайн-системы в денежном эквиваленте.
10:51 Считается это довольно несложно, как оказалось.
10:54 Считала я это на этапе МВП, когда компоненты только их там было не так много, она разрасталась, библиотека, но не так активно.
11:01 И это стали использовать команды.
11:02 У меня пошла простая аналитика, стала опрашивать разработчиков, дизайнеров.
11:08 С них мы собираем оценки.
11:10 Оценки легко переводятся в часы-минуты, а разработчики и дизайнеры переводятся в их зарплатные эквиваленты.
11:17 Прости, оценки временные.
11:20 Да, ну сколько они потратят время на разработку того-то.
11:23 То есть мы понимаем, что дизайн-система используется для разработки экранов.
11:28 Мы знаем, сколько стоит.
11:29 Например, разработать кнопку, знаем, сколько стоит разработать экран с этой кнопкой.
11:34 Можем собрать оценки в части дизайна, разработки, тестирования, учесть, прям все этапы учесть.
11:40 Это довольно несложно, потому что скрам нам позволяет, в принципе, аджил проставить оценки на каждом этапе.
11:47 У каждого мы знаем зарплату.
11:48 Мы знаем, сколько стоит его час работы.
11:51 После чего все пошло разрастаться, мы начинаем домножать.
11:54 Домножать либо на количество компонентов, либо дальше мы умножаем на количество команд потребителей этих компонентов.
12:01 И вот тут становится интереснее.
12:03 За счет того, что мы знаем, сколько стоит один набор компонентов, и знаем, сколько будет стоить х10, например, наборов компонентов, потому что команд 10.
12:13 И если дизайн-системы нет, мы все прекрасно знаем, все будут делать свои кнопки.
12:17 И как бы кто ни уверял, что разработчики тоже собирают компоненты, они собирают, но делают каждый свой - все равно.
12:25 Мы легкой математикой и вычитанием поймем, насколько реально денег мы можем терять.
12:32 А дальше деньги я переводила во время.
12:34 Потому что работая в Б2 сегменте, тебя не всегда говорят.
12:38 Б2 - бизнес-то имплой.
12:42 Мы понимаем, что мы не зарабатываем денег.
12:46 Мы условно их зарабатываем.
12:47 И на самом деле наше задача, основное предназначение - это экономить деньги нашей компании и ускорять работу наших сотрудников.
12:53 И здесь дизайн-системы тоже показывают крутые результаты, мы тоже можем начать переводить все во время.
12:58 Хотя самые оценки нам классно помогли все это пересчитать и пересчитать в экономии времени.
13:04 А сколько обычный разработчик будет экономить на разработке какой-нибудь фичи, сложной фичи, легкой фичи.
13:11 Я их поделила еще по уровню, потому что сложная фича может там зависеть от не
13:17 ЮА, а больше от какого-нибудь там бэк-эндового сервиса такая, более часто.
13:25 У меня были доступы во все джиры.
13:27 Нет, вот джиры понятно, но аналитика на основе чего?
13:31 Вот ты садишься, считать.
13:34 Как ты оцениваешь, что вот эта фича будет сложная?
13:36 А вот эта средства - это была экспертная оценка - то есть, это оценивал не я, а лиды, лиды разработки, то есть, я пошла через них, и то есть, это была прям непосредственно экспертная оценка, конкретного направления, то есть можно назвать это качественной, наверное, оценкой.
13:49 То есть она не прям какая-то явная количественная, но все равно это уже какое-то число, которое смогло дать очень сильный толчок и дать первый шаг для бизнеса нашего - подумать в целом над созданием команды.
14:04 И первое, что они дали, и на что согласились, - это как раз небольшой эксперимент, я бы это назвала: эксперимент в формате команда в команде.
14:14 То есть, мы сформировали небольшую команду дизайн-системы, но внутри команды продуктовой, в которой мы жили и работали с ребятами вместе.
14:21 И дальше на основе этого эксперимента я просто продолжила считать: считать и следить за эффективностью, потому что задачи стали внедряться, компоненты стали переиспользоваться, и уже эти все экспертные оценки превратились в реальные.
14:34 И я потихоньку, развивая дизайн-систему, при этом развивая все наши продукты, которые работают с этими компонентами, еще небольшой группой, стало следить просто за оценками и дальше считать уже реальные цифры, реальные фичевые задачи - благо в джире, все еще это все вели.
14:52 Это на самом деле иногда проблема.
14:53 Не все ведут так хорошо джиру, и поэтому у кого-то сложности такие вещи считать.
14:58 А потом мне пришла гениальная мысль.
15:00 Я подумала: так как иногда, как аналитик, начиная с системно, приходилось еще и тестировать продукты, я поняла, что очень часто уайные баги выходят на пром, потому что на них немножко забивают: типа, ну и че?
15:13 Ну, съехал отступ, ну, пиксель перфект никому не нужен.
15:18 И вот такие баги я стала тоже считать: понимая, что дизайн-система - это тот инструмент, который от этого избавит нас всех.
15:24 Там будет пиксель перфект, потому что мы ДС-ку сделаем шикарную.
15:29 Себя не похвалишь, никто не похвалит.
15:32 И после того, как мы сделаем это, мы избавимся от багов.
15:36 И реально я стала тоже замечать: и следить - уже вела такую отдельную аналитику багов - юайных багов, которые выходили до промо, потом до тестового стенда.
15:46 За 3 месяца они сократились в 8 раз.
15:49 И это очень хороший был показатель и результат качества продуктов для бизнеса, потому что во внутренних, в том числе, на качество, любят смотреть.
15:58 Потому что для нас тоже это хорошая как критерий и оценка.
16:03 А вот знаешь, хотелось бы здесь немного контекста: в какой момент вот я уже услышал несколько тезисов: что было компонентов немного, но команды там с ними работали, когда-то компонентов не было.
16:15 Вот где ты тут появилась с своей продуктовой командой?
16:19 Ты же не с самого начала придумали 5 продуктов, и эти 5 продуктов мы начнем делать по дизайн-системе.
16:26 Они же уже работали, жили.
16:28 Да, я вообще изначально работала, получается, системным аналитиком в команде - обычной продуктовой одного из внутренних продуктов.
16:35 И мы, как я и сказала, все начинается с инициативы с девочкой, фронт-энд-разработчиком, с которыми супер хорошо общались.
16:44 В целом, начали разгонять эту тему, что круто было бы подобные и одинаковые вещи просто выносить в общую какую-то либо - в одно место, где это могут переиспользовать.
16:55 И мы начали об этом думать в тот момент, когда продукт стал активно расти, и количество команд стало расти: соответственно, количество разработчиков и количество дизайнеров.
17:05 То есть, это люди, которые масштабировались.
17:08 Но наши компоненты, из которых можно было собирать экраны, и они не масштабировались.
17:12 То есть мы понимали, что сейчас сядет и будет тратить время разрабатывать одну и ту же кнопку 10 раз.
17:18 И первая - сразу мысль - зачем?
17:22 И начали делать ЙОА-кит, не дизайн-систему еще, потому что просто паковать компоненты в одну папочку.
17:29 Потом стали договариваться с дизайнером, нашли дизайнера, который готов был этим позаниматься.
17:35 И с ним прям сели и начали этот первый шаг дизайн-системе, когда сели за токены, начали собирать шрифты, паковать их в нормальные переменные цвета собрали, как-то их расположили семантически все это делалось на коленке, еще на самом деле, без какого-либо опыта, поэтому любые дизайн-системы потом терпит изменения или дизайны.
17:55 Как раз из-за того, что все сначала мы коленко собираем.
17:58 А потом мы начали искать еще других разработчиков.
18:01 Зная, что у нас есть мобилка, где такая, так.
18:03 Но если мобилка будет еще отставать, и она и так отставала очень сильно от веба, как очень часто бывает у всех, я нашла разрабов тоже, с которым подговорила немножко, там, сдружилась, типа, я такая, давайте.
18:18 Давайте, хотите поучаствовать.
18:21 И ты очень прикольно продаешь такие вещи людям, которым непосредственно этим пользоваться.
18:27 Как оказалось, то есть разработчики шарят, что такое дизайн-система.
18:31 Дизайнеры шарят, что такое дизайн-система, и им даже отчасти продавать не надо.
18:35 Ты им приходишь, объясняешь вашу идею, и он такой: да давай.
18:39 На чистом энтузиазме.
18:41 Понимая, что это будет поверх работы основной, все равно все были готовы вкладываться, изначально понимая, что дальше от этого получит выгоду.
18:50 И вот это, наверное, был отдельный плюс, что у тебя вот это было ощущение, что вокруг-то тебя все понимают.
18:56 Хотя бы вот на уровне, да, все заряженные, хотя бы на уровне команд - то есть обычных наших работяг, все такие, да, круто, это точно нам поможет.
19:06 А вот дальше был шаг, когда мы поняли, что это действительно выстрелило, это действительно потребовалось.
19:12 То есть, еще выросли команды.
19:14 Этим стали пользоваться, потому что были внутренние договоренности через ледов, еще через кого-то, и мы решили, что надо это бизнесу продавать, нести, а чего сидеть?
19:26 Уже тяжеловато делать это в свободное, как бы от работы время немножко, потому что есть основные задачи?
19:34 Я стала думать, а как это продать.
19:36 И вот тут пошли вот эти все мои подсчеты: первые метрики, скролинг, вообще джира, бесконечные, разных продуктовых команд.
19:44 Ну, ты посчитала, сколько ты сама времени потратила на то, чтобы подготовиться?
19:48 Блин, честно, я об этом, кстати, вот не думала даже, что я тоже тратила свое время, но мне это было настолько - то есть, типа, мне хотелось, мне было интересно, я понимала, что это очень надо, что это очень круто.
20:01 И это как бы мое первое место работы.
20:05 глаза заряжены, сейчас все сделаем, все будет круто.
20:08 И мне кажется, мне очень сильно повезло, что я изначально не уперлась-то в стену с этим, потому что часть, я знаю, ребят, они всегда упираются в этот момент в стену, и им надо искать еще способы, как доказать.
20:19 А мне дали попробовать.
20:21 Вот такие давай поэкспериментируем, чтобы еще посчитать, и доказать реальную эффективность, реальную экономию, кайф.
20:34 Понятно, как бизнесу было доказано, посчитано, но вот сейчас вы находитесь в точке, что вы что-то делаете.
20:42 Все равно же нужно отчитываться, как вы сэкономили, насколько вы эффективны, а что вы еще сделали?
20:50 Захотелось метрик чуть коснуться поглубже, потому что с продуктом понятно, ты можешь там замерять лояльность, покупательскую способность, конверсию - считать, а тут непонятно - здесь же речь про кнопочки.
21:05 Вот что можно в дизайн-системе посчитать.
21:08 Первое, с чего мы начали - с самого банального - это с Сисая.
21:12 Вот, казалось бы, просто удовлетворенность тем, что ты делаешь.
21:17 С продуктовыми командами?
21:18 Те, кто непосредственно использует твою дизайн, с чем.
21:20 То есть это продуктовые команды, у кого-то там у нас была отдельно сервисная команда дизайна, то есть с ними тоже.
21:26 И они нас просто оценивали, раз в квартал, мы считали это.
21:34 Не людей, не команду, а отдельную дизайн-систему.
21:38 Людей они и так оценивали, и так приходили, общались, рассказывали.
21:41 Нам было важно все же именно то, что мы делаем, а не кто мы такие.
21:45 Кто мы такие, мы в принципе вроде плюс не понимаете.
21:48 Ну, там скорость ответа, насколько быстро отвечают или делают.
21:52 Да, но мы в это чуть пошли попозже.
21:54 Изначально мы начали с оценки просто дизайн-системы, чтобы понимать, что то, что мы делаем, оно реально нужно, и оно им подходит - и мы идем в нужную сторону.
22:03 Потом этого стало очевидно мало, и пошли - как раз то, о чем ты говоришь, это про скорость, про такой некий слой на разработку нового компонента, на обновление компонента, на консультацию по дизайн-системе по компонентам.
22:17 Это тоже мы заложили как такую небольшую метрику.
22:19 Сколько у вас человек в команде?
22:21 На данный момент у нас 7 человек.
22:27 Один дизайнер, один разработчик веб, один айоса, один андроида, один тестировщик.
22:34 Всех по одному у нас.
22:38 На компонент примерно 2-3 дня.
22:43 Мы уже просто выросли.
22:46 Мы большая дизайн-система, и у нас не так много потребностей сыпется сейчас.
22:53 На начальном этапе: да, это было тяжеловато, но там сработала
22:59 мой первый шаг в развитии в целом, где-то как менеджер, то есть, как продукт, поэтому где-то я говорю, что я продукт.
23:05 Потому что приоритизация, вот эти менеджерские тайм-менеджменты, это все выстраивала я, чтобы мы ребята не зашивались в команде, мы все успевали, отдавали всем в срок.
23:16 Но да, изначально, конечно, потребности сыпались только так, и мы сами составляли себе этот бесконечный бэклок - что нам нужно сделать.
23:24 Ну, вы с принтами идете?
23:26 Мы идем не совсем с принтами.
23:29 У нас есть канбан-история, то есть мы живем по приоритету, и чем нужнее важнее задача, она идет наверх доски, ее берут в первую очередь.
23:37 Как приоритизируете?
23:39 За счет срочности задачи для команды, за счет ее важности уровня, так как мы внутренний продукт, у нас основные заканчивают - это наш бизнес и топ-менеджмент.
23:49 Соответственно, если это примерно на том уровне, а такое тоже бывает на удивление, что даже на юай-ные компоненты топ-менеджеры тоже могут давать задачки.
23:58 Вот, это еще плюс идет баллы.
24:00 И отдельно это срок, а когда команде это нужно?
24:04 Потому что команды-продуктовые живут как раз по спринтам и по релизным циклам, и мы сразу уточняем, когда и сколько времени у нас есть для вас.
24:12 И за счет этого на самом деле очень хорошо выстраивается эта структура иерархически, потому что никому не надо одновременно, как показывает практика.
24:21 Они, конечно, все скажут, что им надо завтра, но когда ты начинаешь узнавать четкие даты релиза, цикла, ты понимаешь, что нет, у них есть время, и они прекрасно все успеют, так же, как и мы.
24:32 И за счет этой конбаны мы начали жить.
24:35 Поэтому СЛА нам стал очень удобен как метрика.
24:39 Потом я пошла в историю с багами, я ее не отпустила с УАИ-на-багами и стала следить за ЮА-нами-багами продуктов.
24:47 Понимая, что теперь, когда продукт работает на дизайн-системе, скорее всего косяки ЮА-иа это наши косяки, наши ошибки - за которыми мы могли не уследить.
25:00 И я стала следить за ними: считать, насколько вообще много багов на проме, насколько много багов у ребят на каких-то тестовых стендах, УАИ-нах, которые не откладывают.
25:10 И здесь пошла история о том, что лучше надо выстроить процесс, еще и взаимодействие с тестированием, чтобы они отслеживали, в том числе, УАЙ, и помогали нам, потому что мы все же не можем быть глазами всего продукта - а если их много, то это вообще нереально.
25:27 И здесь мы пошли немножко даже в процессную историю: я стала закладывать такие небольшие зерна знаний в аналитиков всех системных, потому что мы все пишем требования, мы описываем требования обязательно к интерфейсу, мы берем за основу дизайн.
25:42 И я такая: почему бы нам на уровне аналитики не начать сразу что-то писать про дизайн-систему.
25:48 А, помочь разработчику, Б, а потом еще и помочь тестировщику, который будет проверять, тестировать и поймет.
25:54 А тестировщику мы стали как раз закладывать историю про ЮАИ-ные баги и любой тестировщик сейчас знает, что если что-то прям с ЮАИ не так, они придут к нам.
26:06 Мы либо узнаем о своих ошибках, хотя сейчас допрома редко доходит, либо мы узнаем, ну, например, о кастами.
26:15 Вот такой вот интерес эффект получился исходя из этого.
26:19 Ну, а кастом как-то замеряете?
26:21 Либо как раз стало мало, мы пошли в историю, а как нам еще померить кастом?
26:27 Но пошли мы в эту историю, когда стали считать количество продуктов, которые подключены к нашей дизайн-системе.
26:33 Сначала мы считали количество команд, потому что продукт один раз, а потом мы поняли, что это можно продать.
26:40 Я это продала еще в парочку продуктов.
26:43 И поняла, что можно еще продать - в другие продукты.
26:46 И тут появилась метрика - как раз количества продуктов, которые работают с данной системой.
26:50 Она растет медленно, но растет и как прикольный показатель - дополнительно тоже крутая.
26:56 А в части кастома мы начали делать свои инструменты.
27:00 Это вот как раз к возврату, к истории - почему мы продукт, а не только как сервисная команда?
27:07 Когда мы столкнулись с историей кастома, хотя процессы написаны, ты всеми обсуждаешь, обговариваешь всегда всю эту историю, ну, все бывает.
27:16 Человеческие фактор, и не всегда это даже сделано специально, а просто потому, что.
27:21 И любимое сделать деточ.
27:22 Да, но это база, это вообще мне кажется, не обсуждаемо.
27:27 Просто потому, что ну захотелось.
27:29 И на ревью, даже с учетом, что ты ревьюешься со стороны ДСК, ты в моменте такого можешь не заметить.
27:37 Стали думать, как вообще от этой штуки уйти, как это померить, и как это сделать еще и не руками?
27:43 И тут появился наш один из инструментов - это плагин.
27:47 Плагин, который прям внедряется в нашем случае в пиксо.
27:51 И он начинает анализировать макет - анализировать макет на использование компонентов дизайн-системы.
27:57 Он их может посчитать количественно, что нам тоже очень удобно - как отдельная метрика - потом под эффективность, под используемость дизайн-системы.
28:07 В нее заложено как раз в основу количества компонентов.
28:10 А вторая история - он как раз показывает кастомные компоненты.
28:13 Он их прям подсвечивает, обводит на макете, и ты прям прокликиваешься, он прям наводится на конкретный компонент.
28:21 Интересно, что кастомными компонентами он считает два вида.
28:26 Первые - это как раз сами непосредственно кастомные компоненты, которые были раздетачены, разрушены, собраны вообще самостоятельно каким-то образом.
28:34 А как он, куда он смотрит?
28:37 Ну а если не похожи на слое?
28:41 Типа он как бы вычисляет вариации несколько вариаций, поэтому вроде пока проблем не было.
28:47 Но есть интересный факт.
28:49 Мы сначала думали, что это наш косяк плагина, а потом поняли, что это не баг офичар.
28:54 Он действительно смотрел на компоненты, но часть компонентов дизайн-системы нам подсвечивал всегда кастом.
29:00 Мы сидели, разбирались - наверное, дня два - чего не так, и поняли, что если ты вдруг не апдейт дизайн-систему, не поднял до последней версии, этот плагин - считает компонент старый - тоже кастомным.
29:14 И тут мы тоже нашли для себя плюс.
29:18 Вот, пожалуйста, вам хороший поинт: что типа вы не апдейтите дизайн-систему в этом макете, в этом продукте и живете не на актуальной версии.
29:26 Еще появился такой небольшой бонус для нас: в коде тоже пошли в интересную историю, код сложнее.
29:33 Мы еще не дошли до полной автоматизации, к сожалению, но тоже есть в планах начать примерно такую же историю считать: такими линчарами, небольшими, их называю, жучками, которые внедрятся в код, но все будет супербезопасно и официально.
29:47 Но стали делать инструменты, которые работают как деф-толзы в браузере.
29:53 То есть, мы можем навестись на верстку страниц и посмотреть, что там скрыто.
29:56 Если в вебе все хорошо, там мы изначально можем увидеть уникальный класс названия компонента и понять, что это дизайн-система или не дизайн-система, и это посчитать спокойно, скриптом, то в мобилке с этим сложнее.
30:11 И в мобилке мы стали делать свой инструмент, который - аналог деф-тулза, он тоже делает верстку экрана, он подсвечивает все компоненты дизайн-системе на мобильном экране - такой яркой-зеленой ядовитой обводкой.
30:26 Подписывает их, прописывает отступы - что помогает тестировщикам, еще потом верстку проверить дополнительно.
30:32 И может посчитать их количество.
30:34 Плюс, очень классно отлавливается кастом.
30:36 Если экран мы видим, что не ядовито зеленого цвета, мы понимаем, что это не на дизайн-системе собрано.
30:42 И ребята об этом все знают и.
30:46 Аля застенчиво улыбнулась.
30:49 Видимо, немножко осуждаем.
30:53 Вы вот эти циферки собираетесь?
30:55 как-то отчитываетесь за ним?
30:56 Да, я каждый квартал - это прям несу как в цели.
31:01 У меня это есть в моих целях.
31:02 Это мой, ну, не Кипяй, мы живем в ОКР, вот, но у меня есть, как раз, метрические результаты, команды, что мы по СЛА выполняли срок, мы отвечали вовремя, у нас есть вот такое количество продуктов, у нас есть покрытие тестами наших компонентов.
31:19 Это тоже отдельная метрика качества у нас как дизайн-системы.
31:21 мы, даже это считаем, свои тесты, которые мы перепроверяем.
31:26 Считаем количество кастома, считаем используемость компонентов, и все это отдается туда.
31:33 А используемость - я еще дополнительно раз в квартал возвращаюсь к пересчету денежной экономии и временной экономии, потому что, как раз на основе уже реальных данных, собранных с макетов и продуктов я могу возвращаться - вот к этому расчету, с которого я и начинала продавать всю эту историю.
31:51 А что лучше в результате получается?
31:53 Меньше кастама или количество найденного кастама?
31:57 Ну, типа, это такая история: типа меньше кастама, значит, все отлично, у нас все работает, и мы молодцы.
32:03 И все типа по ДСК сделано.
32:04 Либо мы такие молодцы, что мы отсмотрели все макеты и нашли 500 тысяч кастома.
32:10 Количество кастома нам на самом деле ничего не даст.
32:13 наша целевая картина - это все же, чтобы кастома не было.
32:18 Не было просто потому, что иначе мы потом можем получить баги, которые мы не ожидали.
32:24 Мы апдейтнули дизайн-систему и перекрасилась в половина интерфейса, она стала зеброй.
32:29 Это мой любимый пример - ребят со сбыла: когда они как раз делали темную тему, активно себе внедряли, у них их сбол стал зеро.
32:37 И они это показывали - ну а что делать?
32:40 Примерно такая же история тут и у нас была: когда мы токены, но это у нас получилось внутри, обновляли токены.
32:46 Тоже ты получаешь зебру в момент, когда ты не ожидал, что ты ее получишь.
32:51 Потому что вроде все, же хорошо все же на компонентах работают, все занятиями.
32:56 А кастом ломает тебе реально продукт и ломает его неожиданно для пользователя.
33:00 Мне кажется, можно было плагин не делать для этого.
33:03 А знаешь, просто врубаешь им принудительно другую цветовую тему и такой, а?
33:09 можно, но это было бы прям жестоко, и нас бы потом, мне кажется, не было.
33:15 А вот как внутри команды вообще происходит взаимодействие?
33:19 Потому что, знаешь, такое бывает, когда дизайнерам все равно на разрабах, а разрабам все равно на дизайнеров, и всем все равно, на тестировщиков.
33:27 И как будто бы здесь делится зона ответственности - то есть мы макет нарисовали, а чего вы там дальше делаете, нас не волнует.
33:34 Или там разработчики.
33:35 Мы это все сделали - вот что там, дизайнер придумал - непонятно.
33:39 Здесь же очень важно синхронизировать дизайнера с технической точки зрения, и разработчика с визуальной точки зрения, потому что и там, и там, по моему опыту и наблюдениям, бывают просадки, потому что дизайнер делает исполняет какую-то ерунду, не опираясь на техническую реализацию, а разраб сделал по дизайну, но ты реально смотришь, а там не по дизайну.
34:03 А он тебе говорит: ну это же по дизайну: отступы, кегли, там, ланькейт, какой-нибудь, неважно.
34:10 Мы тоже с этим поработали, на самом деле, активно, и это одна, наверное, из проблем, которую решила в целом создание вот этой продуктовой команды, как я ее называю.
34:21 Я активно продвигаю теперь, получается.
34:24 Во-первых, в моей команде, так как я уже сказала, у нас всех по одному, я изначально, ребят, приглашаю в нее, говорила, что вы будете как лиц своего направления.
34:36 Вот ты один, и ты ответственен за то, что ты делаешь.
34:40 Но внутри дизайн-системы.
34:42 И это первый, наверное, шаг - то есть, в целом нам важна ответственность, брать на себя ответственность вместе.
34:47 Это мне кажется, в принципе, очень частая проблема.
34:50 И вот это первое, из чего я в целом ребят приглашаю сюда работать, потому что не все на такое готовы, не все готовы с этим сидеть и такой скрупулезной работой, на самом деле, заниматься.
35:00 Это не какая-то творческая задача, и не фичу разработать.
35:04 Это что-то такое - прям - закопаться.
35:08 И в этом надо прям хотеть копаться.
35:10 Я собрала, во-первых, таких людей - вот по, наверное, мироощущению, которые - по майндсе определенному.
35:15 Которые готовы были с этим сидеть и которые готовы были брать на себя ответственность, за
35:21 красоту и качество - то, что они делают.
35:25 Но это, конечно, мало что набрать людей.
35:27 Второе, во что мы пошли, это то, что, например, дизайнер со стороны, когда он смотрит и общается с разработкой, он как минимум знает и умеет работать всеми инструментами тестирования, которое доступно для ручного тестирования.
35:42 Он может зайти в тел-тузы, он может зайти и воспользоваться всеми нашими плагинами, он может развернуть проект локально.
35:48 Это каждый дизайнер может.
35:52 Банально для того, чтобы ему быть уверенным, что все хорошо, что его разработчик понял правильно в этот момент.
36:01 Мы ввели: у нас есть такой процесс - он такой: внутри команды - мы так решили: сами решили: что будем любую доработку, любое изменение дизайна дизайнер нам просто презентует всегда.
36:14 Вот у нас это сейчас просто как база - мы там после дейлика остаемся - типа 5 минут: ребят, я там внес изменения, давайте посмотрим, есть ли вам окей, мы это возьмем в разработку - я там сам заведу задачки, вы будете работать.
36:28 Это на самом деле решило огромный скоб проблем в части взаимодействия коммуникации дизайнера и разработки.
36:33 Вот эти 5 минут после дейка ничего не стоит.
36:37 Вообще ничего не стоит, но решают огромную дыру коммуникаций, потому что дизайнер сел и сам показал разработчикам вот этот, мне кажется, еще шаг, что он сам показал: у разработчиков сразу лояльность.
36:50 Ты выстраиваешь это отношение в команде, взаимодействие, эти доверительные отношения.
36:55 Разработчики могут накидать ему обратной связи.
36:58 Они могут натоксичить немножко - почему нет?
37:01 Ну, вот они такие, построение такое.
37:03 И дизайнеры воспримет нормально, он их уточнит - типа что не так, а покажи.
37:08 И в этот момент разработчик начнет показывать.
37:10 Он тоже понимает, что он работает с дизайнером.
37:13 И здесь вступает вторая часть.
37:15 Я научила изначально разработчиков смотреть на дизайн как дизайнер с насмотренностью, поэтому, когда я ребята в целом искала, собирала, я всегда мой любимый вопрос - типа: какое тебе приложение нравится и что тебе в нем нравится?
37:29 Кажется, банальный вопрос, но очень о многом говорит: а насколько вообще человек за этим следит и обращает внимание, а что есть такого в приложениях.
37:37 Мы любим - просто пример Ютуб, где кучу багов юайных.
37:40 Он лежит мне до сих пор в сердечке, но ты не можешь не пользоваться Ютубом.
37:44 Дальше я попросила разработчиков, если они хотят что-то объяснить дизайнеру, попробовать говорить на его языке - это значит говорить на визуальном языке: показать примеры, показать, как что и где работает.
37:56 Потому что код он не воспримет, ну, если вдруг в прошлом не разработчик, а такие у нас тоже есть очень часто примеры.
38:03 А прям показать на каком-то разработанном примере - потому что на самом деле довольно быстро накидать условную формочку - показать.
38:10 На других дизайн-системах открытых, которые есть, опен-сорсные, где есть похожие инструменты и решения.
38:17 И вот здесь мы очень быстро нашли с ребятами общий язык, потому что с двух сторон шла это коммуникация и взаимодействие: потому что каждый знал, а как лучше показать другому, как лучше доказать что-то другому, показать, что он неправ?
38:32 Объяснить технические проблемы и сложности?
38:35 Прям вот как для ребенка.
38:36 То есть, у нас до такой степени, что разработчик может спокойно сесть и ему объяснить: типа, а почему вот эта функция у него сейчас в моменте не сработает, и почему ховер, он кастомный, здесь не сможет нормально сделать, и как упадет оптимизация отрисовки страницы.
38:51 Но он ему объяснить так, что и дизайнер поймет, он такой: а окей, давайте переделаем вот так.
38:56 И самое интересное, что дизайнер это поймет в моменте.
38:59 Он поймет сразу, что ему надо исправить, а не будет ходить часами и думать, а типа четко-то, вот чего именно технически он не может, и какое мне решение придумать.
39:08 Ну да, когда тебе сухо ответили, что так работать не будет, что это нет, и всегда ходишь, догадываешься точно.
39:12 А еще интересный факт - у нас есть великолепный тестировщик, и она тестирует не только код, но и дизайн.
39:20 Мы решили так: внутри договорились, что она сама захотела, инициатива - вот почему бы и нет, но мы поняли, что это очень крутой процесс.
39:28 Мне кажется, я не слышала такого, чтобы именно тестировщики, как квеей инженеры, тестировали за дизайнерами макеты.
39:36 Вообще нет, ну, это что-то Анреал.
39:39 А что за этим кроется?
39:40 Она единственная, у кого есть доступ на редактирование в дизайн-систему, помимо непосредственно дизайнера дизайн-системы.
39:48 И она берет и каждый компонент вытаскивает, и начинает ломать его.
39:53 Прям как вот в коде мы проверяем корнер-кейс - она начинает его растягивать, писать, длинные текста, включать различные комбинации свойств, которые в идеале могут не работать вместе.
40:05 Заходит тестировщик в бар, забегает тестировщик в бар, залезает в окно тестировщик губар.
40:11 Реально, так и есть.
40:13 И это очень сильно помогло сделать в дизайне качественную ДС-ку.
40:17 И дизайнер оказался-то неправ, ему это прикольно.
40:20 Потому что обычно дизайн-системами работают и так дотошные люди.
40:23 То есть, они вот этот пиксель перфект любят докопаться до мелочей, потому что им надо сделать что-то качественное, хорошее, что можно как раз переиспользовать.
40:33 Наш тестировщик здесь прям со всех сторон окружила.
40:37 Всех и все ее слушают.
40:39 Она у нас главная - вообще в команде - на самом деле: ее слушают все вообще.
40:43 Процесс закрутился так, что мы начали выпускать какие-то крутые качественные компоненты, они уже изначально протестированы, багов уже не находят.
40:53 На проме вообще про ЮАИ-Н-баги речь сейчас не идет.
40:56 Я думаю, что это довольно крутой результат, к которому мы пришли.
41:00 Слушай, а есть какие-то еще инструменты, ритуалы, не знаю, чтобы вам синхронизировать?
41:06 Какие-то ревью - совместные синки?
41:09 Да, у нас есть совместные ревью.
41:11 Они тоже проходят в формате, что, например, разработчик, когда сделал компонент, мы обычно такое делаем после дейлика - сразу бронируем время.
41:22 Не обязательно пять.
41:23 Это бывает, что мы бронируем время, если там что-то сложное, какая-нибудь история.
41:25 Нам надо прям сесть, посмотреть, пообсуждать.
41:28 А мы садимся, и в этот момент, например, уже разработчик презентует разработанный компонент.
41:33 Он прям показывает, протыкивает, тебе показывает все отступы и так далее.
41:37 То есть, да, этап тестирования есть.
41:40 Понимаем, что там вроде должно быть все окей.
41:42 Но вот эта история о том, что ты все равно с двух сторон презентуешь и показываешь - не только дизайнер показывает разработчику, но и разработчик заходит со своей стороны на встречу и показывает: смотри, я сделала, все окей, тебе все нравится.
41:56 Были моменты, когда: ну, там дизайнер - моменти такой: ой, нет, давай вот тут скругление - поменяем, и все это окей, воспринимает.
42:02 Это не воспринимается, что ой, накидали сверху, опять тратить время, нет, они такие: а ну окей, он же, типа, эксперт в этом, он, значит, прав, он будет решать.
42:12 И вот у нас на этом уровне: что каждый уважает друг друга, его экспертность - именно, что вот он ответственен за свое направление, он в этом шарит.
42:22 Значит, я буду, как бы, с ним, в общем, соглашаться, но при этом никто не боится оспаривать решения и предлагать какие-то прикольные идеи.
42:35 Наверное, здесь хотелось еще очень сильно затронуть тему про генуй, нейронки, которая облегчает рутину в жизни, в работе, плюс есть курс определенный на оптимизацию каких-то процессов.
42:53 И мне самому эта тема довольно близка и интересна, потому что человеческий труд и ресурс можно высвободить просто за счет нейронок.
43:04 Вот хотелось бы здесь проговорить про ген УА.
43:06 Я, наверное, чуть контекста дам, что это такое - для наших слушателей, кто не знает, гену это по сути сгенерированные нейросетью те компоненты дизайн-симы и те экраны из этих компонентов дизайн-системы, где дизайнеру останется, наверное, только по ревьють, что это все правильно работает.
43:25 Вы вообще как в своей команде используете ген ЮА?
43:29 Я это называю и головного мозга.
43:31 Мне кажется, сейчас в целом на эту историю она очень трендовая, и это прикольно, почему бы и нет, надо не отставать - от этой всей истории.
43:40 Но я тут сделаю, наверное, небольшой ремарку и контекст - как мы вообще в эту историю пошли.
43:46 Очевидно, что мы все работаем пошли, точно пошли, и сейчас мне кажется - нельзя не идти.
43:52 Не просто потому, что заставляют, а просто потому, что, иначе, ты это станешь - от эволюции - так уж громко скажу, но это факт.
43:59 У нас в этом плане очень прикольный был посыл изначально от нашего руководства.
44:04 Мне он просто очень близок, типа к душе, руководителю непосредственно.
44:09 Он нам сказал: что а давайте начнем рассказывать, как вы применять и для себя в жизни.
44:14 Потому что это в целом, мне кажется, первое, с чем мы начинаем, и для каких-то своих личных рутинных вот задач, которые ты хочешь как-то облегчить и упростить.
44:23 И здесь очень прикольно оказалось.
44:26 Я вот всем рассказываю, друзьям, у меня в одной университе есть великолепный чат, где просто все мои болячки собраны.
44:33 Это мой личный врач.
44:35 Он все проверяет за мной.
44:37 Но это не значит, что я не хожу к врачу, я хожу, но вот это второе мнение - оно теперь у меня есть.
44:43 Вот лучше не гуглить, как оказалось.
44:45 Потому что когда ты гуглишь, тебе все, ты умрешь.
44:48 А если ты общаешься с СИИ, ты понимаешь, что ты будешь жить, он тебя поддерживает, он тебя морально поддерживает.
44:55 Ты такой - да, это вообще мой лучший друг тебе.
44:57 И вот это прикольная история.
44:59 У нас есть кейс: что коллега написал игру с помощью Е, чтобы потестить.
45:04 Вместе с ребенком компьютерную игру написали: прям вот.
45:07 Просто им было интересно, насколько ИИ умен.
45:10 И получилась полноценная игра, в которой он сгенерировал дизайн, в которой он написал код, и теперь эта игра запускается спокойно, у него на компьютере, и они с ребенком играют.
45:19 Кайфово, я тоже вайп-кодил.
45:21 У меня есть два телеграм-бота.
45:23 Вот, и это, мне кажется, очень крутой порог входа.
45:26 Он снизился в целом во всю ту историю, которую ты не умел.
45:30 И вот это понимая, мы стали думать: а чего для работы это полезно может быть.
45:35 И стали думать изначально за счет этого контекста: не как ее всунуть, чтобы всунуть, эту ИИшку, а как ее применить, чтобы она действительно принесла пользу и немножко оптимизировала нашу работу, ускорила, упростила нашу жизнь.
45:49 И мы начали с простого, мы пошли оттестирование на удивление, но нам показалось, что вот там как раз то место, где можно начать.
45:58 С учетом того, что у нас один тестировщик: нам сложно успевать
46:04 протестировать быстро все платформы, если вдруг задача есть - вообще везде - и на веб, и на Йос, и на андроид по компонентам.
46:12 Ей надо это быстро, ей надо еще это соблюсти
46:16 такие административные вещи, завести тестовую модель, прокликать, сделать эти тестовые прогоны, то есть куча таких условностей, шагов в рутинах, которые надо делать.
46:25 И она стала тестить ИИшку, отдавать ей генерацию непосредственно вот этих тестовых кейсов и тестовой модели.
46:32 То есть она отдавала исходный код компонентов, благо, там нет никаких нарушений, персональных данных, ничего, он супер абстрактный.
46:40 Такое можно отдавать.
46:41 Очень важно сказать, что отдавая что-то вы особенно на работе, имейте в виду, что эти данные обрабатываются и вся конфиденциальная информация, перст данная - они тоже обрабатываются, имейте в виду.
46:54 Да, поэтому с этим надо быть аккуратным.
46:56 Мы изначально зная, так как нам уже внедрили опыт, что потестите в жизни, а потом в работе, мы уже понимали, как с этим жить и работать.
47:05 Поэтому стали супераккуратно отдавать исходный код - но тот, который можно было отдавать, и генерировать тест-кейсы для проверки наших компонентов.
47:14 То есть, она убрала с себя: вот эту рутину, на которую уходит много времени, просто потому что это надо написать.
47:21 Вот именно эта писанина она теперь ушла на сторону.
47:25 Второй шаг: мы пошли в автоматизацию.
47:28 У меня тестировщик изначально ручной вообще с тажером пришла ко мне.
47:32 Соответственно, код писать только для себя, только для универа - и никак не связанный по непосредственной работе, задачам, и не про какие автотесты она и не слышала - изначально слышала, но не писала.
47:47 И тут стал для нее небольшим наставником - вот этим первым шагом - вот этот вайб-кодинг, но в правильном его понимании, как раз, он ей помог накидать базу автотестов, которые дальше наши разработчики чуть привели, и у нас появилась база автотестов.
48:04 У нас стали наши компоненты еще прогонятся, автоматически проверятся.
48:08 Плюс она изучила, как пишутся автотесты, стала их писать сама, даучивать здесь сиишку, чтобы она генерила дальше.
48:16 Но это все равно история про вот эту полуручную, да, то есть мы тут не говорим про какую-то автоматическую агентизацию, о чем сейчас тоже говорят, что это уже агентная история.
48:26 Представь, что ты агента заряжаешь, он пошел за тебя все по-другому.
48:29 Я думаю, что мы к этому как раз и придем.
48:31 Ближайшие 100% в будущее нам нужно чуть-чуть времени, чтобы к этому прийти.
48:36 Но это точно один из наших шагов.
48:38 Следующий - в принципе, мне кажется, любой сейчас команды, продукты, шаг.
48:42 Дальше мы стали думать: о что бы нет, что бы ни генерировать?
48:47 А может быть, интерфейсы?
48:49 Конечно, эта мысль возникает в моменте, но интересный факт - она не возникла в части генерации ДС-ки.
48:57 Мы пошли думать сразу в части генерации интерфейсов продуктов.
49:02 И как мы стали думать?
49:04 Базовые нейросети строятся в любом случае на большом объеме данных, на которых она обучается и принимает на вход.
49:10 Тут прошлое универа очень сильно мне помогло на самом деле в этой теории - просто потому что это все проходилось.
49:17 И мы поняли, что наша дизайн-система: код компонентов, требования, дизайн, тесты, различные продуктовые макеты хорошо собранные на дизайн-системе, а благо, мы теперь можем проверить за счет различных плагинов.
49:31 Могут стать той базой данных для ИИшки, чтобы она начинала генерировать интерфейсы на основе нашей дизайн-системы.
49:39 И начали тестить просто через обычные чаты, контекст.
49:43 Вкидывали много контекста: насколько она выдавала вообще результат, насколько она эголюционировала.
49:48 Она не захлебывается от большого количества контекстов?
49:51 Захлебывается, но это тоже исправимо.
49:53 Но исправимо, когда ты это делаешь не локально, а потом уже появляются у тебя мощность.
49:58 Нам было важно потестить, хотя бы в ту ли сторону она думает.
50:01 То есть, реально ли это?
50:03 Можно ли в это пойти?
50:04 Потому что мы момент не понимали.
50:06 Ну, сомнения, еще понимаете.
50:08 Они до сих пор есть, это нормально.
50:10 Потому что все это просто активно развивается.
50:13 И там сегодня мы сомневаемся, через две недели - там выпустили новый апдейт, и мы уже не сомневаемся, она уже сама реально что-то делает.
50:20 И начали понимать, что Ишка понимает.
50:23 И понимает, если ты задаешь ей правильные промты, вкидываешь много контекста, который обработан, и как бы ссылаешься на него в своем промпте - тоже на контекст.
50:33 То есть ставишь четкие задачи.
50:34 Вот этот промпт-инженеринг - вообще мне кажется, отдельная тема: как правильно общаться с ИИшкой.
50:39 Вот, это прям всем важно, мне кажется, тоже изучить и понимать.
50:43 Иишка стала давать прикольные результаты, но здесь мы на данный момент уперлись - в то, что как раз эта ресурсность - типа - где это развернуть, а как это запустить.
50:55 Ну, просто потому что находясь в компании, это в любой компании, это в принципе там сложнее, что нужно теперь выбить ресурсы под все это, чтобы развернуть.
51:05 Но интересное произошла ситуация, к нам пришли коллеги, которые не мы одни, очевидно, этим занимались.
51:12 Это прикольно, что все думают в эту сторону.
51:16 И изобретать велосипед тоже никогда не хочется.
51:18 В этом тоже как будто нет смысла.
51:20 Пришли коллеги, которые начали не со стороны кода, а начали со стороны генерации, получается, интерфейсов в макетах в Пиксо - тоже пытаться делать своего - ну, типа агента - как раз через Ишку, и пришли с предложением попробовать на нашей ДС-ске тоже потестить всю эту историю, что мы им как раз
51:41 Датасет свой отдадим, и они хотят потестить, а насколько их ИИшка адаптируется под то, что собирать, например, уже на другой дизайн-системе.
51:49 Потому что они тестили над своей, им стало интересно, можно ли это как раз масштабировать.
51:53 А это логичный шаг - сразу это масштабировать.
51:55 Зачем мы тут будем тратить время, если ребята уже к чему-то пришли.
52:00 И мы как раз на этапе сейчас такой рабочей группы с ребятами придумываем, как нам это докрутить.
52:07 Ну, вот уже я слежу за фигмой, как она развивается с точки зрения нейронок, они же запустили мейк, ты можешь туда просто библиотеку подрубить, и он тебе на компонентах этой библиотеки сделает.
52:23 обновили МСП-сервер, ты можешь к ней подрубаться - прям в файл по МСП-серверу, и нейронка уже может быть внешне, какая-то нейронка может таскать компоненты прямо оттуда.
52:34 Да, я даже тестила, как раз ИИшку в фигме просто по генерации экрана.
52:40 И если я стала обращать внимание, что она изначально генерирует эти экраны, интерфейсов на компонентах, она это уже сразу собирает.
52:48 И за счет этого можно сразу, как минимум ЙА-кит уже вытащить готовый.
52:52 То есть это прям очень крутая тема.
52:55 Есть внешняя Ишка, которое дизайн-система на самом деле уже генерит.
52:59 Но она код генерит не дизайнерскую часть, а вот кодовую часть - но она вот генерит этот УА-кит разработанный тебе прям под твой продукт, под твой запрос.
53:08 Мне кажется, это прям крутой вообще будущее наше.
53:11 Ну а вот если порассуждать немножко о будущем - у тебя семь человек, дизайнер и разраб есть.
53:18 Вы навернете, предположим, все работает, негаллюционирует, все гениец.
53:23 Что будет с дизайнером-разработчиком?
53:26 Адаптируется, поменяется сам смысл немножко их работы, как профессии: они станут не тем дизайнером, который непосредственно работает руками, а станут, я бы назвала это, оператором ИИшки, чтобы направлять и как раз собирать через нее под наши потребности.
53:45 Просто его скорость увеличится в разы за счет этого.
53:50 И это не значит, что человек пропадет.
53:52 Он не пропадет, он просто адаптируется к новому условиям.
53:55 И тут мне кажется, важно подсвечивать, что надо адаптироваться к новым условиям.
53:59 Он просто превратится в промпт инженера, который будет помогать и направлять ИИшку в нужную сторону, потому что Иишку здесь важно рассматривать как своего помощника, коллегу, например, Джуна.
54:14 А ты станешь в этом во всем ледом, которого будет команда вот таких агентиков, которые будут тебе что-то делать.
54:20 Мы, кстати, на подкасте говорили с Димой Малаховым.
54:23 Он очень классный тезис сказал: что если раньше
54:27 без ИИшки посмотреть: вот ты как менеджер, у тебя есть подчиненные, сотрудники твои, и вот это как раз-таки и была твоя ИИшка, которая делала все за тебя, и там важно менеджеру объяснить всем своим агентикам, как делать задачу.
54:45 Мы сейчас стали жить немножко в другой реальности, когда у каждого агентика появился свой персональный помощ.
54:52 И им теперь важно научиться думать как менеджер, чтобы объяснять задачу нейросетки.
55:00 Это очень важно в целом эту задачу донести.
55:03 Я еще привожу пример: когда в целом где-нибудь рассказываю, как мы там и используем, и затрагиваем эту тему, что ИИшку надо представлять как нового сотрудника, а ты его бади.
55:16 И вот твоя задача: чтобы он что-то начал делать - что тебе нужно - обучи его.
55:21 Погрузи, обучи, дай контекста, сгрузи в него всю инфу, которая у тебя есть, и он будет делать ровно то, что ты захочешь.
55:29 А так как это все же не человек, а робот, он еще это будет делать практически без ошибок.
55:36 И, наверное, последний вопрос: что бы ты посоветовала дизайнерам, которые хотят строить или поддерживать свою дизайн-систему?
55:42 Первое, это точно не бояться, а второе - посмотреть на нее как продукт - и как продукт, который может стать эффективным, который может экономить деньги и время.
55:55 И когда ты смотришь на это как продукт, ты начинаешь по-другому работать над ним и понимаешь, как это продать, доказать, что это нужно всем.
56:05 И еще по-другому использовать - и, мне кажется, относиться в целом, когда работаешь, развиваешь его.
56:12 Друзья, сегодня у меня в гостях была Аль Чугунова, руководитель команды Дзайин-системы во внутренних продуктах Сбера.
56:17 Аль, спасибо тебе большое.
56:21 Было клево пообщаться.
56:24 Друзья, это был подкаст Дизайн Тусовка и ее бессменный ведущий Жень Шевцов.
56:28 Подписывайся на телеграм-канал Манкендизайнер.
56:31 Ставь лайки этому подкасту в Яндекс.Музыке и жми звездочки в Эпл подкасты и слушай нас, когда едешь на работу или ложишься спать.
56:41 Партнер, выпуска ПАО Сбербанк.
Комментарии
Войдите, чтобы оставить комментарий.