На этих выходных вместе с Махачом aka Архитектор (@architector_notes) посетили Грозный, где нас встретил Иса Эзербаев (@monoteistBlog) — старший брат IT-бороды.
У Исы было запланировано интервью с Go-разработчиком, студентом Школы 21. Так мы попали на съемки 🙃. Интересно было наблюдать за процессом, увидеть всякие закулисные фишки, поснимать бэкстейдж.
Видео появится на его
Please open Telegram to view this post
VIEW IN TELEGRAM
👍31
💫 Фичелидинг
Один из способов делегирования в разработке — фичелидинг (feature leading), когда разработчик становится ответственным за какую-то относительно крупную фичу. По сути он берет на себя обязанности техлида, но для определенной части проекта.
Лид фичи ответственен за нее от этапа идеи/первоначального ТЗ до момента запуска ее на проде. Он общается с заказчиками и другими стейкхолдерами, уточняя детали, прорабатывает архитектуру, разбивает ТЗ на задачи и затем приносит все это команде. Также он является конечной точкой во всех возникающих вопросах.
Для разработчика фичелидинг — это возможность прокачать навыки проектирования, управления, лучше прочувствовать сам продукт и процессы, да и просто отметиться на ревью, а для тех/тимлида — возможность вырастить своих подчиненных и снять с себя часть нагрузки.
Один из способов делегирования в разработке — фичелидинг (feature leading), когда разработчик становится ответственным за какую-то относительно крупную фичу. По сути он берет на себя обязанности техлида, но для определенной части проекта.
Лид фичи ответственен за нее от этапа идеи/первоначального ТЗ до момента запуска ее на проде. Он общается с заказчиками и другими стейкхолдерами, уточняя детали, прорабатывает архитектуру, разбивает ТЗ на задачи и затем приносит все это команде. Также он является конечной точкой во всех возникающих вопросах.
Для разработчика фичелидинг — это возможность прокачать навыки проектирования, управления, лучше прочувствовать сам продукт и процессы, да и просто отметиться на ревью, а для тех/тимлида — возможность вырастить своих подчиненных и снять с себя часть нагрузки.
👍19❤7🔥6
🏄 Мой опыт онбординга
По следам поста Муаммара.
Онбординг — процесс адаптации сотрудника на новой работе, который помогает ему быстрее включиться во все процессы.
Мне довелось пройти два онбординга — в Авито и в Яндексе. В моем случае это была удаленка: для тех, кто выходит в офис, процесс немного отличается.
В Яндексе этим занимается целая команда и работа по адаптации начинается еще до момента выхода сотрудника.
1. Выдача оборудования. В офисе это отдельные ребята, которые занимаются всеми вопросами по оборудованию. В моем случае ноут мне принес курьер.
2. Вход в корпоративный аккаунт. У крупных компаний обычно есть внутренний сервис, хранящий всю информацию о сотрудниках. С его помощью мы авторизуемся во всех остальных сервисах, в том числе внешних.
3. Созвон с командой адаптации. Рассказывают про оформление документов, различные плюшки а-ля ДМС, к кому обращаться с вопросами. Также добавляют в отдельный чат для новичков.
4. Знакомство с командой. В зависимости от формата работы — может быть вживую, в виде созвона или просто сообщением в чате.
5. Обучающие созвоны для новичков. Многие из которых можно пропустить.
6. Чеклист новичка. Обычно это задача в трекере с пунктами типа “Подписать документы”, “Добавиться в рабочие чаты”, “Получить доступы к коду”, “Пройти курс XXX”. У Яндекса есть отдельный красивый лендинг, который рассказывает, что нужно сделать в первые день, неделю и месяц.
7. Курсы. У тройки Яндекс, ВК, Авито есть внутренние LMS с различными курсами. В чеклисте обычно половина курсов — это всякие формальности типа “Охрана труда и безопасность в офисе”, которые можно прокликать, а другая половина — уроки по внутренним инструментам, которым стоит уделить внимание. Сюда же входит и NDA, который подскажет, что не стоит выносить за пределы компании.
8. Наставник/бадди. Обычно это опытный член команды. В Авито это был мой коллега-фронтендер, в Яндексе — мой тимлид, т. к. нас было всего двое 😀. Бадди отвечает на все вопросы новичка — по процессам, коду, корпоративной культуре и т. д. Если это офис, то он поможет получить бейдж и покажет что и где находится.
9. Личные встречи с руководителем. На них новичок и руководитель обсуждают прогресс по адаптации, могут глянуть чеклист, обсуждают возникшие вопросы. В первое время они были каждый день, со временем стали реже.
10. Цели и ожидания на период адаптации. Ставятся руководителем и представляют собой чеклист вида: “Должен уметь то-то и то-то, уметь решать такие-то задачи”.
11. Промежуточная и итоговые встречи. Встречи в середине и конце периода адаптации, где обсуждаются итоги онбординга.
Из интересного: когда на работу выходил наш новый сотрудник, я предложил нашему тимлиду сделать меня бадди. В этот период я как раз готовился перейти на позицию лида и этот опыт помог войти мне в эту роль более плавно.
В следующем посте я расскажу, что вы можете сделать, чтобы быстрее включиться в работу.
По следам поста Муаммара.
Онбординг — процесс адаптации сотрудника на новой работе, который помогает ему быстрее включиться во все процессы.
Мне довелось пройти два онбординга — в Авито и в Яндексе. В моем случае это была удаленка: для тех, кто выходит в офис, процесс немного отличается.
В Яндексе этим занимается целая команда и работа по адаптации начинается еще до момента выхода сотрудника.
1. Выдача оборудования. В офисе это отдельные ребята, которые занимаются всеми вопросами по оборудованию. В моем случае ноут мне принес курьер.
2. Вход в корпоративный аккаунт. У крупных компаний обычно есть внутренний сервис, хранящий всю информацию о сотрудниках. С его помощью мы авторизуемся во всех остальных сервисах, в том числе внешних.
3. Созвон с командой адаптации. Рассказывают про оформление документов, различные плюшки а-ля ДМС, к кому обращаться с вопросами. Также добавляют в отдельный чат для новичков.
4. Знакомство с командой. В зависимости от формата работы — может быть вживую, в виде созвона или просто сообщением в чате.
5. Обучающие созвоны для новичков. Многие из которых можно пропустить.
6. Чеклист новичка. Обычно это задача в трекере с пунктами типа “Подписать документы”, “Добавиться в рабочие чаты”, “Получить доступы к коду”, “Пройти курс XXX”. У Яндекса есть отдельный красивый лендинг, который рассказывает, что нужно сделать в первые день, неделю и месяц.
7. Курсы. У тройки Яндекс, ВК, Авито есть внутренние LMS с различными курсами. В чеклисте обычно половина курсов — это всякие формальности типа “Охрана труда и безопасность в офисе”, которые можно прокликать, а другая половина — уроки по внутренним инструментам, которым стоит уделить внимание. Сюда же входит и NDA, который подскажет, что не стоит выносить за пределы компании.
8. Наставник/бадди. Обычно это опытный член команды. В Авито это был мой коллега-фронтендер, в Яндексе — мой тимлид, т. к. нас было всего двое 😀. Бадди отвечает на все вопросы новичка — по процессам, коду, корпоративной культуре и т. д. Если это офис, то он поможет получить бейдж и покажет что и где находится.
9. Личные встречи с руководителем. На них новичок и руководитель обсуждают прогресс по адаптации, могут глянуть чеклист, обсуждают возникшие вопросы. В первое время они были каждый день, со временем стали реже.
10. Цели и ожидания на период адаптации. Ставятся руководителем и представляют собой чеклист вида: “Должен уметь то-то и то-то, уметь решать такие-то задачи”.
11. Промежуточная и итоговые встречи. Встречи в середине и конце периода адаптации, где обсуждаются итоги онбординга.
Из интересного: когда на работу выходил наш новый сотрудник, я предложил нашему тимлиду сделать меня бадди. В этот период я как раз готовился перейти на позицию лида и этот опыт помог войти мне в эту роль более плавно.
В следующем посте я расскажу, что вы можете сделать, чтобы быстрее включиться в работу.
👍32❤10🔥4
Кстати, не так давно я завел веб-версию блога. Сделан на Gatsby, хостится на Netlify + GitHub. Cами посты пишутся в формате Markdown.
Выглядит пока неказисто, но мне почему-то всегда хотелось иметь блог именно в виде сайта, не запариваясь при этом с хостингом, базами данных и прочим.
Выглядит пока неказисто, но мне почему-то всегда хотелось иметь блог именно в виде сайта, не запариваясь при этом с хостингом, базами данных и прочим.
👍19🔥5🤨1
🚀 Как быстро влиться в работу
… и пройти испытательный срок.
Выходите на работу отдохнувшим
Первое, что стоит сделать перед выходом на новую работу — это хорошо отдохнуть. На мой взгляд, первые два-три месяца работы — это немного не про work-life balance. Придется разбираться в продукте, процессах, инструментах, кодовой базе и лучше сделать это быстро. И хотя в первое время от вас не ожидается серьезного вклада в проект — это не повод расслабляться.
Изучите ваш продукт
Продукт — товар или услуга, несущие какую-то ценность для клиента, закрывающая его потребность.
Знание продукта позволит лучше понимать задачи и говорить с коллегами на одном языке.
Что можно сделать для этого?
🟠 Попользуйтесь вашим продуктом, изучите различные пользовательские сценарии
🟠 Почитайте пользовательскую документацию
🟠 Изучите глоссарий проекта — словарь часто используемых терминов
Немного неочевидный момент (по крайней мере, был для меня) — обычно на многие вопросы по продукту кроме продакта могут ответить тестировщики, т. к. они проходят все эти сценарии по многу раз. У них же можно спросить про тестовые стенды, креды и все прочее.
Созвонитесь с наставником
🟠 Спросите про продукт, архитектуру проекта, процессы, с кем придется взаимодействовать (бэк, фронт, дизайнеры, тестировщики, смежные команды)
🟠 Можно спросить про текущие подпроекты и их статус — какие-то крупные фичи с долгим циклом разработки
🟠 Определите цели на испытательный срок
Задавайте вопросы
Не стесняйтесь задавать вопросы бадди, руководителю и в чатах, особенно на этапе онбординга.
Не исключено, что вы делаете все правильно и ошибка не на вашей стороне: документация могла устареть, задача плохо описана, что-то сломалось и т. п. Если поиск решения занимает больше пары часов — лучше пойти с вопросом к коллегам.
Держите руку на пульсе
🟠 Периодически сверяйтесь с ожиданиями на испытательный срок и проводите ретроспективу своей работы — все ли идет по плану?
🟠 Используйте one-to-one: подсвечивайте проблемы и опасения, запрашивайте фидбек
Записывайте потенциальные места для улучшения
Это могут быть как технические улучшения, так и улучшения в процессах.
Пока все ново глаз не замылен, можно увидеть то, что не замечают коллеги. Зафиксируйте их и отложите до момента, когда вы разберетесь в проекте, поймете почему сделано так или иначе и получите какой-то авторитет в команде. После этого можно вернуться к своим заметкам и, если они актуальны, предложить их команде.
Post Scriptum
Для себя я составил небольшой чек-лист действий и вопросов при вливании в проект, которые касаются технических моментов, процессов и т. д., вы можете сделать так же. Если дойдут руки нормально оформить его — выложу сюда, ин шаа Ллах.
Все написанное основано на личном опыте, либо на том, что я наблюдал со стороны.
Предлагаю обсудить в комментариях, что помогает вам при адаптации на новой работе.
… и пройти испытательный срок.
Выходите на работу отдохнувшим
Первое, что стоит сделать перед выходом на новую работу — это хорошо отдохнуть. На мой взгляд, первые два-три месяца работы — это немного не про work-life balance. Придется разбираться в продукте, процессах, инструментах, кодовой базе и лучше сделать это быстро. И хотя в первое время от вас не ожидается серьезного вклада в проект — это не повод расслабляться.
Изучите ваш продукт
Продукт — товар или услуга, несущие какую-то ценность для клиента, закрывающая его потребность.
Знание продукта позволит лучше понимать задачи и говорить с коллегами на одном языке.
Что можно сделать для этого?
Немного неочевидный момент (по крайней мере, был для меня) — обычно на многие вопросы по продукту кроме продакта могут ответить тестировщики, т. к. они проходят все эти сценарии по многу раз. У них же можно спросить про тестовые стенды, креды и все прочее.
Созвонитесь с наставником
Задавайте вопросы
Не стесняйтесь задавать вопросы бадди, руководителю и в чатах, особенно на этапе онбординга.
Не исключено, что вы делаете все правильно и ошибка не на вашей стороне: документация могла устареть, задача плохо описана, что-то сломалось и т. п. Если поиск решения занимает больше пары часов — лучше пойти с вопросом к коллегам.
Держите руку на пульсе
Записывайте потенциальные места для улучшения
Это могут быть как технические улучшения, так и улучшения в процессах.
Пока все ново глаз не замылен, можно увидеть то, что не замечают коллеги. Зафиксируйте их и отложите до момента, когда вы разберетесь в проекте, поймете почему сделано так или иначе и получите какой-то авторитет в команде. После этого можно вернуться к своим заметкам и, если они актуальны, предложить их команде.
Post Scriptum
Для себя я составил небольшой чек-лист действий и вопросов при вливании в проект, которые касаются технических моментов, процессов и т. д., вы можете сделать так же. Если дойдут руки нормально оформить его — выложу сюда, ин шаа Ллах.
Все написанное основано на личном опыте, либо на том, что я наблюдал со стороны.
Предлагаю обсудить в комментариях, что помогает вам при адаптации на новой работе.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍30❤10🔥6
السلام عليكم ورحمة الله وبركاته
Поздравляю всех мусульман с праздником 'Ид аль-Фитр!
تقبل الله منا ومنكم
Поздравляю всех мусульман с праздником 'Ид аль-Фитр!
تقبل الله منا ومنكم
❤43❤🔥7👍5😡1
🧑💻 Как я провожу финальные собеседования
За последнее время я провел чуть более 30 финальных встреч с кандидатами на позицию разработчика в нашу команду — относительно небольшое количество, если сравнивать с бывалыми тимлидами, но дающее полезные инсайды для рядового разработчика.
В посте я расскажу:
🟠 Какие этапы собеседований есть в крупных компаниях
🟠 Как выглядит финальная встреча с нанимающей стороны
🟠 Какие вопросы я задаю и на что обращаю внимание
🟠 Как определяется итоговый грейд и почему важно сделать это точно
🟠 Что опыт собеседования дает мне
https://imangazaliev.dev/blog/how-i-conduct-final-interview
За последнее время я провел чуть более 30 финальных встреч с кандидатами на позицию разработчика в нашу команду — относительно небольшое количество, если сравнивать с бывалыми тимлидами, но дающее полезные инсайды для рядового разработчика.
В посте я расскажу:
https://imangazaliev.dev/blog/how-i-conduct-final-interview
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥21👍5❤4
Были времена 😆
В свое время подолгу зависал на форуме boolean.name в разделе про MIDletPascal. На этом языке мы с братом писали приложения для своих нокий, иногда соревнуясь чье приложение круче.
Где-то здесь можно найти наши проекты — я писал движок для мобильных журналов (в то время они были очень популярны), а брат — приложение для подбора цвета.
А еще GitHub хранит мои первые шаги в веб-разработке: первый сайт на PHP и проект на Vue. Тогда я еще не знал про Git, поэтому в некоторых проектах можно заметить папки «v1», «v2» 😁
В свое время подолгу зависал на форуме boolean.name в разделе про MIDletPascal. На этом языке мы с братом писали приложения для своих нокий, иногда соревнуясь чье приложение круче.
Где-то здесь можно найти наши проекты — я писал движок для мобильных журналов (в то время они были очень популярны), а брат — приложение для подбора цвета.
А еще GitHub хранит мои первые шаги в веб-разработке: первый сайт на PHP и проект на Vue. Тогда я еще не знал про Git, поэтому в некоторых проектах можно заметить папки «v1», «v2» 😁
❤12😁9👍2
🤔 О чем спросить на собеседовании?
Часто мы воспринимаем собеседование как экзамен, где наша главная цель — просто пройти его. На самом деле компания не меньше нашего заинтересована в найме подходящего кандидата — задачи-то ждут 🙂 И если джунам выбирать особо не приходится, то у мидлов и выше такая возможность есть.
Чтобы выбрать правильный оффер и не разочароваться после выхода на работу, просто задавайте вопросы 🤷♂️
Какие моменты нужно прояснить для себя:
🟠 Продукт — что из себя представляет, какую ценность несет для пользователя и сколько этих самых пользователей
🟠 Технологии — стек, архитектура
🟠 Команда — размер, состав
🟠 Процессы — откуда приходят задачи, как планируют, работают, оценивают результаты
🟠 Планы на ближайшее время (условно, год)
🟠 Задачи, которые будут стоять перед вами
Хорошо бы записать ответы, чтобы взять время подумать или сравнить офферы.
Часто ситуацию, когда мы задаем вопросы называют обратным собеседованием (reverse interview) — можно погуглить и найти список вопросов. Есть пара неплохих подборок: раз и два.
Не стоит задавать все вопросы из списка — проанализируйте свой предыдущий опыт и выберите важное для себя. Еще вопросы зависят от самой компании. К примеру стартапам свойственны горящие дедлайны, переработки, ограниченные финансы и неожиданные закрытия — имеет смысл спросить об оплате переработок, наличии реальных клиентов. В других компаниях стоит спросить про легаси и т. д.
В комментариях можем обсудить какие вопросы задали бы вы.
Часто мы воспринимаем собеседование как экзамен, где наша главная цель — просто пройти его. На самом деле компания не меньше нашего заинтересована в найме подходящего кандидата — задачи-то ждут 🙂 И если джунам выбирать особо не приходится, то у мидлов и выше такая возможность есть.
Чтобы выбрать правильный оффер и не разочароваться после выхода на работу, просто задавайте вопросы 🤷♂️
Какие моменты нужно прояснить для себя:
Хорошо бы записать ответы, чтобы взять время подумать или сравнить офферы.
Часто ситуацию, когда мы задаем вопросы называют обратным собеседованием (reverse interview) — можно погуглить и найти список вопросов. Есть пара неплохих подборок: раз и два.
Не стоит задавать все вопросы из списка — проанализируйте свой предыдущий опыт и выберите важное для себя. Еще вопросы зависят от самой компании. К примеру стартапам свойственны горящие дедлайны, переработки, ограниченные финансы и неожиданные закрытия — имеет смысл спросить об оплате переработок, наличии реальных клиентов. В других компаниях стоит спросить про легаси и т. д.
В комментариях можем обсудить какие вопросы задали бы вы.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍20🔥8
👨💻 Так ли тяжело найти первую работу в IT?
Часто от джунов можно услышать жалобы насколько тяжело стало найти первую работу: то на отклики не отвечают, то на собеседовании слишком много требуют. Но на самом ли деле джуны прикладывают все усилия, чтобы получить желанный оффер?
Что сделал бы я на месте джуна с текущими знаниями о поиске работы:
🟠 Проанализировал свой день и исключил все отвлекающие факторы — фокус только на поиске работы
🟠 Хорошо оформил резюме: проанализировал чужие резюме, посмотрел разборы на Ютубе и попросил ревью у эксперта
🟠 Разместил его на всевозможных площадках. Есть около десятка популярных сайтов кроме hh.ru или Хабр Карьеры, каналы в Telegram и группы в ВК, сайты крупных компаний, аутсорс и аутстафф-контор
🟠 Адаптировал сопроводительные письма под каждую вакансию
🟠 Оформил GitHub с несколькими пет-проектами, красивым README и демо (!)
🟠 Просмотрел записи интервью на Ютубе, которых там десятки
🟠 Нашел топ 50 / 100 вопросов на собеседовании в своем направлении и отточил их до совершенства
🟠 Прошел мок-интервью
🟠 Подался на стажировки, которых тоже десятки
🟠 Нашел контакты HR, менеджеров или разработчиков и написал им в личку, либо нашел еще более оригинальные способы выделиться из толпы
🟠 Записался на карьерную консультацию на Хабр Карьере, Solvery, GetMentor, Эйч (есть кто делает это бесплатно)
🟠 Нашел себе ментора
Как это обычно выглядит на самом деле:
🛑 Резюме: в графе «О себе» максимально общее описание, места работы указаны без каких-либо подробностей
🛑 Резюме размещено на одной-двух площадках
🛑 Отклики с шаблонным текстом
🛑 Пустой GitHub или проекты, сделанные на курсе под копирку (которые рекрутеры уже знают наизусть)
🛑 Не могут внятно ответить на базовые вопросы по своему стеку
IT-сфера повзрослела и не нужно сравнивать ее с ситуацией 10-летней давности, когда для устройства на работу было достаточно самых базовых знаний.
Напоследок подкину пару полезных ссылок:
🟠 Пример ревью резюме
🟠 Сайт EasyOffer. Автор проделал большую работу: собрал частые вопросы на собесах, привел ответы для многих из них + к этому проанализировал мок-интервью и дал ссылки с таймкодами, чтобы вы могли посмотреть как отвечают другие.
🛑 Подписаться на Imangazaliev Blog
Часто от джунов можно услышать жалобы насколько тяжело стало найти первую работу: то на отклики не отвечают, то на собеседовании слишком много требуют. Но на самом ли деле джуны прикладывают все усилия, чтобы получить желанный оффер?
Что сделал бы я на месте джуна с текущими знаниями о поиске работы:
Как это обычно выглядит на самом деле:
IT-сфера повзрослела и не нужно сравнивать ее с ситуацией 10-летней давности, когда для устройства на работу было достаточно самых базовых знаний.
Напоследок подкину пару полезных ссылок:
Please open Telegram to view this post
VIEW IN TELEGRAM
👍38❤8🔥8
السلام عليكم ورحمة الله وبركاته
Поздравляю всех мусульман с праздником 'Ид аль-Адха!
تقبل الله منا ومنكم
Поздравляю всех мусульман с праздником 'Ид аль-Адха!
تقبل الله منا ومنكم
❤30❤🔥5👍2🔥2😎2
🗓 Квартальное планирование
На этой неделе у нас в Яндекс 360 прошло очередное планирование. На нем примерно 150 человек и 20 команд пытаются понять, что они будут делать следующие три месяца. Процесс сложный, немного выматывающий, но очень интересный.
🗂 Сбор бэклога и капасити
Примерно за 2 недели до планирования начинает формироваться бэклог — список задач, которые мы потенциально можем взять. Задачи приносят продакт, техлид и другие команды. Плюс к этому часть задач можем переехать с предыдущего квартала.
Чтобы не забивать на техническое развитие, в бэклоге должно быть определенное соотношение продуктовых и технических задач.
Каждую задачу нужно оценить в днях дизайна, разработки и тестирования. Точность оценки зависит от степени проработки задачи — где-то уже есть дизайн и описание API, а где-то только тех. задание.
Еще у команды есть ограниченные ресурсы дизайна, разработки и тестирования. Для них рассчитывается капасити (емкость) с учетом отпусков, дежурств, созвонов и т. д. Объем бэклога больше, чем команда реально способна переварить — просто потому что часть задач может отвалиться на следующих этапах.
🤝 Согласование бэклогов
Когда бэклоги команд сформированы, начинается самое интересное — нужно согласовать их друг с другом. Происходит это на общем созвоне, где десятки курсоров бегают по доске в Miro и раскладывают стикеры на табличке со спринтами (скрин выше). У каждой команды своя комната в зуме — по ним можно ходить и разруливать связанные задачи.
Кроме задач прописываются риски — факторы, которые влияют на выполнение задачи. У каждого риска есть причины, последствия и возможные решения. К примеру, это может быть нехватка каких-то ресурсов, из-за чего могут поехать сроки и команда не уложится дедлайн. Для такого случая можно придумать разные решения — нанять новых людей, взять на время из других команд, взять аутстафф, изменить ТЗ — и у каждого такого решения есть свои плюсы и минусы.
В финале команды представляют свои планы стейкхолдерам, получают фидбек и могут скорректировать их по этому фидбеку.
🎯 Удается ли уложиться в сроки?
Квартал состоит примерно 6 спринтов, из которых планируется в норме только 5. Шестой спринт нужен для того, чтобы добить хвосты и подготовиться к следующему планированию.
Часть задач так или иначе съезжает на следующий квартал, либо целиком, либо в виде доработок, но с каждым разом процесс совершенствуется и, надеюсь, попадание будет более точным.
Например, в первом квартале мы допустили ошибку, запланировав на меня задачи наравне с другими разработчиками, из-за чего мне не удалось уделить достаточно времени найму и работой над процессами. Во втором квартале мы это пофиксили, благодаря чему удалось нанять троих разработчиков и немного улучшить процессы.
Также теперь мы чуть раньше начинаем проработку задач, запланированных на квартал — сразу после планирования я смотрю какие вопросы можно решить в самом начале, чтобы потом это не стало блокером — согласовать контракты API, доступы и т. д.
Если интересна тема, можно погуглить про PI-планирование и Scaled Agile Framework (SAFe).
🛑 Подписаться на Imangazaliev Blog
На этой неделе у нас в Яндекс 360 прошло очередное планирование. На нем примерно 150 человек и 20 команд пытаются понять, что они будут делать следующие три месяца. Процесс сложный, немного выматывающий, но очень интересный.
🗂 Сбор бэклога и капасити
Примерно за 2 недели до планирования начинает формироваться бэклог — список задач, которые мы потенциально можем взять. Задачи приносят продакт, техлид и другие команды. Плюс к этому часть задач можем переехать с предыдущего квартала.
Чтобы не забивать на техническое развитие, в бэклоге должно быть определенное соотношение продуктовых и технических задач.
Каждую задачу нужно оценить в днях дизайна, разработки и тестирования. Точность оценки зависит от степени проработки задачи — где-то уже есть дизайн и описание API, а где-то только тех. задание.
Еще у команды есть ограниченные ресурсы дизайна, разработки и тестирования. Для них рассчитывается капасити (емкость) с учетом отпусков, дежурств, созвонов и т. д. Объем бэклога больше, чем команда реально способна переварить — просто потому что часть задач может отвалиться на следующих этапах.
🤝 Согласование бэклогов
Когда бэклоги команд сформированы, начинается самое интересное — нужно согласовать их друг с другом. Происходит это на общем созвоне, где десятки курсоров бегают по доске в Miro и раскладывают стикеры на табличке со спринтами (скрин выше). У каждой команды своя комната в зуме — по ним можно ходить и разруливать связанные задачи.
Кроме задач прописываются риски — факторы, которые влияют на выполнение задачи. У каждого риска есть причины, последствия и возможные решения. К примеру, это может быть нехватка каких-то ресурсов, из-за чего могут поехать сроки и команда не уложится дедлайн. Для такого случая можно придумать разные решения — нанять новых людей, взять на время из других команд, взять аутстафф, изменить ТЗ — и у каждого такого решения есть свои плюсы и минусы.
В финале команды представляют свои планы стейкхолдерам, получают фидбек и могут скорректировать их по этому фидбеку.
🎯 Удается ли уложиться в сроки?
Квартал состоит примерно 6 спринтов, из которых планируется в норме только 5. Шестой спринт нужен для того, чтобы добить хвосты и подготовиться к следующему планированию.
Часть задач так или иначе съезжает на следующий квартал, либо целиком, либо в виде доработок, но с каждым разом процесс совершенствуется и, надеюсь, попадание будет более точным.
Например, в первом квартале мы допустили ошибку, запланировав на меня задачи наравне с другими разработчиками, из-за чего мне не удалось уделить достаточно времени найму и работой над процессами. Во втором квартале мы это пофиксили, благодаря чему удалось нанять троих разработчиков и немного улучшить процессы.
Также теперь мы чуть раньше начинаем проработку задач, запланированных на квартал — сразу после планирования я смотрю какие вопросы можно решить в самом начале, чтобы потом это не стало блокером — согласовать контракты API, доступы и т. д.
Если интересна тема, можно погуглить про PI-планирование и Scaled Agile Framework (SAFe).
Please open Telegram to view this post
VIEW IN TELEGRAM
👍25🔥8❤6🤔1
🗑 Кладбища полезных материалов
Как-то листал чат, куда я сохраняю полезные материалы и наткнулся на сообщение 2016 года про библиотеку Riot.js — эдакий Vue.js на минималках. С нее я начинал свой путь во фронтенде и она уже практически мертва.
Чуть ниже в этом чате была ссылка на «100 полезных каналов и чатов для программистов», а еще ниже — статья про фразовые глаголы в английском языке. Таких чатов у меня в телеге с десяток.
Есть у меня привычка накапливать полезные (как мне кажется) материалы — своеобразный синдром Плюшкина.
Когда я сидел в ВК, это были репосты на стену; когда активно использовал Discord — отдельный сервер с каналами по тематикам. Ни в ВК, ни в Discord я уже давно не захожу и эти материалы так и остались лежать там.
Сложно представить сколько тысяч «полезных» ссылок, файлов и видео, сохраненных мною, лежит мертвым грузом.
Многое из этого либо уже неактуально само по себе (как в случае с Riot.js), либо стало неинтересно мне, либо я это уже изучил, когда возникла необходимость.
Простые выводы:
🟠 Нет смысла накапливать полезные материалы впрок. Когда требуется информация по определенной теме, я не иду искать в сохраненном, а просто гуглю.
🟠 Никогда не будет подходящего момента, когда можно будет не спеша читать эти статьи. Как и с любым другим делом, которое откладывается на потом, тут вопрос только в приоритетах.
🟠 Ссылки накапливаются быстрее, чем я их просматриваю. Чтобы просмотреть весь накопленный материал, наверняка не хватит и всей жизни (только если не тратить на это все свое время).
Что можно с этим сделать:
🛑 Меньше сохранять. Читать здесь и сейчас или просто закрыть и забыть.
🛑 Сохранять структурировано. Использовать базы в Notion — теги, описание, когда и зачем сохранил, привязывать их к какому-то проекту.
🛑 Беспощадно удалять сохраненное. Я много раз случайно закрывал сотни вкладок в браузере, несколько раз полностью терял все данные на диске и один раз удалил чат в телеге с сотнями ссылок и, вроде, ничего 🙂
🛑 Использовать инструменты, которые дают саммари — Яндекс Браузер, ChatGPT.
🛑 Периодически уделять время на просмотр накопленных материалов.
Немного погуглив на тему подобного накопительства нашел видео Дорофеева, тоже полезно послушать.
🛑 Подписаться на Imangazaliev Blog
Как-то листал чат, куда я сохраняю полезные материалы и наткнулся на сообщение 2016 года про библиотеку Riot.js — эдакий Vue.js на минималках. С нее я начинал свой путь во фронтенде и она уже практически мертва.
Чуть ниже в этом чате была ссылка на «100 полезных каналов и чатов для программистов», а еще ниже — статья про фразовые глаголы в английском языке. Таких чатов у меня в телеге с десяток.
Есть у меня привычка накапливать полезные (как мне кажется) материалы — своеобразный синдром Плюшкина.
Когда я сидел в ВК, это были репосты на стену; когда активно использовал Discord — отдельный сервер с каналами по тематикам. Ни в ВК, ни в Discord я уже давно не захожу и эти материалы так и остались лежать там.
Сложно представить сколько тысяч «полезных» ссылок, файлов и видео, сохраненных мною, лежит мертвым грузом.
Многое из этого либо уже неактуально само по себе (как в случае с Riot.js), либо стало неинтересно мне, либо я это уже изучил, когда возникла необходимость.
Простые выводы:
Что можно с этим сделать:
Немного погуглив на тему подобного накопительства нашел видео Дорофеева, тоже полезно послушать.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍20🔥4❤2🤔1
🔍 Как проходит HR-скрининг
Скрининг — это короткий созвон с рекрутером перед полноценными этапами собеседования. Цель скрининга — быстро отсеять неподходящих кандидатов и составить первичную картину.
Что спрашивают?
🟠 Текущий статус. Где и на какой позиции сейчас работаешь, насколько активно ищешь, есть ли офферы от других компаний (лучше их иметь).
🟠 Опыт. Сколько лет в разработке, какие задачи решал, в каких командах работал. Могут спросить про опыт работы с определенными технологиями и задать пару технических вопросов.
Для высоких грейдов: есть ли опыт управления, проектирования архитектуры, запуска крупных проектов.
🟠 Причины поиска. Норм ответ — достиг потолка в развитии, однотипные задачи, нестабильность компании и т. д.
Тут стоит быть осторожным: если ты говоришь, что достиг потолка в развитии в условном Яндексе будучи джуном, то это звоночек. Также не стоит излишне изливать негатив — может быть воспринято не в твою пользу.
🟠 Зарплатные ожидания. Анализируем рынок и определяем для себя желаемую компенсацию. Не нужно стесняться называть какие-то цифры (например, по верху вилки), торговаться и т. п. — адекватные компании воспринимают это нормально. Чтобы чувствовать себя увереннее важно иметь несколько офферов.
При анализе лучше не только смотреть вакансии и периодические отчеты по зарплатам (в них цифры зачастую занижены), но и поспрашивать знакомых — они дадут куда более точные результаты. Если это лид, то он, основываясь на своем опыте, может еще примерно сориентировать по вилкам.
🟠 Мотивация. Какие задачи интересны, что важно в работе, чем не хотелось бы заниматься.
На все вопросы лучше подготовить ответы заранее — обычно созвон проходит в темпе и времени подумать не так много. Также не стоит стесняться ненавязчиво говорить о своих достижениях.
По итогам рекрутер напишет фидбек, который виден собеседующим на последующих этапах. Кроме этого он(а) расскажет о компании или подразделении, куда ведется найм. Тут самое время вспомнить вопросы из поста про reverse interview.
🛑 Подписаться на Imangazaliev Blog
Скрининг — это короткий созвон с рекрутером перед полноценными этапами собеседования. Цель скрининга — быстро отсеять неподходящих кандидатов и составить первичную картину.
Что спрашивают?
Для высоких грейдов: есть ли опыт управления, проектирования архитектуры, запуска крупных проектов.
Тут стоит быть осторожным: если ты говоришь, что достиг потолка в развитии в условном Яндексе будучи джуном, то это звоночек. Также не стоит излишне изливать негатив — может быть воспринято не в твою пользу.
При анализе лучше не только смотреть вакансии и периодические отчеты по зарплатам (в них цифры зачастую занижены), но и поспрашивать знакомых — они дадут куда более точные результаты. Если это лид, то он, основываясь на своем опыте, может еще примерно сориентировать по вилкам.
На все вопросы лучше подготовить ответы заранее — обычно созвон проходит в темпе и времени подумать не так много. Также не стоит стесняться ненавязчиво говорить о своих достижениях.
По итогам рекрутер напишет фидбек, который виден собеседующим на последующих этапах. Кроме этого он(а) расскажет о компании или подразделении, куда ведется найм. Тут самое время вспомнить вопросы из поста про reverse interview.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍27🔥8❤5
Альтернативы Notion 🧑💻
9 сентября российские аккаунты Notion будут отключены и данные станут недоступны. Печалька. Есть еще надежда, что они найдут выход, как Miro )
Какие есть альтернативы:
🟠 Переехать на какой-нибудь облачный сервис (список альтернатив на Reddit). Из более-менее адекватного показалось Coda.
🟠 self hosted-решение
🟠 Уехать из России
Какие есть варианты self-hosted:
🟠 Распиаренный Obsidian. Мне не зашел, слишком много телодвижений нужно для того, что делалось в Notion в один клик. Возможно, это как-то настраивается, если обвешаться плагинами, но чет как-то не хочется. Из плюсов, что можно положить в Git.
🟠 Outline — визуально похож на Notion. Пару лет назад поднимал его через докер одной командой — пользоваться можно. Были небольшие баги в интерфейсе, но, учитывая, как он активно развивается, думаю, их давно пофиксили. Нужно только подумать над бэкапами.
🛑 Подписаться на Imangazaliev Blog
9 сентября российские аккаунты Notion будут отключены и данные станут недоступны. Печалька. Есть еще надежда, что они найдут выход, как Miro )
Какие есть альтернативы:
Какие есть варианты self-hosted:
Please open Telegram to view this post
VIEW IN TELEGRAM
👍9🔥7❤3
💁 Джун, который достиг потолка
Вспомнился случай, когда мы искали в команду фронтенд-разработчика уровня мидл-сеньор.
Как я писал ранее, после технических секций профили кандидатов приходят на рассмотрение к тимлидам для финального собеседования.
Один из таких финалов у меня проходил с челом из СберТеха. По техническим секциям грейд оценивался как мидл / мидл+.
Стандартный вопрос, который влияет на грейд: «Расскажи о самой сложной / масштабной задаче, которую ты решал». Рассказал о паре задач уровня джун+ / низ мидла.
На вопрос почему хочет уйти из Сбера ответил: «Есть сложности с ростом». Это триггернуло, учитывая, что СберТех — это не веб-студия и работал он там всего 4 месяца. Когда начали копать, выяснилось, что он недоволен своей текущей ЗП — назвал маленькую цифру на этапе оффера. При этом на скрининге сказал, что ему просто всегда был интересен Яндекс.
Дальше было самое интересное: по ходу собеса кандидат отметил, что хочет стать тимлидом в ближайшей перспективе. Тут я почувствовал, что мой трон пошатнулся и я напрягся 😆 (нет). Опыта управления людьми как такового не было.
На финале с другим лидом тот спросил его: «Что, если тебе не будут давать эту позицию три года подряд?». Ответил, что будет искать другую компанию. При том, что это абсолютная норма.
Спустя время посмотрел другие его финалы — замечания были очень похожими, в итоге его так никуда и не взяли.
Какие выводы можно из этого сделать?
🟠 Адекватно оценивайте себя
🟠 Проработайте свое позиционирование: какой у вас стек, куда хотите развиваться (разработка или управление)
🟠 Проработайте кейсы, о которых вы будете рассказывать
🟠 Не нужно вываливать свой поток сознания на рекрутера и собеседующих — продумайте ответы, которые будут совпадать с ожиданиями работодателя (для этого необязательно лгать)
Как рассказывать о кейсах расскажу в следующих постах.
🛑 Подписаться на Imangazaliev Blog
Вспомнился случай, когда мы искали в команду фронтенд-разработчика уровня мидл-сеньор.
Как я писал ранее, после технических секций профили кандидатов приходят на рассмотрение к тимлидам для финального собеседования.
Один из таких финалов у меня проходил с челом из СберТеха. По техническим секциям грейд оценивался как мидл / мидл+.
Стандартный вопрос, который влияет на грейд: «Расскажи о самой сложной / масштабной задаче, которую ты решал». Рассказал о паре задач уровня джун+ / низ мидла.
На вопрос почему хочет уйти из Сбера ответил: «Есть сложности с ростом». Это триггернуло, учитывая, что СберТех — это не веб-студия и работал он там всего 4 месяца. Когда начали копать, выяснилось, что он недоволен своей текущей ЗП — назвал маленькую цифру на этапе оффера. При этом на скрининге сказал, что ему просто всегда был интересен Яндекс.
Дальше было самое интересное: по ходу собеса кандидат отметил, что хочет стать тимлидом в ближайшей перспективе. Тут я почувствовал, что мой трон пошатнулся и я напрягся 😆 (нет). Опыта управления людьми как такового не было.
На финале с другим лидом тот спросил его: «Что, если тебе не будут давать эту позицию три года подряд?». Ответил, что будет искать другую компанию. При том, что это абсолютная норма.
Спустя время посмотрел другие его финалы — замечания были очень похожими, в итоге его так никуда и не взяли.
Какие выводы можно из этого сделать?
Как рассказывать о кейсах расскажу в следующих постах.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍40❤6🔥5
ex-Yandex
Вчера был последний день в Яндексе.
Много чему научился за эти полтора года, особенно в последние 9 месяцев на позиции руководителя.
Решение об уходе не приходит спонтанно, просто в какой-то момент причины, подталкивающие к этому, перевешивают. В моем случае это:
🟠 Высокая нагрузка. Кажется, это в целом особенность бигтехов и компаний с налаженными процессами ревью и планирования. Все бы ничего, если бы не второй пункт.
🟠 Сложности финансового роста. Есть вариант перерабатывать и получаться высоки оценки, но на высоком грейде это делать все сложнее. Work-life balance сильно смещается в сторону work, при этом нет никаких гарантий роста по вилке в рамках грейда. Как ни крути, смена компании все равно остается самым действенным методом поднять свой доход.
🟠 Желание перейти на Go. Думал об этом уже очень давно, еще когда шел в Яндекс. Был план спустя годик ротироваться внутри компании, но когда попал на позицию руководителя планы немного изменились — менеджмент мне тоже был интересен 🙂
Несмотря на то, что мне нравились проект, команда и атмосфера в нашем подразделении, все это породило твердое желание начать поиски.
Было две компании, куда я метил — это😄 Wildberries и 😊 Авито.
Wildberries все затягивал с собесами из-за последних событий, а в Авито все секции прошли дней за 10 в рамках тимлид-марафона.
Как и в прошлый раз, в Авито я попал по рефералке от Яхьи (@easybackend), пусть Аллах воздаст ему наилучшим.
Уже в понедельник стартуем, ин шаа Ллах, а пока я безработный 😌
🛑 Подписаться на Imangazaliev Blog
Вчера был последний день в Яндексе.
Много чему научился за эти полтора года, особенно в последние 9 месяцев на позиции руководителя.
Решение об уходе не приходит спонтанно, просто в какой-то момент причины, подталкивающие к этому, перевешивают. В моем случае это:
Несмотря на то, что мне нравились проект, команда и атмосфера в нашем подразделении, все это породило твердое желание начать поиски.
Было две компании, куда я метил — это
Wildberries все затягивал с собесами из-за последних событий, а в Авито все секции прошли дней за 10 в рамках тимлид-марафона.
Как и в прошлый раз, в Авито я попал по рефералке от Яхьи (@easybackend), пусть Аллах воздаст ему наилучшим.
Уже в понедельник стартуем, ин шаа Ллах, а пока я безработный 😌
Please open Telegram to view this post
VIEW IN TELEGRAM
28👍39🔥12❤6❤🔥4👏2
Спроси маму
Сегодня ненароком ощутил мощь проблемных интервью, когда наблюдал как родственник пытается настроить себе Codex VPN. Принципиально ничего не подсказывал, т. к. потратил достаточно времени, чтобы написать инструкции и даже запилить видео (с этим мне помог один хороший человек).
Заметил два момента:
1️⃣ При настройке VPN есть три шага: получение ключа доступа, выбор платформы (iOS, Android, Windows) и скачивание приложения.
После скачивания приложения нужно скопировать ключ , а для этого — подняться на два экрана наверх, что довольно неудобно. Вроде мелочь, но для обывателя это не всегда очевидно.
2️⃣ Ключ должен копироваться одним нажатием — так оно и работает на компьютере и айфоне, но андроид тут решил выделиться и при клике он открывает меню сообщения. Наконец стала понятна причина одного из самых частых обращений, когда пользователи вставляют в приложение не ключ, а сообщение целиком.
По итогу в бэклоге добавилось несколько задач по улучшению UX.
P. S.: ответы на вопросы в поддержке — это отдельный тренажер для нервов.
Сегодня ненароком ощутил мощь проблемных интервью, когда наблюдал как родственник пытается настроить себе Codex VPN. Принципиально ничего не подсказывал, т. к. потратил достаточно времени, чтобы написать инструкции и даже запилить видео (с этим мне помог один хороший человек).
Заметил два момента:
После скачивания приложения нужно скопировать ключ , а для этого — подняться на два экрана наверх, что довольно неудобно. Вроде мелочь, но для обывателя это не всегда очевидно.
По итогу в бэклоге добавилось несколько задач по улучшению UX.
P. S.: ответы на вопросы в поддержке — это отдельный тренажер для нервов.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍13🔥6😁1