Русский
Русский
English
Статистика
Реклама

Опыт работы

Amazon, Microsoft, Facebook, Tesla, Lyft история поиска работы мечты или вредные советы для карьерного развития

19.04.2021 10:09:21 | Автор: admin

Всем привет!

Я давно хотел поделиться советами и своим опытом к прохождению интервью и развития карьеры. Пока думал про заголовок, вспомнилась книга из детства - "Вредные советы". Но в Отличие от Григория Остера, мои советы могут вам пригодится.

У меня за плечами 11 лет работы в индустрии, 6 из них в Северной Америке. Сейчас я работаю инженером данных в Microsoft Ванкувер. До этого почти 5 лет проработал в Амазоне в Ванкувере, Бостоне и Сиэтле.

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

Возможно вы найдете много оЧепяток. но, к сожалению, грамматика не мой конек, не то, что хождение по собеседованиям, где я как "рыба в воде".

2013 год, только что провалил онлайн собеседование в Берлин, наверно им не понравились мои носки2013 год, только что провалил онлайн собеседование в Берлин, наверно им не понравились мои носки

Прежде чем перейти к компаниям типа Amazon и Microsoft, я хочу начать с простых примеров.

Начало работы

По образованию я инженер конструктор, я честно пытался работать по специальности (целых 3 года).

Мое рабочее место с секретного предприятияМое рабочее место с секретного предприятия

Пока я не узнал, что ассистент проект менеджера получает 50 тысяч рублей (в 2009 году), в то время как начальник участка металлообработки космического центра получает меньше 20 тысяч рублей.

Совет 1: Если вы думаете, что в будущем у вас будет классная работа и хороший доход, вам только нужно проработать Х лет, закончить аспирантуру/учебу, пройди Y курсов и сдать Z сертификатов. Проверьте свои доводы на деле. Возможно вы можете сэкономить время, ресурсы и деньги.

Теперь я знаю, это называется проверка гипотезы. Работая на заводе, я решил проверить гипотезу. На Head Hunter (HH), я сделал резюме, написал, что у меня уже на руках несколько лет опыта, аспирантура и стал откликаться на вакансии.

Я обнаружил, что все вакансии в Подмосковье и зарплаты смешные. И тут я призадумался о судьбе машиностроения в РФ. Как видно не зря.

Когда я учился в университете, то очень хотел попасть на стажировку в Европу. Но в какой-то момент их просто отменили. Следующая картинка очень в тему.

Это я в Копенгагене встретил бабульку (слетал на тренинг от работы). Примерно тоже самое сказал мне декан на вопрос об иностранной стажировке.Это я в Копенгагене встретил бабульку (слетал на тренинг от работы). Примерно тоже самое сказал мне декан на вопрос об иностранной стажировке.

Пришлось переквалифицироваться. До сих пор переквалифицирываюсь. В ИТ пока одно учишь, уже другое появляется, а то что учил уже устарело.

Совет 2: Fake it till you make it. (FITYM)

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

Даже с моим подходом FITYM я не достиг особых успехов, было 2-3 собеседования. Пока не предложили стажировку в банке в департаменте ИТ на должности разоботка отчетности (Business Intelligece). Меня спросили всего один вопрос - "знаю ли я, что такое SQL?". Несмотря на то, что я слышал это слово первый раз, я с увереностью сказал - "Конечно знаю, у меня даже в дипломном проекте был SQL".

Совет 3: Рискуйте. Мы живем один раз, лучше рискнуть. Как сказал Юрий Дудь: Не страшно ошибаться страшно быть унылым г****м

И тут возникает несколько вопросов, своеобразный FAQ:

  1. Если наврать, что есть опыт, а по факту окажется, что его нет, и выгонят с позором.

    Конечно нужно знать пределы. Не нужно говорить, что вы Java архитектор, если вы только недавно написали свою первую программу "Hello, world". Но если вы в теории знаете как решить проблемы, где найти ответ, как правильно сформировать вопрос, то вы не пропадете. Так же процесс поиска сотруднака - это не трудоемкий и затратный процесс. Ваши скилы это лишь часть картины, важно еще насколько вы впишетесь в коллектив. Так же по началу вы сможете компенсировать нехватку опыта временем. Работайте по 16 часов в день без выходных, и вы разберетесь.

  2. В моем резюме не релевантный опыт.

    Первое, с чего мы начниаем, мы переписываем резюме. Пишем туда тот опыт, который необходим для работадателя. Я ниразу не встречал случая, когда рекрутеры сверяли ваше резюме с вашей трудовой. Будьте креативными, напишите в резюме то что вам нужно. Оставьте только "место работы" и "даты работы". "Должность" и "обязанности" можно написать те, которые вам нужны.

  3. Хорошо, с резюме проблем нет. А как же трудовая книжка?

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

  4. А что делать со службой безопасности?

    У крупных компаний, есть служба безопасти. Вы для них лишь ФИО, и они могут вас "пробивать". Тут уже как повезет. Можно оставить телефон друзей, можно договориться. У меня был случай, когда меня проверяли на детекторе лжи. Но ничего, получилось пройти. Для них главное, что у вас криминала нет.

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

Смена работы - из банка в ИТ вендор

1.5 года работы, и уже у меня неплохой опыт, можно выходить на рынок.

Совет 4: Вероятность того, что вы будете впахивать и вам удвоят зарплату стремится к 0. Единственный способ поднять зарплату или должность - это найти новую работу.

Совет 5: Не увольняйтесь, пока у вас не будет оффера на руках.

Совет 6: Не сжигайте мосты, нужно стараться всегда расставаться в хороших отношениях с коллегами.

На собеседование как обычно, меня спрашивали вещи, про которые я лишь где-то слышал. Можно сказать 50% я знал на отлично, другие 50%, на 3-. Хорошо, что им были важны первые 50%.

Я работал в Терадата - это американская компания. Но проекты были в Сбербанке, то есть приходилось много времени проводить в бывших детских садиках/налоговых, сражаться за удобный стул (не сломанный) с другими консультантами и интеграторами.

Стул так себе...Все было ничего, пока нас не спалили, что мы играли в Counter Strike 1.6 в рабочее время=0Стул так себе...Все было ничего, пока нас не спалили, что мы играли в Counter Strike 1.6 в рабочее время=0

Совет 7: Изучите все возможности внутри компании для личностного развития.

Еще до начала работы в Терадата, я уже знал о возможности слетать в Европу на тренинги. Поэтому всеми правдами и неправдами я пытался посещать тренинги. Для этого нужно было быть проактивным.

На Sales тренинге в Мюнхене от Терадаты. Мюнхен запомнил на всю жизнь, а тренинг так себе был))На Sales тренинге в Мюнхене от Терадаты. Мюнхен запомнил на всю жизнь, а тренинг так себе был))

Совет 8: Будьте проактивными. Общайтесь с людьми, ищете возможности для колалборации и для получения новых знаний.

Чтобы быть проактивным, я стал делать тренинги для других консультантов. Провел несколько воркшопов для коллег. Так же я копался во внутренней Wiki и нашел контакты компаний партнеров. Я всем написал письма и получилось организовать несколько встреч и воркшопов. К нам даже прилетали из Европы и обучали партнерским решениям. Мы их не использовали и врят ли бы они пригодились. Но я знал, что для моего резюме и опыта они пригодятся.

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

Смена работы - из ИТ вендора в обувной стартап

Согласно "совету 4", настало время повышать зарплату и менять работу. В данном случае работа нашла меня сама. Это тот случай, когда проактивность приносит дивиденды. Мой бывший руководитель попросил меня провести тренинг и потом предложил присоединиться.

Ламода и Сбертех были в соседних зданиях, было удобно к ним заходить. Фото с тренинга кстати.Ламода и Сбертех были в соседних зданиях, было удобно к ним заходить. Фото с тренинга кстати.

Совет 9: Всегда имейте запасной вариант. Неважно где вы сейчас работаете, всегда имейте план "Б". Я люблю проводить аналогию с тем, как мы карабкаемся на гору. В любой момент времени мы можем упасть, поэтому когда мы делаем движение вперед (вверх) мы обязательно продумываем, на несколько шагов вперед. Если мы сделаем неаккуратный шаг, то мы не упадем, так как у нас был план "Б". Где бы я не работал, я всегда смотрю в будущее и рассматриваю возможные сценария для себя.

Было интерсно поработать в еще одной международной компании, но все как обычно - "денег нет, но вы держитесь"(с). Проработав там 1.5 года, я снова вышел на рынок и поднял свою зарплату до 180 тысяч рублей. Тогда еще курс был 30 рублей за доллар. Это было классно. Но не долго я радовался, через 6 месяцев рубль обвалился. И все мои рублевые накопления на иммиграцию превратились из "кареты" в "тыкву".

Совет 10: Мотивируйте себя сами. Часто работа бывает не интересная, скучная. Поэтому вам нужно придумать себе, почему она интересная, почему ее надо сделать. Например, вы делаете аудит или работаете на поддержке. Это скучно. Превратите эту скучную историю в крутую историю. Расскажите на собеседовании, как вы выполняли тяжелую работу и каких результатов достигли.

Смена работы - из Москвы в Черногорию

Пока мои документы в Канаду процессились, я прошел собеседование на Веб Аналитика в Черногорию. Я раньше не работал веб аналитиком и были очень поверхностные знания по маркетенгу. Тем не менее, я попал на работу и уже на месте стал разбираться, что такое digital marketing.

Черногория это пушка! На фото Свети Стефан. В Канаде хорошо, но в Черногории еще лучше!=)Черногория это пушка! На фото Свети Стефан. В Канаде хорошо, но в Черногории еще лучше!=)

Совет 11: Для того, чтобы пройти собеседование и говорить уверенно о вещах, с которыми вы раньше не работали, вам нужно использовать метод Стива Джобса (тоже узнал про него относительно недавно, несмотря на то, что всегда использовал) - "поле искажения реальности". Я упомянул "fake it till you make it". Что звучит немного грубовато - приврать (в лучшем случае). Теперь же мы можем использовать почти научный способ из сериала Звездный путь - поле искажения реальности. Это значит нам нужно верить в то, что мы говорим.

Совет 12: Чтобы начать верить в то, что мы говорим, нам нужно рассказать эту историю раз 15-20 минимум. То есть прежде чем проходить серьезные собеседования, нам нужно потренироваться на "кошках", найти компании и вакансии попроще, и рассказывать им свою легенду. Если често, я уже давно поверил, что на заводе я работал с SQL, базами данных и аналитикой. Меня ночью разбуди и я не задумываюсь расскажу об этом.

На столе книга по Adobe Site Catalyst - получаю первые знания по свеой новой профессии.На столе книга по Adobe Site Catalyst - получаю первые знания по свеой новой профессии.

Совет 13: Вне зависимости от того, что вам дают на работе, всегда имейте north star, вектор развития и движения. Вам надо двигаться к вашей цели. Я мало времени уделял веб аналитики, зато стал проявлять проактивность и делал BI, установил Tableau, сделал Proof of Concept на Redshift, делал ETL. Я создавал себе "истории" для своего резюме и опыта. И еще по возможности все писал в блог на английском - создавал "активы" для своего резюме.

В Черногории я проработал не долго, так как получил документы в Канаду. У меня было несколько интерсных собеседований в Европе. Одно из них было в Accenture, было все позитивно, но уже у меня были билеты в Канаду.

