Самое важное в резюме

Резюме — это лэндинг, на который должен сесть работодатель.

Самая ценная часть резюме — опыт.
Самая ценная часть в опыте — достижения и наличие отзывов с прошлых мест работы.

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

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

Карьерный путь у разных профессий разный

Карьерный путь у разных профессий разный

Но с годами я заметил несколько универсальных этапов по которым развивается лидерство:

◾️1. Вы Стажер. Вы умеете выполнять поручения, действуя по инструкции. Иногда ошибаетесь. Ваша миссия: учиться.

◾️2. Вы Ассистент. Вы умеете выполнять не четко сформулированные задания. Задаёте уточняющие вопросы когда требуется. Ваша миссия: помогать.

◾️3. Вы Исполнитель. Самостоятельно отслеживаете задачи по мере поступления. Выбираете одно из подходящих известных решений. Ваша миссия: следовать процессу.

◾️4. Вы Специалист.Вы полностью берете на себя ответственность за решение задач и приходите с планом. Придумываете нестандартные и уникальные решения. Ваша миссия: решать проблемы.

◾️5. Вы Эксперт. Вы полностью отвечаете за область сложных задач и разрабатываете лучшие решения самостоятельно. Вы - "ракета с лазерным наведением": когда вам указали на цель, вы точно ее достигните. Ваша миссия: находить лучшее решение.

◾️6. Вы Ведущий Эксперт. Вы не только самостоятельно находите решения, но теперь вы ещё и формулируете новые задачи. На этом этапе вы "ракета с тепловым наведением" - чувствуете цель и следуете за ней. Ваша миссия: видеть новые задачи и возможности.

◾️7. Вы Управленец. Вы идентифицируете задачи и находите людей, которые их решат. Нанимаете и управляете сотрудниками. Ваша миссия: строить структуру, способную находить и решать задачи.

◾️8. Вы Директор. Вы отвечаете за стратегию и культуру команды. Находите, растите и назначаете управленцев. Дизайните структуру команды и процессы. Ваша миссия: создать среду в которой сформируется структура, находящая и решающая задачи.

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

https://www.instagram.com/p/CGu5JUZJyGk/

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

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

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

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, которыми вы пользуетесь/пользовались сами, когда искали работу за рубежом - включу их в список.

Принесла вам новый обзор на книжку Blitzscaling от Reid Hoffman, основателя LinkedIn.

Reid очень крутой и умный, у него отличнейший подкаст Masters of Scale, и на книгу у меня были высокие надежды.

Ну что сказать… Начали за здравие, кончили за упокой. Основная мысль довольно интересная – если хочешь стать глобальным стартапом, то в какой-то момент нужно ставить все на карту и инвестировать в взрывной рост: тогда приходят в действие network и virality effects, которые, в свою очередь, еще больше ускоряют рост и выручку.
С идеей можно, конечно, поспорить: например, Harvard Business Review в последнем выпуске восхваляет стартапы, которые фокусируются на постепенном и контролируемом росте https://hbr.org/2020/03/beyond-silicon-valley (https://hbr.org/2020/03/beyond-silicon-valley), – но о подходе, о котором рассказывает Reid, почитать тоже интересно, тем более, что его использует большинство стартапов в Долине. Понравились примеры с AirBnb и Dropbox.

Про это рассказывается на первых 100 страницах, все остальное (еще 200 страниц) – вода водой. Сначала Рид говорит, как успешно задизайнить бизнес-модель: по сути, это все те же старые-добрые постулаты из книжек 80-х годов про размер рынка, дистрибуцию, высокую маржинальность, (не)возможность масштабирования операционки, product market fit + из относительно новенького network effects. Если с network effects вы раньше не особо встречались, то эта часть, возможно, покажется интересной.

Части 3-6 – такие относительно философские рассуждения на тему, с пересказом идей из других книг или предыдущих глав. Мне очень это все напомнило The Hard thing about hard things https://t.me/proproduct/681 (https://t.me/proproduct/681), где автор под конец уже явно выдавливал из себя главы на немного рандомные темы. Знаю, что обе эти книжки многим нравятся: возможно, если вы заценили The hard thing, Blitzscaling вам тоже зайдет. Как говорится, на вкус и цвет :)

Вот здесь лежат отзывы на другие продуктовые книжки (не поверите, там даже есть позитивные))
https://medium.com/@buldakova/the-product-managers-reading-list-2019-fbaa226cb0fe (https://medium.com/@buldakova/the-product-managers-reading-list-2019-fbaa226cb0fe) ^_^

Андрей Шапиро написал серию статей о методологии сбора требований и планирования релизов программного продукта User Story Mapping

Часть 1. Пользовательская история: https://medium.com/xraizor/b0b0d724d77e

Карта историй создаётся для нового продукта или когда существующий продукт надо частично или полностью переделать, и требуется описать объём имеющейся функциональности.

На входе метода: гипотезы состава стейкхолдеров, их интересов и основных планируемых эффектов ближайшего релиза. Хорошо, если есть картирование процессов в форматах Customer Journey Map или Service Blueprint.

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

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

Любая пользовательская истории записывается для действующего лица: персоны или функциональной роли в системе. Близкая методика Use Cases лишена эмпатии к человеку, для которого создаётся программа.

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

Часть 2. Алгоритм проведения и рекомендации для ведущего: https://medium.com/xraizor/9a90beb2ff57

Часть 3. Чистка историй от ложных требований. Критика метода: https://medium.com/xraizor/2f7bd967a54a

Чинить баги по TDD

Один из кейсов, которые я рассмотрю на своём мастер-классе 26 октября (https://tdd.timepad.ru/event/1074439/?utm_source=telegram&utm_medium=messenger&utm_campaign=mypost-bugs) — это исправление багов по TDD.

Вот прилетает к нам задача, скажем «Жму на кнопку — не работает». Обычно мы чиним такие баги весьма тупо — поднимаем фронт и бек, придумываем гипотезу, и начинаем дебажить: вносим исправление и жмём на кнопку. Если заработало — отлично, если нет — просто перебираем дальше гипотезу за гипотезой. Иногда мы перебираем гипотезы настолько беспорядочно, что даже не убираем следы предыдущих попыток.

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

Правильный процесс выглядит так: открываем контроллер в API, куда ходит кнопка, а дальше ставим под сомнение каждый нижележащий метод, проговаривая про себя гипотезы, к примеру: «я сомневаюсь, что метод get_users() не возвращает неактивных пользователей». Если сразу не находим теста, который доказывает обратное — пишем свой. Если тест падает — отлично, у вас уже есть тест, и остаётся только написать код. Если написанный тест не падает — git checkout --, и ставим под сомнение следующий метод.

Такой процесс заставляет вас тестировать баги изолированно — вы никогда не натолкнётесь ещё на один баг, который создали во время предыдущих бесплодных попыток. А ещё вы никогда не отправите в прод неработающее говно, потому что у вас нет состояния «кажется всё заработало» — всё или заработало, или нет.