Привет! Ты слушаешь первый выпуск подкаста IT Самурай, и я его ведущий Илья Бездилев.
Как выяснилось, самое сложное при записи подкаста — это говорить без выражения,
потому что когда говоришь с выражением, начинаешь звучать как робот.
Поэтому для первого выпуска подкаста я пошел на небольшой лайфхак.
Я пришел в гости на эфир в Инстаграме к дизайнеру Марату Дестербекову.
Мы поговорили на разные темы, в основном про дизайн и про то,
как строится работа в командах в компаниях Google и Amazon, где я работал.
Формат интервью помог мне быть очень непринужденным и расслабленным.
И вы это заметите по тому, с какой скоростью я разговариваю.
Поэтому это не тот подкаст, который вы будете слушать на скорости 1,5х или 2х.
Ставьте воспроизведение в нормальном режиме или можете даже немножко замедлить.
Не буду вас больше задерживать.
Одевайте наушники, идите на прогулку, начинайте мыть посуду, садитесь в машину, чем вы там занимаетесь.
И надеюсь, этот эпизод будет вам полезен.
Первое, о чем я тебя спрошу, это, во-первых, представься для тех, кто тебя видит впервые,
объясни, кто ты, где ты работаешь и почему, в принципе, мы тебя позвали, и почему мы тебя слушаем.
Меня зовут Илья Безделев.
Я работаю сейчас в Google, в Google Cloud на позиции продакт-менеджера.
В Google же работаю почти год.
До этого я работал 5 лет в Амазоне.
Я пришел на позицию синир продакт-менеджера, потом пару лет руководил командой разработки,
потом обратно ушел в продакт, запустил продукт AWS Chatbot с нуля от идеи.
Собственно, я руководил командой разработки, и мы с этой командой запустили новый продукт.
Потом я выгорел, ушел в Google. До этого получил MBA в Америке в бизнес-школе Worden.
До этого еще 8 лет работал в компании DHL, в основном на позиции, связанные с анализом данных.
Очень много переезжал, жил в 5 странах, в 8 или даже 9 городах.
В общем, у меня такая жизнь не очень линейная.
По образованию я программист. Я работал программистом, работал фрилансером, была своя компания,
работал на других людей.
Но это было все очень давно, еще когда в универе учился.
Я слушал, кстати, подкаст «Уехавший», да-да-да.
И там ты рассказывал, что ты учился на программиста, связанного именно с экономикой, да?
Специальность называлась «Перекладная информатика в экономике».
Чтобы ты понимал, это был 2000 год.
Большинство людей еще не знало про интернет, или там что-то про него слышало.
Это было что-то такое далекое.
Это как сейчас, наверное, знаешь, какой-нибудь искусственный интеллект,
или виртуальная реальность, или AR.
То есть люди знают, что это что-то где-то существует,
но они это не понимают, большинство людей.
Так же было с интернетом в те годы.
Вот эта специальность, она была построена на базе математического факультета.
Все люди, которые там преподавали, это были такие профессора старой закалки,
которые там разбираются дискретно в математике, в статистике, в теории вероятностей.
И поэтому учили нас, по большей части, на самом деле, математике,
немножко программированию, ну, немножко экономике.
И многие, кстати, спрашивали по поводу того, на кого бы ты советовал сейчас,
вот если бы ты сейчас начинал и хотел бы прийти вот туда, где ты сейчас находишься,
куда ты бы посоветовал поступить, учиться,
либо советовал бы ты поступать в университет,
либо ты советовал именно начинать с практики?
Вот твое мнение.
Да, такой сложный вопрос, на самом деле, я часто получаю его от родителей,
подростков, например, такие приходят вопросы.
И тут дети, ну, назовем подростков детьми,
они еще не знают, чего они хотят.
В моем случае у меня был компьютер, я занимался веб-дизайном в свободное время,
программировал, я знал, что все, я вот, я одержим технологиями,
я хочу пойти вот учиться на технологии.
И вот этот факультет, он был один из двух факультетов в городе,
который ты предлагал, где-то трех факультетов, может быть, в городе.
Ну, мне здесь понравилось, я туда пошел учиться.
Сейчас у многих молодых ребят нету стремления, нету понимания, что они хотят делать.
Я считаю, что важно идти туда, где-либо тебя прет.
Если тебе вот реально нравится, там, не знаю, работать с компьютерами,
программировать, если ты уже занимаешься программированием,
иди туда, где тебя этому научат еще лучше.
И если ты не знаешь, чего делать, с этим, мне кажется, сложнее,
потому что ты можешь пойти учиться на то же самое программирование,
а потом в этом полностью разочароваться,
и у тебя будет специальность, которая дала тебе кучу хардскиллов,
которые ты не умеешь применять или не хочешь применять,
от которых ты выгораешь и так далее.
Это, на самом деле, очень сложный вопрос.
Я знаю, что в Америке, кто учится, именно ребята 18 лет,
которые приходят на учебу, здесь система немножко другая.
Здесь ты поступаешь в колледж, и ты не выбираешь специальность заранее.
Ты пару лет учишься всему подряд, то есть, там, изучаешь психологию,
ой, не психологию, психологию, философию, историю, там, математику, еще что-то.
То есть, полный набор общих предметов.
После чего ты начинаешь потихонечку брать дополнительные какие-то курсы,
которые ты уже выбираешь там из каталога, и ты начинаешь специализироваться.
Условно говоря, где-то годом 20, после того, как ты уже пару лет побыл в университете,
у тебя же складывается какое-то впечатление, ты уже что-то попробовал,
ты уже можешь более правильно выбрать профессию.
Я думаю, все равно можно ошибиться, конечно, даже при таком подходе,
но при нем ошибиться значительно сложнее, потому что ты уже все-таки немножко знаешь,
что ты делаешь.
Тем, ребятам, у кого есть возможность поехать, учиться в заграничную систему,
ну, я бы, скажем, советовал, наверное, сделать это, если у вас есть возможность.
Если есть, не знаю, если вы прошли через этот процесс, если вы поступили,
если есть деньги, если получили какой-то грант, это очень крутая система.
Если выбирать приходится, ну, условно говоря, в своем родном городе,
тут, наверное, два подхода, да, то есть, либо тебя точно пррет от чего-то,
ты идешь туда учиться, либо ты идешь туда, где у тебя больше шансов заработать деньги, наверное.
И тут, если у тебя хорошо с математикой, с логикой, со структурой,
то программирование, конечно, это такая специальность,
которой по деньгам сейчас не прогадаешь.
Из-за этого вытекал часто такой еще вопрос по поводу образования.
В принципе, вот такие крупные компании, как Google, Facebook, там, Amazon,
в которой ты работал, насколько важно, в принципе, им именно образование
в плане, ну, теплом?
Либо они могут взять тебя, если у тебя просто вот ноль образования,
но есть опыт, например. Есть такие прецеденты, либо для них это принципиально?
Образование влияет в зависимости от того, где ты находишься в своей стадии карьеры, да?
Если тебе, условно говоря, 22 года, то есть свежий выпускник,
такие ребята приходят, многие, напрямую в Google или в Amazon после колледжа,
то есть на самой начальной позиции, допустим, программистами.
И их там уже всему обучают, то есть первые пару лет они что-то,
какую-то пользу приносят, но они приносят пользу совершенно незазмеримым деньгам,
которые им платят.
Их учат на будущее, на то, чтобы они учились и становились эффективными,
в итоге выросли для сеньеров и так далее.
У них очень много пробелов, которые нужно получить только на практике.
Но у них есть очень серьезные интеллектуальные способности и скиллы
именно вот сесть и что-то заходить, именно вот алгоритмическое.
Тут образование очень важно, потому что, если ты учишься на программиста 4-5 лет,
то тебя натаскивают по этим всем делам.
Поэтому образование важно, когда ты в самом начале своей карьеры.
То есть, если ты прошел буткемп, ну, шансов попасть в Google или в Amazon практически нет.
Если ты не какой-то там, не знаю, работал по 20 часов в день
и занимался еще алгоритмами и получил эквивалент половины школьного образования.
И если ты приходишь уже, скажем, более позже, да,
когда ты не совсем еще молодой, у тебя уже есть какой-то опыт за плечами,
может быть, ты вообще не учился в университете,
но ты много занимался сам, работал где-то, был программистом, был дизайнером,
у тебя крутое портфолио, у тебя крутые комменации,
тебе есть что показать, ты круто решаешь задачи на собеседовании,
то у тебя все шансы попасть и тебя возьмут.
И когда смотрят, когда мне приходят резюме, я их смотрю,
потому что в этих компаниях собеседуют все, собеседуют не HR.
Мне приходится привыкать к этому, как в России про это говорят.
HR в этих компаниях отвечает за зарплаты, за отпуска, за политики,
но за найм отвечают рекрутеры.
Это специальность отдельная от HR.
Их задача в том, чтобы найти кандидатов,
продать им только классно работать в компании
и потом направить уже их в команду, а собеседует уже команда.
То есть все собеседования, которые ты проходишь,
это собеседование с людьми, которые выполняют ту же функцию, что это.
И они уже могут принять решение о твоем нами.
Рекрутеры, они не принимают участие в принятии решения.
И для меня вот это был такой разрыв шаблона,
когда я общался с парой рекрутеров в России.
И говоря про образование, то есть когда ты приходишь,
уже опытный, смотрит на опыт.
Если у тебя нет совсем образования,
это будет больше вызывать вопросы.
Со мной работал парень, он был синером,
ну и сейчас до сих пор синер в Амазоне,
очень крутой, хорошей траектории.
Он учился на, ну что-то вроде гражданского строительства в Индии.
То есть совершенно не компьютерная специальность.
И он где-то в середине своей учебы
начал на учебу немножко забивать и учиться программировать.
И ему так прямо зашло, что он начал работать, там фрилансить.
Потом устроился на работу куда-то.
При годах, может быть, ну и 26-27,
он попал в Амазон без образования в программировании.
Но сейчас он, ну, один из самых крутых программистов,
с которым я работал.
И у него нет профильного образования.
Поэтому, как бы, образование не является таким фактором,
который тебя ограничит.
Но тебе нужно обладать эквивалентным набором знаний,
которые получить значительно сложнее,
если ты, ну, не учишься в программировании.
В колледже, в университете тебя именно натаскивают по алгоритмам.
А алгоритмы, они такая штука,
которую изучать очень стрёмно и неинтересно.
Поэтому не у каждого хватит терпения, чтобы это делать.
Потому что тут еще важно понимать, что когда ты пишешь,
особенно когда ты начинаешь только,
то, что ты пишешь, создаешь там сайты, какие-то веб-приложения,
ты практически не используешь алгоритмы в том смысле,
в котором они нужны в большой компаниях.
Ты там, может, сделал какие-то формочки,
какую-то интеракцию с каким-то API.
Это все такая бизнес-логика, которую...
Ее несложно написать, нужно просто знать, как работает язык.
Когда мы говорим про алгоритмы, которые спрашивают на собеседовании,
тебя, условно говоря, попросят, допустим, написать
или улучшить алгоритм сортировки или что-то такое.
Будут вопросы по системному дизайну, например.
Ну, я любил спрашивать, когда в Амазоне работал,
допустим, за дизайн мне систему проверки и оплаты парковочных билетов на парковке.
То есть, когда ты приезжаешь, вот срежешь карточку в паркомат,
для маленького уровня ты начинаешь с того, что...
Ну, то есть, как устроена система,
какие у нее должны быть интерфейсы,
как она должна писать базу данных и так далее.
Это, в принципе, могут справиться многие.
Потом ты начинаешь усложнять.
Что, если у тебя отвалилась связь?
Что, если у тебя несколько этих шлагбаумов?
Как они должны между собой синхронизироваться?
И так далее.
Ты начинаешь как бы усложнять, усложнять, усложнять,
пока это все не переходит в задачу про распределенную систему.
И таким образом уже определяется уровень человека.
И также смотришь, насколько человек мыслит за пределы задач,
которые ему дали.
То есть, насколько он думает про UX,
насколько он думает про время ожидания,
про очереди, которые скапливаются.
Я к чему это сейчас говорю, да?
Что очень важно в этих компаниях
обладать еще не только техническими навыками
и умением решать задачи, именно из книжек,
но обладать этим общим кругозором
и пониманием бизнес-проблемы за пределами того,
что непосредственно ты делаешь, склоняя голову над компьютером.
Я здесь восстановлюсь, потому что я очень много уже сказал.
Ты упомянул две вещи.
Во-первых, ты сказал, что рекрутируют все,
вся команда.
Ну, не рекрутируют, а собеседуют.
Собеседуют.
А во-вторых, ты сказал, что программисты,
вот сейчас ты упомянул недавно,
что они тоже занимаются UX,
думают о нем в том числе.
Во-первых, у меня два вопроса сразу войдут.
Первый.
Это как вообще вы рекрутируете и собеседуете UX-дизайнеров?
Ну, или, в принципе, дизайнеров?
То есть ты лично как-то все проходила?
Что ты от них ждешь, что ты требуешь?
Ну, и потом я задам второй вопрос.
Я в Гугле дизайнеров не собеседовал.
Я собеседовал в Амазоне несколько человек.
Тоже, наверное, поясню немножко процесс,
чтобы было более понятно,
почему продакт-менеджер был на собеседовании у дизайнеров.
Процесс проходит таким образом.
То есть рекрутер находит кандидата.
То есть кандидат, может быть, подается,
или его находит,
его кто-то делает ему реферал,
направляет его в компанию.
Или, может быть, это из университета кто-то приходит.
Рекрутер с ним разговаривает,
настраивает весь процесс.
И сначала идет телефонный скрин.
Ну, его так называют,
хотя сейчас все проходит через видео.
Это первое телефонное собеседование,
на котором, честно говоря,
у дизайнеров я не знаю, что спрашивают,
но суть первого телефонного звонка
это в том, чтобы отсечь
заведомо плохих кандидатов.
То есть если ты общаешься с человеком,
ты понимаешь, что он вообще ничего не знает.
И ты не хочешь тратить время шести человек
на то, чтобы удачу собеседовать.
То есть это вот чисто вот такой фильтр,
вот такой очень грубый фильтр
для того, чтобы просто не допустить
совсем плохих кандидатов.
Потом следующий этап,
это так называемый on-site.
То есть в былые времена люди приходили,
им покупали билет,
они прилетали к тебе в офис
и их собеседовали лично.
Сейчас все происходит удаленно через видео.
Это порядка пяти-шести интервью
по 45-60 минут друг за другом.
То есть это занимает целый день.
Когда ты проходил в офисе,
люди еще подели на ланч,
то есть реально ты приезжаешь,
в 9 часов у тебя начинается,
ты заканчиваешь часа в 3 вечера
весь измотанный.
Для интервью назначают людей,
которые проверяют определенные
важные для компании срезы.
Если говорить про Амазон,
у Амазона есть лидерские принципы.
Это 14 лидерских принципов,
которые определяют культуру компании.
И у каждого из себеседующих
есть задача проверить,
насколько человек соответствует
наиболее важным лидерским принципам.
То есть каждому даются, допустим,
по два лидерских принципа,
и в итоге 5 человек проверяют 10 принципов.
То есть это вопросы из серии
«Расскажи мне, как ты работаешь с конфликтом.
Расскажи мне, допустим,
у тебя была задача,
в которой было невозможно
решить, что ты с ней сделал».
То есть это интервью больше
не техническое,
не в плане хардскиллов.
Это интервью больше на твою
рабочую этику
и на твои софтскиллы,
на то, как ты умеешь работать
с людьми и так далее.
Это обязательно часть любого интервью
и каждого человека,
который собеседует.
Вторая половина интервью
каждого из себеседований
это проверка каких-то технических скиллов.
С дизайнерами
я знаю, что Amazon делал
ревью портфолио.
Ты как кандидат
собираешь портфолио,
тебе говорят о том,
что они ищут.
То есть 5G компании, да,
они не скрывают,
что они ищут.
Они говорят,
для того, чтобы быть успешным
дизайнером в Амазоне,
тебе нужно обладать
тем-то, тем-то и тем-то.
И это то, что мы будем спрашивать.
И они хотят,
чтобы ты заранее подготовился,
чтобы ты мог себя
хорошо презентовать.
Потому что их задача
найти хорошего специалиста,
не быть сервером
на вратах компании.
И у многих кандидатов
на самом деле
вот это ощущение,
у меня само было такое ощущение,
особенно приезжая из России,
что вот эти люди,
они хотят меня
как бы не пустить.
На самом деле,
они хотят тебя пустить,
но они хотят пустить тебя
только в том случае,
если ты соответствуешь
их требованиям.
Для того, чтобы лучше
проверить требования,
они заранее как бы
ими делятся,
для того, чтобы ты мог
о них хорошо рассказать
о своем опыте.
И портфолио-ревью,
насколько я знаю,
это ты показываешь,
что ты делал,
или ты выбираешь
какой проект,
не подошел,
какой был процесс
поиска этого решения,
какие принципы ты использовал,
как ты работал
с другими стейхолтерами,
как ты работал с продуктом,
как ты работал с инженерами,
с другими командами,
если нужно.
Ну и, соответственно,
что вышло в итоге, да?
Что вышло в итоге,
это показывает,
насколько то,
что ты делал,
к какому результату
это привело.
На самом деле,
результат, он в этом плане
даже менее важный,
чем процесс.
То есть результат,
он, знаешь,
это верхушка айсберга.
Вот, так выходит
ваш портфолио-ревью.
Минут 30-40
тебя спрашивают
по этому проекту,
уходят вглубь.
И Амазон очень известен тем,
что в Амазоне
интервью очень-очень глубокие.
То есть тебе могут
задать один вопрос,
и этот вопрос будет вопрос,
который ты хочешь отвечать
целый час.
Потому что тебе будет
постоянно идти
глубже, глубже, глубже, глубже.
Цель этого в том,
чтобы убедиться,
что ты как бы
не придумываешь это на ходу,
а на самом деле
делал то,
что ты говоришь, что делал.
Потому что,
когда идут очень глубоко,
ты уже не можешь
придумывать на ходу
какие-то вещи.
Ты уже начнешь как бы
запинаться,
портфолио.
Я делаю только
вопросы по софтскиллам,
по работе с командой.
То есть мне тут важно понять,
насколько этот человек
как бы мыслит правильно
для того,
что мне нужно
для моего продукта.
Мы говорим
про продуктовые команды.
Команды, которые делают
проекты для продуктов,
не для других компаний.
У нас нету
конкретного клиента,
на котором мы работаем.
У нас есть там
тысячи, в каких-то случаях,
миллионы клиентов,
пользователей,
и мы делаем для них продукт.
Один для всех.
То есть есть направление
как бы консюмер,
то есть пользовательские продукты,
обычные люди.
Есть Enterprise.
Это то,
что можно назвать B2B.
Но это не просто B2B,
это B2B для очень
больших корпораций.
То есть условно говоря,
Google Maps
это продукт пользовательский.
Ты зашел,
карты там,
что-то нашел,
посмотрел,
когда бизнес работает,
все закрыл.
Это твой пользовательский
use case.
И Enterprise use case,
это, например,
то, чем я сейчас занимаюсь,
это платформа,
на которой разработчики
из крупных корпораций
запускают свои приложения.
И если я нанимаю
дизайнера на такого
рода продукты,
то есть мне важно,
чтобы он понимал
именно потребности
таких пользователей
то есть мы неожиданно
то, что у человека
есть опыт в интерпрайзе.
Если у человека
есть опыт в пользовательских
приложениях,
он может успешно
справиться в интерпрайзе.
Но не всегда люди
готовы подстроиться
под другой склад,
под другой подход,
наверное, правильно сказать.
То есть когда ты делаешь
пользовательские приложения,
ты можешь поменять дизайн.
Ну, блин, пользователи,
держите вам новый дизайн,
привыкайте к нему.
В то время как в Enterprise,
если ты такое сделаешь,
то тебе придется
какое-нибудь имя использовать.
Грубо говоря,
IKEA, как компания
огромная, да,
и скажет,
ребят, у нас куча тренингов,
которые были завязаны
на видео
из вашего интерфейса.
Вы нам все поломали.
У нас сломались все тренинги,
у нас сломалась вся документация,
у нас стала неэффективная команда
из 800 человек.
И ты такой,
упс.
И помимо IKEA,
к тебе пришло еще
300 таких же, да,
вот крупных корпораций.
На что это влияет, да?
То есть когда ты делаешь дизайн
для продуктов
для таких корпораций,
ты должен очень-очень
глубоко продумывать изменения.
То есть на сколько
эти изменения повлияют
на пользователей.
Действительно ли
то, что ты меняешь,
становится лучше для них.
Ты не можешь делать эксперименты.
То есть если в пользовательском интерфейсе
ты можешь делать
EB-тест
и дать там миллиону пользователю
что-то одно,
10 миллиону что-то другое
и посмотреть,
какие будут метрики.
И люди это схавают,
потому что они
в большинстве случаев
пользуются этим продуктом бесплатно.
В интерпрайсе это просто не работает,
потому что тебе люди платят
миллион долларов,
каждый из них,
и ты должен очень подстраиваться
по то,
как они работают.
У Google была такая проблема,
когда они только заходили в облако
лет, наверное, 10-12 назад.
То есть они подходили к облаку
как к своим остальным продуктам,
как к поиску.
Где ты можешь что-то поменять,
и люди просто дохавают,
потому что у них нет другой выбора.
И это им, скажем, не помогло.
Последние несколько лет
Google очень серьезно
вкладывает, инвестирует
в то, чтобы соответствовать
требованиям корпораций,
в том числе касается и дизайна.
То есть дизайнерам приходится
переучиваться в плане того,
как они мыслят для того,
чтобы работать в облачной среде.
Ты говорил, что программист
на собеседовании
может там начать рассказывать
что-то про UX-дизайн,
и, соответственно, это говорит о том,
что в команде у вас все владеют
какими-то знаниями про UX.
Соответственно, как происходит
работа над UX-дизайном,
если есть UX-дизайнер,
и при этом вся команда
что-то понимает в UX-дизайне.
То есть как распределяются задачи,
за кем последнее слово и так далее.
Программисты не делают UX-дизайн
и не должны делать UX-дизайн.
Программисты PM и UX,
это три функции,
у которых, если ты начинаешь совмещать
то, что они делают,
возникает конфликт интереса.
То, что менее удобно для пользователей,
обычно проще запрограммировать.
Программисты, которые делают UX,
это как лесоприятники,
потому что они могут для себя
делать что-то легче
и могут не хотеть делать что-то
дополнительное для пользователя,
потому что для них это
дополнительная работа.
Вот поэтому это должно быть разделено.
То, что я хотел донести,
суть, это то, что люди должны думать о том,
как их работа влияет на то,
за что они не несут прямую ответственность.
То есть если ты программист,
ты делаешь какую-то API,
этот API используется пользовательским интерфейсом.
И ты должен всегда понимать
все твои зависимости,
которые тебя используют.
И UX это одна их зависимости.
Плюс UX это такая дисциплина,
знаешь, где у всех есть как бы мнение.
Я вспоминаю,
есть такой прикольный комикс,
картинка,
типа, что если бы программисты
были UX дизайнерами?
И там сидит толпа людей в пиджаках,
и стоит программист,
пишет код на доске.
И один из этих людей
в пиджаках говорит ему,
мне кажется,
эту перемену нужно назвать по-другому.
Суть этого в том,
что когда тебе показывают дизайн,
ты интуитивно все равно понимаешь его.
И ты говоришь,
мне синий цвет не нравится,
давайте все используем красный.
У дизайнеров в этом плане
очень сложная работа,
потому что их работа,
она интуитивно понятна другим людям.
И другие люди могут им давать советы,
которые, ну, часто не прощены,
часто не используют правильные принципы,
и они как бы не из того места идут,
скажем,
не из экспертизы.
Как работает дизайн в этих компаниях?
Давай опять же посмотрим, наверное,
на процесс создания продукта
от начала до конца.
То есть все начинается где-то с идеи.
За идею отвечает Product Management.
То есть идея приходит
или от пользователей,
или она может выйти откуда-то сверху,
или от самого Product Manager.
Product Manager начинает ее оформлять
в какой-то документ.
Документы в компаниях разные,
но это какое-то подобие
такого стратегического документа,
в который также включаются
требования продукта в целом.
Не к определенным фичам,
а к продукту в целом
и к фичам, которые будут в первой версии.
На каком-то этапе,
когда уже начинает идея формироваться
в что-то более конкретное,
обычно вовлекается UX
для того, чтобы
по-брейнстормить,
как это вписывается
в другие продукты,
какой может быть интерфейс,
обмен идей,
для того, чтобы
вот этой идеи
в какую-то визуальную форму.
Потому что идеи из визуальной формы
всегда легче продать.
Продать в плане,
то есть ты работаешь в большой компании,
ты не можешь просто взять
и начать делать свою идею,
потому что любая идея
занимает очень много времени
и требует очень больших ресурсов инженерных.
Поэтому идею нужно продать,
чтобы тебе дали на нее ресурсы.
И когда у тебя есть,
грубо говоря,
хорошее видение,
стратегия,
есть UX дизайн,
то это все намного проще.
Первая версия дизайна,
она, как правило,
это просто МОКС,
как правильно назвать по-русски,
грубый дизайн.
Когда я начинал в Амазоне,
было так,
то есть было все нарисовано
в каких-то просто,
может сказать, линиях.
Но за последние годы
очень стала популярна
тема систем дизайна.
И компании,
такие как Амазон,
Google,
Facebook,
у всех есть своя система дизайна,
которая делает
интерфейс унифицированным
по всем их продуктам.
И за счет того,
что есть набор компонентов,
набор паттернов,
набор принципов,
которые они используют.
У этих дизайн-систем
есть интеграция
в Figma,
в Sketch,
в другие приложения,
которые они используют.
Поэтому на самом деле сейчас
даже самые первые
эти наброски дизайна,
они уже выглядят
как законченный продукт.
Потому что дизайн-система
позволяет тебе
вместо того,
чтобы рисовать
какой-то грубый квадратик,
ты просто берешь
и делаешь кнопку так,
как она будет выглядеть
уже на сайте.
И для дизайнера
не требуется никакой
дополнительной работы.
То есть у тебя есть уже
вот эти вот рамки,
в которых ты работаешь
в плане визуального представления.
Кстати,
это тоже важный фактор такой,
когда у тебя есть дизайн-система,
у дизайнера очень мало свободы
в визуальном представлении информации.
Это опять же зависит,
конечно, от компании
и от того,
работаешь ты в пользовательском домене
или в Enterprise.
Я работаю в Enterprise,
то есть у нас у дизайнера
очень мало свободы
в плане того,
как это все выглядит.
То есть есть определенные компоненты,
есть формы,
потому что все портфолио продуктов
должно выглядеть так
для пользователя,
что они видят,
что это продукт
именно от твоей компании.
Если ты посмотришь
на продукты Microsoft,
например, Word, Excel,
PowerPoint,
SQL Server, например,
Windows,
ты понимаешь,
что это продукт Microsoft.
Несмотря на то,
что вы делали сотни разных людей,
это дизайнеры,
потому что они используют
одну и ту же дизайн-систему.
В общем, дизайнер создает
с тобой вместе
вот этот,
как это все будет выглядеть,
и потом в какой-то момент
ты начинаешь вовлекать
инженеров, программистов,
ну, как правило,
это как бы лидов,
которые начинают оценивать,
как эта идея будет разрабатываться,
сколько это будет стоить
в плане инженерных ресурсов,
какая-то же архитектура.
Это вот как работает,
скажем,
Agile Product Development.
У тебя еще нет
законченных требований,
но ты уже работаешь с дизайнером,
ты уже работаешь с разработкой.
Ты как бы вместе
как-то идете вперед,
хотя дизайн еще до конца
не доработан,
инженерные вещи
еще до конца не доработаны,
но они вносят,
я бы сказал,
как дизайн обогащает требования,
потому что он помогает
их более, скажем,
красиво представить
и визуализировать
и увидеть какие-то,
может быть, пробелы,
которые ты не продумываешь
в требованиях.
А инженерная тема,
архитектура,
она помогает тебе увидеть
технические ограничения,
с которыми ты можешь столкнуться,
которые могут, собственно,
помешать тебе вообще
сделать этот продукт
или сделать его разработку
настолько дорогой,
что это просто будет непрактично.
Вот и в итоге
все это вместе
как бы сходится в требования,
которые, как правило,
в этих компаниях,
то есть ты идешь
к каким-то руководителям,
да, там, с коллегами,
все это обсуждается,
куча итераций,
если там это, там,
два-три месяца
все это продолжается,
и у тебя в итоге получается
законченный комплект требований,
какое-то подобие архитектуры
инженерной
и какое-то подобие UX-дизайна,
которое нужно дальше развивать.
Дизайнеры дальше
берут эти,
то, что они наработали,
изменения какие-то в требованиях
и начинают уже создавать
различные версии UX,
как это может выглядеть.
Происходит несколько разных встреч,
где все это обсуждается,
они дают дизайна-критику
своим другим коллегам-дизайнерам,
продакт-менеджмент
очень активно участвует,
программисты
в каких-то случаях
тоже дают фидбэк.
Важно получать фидбэк
от программиста,
потому что то,
что ты делаешь,
может быть невозможно.
То есть визуально
это все возможно.
Визуально возможно сделать
в принципе сейчас все,
наверное, в нынешней среде,
ну, допустим,
ты хочешь показать какие-то данные
и программисты тебе говорят,
блин, у нас нет такого API
или эти данные вообще не существуют.
Если на этом держится
весь твой дизайн,
то стоит выбор,
да, либо мы это разрабатываем,
на это уходит, допустим, год,
либо мы делаем без этого.
И поэтому идет постоянно
как бы вот такое вот
слово пытаюсь подобрать,
такое трение, наверное, да,
между дизайном,
инженерингом
и продакт-менеджментом.
В плане конструктивное трение.
То есть это трение,
когда, это значит,
как наждачная шкурка, да,
то есть все постепенно
как бы отшлифовывается.
И так вот мы идем,
как бы так вот идем
такими вот совместными шагами,
дорабатывая требования,
создавая код
и дорабатывая дизайн.
Потому что тоже
в процессе создания продукта
у разработчиков
могут возникнуть вопросы,
например,
о, а это как мы показываем,
да, мы как бы про это вот,
этого не было в дизайне.
Плохой разработчик
возьмется сделать это сам.
И потом у нас получается продукты,
когда у тебя там кнопки
навешаны друг на друга,
ничего не понятно.
Кручу все через жопу,
если говорить нашим русским языком.
И такие продукты
пользователи не любят.
Потому что дизайнер,
его задача в том,
чтобы смотреть на дизайн целиком.
То есть, словно говоря,
тебе говорят,
вот на этой форме, да,
у меня не хватает кнопки.
Дизайнер не просто
добавляет эту кнопку
рядом с существующей кнопкой,
отзумливается назад, да,
и смотрит,
как эта кнопка
будет связана
со всем остальным.
Возможное решение
будет вообще просто
переделать полностью
весь этот поток форм,
где нужна эта кнопка,
для того,
чтобы сделать ее по-другому.
Потому что
эта одна дополнительная кнопка
все настолько меняет,
что меняется весь дизайн.
И в этом плане
дизайнеру очень важно
визуально,
это которое люди
именно создают графику.
UI целиком входит
как бы в UX.
UX это такая
всеобъемлющая специальность,
как я для себя определяю.
UX отвечает
за удовлетворение
потребностей пользователей
через дизайн.
И в UX входит UI,
в UX входит весь текст,
который ты изображаешь
в интерфейсе.
В UX входит
в том числе API.
Опять, если ты работаешь
в очень технической компании,
допустим, в облаках,
то API, дизайн API,
это тоже UX.
То, что пользователь видит на экране,
не изолировано
от того,
как он использует продукт
через бэкэнд.
Интерфейс командной строки
это тоже UX.
Дизайнеры,
как правило,
не обладают достаточно
техническими знаниями,
чтобы именно
как бы вносить
серьезный вклад
в то, как создается
командная строка, да?
Но текст, который там идет
в командной строке,
то есть это все должно идти
через UX дизайн.
Документация тоже UX.
То есть UX,
даже если дизайнер отвечает
непосредственно за UI
в конкретном проекте,
он все равно должен думать
за пределы UI
все, с чем взаимодействовать
пользователям.
Это очень важно.
И опять же,
уровень дизайнера
в этих компаниях
зависит от того,
насколько они способны
мыслить широко.
Плюс еще
такой очень важный фактор
продукты Microsoft,
я думаю,
они всем известны.
Есть Word,
есть Excel,
есть еще куча других продуктов.
И эти продукты
работают все
друг с другом.
Чем выше уровень дизайнера,
чем он опытнее,
тем больше он смотрит
на то,
как продукты
взаимодействуют между собой
и как сделать какие-то вещи,
когда у тебя переход
между продуктами
настолько гладкий,
что пользователь
просто этого не замечает даже,
что он переходит
между продуктами.
Знаешь,
в какой-то степени,
я процитирую,
по-моему,
это был
или Стив Джобс
или кто-то из Апплата сказал,
что когда ты смотришь
на телефон,
ты должен видеть
не телефон,
телефон должен просто
растворяться.
То есть дизайн,
хороший дизайн,
он растворяется,
ты его не замечаешь.
Ты просто взаимодействуешь
с той проблемой,
которую ты хочешь решить
посредством того,
что тебе дали.
Если ты начинаешь
обращать внимание,
что, блин,
я вот не могу нажать
или это как-то неудобно,
то это уже признак
плохого дизайна.
Получается,
во-первых,
в рамках всего проекта,
а во-вторых,
еще дальше
и в рамках всей экосистемы,
чтобы понимать,
как это все должно работать
вместе и с бэкэндом,
и с другими продуктами.
И это все входит
в обязательства
и в навыки UX-дизайнера,
вот, например, в Google.
Да, да.
Еще, кстати, я отмечу,
что после определенного уровня,
обычно это уровень
принципал дизайнер
в Амазоне,
и то, что она распространяется
на уровень принципал инженер
для программистов,
это люди уже,
которые очень мало делают дизайна
или пишут код своими руками.
Они леды,
но им не подчиняются люди.
То есть их задача
во многих командах
в том, чтобы создавать архитектуру.
Для разработки,
ну, все это понятно,
у тебя есть там система,
тебе нужно,
чтобы она хорошо работала
со всеми другими системами,
там, хорошо масштабировалась
и так далее.
Это, мне кажется,
более понятно.
А с дизайном,
в крупных компаниях
информационная архитектура
очень важна,
дизайн системы и так далее.
В больших организациях
такие вот принципы,
не создают дизайн сами,
но они поряд над всеми,
со всеми общаются,
вытягивают,
толкают для того,
чтобы то,
что было на выходе,
допустим,
через три года,
было нормальным,
полноценным продуктом,
где все его компоненты
взаимодействуют
с другом очень хорошо.
Это тоже такая интересная тема
в плане профессионального роста,
потому что ты можешь
расти вертикально,
то есть ты можешь быть
дизайнером,
первый уровень дизайнера,
второй уровень дизайнером,
третий уровень,
потом, если ты хочешь,
ты можешь стать менеджером,
тебе уже подчиняются
другие дизайнеры,
потом ты становишься
старшим менеджером,
когда тебе подчиняются
менеджеры,
которым подчиняются дизайнеры,
ты можешь стать директором дизайна,
VP дизайном,
это такая вертикальная схема,
в которой при переходе
на каждый следующий уровень
у тебя добавляется
все больше и больше потребностей
в софт-скиллах
и именно в таком
более широком мышлении.
И когда ты переходишь
на уровень менеджмента,
ты перестаешь делать дизайн.
Это очень важно.
Ты продолжаешь его понимать,
но ты перестаешь его делать.
Многие люди,
я знаю достаточно много людей,
в основе из разработки,
кто не смог пережить
этот переход
из разработчика в менеджмент.
Не потому, что они не справились,
а потому, что им просто
не понравилось.
Посмотрели там
вся эта работа с людьми,
все эти увольнения,
найм,
коучинг,
конфликты между людьми,
про которые ты не знаешь,
когда ты работаешь
просто вот в команде.
Оказывается, у кого-то
какие-то терки,
у кого-то, блин, там
проблемы очень серьезные,
там личные,
куча еще административки,
во всем ты варишься,
и думаешь, блин,
нахрена мне это нужно, да?
Пойду-ка я обратно,
короче, дизайнить.
И это совершенно нормально.
И в эти компании
они дают возможность
работа уже в основном
лежит на софт-скиллах
и на очень глубоком
понимании принципов,
то, что принято
называть, наверное,
насмотренностью сейчас.
Насмотренность не в плане,
визуальной насмотренности,
а именно вот какие-то
архитектурные паттерны,
принципы,
то есть понимание того,
что как люди это сейчас делают,
через три года
это может создать проблему.
То есть он это уже видел
где-то там в прошлом у себя
в своем опыте.
То есть такая насмотренность
более высокого порядка,
вот так сказал.
Эта работа тоже не всем заходит,
потому что у тебя
возникает ответственность
со стратегией,
при этом ты ее не исполняешь,
и при этом люди тебе
не подчиняются.
Эта должность,
не все люди могут
с ней справиться,
потому что
это позиция мягкого лидерства,
когда ты влияешь
на других людей.
Ты можешь, конечно,
эскалировать,
их менеджеры искать,
люди делают говно,
нужно их остановить
и что-то сделать.
Но обычно это возникает
только когда люди
тебя не слушают,
когда ты не можешь
донести до людей разумно,
ну, бывают люди
нерациональные
на другом конце провода.
Эта позиция очень сложная,
потому что у тебя
очень-очень длинные проекты
и у тебя нету
такого ощущения
какого-то успеха,
такого, знаешь,
ежедневного.
Работаешь дизайнером,
ты вот сделал кнопочку,
тебя похвалили,
думаешь, клево,
как, да, вот,
я делаю свою работу.
Или там ты сделал проект
за три месяца, да,
в конце там трех месяцев
у тебя тоже пользователи
пользуются,
всем нравится, да,
ты тоже там доволен.
У принципов,
у них проекты
могут длиться годами.
Их результат, в принципе,
даже не так просто
на него указать,
потому что, ну, да,
у Microsoft классные продукты,
которые круто между собой
взаимодействуют.
Но, это знаешь,
говорят, что
самый классный сисадмин,
это сисадмин,
которого никто не видит,
потому что все просто работает.
В этом плане
работа принципов,
может быть, неблагодарна,
потому что все успехи,
они будут присвоены
тем людям,
которые делали работу.
Тебе нужно при этом
себя еще хорошо продавать
внутри компании,
именно в плане политики,
да, чтобы люди знали,
что ты делаешь,
какую пользу ты приносишь.
Потому что иначе
это будет выглядеть,
как будто другие люди
просто сделали
классную работу,
а ты вообще что здесь делаешь?
Это такое очень интересное
направление.
До него тоже
дорастают просто,
ну и, скажем,
единицы,
очень маленький процент,
потому что он требует
очень серьезных
лидерских навыков
без непосредственного
контроля людей.
Многие просто,
скажем, останавливаются
на синере и думают,
ну все, короче,
я не хочу влиять,
я хочу просто создавать.
И они на этом уровне
встаются,
опираются в этот момент
в потолок по зарплате,
не могут быть какие-то бонусы,
там еще что-то.
Есть какой-то диапазон
денег, которые они зарабатывают,
и выше него они уже не пойдут.
Ну только если,
может быть куда-то перескочить,
но все равно по индустрии
в целом у тебя будет
определенный потолок.
В то время как
если ты идешь на уровень принципа,
там уже разброс
может быть просто колоссальный.
Потому что если ты работаешь
на каких-то очень огромных
проектах,
в организациях,
то тебе будет очень много платить,
потому что таких людей
очень мало.
Это, скажем,
для вдохновения,
для дизайнеров,
которые хотят перейти в менеджмент,
но не очень хотят.
Есть пути
не быть менеджером,
быть специалистом,
но нужно быть очень крутым
и обладать серьезными
софтскалами.
Ты взаимодействуешь
как-то вот с таким вот человеком
у себя на работе?
То есть вы общаетесь
или это как-то
именно чисто с дизайнерами?
Я работал с двумя принципами.
Один дизайнер был,
другой в разработке.
Причем мы все начинали
как синьеры,
и мы все стали принципами
в итоге.
То есть я стал принципом
продактом,
стал принципом дизайнером,
стал принципом инженером
на том проекте,
который мы вместе создали.
И если немножко
описать их работу,
мужик,
принципом дизайнер,
его звали Рон.
Я про него, кстати,
писал в одном из постов
или сторис.
Он у меня старше, наверное,
на 25 лет.
То есть он старше моих родителей.
И он проработал в индустрии
больше, чем я живу.
Он там с 70-х годов
еще в этом всем варился,
когда еще никто про это не знал.
Он был на самом деле
такой дизайнер
слэш информационный архитектор.
В больших организациях
у тебя дофига информации,
у тебя куча документаций,
именно внешней документации,
которую используют пользователи.
У тебя есть весь этот текст
во всех интерфейсах.
В Амазоне, в AWS
на тот момент было
170 продуктов,
у каждого из которых
свой отдельный интерфейс,
в котором есть еще под-интерфейсы.
Огромное количество
текста везде,
текста и информации.
И его была задача в том,
чтобы во всей компании
текст соответствовал
определенным принципам.
Чтобы люди, читая текст
в разных местах,
понимали, что они взаимодействуют
именно с Amazon Web Services,
а не с какими-то
разными компаниями.
Его работа, наверное,
на 60% заключалась в том,
чтобы ходить на разные ревью,
давать людям фидбэк.
Если он заметил,
что где-то что-то делается не так,
он тоже давал им фидбэк
без спроса.
То есть он где-то эскалировал,
если было нужно,
если кто-то шел не туда.
Плюс у него были какие-то проекты,
которые он сам создавал.
То есть он видит,
ага, у нас вот текст
пишут не дизайнеры,
текст пишут разработчики.
Из-за этого у нас
просто очень полный хаос везде.
И один из проектов,
который он сделал,
если не ошибаюсь,
он собрал руководство
с разных организаций
и продавил им эту идею,
что текст должны писать
на самом деле не дизайнеры.
В нашем случае текст писали
люди, которые отвечают
за написание документации.
То есть он, по сути,
забрал написание текста
из рук дизайнеров
и отдал это в руки людей,
которые пишут текст
целыми днями.
Это их работа.
И вот это как пример
такого проекта,
с которыми работают принциповые.
Какими навыками
должен обладать дизайнер,
чтобы вот войти в...
ну, устроиться на работу
в тот же самый Google,
например, или Amazon?
На что будут смотреть
и, ну, что важнее?
Вот, во-первых,
что важно в хардскеллах,
если ты, конечно,
владеешь этой информацией
по UX, по дизайну,
и что важно по софтскеллам?
По хардскеллам
у меня ограниченной информацией.
Занимался немножко
наймом для других команд.
Для своей команды
я не нанимал дизайнеров.
Что касается софтскеллов,
смотрит на то,
как человек взаимодействует
с командой.
Потому что дизайнер
это такая функция,
я уже говорил,
что он немножко,
может быть, неблагодарный,
потому что тебе все хотят
дать какой-то фидбэк,
рассказать,
какая кнопочка должна быть
больше и так далее.
То есть что-то совершенно
не основано на знаниях
или экспертизе,
а вот чисто на мнении человека.
И дизайнер должен
очень хорошо уметь
работать с такими мнениями.
То есть для этого
дизайнеру важно
понимать принципы дизайна.
Есть, например,
книжка Дона Нормана
«Дизайн повседневных вещей».
Она написана, по-моему,
еще в 70-х.
Очень давно.
Я читал первое издание,
оно на 100% применимо
к современному миру.
Просто нужно
вместо слова «печка»
использовать слово «кнопка»,
потому что все принципы
переносятся на современный мир.
И когда, условно говоря,
тебе дают какое-то мнение,
то дизайнер должен
уметь его парировать
при помощи принципов,
объясняя, почему именно так
важно для пользователя,
почему эти вещи
расположены рядом с другом
и так далее.
Но дизайнер должен,
опять же, уметь принимать фидбэк,
потому что такая профессия,
когда ты делаешь что-то творческое,
особенно когда ты начинаешь
вовлекаться эмоционально,
то очень перерастаешь
к продукту своего труда.
И когда тебе что-то говорят,
то можно это воспринять в штыки
и не хотеть менять то,
что ты сделал.
Когда люди закрываются,
ты это сразу чувствуешь.
Станется закрытая поза,
меняется голос.
Ты начинаешь чувствовать
сопротивление на таком
интуитивном уровне,
на языке жестов.
Это нормальный,
на определенном уровне,
потому что мы все люди,
не всегда хотим
дополнительную работу делать,
можем быть не согласны.
Хороший дизайнер,
он примет этот фидбэк,
запишет его где-нибудь
и скажет, я подумаю.
Хотя внутри у него,
может быть, все так кипит,
он думает,
вообще, почему ты мне это говоришь, да?
Кто здесь дизайнер?
Потом он идет обратно,
может быть, даст ему там ночь
повариться
и смотрит на свой дизайн
критическим взглядом.
Начинает анализировать
то, что ему дали,
опять же, с позиции принципов,
с позиции того,
а может быть, я чего-то не знаю,
может быть, я что-то упускаю,
может быть, я что-то не знаю
про пользователя,
или может быть, я что-то не знаю
про бэкэнстэк,
который мешает сделать то,
что я хочу сделать.
И он начинает дорабатывать
и делать новую итерацию.
У тебя может быть
20-30 итераций дизайна,
перед которым
ты переберешь
3-4 разных варианты,
которые просто
совершенно друг от друга
отличаются.
Дизайн, многие другие профессии,
люди думают,
ты сидишь там и рисуешь
вот эти квадатики,
это класс,
потом пользователи пользуются
и все счастливы.
Но на самом деле
в работе дизайнера
очень много негламурной работы.
И негламурная работа
на как раз и заключается в том,
чтобы получить этот фидбэк,
разломать все, что ты сделал,
создать это заново.
Потому что ты начинаешь что-то менять,
у тебя начинает ломаться
в другой месте,
ты думаешь, блин.
Это особенно сложно,
когда ты делаешь не новый продукт,
а когда у тебя уже есть
работающая система,
у которой есть пользователи,
тебе нужно что-то сделать,
и у тебя очень серьезное ограничение,
потому что оно уже там существует,
люди пользуются,
ты не можешь просто брать и ломать.
Да, поэтому брать фидбэк
очень важно.
И не весь фидбэк
обязан принимать.
То есть важно уметь его фильтровать,
оценивать, документировать
и обосновывать то,
что ты взял,
то, что ты не взял
на основе принципов.
И третий очень важный навык,
это понимание концепции
экспериментирования.
Есть принципы,
есть мнение,
есть конфликтующие мнения,
конфликтующие принципы.
И правильный ответ
на самом деле непонятен.
То есть ты не знаешь,
как сделать лучше.
И тогда ты начинаешь тестировать.
Есть два механизма тестирования
таких основных,
концептуальных.
То есть первое,
это ты берешь пользователя,
садишь его за компьютер,
садишься с ним рядом
и наблюдаешь за тем,
что он делает.
В каких-то командах
это делают отдельные команды
UX Research,
где-то это делает
сам непосредственно дизайнер.
Но дизайнеру важно
находиться при этом,
закрыть рот
и слушать все,
что пользователь говорит.
Потому что то,
что пользователь говорит
и то, что он делает,
это реальность.
То, что у тебя в голове,
принципы,
мнения,
это все воображаемое.
Если ты посадил 10 пользователей
и они делают то,
что противоречит принципам,
значит,
у тебя неправильные принципы.
Или эти принципы
здесь не применяются.
И очень важно тоже
уметь это принимать.
Я недавно себе писал,
что есть в некоторых культурах
вот это представление,
что пользователи просто тупые.
То есть мой дизайн классный,
мой продукт классный,
пользователи просто
недалеки,
не догоняют
все эти идеальные штуки,
которые я сделал.
Это очень токсичная тема,
потому что пользователи
это реальность,
это то,
что происходит на самом деле.
И второй подход к тестированию
это тестирование
непосредственно в продакшене
и битестирование.
Не везде есть такая возможность
это сделать,
но там есть возможность,
ее нужно активно использовать.
В любом случае,
ты сначала тестируешь с пользователями,
но если изменения какие-то маленькие,
ты можешь их сразу,
в принципе, в продакшен отправить
и ты отправляешь
такой маленький процент трафика,
если это веб-приложение
или мобильное приложение,
на свою измененную версию.
Условно говоря,
99% трафика идет
на то, что у тебя есть сейчас
и 1% трафика идет на то,
что ты хочешь изменить.
И у тебя есть определенная метрика,
которую ты хочешь оптимизировать.
В Амазоне они измеряют,
сколько ты потратил денег.
Я не помню,
даже нюансы этой метрики.
Но, условно говоря,
если человек тратит меньше денег,
то дизайн работает хуже.
Если он тратит больше денег,
то дизайн работает лучше,
потому что цель – это рост.
Могут быть и вспомогательные метрики.
Есть процент завершения корзины,
может быть метрика,
которую ты оптимизируешь.
A, B-тестирование.
Почему называется A, B?
Потому что у тебя есть A,
это то, что у тебя существует.
A, B, да?
Это то, что ты хочешь проверить.
Еще бывает C и так далее.
То есть ты можешь несколько вариантов
одновременно делать,
если у тебя количество пользователей
позволяет делать такие большие эксперименты.
И тогда ты даешь данным разрешить спор.
Собственно, у тебя спор может быть
самим собой.
Ты может быть,
я не знаю, как лучше сделать.
У меня есть такая идея,
есть такая идея.
Вроде обе хорошие,
и на самом деле они обе могут быть хорошими,
но одна всегда будет немножко лучше.
Ну, кстати, не всегда.
Они могут дать эквивалентные,
на самом деле, метрики.
Различие будет статистически незначимым.
И тогда, в принципе,
ты можешь пойти с любым вариантом.
Хороший дизайнер,
умеет хорошо коммуникировать
и хорошо принимать фидбэк
и участвовать в этих обсуждениях.
И из этого исходят многие другие скиллы.
Ты должен уметь хорошо говорить,
ты должен уметь хорошо струклировать информацию.
Как-то так.
Когда начинается вот это тестирование?
Ты до этого еще рассказывал,
как начинается работа с продуктом
и в какой момент тестирование начинается.
И когда вы начинаете именно тестировать
на живых людях,
будь то команда или прям пользователи,
либо вы как-то сами все это обдумываете,
варите в собственном соку,
а потом презентуете.
Как это все происходит?
Учитывая то, что мы работаем в Enterprise IT,
наши пользователи очень требовательны.
Их не так много, но они очень требовательны.
Как правило, все, что выходит в продакшн,
тестируется какими-то внешними пользователями.
Какие-то маленькие изменения,
если ты хочешь кнопку добавить,
и у тебя, в принципе, и так все понятно,
и эта кнопка приносит новую функцию.
В принципе, ее не обязательно тестировать.
Она ничего кардинально не меняет.
Если ты делаешь какие-то изменения в том,
как, например, происходит навигация,
или ты меняешь формат таблицы,
как показываются какие-то данные.
Это то, что может материально повлиять
на то, как пользователи взаимодействуют с системой.
Внутри команды мы это тестируем,
просто показывают людям.
Дизайнеры показывают разработки,
продукты, все это смотрят, дают фидбэк.
Все это больше не тестирование,
это больше как бы брейнсторн.
Когда начается тестирование,
это зависит от того, какая у тебя фича,
то есть что ты меняешь,
насколько это сильно меняется.
В каких-то случаях изменения настолько кардинальные
или что-то настолько новое,
что ты делаешь прототип,
который можно кликать,
иногда добавить просто PDF.
Это не обязательно что-то очень сложное.
Ты находишь внешних пользователей,
которые готовы тебе помочь,
даешь им в награду какие-нибудь гиф-карты,
да что-то такое,
чтобы, знаешь, людям дать мотивацию поучаствовать.
Даешь им этот прототип
и смотришь, как они с ним взаимодействуют.
Этот тест приближен к использованию реальной системы,
но он все равно такой искусственный.
Другой вариант.
Если изменения достаточно простые
в плане именно технических изменений,
то есть ты можешь сделать эксперимент,
который скрыт от публики.
У тебя есть другая версия в продакшене,
которую ты можешь дать определенным пользователям.
То есть ты добавляешь пользователя
в так называемый white list,
это в белый список,
и этот пользователь может увидеть другой интерфейс.
Ты этого пользователя садишь с собой,
и он уже непосредственно взаимодействует с продакшеном,
со своими собственными данными,
со своим собственным аккаунтом.
И это такой очень хороший тест,
когда ты можешь получить очень хорошие данные,
потому что эта ситуация не искусственная.
Но это не всегда возможно,
потому что иногда бывает очень дорого
эти изменения внедрить в продакшен,
и проще насечить какие-то плохие идеи на этапе прототипов.
Другой вариант, который очень сильно развит
в крупных компаниях,
и в Амазоне, и в Гугле,
это так называемый dogfooding.
Этот термин идет из, по-моему, 70-х годов.
Делали какую-то собачью еду,
и лозунг рекламы был что-то вроде
«Будут ли собаки есть собачью еду?»
Этот термин прижился,
я не знаю, как он попал в IT.
Условно говоря, если ты берешь компанию Google,
она производит собачью еду,
это твой продукт.
Все, кто работает в Гугле, это собаки.
И вопрос там,
будут ли сотрудники Гугла,
есть то, что они выводят на рынок.
Тестирование здесь в том,
что ты запускаешь продукт для внутреннего использования.
То есть есть определенный механизм,
который позволяет сделать так,
что есть разные версии продукта.
Gmail, Google Docs,
всем, чем я пользуюсь на работе,
я вижу другую версию,
в отличие от того,
что видят люди,
кто не работает в компании.
Мы всегда используем
самые-самые последние эксперименты
внутри компании.
Поэтому, допустим,
мне нельзя делать скриншоты,
даже, например, Google Card
с рабочего аккаунта,
потому что там могут быть фичи,
которые не были запущены.
И там ты собираешь метрики,
плюс ты можешь делать какую-то форму,
где пользователи могут
дать ей фидбэк,
они могут тебе просто email написать.
Потому что внутри компании
ты можешь делать какое-то мероприятие,
где ты сделаешь презентацию,
ты можешь отправить email,
ты можешь активно просить людей
дать тебе обратную связь.
В то время как с внешними пользователями
это намного сложнее.
Тут важно понимать,
что те, кто работает внутри компании,
у них все равно может быть
немножко скажу,
перспектива,
потому что они не всегда
могут быть
репрезентативными пользователями.
Но если говорить про юзабилити,
допустим,
если кнопка добавляет
больше проблем,
чем решает проблему,
то обычно это, в принципе,
можно поймать
и на внутреннем тестировании.
Мой ответ, наверное, в том,
что здесь нет конкретного процесса,
где ты говоришь,
что вот если так,
то так вот,
если так, то так вот.
Ты смотришь по ситуации,
и опять же,
еще есть важный фактор
такой, как ресурсы,
потому что у тебя не всегда
есть время делать полноценный ресерч,
не всегда есть возможность
в продакшн впихнуть,
и ты принимаешь эти решения,
исходя из того,
какие у тебя потребности
и какие у тебя риски.
Опять же, да,
если у тебя очень высокие риски,
то ты тратишь больше времени,
вкладываешь больше денег
и делаешь их, может быть,
более медленно
и более правильно.
Если у тебя риски маленькие,
бюджет маленький тоже.
Ну, посмотрим, как будет.
Если у тебя есть портфолио,
какой-то крутой проект,
но вот он под NDA,
и ты не можешь его там
показывать по договору,
то есть, ну, он крутой,
и хотелось бы его показать
на, допустим, собеседовании.
А есть ли какие-то здесь выходы,
либо просто придумывать
тогда что-то другое?
Такие вопросы стоят
и в собеседованиях
у других позиций,
когда тебе приходится
более растутчатыми вещами
рассказывать о том,
что ты сделал,
потому что ты не можешь
углубляться в детали.
Я не знаю, как это проходит
у дизайнеров,
но ты однозначно
не можешь показывать
то, что ты делал,
потому что это под NDA.
Тебе придется про это
как-то рассказывать,
может быть, описывать,
какая была пользовательская проблема,
как ты ее решал,
какие принципы ты использовал.
Буду смотреть больше на то,
как ты мыслишь.
В любом случае,
ты можешь это как-то
отойдя от темы
портфолио собеседований,
сейчас у вас же локдаун,
да, и ты, получается,
работаешь из дома.
И как вообще
Google выстраивают,
решают вот эту проблему?
Ну, понятное дело,
что в офисе
коммуникация проходит
эффективнее.
И как сейчас
вы выстраиваете коммуникацию,
например, с дизайнером,
когда нужно обсудить
вот эти вот все
визуальные вещи,
и вы при этом находитесь,
насколько я понимаю,
ты на Гавайях сейчас находишься,
а он там, условно,
где-нибудь в Сиэтле.
И как вы это все устраиваете,
как вы это все организовываете,
сейчас в условиях пандемии,
скажем так?
Локдаун – это очень
моя больная тема,
потому что я из тех людей,
кто любит работать в коридорах.
Для меня каждый поход,
ну, условно,
игра в туалет, да,
или там за водой,
это возможность
кого-то в коридоре встретить
и с ним пару минут
перетянуться в пару слов.
И таким образом
я собираю, как бы, контекст.
Как продакт, да,
мне очень важно
видеть, как бы, широкую картину
и понимать, что где происходит,
потому что у меня есть
много зависимости,
много стейкхолдеров.
И, допустим,
чтобы немножко где-то
почву прощупать
и узнать какие-то слухи,
может, знаешь,
уже слухи важны, да,
потому что,
а что если там какая-то,
кто-то, допустим,
ушел из команды, да,
и это влияет на
исполнение проекта
где-то в другом месте,
и это влияет на меня косвенно.
Ну, то есть такие вот вещи, да,
вот.
И находясь в коридоре,
ты можешь всю эту информацию
собирать.
Это мой стиль работы вообще, да.
То есть у меня
всегда было не так много митингов,
но я очень много
общался с людьми в коридорах.
Может быть, час в день
общался с людьми в коридорах.
Нужно его запланировать,
у человека должно быть
свободное время,
ты не можешь его просто
там подойти сзади,
постучать ему по плечу.
Было просто адски сложно
для меня в самом начале.
И это был март,
и как раз я вот тогда
в Амазоне
начал просто сильно
очень выгорать.
В апреле запустили
последнюю версию продукта,
которую я делал,
и все, в июне я уже ушел.
Я просто не мог
работать в этой среде,
несмотря на то,
что я все знал,
у меня был полностью контекст.
Уровень стресса у меня
повысился в несколько раз
с начала локдауна.
Проблема была в Амазоне
в том, что это все
только началось,
и там менеджмент
был не особо понимающий
проблемы.
Проблема была больше
не в том, что люди
работали из дома,
а в том, что у половины
людей есть маленькие дети,
у которых закрылись школы,
закрылись детские сады.
У меня жена не работает,
но у меня двое детей,
дому было меньше двух лет.
У кого-то оба супруга работают,
и у них еще маленькие дети,
у которых закрылась школа.
Это был просто коллаб.
Все рабочие системы,
для меня это было просто выживание.
Поэтому первые месяцы
были очень сложные.
Когда я пришел в Google,
уже было понимание того,
что это новая реальность,
по крайней мере,
как выясняется уже
на следующий год.
К этому нужно просто
подстраиваться.
То есть я выставил
определенные процессы дома,
чтобы меня меньше мешали,
но все равно было очень сложно.
Если говорить конкретно
про рабочие процессы,
Google это такая компания,
у которых много мест,
где люди взаимодействуют
друг с другом.
Это очень коридорная культура,
скажем так.
То есть люди постоянно
взаимодействуют,
постоянно что-то рисуют
на досках,
вся эта бесплатная еда,
кофе.
Это все сделано для того,
чтобы люди могли сказать
«Пойдем кофе попьем»,
и заодно что-то обсудить
в комфортной атмосфере.
Потому что идеи берутся
именно из разговоров,
из обсуждений.
Для Google это был
очень большой шок,
потому что Google вообще
не разрешал работать из дома.
А тут все стали работать из дома.
Были все технологии для того,
чтобы это делать.
Была плноценная инфраструктура,
но это просто было
очень сложно для людей.
Что поменялось сильно?
Это стало больше
формальных митингов.
Если раньше ты мог просто
подойти к дизайнеру,
или дизайнер мог тебе подойти,
инженеры тоже взяли
с соседнего стула
и пошли там с ними
втроем к доске.
За 15 минут все обсудили.
Все получили, что им нужно,
все довольны.
Еще эмоционально
получили какой-то заряд от этого.
А в новой реальности
у дизайнера, например,
есть вопрос.
И ему нужно либо задать
это где-то в чате.
А когда ты пишешь текстом,
ты не всегда можешь
объяснить хорошо
то, что тебе нужно.
Особенно если проблема
такая расплодчатая,
ты потратишь больше времени
на объяснение текстом,
чем на то, чтобы
это сказать словами
и обсудить.
И ты хочешь поговорить с людьми,
ты начинаешь смотреть
в их календарь,
они заняты,
у всех куча митингов.
И в следующий раз,
когда ты можешь встретиться,
сейчас, не знаю,
в понедельник
у людей свободное время
только в четверг.
И тебе нужно либо
писать им,
типа, мне нужно встретиться,
мы же встретимся.
Сегодня, чуть позже,
людям нужно переделывать
свои календари.
И получается много
пустой работы
по организации времени.
Система календарей
так устроена,
что митинги, в принципе,
меньше полчаса
обычно не делают.
Потому что по умолчанию
это полчаса,
15 минут,
ты как бы ни туда, ни сюда.
И ты выдергиваешь людей
на полчаса
из того, с чем они занимаются
в этот митинг.
Хотя у тебя вопросов
может быть только на 10 минут.
И ты начинаешь думать,
раз уж мы с ними встречаемся,
обсудим-то что-нибудь еще,
то у тебя получается
там огромная адженда.
И если вот работа в коридорах,
она такая более agile,
то есть когда ты просто
делаешь то, что нужно,
когда нужно,
то вот эта работа с календарями,
она больше как водопадная система,
когда тебе нужно
много больше планировать.
Это очень сильно усложняет работу,
особенно на поле новых продуктах,
новых проектах,
где тебе нужно именно реально
какие-то идеи, идеи, идеи обсуждать.
Становишься заложником
вот этих рамок календарных.
Да, это сложно.
Конкретно с дизайнерами,
у нас в Гугле
такая же система,
что, ну, организационная система,
что у нас остальная команда разработки
находится в Сиатле
для нашего продукта.
Часть команды находится в Сан-Франциско.
И команда, которая занимается
непосредственно пользовательским интерфейсом,
то есть именно инженерная команда,
которая занимается созданием UI,
она находится в Варшаве, в Польше.
И раз в неделю
мы встречаемся на митинг,
в котором иногда бывает по 15 человек,
в котором участвуют
все дизайнеры из Сан-Франциско,
и несколько человек из Сиатла.
То есть все продукт-менеджеры
и разработчики,
которым нужно там быть.
Вот мы в течение получаса
у нас есть Google Doc.
Это, кстати, вот такая тема
распространена в митингах в Гугле.
Есть Google Doc,
где собираются заметки
с каждого из митингов.
То есть это Google Doc,
он добавлен в календарь.
То есть у каждого мероприятия,
у каждого ивента
есть документ,
в котором люди могут печатать
то, что они обсуждают.
И особенно у митингов,
которые повторяющиеся,
в общем, каждую неделю
мы встречаемся на эту синхронизацию.
То есть это один и тот же документ
мы используем.
И перед митингом
все добавляют в список,
что они хотят обсудить.
Обычный формат такой,
что они добавляют свое имя
и то, что они хотят обсудить.
И потом уже на митинге
они это проговаривают,
это идет обсуждение
и документируется
какое-то решение
или какие-то ссылки.
То, что нужно потом для будущего,
это документируется в документе.
И это для меня был
прямо такой вот вау-экспириенс
в Гугле.
Вот эти инструменты
для работы в реальном времени,
когда 10 человек
одновременно могут
что-то печатать в документе,
все это сохраняется,
все это можно потом использовать,
это можно отправить другим людям.
И в Гугле, кстати,
культура еще такая,
что документы все очень открыты.
То есть я могу получить доступ
практически к любому документу.
Единственное,
две вещи, которые Гугл охраняет
очень-очень сильно,
это пользовательская информация.
То есть чтобы получить данные
какому-нибудь пользователю,
каких-то использований,
это нужно пройти просто
какие-то нереальные количество
этих одобрений.
Это информация,
которую люди доверяют Гуглу,
и Гугл, по сути,
обещает, что эту информацию
никто не будет трогать,
даже сотрудники.
То есть ты можешь делать
20 часов вечера.
Если ты смог получить доступ туда,
есть проблема в системах
ограничения доступа,
и Гугл ее сразу же исправит.
А если ты, допустим,
работаешь так,
что ты смог получить доступ туда
каким-то нечестными путями,
то завтра ты уже в компании
работать не будешь.
То есть это очень важно.
И вторая вещь,
которую Гугл охраняет,
это финансовые данные.
А все остальное,
есть куча документов,
есть куча сайтов внутренних,
где ты можешь посмотреть,
на чем работают другие команды.
Я могу посмотреть цели
любого другого сотрудника в компании.
То есть в этом плане
это очень сильно упрощает
вот работа на удаленке,
потому что у Гугла
изначально была такая культура,
что все открыто.
И в каких-то моментах,
допустим,
если я хочу спросить,
чем человек занимается,
мне не обязательно
с ним разговаривать.
Я могу просто зайти
и посмотреть,
что он на самом деле делает.
За счет вот этой открытости
ты можешь планировать
как продукт
свою деятельность,
знать, кто что делает,
кого ты можешь себе
в команду позвать
или не можешь,
и так далее.
То есть это получается
как бы общая база того,
где ты видишь всех,
и все видят тебя причем.
И это тоже интересно.
А тем мне сначала
было некомфортно,
потому что я не привык
к такому,
что все-все видят.
А потом начинаешь
к этому привыкать,
и это еще очень хорошо
помогает в создании культуры,
компании, культуры, команды.
Потому что в Гугле хаос.
В Гугле очень мало процессов.
Есть процесс,
но процессы в основном
на высоком уровне.
Допустим,
чтобы что-то запустить,
ты должен делать
определенные легальные
какие-то вещи,
юридические,
маркетинги и так далее.
Но в том,
как ты делаешь свою работу,
процессов вообще нет.
То есть ты сам, по сути,
в эти процессы определяются
команда,
где ты работаешь,
тобой лично.
И такая открытость,
она помогает, наверное,
обеспечить
такой, может быть,
негласный контроль, что ли,
что люди все-таки делают
то, что они должны делать,
потому что все это прозрачно.
То есть тебя никто не контролирует
за счет того,
что все открыто,
все на виду.
Ты знаешь, наверное,
как в спорте, да?
То есть в футбольной команде
все видят,
как играют другие игроки.
То есть если ты начнешь
что-то лажать
или не пинать мяч,
как и выжда,
тебе сразу об этом скажут.
И здесь то же самое.
И поэтому, как бы,
потому что это все на виду,
ты стараешься больше.
И это, мне кажется,
такая пассивная форма контроля,
наверное,
она очень хорошо работает
для поддержания культуры.
И опять же, да,
допустим,
ты не будешь писать
каких-то плохих вещей.
Есть даже где-то
в комнате с тренингов,
вы говорите, да,
что все, что вы напишите, да,
в e-mail или в чате,
пишите с таким пониманием,
что это может быть
со скриншотина
и сделано публичным.
Поэтому в гугле
я вообще не вижу
обсуждения людей
за глаза в письменном виде,
например.
Потому что это
просто сразу же может всплыть.
Нету агрессии
в чатах, в e-mail,
потому что, опять же, да,
там в любой момент
в e-mail могут быть
добавлены другие люди.
То есть в этом плане
эта прозрачность,
она, конечно, помогает.
Мне кажется, в гугле
в локдауне она очень сильно помогла.
И если сравнить
вот эту систему
практически абсолютного хаоса
с тем, что было в Amazon,
насколько там
все более четко
и как ты можешь сравнить,
вот, где, на твой взгляд,
комфортнее
и что, на твой взгляд,
более удобно,
если это, конечно,
корректное сравнение?
В Amazon очень много свободы
в том, как ты делаешь свою работу.
Но при этом есть
определенные вещи,
которые ты должен делать.
Это то, чего в гугле нет.
И я могу привести пример,
два примера.
Один с продукта,
другой с разработки.
Создание продуктов
в Amazon начинается
с того, что ты пишешь
пресс-релиз,
как будто бы,
если ты этот продукт
запускаешь на рынок.
И пять страниц,
обычно это пять страниц,
FAQ, да,
то есть вопросы,
которые тебе могут задать
пользователи,
вопросы, которые тебе могут задать
какие-то внутренние стейхолдеры.
И этот документ потом ты делаешь,
ты его обсуждаешь
от того,
какая у тебя фича.
Если ты запускаешь какую-то фичу,
это может пойти
на один или два уровня выше.
Если ты запускаешь
целый новый продукт,
это может пойти
на уровень CEO
твоего подразделения.
То есть я четыре раза
презентовал продукт
AWS Chatbot,
который я создал.
Энди Джасси,
это CEO облачного бизнеса.
Он в скором времени
станет CEO всего Амазона.
Судеба процесса в том,
что создавая этот документ,
описывая требования,
описывая стратегию,
на каждом этом этапе
то есть у людей
более широкая картина мира
и больше опыта.
Люди реально очень умные
на высоких позициях.
И каждый раз
тебе куча
чего тебе нужно дорабатывать.
И ты, получается,
с каждым таким шагом
ты все больше и больше
дорабатываешь,
делаешь свою идею
более явно выраженной,
ты больше понимаешь ее,
у тебя больше глубины.
В итоге, когда ты прошел
этот процесс,
он занимает,
он может занять на месяца три
спокойно,
от идеи до того,
как ты получил одобрение.
У тебя документ,
который прямо вот
кристально ясно
описывает то,
что тебе нужно делать.
А потом ты уже
как бы свободен делать
все, что ты хочешь.
Ну, есть определенный процесс,
но в целом
вот этот процесс
определения продукта,
он форсирует глубину мысли.
Второй процесс в Амазоне,
который очень крутой,
я считаю,
это для всех разработчиков,
это не во всем Амазоне,
это в AWS,
в облачном бизнесе.
То есть облачный бизнес
очень высоко ценит
uptime,
как это называется.
Настолько продукты
стабильны и не падают.
То есть, условно говоря,
у тебя 99,9999%
основные продукты
должны быть доступны
для пользователей.
И если ты падаешь
на одну десятитысячную,
или стотысячную,
я уже запутался в этих цифрах,
то это проблема.
И для того,
чтобы вот этот
такой образ мышления
внедрить во все команды,
то есть,
есть такой как бы механизм.
Во-первых,
в Амазоне все команды,
это команда DevOps,
то есть,
у тебя, условно говоря,
10 человек,
которые работают на такой-то фичи,
они отвечают за какой-то
конкретный сервис,
набор фич,
набор продуктов,
и они за него
отвечают целиком.
То есть,
они сами отвечают
за инфраструктуру,
за все метрики,
они несут за него ответственность.
И это подход,
который они называют
you build it, you run it.
То есть,
ты его построил,
ты его,
ты ему управляешь.
И суть в том,
что все,
что ты делаешь,
если ты сделаешь что-то криво,
то вся боль ложится на тебя.
Ты как бы,
ты создаешь проблемы
для самого себя.
Таким образом,
как бы,
это мотивирует людей
делать вещи правильно
на долгосрочную перспективу,
потому что,
даже если ты сам,
допустим,
хочешь через полгода
уйти за этой командой,
но другие люди,
возможно, не хотят,
они тебе просто
не дадут сделать.
Плохо.
Потому что,
это очень такое
долгосрочное мышление
это внедряет.
Каждую среду
в AWS собирается
огромное количество людей,
больше ста человек.
Это все,
то есть,
каждый технический директор,
каждый технический вице-президент
должен быть там,
либо отправить
кого-то из своей команды,
плюс все менеджеры разработки там.
Разбираются
все инциденты
за предыдущую неделю
операционные.
То есть,
если где-то что-то упало,
это все разбирается.
И председатель этого митинга
это чувак,
он старший вице-президент,
который отвечает за весь продукт.
Он очень строгий,
но справедливый,
я бы так сказал.
С ним очень сложно бывает.
То есть,
он как бы просто
задаст тебе такие вопросы,
на которые, знаешь,
ты можешь просто потеряться.
Поэтому это требует
очень большой подготовки
к этому митингу,
особенно если у тебя была
какая-то проблема.
Если выясняется,
что у тебя система упала,
ну как,
точнее,
если у тебя система упала
больше,
чем на какое-то
определенное количество
поинтов,
и это повлияло на пользователей,
ты обязан написать документ,
который описывает
прямо по минутам
все, что произошло,
какие были действия приняты,
где были какие-то
системные ошибки,
и что ты можешь сделать
для того,
чтобы автоматизировать
эту проблему.
И эти документы
потом проверяются
тоже на многих разных уровнях,
и благодаря им
команды, по сути,
заставляют
автоматизировать
ручной труд.
И это происходит
как бы на уровне
всей системы,
всей компании в целом.
Вот этот процесс,
он такой как бы,
он со стороны выглядит жестким,
но его цель,
его направленность
в том, чтобы
реально сделать
компанию лучше.
И поэтому
Amazon,
несмотря на то,
что я ушел с компании,
я безмерно вообще их уважаю
как компанию,
как строители организаций,
потому что они прямо
умеют создать
эти механизмы,
эти структуры
для того, чтобы все работало
прямо как часы.
Очень часто повторяющий вопрос
и от моих учеников,
и от моих подписчиков.
Условно,
что бы ты посоветовал
дизайнеру,
что бы сейчас
он начал делать,
учить,
во что должен
погружаться,
что бы он стал
вот хорошим кандидатом
для вот того же
Google, например,
либо Amazon?
Вот,
что нужно делать дизайнеру,
чтобы развиваться
и быть готовым,
подготовиться
для работы в Google?
То есть нужно изучать принципы.
То есть нужно
как можно больше искать
принципы дизайна,
читать про них,
изучать их
и внедрять их
в повседневной жизни.
То есть знать принципы
недостаточно,
важно их видеть.
То есть ты смотришь на что-то...
У меня недавно была
серия Stories,
и есть такие принципы
Грайса,
или Максим Грайса,
про информацию.
Что информация должна быть
в правильном количестве,
в правильном качестве.
Это буквально
четыре предложения.
Но имея это у себя
на подкорке,
глядя, допустим,
на текст в интерфейсе,
ты можешь оценить,
принципам.
Потому что эти принципы,
они очень простые,
но они толкают тебя
в правильном направлении.
И если ты где-то
не соответствуешь
каким-то принципам,
то ты должен себя спросить,
почему, да?
То есть это есть объективная
где-то причина,
или это где-то моя лень просто.
Я, не знаю,
недостаточно хорошо
в чем-то разбираюсь,
и мне нужно в чем-то
больше разобраться.
Плюс книга
Дона Нормана,
про которую я говорил,
дизайн повседневных вещей.
Он тоже раскладывает
все на принципы,
и эти принципы
применимы ко всему.
И то, что я делаю, да,
то есть принципы
это вообще моя тема, да.
То есть я люблю принципы
во всех направлениях.
Я про них читаю,
стараюсь их искать в мире.
То есть ты идешь на улице,
увидел какую-то вывеску,
и у тебя глаза как бы цепляются,
да, и ты начинаешь
анализировать
с точки зрения принципов.
Это формирует такую вот
насмотренность.
Насмотренность именно
на...
Не то, что работает,
знаешь, а именно как бы
насмотренность на неправильное слово.
Формирует привычку.
Формирует привычку
везде видеть принципы,
видеть вот это,
то, что находится за внешним видом.
Этим отличаются дизайнеры,
наверное, в топовых компаниях,
может быть,
от людей, которые не могут
там попасть.
Пробуют, но не могут.
Это вот именно вот
возможность видеть,
способность видеть то,
что находится за пределами
того, что видит класс.
И, к сожалению, здесь, да,
как бы это очень сложно.
То есть это не то,
что я этим могу дать список,
да, вот эти 10 вещей
ты должен делать.
То есть, в принципе,
это такая постоянная работа
над собой,
над ясностью своего мышления.
И тут очень важно тоже
не загнать себя
в какие-то шаблоны
этих принципов.
То есть нужно именно
как-то уметь их использовать,
при этом не мысля шаблонно.
Поэтому очень важно читать,
я считаю,
важно в целом
внимать в себя
как можно больше
примеров, информации
из других смежных
отраслей, да,
вот, допустим,
почитать про product management.
Потому что product management
даст тебе понимание
стратегии,
понимание пользователя,
как мыслят продукты.
То есть можно почитать
что-то про разработку,
какие-то, может быть,
высоковровневые вещи.
Это даст тебе понять,
как мыслят твои
стейхолдеры-разработчики.
То есть вот в целом
вот это понимание,
вот на этом строится
фундамент твоего успеха
большой корпорации.
И плюс хардскиллы, да,
ну а хардскиллы,
то есть нужно всегда
развивать, да,
учиться, учиться
чему-то новому,
проходить курсы.
Вот сейчас, кстати,
стал очень много курсов.
Я не знаю,
у тебя есть курсы или нет.
Но много очень я вижу
курсов на Инстаграме
от людей.
Мне даже сложно сказать,
профессионалы
они в своем деле или нет.
И насколько они как бы
хорошо владеют тем,
о чем они рассказывают.
Насколько это правильно.
Поэтому я ни разу
не брал курсы из Инстаграма,
сам лично.
И всегда стараюсь,
если я беру какой-то курс,
очень продвинутый.
Кто-то, у кого уже есть
имя в индустрии.
И от них можно
намного больше научиться.
Кстати,
тоже очень хороший момент
в этом плане.
Нужно учить английский язык,
потому что очень много
видео на YouTube,
где люди рассказывают
какие-то вещи на конференциях,
на каких-то презентациях.
Google очень много
публикует видео
со своих внутренних
мероприятий на YouTube,
где можно послушать людей.
Например,
есть чувак,
Люк Враблевский.
Он директор по дизайну
в Google,
и он придумал термин
mobile first,
когда ты начинаешь
разрабатывать приложение
именно с телефона,
а не с того,
как пользователь будет
с компьютера с ним
взаимодействовать.
И я видел несколько видео
презентаций.
Вот чувак прямо
очень круто объясняет
принципы
и на примерах
все это раскладывает
и объясняет,
как было бы лучше сделать.
Каждый раз,
когда я его смотрю,
значит,
когда нужно ставить на паузу,
думать немножко,
а потом идти дальше,
потому что он прямо
нереально крут.
И такие видео,
они, естественно,
на русский переведены,
большинство из них не будут.
Они доступны только
на английском языке.
И в целом,
если мне про дизайн
сложно сказать,
оно отстает
на несколько лет
от того,
что происходит в долине.
Ну и, собственно,
вся Америка,
остальные тоже отстают
на несколько лет
от долины.
Но в Америке проще,
потому что там
все на одном языке.
То есть человек,
условно говоря,
из какой-нибудь Канзаса
может почитать то,
что пишет человек
из Гугла
и это начать использовать.
В то время,
как человек из России,
если он не знает
английского языка,
то он себя,
по сути,
отталкивает
несколько лет,
ожидая что-то другое,
для него это переведет,
опубликует
и каким-то образом
должен эту информацию найти.
То есть, получается,
воспринимаешь информацию
через фильтр того,
что тебе дают.
Фильтр какого-нибудь
конкретного человека,
конкретных людей.
И это очень такая
плохая позиция,
на самом деле.
То есть, лучше всегда
искать информацию
в первой источнике
и для этого язык,
ну, я считаю,
это просто фундаментальный
скилл, который нужен
любому специалисту.
Спасибо, что дослушали
до конца интервью.
Если у вас есть
какие-то мысли
по поводу того,
как сделать подкаст лучше,
пожалуйста, напишите мне
в Инстаграме.
Я отвечаю на все
сообщения в Директе.
Мне будет очень важно
услышать, что вам понравилось,
что вам не понравилось.
Где-то что-то можно улучшить,
где-то чего-то можно добавить,
чего-то можно сделать больше.
Подкидывайте интересные темы.
Если у вас интересные
есть гости,
с которыми вы бы хотели,
чтобы я поговорил,
пожалуйста, отправляйте мне
все это в Инстаграме в Директ.
Я буду очень рад
от всех от вас слышать.
Ну, и не забывайте
подписываться на меня
Илья.Безелев в Инстаграме,
а также на Марата
М.Достарбеков
тоже в Инстаграме.
Также для подкастов,
хорошее в комментариях.
Я буду очень вам
за это благодарен.
Все, всем спасибо, пока.
До следующих выпусков.