Едим в поезде из Черногории в Белград. Ознакамливаюсь с историей Канады. В книге времен СССР автор часто упоминает коммунистические партии Канады!)Едим в поезде из Черногории в Белград. Ознакамливаюсь с историей Канады. В книге времен СССР автор часто упоминает коммунистические партии Канады!)

Совет 14: Ходите на собеседования всегда и везде. Никогда не упускайте возможности сходить на собеседование. Особенно, если у вас все хорошо и вы не ищете работу. Лучше выбирать работу без спешки и стресса. Тогда можно ВБИРАТЬ, а не браться за первую попавшую. Тогда не придется лишний раз врать и можно быть собой. В Linkedin я видел пост чувака из Google. Он задал этот вопрос своему ментору. Ментор ему именно так и сказал. Задача работадателя создать вам комфортные условия на работе, дать конкурентнуспособную зарплату. Если, кто-то предложил больше, вас либо оставят (попытаются перекупить), либо отпустят (так как вы не нужны). Поэтому от этого выигривают все. Конечно, нужно это делать так, чтобы никто не знал, что вы это делаете:)

Я даже проводил опрос в своем телеграмм канале:

Сейчас я уже немного разленился, и мне жалко времени на собеседования, но я могу себе это позволить, у меня отличный опыт хождения по собеседованиям;)

Смена работы - из Черногории в Канаду

Совет 15: Если вы готовитесь к переезду, начните искать работу заранее. За год или 6 месяцев. Подпишитесь на еженедельные рассылки вакансий, добавляете людей в Linkedin, общайтесь и знакомьтесь. Вы сэкономите много денег и времени в будущем.

Я приехал в Канаду в Виннипег и вышел на работу уже через 5 дней в страховую компанию на 75 тысяч канадских долларов, это где-то 4 тысячи в месяц. Так как у меня был offer на руках и меня уже ждали.

Офис кубик. В выходные я работал сверхурочно за 2ю оплату, чтобы выплатить наш первый кредит за Dodge Journey. Сына иногда брал в офис поиграть рядом. Офис кубик. В выходные я работал сверхурочно за 2ю оплату, чтобы выплатить наш первый кредит за Dodge Journey. Сына иногда брал в офис поиграть рядом.

Как я нашел работу еще до моего приезда? Ответ очевиден, я использовал свои советы.

Я расскажу про некоторые техники, которые мне помогли:

  1. Я подписался на рассылка вакансий в моей провинции на indeed.ca

  2. Я сделал себе резюме, в котором указал fake местный адреc. Так же я сделал себе IP телефон с кодом Виннипега. Он делал переадресацию на мой мобильный. Моя задача была, чтобы HR соединил меня с hiring manager. В итоге мой план сработал.

  3. Был еще один life hack. Вместо cover letter (по мне вообще бесполезная бумажка), я отправлял презентацию со slideshare. Вот пример довольно старый. Основая идея была показать не мой опыт и мои скилы, а рассказать о ценности, которую я могу добавить компании. Нужно раскрыть тему своей ЦЕННОСТИ, попробовать указать проблемы индустрии, показать, что вы с ними знакомы и знаете решение. Slideshare имеете интересный функционал. Мы можем скрыть презентацию от всех, и оставить доступ только через ссылки. А потом показать нам, откуда (по IP) и сколько раз открыли. То есть инструменты веб аналитики. Так мы можем измерять вовлеченность.

Смена работы - из страховой в Амазон

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

Совет 16: Будьте аккуратны с шуточками. Женская половина коллектива приняла в штыки мои безобидные шуточки. Как результат, меня стали подставлять.

Я благодарен коллегам за их попытки вывести меня из себя, так как я нашел работу в Амазоне. У меня был еще один offer от местного стартапа Skip The Dish, которые теперь довольно популярный. Я написал основателям и пришел к ним на встречу, принес книгу, которую я написал (первая моя книга). Они мне предложили возглавить отдел аналитики. Я взял паузу и решил еще поискать варианты. Как видно не зря.

И теперь можно поподробней поговорить про процесс собеседования в Амазон. Это я теперь эксперт по собеседованиям, потому что провел их больше 50 внутри Амазона и закончил тренинги. А тогда вообще не знал ничего. Уверен, что мне сильно повезло.

Совет 17: Если вы ищете работу, используйте "ковровую бомбардировку" - что значит отвлекайтесь на все вакансии по специальности по максимум, потом разберетесь. Возможно получите важный опыт переговоров и собеседований. Который вам поможет найти работу мечты.

Я обычно завожу spreadsheet и туда заношу всю информацию:

Поиск работы в КанадеПоиск работы в Канаде

У меня был неплохой опыт, пару книг в публикации, блогпост, но искать работу это не быстро. Главная сложность заключается в том, что на каждую вакансию откликается человек 30-50-100 (в зависимости от компании). Соответственно, если ваше резюме будет 81 в списке, не думаю, что компания узнает о таком ценном кандидате. Поэтому важен нетворкинг, скорость отклика и немножко удачи, чтобы получить свой шанс.

У меня были примеры в Google, когда рекрутер просто пропадал, из-за того, что мы не могли выбрать время. У них все просто, они готовы потерять хорошего кандидата, потому что в итоге всеравно придет другой хороший кандидат. Поиска работы в FAANG компания это почти как лотерея. Поэтому очень важно искать туда нестандартные входы.

Мне повезло, я получил приглашение на собеседование.

Совет 18: Вам нужно конкурентное премимущество. Чем вы лучше других кандидатов? Это можно быстро продемонстрировать за счет дополнительных артифактов - блог, выступления на конференциях и митапах, youtube канал. У меня были книги и блогпост. В Амазоне они оценили наличие этих артифактов.

Собседование в Амазон

Amazon Leadership Principals уже в моем DNA.

Процесс собеседования примерно такой:

  1. Phone Screen - вам звонят, задают разные вопросы, технические и не технические. Посмотреть насколько вы подходите.

  2. Может быть еще Phone Screen собеседование, но уже с hiring manager. Так же вам могут прислать тестовое задание. Я был настолько проактивным, что решил тестовое задание 3мя способами и еще нарисовал им дашбордов, хотя они не просили.После был еще уточняющий звонок по тестовому.

  3. Если прошли этот этап, то можно рассчитывать на on-site interview. (в до ковидные времена). Мне купили билеты и запланоривали 5-6 собеседований, включая обед с командой.

На собеседование я принес свою коронную презентацию (мой cover letter на slidesashare). Технический директор сразу сказал, это лишнее. И начал мне завадавать вопросы и записывать мои ответы. И так делали все остальные. Иногда вопросы повторялись.

Уже сейчас я знаю, что это было. Само интервью состоит из 2х частей:

  • behavioral interview - ситуативное интевью

  • functional interview - ваши технические навыки

Цель behavior interview - проверить вас, насколько вы соответствуете Amazon Leadership Principles. А их 14. Как правило, сотруднику поручают 2 принципа. Дальше он идет в "банк вопросов", копирует по 2-3 вопроса, с которых начинается дискуссия. А потом они пишут отчет, как у вас дела с этим принципом, вам надо, как говорится meet the bar. То есть быть не хуже, чем 50% человек на этой роле. В общем, надо с покер фейс заполнить отчет, и сказать, кандидат тянет или нет.

Примеры моих вопросов:

Amazon LP - Ownership

Q: Tell me about a time when you took on something significant outside your area of responsibility. Why was it important? What was the outcome?

Amazon LP - Insist on the Highest Standards

Q: What measures have you personally put in place to ensure performance improvement? What targets and standards are achieved?

Лучше всего отвечать на такие вопросы в формате STAR:

  • Situation - ситуация/проблема

  • Task - задача

  • Action - ваши действия

  • Result - результат

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

Спустя неделю мне позвонили и сделали оффер. Я не посмел торговаться. Зарплату дали маленькую по меркам Амазона - 90 тысяч CAD в год + signup bonus + 80 акций Амазон на 4 года. (их цена тогда было 600$, то есть 48 000 CAD на 4 года). Я был очень рад и мы двинулись в Британскую Колумбию. Мне дали уровень 5 (L5):

levels.fyilevels.fyi

L5 это middle. Первые два года я работал очень много. Я надеялся, что если буду хорошо работать, меня повысят, мне прибавят денег. Я был наивный.

Совет 19: Он очевидный, и вроде мы про него знаем, но никогда не делаем. Необходимо чуть ли не с первого дня прописать все цели, за выполнение которых последует повышение. Возможно это будет на следующие 12-18 месяцев. Но это единственный вариант в Амазон. В моем случае, я наивно впахивал 2 года, и на вопрос о повышении, мой менеджер тактично меня осадил, расскзаал про цели, о том, что их надо прописать и тд.

В Амазоне есть performance review раз в год, где-то в феврале. Перед этой встречей, вам необходимо запросить feedback у ваших коллег. Коллеги вас будут оценивать по 2м показателям:

  • Ваши Super Powers (читай Leadership principalse), которые вы проявили.

  • Ваши Grow Areas (читай Leadership principals), которые вам нужно прокачать.

По результатам всей это истории, вам могуть поднять зарплату на 1-4%. Менеджер расскажет о том, как он/она приложили нечеловеческие усилия, чтобы это сделать. Вам добавили денег на лишний капучино в неделю, 1-4% это до вычета налога.

Если вам повезет, вам добавят Amazon Stock. За 5 лет, мне дали наверно 25 акций, помимо моих 80ти, которые я получил в 1й день работы. Это конечно мало. Хороший показатель это акций 20-40 в год. Все это очень завивист от вашего менеджера.

Все 5 лет на мой вопрос "почему моя зарплата так медленно растет", я получал ответ, что Amazon Stock очень вырос.

Стоки действительно выросли от изначальной стоимости. Но я был категорически не согласен с политикой партии. Стоки я получил в 1й день работы. И даже, если бы я работал так себе, я бы все равно их получил. А за свой performance, переработки и любовь к тому, что я делал, я получил 2-4% прироста к зарплате. Обычно это назвается индексация.

Чтобы в Amazon получить повышение, вам необходимо заполнить несколько документов, причем 60% усилий должен сделать ваш менеджер. Это целая стретегическая игра, которая не очень тесно связана с вашими техническими компетенциями. Поэтому очень важно (совет 19) прорабатывать стратегию заранее и обсуждать ее с менеджером. Задача компании получать от вас максимум, платить минимум.

Совет 20: Ваша зарплата в 95% случаев будет такая, на которую вы изначально пришли. Моя зп в Амазоне выросла на 10% за 5 лет. И если бы я даже перешел бы на L6 (следующий уровень), то она бы выросла еще на 10-15%, что было бы достаточно низко. Как в совете 4, хотим роста, меняем работадателя, но важно, чтобы у нас был solid case и хотя бы 12 месяцев опыта на текущем месте работы.

Смена комманд в Амазон

Амазон это оргормная корпорация. В ней огромное множество комманд и направлений бизнеса. У вас есть возможность перейти в любую команду по всему миру. Много знакомых американцев переехало в Европу и наоборот, из Европу в США и Канаду.

Проработав 2,5 года в одной команде я был сыт обещаниям менеджера о повышении. И решил попробовать поискать другие команды.

