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