Привет! Я Алина — QA Lead команды платформы.
Платформа — это не продуктовая команда. Мы занимаемся общими компонентами: видеосвязь, авторизация, чаты, пуши, которые используются в разных продуктах компании, а также инструментами и процессами. Своего рода PaaS — Platform as a Service.
Недавно руководители тестирования прошли серию воркшопов по переговорам для прокачки скиллов, проработки трудных кейсов и помощи себе в ежедневных встречах, на которые у лидов уходит добрая часть времени. Поделюсь несколькими ценными выводами. Скипаем small talk и сразу к делу 🔥
Платформа — это не продуктовая команда. Мы занимаемся общими компонентами: видеосвязь, авторизация, чаты, пуши, которые используются в разных продуктах компании, а также инструментами и процессами. Своего рода PaaS — Platform as a Service.
Недавно руководители тестирования прошли серию воркшопов по переговорам для прокачки скиллов, проработки трудных кейсов и помощи себе в ежедневных встречах, на которые у лидов уходит добрая часть времени. Поделюсь несколькими ценными выводами. Скипаем small talk и сразу к делу 🔥
👍2
На воркшопах мы моделировали кейсы из рабочих будней.
🍀 Встречи, которые начинаются с «Как поживаешь?» иногда интуитивно вызывают чувство неловкости у собеседника. Причины разные: степень знакомства, уместность, желание задавать и отвечать на этот абстрактный вопрос. Нормально сказать: «Привет, спасибо, что пришел/ла. План на встречу у нас такой-то» — и погнали!
На первом этапе озвучиваем повестку и цель, сверяемся с ожиданиями собеседника и не забываем выяснить, что ему важно обсудить.
🍀 По правилам хорошего тона на встречи приходят подготовленными. Но есть нюанс: не стоит настраиваться на конкретные эмоции или пытаться заранее планировать реакцию – свою или собеседника.
Переговоры не стали бы трудными, если бы в начале встречи я не сказала: «Привет, разговор будет непростым». Коллеги давали обратную связь, что после такого старта они были готовы к увольнению здесь и сейчас. Я же таким ошибочным образом пыталась настроить человека на фидбек-сессию по результатам, которые нужно подтянуть 🙂
При переигровке ситуации обсуждение шло естественнее, и я работала с теми эмоциями, которые встретила от собеседника, а не которые прогнозировала.
🍀 Многим мешал заранее подготовленный диалог. Он отвлекал от хода переговоров и не давал в моменте отвечать на вопросы собеседника.
🍀 Методом проб и ошибок мы пришли к тому, что важно задавать вопросы. Нужно быть в контакте с собеседником. Задача — выяснить, почему человек думает именно так: «Что ты имеешь в виду?», «Правильно ли я услышал/а, что…?». Особенно, если точки зрения различаются.
🍀 Говорить о чувствах, а не игнорировать их. Недавно на встрече я поделилась с коллегами, что «испытываю сопротивление делать такую-то задачу» и получила поддержку и понимание вместо спора и осуждения.
🍀 Last but not least — заходить на переговоры в позиции партнера, а не воина. Только отстоять свою точку зрения не является целью. В наших интересах — понять «картину» собеседника, его мотивацию и боли, чтобы с ними работать и находить оптимальные для обеих сторон решения. А список action items обязательно унесите с собой, как артефакт встречи. Кстати, именно с них можно будет начать следующую.
Расскажите о своих инсайтах при ведении переговоров. С какими трудностями сталкиваетесь и как учитесь решать?
🍀 Встречи, которые начинаются с «Как поживаешь?» иногда интуитивно вызывают чувство неловкости у собеседника. Причины разные: степень знакомства, уместность, желание задавать и отвечать на этот абстрактный вопрос. Нормально сказать: «Привет, спасибо, что пришел/ла. План на встречу у нас такой-то» — и погнали!
На первом этапе озвучиваем повестку и цель, сверяемся с ожиданиями собеседника и не забываем выяснить, что ему важно обсудить.
🍀 По правилам хорошего тона на встречи приходят подготовленными. Но есть нюанс: не стоит настраиваться на конкретные эмоции или пытаться заранее планировать реакцию – свою или собеседника.
Переговоры не стали бы трудными, если бы в начале встречи я не сказала: «Привет, разговор будет непростым». Коллеги давали обратную связь, что после такого старта они были готовы к увольнению здесь и сейчас. Я же таким ошибочным образом пыталась настроить человека на фидбек-сессию по результатам, которые нужно подтянуть 🙂
При переигровке ситуации обсуждение шло естественнее, и я работала с теми эмоциями, которые встретила от собеседника, а не которые прогнозировала.
🍀 Многим мешал заранее подготовленный диалог. Он отвлекал от хода переговоров и не давал в моменте отвечать на вопросы собеседника.
🍀 Методом проб и ошибок мы пришли к тому, что важно задавать вопросы. Нужно быть в контакте с собеседником. Задача — выяснить, почему человек думает именно так: «Что ты имеешь в виду?», «Правильно ли я услышал/а, что…?». Особенно, если точки зрения различаются.
🍀 Говорить о чувствах, а не игнорировать их. Недавно на встрече я поделилась с коллегами, что «испытываю сопротивление делать такую-то задачу» и получила поддержку и понимание вместо спора и осуждения.
🍀 Last but not least — заходить на переговоры в позиции партнера, а не воина. Только отстоять свою точку зрения не является целью. В наших интересах — понять «картину» собеседника, его мотивацию и боли, чтобы с ними работать и находить оптимальные для обеих сторон решения. А список action items обязательно унесите с собой, как артефакт встречи. Кстати, именно с них можно будет начать следующую.
Расскажите о своих инсайтах при ведении переговоров. С какими трудностями сталкиваетесь и как учитесь решать?
🔥17👍13👎1
Всем привет! 👋
Меня зовут Дмитрий Шкилёв, я тимлид команды Teachers Platform. Мы занимаемся личным кабинетом преподавателя и внутренними ресурсами, которые необходимы для обеспечения работы преподавателей.
Однажды мне надоело заполнять вручную отчет в экселе по результатам производительности команды. И я задумался, можно ли это автоматизировать?
Мы работаем с Jira. Теоретически, можно сделать отдельный Jira-report, но у нас практически нет Java-разработчиков, да и это займет время. Но зато есть Grafana и доступ к реплике БД Jira.
Поэтому выбор пал на связку Grafana + Jira. Нужно было лишь разобраться во внутреннем устройстве БД Jira. Какие-то лайфхаки нашли на просторах сети, где-то использовали отдельные плагины, а где-то — реверс-инжиниринг.
Хочу поделиться результатами и в паре постов на примерах показать, как с помощью Jira и Grafana облегчить жизнь тимлида.
Меня зовут Дмитрий Шкилёв, я тимлид команды Teachers Platform. Мы занимаемся личным кабинетом преподавателя и внутренними ресурсами, которые необходимы для обеспечения работы преподавателей.
Однажды мне надоело заполнять вручную отчет в экселе по результатам производительности команды. И я задумался, можно ли это автоматизировать?
Мы работаем с Jira. Теоретически, можно сделать отдельный Jira-report, но у нас практически нет Java-разработчиков, да и это займет время. Но зато есть Grafana и доступ к реплике БД Jira.
Поэтому выбор пал на связку Grafana + Jira. Нужно было лишь разобраться во внутреннем устройстве БД Jira. Какие-то лайфхаки нашли на просторах сети, где-то использовали отдельные плагины, а где-то — реверс-инжиниринг.
Хочу поделиться результатами и в паре постов на примерах показать, как с помощью Jira и Grafana облегчить жизнь тимлида.
👍21
Первый кейс, про который расскажу — грейдирование 🤘
Раз в полгода у нас проходит грейдирование разработчиков. Ребята оценивают сами себя, друг друга и получают оценку от руководителей. Необходимо ответить на вопросы о производительности разработчика и количестве задач, которые вернули после тестирования.
Чтобы определить грейд, необходимо знать точные цифры по каждому разработчику:
1️⃣ % задач, которые были возвращены QA после тестирования на доработку.
2️⃣ % задач, в которых разработчик уложился в оценку.
3️⃣ % задач, которые были сделаны быстрее, чем их оценивали.
Естественно, эти цифры не зависят от респондента, но долгое время каждый отвечал «по личным ощущениям», и они не всегда совпадали с правдой. Так как же считать эти показатели?
▫️С % задач, которые были возвращены QA после тестирования, мне повезло. У нас уже было кастомное поле WasInTesting, которое увеличивалось на 1 каждый раз, когда задача из разработки отправлялась в тестирование. Осталось только посчитать % задач, у которых этот показатель был >1.
▫️Что касается сравнения фактических результатов и планируемых, то количество залогированных часов в Jira есть (поле jiraissue.timespent). Плановые часы мы также сохраняем в отдельном кастомное поле Initial estimate (Original estimate не можем использовать для этого, так как мы его меняем каждый раз перед началом спринта). Остается сравнить количество потраченных часов на задачу и плановых.
У нас есть задачи на исследования, которые мы заранее не оцениваем. Для формирования корректной выборки необходимо исключить их. Это легко можно сделать, если помечать их отдельным лейблом (мы выбрали лейбл research).
▫️Как известно, аппетит приходит во время еды. Поэтому кроме необходимых показателей для ответов на вопросы грейдирования я вывел и ряд других, которые позволяют понять, как человек поработал в этом квартале, увидеть конкретные задачи, на которые ушло много времени. Кроме того, дашборд доступен для всей команды. Каждый видит свои результаты и результаты коллег. Всё прозрачно и непредвзято. Это повышает доверие команды к результатам грейдирования и компании в целом, а также мотивирует ребят на улучшение своих показателей.
Раз в полгода у нас проходит грейдирование разработчиков. Ребята оценивают сами себя, друг друга и получают оценку от руководителей. Необходимо ответить на вопросы о производительности разработчика и количестве задач, которые вернули после тестирования.
Чтобы определить грейд, необходимо знать точные цифры по каждому разработчику:
1️⃣ % задач, которые были возвращены QA после тестирования на доработку.
2️⃣ % задач, в которых разработчик уложился в оценку.
3️⃣ % задач, которые были сделаны быстрее, чем их оценивали.
Естественно, эти цифры не зависят от респондента, но долгое время каждый отвечал «по личным ощущениям», и они не всегда совпадали с правдой. Так как же считать эти показатели?
▫️С % задач, которые были возвращены QA после тестирования, мне повезло. У нас уже было кастомное поле WasInTesting, которое увеличивалось на 1 каждый раз, когда задача из разработки отправлялась в тестирование. Осталось только посчитать % задач, у которых этот показатель был >1.
▫️Что касается сравнения фактических результатов и планируемых, то количество залогированных часов в Jira есть (поле jiraissue.timespent). Плановые часы мы также сохраняем в отдельном кастомное поле Initial estimate (Original estimate не можем использовать для этого, так как мы его меняем каждый раз перед началом спринта). Остается сравнить количество потраченных часов на задачу и плановых.
У нас есть задачи на исследования, которые мы заранее не оцениваем. Для формирования корректной выборки необходимо исключить их. Это легко можно сделать, если помечать их отдельным лейблом (мы выбрали лейбл research).
▫️Как известно, аппетит приходит во время еды. Поэтому кроме необходимых показателей для ответов на вопросы грейдирования я вывел и ряд других, которые позволяют понять, как человек поработал в этом квартале, увидеть конкретные задачи, на которые ушло много времени. Кроме того, дашборд доступен для всей команды. Каждый видит свои результаты и результаты коллег. Всё прозрачно и непредвзято. Это повышает доверие команды к результатам грейдирования и компании в целом, а также мотивирует ребят на улучшение своих показателей.
👎47👍10🔥5
Привет! Разберем ещё один кейс, с которым помогает связка инструментов Jira + Grafana.
Если:
▫️К вам когда-нибудь приходили с вопросом «А сколько времени ушло на разработку этого сервиса?»
▫️Вам интересно узнать, сколько потрачено времени на разработку своих и не только своих сервисов.
▫️Вы хотите понять, насколько уложились в оценки по разработке новых сервисов.
…то вам будет полезен отдельный дашборд в Grafana c количеством потраченного времени по сервисам.
Если:
▫️К вам когда-нибудь приходили с вопросом «А сколько времени ушло на разработку этого сервиса?»
▫️Вам интересно узнать, сколько потрачено времени на разработку своих и не только своих сервисов.
▫️Вы хотите понять, насколько уложились в оценки по разработке новых сервисов.
…то вам будет полезен отдельный дашборд в Grafana c количеством потраченного времени по сервисам.
👍7
Тимлид Леонид
Привет! Разберем ещё один кейс, с которым помогает связка инструментов Jira + Grafana. Если: ▫️К вам когда-нибудь приходили с вопросом «А сколько времени ушло на разработку этого сервиса?» ▫️Вам интересно узнать, сколько потрачено времени на разработку…
Я смотрю на три показателя, которые используем в команде:
1) Initial Estimate — изначальная оценка. Ставится один раз после проведения техревью и не меняется. Если по задаче произошёл scope change, то лучше завести отдельную задачу.
2) Original Estimate — у нас это оценка задачи на момент перед стартом спринта (мы перед каждым спринтом проставляем Original Estimate и Remaining Estimate равными цифрами).
3) Logged Time — количество часов, которое залогировали по задаче.
Разница между Initial Estimate и Logged Time показывает, насколько мы ошибаемся в оценке. Original Estimate позволяет контролировать объем задач в спринте.
💡Как это всё работает
Спасибо команде инфры: после деплоя каждой задачи у неё проставляется лейбл deployed-<название сервиса>. По этим лейблам я определяю сервис, в рамках которого шла работа по задаче. Ну а дальше остаётся только просуммировать задачи с группировкой по сервису, в которые были зарезолвлены в обозначенное время.
💡На что обратить внимание
Необходимо следить за лейблами. Обращал внимание на случаи, когда новые задачи заводились путём клонирования и лейблы клонировались от исходной задачи. В итоге у задачи было несколько деплойных лейблов, что приводило к задвоению/затроению оценок.
Анализируя полученные цифры, можно найти для себя ряд сюрпризов. Я, например, обнаружил, что в рамках квартала у нас ушло значительно больше времени на доработку сервиса соседней команды, чем мы рассчитывали.
Если приходится регулярно фиксить баги в каком-то сервисе, то с помощью такого отчёта легко показать бизнесу, сколько времени уходит на поддержку работоспособности сервиса, а это даёт рычаг для обоснования необходимости устранения технического долга.
По количеству сервисов, на которые тратится основной объём времени, тоже можно сделать выводы. Если у вас больше 3 сервисов, на каждый из которых уходит более 5% времени, то это говорит о расфокусировке команды. В этом случае стоит проговорить зоны ответственности и понять, действительно ли вам стоит отвечать за все эти сервисы или есть более подходящая команда. Возможно, пришла пора разделять команду на части.
1) Initial Estimate — изначальная оценка. Ставится один раз после проведения техревью и не меняется. Если по задаче произошёл scope change, то лучше завести отдельную задачу.
2) Original Estimate — у нас это оценка задачи на момент перед стартом спринта (мы перед каждым спринтом проставляем Original Estimate и Remaining Estimate равными цифрами).
3) Logged Time — количество часов, которое залогировали по задаче.
Разница между Initial Estimate и Logged Time показывает, насколько мы ошибаемся в оценке. Original Estimate позволяет контролировать объем задач в спринте.
💡Как это всё работает
Спасибо команде инфры: после деплоя каждой задачи у неё проставляется лейбл deployed-<название сервиса>. По этим лейблам я определяю сервис, в рамках которого шла работа по задаче. Ну а дальше остаётся только просуммировать задачи с группировкой по сервису, в которые были зарезолвлены в обозначенное время.
💡На что обратить внимание
Необходимо следить за лейблами. Обращал внимание на случаи, когда новые задачи заводились путём клонирования и лейблы клонировались от исходной задачи. В итоге у задачи было несколько деплойных лейблов, что приводило к задвоению/затроению оценок.
Анализируя полученные цифры, можно найти для себя ряд сюрпризов. Я, например, обнаружил, что в рамках квартала у нас ушло значительно больше времени на доработку сервиса соседней команды, чем мы рассчитывали.
Если приходится регулярно фиксить баги в каком-то сервисе, то с помощью такого отчёта легко показать бизнесу, сколько времени уходит на поддержку работоспособности сервиса, а это даёт рычаг для обоснования необходимости устранения технического долга.
По количеству сервисов, на которые тратится основной объём времени, тоже можно сделать выводы. Если у вас больше 3 сервисов, на каждый из которых уходит более 5% времени, то это говорит о расфокусировке команды. В этом случае стоит проговорить зоны ответственности и понять, действительно ли вам стоит отвечать за все эти сервисы или есть более подходящая команда. Возможно, пришла пора разделять команду на части.
👍8👎8🔥4🤯2
Всем привет! Готовимся к долгим выходным — уже вышли на фичафриз, закрываем последние таски.
На старте 2023 поделимся историями нескольких технический кейсов разных команд Skyeng Tech. А сегодня ретроспективно будут пара статей.
▫️ Язык диаграмм. Разобрались, жив ли UML, как учить, каким командам полезен. И примеры.
▫️ Путь в QAA. Попросили Head of QAA, Ивана Шевелёва, рассказать, чему и как учиться, если хочешь расти в автоматизаторы. Заодно Ваня разбил несколько мифов про обучение.
🎉 И раз идет финальная неделя года — заготовили сертификаты на знания. Взрослым — английский для любых целей и интересов, детям — школьные предметы, хобби и кодинг.
Увидимся в 2023! 🎄🥳
На старте 2023 поделимся историями нескольких технический кейсов разных команд Skyeng Tech. А сегодня ретроспективно будут пара статей.
▫️ Язык диаграмм. Разобрались, жив ли UML, как учить, каким командам полезен. И примеры.
▫️ Путь в QAA. Попросили Head of QAA, Ивана Шевелёва, рассказать, чему и как учиться, если хочешь расти в автоматизаторы. Заодно Ваня разбил несколько мифов про обучение.
🎉 И раз идет финальная неделя года — заготовили сертификаты на знания. Взрослым — английский для любых целей и интересов, детям — школьные предметы, хобби и кодинг.
Увидимся в 2023! 🎄🥳
🔥9👍3
Media is too big
VIEW IN TELEGRAM
ребят, привет! это Лёша Катаев
я ушёл из Skyeng делать стартапы, и сегодня запускаю свой продукт на Product Hunt
это Eightify — мгновенные summary для Youtube, GPT-powered
1️⃣ если у тебя есть аккаунт на Product Hunt — поддержи меня там, пожалуйста
2️⃣ если у тебя есть Twitter, репостни мой пост, пожалуйста
спасибо ❤️❤️❤️
P.S. теперь буду писать в твиттер → подписывайтесь
я ушёл из Skyeng делать стартапы, и сегодня запускаю свой продукт на Product Hunt
это Eightify — мгновенные summary для Youtube, GPT-powered
1️⃣ если у тебя есть аккаунт на Product Hunt — поддержи меня там, пожалуйста
2️⃣ если у тебя есть Twitter, репостни мой пост, пожалуйста
спасибо ❤️❤️❤️
P.S. теперь буду писать в твиттер → подписывайтесь
🔥55👎11👍5😁2
Привет! 👋
Прошлой осенью мы затеяли генеральную уборку. Багатон стал целой эпопеей — на неделю поставили на паузу продуктовые задачи и пошли расчищать багбэклоги (чего мы там только не нашли).
Не все прошло гладко, но история многому нас научила. И, конечно, это был только один из шагов для повышения качества. Но обо всем по порядку.
В общем, про Багатон недавно в деталях поделились на Хабре 🙂
Прошлой осенью мы затеяли генеральную уборку. Багатон стал целой эпопеей — на неделю поставили на паузу продуктовые задачи и пошли расчищать багбэклоги (чего мы там только не нашли).
Не все прошло гладко, но история многому нас научила. И, конечно, это был только один из шагов для повышения качества. Но обо всем по порядку.
В общем, про Багатон недавно в деталях поделились на Хабре 🙂
🔥20👍3❤1👎1
Привет! Грядет февральская TeamLead Conf и коллеги из Яндекса готовят трек — R&D и культура компании 💪
Программа занятная. 7 докладов о том, как в IT-компаниях с разной корпоративной культурой устроены R&D-департаменты, где рождаются, тестируются и запускаются инновационные решения.
Конечно, «инженерную культуру» в сообществе трактуют по-разному. Фокус будет на том, когда разработке для решения продуктовой задачи нужны технологии, которых нет на рынке, или они не доступны.
Послушаем и обсудим:
- Роль бизнеса и инженеров в компаниях с разной корпкультурой.
- Как построены процессы генерации и приоритезации идей и инноваций.
- Как строится взаимодействие между продуктом, разработкой и созданием новых технологий.
И не только. Подробнее о спикерах и тезисах — в программе.
Увидимся на TeamLead Conf! 🔥
Программа занятная. 7 докладов о том, как в IT-компаниях с разной корпоративной культурой устроены R&D-департаменты, где рождаются, тестируются и запускаются инновационные решения.
Конечно, «инженерную культуру» в сообществе трактуют по-разному. Фокус будет на том, когда разработке для решения продуктовой задачи нужны технологии, которых нет на рынке, или они не доступны.
Послушаем и обсудим:
- Роль бизнеса и инженеров в компаниях с разной корпкультурой.
- Как построены процессы генерации и приоритезации идей и инноваций.
- Как строится взаимодействие между продуктом, разработкой и созданием новых технологий.
И не только. Подробнее о спикерах и тезисах — в программе.
Увидимся на TeamLead Conf! 🔥
👍7🔥3
Symfony, Laravel или Yii для рабочих проектов? А для личных? И много ли PHP-разработчиков смотрят в сторону Go?
Привет! 👋
Третий год мы с ребятами, которые развивают русскоязычное PHP-сообщество и создают движ для обмена опытом, проводим опрос. Смотрим, как меняется ситуация с фреймворками и версиями PHP в командах, какие статьи и доклады были топ по полезности, какие языки выбирают в качестве дополнительных для изучения и работы. И не только.
🐘 Подвели итоги третьего опроса (за 2022) и собрали результаты в статье и на сайте.
📗 А на phpcommunity.ru можно найти итоги за 2021 и 2020.
#skyeng_habr
Привет! 👋
Третий год мы с ребятами, которые развивают русскоязычное PHP-сообщество и создают движ для обмена опытом, проводим опрос. Смотрим, как меняется ситуация с фреймворками и версиями PHP в командах, какие статьи и доклады были топ по полезности, какие языки выбирают в качестве дополнительных для изучения и работы. И не только.
🐘 Подвели итоги третьего опроса (за 2022) и собрали результаты в статье и на сайте.
📗 А на phpcommunity.ru можно найти итоги за 2021 и 2020.
#skyeng_habr
🔥12👍2😁1😱1
Всем привет! 👋
Меня зовут Олег Мифле. В Skyeng работаю над проектом Skypro. В IT я уже больше 10 лет, 7 из которых пишу на PHP. За плечами десятки разных проектов.
Были и классические фуллстек-проекты, и проекты, где фронтенд и бэкенд «живут» отдельно и коммуницируют друг с другом по API. Боль от отсутствия версионирования я испытал на себе.
📖 Поделился в статье на Хабре:
▫️ Зачем версионировать API и нужно ли вообще.
▫️ Какие есть подходы, в чем плюсы и минусы.
▫️ Как избежать типичных проблем версионирования.
Все с примерами и скринами. Приятного чтения! ✌️
#skyeng_habr
Меня зовут Олег Мифле. В Skyeng работаю над проектом Skypro. В IT я уже больше 10 лет, 7 из которых пишу на PHP. За плечами десятки разных проектов.
Были и классические фуллстек-проекты, и проекты, где фронтенд и бэкенд «живут» отдельно и коммуницируют друг с другом по API. Боль от отсутствия версионирования я испытал на себе.
📖 Поделился в статье на Хабре:
▫️ Зачем версионировать API и нужно ли вообще.
▫️ Какие есть подходы, в чем плюсы и минусы.
▫️ Как избежать типичных проблем версионирования.
Все с примерами и скринами. Приятного чтения! ✌️
#skyeng_habr
🔥18👍2👎2
Всем привет!
Почти синхронно QA-сообщество пополнилось двумя телеграм-каналами про развитие от наших ребят 🔥 Хотим поделиться — возможно вам или коллегам ресурсы окажутся полезны.
🪲 Test it easy | Всё о тестировании — канал Игоря Егоренкова @toronto15, Senior QA Engineer команды Billing. Есть материалы и для тех, кто только начинает путь в тестирование, и для тех, кто прошел огонь, воду и сотни багов. Статьи, тренды, лайфхаки и личные мысли.
🪲 QAA Spells — Mastering the Art of Automation — канал ex-QAA Tech Lead Skyeng Вани Шевелева @NeONRAcE. Статьи про автоматизацию тестирования и менеджмент, голосования и философские вопросы по специальности, паттерны хорошей архитектуры и кода и не только.
Оба канала с возможностью обсуждения постов 🙌
Почти синхронно QA-сообщество пополнилось двумя телеграм-каналами про развитие от наших ребят 🔥 Хотим поделиться — возможно вам или коллегам ресурсы окажутся полезны.
🪲 Test it easy | Всё о тестировании — канал Игоря Егоренкова @toronto15, Senior QA Engineer команды Billing. Есть материалы и для тех, кто только начинает путь в тестирование, и для тех, кто прошел огонь, воду и сотни багов. Статьи, тренды, лайфхаки и личные мысли.
🪲 QAA Spells — Mastering the Art of Automation — канал ex-QAA Tech Lead Skyeng Вани Шевелева @NeONRAcE. Статьи про автоматизацию тестирования и менеджмент, голосования и философские вопросы по специальности, паттерны хорошей архитектуры и кода и не только.
Оба канала с возможностью обсуждения постов 🙌
🔥10👍6👏2❤1
Привет! 👋 Тема работы с удаленными-распределенными командами не нова. Но как меняются процессы в разных компаниях? Решили собраться и обсудить с коллегами из SuperJob, JetStyle и РАЭК.
📬 Завтра (16 марта) в 18:00 по Москве — встречаемся в онлайне.
О чем поговорим:
▫️Ольга Лугинина, HRD в SuperJob: «Релокация сотрудников из российского офиса: что нужно учесть руководителям»
▫️Анастасия Юрчихина, Head of Employee Relations в Skyeng: «6 часовых поясов и никаких встреч в офисе. Как работать с вовлеченностью распределенной команды?»
▫️Алексей Кулаков, CEO JetStyle: «Гибридные команды. Почему в гибридных командах несущими являются онлайн-процессы»
Регистрация. До встречи! 🙌
📬 Завтра (16 марта) в 18:00 по Москве — встречаемся в онлайне.
О чем поговорим:
▫️Ольга Лугинина, HRD в SuperJob: «Релокация сотрудников из российского офиса: что нужно учесть руководителям»
▫️Анастасия Юрчихина, Head of Employee Relations в Skyeng: «6 часовых поясов и никаких встреч в офисе. Как работать с вовлеченностью распределенной команды?»
▫️Алексей Кулаков, CEO JetStyle: «Гибридные команды. Почему в гибридных командах несущими являются онлайн-процессы»
Регистрация. До встречи! 🙌
🔥9
Привет! Я Саша Володин, backend-разработчик команды ECO Growth в Skyeng.
С выходом PHP 8 захотелось скорее использовать новые фичи релиза, поэтому я взял рабочий проект и... поправил весь код руками. Сначала это было интересно, затем монотонно, а к середине рефакторинга превратилось в наказание.
Ох, PHP 8, ты классный, но второй такой рефакторинг я не потяну 🥵 И тогда я задался вопросом: есть ли инструмент, который автоматически переводил бы код на новую версию синтаксиса? Так я познакомился с Rector.
📗 В статье собрал опыт работы с инструментом — как он помогает обуздать легаси и автоматизировать обновление проектов и пакетов, чтобы процесс проходил эффективнее и малой кровью.
Статья по мотивам доклада с PHP Russia 2022 — вот запись.
#skyeng_habr
С выходом PHP 8 захотелось скорее использовать новые фичи релиза, поэтому я взял рабочий проект и... поправил весь код руками. Сначала это было интересно, затем монотонно, а к середине рефакторинга превратилось в наказание.
Ох, PHP 8, ты классный, но второй такой рефакторинг я не потяну 🥵 И тогда я задался вопросом: есть ли инструмент, который автоматически переводил бы код на новую версию синтаксиса? Так я познакомился с Rector.
📗 В статье собрал опыт работы с инструментом — как он помогает обуздать легаси и автоматизировать обновление проектов и пакетов, чтобы процесс проходил эффективнее и малой кровью.
Статья по мотивам доклада с PHP Russia 2022 — вот запись.
#skyeng_habr
🔥15❤5👍5
Привет! 👋
В прошлый четверг мы участвовали в митапе про работу распределенных команд. Делимся записью. Говорили про релокейты, про инструменты, вовлеченность команд и не только.
🖍 По следам митапа запустили минутный опрос.
Если у вас есть совет, наблюдение, классная традиция или работающая практика, которые помогают продуктивно жить вам / вашей команде в условиях удаленности-распределенности — кидайте в форму.
🍀 Все прочитаем, выберем на днях один из советов и отправим автору топ-рюкзак Skyeng Tech.
В прошлый четверг мы участвовали в митапе про работу распределенных команд. Делимся записью. Говорили про релокейты, про инструменты, вовлеченность команд и не только.
🖍 По следам митапа запустили минутный опрос.
Если у вас есть совет, наблюдение, классная традиция или работающая практика, которые помогают продуктивно жить вам / вашей команде в условиях удаленности-распределенности — кидайте в форму.
🍀 Все прочитаем, выберем на днях один из советов и отправим автору топ-рюкзак Skyeng Tech.
Youtube
- YouTube
Enjoy the videos and music you love, upload original content, and share it all with friends, family, and the world on YouTube.
👍7
Привет! 👋
Коллеги из DevCrowd опубликовали результаты рисерча — 570 мнений руководителей разработки.
Есть и про особенности профессии, про сообщество, релокацию и удаленку, про жизнь в разных компаниях. А также полезные ресурсы для развития.
В общем, данные крутые — мы зачитались, поэтому делимся с вами, если еще не видели 🔥
Коллеги из DevCrowd опубликовали результаты рисерча — 570 мнений руководителей разработки.
Есть и про особенности профессии, про сообщество, релокацию и удаленку, про жизнь в разных компаниях. А также полезные ресурсы для развития.
В общем, данные крутые — мы зачитались, поэтому делимся с вами, если еще не видели 🔥
🔥30❤2
Всем привет! 👋
На неделе у коллег из Setters Education аж 4 вечерних прямых эфира о том, как сделать взаимодействие с командой эффективным и экологичным и грамотно работать с состоянием сотрудников и их мотивацией. Сегодня опытом поделимся мы 🔥
🎧 В 19:00 Саша Осколкова, Product Manager команды Teachers Recruiting, подключится с темой «Chief Happiness Officer: с чего начать работу над счастьем команды»
🎤 Эфир можно ловить в канале. Там же останется запись. А по ссылке — напоминание в календарь.
На неделе у коллег из Setters Education аж 4 вечерних прямых эфира о том, как сделать взаимодействие с командой эффективным и экологичным и грамотно работать с состоянием сотрудников и их мотивацией. Сегодня опытом поделимся мы 🔥
🎧 В 19:00 Саша Осколкова, Product Manager команды Teachers Recruiting, подключится с темой «Chief Happiness Officer: с чего начать работу над счастьем команды»
🎤 Эфир можно ловить в канале. Там же останется запись. А по ссылке — напоминание в календарь.
🔥7😁2