Совет 21: Он очень важный. У нас есть одна особенность, мы привыкли винить в неудачах других - "все дураки, один я умный". Примеров огромное множество. Это очень плохая позиция. Старайтесь избегать такой точки зрения. Из моей карьеры я только года 2 назад стал меняться и научились брать ответственность за свои поступки и не считать себя умней других. Например, я прекрасно понимаю, что это только мой личный fail, что я не смог получить повышение в Амазон. Поэтому, никогда не считайте себя умней других. Если вы знаете что-то лучше других, помогите им разобраться и понять. Если кто-то накосячил, на то есть причины, помогите человеку преодолеть трудности. Но никогда не думайте, что вы лучше других. И вам будет легче жить и легче добавиться поставленных целей.

Я находился на West Coast побережье и нашел работу инженера данных на East Coast побережье.

Вид из Cambridge, MA на Boston, MAВид из Cambridge, MA на Boston, MA

Интересный парадокс. Зарплата не высокая, но есть возможность получать другие benefits. Например, летом я перешел в команду Amazon Alexa, которая находилась в Cambridge, MA (оказывается есть такой город и в США). В нем находятся MIT и Harward. А если перейти мост, то будет Бостон.

Еще одно #dimaworkplaceЕще одно #dimaworkplace

Всей семье мы полелетели в Бостон на 2 месяца, чтобы я мог познакомиться с командой. Нам сняли квартиру в 5 минутах от офиса и от MIT. Цена в месяц 12тысяч US$. Так же оплатили всю еду и мой билет на самолет. Лето в Бостоне с семьей - бесценно.

В течение года я еще несолько раз летал к ним и останавливался в Airbnb в историческом центре Бостона.

Beacon Hill - самый старый район БостонаBeacon Hill - самый старый район Бостона

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

Ночной СиэтлНочной СиэтлМои значки и communities из личного кабинета Амазон, некоторый я сам сделал. Наиболее ценные для меня это значки "Speaker".оМои значки и communities из личного кабинета Амазон, некоторый я сам сделал. Наиболее ценные для меня это значки "Speaker".о

Кстати, с Amazon Alexa я познакомился когда выступал на конференции в Бостоне - Enterprise Data World. Я уже 2ой раз выступал на этой конференции. 1й раз бьл в Сан-Диего. Было тепло. А тут начало марта, очень холодно. Выступление на конференции дает только бесплатный билет. Конференция идет 6 дней и стоит 3500US$. Спикерам бесплатно, но билеты и отель за свой счет. Я снял Airbnb коморку за 100$ в сутки, комната 2 на 2 метра.

По пути в Бостон на конференцию EDW2019По пути в Бостон на конференцию EDW2019

Совет 22: Возможно я уже про это говорил, скажу еще раз! Если вы серьезно занимаетесь своей карьерой - на все возможные opportunities всегда говорите да. Мне было очень не комфортно первые несколько лет. Сейчас уже конечно стало лучше. Ставьте себе цель - выступить на meetup, usergroup, податься на конференцию, рассказать о своем опыте на datalearn.ru ;)

Кроме конференций, мне нравится делать что-нибудь еще, например у сына во 2м классе я проводил Amazon Future Engineer - Hour of Code. Или волентерил в университете, или выступал в high school. То есть делал буквально все, что было в моих силах. На вопрос "Зачем?!" - я думал, что пригодится. Каждая возможность пораждает новые возможности и знакомства. Если ничего не делать, то ничего не будет.

Рассказываю про роль данных для 1го курса Computer ScienceРассказываю про роль данных для 1го курса Computer Science

Совет 23: Если у вас есть дети и семья, всегда ищете возможность брать их с собой в поездки, на конференции. Это ценный опыт для детей (от 5-6 лет) и отлично для 2ой половинки.

