Где искать работу за границей

Где искать работу за границей

Делюсь с вами кратким списком того, откуда можно начать поиск работы за границей помимо своего нетворка - пройдемся по воронке от наиболее широкого до наиболее узкого поиска.

1. Google Jobs (https://www.google.com/search?q=product+manager+jobs&oq=google+jobs&aqs=chrome..69i57j69i64l2j69i60l2.1840j0j1&sourceid=chrome&ie=UTF-8&ibp=htl;jobs&sa=X&ved=2ahUKEwjq49L78-7mAhUvQRUIHYZDDnAQiYsCKAB6BAgIEAM#fpstate=tldetail&htivrt=jobs&htidocid=QwzuMc_i3T_PcbV7AAAAAA%3D%3D) - в англоязычном поиске должен быть доступен поиск позиций прямо из поиска Google. Забейте ‘product manager jobs’ и вам должен выпасть список позиций недалеко от вашей локации.

2. LinkedIn (https://www.linkedin.com/jobs/) - неплохой поисковик для начала исследования рынка. В бете сразу показывают примерную зарплату и ожидаемые perks.

3. Glassdoor (https://www.glassdoor.co.uk/Job/london-product-manager-jobs-SRCH_IL.0,6_IC2671300_KO7,22.htm?srs=MY_JOBS) - похожий функционал, можно сразу посмотреть информацию о компании, отзывы о них и т.д.

4. Сайты компаний - заходим на сайты интересующих компаний и смотрим там в разделе careers. Сайты FAANG компаний:

Facebook (https://www.facebook.com/careers/)
Apple (https://www.apple.com/jobs/us/)
Amazon (https://www.amazon.jobs/en)
Netflix (https://jobs.netflix.com/)
Google (https://careers.google.com/)

5. Агрегаторы:

Indeed.com (https://www.indeed.co.uk/)
Monster (https://www.indeed.co.uk/)

Startups - Angel.co (можно почитать о каждом отдельном стартапе на Crunchbase)

Stackoverflow (https://stackoverflow.com/jobs) - можно сделать фильтр по visa sponsored jobs (https://stackoverflow.com/jobs/visa-sponsorship-developer-jobs).

Удаленная работа - We Work Remotely (https://weworkremotely.com/).

6. Русскоязычные каналы в Telegram:

https://t.me/hireproproduct
https://t.me/jabroad

Присылайте и другие ресурсы на @alinaverbenchuk, которыми вы пользуетесь/пользовались сами, когда искали работу за рубежом - включу их в список.

Массовый опрос с картой

Поскольку цель опроса — зафиксировать причины, по которым респондент находится в том или ином месте, то в идеале, необходимо иметь представление, откуда и куда он движется. Поэтому, когда позволяют условия исследования, полевикам выдаются бумажные карты, на которых они, во время анкетирования, помечают начальную и конечную точку движения респондента. Таким образом получается собрать наиболее достоверную информацию о передвижении людей.

Если при анкетировании процесс проходит полностью в электронном виде — в приложении, то при опросе с картой существующие инструменты уже не справляются, по этой причине, в данном методе, используются только бумажные карты. С этим связано и главное ограничение — оцифровка информации с бумаги отнимает кучу ресурсов. И, если исследование объемное, то на обработку большого количества данных может просто не хватить рук: в таком случае от использования карт отказываются. Но, даже когда исследование позволяет использовать этот метод, объем полученной информации достаточно велик, и для его оцифровки может потребоваться несколько недель работы одного исследователя.

С точки зрения человека, работающего в полях, наличие карты, так же, не делает его работу проще. Подсчет квоты и заполнение анкеты он производит на смартфоне, а чтобы отметить маршрут, ему приходится переключаться на бумажную карту.
Одной анкете соответствует один экземпляр карты (то есть полевик несет с собой 25 распечаток + резерв). На карте имеется уникальный номер, который необходимо внести в конце электронной анкеты, чтобы связать офлайн карту с онлайн опросом. Одновременно с этим, на бумажной карте полевик ставит свои инициалы, чтобы, в случае возникновения проблем, с ним можно было связаться.

В итоге, получается довольно много возни, во многом из-за этого полевики совершают ошибки: кто-то указывает две точки, не помечая, какая из них начальная, а какая конечная; другие торопятся и пишут неразборчиво; а кто-то вообще может забыть внести данные на карту.

Таким образом, массовый опрос с использованием карты является, пожалуй, одним из самых трудоемких методов, со стороны исследователей так уж точно.

Юрий Ветров #1 - об аутсорсе и развитии дизайн-системы.

Директор по дизайну в Mail.Ru Group (продукты под брендом “Mail.Ru”).
jvetrau.com

— Привет, Юр. Давай для начала поймем, за что отвечает дизайн-директор по продуктам в Mail.Ru?

Компания делится на продуктовые направления, я отвечаю за дизайн в нескольких из них.

У меня такие группы задач:
- Координация работы дизайнеров, помощь менеджерам в работе с ними.
- Найм и развитие команды.
- Задание направления для дизайна продуктов и его координация.
- Маркетинг нашей экспертизы для усиления бренда (публикации, конференции и т.п.).
- Работа руками, там где хватает времени.

В разных продуктах разная ситуация, поэтому эти обязанности комбинируются по-своему — где-то это всё и сразу, где-то, например, только помощь дизайнеру в развитии. В других подразделениях компании всё устроено по-своему; общий глава дизайна вряд ли возможен, учитывая разнообразие направлений и подходов (игры, социальные сети, e-commerce).

— В прошлом году вы искали аутсорс-дизайнера на продуктовые лендинги. В каком случае вы привлекаете внешних специалистов?

Работа над самим продуктом всегда делается внутри команды. Это позволяет быстро пробовать уйму разных направлений развития и экспериментировать с дизайном; скорость реакции и погруженность дизайнера тоже наилучшие только в таком формате.

Но для части маркетинговых задач (промо-сайты, иллюстрации, баннеры и т.п.), либо там где у нас нет сильной экспертизы и мало практических задач для её развития (например, шрифтовой дизайн, видео-продакшен, брендинг) — иногда обращаемся к внешним студиям. Ещё один повод — если нужно сделать прорыв в продукте и важно посмотреть на проблему со стороны (бывает, что ограничения слишком давят на дизайнеров внутри), здесь иногда заказываем концепты сторонним дизайнерам или студиям (и сами думаем параллельно). Вот неплохо описан процесс работы над брендом My.com, который шёл по такой схеме — be.net/gallery/10980469/Mycom-Identity.

— Вы уже давно занимаетесь развитием своей дизайн-системы Paradigm. Что бы ты сделал по-другому, начиная работать над ней сейчас?

Да, мы начали работу над технологическим фреймворком для дизайн-системы ещё в 2012 году, а первые продукты на ней запустились в 2013. Тогда тема была сырой как идеологически, так и технологически, так что путь приходилось прокладывать по ходу и я уверен, что можно было бы сделать всё гораздо быстрее, имея огромное количество публикаций и примеров, которые есть сейчас.

Я бы начал с идеи токенов (файлов с переменными, которые легко описать и раздавать в любые технологические фреймворки — medium.com/eightshapes-llc/tokens-in-design-systems-25dd82d58421). Мы переводим Paradigm на эту архитектуру с прошлого года и это оказалось настоящей серебряной пулей — здорово сокращает расхождения, очень легко найти общий язык с фронтендом, для многих продуктов это очень дешёвый первый шаг перехода на Paradigm. Весной мы про это подробно расскажем.

— Как ты видишь её дальнейшее развитие?

Ничего особенного, просто чтобы она работала как задумано :) Это самое сложное — хотя дизайн-система начинает давать выхлоп очень быстро, путь к оптимальному состоянию очень длинный.

Из ключевых планов:
- Перевод на архитектуру токенов и замена полу-живого гайдлайна на настоящий живой.
- Раздача токенов в мобильные приложения.
- Перевод большего количества продуктов на дизайн-систему.
- Связка шаблонов в Sketch c настоящими компонентами в коде, чтобы их не пришлось поддерживать вручную.
- Сделать дешёвую адаптацию живого гайдлайна под мобильные. Нам для работы это вообще не надо, но устали получать пинки от сообщества.

Дюжина типов мышления среди дизайнеров

Дюжина типов мышления среди дизайнеров

Есть дюжина типов мышления среди дизайнеров. Выделим пару. Одни уверены, что дизайн это сервисная деятельность, к тебе пришли с конкретной задачей и ты находишь несколько вариантов решения, одно из которых удовлетворит все требования. К тебе пришли за владением инструментом — за набором.

Дизайн как решение задачи — «Найти вариант написания для вывески “Мы открылись”»
Дизайнер анализирует аналоги, конкурентные решения, область деятельности и принятые там законы визуального языка, начинает подбирать размеры, шрифт, цвета, композицию, материалы — добиваясь удобства и визуальной грамотности сообщения. Возможны десятки хороших решений, каждое из которых будет работать.

Второй тип мышления воспитывает отношение к дизайну, как к деятельности созидательной, результатом которой является трансформация исходной ценности, зачастую формулирование самой проблемы в расширении ценности исходного объекта.
Дизайн как расширение задачи — «Найти вариант написания для вывески “Мы открылись”».
Дизайнер анализирует сотни похожих решений, сочетаний слов, композиций, шрифтов и понимает, что ценность сообщения будет выше если его филологически разработать. Начинает разбираться с функцией слов, смыслом сообщения, желаемым результатом. Возникающей эмоциональной связи. Начинает складывать новые слова в комбинации в рамках 12-15 знаков.

Простые альтернативы с демонстрацией заинтересованности, от самоуверенной радости «А вот и мы!» (10 знаков), до нейтральных «Заходите в гости» (16 знаков, перебор), «Мы вам рады» (11 знаков), до буквальности и констатации выгоды — «Вкусно — здесь!» (13 знаков).

А после уже начинается работа по визуальному конструированию вывески, но которую уже должны заметить, увидеть смысл, новую ценность от работы дизайнера, шире диапазон воздействия.

Вопрос: есть команда из трёх человек

Вопрос: есть команда из трёх человек: сильный разработчик, который делает быстро, но поверхностно; есть слабый разработчик, который делает медленно, но работающий код (и часто переделывает за сильным) и есть тимлид/пм (я), который не сильно разбирается в коде. Сильный буллит слабого, что тот не разбирается и вообще плохой программист. Что делать?

Давайте для начала разберёмся, почему вы считаете сильным того программиста, который буллит? Судя по вашему описанию, второй программист гораздо сильнее, чем первый — за ним не приходится переделывать.

Человек, который внутренне уверен в себе и своих знаниях, вряд ли будет когда-нибудь кого-нибудь буллить, так что я бы поставил под сомнение компетентность первого, как разработчика.

Подумайте внимательно, насколько поведение первого программиста совместимо с профессионализмом на работе в вашем представлении? Как далеко он заходит в своём буллинге? Если недалеко (хотя мне сложно такое представить) — отправьте его на месяц или два в отпуск, посмотрите как команда поживёт через него. Если сильно — немедленно увольняйте, иначе второй просто сбежит или, ещё хуже, превратится в фикус, и вы в любом случае останетесь без двух программистов.

Корректура в конце

Как думают обычные люди: исправление орфографических ошибок — главная обязанность редактора.
Как на самом деле: корректура — незначительный этап, который оставляют на конец.

Сейчас в меня полетят помидоры от магов корректорской гильдии, но я должен об этом сказать. Орфография переоценена. Да, ошибки снижают доверие и обидно оскорбляют русский язык и Розенталя лично. Но разве «тся или ться» — это главное в жизни?

У меня тоже есть дурацкая привычка писать грамотно, даже в чатике о выдрах. И такая борьба с ошибками часто становится чем-то вроде прокрастинации. Я поправляю двойные согласные и расставляю запятые, хотя прекрасно понимаю, что после отправки дизайнеру всё может десять раз поменяться.

Понятно, что текст, в котором много ошибок, стыдно показывать людям. Но сильно заморачиваться тоже не стоит. Лучше сосредоточиться на чем-то более важном, а ошибки чекнуть перед релизом.

Потому что запятую скорее всего простят, а вот бесполезность и алогичность — нет.