Forwarded from Блог Махача
Отцу не объяснишь, что ты сеньор
Это два самых дорогих грузчика, которых я видел
Это два самых дорогих грузчика, которых я видел
😁27🤣8👍5
📈 Про перформанс-ревью
Совсем недавно в Яндексе завершился период ревью — оценки работы сотрудников за последние полгода.
Если коротко — вы описываете результаты своей работы, пишете отзывы на коллег, после чего руководители путем хитрых манипуляций выставляют вам оценку. По итогам одни получают премии, другие повышения, а кто-то открывает сайт с вакансиями 🫠.
Эта практика есть во многих крупных компаниях. Чуть больше можно узнать в докладах от😊 Яндекса и 😊 Авито.
При написании селф-ревью (отчета о своей работе) важно делать это через призму пользы для бизнеса. Результат вашей работы позволил бизнесу либо заработать больше, либо потратить меньше. К примеру, не просто «оптимизировал поиск», а «оптимизировал поиск, что уменьшило количество отказов на 10%».
Бизнес-ценность зачастую можно извлечь из описания задачи (для чего-то ведь ее ставили), а метрики «до/после» пообщавшись с аналитиками. Кстати, это вырабатывает привычку думать о ценности задачи еще на этапе грумминга. При правильном подходе даже для чисто технических задач можно найти ее. Пример: «оптимизировал линтинг» → «ускорил CI» → «уменьшил время доставки фич».
В процессе первого для меня ревью я прошерстил задачи и коммиты за последние полгода, чтобы вспомнить все детали. Зачастую в этих деталях и кроется вся соль задачи, о которой важно написать.
В результате я начал фиксировать детали выполняемых мною задач в отдельной заметке: в чем заключалась задача, какие были сложности, с кем приходилось взаимодействовать. При таком подходе для написания селф-ревью останется только немного подредактировать собранную инфу. Плюс это помогает сразу определиться у кого стоит запросить фидбек.
Параллельно с этим я делаю пометки о работе своих коллег — это позволяет написать более развернутый фидбек, если они его запросят. Если вспомнить свои задачи за полгода бывает непросто, что говорить о работе коллег.
К примеру, я заметил, что один из наших тестировщиков очень скрупулезно подходит к тестированию и пишет очень подробные, хорошо оформленные отчеты. Вряд ли я бы вспомнил эти детали в конце полугодия, учитывая, что с ним мы взаимодействовали только в самом его начале.
Проводить селф-ревью полезно даже если в вашей компании нет такого процесса:
🟠 Можно оценить свой прогресс
🟠 Обосновать повышение ЗП для руководства
🟠 Использовать при описании опыта в резюме и на собесах
В комментариях можем обсудить как в вашей компании происходит оценка работы сотрудников.
Совсем недавно в Яндексе завершился период ревью — оценки работы сотрудников за последние полгода.
Если коротко — вы описываете результаты своей работы, пишете отзывы на коллег, после чего руководители путем хитрых манипуляций выставляют вам оценку. По итогам одни получают премии, другие повышения, а кто-то открывает сайт с вакансиями 🫠.
Эта практика есть во многих крупных компаниях. Чуть больше можно узнать в докладах от
При написании селф-ревью (отчета о своей работе) важно делать это через призму пользы для бизнеса. Результат вашей работы позволил бизнесу либо заработать больше, либо потратить меньше. К примеру, не просто «оптимизировал поиск», а «оптимизировал поиск, что уменьшило количество отказов на 10%».
Бизнес-ценность зачастую можно извлечь из описания задачи (для чего-то ведь ее ставили), а метрики «до/после» пообщавшись с аналитиками. Кстати, это вырабатывает привычку думать о ценности задачи еще на этапе грумминга. При правильном подходе даже для чисто технических задач можно найти ее. Пример: «оптимизировал линтинг» → «ускорил CI» → «уменьшил время доставки фич».
В процессе первого для меня ревью я прошерстил задачи и коммиты за последние полгода, чтобы вспомнить все детали. Зачастую в этих деталях и кроется вся соль задачи, о которой важно написать.
В результате я начал фиксировать детали выполняемых мною задач в отдельной заметке: в чем заключалась задача, какие были сложности, с кем приходилось взаимодействовать. При таком подходе для написания селф-ревью останется только немного подредактировать собранную инфу. Плюс это помогает сразу определиться у кого стоит запросить фидбек.
Параллельно с этим я делаю пометки о работе своих коллег — это позволяет написать более развернутый фидбек, если они его запросят. Если вспомнить свои задачи за полгода бывает непросто, что говорить о работе коллег.
К примеру, я заметил, что один из наших тестировщиков очень скрупулезно подходит к тестированию и пишет очень подробные, хорошо оформленные отчеты. Вряд ли я бы вспомнил эти детали в конце полугодия, учитывая, что с ним мы взаимодействовали только в самом его начале.
Проводить селф-ревью полезно даже если в вашей компании нет такого процесса:
В комментариях можем обсудить как в вашей компании происходит оценка работы сотрудников.
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
Нужно ли быть нормальным? – Андрей Стыскин, Яндекс
Слайды: https://yadi.sk/i/N3X5E3YcPaLnsA
О спикере:
Андрей Стыскин с 2019 года возглавляет поисковый портал. До этого руководил управлением поисковых продуктов, отделом ранжирования, занимался качеством международного поиска и создавал поиск для Турции.…
О спикере:
Андрей Стыскин с 2019 года возглавляет поисковый портал. До этого руководил управлением поисковых продуктов, отделом ранжирования, занимался качеством международного поиска и создавал поиск для Турции.…
👍33🔥9❤6
🧠 Когнитивные искажения
В последнее время довольно много читал про различные когнитивные искажения (ошибки восприятия и интерпретации информации). Советую ознакомиться со списком таких искажений в Википедии — это очень интересно.
В какой-то момент мне захотелось собрать список искажений, свойственных для разработки (если брать шире — для любого бизнеса), но оказалось, что он уже есть — проект UXCore на сайте KeepSimple.
Для каждого искажения приводится описание и примеры влияния на продукт или HR-менеджмент (наём, бренд компании, управление кадрами). Для некоторых ситуаций приводятся решения. По мне просто находка для менеджеров, HR-ов, да и просто бизнесменов.
Несколько примеров таких искажений:
🛑 Синдром неприятия чужой разработки или NIH (not-invented-here) — когда вместо использования готового инструмента или библиотеки, пилится свой велосипед.
🛑 Ловушка невозвратных затрат или эффект Конкорда — ситуация, когда большое количество потраченных ресурсов мешают вовремя бросить бесперспективное дело. Решение этой ситуации выражено в поговорке: «Лошадь сдохла — слезь».
🛑 Ошибка планирования — когда вторую неделю работаешь над задачей, на которую закладывалось три дня, а света в конце тоннеля все еще не видно.
Параллельно стоит заглядывать в Википедию, т. к. там тоже можно подчерпнуть что-то полезное. К примеру, на UXCore не приводится решение ошибки планирования, а вот в Википедии — да.
В последнее время довольно много читал про различные когнитивные искажения (ошибки восприятия и интерпретации информации). Советую ознакомиться со списком таких искажений в Википедии — это очень интересно.
В какой-то момент мне захотелось собрать список искажений, свойственных для разработки (если брать шире — для любого бизнеса), но оказалось, что он уже есть — проект UXCore на сайте KeepSimple.
Для каждого искажения приводится описание и примеры влияния на продукт или HR-менеджмент (наём, бренд компании, управление кадрами). Для некоторых ситуаций приводятся решения. По мне просто находка для менеджеров, HR-ов, да и просто бизнесменов.
Несколько примеров таких искажений:
Параллельно стоит заглядывать в Википедию, т. к. там тоже можно подчерпнуть что-то полезное. К примеру, на UXCore не приводится решение ошибки планирования, а вот в Википедии — да.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍26🔥12❤5
На этих выходных вместе с Махачом 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