Рассказываем старшеклассникам вместе про Alexa и раздаем Alexa за самые лучшие вопросы. Сын делает демонстрацию продукта. Жалко сейчас пандемия и все онлайн, скучно:(Рассказываем старшеклассникам вместе про Alexa и раздаем Alexa за самые лучшие вопросы. Сын делает демонстрацию продукта. Жалко сейчас пандемия и все онлайн, скучно:(

Сообщества в Амазон

Я уже писал про проактивность. В Амазон практически сразу я стал развивать сообщества:

  • Amazon Tableau User Group - 3000 пользователей, которые используют Tableau в Amazon. Я отчечал на каждый второй вопрос, организовывал встречи и приглашал куртых спикеров.

  • BI Tech Talk - 100+ data команд со всего Амазона. Так же организовывал презентации со спикерами из Амазона и других компаний.

Все это дало мне огромное преимущество - меня знал почти весь Амазон, кто работает с данными. Поэтому я мог легко поменять команду, пригласить интересного мне спикера из Linkedin. Конечно это никак не влияет на зарплату, но мне нравилось соединять людей и идеи.

Члены Amazon Tableau User Group на Tableau Conference в Las Vegas 2017Члены Amazon Tableau User Group на Tableau Conference в Las Vegas 2017

Даже сейчас в Microsoft есть люди, которые знают меня со времен, когда они работали в Амазон.

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

В Alexa у меня получилось как обычно, я сделал свою работу, но к повышению не приблизился, и поэтому я снова поменял команду. Я общался с командами из Калифорнии и из Сиэтла. Стал подумывать о релокации в США. Я перешел в команду - customer behaviour analytics. И пообещал осенью 2020 переехать в Сиэтл. Но оказалась, что мои Amazon Stock после 4х лет закончились, и мне нужно было переехать с семьей на базовую зарплату 130 тысяч US. Что меня не устраивало. Так как минимальных доход для Сиэтла должен быть 200 тысяч. А хороший, согласно моим исследованиями 300-350 тысяч (это включает в себя стоки).

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

Еще стоит упомянуть про бонусы. Вам дают стоки в штуках. И если умножить цену акции на колличество, получается круглая сумма. НО!!! Когда наступает vested date - то есть когда акции становятся вашими, Канадское государство забирает ровно половину. То есть, вам положено 20 акций, до вас доедет только 10. Можете их продать, а можете оставить, как я сделал. И если у вас было 10 акций по 600US$, то когда они станут 3000$, вы должны заплатить налог на прибыль (capital gains), с каждой акции это 2400$ - сумма прибыли. И нужно заплатить 25% от 2400.

В общем на бумаге выглядит все красиво, но по факту вы получите намного меньше. Еще не забудьте про прогрессивный налог на зарплату - чем выше доход, тем выше зарплата. В США с налогами история другая, они меньше, но там есть свои заморочки со страховками и медициной.

Каждый раз когда я мягко говоря расстаивался из-за своих карьерных достижений на работе, я начинал искать работу. Ходить по собеседования это полезно и важно, надо быть всегда в тонусе. Так я собеседовался с Tesla (для солнечных батарей) на позицию Data Engineer. Не сложилось с ними. Потом собеседовался с Lyft на позицию менеджера data engineering. ЗП в Калифорнии с бонусом было 400-450тысяч US$. У меня опыта менеджера не было, но я прошел все возможные курсы в Амазоне для менеджеров. Тоже не сраслось. На собеседовании меня спрашивали много вопросов связанных с diversity и inclusion.

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

Совет 25: Вы не единственный кандидат на вакансию. Топовые комании получают сотни откликов. Поэтому старайтесь откликаться одними из первых или ищите другие варианты, например через знакомых. Я откликался на 10ки вакансий в FB и Google, но мне никто ничего не написал в ответ.

Зато спустя какое-то время ко мне пришли рекрутеры из Fb, и сами пригласили на собеседование Manager Data Engineering. Было несколько собеседований

  • Phone Screen с рекрутеорм - просто разговоро о вакансии, требованиях и моем опыте

  • Leadership Interview - разговор с менеджером, больше похоже на behaviour interview, вас спрашивают как вы руководите, решаете конфликтные ситуации и все в этом духе. Курсы менеджеров Амазон отлично решают такие вопрсоы

  • Technical Screening - даже для менеджера состоял из 3х элемнтов. 1й это SQL упражнения (15 минут на 5 SQL задач), Python (15 минут на 5 задач), Data Modelling (15 минут)

Скажу вам честно 15 минут это очень мало. В итоге я сделал, 4/5 задач по SQL, 3/5 задач по Python, что для меня было гордостью, я с ним вообще особо не работал. Но реально провалил data modelling. Был простой вопрос - допустим вы работаете в Linkedin, нарисуйте модель, чтобы ответить на 5 вопросов. Нужно было начать сверху вниз (от бизнес вопросов к таблицам фактов), а я начали снизу вверх (от исходных данных вообще всех в Linkedin) к таблицам фактов. И у меня было 7 минут. У меня есть еще одна гипотеза, что в Северной Америке очень сильное лобби ребят из Индии, и я вижу огромное колличество комманд, которое только состоит из таких ребят. Хотя их опыт и знания не всегда круты. По результатам я понимал, что мои шансы 50/50. В общем я не попал. Но был отличный опыт.

Совет 24: Каждое проваленное собседование - это огромный опыт, вы вызодите из зоны комфорта, готовитесь, учите новое. Не упускайте такую возможность. Игра стоит свеч.

Работа "на дядю" или "на себя"

Амазон был для меня вершиной желаний. Я и мечтать не мог, что буду работать в Амазоне, когда был в начале своей карьеры. Но спустя какое-то время работы в Амазоне, стали появлятся вопросы - а что дальше. Вы очетливо понимаете, что вы работаете на "дядю", пусть и на самого богатого в мире - Джефа Безоса.

Я довольно подробно описал попытку создания аналитического консалтинга в этом посте - Опыт создания аналитической консалтинг-компании в Северной Америке (не очень успешный).

В этом посте я не будут вглубь копать про свой бизнес. Скажу одно, если у вас получилось, создать свой бизнес, сервис или продует и вы получаете доход сопоставимый с зарплатой работы на "дадю", то это круто. Вы на правильном пути. У меня не получилось. Мне кажется, чтобы создать, что-то крутое, это нужно сначала завалить 10-15 бизнесов. Я пока запорол только 2. И у меня началось выгорание - это когда вы теряете интерес к тому, что делаете. Так как я делал очень много всего одновременно, то через несколько лет я почувствовал, что ничего не получил взамен. В Амазоне карьера в гору не пошла, консалтинг тоже не взлетел, а силы кончились. Еще и пандемия и работа из дома. Я могу целый день просидеть за компьютером и не дать никакого результата.

Еще один мой аргумент про свой бизнеч, что если вы хотите реально срубить бабла, то скорей всего вам понадобятся венчурные инвестиции и вы будете мечать о IPO или, что вас кто-то купит. Когда вы получаете инвестиции, часто получается, что вы начинаете работать на "дядю". А выход на IPO, это сопоставимо с попаданием в олимппийскую сборную вашего ребенка, когда вы отдаете его на спорт секцию и надеятесь на успешную спортивную карьеру.

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

Совсем недавно мы приобрели наш 2ой дом в большом Ванкувере.

новый таун хаусновый таун хаус

При этом, мы смогли оставить наш первый дом и сдать его в аренду.

Это нам делали тротуар.Это нам делали тротуар.

Схема стара как мир. Конечно, чтобы такое сделать нужно иметь небольшой капитал, за что спасибо Амазону. Сотрудники Амазон действительно смогли улучшить свою жизнь благодаря росту компании. Вот кстати свежая статья - Jeff Bezos shared a note from a couple that bought 2 shares of Amazon in 1997 - and are now using the proceeds to buy a house after the company's 172,499% post-IPO run

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

Совет 26: банальный - старайте избегать ситуации - жить от зарплаты до зарплаты. Обязательно думайте о будущем и постаратесь сделать хоть что-нибудь, чтобы сохранить и приумножить то, что у вас есть.

Смена работы - из Амазона в Майкрософт

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

Так как время от времени по настроению я откликался на вакансии, в мае 2020 я откликался на вакансию Microsoft в Ванкувер. Я даже не читаю описание вакансии (на месте разберемся, как говорится). В мая я сделал отклик, в конце июля мне позвонили. 2,5 месяца ожиданий. Я уже и забыл про них. Процесс собеседования занял наверно месяц. Как я понял, Microsoft не очень шустрый в процессе найма. Процесс собеседования был примерно такой:

  • Phone Interview с HR

  • Phone Interview с менеджером

Это было что-то вроде phonescreen. Я его прошел и мне назначили основное собеседование. Обычно оно занимает весь день, но в мое случае разбили на 2. Было 3 собеседования:

  • С Product Manager и Director - behaviour interview - то есть ситуативные вопросы. Очень много спрашивали про конфликтные ситуации, как работаю с другими командами. Я все им подробно рассказал. Хотя в каждом вопросе я искал намек на Amazon Leadership Principal и придумывал соответствующий ответ.

  • Собеседование с Principal и Senior инженером. Они меня уже просили писать SQL, точнее задачку по статистике решить SQL. И потом попросили сделать архитектуру аналитического решения на AWS или Azure для Big Data и Streaming.

  • Собеседование с Data Science и BI командой. Я им рассказывал про проекты ML в моей последней команде, и это им понравилось.

В общем дальше наступила фаза переговоров. Я поискал на LinkedIn insights, что для старшего инженера зарплата в Канаде может быть 220 тысяч CAD. Но как я лишний раз убедился с Канадскими компаниями сложно торговаться. Есть жесткие лимиты, они уступили совсем немного. В любом случае я уже "тонул" (выгорал) в Амазоне и это было идеальное время для перемен. В Сиэтл я тоже не собирался.

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

Xbox Game PassXbox Game Pass

Если сравнивать культуру Амазон и Майкрософт, то Майкрософт выигрывает по многим показателям. Work-life balanace, страховка и бенефиты намного лучше.

Если сравнивать AWS и Azure как технологии, то решения AWS для аналитике значительно лучше для меня.

Если сравнивать по зарплате, то Амазон платит больше. Но как вы уже поняли, это был не мой случай. Чтобы поднять свою зарплату и должность, мне снова пришлось воспользоваться советом #4 - поменять работу.

Если посмотреть на рынок, то видно, как в Сиэтле соттрудники Амазон и Сиэтл переходят друг к другу на работу. Я знаю тех, кто ушел из Амазон и пришел в Microsoft и знаю тех, кто ушел из Майкрософт и пришел в Амазон. Уверен, что всегда с повышение и надбавкой.

Бонус раунд

Чуть не забыл рассказать еще про одно собеседование. Примерно в то же время когда я думал на offer letter от Microsoft, я увидел вакансию от своей любимой компании - Slalom (это крупнейшая ИТ консалтинг компания, которая фокусируется на инновационных аналитических решениях, дизайне и разработке). Как я описал в статье про свой консалтинг - Rock Your Data - Slalom был для меня идейным вдохновителем и я их использовал как пример.

Эти ребята открывают офис в Ванквере и ищут Director Data Engineering. Это звучит для меня как работа мечты. Я конечно отклинулся. У меня было много собеседований с директорами из Штатов, и всем я понравился. Их не смутило, что я был Data Practice Director в Rock Your Data и работал в Амазон. Единственное, я спалился на том, что я знал технические детали слишком хорошо. Директор не должен влдаеть столь глубокиими познаниями.

По результатам собеседований они мне сказали, что на директора я не тяну. Но могу дать мне роль Principal Consultant и зарплату на 30% выше, чем Microsoft. Я спросил у своего ментора из Амазаон, он сказал даже и не думай, иди в Microsoft. Так же меня растроил тот факт, что я откликался на директора, а получил консультанта.

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

Совет 27: Все что не делается - все к лучшему.

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

Совет 28: высокая зарплата это не всегда главный критерий. Попробуйте подумать о перспективах, как вы себя сможете продать через год. Все ли стабильно на долгой перспективе? Хорошо ли это для вашего психологического здоровья и для вашей семьи? (В мое случае консалтинг, перелеты было явно не в пользу семьи);

Продолжаю делиться опытом

Мне нравится делится опытом, и именно поэтому я веду телеграмм канал Инжиниринг Данных, куда скидываю все из мира аналитики.

И также решил помочь делом, всем тем, кому это необходимо. На портале datalern.ru я записываю курс Введение в Инжиниринг Данных и Аналитику.

За 6-8 месяцев курс вас научит профессии работы с данными и позволит переквалифицироваться. Курс бесплатный. Я получаю удовольствие, когда я кому-то помогаю, когда делюсь опытом. Так же это для меня возможность give back моей родной стране и всем ребятам и девченкам, у которых пока нет возможностей самостоятельно пробиться.

Подробнее..

Продуктовый дизайнер правила эксплуатации

23.09.2020 14:17:26 | Автор: admin


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

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

Ударю по теории и практике.

В теории хочу разобраться кто это такой и что от него хотят.
На практике описать процесс работы этого самого дизайнера над тем самым продуктом.

Поехали!




Часть первая. Теоретическая.
Кто такой, сколько стоит и чего ожидают


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

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

Вот что говорят курсы.

Нетология обещает зарплату от 120 тыщ. рублей
UX/UI дизайнер, дизайнер продукта одна из самых востребованных digital-профессий с широкими возможностями для роста и высокой заработной платой
Она сочетает в себе аналитику и творчество, инженерный подход и нестандартность решений. Грамотная работа дизайнера увеличивает прибыль клиента и улучшает взаимодействие пользователя с продуктом.

Skillbox приманивает зарплатой от 80 тысяч.
Продуктовый дизайнер отвечает за создание и развитие продукта: от идеи до выхода на рынок.
Вы научитесь продумывать бизнес-стратегию, работать с IT-командой, проводить исследования и проектировать дизайн-системы.

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

Вообщем достаточно размыто все в описаниях.

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

Действовала я топорно и без изысков: вбила в поисковую строку Продуктовый дизайнер и выписала часто встречающиеся требования.

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

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

Ну и погнали теперь по общим требованиям:
  • Опыт работы в дизайнерских и около того программах (Sketch, Zeplin, Figma, InVision, Adobe Photoshop и пр.);
  • Опыт работы с web, iOS и Android (потому что есть шанс, что будешь и там, и тут);
  • Разбираться в современных трендах дизайна;
  • Красиво визуализировать что дадут. А дать могут не только сложные и интересные фичи, но и баннеры, лендинги, иконки или иллюстрации. Отсюда, соответственно, вытекает знание основ композиции, типографики, и прочих таких необходимых простому дизайнеру штук;
  • Шарить в паттернах человеческого поведения. Быть в курсе того, что в мире проектирования интерфейсов твориться, что бы не только спроектировать, но и свою гипотезу выдвинуть, а чужую аргументированно задвинуть. На основе чего ты будешь выдвигать и задвигать это уже тебе либо скажут, либо сам придумаешь;
  • Быть ux-аудитором проверить то, что уже есть и исправить это в лучшую сторону, естественно;
  • Бодро отслеживать конкурентов, постоянно держа руку на пульсе;
  • Уметь общаться с пользователями. Это про проведение разного рода исследований и тестирований;
  • Уметь дизайн-систему если не создать, то руку к уже готовой приложить;
  • Где-то надо будет заняться еще и аналитикой (тут в зависимости от ситуации: либо понимать, что тебе говорит и показывает аналитик, либо быть тем самым аналитиком);
  • Грамотно писать тексты, так что местами надо будет совмещать роль и ux писателя;
  • Уметь быстрого прототипировать. Что бы идеи показать, проверить, оттащить пользователю на тест;
  • Понимать что frontend могет, а чего не могет. А так как сейчас frontend могет практически все, только дай ему время и вдохновение, то лучше понимать время, которое займет у разраба твой дизайнерский или интерфейсный креатив; Не забываем следить за качеством того, что все-таки front накреативит в итоге по твоим макетам;
    Кстати, про креатив. Этот свой креатив лучше всего совмещать с логическим мышление на одних плечах;

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

Вообщем, требования достаточно обширные. Где-то больше, где-то меньше.
Надеюсь основное направление понятно.

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



На самом деле все у всех по-разному.

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

Но это лично мой опыт. Может у кого-то совсем и не так.

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

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

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

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

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

Потому что делать все равно надо.

Ну а как?

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



Часть вторая. Практическая.
Основана на реальных событиях.


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

И об этих светлых пятнах и будет мой рассказ.

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

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

Итак

Сбор требований с заказчика


Требования можно собирать от Product Owner, заказчика, или другого ответственного лица.

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

Требования надо собирать тщательно, не оставляя ни одного белого пятна.

По хорошему, этим должен заниматься бизнес-аналитик. Узнал, записал, принес, сделал Чмоки и махнул ручкой на прощание.

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

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

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

Сбор требований с пользователя


Это уже другая сторона медали.

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

Посидеть и посмотреть как он работает с тем, что уже есть.
Спросить что устраивает, а что нет. А как хотелось бы. Что важно при совершении определенного действия, принятия решения и прочее.

Даже если делаем то, чего еще нет, все равно они каким-то образом решают эти задачи.

Потыкав палкой в обе стороны, уже имеешь более-менее внятную картинку с которой можно работать.

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

Почему я обращаю на это внимание? Потому что опять же шишки из практики. Собрал проблемы от экспертов, выпустился и поехал смотреть, насколько рады конечные пользователи свалившемуся на них счастью в виде решения их проблем.
И вдруг, внезапно, оказалось, что часть проблем не валидна, часть возникает не тут и не в это время, а часть вообще звучит странно и хз им бедным, что с этим делать. Короче, спасибо, решили, правда только хуже сделали.

Схема пути пользователя


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

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

А я брала и раскладывала весь пользовательский путь употребления какой-то функцией от точки А до Б, от Б до С и так далее.
Так как часто приходилось делать то, чего еще нет, то реальные проблемы, радости и прочее передать не могла.

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

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

Когда весь путь чист, как слеза младенца, можно уже и к прототипу приступать.

Прототип первый: бумажный


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

Бумажки можно разложить в ряд и оценить логику и понятность будущего продукта.

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

Прототип второй: динамический


Я его делаю в Axure.

Честно, пробовала в других программах, но мне элементарно не удобно, особенно когда будет достаточно большое количество экранов.

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

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

Тестирование прототипа


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

В любом случае, все правки прототип переносит легче, чем продукт, запущенный в прод.

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

Не скажу, что все проходит гладко и правильно.

Были и ограничения по времени, когда просто приходишь и показываешь итог своей работы. Типа, вот смотрите: вы просили, а мы вот чего сделали. Потом сидишь и слушаешь обратную связь.

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

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

Это точно лучше, чем ничего.

Показ прототипа разработке


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

Тадам! Финишная прямая: дизайн


Тут рассказывать особенно нечего. Садишься, открываешь программулину и начинаешь рисовать хорошо или не очень то, над чем трудился в предыдущих сериях.
Позволяет время идешь набираться визуального и прочего вдохновения на ресурсах, названия которых нельзя произносить, потому что последнее время их часто хают.

Передача в разработку


Раньше описывала сценарии в формате user story.
Звучало это примерно так:
Я, как ., хочу
Далее описывалась сама функция, действия с ней пользователем, дополнительные возможности и пр.

Оказалось, что иногда получается много и никто это читать не желает, поэтому стала лепить примечания в самом прототипе и раскладывать в miro путь уже надизайненными экранами.

Оказалось, что разработчикам так работать значительно удобней.

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



Заключение


Повторюсь, что это мое виденье и мой опыт.

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

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

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

Будет ли актуальна эта профессия в будущем или распадется, в конце-концов, на отдельных узких специалистов.
Подробнее..

Поговорим по-красному?

23.10.2020 18:08:20 | Автор: admin

Вы совершили ошибку. Все совершают ошибку. Или не совершали. Или у руководства с утра просто овсянка в сапоге.


Доброе утро, сэр
  • Бэрримор, что у меня хлюпает в сапоге?
  • Овсянка, сэр!
  • Но что она там делает?
  • Хлюпает, сэр!

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


Причин для поговорить по-красному может быть множество. За последний год я их пронаблюдал несколько. И сразу могу сказать win-win тут и не пахнет. И бирюзовостью тоже. Agile тем более. Но встречается такое в наших полях и просторах часто. К чему это может привести?



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


Через три месяца уволили Нияза, великолепного переводчика человека, который привёл меня в компанию.


Говорил мне папа в 5 лет: Не верь в сказки


Полная дискредитация руководителя в глазах подчинённого


Так уж вышло, что пришлось испытать на собственном примере. На одной из предыдущих работ название называю не из-за NDA, потому что эта бумажка юридически ничтожна в юридических границах Российской Федерации, а потому что название ничего не придаст к сути рассказа генеральный директор внезапна(!) осознал, что я выполняю все поставленные задачи, но получаю слишком много. Тогда я, кстати, вывел блог компании на 3 место в Хабре с около 30 или 40, точно уже не помню.


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


Но это было потом. Считайте лёгким flashback. За два месяца до этого был красный разговор, где даже с лёгкой обсценной лексикой мне объясняли, что моё подразделение и я, как руководитель, слишком много кушаем. Не поднимались вопросы, что мы даём компании, что такое долгосрочный эффект, лояльность клиентов, сторителлинг, репутация. Просто много кушаем.


Я слушал примерно 5 минут. После этого очень мягко и корректно, только литературными словами объяснил: Уважаемый ...., если мы решили поговорить по-красному, то теперь мой черёд. Говорить со мной в таком тоне и даже с такими словами может крайне ограниченный круг лиц. Во-первых, это очень близкие друзья и я к ним прислушаюсь. Я тоже могу ошибаться, как любой человек. Во-вторых, это люди, которых я очень уважаю. Это три человека. Полковник ВВС в запасе, полковник ГРУ в запасе и подполковник Вымпела в запасе за их невероятную тяжёлую и мужественную службы стране, за военный опыт и за жизненный опыт. Кроме того, я готов выслушать по-красному моих однополчан, когда я работал военным журналистом, и когда мы вместе чудом пережили 2 миномётных обстрела 120-мм минами. Всё. А вам, уважаемый ...., я права говорить со мной по-красному не давал. И вы его даже за всю жизнь не заслужили. Весь страшномосковский риск, который у вас в жизни был, это подвернуть ногу, вылезая с кожаного кресла внедорожника. И когда вы со мной пытаетесь говорить по по-красному, то вызываете даже не обиду или раздражение, а веселье и хихиканье. Про себя, конечно же, потому что я вежливый человек и мажоров в жизни навидался.


Больше со мной по-красному говорить не пытались. Говорили с другими и не раз. Доводили до слёз девушек и увольняли прямо за столом ресторана после завершение конференции.


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


Профессиональное выгорание


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


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


На словах в компании Agile. Открытость. Прозрачность. Доверие. Blameless Culture.


На деле все животные равны, но некоторые животные равнее других(с)Джордж Оруэлл.


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


Потеря ценного сотрудника


После разговора по-красному можно потерять ценного сотрудника не будем учитывать вариант прямого в челюсть. :)


Почему ценного? Потому что середнячки, невротики и неуверенные в себе люди будут терпеть. Будут терпеть люди, связанные кредитами, ипотеками, больными родственниками. Страдать и терпеть. Мучиться. Болеть. Брать отпуска в надежде, что смогут восстановиться. Выгорать. Мучиться бессоницей. Ходить на работу, как на каторгу. И бояться, что следующими уволят их, потому что они всё делают неправильно, плохо, неэффективно, не так.


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


Agile превращается в карго-культ


Руководство получает новые игрушки: дейли, грумминг, планирование, демо, ретро. Все ходят строем на эти мероприятия. Пропустить хоть одно из них это неуважение команды.


Каждый по принципам Agile равен другому сотруднику. Но как сказано чуть выше есть животные равнее других. И это иногда исподволь, иногда прямо демонстрируется. Вроде бы проходит обычное дейли и тут коммерческий директор, который взял себе роль scrum-мастера, начинает командовать и говорить, что и кому делать. Бирюзово? Да как-то не очень. Скорее по-красному.


Это повторяется раз, два, три. Сотрудники приходят к нему за советом, а получают выговор. Вместо scrum-мастера, они получают обычного руководителя. Вместо Agile, так называемый руджайл, а если проще обычный карго-культ. Но все его выполняют потому что каждый боится оказаться слабым звеном.


Минус этой ситуации: Agile превращается в карго-культ. Сотрудники ходят на дейли, демо и ретро, как на каторгу, и считают, что это потеря времени. Вместо открытости, прозрачности, доверия и blameless-культуры сотрудники получают непрозрачные и необъяснимые процессы в стиле потому что так тут заведено, договорённости за спиной и отдельными группами, закрытость процессов в других отделах и, конечно, вина, вина, вина за это, за другое, за третье. Что опять же ведёт к выгоранию.


А вы встречались с таким по-красному"? И как поступили? Нашли решение win-win?

Подробнее..

Разбор полётов. Уроки и выводы начинающего Scrum-мастера

18.03.2021 12:07:58 | Автор: admin

Источник фото

Уже третий год я внедряю ценности и принципы Agile в жизни команд разработчиков. За плечами работа Scrum-мастером в двух крупных компаниях, опыт удаленного внедрения гибких методологий в совершенно разных отраслях, бесчисленное количество прочитанных книг и посещенных митапов.

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

Итак, какие уроки я извлекла и выводы сделала в первый год работы в роли Scrum-мастера (о которых кратко пунктами изложила в самом конце):

Розовые очки





После двухдневного тренинга по Scrum я была готова сворачивать горы, изменять мир на пути компании к лучшему. Ничто так не вдохновляет, как грамотный коуч и команда единомышленников! Но стоит только начать, как вдруг ты остаёшься один на один со своим фреймворком Scrum. Есть ребята, загруженные собственными задачами, есть привычки и ценности, которые уже сложились в работе команды, есть менеджмент, который по-своему видит процессы, и это не всегда идёт параллельно с ценностями и представлениями Agile. В общем, добро пожаловать в реальный мир.

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

Сопротивление


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

Важный момент: если в самом начале вы не найдёте в команде разработчиков сторонников, рискуете быть отвергнутыми.

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

Задайте себе вопрос: какова цель моего присутствия в этой роли и как я могу помочь своей команде улучшить существующие процессы работы?. Если ответ нашёлся отлично, вперёд к изменениям! Если нет, то стоит понаблюдать ещё.

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

Спешка худший помощник





Спешка и желание показать себя с первых дней работы наверное, самая большая ошибка начинающего Scrum-мастера. Жизненно важно знать, что резкие изменения без понимания, зачем это нужно и как повлияет на сложившийся уклад жизни команды, может вызвать ещё большее сопротивление и недоверие. Бывали случаи, когда Scrum-мастер вредил командам именно вследствие непродуманных и непроработанных изменений.

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

Понимание среды


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

Не повторяйте мою ошибку: не важно, маленькая у вас компания или большая, но понимать коммуникацию между отделами и знать лично пару ключевых коллег нужно. Говорят, что Scrum-мастер должен устранять препятствия, отвлекающие команду от создания ИТ-продукта. Но как это сделать, если вы не будете знать, к кому обратиться?

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

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

Присутствие стратегии


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

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

Чаще всего, приходя в команду, я видела, как ребята проводят ежедневные совещания по 1,5-2 часа, на которых пытаются проработать все вопросы. А это, между прочим, колоссальное количество времени, которое вычитается из рабочих часов и снижает эффективность работ команд. Да и Scrum Guide предполагает на это событие только 15 минут и ни минутой больше.
Как быть: самым правильным подходом, на мой взгляд, является разделение таких активностей и фокусировка на поставленных задачах в рамках целей Sprint.

Отталкиваясь от болей и наиболее частых вопросов, помимо основных событий Scrum (планирование, daily, demo, retro) может формироваться, например, еженедельная исследовательская встреча, обсуждение бэклога идей или же мозговые штурмы для обсуждения углубленных вопросов, как происходит сегодня у нас в ICL Services. Мы видим боль, знаем, как исправить ситуацию и что нужно сделать остаётся лишь обсудить изменение формата работ с менеджментом и командой для достижения наилучшего эффекта.

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

Нехватка технических знаний





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

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

Краткие итоги


1. Опирайтесь на уже имеющийся опыт. Поймите, в чём нуждается команда, какие проблемы и недосказанности существуют и как можно ей помочь.

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

3. Позвольте себе понаблюдать за командой первый Sprint, понимание процессов и ценностей команды приходит без спешки, а готовность к изменениям наступает постепенно.

4. Понимание взаимосвязи между отделами и активная коммуникация с менеджментом это ценный ресурс, который поможет вам устранять препятствия, отвлекающие команду от главного создания ИТ-продукта.

5. Задайте себе вопрос что мы хотим изменить и почему?, и ответом на него станет четкая цель. А в ответ на вопрос как мы будем это делать? составьте план, который будет понятен и известен руководству еще до начала изменений, т. к. в него могут внестись весомые правки в зависимости от верхнеуровневых целей компании.

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

Уверена, что все уроки, полученные мной, помогут и вам сделать выводы и перестроиться в правильном направлении, потому что сегодня я на самом деле люблю то, что делаю. И, главное, не бойтесь ошибок, а учитесь на них. Удачи!
Подробнее..

Работа с японцами в IT 10 отличий

25.03.2021 14:07:14 | Автор: admin


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

Вступление


Перед нашей командой стояла нелегкая задача адаптировать существующее PoS-решение под японский рынок и сделать его кроссплатформенным, при этом минимизировав отклонения от существующего решения. Можно сказать, что с одной стороны мы получили карт-бланш на изменение продукта, но в то же время были серьезно ограничены существующей кодовой базой. Нам доверили изменение основных (core) функций, и разработка велась по каскадной модели. Работа над проектом заняла 3 года, за которые мы имели дело с гигабайтами строк кода, совершили десятки командировок из Токио в Казань и обратно и успели поработать с тремя сотнями его участников как со стороны заказчика, так и смежных подрядчиков из Японии, России и Филиппин.

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

Работа в Excel


То самое, что вызывало боль. Microsoft Excel в японских компаниях применяется для всего: документации самой разной детализации (даже если там лишь UML диаграммы), сборника скриншотов с багами, и конечно же, бескрайних полей отчетов, из ячеек которых можно было бы складывать мегапиксельные матрицы. У наших менеджеров Excel просто не выдерживал таких страданий и отказывался работать. К слову, иногда подобная одержимость приобретает причудливые формы. Если для отчетов такой формат еще более или менее привычен, то для девелоперской документации это экзотика, мягко говоря.

Слишком длинные митинги


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



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

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

Языковой барьер


Япония страна самодостаточная, и уровень эмиграции там сравнительно невысокий. Поэтому тот самый английский язык, на который уповали мы, там не очень популярен: собеседник с уровнем А2 это максимум, на который мы могли рассчитывать. Помните, если вы начинаете проект с японцами, то без переводчика не обойтись! С самого начала проекта у нас был человек, без которого наше взаимодействие с японцами было бы просто невозможно разговаривающий на японском языке проектный координатор, на котором лежала ответственность ведения переговоров и ключевых переписок. Кроме него в переводе документации, писем, и тикетов и на переговорах участвовали несколько переводчиков.
Сложности, связанные с языковым барьером, оставались вплоть до конца проекта но в таких ситуациях помогала большая уверенность и настойчивость с нашей стороны. Мы понимали, что несмотря на разные языки, перед нами стоит единая цель.

Отчеты всегда и везде


Наш проект осуществлялся по каскадной модели разработки, и обилие отчетности и постоянное обновление план-графиков отчасти этим обуславливались. Нельзя сказать, что обилие отчетности чисто японская особенность. Но если сравнить похожий проект в России и СНГ с Японией, то дальневосточный колорит проявляется во всей красе. Мне как тимлиду пришлось в полной мере столкнуться со всеми видами отчетных документов как в роли читателя, так и автора за исключением, пожалуй, финансовых: по качеству с разбором причин багов, по прогрессу, внеочередными техническими, и, конечно же, традиционными для waterfall план-графиками. Каждый из этих отчетов представлял из себя увесистый Excel-файл, разлинованный таблицами в лучших традициях сканвордов для дома престарелых.

В ходе непрерывной коммуникации на долгих зимних митингах понимание стало распространяться сначала на менеджмент, а потом и на команду. Мы пришли к пониманию основных отличий от отчетности подобного рода в аналогичном российском проекте они делались не для галочки, но содержали актуальные индикаторы состояния проекта и были объектом пристального внимания и анализа (и нередко правок) наших японских коллег.


План-график в японском стиле

Тем не менее, у них был и смысл, и даже благая цель: например, отчет по качеству показывает проблемные места, при его составлении можно докопаться до сути проблемы, а отчет по прогрессу помогал трекать объем выполненной на данный момент работы. К слову, второй со временем обрастал все новыми столбцами, и на его заполнение у менеджера могло уходить до трех часов 2 раза в неделю, а иногда и чаще. С план-графиками вышло еще сложнее: изначально я пытался программным путем брать тикеты из таск-трекера вместе с оценками и накладывать на график их в MS Project, но он оказался очень капризным, и план-графики постоянно слетали и менялись. Отчаявшись, я довольно быстро накидал построение план-графиков в Excel, конечно.

Разница во времени


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

Работая с западными коллегами, вы, казалось бы, все время играете на опережение: начинаете работать раньше них и можете спокойно настроиться на рабочий лад, разгрести вчерашнюю почту и подготовиться к митингам. Но нет представьте себя на месте японцев. Вы находите критический баг, который нужно срочно пофиксить, а разработчики еще спят. Пусть даже вы понимаете, что они будут стараться и продолжат фиксить баг и после окончания вашего рабочего дня, но ощущение вечного опоздания будет усиливаться пропорционально срочности бага. Благо наш координатор работает во Владивостоке, что опережает Японию на 1 час. Это очень выручало, поскольку основной удар негодования он героически принимал на себя и немного демпфировал переживания японцев.

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

Фокус на качестве


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

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

Также в качестве улучшения качества кода мы предложили японцам практику проведения до 4-х ревью от разных людей включая самого тимлида в зависимости от сложности тикета. В результате это подтолкнуло меня на изучение возможностей автоматического пре-ревью кода в GitLab. Применить все это на проекте я не смог, но написал небольшой шаблон для будущих проектов. Кроме усиления ревью мы добились успехов и в части улучшения автоматического тестирования (unit, integration, smoke).

Метрики производительности (KS)


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

Количество строк кода также применялось для расчета производительности программистов.
На ум приходят сразу куча проблем этого метода: код UI гораздо объемнее, но содержит меньше сложности, а иные 10 строк кода могут быть добыты ценой упорной мозговой деятельности на протяжении нескольких дней. Мы пытались начать оценивать работу в количестве use cases, но выделенных аналитиков не было, а компетенций разработчиков не хватало. Ближе к середине проекта предыдущий тимлид предложил использовать количество методов в качестве метрики объема. В результате мы стали посчитывать и KS и количество методов.

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

Эстимейты и дедлайны


В Японии встречается практика продавить разработчика на более низкие эстимейты и, соответственно, дедлайны, а потом давить на чувство вины (ты же сам говорил), чтобы виновник перерабатывал, пытаясь уложиться в сроки. В нашей ситуации это иногда напоминало торг за дедлайны. Мы убеждали, что 2-3 дополнительных разработчика не ускорят работу над задачей но на другой стороне провода твердо стояли на своем. С переменным успехом мы героически отстаивали сроки, а в преддверие особенно критичных дедлайнов шли на компромисс, который обычно состоял из переработок и реже привлечением дополнительных ресурсов. Впрочем, мы нередко эти дедлайны успешно проваливали.

Со временем было решено автоматизировать и это явление. Я брал за основу тикеты, добавлял необходимые ревью, возможные баги и Пытался натянуть это в MS Project. К сожалению, из раза в раз он показывал разный порядок задач и неведомым образом выставлял constraint'ы. Времени было немного, поэтому решил по-быстрому сделать построение диаграмм Ганта в Excel благо он оказался более предсказуемым и послушным. Таким образом, мы могли спокойно менять эстимейты вместе с ними менялись и даты завершения. Перестраивать план-графики стало гораздо проще, заказчику они понравились. Хоть проблему проваливания дедлайнов это и не решало, но мы могли заранее предупреждать заказчика о сдвиге сроков.

Традиции


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


Источник фото

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

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

В традиционных японских компаниях в отношениях с начальством японцы соблюдают строгую субординацию. Мне кажется, это одно из нынешних ключевых различий между разработчиками Японии и России. При возникновении проблем японцы практически никогда не винят непосредственных исполнителей, но более склонны винить руководство, причем с обеих сторон. Чем более высокий ранг, тем больше ответственности и выше цена неудачи. Все по правилам: чем больше сила, тем больше и ответственность.

Клиент бог


Япония отличается особенным отношением к клиенту. И вероятно такого же отношения ждал от нас наш японский заказчик.

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

Заключение


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

Можно ли сказать, что большинство стереотипов о японцах в работе верны? Все не так однозначно.

Субординация между начальством и подчиненными действительно ощущается в Японии сильнее, но в последнее время молодежь все чаще ломает систему. Переработки встречаются часто, но праздников в Японии больше, чем в России. Гиперответственные люди, склонные уложиться в дедлайн во что бы то ни стало, есть всегда и везде и это вовсе не зависит от страны или менталитета. Чем дольше мы работали с нашими коллегами из Японии, тем меньше были заметны различия и больше находилось сходств. Уникальная история и культура не могут не отразиться на национальном характере и традициях, но все же, общего оказалось гораздо больше. И я благодарен за этот опыт!
Подробнее..

Может поменять способ хранения?

24.05.2021 20:06:11 | Автор: admin

Собрались однажды 2 разработчика. И нужно было им новую HTTP API реализовать для игрового магазина. Дошло дело до выбора БД, которую стоит применить в проекте:

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

- Сперва нужно понять какие данные будут в нашей предметной области!

- Да, вот я уже набросал схемку:

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

- Выглядит так, что у нас уже есть четко описанная структурированная модель, да и опыт использования MySQL есть в компании. Предлагаю использовать его!


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

Начали интегрироваться партнеры, и тут начались проблемы Оказывается, API работает очень медленно и совсем не держит нагрузки! Масштабирование дает смехотворный прирост, подключение кэшей всевозможных уровней дает профит, но зависимость запросов от параметров пользователей (сегментирование и атрибутирование) снижают его практически до ноля.

Корнем проблемы являлось большое (очень) количество запросов к БД - на каждое отношение между сущностями ORM генерировала дополнительный запрос.

Разработчики опустили руки и приуныли. Что же делать? Повезло им, ведь нашли они мудрость, увековеченную на бумажном носителе (милая книга с кабанчиком от Клеппмана).

А книга и порекомендовала еще раз внимательно взглянуть на свою предметную область... Ведь отношения между сущностями образуют дерево! А дерево можно уместить в одном документе (или представить с помощью одного JSON), что позволит избежать такого количества запросов.

Вооружились идеей разработчики и просто сериализовали сущность в JSON и сложили в 1 столбец MySQL (+ несколько генерируемых столбцов с индексами, для поиска):

95 перцентиль уменьшилась более чем в 3 раза, пропорционально увеличился и выдаваемый rps одного инстанса приложения.

А ведь просто поменяли формат хранимых данных, никак не затрагивая инфраструктуру и конфигурацию приложения

Какой вывод можно сделать?

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

  • Важнее понимать какие концепты помогут достичь требуемого качества, а затем выбирать технологии, реализующие их, нежели просто выбирать между технологиями

  • Стереотипное мышление вроде MongoDB для неструктурированных, для структурированных что-нибудь реляционное или Ну Redis небезопасный, поэтому не будем там хранить ничего и т.п. скорее вредно. Зачастую все зависит от реализации приложения и конфигурации сервисов.

Подробнее..

Recovery mode Как компании выбрать инструменты для дата-инженеров и не превратить всё в технологический зоопарк опыт PROFI.RU

21.08.2020 12:12:17 | Автор: admin
Редактор Нетологии побеседовала с тимлидом команды BI в Profi.ru Павлом Саяпиным о том, какие задачи решают дата-инженеры в его команде, что за инструменты для этого используют и как же всё-таки правильно подойти к выбору инструментария для решения дата-задач, в том числе нетипичных. Павел преподаватель на курсе Дата-инженер.

Чем занимаются дата-инженеры в Profi.ru


Profi.ru это сервис, который помогает встретиться клиентам и специалистам самых различных сфер. В базе сервиса более 900 тысяч специалистов по 700 видам услуг: репетиторы, мастера по ремонту, тренеры, мастера красоты, артисты и другие. Ежедневно регистрируется более 10 тысяч новых заказов всё это даёт порядка 100 млн событий в день. Поддерживать порядок в таком количестве данных невозможно без профессиональных дата-инженеров.

В идеале Data Engineer развивает культуру работы с данными, с помощью которой компания может получать дополнительную прибыль или сокращать издержки. Приносит ценность бизнесу, работая в команде и выступая важным звеном между различными участниками от разработчиков до бизнес-потребителей отчётности. Но в каждой компании задачи могут отличаться, поэтому рассмотрим их на примере Profi.ru.

Собирают данные для принятия решения и предоставляют их конечному пользователю топ-менеджеру, продакт-менеджеру, аналитику


Данные должны быть понятными для принятия решений и удобными для использования. Не нужно прикладывать усилий для поиска описания или составлять сложный SQL-запрос, который учитывает много различных факторов. Идеальная картинка пользователь смотрит на дашборд и его всё устраивает. А если не хватает данных в каком-то разрезе, то он идёт в базу и с помощью простейшего SQL-запроса получает то, что нужно.


Место процесса Data Quality в общей структуре хранилища данных

Важное значение отводится пояснительной документации по работе с данными. Это упрощает работу и дата-инженера (не отвлекают вопросами), и пользователя данных (может сам найти ответы на свои вопросы). В Profi.ru такие документы собраны на внутреннем форуме.

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

Тот же Tableau с точки зрения конечного пользователя дашборда не позволяет вывести все возможные измерения. Пользователь довольствуется теми фильтрами, что сделал разработчик дашборда. Это порождает два сценария:

  • Разработчик делает множество разрезов для дашборда количество страниц сильно увеличивается. Это снижает доступность данных: становится сложно понять, где что лежит.
  • Разработчик создаёт только ключевые разрезы. Найти информацию легче, но за чуть менее стандартным разрезом всё равно придётся идти либо в базу, либо к аналитикам. Что также плохо влияет на доступность.

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

Аккумулируют данные со всех источников в одном месте


Источники данных могут быть внутренними и внешними. Например, у кого-то бизнес зависит от погодных сводок, которые нужно собирать и хранить, от внешних источников.

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

Делают дашборды


Визуализацию данных лучше делать в профессиональном инструменте например, в Tableau.

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

Качественная визуализация данных позволяет легче и быстрее принимать решения.

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


Пример продакт-дашборда Profi.ru (один из листов). В целях конфиденциальности информации названия метрик и осей скрыты

Примеры реальных задач


Задача 1 перелить данные из исходных (операционных) систем в хранилище данных или ETL


Одна из рутинных задач дата-инженера.

Для этого могут использоваться:

  • самописные скрипты, запускаемые по cron или с помощью специального оркестровщика типа Airflow или Prefect;
  • ETL-решения с открытым кодом: Pentaho Data Integration, Talend Data Studio и другие;
  • проприетарные решения: Informatica PowerCenter, SSIS и другие;
  • облачные решение: Matillion, Panoply и другие.

В простом исполнении задача решается написанием YML-файла строк на 20. Занимает это минут 5.

В самом сложном случае, когда нужно добавить новый источник например, новую БД, может занимать до нескольких дней.

В Profi эта простая задача при отлаженном процессе состоит из следующих шагов:

  • Выяснить у заказчика, какие нужны данные и где они лежат.
  • Понять, есть ли доступы к этим данным.
  • Если доступов нет, запросить у админов.
  • Добавить новую ветку в Git с кодом задачи в Jira.
  • Создать миграцию на добавление данных в якорную модель через интерактивный Python-скрипт.
  • Добавить файлы прогрузок (YML-файл с описанием того, откуда данные берутся и в какую таблицу записываются).
  • Протестировать на стенде.
  • Залить данные в репозиторий.
  • Создать pull request.
  • Пройти код ревью.
  • После прохождения код-ревью данные заливаются в мастер-ветку и автоматически раскатываются в продуктив (CI/CD).

Задача 2 удобно разместить загруженные данные


Другая частая задача разместить загруженные данные так, чтобы конечному пользователю (или BI-инструменту) было удобно с ними работать и не приходилось делать лишних движений для выполнения большинства задач. То есть построить или обновить Dimension Data Store (DDS).

Для этого могут применяться решения из 1-й задачи, так как это также ETL-процесс. В самом простом варианте обновление DDS осуществляется с помощью SQL-скриптов.

Задача 3 из разряда нетипичных задач


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

Используем движок на базе Apache Flink. Пока порядок действий такой: движок обрабатывает входящий поток событий складывает их пачками в ClickHouse на ходу считает количество событий за 15 минут передаёт их сервису, который определяет, есть ли аномалии сравнивает со значениями за аналогичные 15 минут с глубиной в 3 месяца если есть, кидает оповещение в Slack.


Схема для фронтовой аналитики (часть загрузки)

Фреймворк Apache Flink гарантирует доставку как минимум один раз. Тем не менее появляется вероятность дубликатов. В случае с RabbitMQ это можно решить, используя Correlation ID. Тогда гарантируется единичная доставка целостность данных.

Считаем количество событий опять же с помощью Apache Flink, выводим через самописный дашборд, написанный на NodeJS, + фронт на ReactJS. Быстрый поиск не дал похожих решений. Да и сам код получился простым написание не заняло много времени.

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

Основные инструменты дата-инженеров


С задачами дата-инженеров более-менее понятно, теперь немного об инструментах, которые используются для их решения. Конечно, инструменты в разных компаниях могут (и должны) отличаться всё зависит от объема данных, их скорости поступления и неоднородности. Также может зависеть от пристрастности специалиста к какому-то одному инструменту только потому, что он с ним работал и хорошо его знает. В Profi.ru остановились на таких вариантах

Для визуализации данных Tableau, Metabase


Tableau выбрали давно. Эта система позволяет оперативно анализировать большие массивы данных, при этом не требует затратного внедрения. Для нас он удобен, красив и привычен часто в нём работаем.

Про Metabase знают немногие, между тем для прототипирования он очень хорош.

Из инструментов визуализации ещё можно сказать про Superset от Airbnb. Его особенная фича много коннектов к базам данных и возможностей для визуализации. Однако для рядового пользователя он менее удобен, чем Metabase, в нём нельзя соединять таблицы, для этого нужно делать отдельные представления.

В том же Metabase соединять таблицы можно, более того сервис делает это сам с учётом схемы базы данных. Да и интерфейс у Metabase проще и приятнее.

Инструментов очень много просто найдите свой :-)

