Привет! Ты слушаешь первый выпуск подкаста «Ти самурай» и я его ведущий Илья Бездилев. Как выяснилось, самое сложное при записи подкаста — это говорить без выражения. Потому что, когда говоришь с выражением, начинаешь звучать как робот. Поэтому для первого выпуска подкаста я пошел на небольшой лайфхак.
Я пришел в гости на эфир в инстаграме к дизайнеру Марату Дестербекову. Мы поговорили на разные темы, в основном про дизайн и про то, как строится работа в командах в компаниях Google и Amazon, где я работал. Формат интервью помог мне быть очень непринужденным и расслабленным. И вы это заметите по тому, с какой скоростью я разговариваю. Поэтому это не тот подкаст, который вы будете слушать на скорость 1,5х или 2х.
Ставьте воспроизведение в нормальном режиме или можете даже немножко замедлить. Не буду вас больше задерживать. Одевайте наушники, идите на прогулку, начинайте мыть посуду, садитесь в машину, чем вы там занимаетесь. И надеюсь, этот эпизод будет вам полезен.
Первое, о чем я тебя спрошу, это, во-первых, представься для тех, кто тебя видит впервые, объясни, кто ты, где ты работаешь и почему, в принципе, мы тебя позвали, почему мы тебя слушаем. Меня зовут Илья Безделев, я работаю... Сейчас в Гугле в Google Cloud. на позиции продакт-менеджера. Гугли же, работаю почти год. До этого я работал 5 лет в Амазонию. Я пришел на позицию синьор продакт-менеджера, потом пару лет руководил командой разработки, потом обратно шел в продакт.
запустил продукт AWS Chatbot но с нуля от идеи. Собственно, я руководил командой разработки, и мы с этой командой запустили новый продукт. Потом я выиграл, ушел в Google. До этого получил MBA в Америке в бизнес-школе Worden. До этого еще 8 лет работал в компании DHL, в основном на позиции, связанные с анализом данных. очень много пережал, разжил в петлю.
В общем, у меня такая жизнь не очень линейная. По образованию я программист. Я работал программистом, работал фрилансером, была своя компания, работал на других людей. Но это было все очень давно, еще когда в универе учился. Я слушал, кстати, подкаст Уехавший и там ты рассказывал, что ты
учился на программиста, связанного именно с экономикой. Специальность называлась «Перекладная информатика в экономике». Чтобы ты понимал, это был 2000 год. Большинство людей еще не знало про интернет или что-то про него слышало. Это было что-то такое далекое. Это как сейчас, наверное,
какой-нибудь искусственный интеллект или виртуальная реальность или AR. То есть люди знают, что это где-то существует, но они это не понимают большинство людей. Так же было с интернетом в те годы. Вот эта специальность, она была... построен на базе математического факультета. Все люди, которые там преподавали, это были такие профессоры старой закалки, которые там
разбираться дискретно в математике, в статистике, в теории вероятностей. И поэтому мы учили нас по большей части на самом деле математике, немножко программированию, немножко экономики. спрашивали по поводу того, на кого бы ты советовал сейчас, вот если бы ты сейчас начинал и хотел бы прийти вот туда, где ты сейчас находишься. Куда ты бы посоветовал поступить учиться, либо советовал бы ты поступать в университет, либо ты советовал именно начинать с практики? твоем
Да, такой сложный вопрос, на самом деле, я часто получаю его от родителей, подростков, например, такие приходят вопросы. И тут дети, назовем подростков, дети, они еще не знают, чего они хотят. В моем случае у меня был компьютер, я занимался веб-дизайном в свободное время, программировал. Я знал, что я одержим технологиями, я хочу пойти учиться технологии. И этот факультет был один из двух факультетов в городе, который ты предлагал. Мне здесь понравилось, я туда пошел учиться.
Сейчас у многих молодых ребят нет стремления, нет понимания, что они хотят делать. Я считаю, что важно идти туда, где-либо тебя прет. компьютерами, да, программировать, если ты уже занимаешься программированием. Иди туда, где тебя, думаю, научат еще лучше. И если ты не знаешь, чего делать, с этим, мне кажется, сложнее, потому что ты можешь пойти учиться на то же самое программирование, а потом в этом полностью разочароваться.
и у тебя будет специальность, которая дала тебе кучу хардскилов, которые ты не умеешь применять или не хочешь применять, от которых ты выгораешь и так далее. Это на самом деле очень сложный вопрос. Я знаю, что в Америке, кто учится именно ребятам 18 лет, которые приходят на учебу, здесь система немножко другая. Здесь ты поступаешь в колледж, и ты не выбираешь специальность заранее. Ты пару лет учишься всему подряд, то есть там изучаешь психологию, ой, не психологию.
в исходе. Вилософию, историю, математику, еще что-то. То есть полный набор общих предметов. После чего ты начинаешь потихонечку брать дополнительные курсы, которые ты уже выбираешь там из каталога, и ты начинаешь специализироваться. Условно говоря, где-то годом 20,
После того, как ты уже породит, побыл в университете. Тебя же складывается какое-то впечатление. Ты уже что-то попробовал. Ты уже можешь более правильно выбрать профессию. Я думаю, все равно можно ошибиться, конечно, даже при таком подходе. но прием ошибиться значительно сложнее потому что ты уже все таки немножко знаешь
что ты делаешь. Тем, ребятам, у кого есть возможность поехать учиться в заграничную систему, ну, я бы, скажем, советовал, наверное, сделать это, если у вас есть возможность. Если есть, не знаю, если вы прошли через этот процесс, если вы поступили, если есть деньги, если получили какой-то грант, это очень крутая система. А если выбирать приходится
в своем родном городе, тут, наверное, два подхода. То есть, либо тебя точно прет от чего-то, и ты идешь туда учиться, либо ты идешь туда, где у тебя больше шансов заработать деньги, наверное. И Тут, если у тебя хорошо с математикой, с логикой, со структурой, то программирование, конечно, это такая специальность, в которой по деньгам ты сейчас не прогадаешь. Из этого вытекал часто такой еще вопрос по поводу образования.
В принципе, вот такие крупные компании, как Google, Facebook, Amazon, в которой ты работал, насколько важно, в принципе, именно образование в плане теплом? Либо они могут взять тебя, если у тебя просто ноль образования, но есть опыт, например. Есть такие прецеденты или для них это принципиально? Образование влияет в зависимости от того, где ты находишься в своей стадии карьеры.
Если тебе, условно говоря, 22 года, то есть свежий выпуск книг, такие ребята приходят многие напрямую в Google или в Amazon после колледжа, то есть на самой начальной позиции, допустим, программистами. И их там уже всему обучают, то есть первые пару лет они что-то какую-то пользу приносят.
но они приносят пользу совершенно незаменимым и деньгам, которые им платят. Их учат на будущее, на то, чтобы они учились и становились эффективными, в итоге выросли до сильнеров и так далее. У них очень много пробелов, которые им нужно получить только на практике. Но у них есть очень серьезные интеллектуальные
способности и скиллы именно вот сесть и что-то заходить, именно вот алгоритмическое. Тут образование очень важно, потому что если ты учишься на программиста 4-5 лет, то тебя натаскивают по этим всем делам. Поэтому образование важно, когда ты в самом начале своей карьеры. То есть, если ты прошел буткамп, Шансов попасть в Google или в Amazon практически нет. Если ты работал по 20 часов в день и занимался алгоритмами и получил...
эквивалент половины школьного образования. Если ты приходишь уже, скажем, более позже, когда ты не совсем очень молодой, а у тебя уже есть какой-то опыт за плечами, может быть, ты вообще не учился в университете, но ты много занимался сам, работал где-то, был программистом, под дизайнером, у тебя крутое портфолио, у тебя крутые рекомендации, тебе есть что показать, ты круто решаешь задачи на собеседовании, то у тебя все шансы попасть
И когда смотрят, когда мне приходят резюме, я их смотрю, потому что в этих компаниях собеседуют все. Собеседуют не HR. Мне приходится привыкать к этому, как в России про это говорят. HR в этих компаниях отвечают за зарплаты, за отпуска, за политики, но за найм отвечают рекрутеры. Это специальность отдельная от HR. Их задача в том, чтобы найти кандидатов, продать им только классную работу в компании и потом направить уже их в команду, собеседовать уже команду.
То есть все собеседования, которые ты проходишь, это собеседования с людьми, которые выполняют ту же функцию, что это. И они уже могут принять решение о твоем намеке. Прикрутеры, они не принимают участие. в принятии решения. И для меня вот это был такой разрыв шалона, когда я разобщался с парой репетёров в России. И говоря про образование, то есть, когда ты приходишь, уже опытный, смотрит на опыт,
Если у тебя нет совсем образования, это будет больше вызывать вопросы. Со мной работал парень, он был синьером, сейчас до сих пор синьер в Амазоне, очень крутой, хорошей траектории. Он учился на что-то вроде гражданского строительства в Индии. Совершенно не компьютерная специальность. И он где-то в середине своей учебы начал учебу немножко забивать и учиться программировать. И ему так прямо зашло, что он начал работать, фрилансить, потом устроился на работу куда-то, когда может быть.
26-27, он попал в Амазон без образования в программировании, но сейчас он один из самых крутых программистов, с которым я работал, и у него нет профильного образования. バイトロー! образование не является таким фактором, который тебя ограничит, но тебе нужно обладать эквивалентным набором знаний, который получить значительно сложнее, если ты не учишься в программировании. В колледже, в университете тебя именно натаскивают по алгоритмам, а алгоритмы, они...
Такая штука, которую изучать очень стрёмно и неинтересно. Поэтому не у каждого хватит терпения, чтобы это делать, потому что тут еще важно понимать, что когда ты пишешь, Особенно когда ты начинаешь, когда ты пишешь, создаешь сайты, какие-то веб-приложения, ты практически не используешь алгоритмы в том смысле, в котором они нужны в больших компаниях. Ты, может, сделал какие-то формочки, какую-то интеракцию с каким-то API. Это все такая бизнес-логика.
которую... Ее не сложно написать, нужно просто знать, как работает язык. Когда мы говорим про алгоритмы, которые спрашивают на собеседовании, тебя, условно говоря, попросят написать или улучшить алгоритм сортировки или что-то такое. Будут вопросы по системному дизайну, например. Я любил спрашивать, когда в Amazon работал, допустим, задизайнил мне систему проверки и оплаты парковочных билетов на парковку.
Когда ты приезжаешь, выставишь карточку в Power Command. Для маленького уровня ты начинаешь с того, как устроена система, какие у нее должны быть интерфейсы, как она должна писать базу данных и так далее. Это могут справиться многие. Потом ты начинаешь усложнять. Что если у тебя отвалилась связь? Что если...
у тебя несколько этих шлагбаумов, как они между собой синхронизироваться и так далее. Ты начинаешь как бы усложать, усложать, усложать, пока это все не переходит в задачу про распределенную систему. И таким образом уже определяется по уровню человека. И также смотришь, насколько человек мыслит за пределы задачи перемутания, то есть, насколько он
думает про UX, он думает про время ожидания, про очереди, которые скапливаются. Я к чему это сейчас говорю, что очень важно в этих компаниях обладать еще не только техническими навыками и умением решать задачи, но обладать этим общим кругозором и пониманием бизнеса. проблемы за пределами того, что непосредственно ты делаешь, склоняя голову над компьютером. А здесь остановлюсь, потому что я очень много уже сказал. Ты упомянул две вещи. Во-первых, ты сказал, что рекрутируют все.
вся команда не рекрутирует, как-то собеседовать. А во-вторых, ты сказал, что программисты, вот сейчас ты упомянул недавно, что они тоже занимаются UX, думают о нем в том числе. Во-первых, у меня два вопроса сразу. Первый, это... Как вообще вы рекрутируете и собеседуете UX дизайнеров? Ну или в принципе дизайнеров? То есть ты лично как-то все проходила? что ты от них ждешь, что ты требуешь и потом я задам второй вопрос. Я в гугле
дизайнеров не собеседовал. Я собеседовал в Амазоне несколько человек. Тоже, наверное, поясню немножко процесс, чтобы было как-то более понятно, почему продакт-менеджер был на собеседовании у дизайнеров. Процесс проходит таким образом. То есть рекрутер находит кандидата. То есть кандидат, может быть, подается или его находит, его кто-то делает ему реферал.
направляет его в компанию. Или, может быть, это из университета кто-то приходит. Рекрутер с ним разговаривает, настраивает весь процесс. И сначала идет телефонный скрин Ну, его так называют, хотя сейчас все проходит через видео. Это первый телефонное собеседование, на котором, честно говоря, у дизайнеров я не знаю, что спрашиваю, но суть первого телефонного звонка это в том, чтобы отсечь...
заведомо плохих кандидатов. То есть если ты общаешься с человеком, ты понимаешь, что он вообще ничего не знает. И ты не хочешь тратить время шести человек на то, чтобы удачу собеседовать. То есть это вот чисто вот такой вот фильтр, вот такой очень грубый фильтр для того, чтобы просто не допустить совсем плохих кандидатов. Потом следующий этап, вот так называемый on-site.
То есть в былые времена люди приходили, им покупали билет, они прилетали к тебе в офис, и их собеседовали лично сейчас, и все происходит удаленно через видео. Это порядка 5-6 интервью по 45. 60 минут друг за другом. То есть это занимает целый день. Когда ты проходил в офисе, люди еще подели на ланч. То есть реально ты приезжаешь, в 5 часов у тебя начинается, ты заканчиваешь часа в 3 вечера.
весь измотанный. Для интервью назначают людей, которые проверяют определенные важные для компании срезы. Если говорить про Amazon, у Amazon есть лидерские принципы. Это 14 лидерских принципов, которые определяют
культуру компании. И у каждого из собеседующих есть задача проверить, насколько человек соответствует наиболее важным лидерским принципам. То есть каждому дают, допустим, два лидерских принципа, и в итоге пять человек проверяют десять принципов. То есть это вопросы из серии «Расскажи мне, как...»
допустим, ты работаешь с конфликтом. Расскажи мне, допустим, у тебя была задача, в которой было невозможно, что ты с ней сделал. То есть это интервью больше не техническое, не в плане хардскиллов, это интервью больше на твою рабочую этику и на твои софтскиллы. как ты умеешь работать с людьми и так далее. Это как бы обязательно часть любого интервью и каждого человека, который собеседует. Вторая
половина интервью каждое собеседование. Это проверка каких-то технических скиллов. С дизайнерами я знаю, что Amazon делал ревью портфолио. Ты как кандидат собираешь портфолио. Те говорят о том, что они ищут. То есть опять же эти компании, да, они не скрывают, что они ищут. Они говорят, вот
для того, чтобы быть успешным дизайнером в Амазоне, тебе нужно было тем-то, тем-то, тем-то. И это то, что мы будем спрашивать. И они хотят, чтобы ты заранее подготовился, чтобы ты мог себя хорошо презентовать. Потому что их задача найти хорошего специалиста, а не быть сервером на вратах.
И у многих кандидатов на самом деле вот это ощущение, у меня само было такое ощущение, особенно приезжая из России, что вот эти люди, они хотят меня как бы не пустить. На самом деле они хотят тебя пустить, но они хотят пустить тебя только в том случае, если ты соответствующих требованиям. Для того, чтобы лучше проверить требования, они заранее ими делятся, для того, чтобы ты мог о них хорошо рассказать.
И портфолио review, насколько я знаю, это ты показываешь, что ты делал, или ты выбираешь какой проект, о котором ты хочешь рассказать, и рассказываешь о том, какая была бизнес-проблема, которую ты решал, как ты к ней подошел, какой был процесс, поиск этого решения. какие принципы ты использовал, как ты работал с другими стейхолтерами, как ты работал с продуктом, как ты работал. с инженерами, с другими командами, если нужно. Ну и, соответственно, что вышло в итоге. что в итоге это...
показывает, насколько то, что ты делал, к какому результату это привело. Но на самом деле результат, он в этом плане даже менее важный, чем процесс. То есть результат, он, знаешь, какая-то верхушка избранная. Так выходит наш портфолио-ревью. Минут 30-40 тебя спрашивают по этому проекту, уходят вглубь. И Амазон очень известен тем, что в Амазоне интервью очень-очень глубокие.
То есть я могу задать один вопрос, и этот вопрос будет вопрос, который ты можешь отвечать целый час, потому что тебя вот постоянно... идти глубже и глубже и глубже и глубже. Цель этого в том, чтобы убедиться, что ты не придумываешь что-то на ходу, а на самом деле делал то, что ты говоришь, что делал. Потому что когда очень глубоко ты уже не можешь придумывать на ходу какие-то вещи, ты уже начнешь запинаться, и это сразу всплывет. Поэтому эти вопросы, они очень эффективны. Когда я проводил...
для дизайнеров. Я не делаю портфолио, я делаю только вопросы по софтскилам, по работе с командой. Мне тут важно понять, насколько этот человек мыслит правильно для того, что мне нужно для моего продукта. Мы говорим про продуктовые команды, которые делают проекты для продуктов, не для других компаний. У нас нет конкретного клиента, на котором мы работаем. У нас есть тысячи, в случае миллионов клиентов, пользователей, и мы делаем для них продукт. Один для всех. То есть есть направление...
то есть пользуются такие продукты обычные люди. Есть Enterprise, это то, что можно назвать B2B. Но это не просто B2B, это B2B для очень большой корпорации. Условно говоря, Google Maps – это продукт пользовательский. Ты зашел, каждый там что-то нашел, посмотрел, когда бизнес работает, все закрыл.
Это твой пользователь use case. И Enterprise use case, это, например, то, чем я сейчас занимаюсь, это платформа, на которой разработчики из крупных корпораций запускают свои приложения. И если я нанимаю дизайнера на такого рода продукты, то есть мне важно, чтобы он понимал именно потребности таких пользователей. и мог бы под них подстроить.
То есть мы не ожидаемо, что у человека есть опыт в интерпризе. Если у человека есть опыт в пользовательских приложениях, он может успешно справиться в интерпризе. Но не всегда люди готовы подстроиться под другой... склад, другой подход, наверное, правильно сказать. То есть, когда ты делаешь пользовательские приложения, ты можешь поменять дизайн. Ну, блин, пользователи держат себе новый дизайн, привыкайте к нему.
В то время как в Enterprise, если ты такое сделаешь, то тебе придется какое-нибудь имя использовать. Грубо говоря, IKEA, как компания огромная, скажет, Ребята, у нас куча тренингов, которые были завязаны на видео из вашего интерфейса. вы нам все поломали. У нас сломались все тренинги, у нас сломалась вся документация, у нас стала неэффективная команда из 800 человек. И ты такой, упс. И помимо ИКИ, где пришло еще 300 потише.
крупных корпораций. На что это влияет? Когда ты делаешь дизайн для продуктов для таких корпораций, ты должен очень-очень глубоко продумывать изменения. На сколько эти изменения повлияют на пользователя? Действительно ли то, что ты меняешь, становится лучше для них. Ты не можешь делать эксперименты. То есть, если в пользовательском интерфейсе ты можешь делать A-B-тест и дать миллиону пользователя что-то одно, 10 миллионов что-то другое,
и посмотреть, какие будут метрики. И люди это схавают, потому что они в большинстве случаев пользуются этим продуктом бесплатно. В интерпрайсе это просто не работает. потому что тебе люди платят миллион долларов, каждый из них, и ты должен очень подстраиваться по то, как они работают. У Google была такая проблема, когда они только заходили в Облако лет, наверное, 10-12 назад. То есть они подходили к Облако как
к своим остальным продуктам, как к поиску. Где ты можешь что-то поменять, и люди просто хавают, потому что у них нет другого выбора. И это их
Это им, скажем, не помогло в последние несколько лет. Google очень серьезно вкладывает, инвестирует в то, чтобы соответствовать требованиям корпораций, в том числе касается и дизайна. Дизайнерам приходится переучиваться в плане того, как они мыслят для того, чтобы работать в облачной среде. Ты говорил, что программисты... на собеседование, может там начать рассказывать что-то про UX-дизайн и соответственно это говорит о том, что в команде у вас
все владеют какими-то знаниями про UX. Соответственно, как происходит работа над UX-дизайном, если есть UX-дизайнер и при этом вся команда что-то понимает в UX-дизайне, то как распределяются задачи, за кем последнее слово и так далее.
Программисты не делают UX-дизайн и не должны делать UX-дизайн. Программисты PM и UX — это три функции, у которых, если ты начинаешь совмещать то, что они делают, возникает конфликт интереса. То, что менее удобно для пользователей, обычно проще запрограммировать. Программисты, которые делают UX — это как леса в курятнике.
Потому что они могут для себя делать что-то легче и могут не хотеть делать что-то дополнительное для пользователя, потому что для них это дополнительная работа. Вот поэтому это должно быть разделено. То, что я хотел донести... Это то, что люди должны думать о том, как их работа влияет на то, за что они не несут прямую ответственность.
То есть, если ты программист, ты делаешь какую-то API, API используется пользовательским интерфейсом. И ты должен всегда понимать все твои зависимости, которые тебя используют. И UX это одна из их зависимостей. Плюс UX это такая дисциплина, знаешь, где у всех есть мнение. Я вспоминаю, есть такой прикольный комикс, картинка.
Типа, что если бы программисты были UX-дизайнерами? И там сидит толпа людей в пиджаках. И стоит программист, пишет код на доске. И один из этих людей в пиджаках говорит ему. Мне кажется, эту перемену нужно назвать по-другому. Суть этого в том, что когда тебе показывают дизайн, ты интуитивно все понимаешь.
И ты говоришь, мне синий цвет не нравится, давайте используем красный. У дизайнеров в этом плане очень сложная работа, потому что их работа, она интуитивно понятна другим людям, и другие люди могут им давать советы, которые часто не прощены, часто не используют правильные принципы, и они как бы не из того места, скажем, не из экспертизы. Как работает дизайна этих компаний. Давай опять же посмотрим, наверное, на процесс.
создание продукта от начала до конца. То есть все начинается где-то с идеи. За идея отвечает Product Management. То есть идея приходит действовать от пользователей или она может может купить откуда-то сверху или от самого продакт-менеджера. Продакт-менеджер начинает ее оформлять в документы. Документы в компаниях разные, но это какое-то подобие такого стратегического документа, в который также включаются...
требования к продукту в целом, не к определенным фичам, а к продукту в целом и к фичам, которые будут в первой версии. На каком-то этапе, когда уже начинает идея формироваться в что-то более конкретное, обычно увлекается UX, для того, чтобы по-брейнстормить, как это вписывается в другие продукты, какой может быть интерфейс, обмен идей. для того чтобы
вот этой идеи в какую-то визуальную форму, потому что идеи в визуальной форме всегда легче продать. Продать в плане, то есть ты работаешь в большой компании, ты не можешь просто взять и начать делать свою идею, потому что любая идея занимает очень много времени и требует очень больших ресурсов инженерных. Поэтому идею нужно продать,
чтобы тебе дали на нее ресурсы. И когда у тебя есть, грубо говоря, хорошее видение, стратегия, есть UX-дизайн, то это все намного проще. Первая версия дизайна, она, как правило, это просто мох, Моки, как правильно назвать по-русски? Грубый дизайн. Когда я начинал в Amazon, было так. Было все нарисовано в каких-то просто, может сказать, линиях. Но за последние годы очень стала популярна тема
систем дизайна. И компании, такие как Amazon, Google, Facebook, у всех есть своя система дизайна, которая делает интерфейс унифицированным по всем их продуктам. И за счет того, что есть набор компонентов, набор паттернов, набор принципов, которые они используют. У этих дизайн-систем есть интеграция в Figma, Sketch и другие приложения, которые они используют. Поэтому, на самом деле, сейчас даже самые первые наброски дизайна, они уже выглядят как...
законченный продукт, потому что дизайн-система позволяет тебе вместо того, чтобы рисовать какой-то грубый квадратик, ты просто берешь и делаешь мобку так, как она будет выглядеть уже на сайте. И для дизайнера не требуется никакой дополнительной работы. То есть у тебя есть уже вот эти вот рамки, в которых ты работаешь в плане визуального представления. Кстати, это тоже важный фактор, когда у тебя есть дизайн-система, у дизайнера очень мало свободы в визуальном представлении информации.
Это, опять же, зависит, конечно, от компании и от того, работаешь в пользовательском домене или в Enterprise. Я работаю в Enterprise, и у нас у дизайнеров очень мало свободы в плане того, как это все выглядит. То есть есть определенные компоненты, есть формы, потому что... все портфолио продуктов должно выглядеть так,
для пользователя, что они видят, что это продукты именно твоей компании. Если ты посмотришь на продукты Microsoft, например, Word, Excel, PowerPoint, SQL Server, например, Windows, ты понимаешь, что это продукты Microsoft. Несмотря на то, что его делали сотни разных людей, это дизайнили. Потому что они используют одну и ту же дизайн-систему. В общем, дизайнер создает...
с тобой вместе, как это все будет выглядеть. И потом в какой-то момент ты начинаешь вовлекать инженеров, программистов. Ну, как правило, это лидов, которые начинают оценивать, как эта идея будет разрабатываться, сколько это будет. стоить в плане жирных ресурсов, как она же архитектура, это вот как работает, скажем, agile product development.
У тебя еще нет законченных требований, но ты уже работаешь с дизайнером, ты уже работаешь с разработкой. Ты вместе как-то идешь вперед, хотя дизайн еще до конца не доработан. инженерные вещи еще до конца не доработаны, но они вносят, я бы сказал, как дизайн обогащает требования, потому что он помогает их более, скажем, красиво представить и визуализировать, и увидеть какие-то, может быть, пробелы.
которые ты не продумываешь в требованиях. А инженерная тема, архитектура, она помогает тебе увидеть технические ограничения, с которыми ты можешь столкнуться и которые могут...
собственно помешать тебе вообще сделать этот продукт или сделать его разработку настолько дорогой, что это просто будет непрактично. Вот и в итоге все это вместе как бы сходится в требования, которые, как правило, в этих компаниях, то есть ты идешь к каким-то руководителям, да, там с коллегами, все это обсуждается, куча итераций, 2-3 месяца все это продолжается, и у тебя в итоге получается законченный комплект требований какой-то подобной архитектуры.
инженерный и какое-то подобие UX-дизайна, которое нужно дальше развивать. Дизайнеры дальше берут то, что они наработали, изменения в требованиях, и начинает уже создавать различные версии UX, как это может выглядеть. Происходит несколько разных встреч, где
все это обсуждается. Они дают дизайн-критику своим другим коллегам, дизайнерам. Product management очень активно участвует. Программисты в каких-то случаях тоже дают фидбэк. Важно получать фидбэк от программиста, потому что то, что ты делаешь, может быть невозможно. То есть визуально это все возможно. Визуально возможно сделать, в принципе, сейчас все, наверное.
в нынешней среде. Ну, допустим, ты хочешь показать какие-то данные, и программисты тебе говорят, блин, у нас нет такого API, или эти данные вообще не существуют. Если на этом держится зависит твой дизайн, то стоит выбор, да, либо мы это разрабатываем, на это уходит, допустим, год, либо мы делаем без этого. И поэтому идет постоянно как бы вот такой вот
слово пытаюсь подобрать, такое трение, наверное, да, между дизайном, инженерингом и продукт-менеджментом, вполне конструктивное трение. То есть это трение, когда, это значит, как наждачная шкурка, да, то все постепенно шлифовывается. И так вот мы идем, как бы вот так вот идем, такими вот совместными шагами.
дорабатывая требования, создавая код и дорабатывая дизайн. Потому что тоже в процессе создания продукта у разработчиков могут возникнуть вопросы. Например, о, а это как мы показываем? Этого не было в дизайне. Плохой разработчик возьмется сделать это сам. И потом у нас получаются продукты, когда у тебя там кнопки навешаны друг на друга, ничего не понятно. И такие продукты пользователи не любят. Это люди, которые ругаются на эти продукты. Важно вовлекать обратно дизайнера, потому что дизайнер...
Его задача в том, чтобы смотреть на дизайн целиком. То есть, словно говоря, тебе говорят, вот на этой форме у меня не хватает кнопки. Дизайнер не просто добавляет эту кнопку рядом с существующей кнопкой. Отзумливается назад и смотрит. как эта кнопка будет связана со всем остальным. Возможно, решение будет вообще просто переделать полностью весь этот поток. где нужна эта кнопка для того, чтобы сделать ее по-другому.
потому что это одна дополнительная кнопка все настолько меняется, что меняется весь дизайн. И в этом плане дизайнеру очень важно помыслить за пределами дизайна. У нас нет UI-дизайнеров, у нас Есть визуальные дизайнеры, но их очень мало. Визуально это которое люди создают графику. UI целиком входит в UX. UX это всеобъемлющая специальность, как я для себя определяю. UX отвечает за удовлетворение потребностей пользователей через дизайн. И в UX входит UI, в UX входит весь текст.
который ты изображаешь в интерфейсе. В UX входит в том числе API. Если ты работаешь в очень технической компании, допустим, в облаках, то API, дизайн API, это тоже UX. То, что пользователь видит на экране, не изолировано от того, как он использует продукт через backend. Интерфейс командной строки, это тоже UX. Дизайнеры... Как правило, они обладают достаточно техническими знаниями, чтобы именно вносить серьезный вклад.
в то, как создается командная строка. Но текст, который там идет в командной строке, то есть это все должно идти через UX-дизайн. Документация тоже UX. То есть UX, даже если дизайнер отвечает непосредственно за UI в конкретном проекте, он все равно должен думать за пределы UI.
с чем взаимодействовать пользователи. Это очень важно. И, опять же, уровень дизайнера в этих компаниях зависит от того, насколько они способны мыслить широко. Плюс еще такой очень важный фактор. Продукты Microsoft, я думаю, они всем известны. Есть Word, есть Excel, есть еще куча других продуктов. И эти продукты работают всем. друг с другом. Чем выше уровень дизайнера, чем он опытнее, тем больше он смотрит на то, как продукты взаимодействуют между собой и как
сделать какие-то вещи, когда у тебя переход между продуктами настолько гладкий, что пользователь просто этого не замечает даже, что он переходит между продуктами. Знаешь, в какой-то степени, я, наверное, процитирую, по-моему, это был Белестив Джобс, где кто-то из Аппл это сказал, что когда ты смотришь на телефон, ты должен видеть телефон, телефон должен просто растворяться. То есть дизайн, хороший дизайн, он растворяется, ты его не замечаешь, ты просто взаимодействуешь
той проблемы, которую ты хочешь решить, вот, посредством того, что тебе дали. Если ты начинаешь обращать внимание, что, блин, я вот не могу нажать, или это как-то неудобно, то это уже признак
Какого плохого дела? Получается, если подытожить, это такое экосистемное мышление, чтобы понимать не просто на уровне вот этой конкретной формы и этой конкретной кнопки, а нужно понимать, во-первых, в рамках всего проекта, а во-вторых, еще дальше и в рамках всей экосистемы, чтобы понимать, как это все должно работать вместе. и с бэкэндом и с другими продуктами. И это все входит
в обязательства и в навыки UX-дизайнеров, например, в Google. Еще, кстати, я отмечу, что после определенного уровня, обычно это уровень principal, дизайнер в Амазоне. И то же самое спространяется на уровне принципов инженер для программистов. Это люди уже, которые очень мало делают дизайна или пишут код своими руками. Они леды, но им не подчиняются люди. Их задача во многих командах
в том, чтобы создавать архитектуру. Для разработки все это понятно. У тебя есть система, тебе нужно, чтобы она хорошо работала со всеми другими системами, хорошо масштабировалась и так далее. Это, мне кажется, более понятно. А с дизайном?
В крупных компаниях информационная терапия очень важна, дизайн системы и так далее. В больших организациях такие вот принципы не создают дизайн сами, но они порядок над всеми, со всеми общаются, вытягивают, толкают для того, чтобы то, что было на выходе, допустим, через три года. было нормальным полноценным продуктом, где все его компоненты взаимодействуют с другом очень хорошо. Это тоже такая интересная тема в плане профессионального роста.
Потому что ты можешь расти вертикально, то есть ты можешь быть дизайнером первого уровня, дизайнером второго уровня, дизайнером третьего уровня. Потом, если ты хочешь, ты можешь стать менеджером, тебе уже подчиняются другие дизайнеры.
ты становишься старшим менеджером, когда тебе подчиняются. Менеджеры, которым подчиняются дизайнеры. Ты можешь стать директором дизайна, VP дизайна. Это вот такая вертикальная схема, в которой при переходе на каждый следующий уровень у тебя появляется все больше и больше потребностей в софт-скиллах.
и именно в таком более широком мышлении. И когда ты переходишь на уровень менеджмента, ты перестаешь делать дизайн. Это очень важно. Ты продолжаешь его понимать, но ты перестаешь его делать. Многие люди, я знаю достаточно много людей, но в основу из разработки, кто... не смог пережить этот переход. из разработчика в менеджмент. Не потому, что они не справились, а потому, что им просто мне понравилось.
Посмотрели там вся эта работа с людьми, все эти увольнения, найм, коучинг, конфликты между людьми, про которые ты не знаешь, когда ты работаешь. в команде. Оказывается, у кого-то там какие-то тёрки, у кого-то, блин, там, проблемы очень серьёзные, там, личные. Куча ещё административки, во всём ты варишься и думаешь, блин, нахрена мне это нужно, да? Пойду-ка я обратно, короче, дизайнить. И это совершенно нормально. И в эти компании они дают возможность развиваться.
в этом направлении. То есть ты можешь вместо того, чтобы пойти в менеджмент, идти дальше по уровням как специалист. Но там тоже, как я уже говорил про принципов, их работа уже в основном лежит на soft skills и на очень глубоком понимании принципов, то, что принято называть насмотренностью сейчас. Насмотренность не в плане визуальной насмотренности, а именно какие-то архитектурные паттерны, принципы, то есть понимание того, как люди эти тетки
сейчас делают, через три года это может создать проблему. То есть он это уже видел где-то там в прошлом у себя в своем опыте. То есть он смотрен с более высокого порядка, так сказать. Эта работа тоже не всем заходит, потому что у тебя возникает ответственность за стратегию, при этом ты ее не исполняешь. и при этом люди тебе не подчиняются. Это должность,
Не все люди могут с ней справиться, потому что это позиция мягкого лидерства, когда ты влияешь на других людей. Ты можешь, конечно, эскалировать, их менеджеры скажут, что люди делают говно, нужно их остановить. и что-то сделать. Но обычно это возникает только когда люди тебя не слушают.
когда ты не можешь донести до людей разумно, ну, любят люди нерациональные на другом конце провода. Эта позиция очень сложная, потому что у тебя очень-очень длинные проекты, и у тебя нет такого ощущения какого-то успеха, такого, знаешь, ежедневного. Работаешь дизайнером, ты вот сделал кнопочку, у тебя похвалили, думаешь, клево, как, да, вот.
Я делаю свою работу. Или ты сделал проект за три месяца, в конце трех месяцев у тебя тоже пользователи пользуются, всем нравится, ты тоже там доволен. У принципов, у них проекты могут длиться годами. Их результат, в принципе, даже не так просто.
на него указать, потому что, ну да, у Microsoft классные продукты, которые круто между собой взаимодействуют. Но это знаешь, как говорят, что самый классный сисадмин, это сисадмин, которого никто не видит, потому что все просто работает. В этом плане работа принципа может быть неблагодарна, потому что...
все успехи, они будут присвоены тем людям, которые делали работу. Тебе нужно при этом себя еще хорошо продавать внутри компании, именно в плане политики, чтобы люди знали, что ты делаешь, какую пользу ты приносишь. Потому что иначе это будет выглядеть, как будто другие люди просто сделали классную работу, а ты вообще что здесь делаешь?
Это очень интересное направление. До него тоже дорастает просто, скажем, единица, очень маленький процент, потому что он требует очень серьезных лидерских навыков без непосредством контроля людей. Многие просто, скажем, останавливаются на синере и думают, ну все, короче, я не хочу влиять, я хочу просто создавать. И они на этом уровне встаются.
Убираются в этот момент потолок по зарплате. Не могут быть какие-то бонусы, там еще что-то. Есть какой-то диапазон денег, который они зарабатывают. И выше него они уже не пойдут. Ну, только если, может быть, по-другому перескочат. Но все равно по индустрии в целом у тебя будет вреден потолок. В то время как, если ты идешь на уровень принципа, там уже разброс может быть просто колоссальный.
Потому что если ты работаешь на очень огромных проектах, организациях, то тебе будет очень много платить, потому что таких людей очень мало. Это, скажем, для вдохновения, для дизайнеров, которые хотят перейти в менеджмент, но не очень хотят. Есть пути не быть менеджером, быть специалистом, но нужно быть очень крутым и обладать серьезными софтами. Ты взаимодействуешь как-то с таким человеком у себя на работе? Вы общаетесь или это как-то именно с
чисто с дизайнерами? Я работал с двумя принципами. Один дизайнер был другой в разработке. Причем мы все начинали как синьеры, и мы все стали принциповым в итоге. То есть я стал принциповым продуктом, а не стал принциповым. дизайнером, он стал принциповым инженером на том проекте, который мы вместе создали. И если немножко описать их работу, мужик
принцип дизайнер, его звали Рон. Я про него, кстати, писал в одном из постов или сторис. Он меня старше, наверное, 25 лет. То есть он старше моих родителей. И он проработал в индустрии больше, чем я живу. Он там с 70-х годов еще в этом варился. когда еще никто про это не знал. Он был на самом деле такой дизайнер,
В больших организациях у тебя дофига информации, у тебя куча документации, именно внешней документации, которую используют пользователи. У тебя есть весь этот текст во всех интерфейсах. В Амазоне в AWS на тот момент было 170 продуктов, у каждой из которых свой отдельный интерфейс.
в котором есть еще под-интерфейсы. Это огромное количество текста везде, текста и информации. И его была задача в том, чтобы во всей компании текст Содействовал определенным принципом, чтобы люди, читая текст в разных местах, понимали, что они взаимодействуют именно с Amazon Web Services, а не с какими-то разными. Его работа, наверное, на 60% заключалась в том, чтобы ходить на разные ревью, давать людям фидбэк, если он заметил, что где-то что-то делается не так.
он тоже давал им фидбэк без спроса. То есть он где-то эскалировал, если было нужно, если кто-то шел туда. Плюс у него были какие-то проекты, которые он сам создавал. То есть он видит, ага, у нас вот Текст пишут не дизайнеры, текст пишут разработчики. Из-за этого у нас просто полный хаос везде. И один из проектов, который он сделал, если не ошибаюсь, он собрал руководство с разных организаций и продавил им эту идею, что текст должны писать.
В нашем случае текст писали люди, которые отвечают за написание документации. Он, по сути, забрал написание текста из рук дизайнеров и отдал это в руки людей, которые... пишут текст целыми днями. Это их работа. И вот это как пример такого проекта, с которыми работают принципы. Какими навыками должен обладать дизайнер, чтобы устроиться на работу в тот же самый Google, например, или Amazon? На что будут смотреть?
и что важнее. Во-первых, что важно в hard skill, если ты, конечно, владеешь этой информацией по UX, по дизайну. и что важно по софтскому По хардскиламу у меня ограниченная информация. занимался немножко наймом для других команд. Для своей команды я не нанимал дизайнеров. Что касается софт-схиллов, смотрят на то, как человек взаимодействует с командой. Потому что дизайнер, это такая функция, я уже говорил, что он немножко, может быть, неблагодарный, потому что тебе все хотят дать какой-то фидбэк.
рассказать, какая кнопочка должна быть больше и так далее. То есть что-то совершенно не основано на знаниях и экспертизах, а чисто на мнении человека. И дизайнер должен очень хорошо иметь работать с такими мнениями. дизайнеру важно понимать принципы дизайна. Есть, например, книжка Дона Нормана «Дизайн повседневных вещей». Она написана, по-моему, еще в 70-х, но очень давно. Я читал первое издание, оно на 100% применимо к современному миру.
Просто нужно вместо слова «печка» использовать слово «кнопка». Потому что все принципы переносятся на современный мир. И когда, условно говоря, тебе дают какое-то мнение, то дизайнер должен уметь его парировать при помощи принципов. объясняя, почему именно так важно для пользователя, почему эти вещи расположены рядом с другом и так далее. Но дизайнер должен, опять же, уметь принимать фидбэк, потому что это такая профессия, когда ты делаешь это творчество,
Когда ты начинаешь вовлекаться эмоционально, то очень перерасстаешь к продукту своего труда. И когда тебе что-то говорят, то можно это воспринять в штыки и не хотеть менять то, что ты сделал. Когда люди закрываются, ты сразу чувствуешь, что становится закрытая поза, меняется голос.
Ты начинаешь чувствовать сопротивление на таком интуитивном уровне, на языке жестов. Это нормальный, на определенном уровне, потому что мы все люди, мы всегда хотим дополнительную работу делать, мы можем быть не согласны. Хороший дизайнер, он примет этот фидбэк,
запишет его где-нибудь и скажет, я подумаю. Хотя внутри у него, может быть, все так кипит. Он думает, почему ты мне так говоришь, да? Кто здесь дизайнер? И потом идет обратно, может быть, даст ему там ночь, говорится. И... смотрит на свой дизайн критическим взглядом, начинает анализировать то, что ему дали, опять же, с позиции принципов, с позиции того, а может быть, я чего-то не знаю, может быть, я что-то выпускаю, может быть, я что-то не знаю.
про пользователя или, может быть, я что-то не знаю про back-end stack, который мешает сделать то, что я хочу сделать. И он начинает дорабатывать и делать новую итерацию. У тебя может быть 20-30 итераций дизайна, при котором ты переберешь 3-4 разных варианты, которые просто совершенно друг от друга отличаются.
Дизайн и многие другие профессии люди думают, ты сидишь там и рисуешь вот эти квадатики, это класс, потом пользователи пользуются и все счастливы. Но на самом деле в работе дизайнера очень много негламурной работы. И негламурная работа заключается в том, чтобы получить этот фидбэк, разломать все, что ты сделал, создать это заново. Потому что ты начинаешь что-то менять, у тебя оно начнет ломаться в другом месте.
Ты думаешь, блин, это особенно сложно, когда ты делаешь не новый продукт, а когда у тебя уже есть работающая система, у которой есть пользователи. Тебе нужно что-то сделать, и у тебя очень серьезные ограничения, потому что оно уже там существует, люди пользуются, ты не можешь просто брать и ломать. Да, поэтому брать фидбак очень важно. и не весь выбор обязан принимать. Важно уметь его фильтровать, оценивать, документировать и обосновывать.
то, что ты взял, то, что ты не взял на основе принципов. И третий очень важный навык, да, это понимание концепции экспериментирования. Есть принципы, есть мнение, есть конфликтующие мнения, конфликтующие принципы. И правильный ответ на самом деле непонятен. То есть ты не знаешь, как сделать лучше. И тогда ты начинаешь тестировать.
Есть два механизма тестирования, таких основных, концептуальных. То есть, первое, это ты берешь пользователя, садишь его за компьютер, садишься с ним рядом и наблюдаешь за тем, что он делает. В каких-то командах это делают отдельные команды UX Research. Где-то это делает сам непосредственно дизайнер. Но дизайнеру важно находиться при этом, закрыть рот и слушать все, что пользователь говорит. Потому что то, что пользователь говорит и то, что он делает, это реальность.
То, что у тебя в голове, принципы, мнения, это все воображаемое. Если ты посадил 10 пользователей, и они делают то, что противоречит принципам, значит, это неправильный принцип. И эти принципы здесь не применяются. И очень важно тоже уметь это принимать. Я недавно себе писал, что есть в некоторых культурах представление, что пользователи просто тупые. То есть мой дизайн классный, мой продукт классный. Пользователи просто недалекие, не догоняют.
Все это идеальные штуки, которые я сделал. Это очень токсичная тема, потому что пользователи это реальность. Это то, что происходит на самом деле. И второй подход к тестированию это
тестирование непосредственно в продакшене и битестирование. Не везде есть такая возможность это сделать, но там есть возможность, ее нужно активно использовать. В любом случае, ты сначала тестируешь с пользователями, но если изменения маленькие, ты можешь их сразу в продакшен отправить и ты отправляешь только маленький процент трафика. если это веб-приложение или мобильное приложение.
на свою измененную версию. Условно говоря, 99% трафика идет на то, что у тебя есть сейчас, и 1% трафика идет на то, что ты хочешь изменить. И у тебя есть определенная метрика, которую ты хочешь оптимизировать. В Амазоне они измеряют сколько ты потратил денег. Я не помню, эти нюансы, эти метрики. Но, условно говоря, если человек тратит меньше денег, то дизайнеры работают хуже. Если он тратит больше денег, то дизайнеры работают лучше, потому что цель – это рост.
могут быть и вспомогательные метрики, и есть процент завершения корзины. Может быть метрика, которую ты оптимизируешь. AB-тестирование. Почему называется AB? Потому что у тебя есть A, это то, что у тебя существует. AB, это то, что ты хочешь проверить. Еще бывает MC и так далее. То есть ты можешь несколько вариантов одновременно делать. Если у тебя количество пользователей позволяет делать
такие большие эксперименты. И всегда ты даешь данным разрешить спор. Собственно, у тебя спор может быть самим собой. Это может быть, я не знаю, как лучше сделать. У меня есть такая идея, есть такая идея. Вроде обе хорошие. И на самом деле они обе могут быть хорошие, но одна всегда будет немножко лучше. Ну, кстати, не всегда.
Они могут дать эквивалентные метрики, а различия будут статистически незначимы. И тогда, в принципе, ты можешь пойти с любым вариантом. Хороший дизайнер, умеет хорошо коммуникировать и хорошо принимать. фидбэк и участвовать в этих обсуждениях. И, скорее всего, исходят многие другие скиллы. Ты должен уметь хорошо говорить, ты должен уметь хорошо струклировать информацию. Как-то так.
Когда начинается это тестирование? Ты до этого рассказывал, как начинается работа с продуктом и в какой момент тестирование начинается и когда вы начинаете именно тестировать на живых людях. кто команда или прям пользователи, либо вы как-то сами все это обдумываете, варите в собственном соку, а потом презентуете. Как это все происходит? Учитывая то, что мы работаем в Enterprise IT, наши пользователи очень требовательны. Их не так много, но они очень требовательны, как правило.
все, что выходит в продакшн, тестируется какими-то внешними пользователями. Какие-то маленькие изменения, если ты хочешь какую-то коду добавить, и у тебя в принципе и так все понятно, и эта кнопка приносит новую функцию. В принципе ее не обязательно тестировать, она нечетно.
кардинально не меняет. Если ты делаешь какие-то изменения в том, как, например, происходит навигация, или ты меняешь формат таблицы, как показываются какие-то данные, за то, что может материально повлиять на то, как пользователи взаимодействуют с системой. Внутри команды мы это тестируем. просто показывает людям. Дизайнеры показывают разработки, продукты, все это смотрят, дают фидбэк. Все это больше не тестирование, это больше брейнсторн. Когда начинается тестирование, это зависит от
того, какая у тебя фича, то есть что ты меняешь, насколько это сильно меняется. В каких-то случаях изменения настолько кардинальные или что-то настолько новое, что ты делаешь прототип, который можно кликать, иногда добавить просто PDF. Это не обязательно что-то очень сложное. Ты находишь внешних пользователей, которые готовы тебе
помочь, даешь им в награду какие-нибудь гиф-карты, ну что-то такое, чтобы, знаешь, людям дать мотивацию поучаствовать. Даешь им этот прототип и смотришь, как они с ним взаимодействуют. Этот тест приближен к использованию реальной системы, но он все равно такой искусственный. Другой вариант, если
Изменения достаточно простые в плане именно технических изменений. То есть ты можешь сделать эксперимент, который скрыт от публики. У тебя есть другая версия в продакшене, которую ты можешь дать определенным пользователям. То есть ты добавляешь пользователя в так называемый white list,
Это белый список. И этот пользователь может увидеть другой интерфейс. И ты этого пользователя садишь с собой, и он уже непосредственно взаимодействует с продакшеном, со своими собственными данными, со своим собственным аккаунтом. И это такой очень хороший тест.
когда ты можешь получить очень хорошие данные, потому что эта ситуация не искусственная. Но это не всегда возможно, потому что иногда бывает очень дорого эти изменения внедрить в продакшн и проще насечить какие-то плохие идеи на этапе прототипов. Другой вариант, который очень сильно развит, в крупных компаниях и в Амазоне, и в Гугле. Это так называемый dogfooding. Этот термин идет из, по-моему, 70-х годов. Делали какую-то собачью еду.
И лозунг рекламы был что-то вроде, будут ли собаки есть собачью еду. Этот термин прижился. Я не знаю, как он попал в IT. Условно говоря, если ты берешь компанию Google, она производит собачью еду. Это твой продукт. Все, кто работает в Google, это собаки. И вопрос там, будут ли сотрудники Google есть. то что они выводят на рынок
Тестирование здесь в том, что ты запускаешь продукт для внутреннего использования. Есть определенный механизм, который позволяет сделать так, что есть разные версии продукта. Gmail, Google Docs и всем, чем я пользуюсь. на работе, я вижу другую версию, в отличие от того, что видят люди, кто не работают в компании. Мы всегда используем самые последние эксперименты внутри компании. Поэтому нельзя делать скриншотом даже Google карты
с рабочего аккаунта, потому что там могут быть фичи, которые не были запущены. И там ты собираешь метрики, плюс ты можешь сделать какую-то форму, где пользователи могут дать ей фидбэк, они могут тебе просто имейл написать. Потому что внутри компании ты можешь сделать какое-то мероприятие, где ты сделаешь презентацию, ты можешь отправить имейл.
ты можешь активно просить людей дать тебе обратную связь. В то время как с внешними пользователями это намного сложнее. Тут важно понимать, что те, кто работает внутри компании, у них все равно может быть немножко скажемой перспективы, потому что они не всегда могут быть
репрезентативными пользователями. Если говорить про usability, допустим, если кнопка добавляет больше проблем, чем решает проблему, то обычно это можно поймать и на внутреннем тестировании. Поэтому ответ в том, что здесь нет конкретного процесса, где ты говоришь, что если так, то так, если так, то так.
Ты смотришь по ситуации, и, опять же, еще есть важный фактор такой, как ресурсы, потому что у тебя не всегда есть время делать полноценный ресурч, не всегда есть возможность это в продакшен впихнуть, и ты принимаешь эти решения, исходя из того, какие у тебя потребности и какие у тебя риски. Если у тебя очень высокие риски, то...
Ты тратишь больше времени, вкладываешь больше денег и делаешь их, может быть, более медленно и более правильно. Если у тебя риски маленькие, бюджет маленький тоже. Ну, посмотрим, как будет. Если у тебя есть портфолио, какой-то крутой проект, но вот он под идеей, ты не можешь его там показывать по договору.
но он крутой и хотелось бы его показать на, допустим, собеседовании. А есть ли какие-то здесь выходы, либо просто придумывать тогда что-то другое? Такие вопросы встают и в собеседованиях у других позиций, когда тебе приходится более разлучатыми вещами рассказывать о том, что сделал, потому что что ты не можешь добавляться в детали. Я не знаю, как это проходит у дизайнеров, но ты однозначно не можешь показывать.
то, что ты это делал, потому что это BD9. Тебе придется про это как-то рассказывать, может быть, описывать, какая была пользовательская проблема, как ты ее решал.
какие принципы ты использовал. Будут смотреть больше на то, как ты мыслишь. В любом случае, ты можешь это как-то все описать, обойти. Просто конкретно в позиции дизайна это сложнее, потому что у тебя нет визуального представления о своей работе. Отойдя от темы портфолио собеседований, сейчас же локдаун и ты получается работаешь из дома и Как вообще в Google выстраивать и решать эту проблему? Понятное дело, что в офисе коммуникация проходит эффективнее.
Как сейчас вы устраиваете коммуникацию, например, с дизайнером, когда нужно обсудить вот эти вот все визуальные вещи, и вы при этом находитесь, насколько я понимаю, ты на Гавайях сейчас находишься, а он там условно где-нибудь...
в Сиэтле. И как вы это все устраиваете, и как вы это все организовываете, и как у вас происходит именно вот работа сейчас в условиях пандемии, скажем так. Локдаун – это очень моя больная тема, потому что я из тех людей, кто любит работать в коридорах. Для меня каждый поход, ну, в основном, граф.
в туалет или за водой, это возможность кого-то в коридоре встретить и с ним пару минут перетянуться пару слов. Таким образом, я собираю контекст. Как продакт, мне очень важно видеть широкую картину, понимать, что где происходит, потому что у меня есть много зависимости и много.
стейкхолдеров. И, допустим, чтобы немножко где-то почву прощупать, узнать какие-то слухи, может, знаешь, уже слухи важны, да, потому что, а что если там какая-то, кто, допустим, ушел из команды, да, и это влияет на исполнение проекта где-то в другом месте, и это влияет на меня косвенно. Ну, то есть такие вещи, да. И находясь в коридоре, ты можешь эту информацию собирать. Это мой стиль работы вообще. То есть у меня...
Всегда было не так много митингов, но я очень много общался с людьми в коридорах. Может быть, час. в день общался с людьми в коридорах. И когда начался локдаун, я работал еще в Амазоне, у меня забрали. Ты выходишь из такой ситуации, когда у тебя все общение в чате и в митингах. То есть митинг это нужно его запланировать, у человека должно быть свободное время. Ты не можешь просто подойти сзади, постучать ему по плечу. Было просто адски сложно для меня в самом начале. И это был март.
И как раз я тогда в Амазоне начал просто сильно очень выгорать. В апреле запустили последний версий продукт, который я делал. И все, в июне я уже ушел. Я просто не мог работать в этой среде. Несмотря на то, что я все знал, у меня был полностью контекст. Уровень стресса у меня повысился в несколько раз.
с начала локдауна. Проблема была в Амазоне в том, что это все только началось, и там менеджмент был не особо понимающий проблемы. Проблема была больше не в том, что люди работали из дома, а в том, что у половины людей есть маленькие дети, у которых закрылись школы. закрылись детские сады. У меня жена не работает, но у меня два детей, я думаю, было меньше трех лет. У кого-то оба
Супруга работает, и у них еще маленькие дети, у которых закрылась школа. Это был просто коллаб всей рабочей системы. Для меня это было просто выживание. Поэтому первые месяцы были очень сложные. Когда я пришел в Google, уже было понимание того, что это новая реальность, как выясняется уже на следующий год.
К этому нужно просто подстраиваться. Я выставил определенные процессы дома, чтобы меня их меньше мешали, но все равно было очень сложно. Если говорить конкретно про рабочие процессы, Google это такая компания, у которых много места где люди взаимодействуют друг с другом. Это очень коридорная культура, скажем так. То есть люди постоянно взаимодействуют, постоянно что-то рисуют на досках, вся эта бесплатная еда, кофе. Я все сделаю для того, чтобы люди могли...
Пойдем кофе попьем и заодно это что-то обсудить в комфортной атмосфере. Потому что идеи берутся именно из разговоров, из обсуждений. Для Google это был очень большой шок, потому что Google вообще не разрешал работать из дома. А тут все стали работать из дома. Были все технологии для того, чтобы это делать. Была полноценная инфраструктура.
Но это просто было очень сложно для людей. Что поменялось сильно, это стало больше формальных митингов. Если раньше ты мог просто подойти к дизайнеру, или дизайнер мог тебе подойти. Инженера тоже взяли с соседнего стула и пошли с ними втроем к доске. За 15 минут все обсудили. Все получили, что им нужно.
все довольны и еще эмоционально получили какой-то заряд от этого. А в новой реальности дизайнеру есть вопрос и ему нужно было задать где-то в чате. А когда ты пишешь текстом, ты не всегда можешь объяснить хорошо то, что тебе нужно, особенно если проблема такая расслучатая. Ты потратишь больше времени на объяснение текстом, чем
на то, чтобы это сказать словами и, собственно, и обсудить. И ты хочешь поговорить с людьми, ты начинаешь смотреть в их календарь, они заняты, у всех куча митингов, и в следующий раз, когда ты можешь встретиться, в общем, сейчас, не знаю, понедельник, у людей свободное время только в четверг. И тебе нужна либо...
писать им, типа, мне нужно встретиться, мы же встретимся. Сегодня, чуть позже, людям нужно переделать свои календари. И получается много пустой работы по организации времени. Система календарей так устроена, что митинги, в принципе, меньше полчаса обычно не делают. Потому что по умолчанию это полчаса, 15 минут, как бы ни туда, ни сюда.
И ты выдергиваешь людей на полчаса из того, чем они занимаются в этот митинг, хотя у тебя вопросов может быть только на 10 минут. И ты начинаешь думать, раз уж мы с ними встречаемся, обсудим что-нибудь еще, то у тебя получается огромная адженда. И если работа в коридорах более agile, то есть когда ты просто делаешь то, что нужно, когда нужно, то эта работа с календарями больше как водопадная система, когда тебе нужно много больше планировать.
Это очень сильно усложняет работу, особенно на поле новых продуктов, новых проектах, где тебе нужно реально какие-то идеи обсуждать. Становишься заложником этих рамок календарных. Да, это сложно. Конкретно с дизайнерами у нас в Гугле такая система, что... организационная система. Что у нас остальная команда разработки находится в Сиатле для нашего продукта. Часть команды находится в Сан-Франциско. И...
команда, которая занимается непосредственно пользовательским интерфейсом, то есть именно инженерная команда, которая занимается созданием UI. Она находится в Варшаве, в Польше. И раз в неделю мы встречаемся на митинг, в котором иногда бывает по 15 человек, в котором участвуют
все дизайнеры Сан-Франциско, пара человек из Варшавы. Они участвуют в очень позднее для себя время, это уже очень неудобно для них. И несколько человек из Seattle, то есть все продакт-менеджеры и разработчики, которым нужно там быть. Вот мы в течение полчаса, у нас есть Google Docs,
Это, кстати, вот такая тема распространена в митингах в Google. Есть Google Doc, где собираются заметки с каждого из митингов. То есть это Google Doc, он добавлен в календарь. То есть у каждого мероприятия, у каждого ивента есть документ, в котором люди могут печатать. То, что они обсуждают. И особенно у митингов, которые повторяющиеся. Каждую неделю мы встречаемся на эту синхронизацию. Один и тот же документ мы используем. И перед митингом все добавляют
что они хотят обсудить. Обычный формат такой, что набирает свое имя и то, что они хотят обсудить. И потом уже на митинге они это проговаривают, это идет обсуждение и документируется какое-то решение или какие-то ссылки. То, что нужно потом для будущего, это документируется в документе. И это для меня был прямо такой вот вау-эксперинс.
в Гугле. Вот эти инструменты для работы в реальном времени, когда 10 человек одновременно могут что-то печатать в документе, все это сохраняется, все это можно потом использовать, это можно отправить другим людям. И в Гугле, кстати, культура такая, что документы все очень открыты, то есть я могу получить доступ практически к любому документу.
Единственное, две вещи, которые Google охраняет очень сильно, это пользовательская информация. Чтобы получить данные какому-нибудь пользователю, к их использованию, это нужно пройти просто какое-то нереальное количество.
этих одобрений. Это информация, которую люди доверяют Google. И Google, по сути, обещает, что эту информацию никто не будет трогать, даже сотрудники. То есть ты можешь делать какие-то агрегатные вещи, но ты не можешь посмотреть, что Марат делал в Gmail вчера в 7 часов вечера. Если ты смог получить доступ туда, есть проблема в системах.
ограничение доступа, и Google ее сразу же исправит. А если ты, допустим, работаешь так, что ты смог получить доступ туда каким-то нечистыми путями, то завтра ты уже в компании работать не будешь. То есть это очень важно. И вторая вещь, которую Google охраняет, это финансовые данные. А все остальное, есть куча документов, есть куча сайтов внутренних, где ты можешь посмотреть, на чем работают другие команды. Я могу посмотреть цели любого другого сотрудника в компании.
В этом плане это очень сильно упрощает работу на удаленке, потому что у Google изначально была такая культура, что все открыто. И в каких-то моментах, допустим, если я хочу спросить, чем человек занимается, мне не обязательно с ним разговаривать. Я могу просто зайти и посмотреть, что он на самом деле делает. За счет вот этой открытости ты можешь планировать как продукт.
свою деятельность, знать кто что делает, кого ты можешь себе в команду позвать или не можешь и так далее. То есть это получается общая база того, где ты видишь всех и все видят тебя причем. Мне сначала было некомфортно, потому что я не привык к такому, что Все-все видят. А потом начинаешь к этому привыкать, и это еще очень хорошо помогает в создании культуры, компании, культуры команд, потому что в гугле хав.
В Google очень мало процессов. Есть процесс, но процесс в основном на высоком уровне. Допустим, чтобы что-то запустить, ты должен делать определенные легальные вещи, юридические, маркетинг и так далее. Но в том, как ты делаешь свою работу, процессов вообще нет. То есть ты сам, по сути, эти процессы определяются...
команда, где ты работаешь, там того и лично. И такая открытость, она помогает обеспечить такой, может быть, негласный контроль, что люди все-таки делают то, что они должны делать, потому что все это прозрачно. То есть тебя никто не контролирует за счет того, что все открыто, все на виду. Ты знаешь, как в спорте, в футбольной команде. Все видят, как играют другие игроки.
что-то лажать или не делать, не пинать мяч, как нужно. Тебе сразу об этом скажут. И здесь то же самое. Потому что это все на виду, ты стараешься больше. И это, мне кажется, такой вот Такая пассивная форма контроля, наверное, она очень хорошо работает для поддержания культуры. И опять же, ты не будешь писать каких-то плохих вещей. Есть даже где-то в комнате с тренингов, вы говорите, что все, что вы напишите в e-mail или в чате, пишите с таким пониманием.
что это может быть со скриншотина и сделано публичным. Поэтому в гугле я вообще не вижу обсуждения людей за глаза в письменном виде, потому что это просто сразу же может всплыть. Нет агрессии в чатах, в e-mail, потому что, опять же, да, в любой момент в этот e-mail могут быть добавлены другие люди. В этом плане прозрачность, она, конечно, помогает. Мне кажется, в гугле, в локдауне она очень сильно помогла. И если сравнить вот эту систему практически абсолютного хаоса,
с тем, что было в Амазон? Насколько там все более четко и как ты можешь сравнить, где, на твой взгляд, комфортнее и что, на твой взгляд, более удобно? Если это, конечно, корректное сравнение. В Амазоне очень много свободы в том, как ты делаешь свою работу, но при этом есть
определенные вещи, которые ты должен делать. Это то, чего в Google нет. Я могу привести два примера. Один с продукта, другой с разработки. Создание продуктов в Амазоне начинается с того, что ты пишешь пресс-релиз, как будто бы если ты этот продукт запускаешь на рынок. И 5 страниц, обычно это 5 страниц,
FAQ, то есть вопросы, которые тебе могут задать пользователи, вопросы, которые тебе могут задать какие-то внутренние стейхолдеры. И этот документ потом ты обсуждаешь своими коллегами с инженерами с дизайнерами потом идет на уровень выше и выше и выше и выше и выше и выше в зависимости от того какая у тебя фича запускаешь фича это может пойти на один или два уровня выше если запускаешь одного продукта это может пойти на уровень seo
этого подразделения. То есть я четыре раза презентовал продукт AWS Chatbot, который я создал. Эдди Джасси — это CEO облачного бизнеса. Он в скором времени станет CEO всего Амазона. Судебный процесс в том, что создавая этот документ, описывая требования, описывая стратегию, на каждом этом этапе у людей более широкая картина мира и больше опыта. Люди реально очень умные на высоких позициях. И каждый раз тебе куча...
чего тебе нужно дорабатывать. И ты, получается, с каждым этим шагом все больше и больше дорабатываешь, делаешь свою идею более явно выраженной, ты больше понимаешь ее, у тебя больше глубины. В итоге, когда ты прошел этот процесс, он занимает, можно занять на месяца три спокойно. от идеи до того, как ты получил одобрение. У тебя документ, который кристально ясно написывает то, что тебе нужно делать?
А потом ты уже свободен делать все, что ты хочешь. Есть определенные процессы, но в целом вот этот процесс определения продукта, он форсирует глубину мысли. Второй процесс в Амазоне, который очень крутой, я считаю, это для всех разработчиков. Это не во всем Амазоне, это в AWS, в облачном бизнесе. Облачный бизнес очень высоко ценит аптайм, как это называется. Настолько продукты стабильны и не падают.
То есть, условно говоря, у тебя 99,9999% и остальные продукты должны быть доступны для пользователей. И если ты падаешь на одну десятитысячную или сотысячную, я уже запутался в этих цифрах. то это проблема. И для того, чтобы такого размышления внедрить во все команды, то есть есть такой механизм. Во-первых, в Амазоне вся команда, это команда DevOps, У тебя, условно говоря, 10 человек, которые работают на какой-то фичи, они отвечают за какой-то конкретный сервис.
сервис, набор фич, набор продуктов, и они за него отвечают целиком. То есть они сами отвечают за инфраструктуру, за все метрики, они несут за него ответственность. И это подход, который они называют, you build it, you run it. То есть ты его построил, ты им управляешь. И суть в том, что Все, что ты делаешь, если ты сделаешь что-то криво, то вся боль ложится на тебя. Ты создаешь проблемы для самого себя. Таким образом, это мотивирует людей делать вещи правильно на долгосрочную перспективу.
Потому что даже если ты сам, допустим, хочешь через полгода, допустим, уйти за этой командой, но другие люди, возможно, не хотят, они тебе просто не дадут сделать. Это плохо. Потому что это очень такое долгосрочное мышление. Это внедряет. Каждую среду в AWS собирается огромное количество людей, больше ста человек. Каждый технический директор, каждый технический вец-президент
Он должен быть там, либо отправить кого-то из своей команды, плюс все менеджеры разработки там. Разбираются все инциденты за предыдущую неделю операционные. То есть, если где-то что-то упало, это все разбирается. И председатель этого митинга – это чувак. Он старший вице-президент, который отвечает за весь продукт. Он очень строгий, но справедливый, я так сказал. С ним очень сложно бывает. То есть он как бы просто...
задаст тебе такие вопросы, на которые, знаешь, ты можешь просто потеряться. Поэтому это требует очень большой подготовки к этому митингу, особенно если у тебя была какая-то проблема. Если выясняется, что у тебя система упала, точнее, если у тебя система упала больше, чем на какое-то определенное количество статпоинтов, и если и это повлияло на пользователей, ты обязан написать документ, который описывает прямо
по минутам все, что произошло, какие были действия приняты, где были какие-то системные ошибки и что ты можешь сделать для того, чтобы автоматизировать эту проблему. И эти документы потом проверяются тоже на многих разных уровнях. И благодаря им команды, по сути, заставляют оптоматизировать ручной труд. И это происходит на уровне всей системы, всей компании в целом. Этот процесс, он со стороны выглядит жестким, но его...
цель, его направленность в том, чтобы реально сделать компанию лучше. И поэтому Амазон, я просто, несмотря на то, что я ушел из компании, я безмерно вообще их уважаю как компанию, как строители организаций, потому что они прямо умеют создать эти механизмы, эти структуры для того, чтобы все работало прям как... Очень часто повторяющий вопрос и от моих учеников, и от моих подписчиков условно, что бы ты посоветовал дизайнеру?
чтобы сейчас он начал делать, учить, во что должен он погружаться, чтобы он стал хорошим кандидатом для того же Google, например, либо Amazon. Что нужно делать дизайнеру, чтобы развиваться и быть готовым, подготовиться для работы в Google? Нужно изучать принципы. Нужно как можно больше искать принципы дизайна, читать про них. изучать их и внедрять их в повседневной жизни. Знать, в принципе, недостаточно. Важно их видеть, смотреть на что-то. У меня недавно была
серия stories. Есть такие принципы Грайса или Максим Грайса про информацию. Информация должна быть в правильном количестве, в правильном качестве. Это буквально четыре предложения. Но имея это у себя на подкорке, глядя, допустим, на текст, в интерфейсе, ты можешь оценить, насколько то, что ты сделал, соответствует, и то, что другой сделал, соответствует этим принципам. Потому что эти принципы, они...
очень простые, но они толкают тебя в правильное направление. И если ты где-то не соответствуешь каким-то принципам, то ты должен себя спросить, почему. То есть это есть объективная причина, или это где-то моя лень просто. Я, не знаю, недостаточно хорошо в чем-то разбираюсь, мне нужно в чем-то больше разобраться.
Плюс книга Дона Нормана, про которую я говорил. Дизайн повседневных вещей. Он тоже раскладывает все на принципы. И эти принципы применимы ко всему. И то, что я делаю, да, то есть я... Принципы это вообще моя тема, да. То есть я люблю принципы во всех направлениях. Я про них читаю. стараюсь их искать в мире. То есть, идешь на улицу, увидел вывеску, и у тебя глаза как бы цепляются, да, ты... начинаешь анализировать с точки зрения принципов.
Это формирует такую насмотренность. Насмотренность не то, что работает, а именно насмотренность на неправильное слово. Формирует привычку. Формирует привычку, везде видеть принципы, видеть вот это. то, что находится за внешним видом. Этим отличаются дизайнеры в топовых компаниях, может быть, от людей, которые не могут попасть, пробуют, но не могут. Это именно возможность видеть, способность видеть то, что находится за пределами того, что видит класс. И, к сожалению, здесь это очень сложно.
То есть это не то, что я этим могу дать список, да, вот эти 10 вещей ты должен делать. То есть, в принципе, это такая постоянная работа над собой, над ясностью своего мышления. И тут очень важно тоже не загнать себя в какие-то шаблоны этих принципов. То есть нужно именно вот... как-то уметь их использовать, при этом не мысльно-шаблонно. Поэтому очень важно читать. Я считаю, важно в целом
Внимать в себя как можно больше примеров, информации из других смежных отраслей. Допустим, почитать про продакт-менеджмент. Потому что продакт-менеджмент даст тебе понимание стратегии, понимание пользователя, как мыслят продукты. То есть можно почитать что-то про разработку, какие-то, может быть, высокого уровня вещи. это даст тебе понять
как мысли твои стейхолдеры-разработчики. В целом, понимание, на этом строится фундамент твоего успеха в большой корпорации. И плюс хардскиллы. Но хардскиллы нужно всегда развивать. учиться чему-то новому, проходить курсы. Сейчас, кстати, стал очень много курсов. Я не знаю, у тебя есть курсы или нет. Но много очень я вижу курсов на Инстаграме от людей. Мне даже сложно сказать, профессионалы они, в самом деле, или нет. И насколько они хорошо... владеть тем, о чем они рассказывают.
насколько это правильно. Поэтому я ни разу не брал курсы из Инстаграма сам лично. И всегда стараюсь, если я беру какой-то курс, то обычно этот курс стоит денег. И он, в смысле нормальный день, и он, его ведет кто-нибудь очень продвинутый. Кто-то, у кого же есть имя в индустрии. И от них можно много больше научиться.
Кстати, вот тоже очень хороший момент в этом плане. Нужно учить английский язык, потому что очень много видео на YouTube, где люди рассказывают какие-то вещи на конференциях, на каких-то презентациях. Google очень много публикует видео со своих внутренних мероприятий на YouTube, где можно послушать людей, например, здесь чувак,
Люк Вороблевский. Он директор по дизайну в Гугле, и он придумал термин mobile first, когда ты начинаешь разрабатывать приложение с телефона, а не с того, как пользователь будет с компьютера с ними взаимодействовать. И я видел несколько видео. Презентации. Чувак прямо очень круто объясняет. принципы и, например, всегда раскладывает и объясняет, как было бы лучше сделать. Каждый раз, когда я его смотрю, знаешь, когда нужно
ставить на паузу, думать немножко, а потом идти дальше, потому что он прямо нереально короткий. И такие видео, они, естественно, на русский переведены, большинство из них не будут, они доступны только на английском языке. И в целом, Мне про дизайн сложно сказать, но если говорить про продакт-менеджмент, если говорить про разработку, то на моем опыте то, что я вижу на русском языке, оно отстает на несколько лет.
от того, что происходит в долине. Ну и, собственно, вся Америка. Остальное тоже отстоит несколько лет от долины. Но в Америке проще, потому что там все на одном языке. То есть человек, условно, играет с какого-нибудь Канзаса, может почитать то, что пишет человек из Гугла и это начать использовать. Время, как человек... из России, если он не знает английского языка, то он себя, по сути, отталкивает несколько лет, ожидая что-то другое, для него это переведет.
опубликует и каким образом ты должен эту информацию найти. То есть, получается, воспринимаешь информацию через фильтр того, что тебе дают. Фильтр конкретного человека, конкретных людей. И это очень такая плохая позиция на самом деле. То есть лучше всегда искать информацию в первоисточнике. И для этого язык, я считаю, это просто фундаментальный скилл, который нужен любому специалисту.
Спасибо, что дослушали до конца интервью. Если у вас есть какие-то мысли по поводу того, как сделать подкаст лучше, пожалуйста, напишите мне в инстаграме. Я отвечаю на все сообщения в директе. Мне будет очень важно услышать, что вам понравилось.
что вам не понравилось, где-то что-то можно улучшить, где чего-то можно добавить, чего-то можно сделать больше, подкидывайте интересные темы. Если у вас интересные есть гости, с которыми вы бы хотели, чтобы я поговорил, пожалуйста, отправляйте мне все это в Инстаграме в Директор.
Я буду очень рад от всех вас слышать. Ну и не забывайте подписываться на меня, Илья.Безелев в Инстаграме, а также на Марата, М.Достарбеков, тоже в Инстаграме. Также для подкастов, особенно для молодых, очень важные отзывы. Поэтому, пожалуйста, не поделитесь, поставьте оценку. И если хотите, напишите что-нибудь хорошее в комментариях. Я буду очень вам за это благодарен. Все, всем спасибо, пока. До следующих выпусков.