Для хранения данных ClickHouse, Vertica


ClickHouse бесплатный быстрый инструмент для хранения продуктовых событий. На нём аналитики сами делают обособленную аналитику (если им хватает данных) или дата-инженеры берут агрегаты и перезаливают их в Vertica для построения витрин.

Vertica крутой удобный продукт для отображения конечных витрин.

Для управления потоками данных и проведения вычислений Airflow


Данные мы грузим через консольные инструменты. Например, через клиент, который идёт с MySQL, так получается быстрее.

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

Основной язык программирования Python


У Python намного ниже порог вхождения + в компании есть компетенции по этому языку. Другая причина под Airflow DAGи пишутся на Python. Эти скрипты просто обёртка над загрузками, основная работа делается через консольные скрипты.

Java мы используем для разработки под аналитику в режиме реального времени.

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


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

Технологический зоопарк это инструменты, которые выполняют одни и те же функции. Например, Kafka и RabbitMQ для обмена сообщениями или Grafana и Zeppelin для визуализации.


Карта технологий и компаний в сфере данных и ИИ видно, как много дублирующих решений может быть

Также многие для личных целей могут использовать разные ETL-инструменты. В Profi как раз такая ситуация. Основной ETL на Airflow, но кто-то для личных прогрузок использует Pentaho. Они тестируют гипотезы, и через инженеров эти данные им прогонять не нужно. В основном инструменты самообслуживания используют достаточно опытные специалисты, которые занимаются исследовательской деятельностью изучают новые пути развития продукта. Набор их данных для анализа интересен в основном им, к тому же, он постоянно меняется. Соответственно нет смысла заносить эти прогрузки в основную платформу.

Возвращаясь к зоопарку. Часто использование дублирующих технологий связано с человеческим фактором. Обособленные внутренние команды привыкли работать с тем или иным инструментом, который другая команда может и не использовать. И иногда автономия единственный путь для решения особых задач. Например, команде R&D нужно что-то протестировать при помощи определённого инструмента он просто удобен, кто-то из команды уже использовал его или есть другая причина. Ждать ресурса системных администраторов на установку и настройку этого инструмента долго. При этом вдумчивым и дотошным администраторам ещё нужно доказать, что это действительно нужно. Вот команда и ставит инструмент на своих виртуалках и решает свои специфические задачи.

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

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

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

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

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

Выбор инструмента наполовину прыжок веры, наполовину личный опыт. Нет полной уверенности, что инструмент подойдёт.

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

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

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

Если компания зрелая и располагает ресурсами, имеет смысл задуматься о покупке техподдержки. Это поможет оперативно устранять проблемы и получать рекомендации по использованию продукта.

Если говорить о подходе к выбору, то в Profi придерживаются таких принципов:

  • Не принимать решение в одиночку. Когда человек что-то выбирает, он автоматически убеждён в своей правоте. Другое дело убедить других, когда нужно привести серьёзные доводы в защиту. Это помогает в том числе увидеть слабые стороны инструмента.
  • Советоваться с главным специалистом по данным (диалог по вертикали). Это может быть главный дата-инженер (Chief Data Engineer), руководитель BI-команды. Топы видят ситуацию более широко.
  • Общаться с другими командами (диалог по горизонтали). Какие инструменты они используют и насколько удачно. Возможно, инструмент коллег может решить и ваши задачи и не придётся устраивать зоопарк решений.


Внутренние компетенции как эффективная замена внешнему поставщику услуг


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

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

Среди примеров таких задач, когда новое направление развивается силами сотрудников, проведение нагрузочного тестирования и создание хранилища данных. Особенно хранилище данных, так как это уникальная история для каждого бизнеса. Хранилище нельзя купить, можно лишь нанять внешних специалистов, которые его построят при поддержке внутренней команды.

Кстати, по мере развития нового направления команда может понять, что необходимость во внешнем поставщике услуг отпала.

В Profi внедрение BI было in-house. Основная сложность была в том, что бизнес хотел запустить BI быстро. Но на построение такого проекта требовалось время: нарастить компетенции, залить данные, построить удобную схему хранилища, выбрать инструменты и освоить их.

Основная горячая фаза, когда всё строилось и кристаллизовывалось, длилась где-то год. А развивается проект до сих пор.

При построении корпоративного хранилища данных важно придерживаться высоких стандартов, отстаивать свои позиции и не делать кое-как в угоду бизнесу.

С большой болью мы переделывали большую часть проекта, которую пришлось тогда сделать по-быстрому.

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

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

В подобных историях важную роль играют так называемые early adopters те, кто готов пробовать новое, среди топ-менеджеров, аналитиков, продакт-менеджеров. Чтобы сырая тема взлетела, нужны первопроходцы, которые подтвердят, что всё работает и этим удобно пользоваться.

Если кто хочет поделиться решением третьей задачки из описанных выше welcome :-)
Подробнее..

Работа в IT не по специальности недоступная роскошь или захватывающий челлендж?

04.12.2020 12:06:11 | Автор: admin

Привет! Меня зовут Юля, и я технический писатель в Xsolla. В этой статье я расскажу о том, почему всех так привлекает IT-сфера и как в нее попасть, не имея соответствующих знаний и опыта. Поговорим о том, как начать учиться самостоятельно и какие при этом могут возникнуть трудности.


Если очень захотеть, можно IT-специалистом стать

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

Почему?

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

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

Как?

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

Специализированная литература

Освоение информационных технологий сейчас это не такой болезненный процесс, как 20 лет назад. На данный момент практически любую нужную вам книгу можно приобрести или скачать в интернете. В открытом доступе представлены тысячи ресурсов и материалов (как платных, так и бесплатных), по которым можно изучать интересующие вас темы. Очень много ценной информации для IT-специалистов можно найти на таких ресурсах, какhttp://personeltest.ru/aways/habr.com/ru/,http://academy.yandex.ru/,https://tproger.ru/,https://stackoverflow.com/и многих других.

Онлайн-обучение

Если литературы недостаточно, то больше знаний и мотивации могут дать онлайн-курсы. Их преимущество в том, что вы будете получать информацию системно и порционно, а полученные знания сможете закреплять с помощью домашних заданий. Чаще всего подобные курсы платные, однако сейчас, в период самоизоляции, многие платформы делают на свои курсы большие скидки или вовсе предоставляют к ним бесплатный доступ. Из популярных платформ стоит выделитьhttps://www.udemy.com/,https://htmlacademy.ru/,https://geekbrains.ru/,https://www.datacamp.com/.

Практические школы

В последнее время многие вузы и компании стали организовывать практические школы с целью привлечения потенциально крутых специалистов. С успехом подобные мероприятия проводили Сбербанк, Yandex, Xsolla, центр образования Level UP, НИУ ВШЭ и другие организации. Такой вариант обучения будет полезен тем, кто планирует получать знания не только из книг, но и от людей. В школах со студентами взаимодействуют лекторы и наставники, которые помогают лучше освоить информацию. Еще один плюс таких мероприятий в том, что большинство из них бесплатные, нужно лишь успешно выполнить тестовое задание. Школа может стать отличным пунктом в вашем будущем резюме. Кроме того, самым выдающимся выпускникам школ часто предлагают дальнейшее сотрудничество или стажировку. Кстати, о стажировках

Стажировка или практика

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

Магистратура в IT

Этот способ подойдет для тех, кто хочет получить не только знания, но и диплом IT-специалиста. Однако здесь есть несколько нюансов:

  • Первоклассную магистратуру, особенно в провинции, найти нелегко.

  • На обучение в магистратуре придется тратить достаточно много времени и сил.

  • Хорошая магистратура обойдется вам в круглую сумму.

  • Многие знания, полученные во время обучения, могут оказаться неактуальными на практике.

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

Мой путь из экономиста в технического писателя

Наверное, было бы глупо рассказывать о трудностях работы в мире IT не по специальности, не имея собственного опыта в этом. Именно поэтому расскажу немного о том, как я попала в IT-сферу, будучи экономистом.

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

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

Казалось бы, что самый сложный этап был пройден, но нет это было только начало. Первое время мой мозг разбухал от обилия информации. На ее изучение приходилось тратить много свободного от работы времени. Хочется отметить, что изучение чего-либо в IT процесс постоянный, поскольку сфера развивается очень быстро и новая информация появляется чуть ли не ежедневно; важно быть в тренде. Если же читать литературу не только по вашему направлению, но и по смежным это вдвойне круто, поскольку T-shaped специалисты (люди, у которых есть своя глубоко изученная специализация, а также желание развиваться в смежных областях) сейчас очень ценятся. В работе также часто приходится сталкиваться с замечаниями, поэтому еще один крутой скилл, который пригодится при построении карьеры в сфере технологий, устойчивость к критике. Важно понимать, что подобный фидбек помогает вам развиваться и перформить лучше.

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

Ты такой не один

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

Леонид Ратанов, Tech Lead

После обвала рубля в 1415 годах и принятого решения закрыть собственный бизнес, возник вопрос: чем заниматься дальше? Вспомнив о том, что в школьные годы активно участвовал в олимпиадах по информатике и математике, я поставил себе цель стать разработчиком. Закрыл бизнес, устроился наемным специалистом к своим конкурентам и по ночам и выходным начал изучать Java. Через полгода переключился на изучение Android.

Процесс самообучения был неравномерным мог неделями засиживаться за ноутбуком, а были перерывы длиной в полгода. Все это время я пилил свой собственный проект, в процессе постоянно изучая новые темы. Читал книги, статьи, проходил онлайн-курсы. В тот момент остро ощущалась нехватка фундаментальных знаний, отсутствие профильного образования. Через 2,5 года самообучения я наконец решился сменить сферу деятельности и с первой же попытки получил оффер на позицию Junior Android Developer. Рост был стремительным: за два года я дорос до позиции техлида в Xsolla.

Рецепт довольно простой ставить себе цель, постоянно поднимать планку и никогда не сдаваться!

Николай Гагаринов, Junior Backend Developer

Пришел из армии, не было ни законченного образования (не доучился на бухгалтера), ни опыта работы. Пошел продавцом в Магнит, потом сотрудником в колл-центр. Старший брат в то время учился на программиста, и я решил тоже попробовать. В свой первый в жизни отпуск сел учиться: занимался утром, вечером, в выходные, в праздники. Проходил онлайн-курсы, смотрел вебинары, читал книги, ходил на конференции хватал каждую крупицу знаний, которой делились опытные разработчики.

В декабре 2018 года набрался кое-какого опыта и устроился в стартап бэкенд-разработчиком. Через полгода, когда стало не хватать профессиональной поддержки (опытных коллег, у которых я мог бы учиться), снова начал искать работу. И меня позвали в Xsolla на позицию младшего разработчика.

Что бы я посоветовал:

  1. Не думать о том, что учиться уже поздно. Я знаю людей, которые пришли в IT после 3040 лет и добились успеха.

  2. Заниматься стоит регулярно выделять себе хотя бы 30 минут в день.

  3. Читать книги (например, Идеальный программист, Цель процесс непрерывного совершенствования).

  4. Не забывать отдыхать когда мы отдыхаем, мозг решает задачу в рассеянном режиме.

Егор Черных, Junior QA-специалист

Я закончил магистратуру по специальности ГМУ в НИУ ВШЭ Пермь, после чего начал заниматься предпринимательством (сеть сервисных центров по ремонту техники). Со временем бизнес перестал приносить желаемый доход, при этом отнимал довольно много сил и времени. Стал задумываться о смене сферы деятельности выбор пал на IT (компания G-Core Labs). Выбрал QA-направление (тестирование компьютерных игр), потому что это один из самых простых способов попасть в сферу, не имея профильного образования или навыков. Мне повезло, так как компания проводила бесплатное вступительное обучение, после которого я начал разбираться во всех аспектах деятельности. Сейчас я работаю web-тестировщиком в Xsolla и на данном этапе своего развития я считаю это своим наибольшим успехом!

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

Если вам интересен мир IT, то главный совет не бояться: спрашивать, узнавать что-то новое для себя, ходить на собеседования (даже если поначалу будут отказы). Все это дает определенный опыт и вектор дальнейшего развития, что стоит еще узнать. Если хочется стать разработчиком, лучше пройти курсы (хотя бы онлайн). Довольно много компаний на рынке ищут QA без опыта работы, на такие вакансии следует обратить внимание. На самом деле, сейчас в сети очень много материалов по теме IT, главное захотеть!

Максим Куртлацков, Product Owner

В 2010 я работал государственным инспектором в Ростехнадзоре. Инспектировал сильвинитовые шахты в Березниках и Соликамске. Позже была моя первая попытка прийти в digital-сферу: я устроился на позицию SMM-специалиста в рекламное агентство. Очень веселое было время, но голодное. Большая з/п сманила меня на север инспектировать инженерные изыскания магистральных газопроводов в Сибири и на Дальнем Востоке. По возвращении захотелось чего-то более серьезного и стабильного: пошел в нефтянку, ездил по вахтам в Заполярье, но все равно продолжал мечтать об играх. Популярные игровые движки стали бесплатными, и я начал их изучать в межвахтовках. Ввели санкции, что сразу отразилось на работе меня вскоре уволили, и я окончательно разочаровался в профессии. Отрасль лихорадило после санкций, поиск новой работы не увенчался успехом, поэтому я сконцентрировался на игровой разработке.

Когда нет опыта, портфолио и вообще какой-либо конкретной цели, самое лучшее, что может прийти на ум основать стартап! Так появилась моя первая компания VirtuLab. Я получил первые заказы, опыт фриланса и заказной работы. Денег было очень мало, пришлось вернуться на наемную работу, но уже в качестве стажера-разработчика. Это было всего два года назад Карьера стала очень бурно развиваться, через месяц из стажера вырос до начальника отдела визуализации, а через полгода пригласили с нуля организовать мобильную разработку казуальных игр. И я сделал это собранная команда зарелизила две игры вполне сносного качества. Год назад я пришел в Xsolla в качестве техлида, а теперь стал владельцем продукта игровых сервисов.

Главный совет не бояться что-то делать. Только так можно по-настоящему чему-то научится. Даже если ошибаешься, это все равно попадает в копилку опыта.

Анастасия Савостьянова, Flow-developer

На момент начала карьеры в IT профильного бэкграунда у меня не было я закончила эконом ПГНИУ и юриспруденцию в ВШЭ, а также училась на переводчика в Littera ПГНИУ. На момент принятия решения о смене отрасли работала в экономической сфере (сначала госсектор, затем коммерческая организация). Интерес к IT появился в 2017 году, когда я поняла, что хочу развиваться дальше. Выбирала сферу по следующим критериям:

  • Инновационная отрасль

  • Возможность самореализации

  • Работа над продуктами, которые действительно необходимы людям

  • Талантливые коллеги и динамично развивающееся комьюнити

Все это я нашла для себя в IT.

С момента появления мысли о переходе в IT-сферу начала учиться самостоятельно: проходила курсы на GeekBrains по программированию. Получив определенный пул знаний, решила искать работу. Первое место работы в IT ЭР-Телеком Холдинг: прошла конкурсный отбор на позицию бизнес-технолога, доросла до тимлида. Мне очень повезло с проектом желание создавать новое исполнилось. Однако мне не хватало IT-атмосферы, поскольку ЭРТХ в первую очередь телекоммуникационная компания.

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

За все время работы в IT прокачала свои навыки в продуктовом мышлении и программировании, стала лучше понимать свою команду. Мне удалось посетить конференцию Product Sense в Минске и удаленно поучаствовать в тренинге для продакт-менеджеров от Agilix Consulting.

Главный вопрос, который стоит задать себе, начиная карьеру в IT-сфере зачем? Чем четче вы определите ответ на этот вопрос, тем лучше будут результаты. Также необходимо решить, чем именно вы хотите заниматься направлений развития потенциала очень много.

Следующий важный элемент успеха подготовка к собеседованию. Без базовых знаний будет тяжело проявить себя и заинтересовать работодателя. В подготовке обязательно поможет изучение актуальных вакансий и необходимых компетенций. Эффективно также работает посещение митапов, на которых можно познакомиться с компаниями (потенциальными работодателями) и их комьюнити. Это поможет сформировать эффективный трек развития для смены сферы. И, конечно же, английский! В крупных IT-компаниях без него никуда, а значит практика, практика, практика.

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

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

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru