Привет!
19 мая Skyeng примет участие в митапе по мобильной разработке Ozon Tech Mobile Meetup.
Артем Новичков из Skyeng расскажет, как работает новая модель многопоточности, и на примерах разберет, что нового появилось в Swift и как это подружить со своим кодом.
А также Александр Свиридов из Ozon расскажет, какие метрики собираются и как ребята борются за перформанс приложения и Владимир Шедько презентует, как в Ozon делали плавный скролл для нагруженного UI.
Регистрируйтесь по ссылке и подключайтесь 19 мая в 18:00.
19 мая Skyeng примет участие в митапе по мобильной разработке Ozon Tech Mobile Meetup.
Артем Новичков из Skyeng расскажет, как работает новая модель многопоточности, и на примерах разберет, что нового появилось в Swift и как это подружить со своим кодом.
А также Александр Свиридов из Ozon расскажет, какие метрики собираются и как ребята борются за перформанс приложения и Владимир Шедько презентует, как в Ozon делали плавный скролл для нагруженного UI.
Регистрируйтесь по ссылке и подключайтесь 19 мая в 18:00.
ozontech.timepad.ru
Ozon Tech Mobile Meetup / События на TimePad.ru
Присоединяйтесь к нашему второму совместному с сообществом Coffee&Code митапу на тему мобильной разработки!
👍6🔥5
Привет!
А мы снова с митапами🙂
На этот раз мы участвуем в Avito Analytics meetup #6 вместе со спикерами из Яндекс Маркета и Авито. Евгения Дубровина из Skyeng поделится нашим опытом работы со сплит-тестами на разветвлённой клиентской базе с многоэтапной воронкой.
А еще в программе огненные доклады про оценку медиамаркетинговых кампаний и оптимизацию юнит-экономики экспресс-доставки.
Регистрируйтесь по ссылке и подключайтесь 24 мая в 18:00.
А мы снова с митапами🙂
На этот раз мы участвуем в Avito Analytics meetup #6 вместе со спикерами из Яндекс Маркета и Авито. Евгения Дубровина из Skyeng поделится нашим опытом работы со сплит-тестами на разветвлённой клиентской базе с многоэтапной воронкой.
А еще в программе огненные доклады про оценку медиамаркетинговых кампаний и оптимизацию юнит-экономики экспресс-доставки.
Регистрируйтесь по ссылке и подключайтесь 24 мая в 18:00.
avitotech.timepad.ru
Avito Analytics meetup #6 / События на TimePad.ru
На шестом митапе для аналитиков выступят спикеры из Яндекс Маркета, Skyeng и Авито. Доклады — про оценку медиамаркетинговых кампаний, оптимизацию юнит-экономики экспресс-доставки и проведение сплит-тестов.
🔥3👍1🎉1
Всем привет!
На прошлой неделе прошла конференция TeamLead Conf, где было много крутых докладов про управление командами, мотивацию и развитие сотрудников, оптимизацию процессов и многое другое 🚀
Мое выступление было о том, как построить people management на данных и сократить текучку в IT. Делюсь ключевыми поинтами)))
🍀 Прежде чем бросаться в решение какой-то проблемы, нужно ее провалидировать: описать и оценить ее значимость для бизнеса. И только после этого инвестировать ресурсы в решение.
В случае с текучкой, мы собрали данные об уходе сотрудников в IT-команде за год – в январе 2021 показатель составил 38% – и измерили его в деньгах. При этом перенаем одного инженера на тот момент стоил компании ~1.3млн руб. Таким образом, высокая текучка айтишников обходилась бизнесу в сотни миллионов рублей в год. Проблема провалидирована, надо решать.
🍀 Дальше важно провести анализ, чтобы понять первопричины проблемы. В рамках борьбы с текучкой мы взяли данные из опроса вовлеченности, показатель eNPS и разбили их по командам. Так мы увидели ключевые факторы, влияющие на показатель – недостаток обратной связи от руководителей и непрозрачные карьерные возможности для сотрудников.
🍀 Выработка решений. Пожалуй, главная рекомендация на этом этапе – направлять свой ресурс именно в те причины, которые оказывают наибольшее влияние на проблему и не распыляться на остальные. Для борьбы с текучкой мы реализовали несколько инициатив: запустили курсы по обратной связи для руководителей, внедрили прозрачные карьерные треки для инженеров, провели интенсивы по составлению PDP (персональный план развития) среди тимлидов, провели грейдинг команды и составили для каждого планы по развитию.
🍀 Этап, про который очень часто забывают. Перепроверьте, что ваши усилия были не напрасны и проблема решилась.
Какие результаты мы получили:
📌вовлеченность выросла на 4%, в частности пункт про карьеру увеличился на 11%,
📌 eNPS вырос на 7,5%,
📌 ну и самое главное, годовая текучка упала на 30%.
Profit 💪
На прошлой неделе прошла конференция TeamLead Conf, где было много крутых докладов про управление командами, мотивацию и развитие сотрудников, оптимизацию процессов и многое другое 🚀
Мое выступление было о том, как построить people management на данных и сократить текучку в IT. Делюсь ключевыми поинтами)))
🍀 Прежде чем бросаться в решение какой-то проблемы, нужно ее провалидировать: описать и оценить ее значимость для бизнеса. И только после этого инвестировать ресурсы в решение.
В случае с текучкой, мы собрали данные об уходе сотрудников в IT-команде за год – в январе 2021 показатель составил 38% – и измерили его в деньгах. При этом перенаем одного инженера на тот момент стоил компании ~1.3млн руб. Таким образом, высокая текучка айтишников обходилась бизнесу в сотни миллионов рублей в год. Проблема провалидирована, надо решать.
🍀 Дальше важно провести анализ, чтобы понять первопричины проблемы. В рамках борьбы с текучкой мы взяли данные из опроса вовлеченности, показатель eNPS и разбили их по командам. Так мы увидели ключевые факторы, влияющие на показатель – недостаток обратной связи от руководителей и непрозрачные карьерные возможности для сотрудников.
🍀 Выработка решений. Пожалуй, главная рекомендация на этом этапе – направлять свой ресурс именно в те причины, которые оказывают наибольшее влияние на проблему и не распыляться на остальные. Для борьбы с текучкой мы реализовали несколько инициатив: запустили курсы по обратной связи для руководителей, внедрили прозрачные карьерные треки для инженеров, провели интенсивы по составлению PDP (персональный план развития) среди тимлидов, провели грейдинг команды и составили для каждого планы по развитию.
🍀 Этап, про который очень часто забывают. Перепроверьте, что ваши усилия были не напрасны и проблема решилась.
Какие результаты мы получили:
📌вовлеченность выросла на 4%, в частности пункт про карьеру увеличился на 11%,
📌 eNPS вырос на 7,5%,
📌 ну и самое главное, годовая текучка упала на 30%.
Profit 💪
👍21🔥6👎2
Ребят, и оффтопом немного про ближайший викенд)
Эти выходные у многих пройдут под лейтмотивом конференции CodeFest в Новосибе) Skyeng тоже в ней участвует, заходите послушать доклады и познакомиться!
Завтра (28 мая) в 11.00 я – Виталий Леонов – буду открывать секцию Management, расскажу о том, как построить приборную панель тимлида, все оцифровать и спать спокойно. Приходите поддержать и буду рад со всеми пообщаться в перерывах между треками.
29 мая в 11.00 Head of Mobile Platform Слава Слуцкер расскажет про SwiftUI + Combine и как же все же начать писать простой и тестируемый код.
Эти выходные у многих пройдут под лейтмотивом конференции CodeFest в Новосибе) Skyeng тоже в ней участвует, заходите послушать доклады и познакомиться!
Завтра (28 мая) в 11.00 я – Виталий Леонов – буду открывать секцию Management, расскажу о том, как построить приборную панель тимлида, все оцифровать и спать спокойно. Приходите поддержать и буду рад со всеми пообщаться в перерывах между треками.
29 мая в 11.00 Head of Mobile Platform Слава Слуцкер расскажет про SwiftUI + Combine и как же все же начать писать простой и тестируемый код.
CodeFest X 30-31 марта 2019
Приборная панель тимлида. Как оцифровать всё и спать спокойно
Management. Виталий Леонов, Skyeng
👍10🔥6🎉4👎1
Привет! Меня зовут Сергей Никифоров, я руководитель гильдии QA внутри компании Skyeng.
За свою историю в QA я провел сотни собеседований, как на QA/QAA разных уровней, так и на QA Lead (далее – QL). Помимо этого, мы помогали прокачивать курсы по QA в Skypro (наши курсы про #войтивайти), создали собственную платформу стажировок, систему грейдирования и программу обучения по автоматизации.
Не поверите, но понять уровень профессионализма специалиста вам поможет ответ на один простой вопрос: Скорость или качество?
Почему именно этот вопрос? Давай копать 😎
Этот вопрос одновременно отражает знание процессов управления разработкой продукта, показывает опыт человека в решении конфликтов и отстаивании своей точки зрения. Почти всегда – 20 из 24 QL – выбирали один из вариантов, большинство голосовало за «качество».
При попытке объяснить выбор, на меня часто смотрели как на дурака и выдавали аргументы про:
📍Ну, я QL, я про качество.
📍Кроме меня никто на качество смотреть не будет, а качество важно, я должен его контролировать
📍Наш клиент должен получать качественный функционал, это самое важное.
Бесспорно, бывали и варианты про приоритет скорости:
📌 Мы должны следить за качеством, но не мешать своей работой разработке и бизнесу
📌 Качество важно, но мы не влияем на сроки, сказали быстро — делаем быстро
📌 Если у нас спринты, то мы должны успевать, а баги править будем позже
И в том, и в другом случае проблема одна — QL/QA не видит своё влияние на весь процесс. Для него работа в команде это постоянное противостояние между командой «скорости» (чаще всего — разрабы и их тимлид) и «качества» (QA и QL), которые на протяжении 457 серий делают продукт. Это приводит к тому, что человек чаще всего работает с процессами в рамках только этапа тестирования и не думает о счастье пользователя.
Так, а какой ответ верный, спросите вы? А об этом мы поговорим завтра, друзья, не переключайтесь😊
PS. Делитесь в комментах своими подходами 💪
За свою историю в QA я провел сотни собеседований, как на QA/QAA разных уровней, так и на QA Lead (далее – QL). Помимо этого, мы помогали прокачивать курсы по QA в Skypro (наши курсы про #войтивайти), создали собственную платформу стажировок, систему грейдирования и программу обучения по автоматизации.
Не поверите, но понять уровень профессионализма специалиста вам поможет ответ на один простой вопрос: Скорость или качество?
Почему именно этот вопрос? Давай копать 😎
Этот вопрос одновременно отражает знание процессов управления разработкой продукта, показывает опыт человека в решении конфликтов и отстаивании своей точки зрения. Почти всегда – 20 из 24 QL – выбирали один из вариантов, большинство голосовало за «качество».
При попытке объяснить выбор, на меня часто смотрели как на дурака и выдавали аргументы про:
📍Ну, я QL, я про качество.
📍Кроме меня никто на качество смотреть не будет, а качество важно, я должен его контролировать
📍Наш клиент должен получать качественный функционал, это самое важное.
Бесспорно, бывали и варианты про приоритет скорости:
📌 Мы должны следить за качеством, но не мешать своей работой разработке и бизнесу
📌 Качество важно, но мы не влияем на сроки, сказали быстро — делаем быстро
📌 Если у нас спринты, то мы должны успевать, а баги править будем позже
И в том, и в другом случае проблема одна — QL/QA не видит своё влияние на весь процесс. Для него работа в команде это постоянное противостояние между командой «скорости» (чаще всего — разрабы и их тимлид) и «качества» (QA и QL), которые на протяжении 457 серий делают продукт. Это приводит к тому, что человек чаще всего работает с процессами в рамках только этапа тестирования и не думает о счастье пользователя.
Так, а какой ответ верный, спросите вы? А об этом мы поговорим завтра, друзья, не переключайтесь😊
PS. Делитесь в комментах своими подходами 💪
🔥23👎7👍3
Привет!
Итак, возвращаемся к теме «Качество vs скорость». Каким же должен быть ответ на этот вопрос?!
Важно, чтобы QA/QL сказал, что «скорости не бывает без качества» и сможет это аргументировать, например, так:
🍀 Хорошие процессы приводят к хорошим решениям, которые легко разрабатывать (тестирование требований, груминг, исследования)
🍀 Качество — это и поставка нового крутого функционала в сжатые сроки. Клиент должен быть доволен сроками появления фич или исправлением неудачных решений.
🍀 Можно сделать быстро и некачественно, но исправление ошибок тоже жрет время, а следовательно итоговое решение придет все равно позже
🍀 Я должен влиять на сроки, ускоряя производство через качественные процессы, а полученное время команда может использовать для новых задач, рефакторинга и т.д.
Этот простой вопрос не раз помогал мне определиться с кандидатами, он работает как лакмусовая бумажка — можно знать много теории и практики, но если с такой фундаментальной частью проблемы, то ты обязательно столкнешься со сложностями при интеграции такого человека в команду.
Итак, возвращаемся к теме «Качество vs скорость». Каким же должен быть ответ на этот вопрос?!
Важно, чтобы QA/QL сказал, что «скорости не бывает без качества» и сможет это аргументировать, например, так:
🍀 Хорошие процессы приводят к хорошим решениям, которые легко разрабатывать (тестирование требований, груминг, исследования)
🍀 Качество — это и поставка нового крутого функционала в сжатые сроки. Клиент должен быть доволен сроками появления фич или исправлением неудачных решений.
🍀 Можно сделать быстро и некачественно, но исправление ошибок тоже жрет время, а следовательно итоговое решение придет все равно позже
🍀 Я должен влиять на сроки, ускоряя производство через качественные процессы, а полученное время команда может использовать для новых задач, рефакторинга и т.д.
Этот простой вопрос не раз помогал мне определиться с кандидатами, он работает как лакмусовая бумажка — можно знать много теории и практики, но если с такой фундаментальной частью проблемы, то ты обязательно столкнешься со сложностями при интеграции такого человека в команду.
🔥22👍12👏1
Привет!
Мы продолжаем рубрику “СТО на каникулах” и сегодня я, Сергей Никифоров, Head of QA, расскажу, как мы в Skyeng боремся с багами и каких результатов удалось достичь🚀
Если у вас рабочий zero bug policy или lead time от создания до закрытия всех багов меньше недели – перематывайте, вы и так все знаете!
3 года назад для Skyeng нормальным явлением было 5000 багов в бэклоге, и этот тренд уверенно рос. Это нормально для всех стартапов и компаний, где нет иной ценности кроме скорости.
Чаще всего пренебрежение бэклогом сознательное и на то есть несколько причин, давайте назовем их всадниками багоапокалипсиса:
📍 Лень: чем меньше делаешь, тем лучше.
📍 Гордость: баги не мои и вообще такой ерундой разработчик заниматься не хочет.
📍 Отстраненность: ощущение непричастности к продукту и что исправление 1 бага не изменит положение вещей.
📍 Недальновидность: обязательно исправим, но потом.
Давайте разбираться, что и как можно сделать с каждым всадником.
🔥 Лень. Самый коварный противник, но мы его победили. И вот почему: значительную часть багов в core сервисах мы не решали как баги. QA “вспоминали” про их существование при планировании фичи, аргументируя это тем “слушай, ты же все равно полезешь в N, там вот еще это не работало, тебе быстро будет поменять”. И действительно, формулировка “раз ты всё равно полез, поправь попутно” работает лучше, чем отдельно стоящий bug в трекере, который отображается на доске.
Такое поведение создает привычку отдавать готовый продукт и меньше использовать костыли, плюс усиливает code review (ребята сами начинают подсвечивать проблемные зоны без QA друг-другу).
🔥 Гордость. Для большинства крутых разработчиков исправление багов не является интересной задачей. Им хочется запускать ракеты в космос, спасать принцесс, что-то делать с драконами, вот это вот всё.
Этот “всадник” отлично побеждается соревновательным элементом. Введите обязательные политики по жизни багов, SLA по их выполнению и сравните команды между собой, чтобы сильные дяди могли помериться своей силой)
Главное, чтобы все правила задавались “извне”, а не навязывались одной команде другой, чтобы все были в равных условиях.
Завтра поговорим про отстраненность и недальновидность, а также я расскажу, чего мы достигли, выиграв бой у всех “всадников”. Пока делитесь в комментариях своими всадниками багоапакалиписиса 😅
Мы продолжаем рубрику “СТО на каникулах” и сегодня я, Сергей Никифоров, Head of QA, расскажу, как мы в Skyeng боремся с багами и каких результатов удалось достичь🚀
Если у вас рабочий zero bug policy или lead time от создания до закрытия всех багов меньше недели – перематывайте, вы и так все знаете!
3 года назад для Skyeng нормальным явлением было 5000 багов в бэклоге, и этот тренд уверенно рос. Это нормально для всех стартапов и компаний, где нет иной ценности кроме скорости.
Чаще всего пренебрежение бэклогом сознательное и на то есть несколько причин, давайте назовем их всадниками багоапокалипсиса:
📍 Лень: чем меньше делаешь, тем лучше.
📍 Гордость: баги не мои и вообще такой ерундой разработчик заниматься не хочет.
📍 Отстраненность: ощущение непричастности к продукту и что исправление 1 бага не изменит положение вещей.
📍 Недальновидность: обязательно исправим, но потом.
Давайте разбираться, что и как можно сделать с каждым всадником.
🔥 Лень. Самый коварный противник, но мы его победили. И вот почему: значительную часть багов в core сервисах мы не решали как баги. QA “вспоминали” про их существование при планировании фичи, аргументируя это тем “слушай, ты же все равно полезешь в N, там вот еще это не работало, тебе быстро будет поменять”. И действительно, формулировка “раз ты всё равно полез, поправь попутно” работает лучше, чем отдельно стоящий bug в трекере, который отображается на доске.
Такое поведение создает привычку отдавать готовый продукт и меньше использовать костыли, плюс усиливает code review (ребята сами начинают подсвечивать проблемные зоны без QA друг-другу).
🔥 Гордость. Для большинства крутых разработчиков исправление багов не является интересной задачей. Им хочется запускать ракеты в космос, спасать принцесс, что-то делать с драконами, вот это вот всё.
Этот “всадник” отлично побеждается соревновательным элементом. Введите обязательные политики по жизни багов, SLA по их выполнению и сравните команды между собой, чтобы сильные дяди могли помериться своей силой)
Главное, чтобы все правила задавались “извне”, а не навязывались одной команде другой, чтобы все были в равных условиях.
Завтра поговорим про отстраненность и недальновидность, а также я расскажу, чего мы достигли, выиграв бой у всех “всадников”. Пока делитесь в комментариях своими всадниками багоапакалиписиса 😅
👍26
Привет!
Итак, как мы сражались с остальными всадниками.
🔥 Отстраненность. Чаще всего этим “недугом” страдаю команды, у которых разработка идет более 2-х лет. Эйфория от “запуска” уже давно прошла, задачи стали рутинными, а баги на вентилятор продолжают падать.
Этот противник может воздействовать на всю команду и компанию. Его коварство заключается в том, что в определённый момент он может победить и вас, если вы будете недостаточно настойчивыми.
Выиграть здесь возможно только через создание новой системы мотивации, в которой продукт должен не только существовать, но и быть лучшим на рынке, самым стабильным и востребованным. Но здесь без продакта не обойтись)
Здесь важно посчитать урон он тех багов, которые должны быть действительно исправлены и договориться об итерациях определения “уровня сервиса” для ваших команд. Условно, это выглядит как ступеньки, по которым команда проводит продукт, например от большего к меньшему:
Продукт работает, мы можем упасть, но быстро поднимемся
Пользователи сталкиваются с проблемами, но мы не можем упасть
Люди пользуются с удовольствием, редко сталкиваются с проблемами и получают быстро решение
На рынке нет более крутого продукта
Критерии обязательно должны быть засмартованы, чтобы и бизнесу, и разработке был очевиден переход от одного уровня к другому.
🔥 Недальновидность. Чем больше багов у вас в продукте, тем меньше скорость поставки решений до клиента в будущем. Недальновидность образуется там, где нет четкого планирования и ответственности за принятые решения. Но чтобы изменить ситуацию важно провести ретроспективу.
Во-первых, команде нужно будет признать, что ранее принятые решения действительно создают множество проблем и выявить их причины. Имеет смысл проводить это регулярно и чинить процессы, а не людей.
Во-вторых, начинайте всегда с изменений, которые обойдутся команде малой кровью и при этом дадут максимальный результат (принцип Парето, да-да).
Ну и очевидное, проведите ретроспективу, на которой вы покажите результат проведенных изменений.
К каким же результатам мы пришли в Skyeng:
🍀 количество багов в беклоге снизилось с 5000 до 1300 по всем продуктам и проектам. Это до сих пор непозволительно много, но динамика положительная :)
🍀 Появились SLA (срок жизни бага в днях/часах), в которых участвуют команды разработки на фикс багов, мы можем прогнозировать и сообщать пользователям примерные сроки решения проблем.
🍀 Про наш инцидент-менеджмент можно почитать здесь, он тоже помогает в решении пропущенных багов и их скорейшего исправления
🍀 В некоторых платформенных проектах подкрадываемся к Zero Bug Policy. Пока больно, но мы обязательно к этому придем.
Безусловно, эта история про то, что мы смогли пропустить, но мы работаем над тем, чтобы ничего не пропускать 😜
Итак, как мы сражались с остальными всадниками.
🔥 Отстраненность. Чаще всего этим “недугом” страдаю команды, у которых разработка идет более 2-х лет. Эйфория от “запуска” уже давно прошла, задачи стали рутинными, а баги на вентилятор продолжают падать.
Этот противник может воздействовать на всю команду и компанию. Его коварство заключается в том, что в определённый момент он может победить и вас, если вы будете недостаточно настойчивыми.
Выиграть здесь возможно только через создание новой системы мотивации, в которой продукт должен не только существовать, но и быть лучшим на рынке, самым стабильным и востребованным. Но здесь без продакта не обойтись)
Здесь важно посчитать урон он тех багов, которые должны быть действительно исправлены и договориться об итерациях определения “уровня сервиса” для ваших команд. Условно, это выглядит как ступеньки, по которым команда проводит продукт, например от большего к меньшему:
Продукт работает, мы можем упасть, но быстро поднимемся
Пользователи сталкиваются с проблемами, но мы не можем упасть
Люди пользуются с удовольствием, редко сталкиваются с проблемами и получают быстро решение
На рынке нет более крутого продукта
Критерии обязательно должны быть засмартованы, чтобы и бизнесу, и разработке был очевиден переход от одного уровня к другому.
🔥 Недальновидность. Чем больше багов у вас в продукте, тем меньше скорость поставки решений до клиента в будущем. Недальновидность образуется там, где нет четкого планирования и ответственности за принятые решения. Но чтобы изменить ситуацию важно провести ретроспективу.
Во-первых, команде нужно будет признать, что ранее принятые решения действительно создают множество проблем и выявить их причины. Имеет смысл проводить это регулярно и чинить процессы, а не людей.
Во-вторых, начинайте всегда с изменений, которые обойдутся команде малой кровью и при этом дадут максимальный результат (принцип Парето, да-да).
Ну и очевидное, проведите ретроспективу, на которой вы покажите результат проведенных изменений.
К каким же результатам мы пришли в Skyeng:
🍀 количество багов в беклоге снизилось с 5000 до 1300 по всем продуктам и проектам. Это до сих пор непозволительно много, но динамика положительная :)
🍀 Появились SLA (срок жизни бага в днях/часах), в которых участвуют команды разработки на фикс багов, мы можем прогнозировать и сообщать пользователям примерные сроки решения проблем.
🍀 Про наш инцидент-менеджмент можно почитать здесь, он тоже помогает в решении пропущенных багов и их скорейшего исправления
🍀 В некоторых платформенных проектах подкрадываемся к Zero Bug Policy. Пока больно, но мы обязательно к этому придем.
Безусловно, эта история про то, что мы смогли пропустить, но мы работаем над тем, чтобы ничего не пропускать 😜
🔥14👍3
Привет!
Наваяли тут для Хабра статью про наш тернистый опыт подготовки тимлидов в Skyeng. И сразу скажу, что это история о том, как делать не нужно 😜
Мы очень быстро из почти «гаражной» компании стали большой, поэтому тимлидом зачастую становился разработчик, который готов был примерить на себя эту роль. Неудивительно, что такой подход не сработал, и нам пришлось искать другие способы подбора тимлидов в команды. О наших пробах и ошибках и пойдет речь в статье.
Делитесь в комментариях своим удачным и не очень опытом работы с тимлидами. Нам это очень поможет, потому что мы все еще ищем ответ на вопрос – как делать хороших тимлидов и как правильно учить всю команду 😎
Наваяли тут для Хабра статью про наш тернистый опыт подготовки тимлидов в Skyeng. И сразу скажу, что это история о том, как делать не нужно 😜
Мы очень быстро из почти «гаражной» компании стали большой, поэтому тимлидом зачастую становился разработчик, который готов был примерить на себя эту роль. Неудивительно, что такой подход не сработал, и нам пришлось искать другие способы подбора тимлидов в команды. О наших пробах и ошибках и пойдет речь в статье.
Делитесь в комментариях своим удачным и не очень опытом работы с тимлидами. Нам это очень поможет, потому что мы все еще ищем ответ на вопрос – как делать хороших тимлидов и как правильно учить всю команду 😎
Хабр
Наш опыт, как не надо растить тимлидов (не делайте как мы)
Тимлидом у нас часто становился не обученный человек, а тот из разработчиков, который меньше всего не хотел. Потому что часто было надо. Исторически у нас в Skyeng очень много автономных команд (мы...
🔥20👍9
Привет! 📚
Ресурсов для развития в разработке много и порой тяжело решить, за что схватиться в первую очередь. Весь бэк у нас на PHP и не первый год мы поддерживаем русскоязычное PHP-комьюнити, поэтому решили узнать, что ребята используют для прокачки и советуют другим.
Так собралась статья про 70+ актуальных ресурсов для PHP-разработчика: книги, блоги, каналы с комментариями от организаторов сообществ и авторов крупных чатов. Списки проранжированы — самые упоминаемые ресурсы идут первыми в разделах.
Если у вас есть рекомендация, которая не вошла в список — делитесь в комментариях ✌️
Ресурсов для развития в разработке много и порой тяжело решить, за что схватиться в первую очередь. Весь бэк у нас на PHP и не первый год мы поддерживаем русскоязычное PHP-комьюнити, поэтому решили узнать, что ребята используют для прокачки и советуют другим.
Так собралась статья про 70+ актуальных ресурсов для PHP-разработчика: книги, блоги, каналы с комментариями от организаторов сообществ и авторов крупных чатов. Списки проранжированы — самые упоминаемые ресурсы идут первыми в разделах.
Если у вас есть рекомендация, которая не вошла в список — делитесь в комментариях ✌️
Хабр
Как прокачаться в PHP: 70 ресурсов из опроса русскоязычного сообщества
В чаты по PHP часто приходят с вопросами про развитие: какие книги стоит прочитать в первую очередь, на какие каналы подписаться, какие курсы хороши. Если повезет, в ответ чат поделится парой...
🔥13👍3💩2
Привет!
Как вообще управлять разработчиками (читай – интеллектуалами)? На этот вопрос нет простого и понятного ответа, а потому мы решили собрать в одну статью наш опыт и самые частые ошибки 🙈
Сейчас мы практикуем “управление результативностью”, потому что верим, что каждый человек вносит важный вклад в бизнес-результаты компании. И разработчики не исключение)
Читайте, критикуйте и делитесь своими подходами в управлении людьми в командах разработки 😜
Как вообще управлять разработчиками (читай – интеллектуалами)? На этот вопрос нет простого и понятного ответа, а потому мы решили собрать в одну статью наш опыт и самые частые ошибки 🙈
Сейчас мы практикуем “управление результативностью”, потому что верим, что каждый человек вносит важный вклад в бизнес-результаты компании. И разработчики не исключение)
Читайте, критикуйте и делитесь своими подходами в управлении людьми в командах разработки 😜
👍13🤔4🔥1
Привет!
Я Deputy CTO Сергей Сафонов и сегодня расскажу, как мы в Skyeng регулярно оптимизируем расходы на инфраструктуру.
Зачем мы это делаем? Чтобы убрать неоправданные расходы и уменьшить затраты на инфру без ущерба качеству и стабильности. За множество итераций мы выработали 3 простых шага, которые помогают делать это эффективно 😎
📈 Анализ расходов в разных плоскостях: по дата-центрам, серверам, командам, функции (базы данных, кластер, очереди), нагрузке и т.д.
🧭 Выбор основных направлений для более глубокого анализа и проведение анализа.
👨💻 Формирование задач и проектов, сведение их в единый роадмап.
А теперь к результатам) Вот часть изменений, которые в сумме с другими позволили сэкономить около 5% годового бюджета на инфраструктуру:
📍Увеличили среднюю пиковую нагрузку на кластер с ~15% до 60%
📍Сократили расходы на сервисы за счет отказа от сервиса, части функционала, сокращения пользователей или смены тарифа
📍Начали использовать прерываемые виртуальные машины в Yandex Cloud
📍Передали в команды с большими расходами задачу оптимизировать используемые ресурсы и затраты
📍Переехали с bare-metal серверов на k8s
На что еще можно обратить внимание при оптимизации расходов:
🍀 Переосмыслить целесообразность расходов с точки зрения актуальных потребностей бизнеса. Например, вы храните большое количество метаинформации, но у компании нет запроса на ее использование. Стоит ли тратить деньги на ее хранение?!
🍀 Обсудить цены с текущими партнерами и провести переговоры с другими поставщиками.
Я Deputy CTO Сергей Сафонов и сегодня расскажу, как мы в Skyeng регулярно оптимизируем расходы на инфраструктуру.
Зачем мы это делаем? Чтобы убрать неоправданные расходы и уменьшить затраты на инфру без ущерба качеству и стабильности. За множество итераций мы выработали 3 простых шага, которые помогают делать это эффективно 😎
📈 Анализ расходов в разных плоскостях: по дата-центрам, серверам, командам, функции (базы данных, кластер, очереди), нагрузке и т.д.
🧭 Выбор основных направлений для более глубокого анализа и проведение анализа.
👨💻 Формирование задач и проектов, сведение их в единый роадмап.
А теперь к результатам) Вот часть изменений, которые в сумме с другими позволили сэкономить около 5% годового бюджета на инфраструктуру:
📍Увеличили среднюю пиковую нагрузку на кластер с ~15% до 60%
📍Сократили расходы на сервисы за счет отказа от сервиса, части функционала, сокращения пользователей или смены тарифа
📍Начали использовать прерываемые виртуальные машины в Yandex Cloud
📍Передали в команды с большими расходами задачу оптимизировать используемые ресурсы и затраты
📍Переехали с bare-metal серверов на k8s
На что еще можно обратить внимание при оптимизации расходов:
🍀 Переосмыслить целесообразность расходов с точки зрения актуальных потребностей бизнеса. Например, вы храните большое количество метаинформации, но у компании нет запроса на ее использование. Стоит ли тратить деньги на ее хранение?!
🍀 Обсудить цены с текущими партнерами и провести переговоры с другими поставщиками.
🔥16👍4👎1
Привет!
26 июля (вторник) в 18.30 заглядывайте на митап Avito для тимлидов, поговорим про насущное:
🔥 Чего ждут коллеги разных уровней от тимлидов? — доклад, а потом дискуссия, где будет участвовать Дмитрий Кузнецов, Dev Unit Lead Skyeng.
🔥 Во второй части — доклад про осознание себя в роли руководителя тимлидов. И следом тоже крутое обсуждение.
Где: онлайн на ютубе. Регистрация не нужна)
26 июля (вторник) в 18.30 заглядывайте на митап Avito для тимлидов, поговорим про насущное:
🔥 Чего ждут коллеги разных уровней от тимлидов? — доклад, а потом дискуссия, где будет участвовать Дмитрий Кузнецов, Dev Unit Lead Skyeng.
🔥 Во второй части — доклад про осознание себя в роли руководителя тимлидов. И следом тоже крутое обсуждение.
Где: онлайн на ютубе. Регистрация не нужна)
🔥20👍6
Привет!
Как вырваться из рутины, вдохновить и сфокусировать команду на достижении долгосрочных целей? Самый простой путь – провести стратсессию♟
С чего начать
❓Сформировать запрос. Важно учесть мнение каждого участника команды, убедитесь, что все разделяют цели предстоящей встречи.
📚 Сделать “домашнее задание”: что нужно изучить до стратсессии и подготовить ко встрече для погружения всех в общий контекст.
📋 Составить детальный план проведения встречи. Идеальный тайминг – до 2 часов на блок.
🚀 Определить финальный результат. Как правило, это фокусы, цели или крупные проекты на ближайший год.
Сама стратсессия – это 3-4 дня активной работы:
📍День 1. Погружение участников в общий контекст, обсуждение ключевых проблем, вызовов. К концу дня все должны быть “on the same page” :)
📍День 2. Генерация целей, проектов, проблем и решений. Задача – войти в “зону стонов”, выкинуть лишнее, сформировать финальное видение стратегии.
📍День 3. Докрутка стратегии: определение результата в цифрах (KPIs, DoDs) и ответственных за достижений целей, а также за нерешенные вопросы.
На что еще стоит обратить внимание:
🍀 Не забывайте про время после стратсессии, развлечения вечером сами себя не придумают и не организуют :)
🍀 Чем больше участников, тем важнее роль ведущего. Точно стоит пригласить профессионального модератора при 8+ участниках.
🍀 Смело пересматривайте план, если понимаете, что он потерял актуальность. План нужен не ради плана, а для достижения целей.
🍀 Проводите короткие разминки или активности в течение дня, это поможет команде оставаться в тонусе.
🍀 Создание стратегии не означает достижение результата. Последнее будет во многом зависеть от лидера и команды, от их умения реалистично оценивать возможности и воплощать амбициозные планы.
Перед проведением стратсессии советую прочитать книгу “Руководство фасилитатора: как привести группу к принятию совместного решения” или посмотреть, как это делают профессионалы, например, Сергей Артюхов.
Как вырваться из рутины, вдохновить и сфокусировать команду на достижении долгосрочных целей? Самый простой путь – провести стратсессию♟
С чего начать
❓Сформировать запрос. Важно учесть мнение каждого участника команды, убедитесь, что все разделяют цели предстоящей встречи.
📚 Сделать “домашнее задание”: что нужно изучить до стратсессии и подготовить ко встрече для погружения всех в общий контекст.
📋 Составить детальный план проведения встречи. Идеальный тайминг – до 2 часов на блок.
🚀 Определить финальный результат. Как правило, это фокусы, цели или крупные проекты на ближайший год.
Сама стратсессия – это 3-4 дня активной работы:
📍День 1. Погружение участников в общий контекст, обсуждение ключевых проблем, вызовов. К концу дня все должны быть “on the same page” :)
📍День 2. Генерация целей, проектов, проблем и решений. Задача – войти в “зону стонов”, выкинуть лишнее, сформировать финальное видение стратегии.
📍День 3. Докрутка стратегии: определение результата в цифрах (KPIs, DoDs) и ответственных за достижений целей, а также за нерешенные вопросы.
На что еще стоит обратить внимание:
🍀 Не забывайте про время после стратсессии, развлечения вечером сами себя не придумают и не организуют :)
🍀 Чем больше участников, тем важнее роль ведущего. Точно стоит пригласить профессионального модератора при 8+ участниках.
🍀 Смело пересматривайте план, если понимаете, что он потерял актуальность. План нужен не ради плана, а для достижения целей.
🍀 Проводите короткие разминки или активности в течение дня, это поможет команде оставаться в тонусе.
🍀 Создание стратегии не означает достижение результата. Последнее будет во многом зависеть от лидера и команды, от их умения реалистично оценивать возможности и воплощать амбициозные планы.
Перед проведением стратсессии советую прочитать книгу “Руководство фасилитатора: как привести группу к принятию совместного решения” или посмотреть, как это делают профессионалы, например, Сергей Артюхов.
🔥11👍9🤔3👎1
Привет!
Продолжаем рубрику «СТО на каникулах». Сегодня я, Артем Науменко (Head of Infra), расскажу, как мы рассчитываем затраты на инфраструктуру.
Каждый руководитель инфры или СТО сталкивается с планированием бюджета: сколько серверов докупить, чтобы покрыть потребность бизнеса? Или сколько денег мы потратим на облако в следующем году?
Подобную задачу я решал уже не раз, поэтому поделюсь инсайтами 🙂
🗂 Входные данные
1. План компании по количеству уроков на каждый месяц + прогноз по количеству разработчиков за тот же период.
2. Исторические данные по проведенным урокам + затраты на инфру за прошлые периоды.
🖍 Модель для прогноза
Существуют 3 типа расходов. Каждый коррелирует с планами компании:
1. Stateless сервера (k8s/load balancer, ELK) – количество серверов, пропорциональное количеству планируемых уроков. Я отнес ELK в эту категорию, потому что количество хранимых логов пропорционально количеству уроков при неизменном периоде хранения.
2. Statefull сервера (БД, S3) – количество серверов, пропорциональное суммарному накопленному числу уроков за всю историю компании.
3. Средства разработки – окружения разработки, лицензии на IDE и так далее, пропорциональные количеству разработчиков в компании.
Если есть другие значимые статьи расходов, то стоит подумать, с какими расходами они коррелируют.
💡 Что дальше
Сопоставляем факт по расходам по каждой из категорий серверов / сервисов и факт по метрике компании. Если есть явная линейная зависимость, то все отлично — можно прогнозировать.
Если зависимость нелинейная, то из соответствующей категории серверов вычитаем какую-то часть, которая вероятно коррелирует с чем-то другим. Например, изначально я заложил расходы на хранение видеозаписей уроков пропорционально общему количеству уроков, проведенных в школе. Но, увидев что корреляция не сходится, вспомнил, что мы изменили политику на хранение данных только за последние полгода, после чего все сошлось.
🧮 Считаем
Как только у вас появляется корреляция, можно мыслить в терминах:
📍на каждые 100 уроков в день нам нужно +ХХХ CPU и +УУУ RAM (+3000р. в день на инфру).
📍на каждого нового разработчика или QA нужно +5000р. в месяц на инфру.
📍каждый проведенный урок создает расход на хранение информации о нем в будущем на 1 руб./месяц.
Очевидные проекты экономии в будущем – это очистка старых данных.
После построения модели на нее можно наложить доп. расходы или проекты экономии. Например, наша модель не учитывает новые направления, в которых нет уроков с преподавателем (университет допобразования для взрослых Skypro). Такие расходы можно посчитать отдельно или заложить примерно, если расход незначительный по сравнению с остальными затратами.
P.S. Делитесь в комментах своими подходами. В следующий раз расскажу, как мы автоматизировали работу с инфраструктурой)
Продолжаем рубрику «СТО на каникулах». Сегодня я, Артем Науменко (Head of Infra), расскажу, как мы рассчитываем затраты на инфраструктуру.
Каждый руководитель инфры или СТО сталкивается с планированием бюджета: сколько серверов докупить, чтобы покрыть потребность бизнеса? Или сколько денег мы потратим на облако в следующем году?
Подобную задачу я решал уже не раз, поэтому поделюсь инсайтами 🙂
🗂 Входные данные
1. План компании по количеству уроков на каждый месяц + прогноз по количеству разработчиков за тот же период.
2. Исторические данные по проведенным урокам + затраты на инфру за прошлые периоды.
🖍 Модель для прогноза
Существуют 3 типа расходов. Каждый коррелирует с планами компании:
1. Stateless сервера (k8s/load balancer, ELK) – количество серверов, пропорциональное количеству планируемых уроков. Я отнес ELK в эту категорию, потому что количество хранимых логов пропорционально количеству уроков при неизменном периоде хранения.
2. Statefull сервера (БД, S3) – количество серверов, пропорциональное суммарному накопленному числу уроков за всю историю компании.
3. Средства разработки – окружения разработки, лицензии на IDE и так далее, пропорциональные количеству разработчиков в компании.
Если есть другие значимые статьи расходов, то стоит подумать, с какими расходами они коррелируют.
💡 Что дальше
Сопоставляем факт по расходам по каждой из категорий серверов / сервисов и факт по метрике компании. Если есть явная линейная зависимость, то все отлично — можно прогнозировать.
Если зависимость нелинейная, то из соответствующей категории серверов вычитаем какую-то часть, которая вероятно коррелирует с чем-то другим. Например, изначально я заложил расходы на хранение видеозаписей уроков пропорционально общему количеству уроков, проведенных в школе. Но, увидев что корреляция не сходится, вспомнил, что мы изменили политику на хранение данных только за последние полгода, после чего все сошлось.
🧮 Считаем
Как только у вас появляется корреляция, можно мыслить в терминах:
📍на каждые 100 уроков в день нам нужно +ХХХ CPU и +УУУ RAM (+3000р. в день на инфру).
📍на каждого нового разработчика или QA нужно +5000р. в месяц на инфру.
📍каждый проведенный урок создает расход на хранение информации о нем в будущем на 1 руб./месяц.
Очевидные проекты экономии в будущем – это очистка старых данных.
После построения модели на нее можно наложить доп. расходы или проекты экономии. Например, наша модель не учитывает новые направления, в которых нет уроков с преподавателем (университет допобразования для взрослых Skypro). Такие расходы можно посчитать отдельно или заложить примерно, если расход незначительный по сравнению с остальными затратами.
P.S. Делитесь в комментах своими подходами. В следующий раз расскажу, как мы автоматизировали работу с инфраструктурой)
🔥24👍4
Всем привет!
Завершим рабочую неделю еще одним постом про инфру 👋
Инфраструктура часто является узким местом в разработке. До тех пор, пока инфра не создаст базу данных или репозиторий, разработчики не запилят новый сервис и не начнут зарабатывать деньги. В этом контексте важно перестать быть узким горлышком и максимально быстро выполнять запросы от разработчиков. Поделюсь, как мы решаем эту задачу в Skyeng.
1️⃣ С чего начать? Откажитесь от дежурства по очереди и выделите одного ответственного за поддержку, чтобы сотрудник точно был заинтересован в автоматизации работы инфры.
2️⃣ Внедряем CMDB (базу данных управления конфигурациями) для ведения учета за основными сущностями: серверами, базами, сервисами и так далее. Без этого будет невозможен следующий шаг.
3️⃣ Внедряем Service Desk. Это ускорит обработку обращений, которые требуют больше коммуникаций, чем непосредственно нашей работы. Например, выяснить что нужно, а потом объяснить, как пользоваться результатом.
Важно не просто прикрутить Service Desk, а следить за количеством сообщений в каждом обращении и доводить формы запросов до идеального состояния, чтобы обсуждений и уточняющих вопросов вообще не возникало.
Здесь советую использовать данные из CMDB. Например, когда просят доступ в базу данных, то список БД должен подтягиваться из CMDB, чтобы клиент не мог ошибиться в названии БД.
Итак, Service Desk внедрен и обращения максимально формализованы.
4️⃣ Для каждого типа обращения пишем инструкцию, как с ним работать. Мы описываем все, вплоть до того, какой ответ дать автору обращения.
5️⃣ И последнее — строим аналитику, с какими запросами приходят чаще всего. Когда у вас появится аналитика и инструкции по работе с обращениями, автоматизация станет простым и понятным процессом: берете самые частые запросы и автоматизируете согласно инструкции.
Автоматизируйте и наслаждайтесь результатом!
Завершим рабочую неделю еще одним постом про инфру 👋
Инфраструктура часто является узким местом в разработке. До тех пор, пока инфра не создаст базу данных или репозиторий, разработчики не запилят новый сервис и не начнут зарабатывать деньги. В этом контексте важно перестать быть узким горлышком и максимально быстро выполнять запросы от разработчиков. Поделюсь, как мы решаем эту задачу в Skyeng.
1️⃣ С чего начать? Откажитесь от дежурства по очереди и выделите одного ответственного за поддержку, чтобы сотрудник точно был заинтересован в автоматизации работы инфры.
2️⃣ Внедряем CMDB (базу данных управления конфигурациями) для ведения учета за основными сущностями: серверами, базами, сервисами и так далее. Без этого будет невозможен следующий шаг.
3️⃣ Внедряем Service Desk. Это ускорит обработку обращений, которые требуют больше коммуникаций, чем непосредственно нашей работы. Например, выяснить что нужно, а потом объяснить, как пользоваться результатом.
Важно не просто прикрутить Service Desk, а следить за количеством сообщений в каждом обращении и доводить формы запросов до идеального состояния, чтобы обсуждений и уточняющих вопросов вообще не возникало.
Здесь советую использовать данные из CMDB. Например, когда просят доступ в базу данных, то список БД должен подтягиваться из CMDB, чтобы клиент не мог ошибиться в названии БД.
Итак, Service Desk внедрен и обращения максимально формализованы.
4️⃣ Для каждого типа обращения пишем инструкцию, как с ним работать. Мы описываем все, вплоть до того, какой ответ дать автору обращения.
5️⃣ И последнее — строим аналитику, с какими запросами приходят чаще всего. Когда у вас появится аналитика и инструкции по работе с обращениями, автоматизация станет простым и понятным процессом: берете самые частые запросы и автоматизируете согласно инструкции.
Автоматизируйте и наслаждайтесь результатом!
👍19🔥8👏1😁1
Йо, кукусики 👋
Снова выхожу на связь. Это Серёжа, Head of QA Skyeng. Решил поделиться знакомой QA lead\head болью.
За последний месяц дважды столкнулся с реальным непониманием тимлидов команд нашего требования — пускать QA на все синки.
Особое сопротивление с техревью. Как в классическом меме, аргументация часто сводится к: «Этот QA на ревью нам не нужОн!».
Конкретные пункты звучат так:
🙁 Да он ничего не поймет. Мы-то тут вон какие штуки делаем, а он максимум тесты пописывает.
🧐 Потом ему обязательно (нет) расскажем все тонкости. Смысл ему тратить время? Пусть задачки тестит.
🥺 Он будет нас отвлекать, а у нас по 3-4 задачи на ревью.
Возможно, у большинства это вызовет реакцию: «Ну я-то не такой» и он пойдет обнимет своего QA. Но я знаю, что такая проблема не только у меня.
К сожалению, как и из-за уровня QA в целом, так и из-за стереотипов, для большинства QA — это что-то только про тестирование и где-то отдельно, но не про команду. Каждый подобный кейс с нашими лидами мы прорабатываем: кому-то достаточно аналитики, кому-то примеров «грабель» команд, где QA не звали на общие синки.
Почему на встречах важен QA?
Я бы сходу назвал несколько причин:
📝 Качество — это про ответственность команды, а не только этапа тестирования. Написание красивого кода, который не выполняет все кейсы или не учитывает логику внутри продукта, так же плохо, как и выполнить все условия, но с багами.
📝 Если в силе сотрудника есть сомнения, его не стоит изолировать от команды. Лучше развивать или заменять. Задача крутого лида – создать условия, в которых сотрудники хотят причинить пользу продукту, не ждут очереди и не ограничивают себя на основе субъективных оценок.
📝 Каждый инструмент и каждого сотрудника нужно задействовать так, чтобы он давал максимальную пользу за минимальную стоимость. При производстве стоимость ошибки растёт лавинообразно. Получить фидбек раньше и подумать лишние 20 минут над вопросами QA куда лучше, чем потом 5 часов переделывать.
Это не сверхразум и не рокетсайнс. Это то, что есть в каждом втором учебнике по командообразованию. Но то ли учебники не завезли, то ли у них язык не тот…
А у вас есть такая проблема? Как зарешиваете в своих командах?
Снова выхожу на связь. Это Серёжа, Head of QA Skyeng. Решил поделиться знакомой QA lead\head болью.
За последний месяц дважды столкнулся с реальным непониманием тимлидов команд нашего требования — пускать QA на все синки.
Особое сопротивление с техревью. Как в классическом меме, аргументация часто сводится к: «Этот QA на ревью нам не нужОн!».
Конкретные пункты звучат так:
🙁 Да он ничего не поймет. Мы-то тут вон какие штуки делаем, а он максимум тесты пописывает.
🧐 Потом ему обязательно (нет) расскажем все тонкости. Смысл ему тратить время? Пусть задачки тестит.
🥺 Он будет нас отвлекать, а у нас по 3-4 задачи на ревью.
Возможно, у большинства это вызовет реакцию: «Ну я-то не такой» и он пойдет обнимет своего QA. Но я знаю, что такая проблема не только у меня.
К сожалению, как и из-за уровня QA в целом, так и из-за стереотипов, для большинства QA — это что-то только про тестирование и где-то отдельно, но не про команду. Каждый подобный кейс с нашими лидами мы прорабатываем: кому-то достаточно аналитики, кому-то примеров «грабель» команд, где QA не звали на общие синки.
Почему на встречах важен QA?
Я бы сходу назвал несколько причин:
📝 Качество — это про ответственность команды, а не только этапа тестирования. Написание красивого кода, который не выполняет все кейсы или не учитывает логику внутри продукта, так же плохо, как и выполнить все условия, но с багами.
📝 Если в силе сотрудника есть сомнения, его не стоит изолировать от команды. Лучше развивать или заменять. Задача крутого лида – создать условия, в которых сотрудники хотят причинить пользу продукту, не ждут очереди и не ограничивают себя на основе субъективных оценок.
📝 Каждый инструмент и каждого сотрудника нужно задействовать так, чтобы он давал максимальную пользу за минимальную стоимость. При производстве стоимость ошибки растёт лавинообразно. Получить фидбек раньше и подумать лишние 20 минут над вопросами QA куда лучше, чем потом 5 часов переделывать.
Это не сверхразум и не рокетсайнс. Это то, что есть в каждом втором учебнике по командообразованию. Но то ли учебники не завезли, то ли у них язык не тот…
А у вас есть такая проблема? Как зарешиваете в своих командах?
🔥25👍11
Привет!
Скоро закончится рубрика «СТО на каникулах» — ведь и лето подходит к концу. А пока делимся классной штукой про Skyeng Tech.
У нас говорят: «В Skyeng год за три». И не зря — ребята каждые день зарешивают такие челленджи, что просто держись.
Вот несколько историй:
🍀 Дима Кузнецов (Dev Unit Lead) рассказал про эпопею с разработкой системы грейдирования.
🍀 Ира Шанина (Team Lead и Frontend Developer) — о том, как совмещать две роли: руководить командой разработки и писать фронтенд в другом проекте.
🍀 Настя Анисимова (Frontend Developer) поделилась, как сам путь в разработку стал тем еще испытанием и что помогло дорасти до Core-команды платформы.
🍀 Саша Фомиченко (Game Studio Lead) — о дилемме «Что первично: игры или образование?» и зачем вообще Skyeng геймдев-команда.
🍀 Миша Ефанов (Frontend Developer) про кейс, когда за 4 недели команда пересобрала стартовую страницу Skysmart Pro и 12 дополнительных.
🍀 Дима Бормотов (CIS: Head of Growth & Local Products) — о своей сложнопроизносимой должности, большом эксперименте и канале с мемами как главном челлендже (это не шутка).
🔥🤩 Больше видео и текстовых историй ребят собрали на сайте Growthboosters.
Скоро закончится рубрика «СТО на каникулах» — ведь и лето подходит к концу. А пока делимся классной штукой про Skyeng Tech.
У нас говорят: «В Skyeng год за три». И не зря — ребята каждые день зарешивают такие челленджи, что просто держись.
Вот несколько историй:
🍀 Дима Кузнецов (Dev Unit Lead) рассказал про эпопею с разработкой системы грейдирования.
🍀 Ира Шанина (Team Lead и Frontend Developer) — о том, как совмещать две роли: руководить командой разработки и писать фронтенд в другом проекте.
🍀 Настя Анисимова (Frontend Developer) поделилась, как сам путь в разработку стал тем еще испытанием и что помогло дорасти до Core-команды платформы.
🍀 Саша Фомиченко (Game Studio Lead) — о дилемме «Что первично: игры или образование?» и зачем вообще Skyeng геймдев-команда.
🍀 Миша Ефанов (Frontend Developer) про кейс, когда за 4 недели команда пересобрала стартовую страницу Skysmart Pro и 12 дополнительных.
🍀 Дима Бормотов (CIS: Head of Growth & Local Products) — о своей сложнопроизносимой должности, большом эксперименте и канале с мемами как главном челлендже (это не шутка).
🔥🤩 Больше видео и текстовых историй ребят собрали на сайте Growthboosters.
🔥9👍4
Всем привет!
Ищем Dev Team Lead в платформенную команду Skyeng.
Если ты хочешь создавать крутые технические решения для других инженеров и команд, отвечать за стабильность и развитие ключевых сервисов компании, внедрять современные практики backend-разработки и стать настоящим амбассадором в гильдии PHP, го к нам. Будем вместе драйвить развитие — твое и команды 🚀
Что тебе предстоит делать:
👨💻 Проводить техревью, реализовывать технические решения в сервисах: авторизация, права и роли, уведомления, сокет-соединения
🚨 Выстраивать SLA, алерты и мониторинги для сервисов
Разрабатывать архитектурные и технические решения
📈 Поддерживать и развивать процессы внутри команды: планирование, scrum, практики тестирования и деплоя
🦸♂️ Управлять командой: прокачка, мотивация и найм сотрудников
🚀 Участвовать в кросс-командных проектах и интегрировать решения в экосистему Skyeng
Подробнее по ссылке.
Ищем Dev Team Lead в платформенную команду Skyeng.
Если ты хочешь создавать крутые технические решения для других инженеров и команд, отвечать за стабильность и развитие ключевых сервисов компании, внедрять современные практики backend-разработки и стать настоящим амбассадором в гильдии PHP, го к нам. Будем вместе драйвить развитие — твое и команды 🚀
Что тебе предстоит делать:
👨💻 Проводить техревью, реализовывать технические решения в сервисах: авторизация, права и роли, уведомления, сокет-соединения
🚨 Выстраивать SLA, алерты и мониторинги для сервисов
Разрабатывать архитектурные и технические решения
📈 Поддерживать и развивать процессы внутри команды: планирование, scrum, практики тестирования и деплоя
🦸♂️ Управлять командой: прокачка, мотивация и найм сотрудников
🚀 Участвовать в кросс-командных проектах и интегрировать решения в экосистему Skyeng
Подробнее по ссылке.
🔥13👍6🤔2
Всем привет! 🙌
Мы давно не выходили на связь. Исправляемся и не откладываем на 2023. Решили больше рассказывать про Skyeng Tech и брать разные темы.
Уже заготовили крутых постов — потихоньку поделимся. Вдруг вы тоже закинете тем и вопросов? Про что интересно узнать? Может конкретные кейсы на нашем опыте.
🔥 А пока — наверстаем упущенное по статьям. Сделали расшифровку доклада с DUMP’22 про ретроспективы.
Наш тимлид из команды Student Cabinet, Лёша Дидух, поработав в нескольких командах с разными культурами и подходами, собрал в статью все, что знает про ретро.
Будет полезно и тимлидам, и юным скрам-мастерам, да и вообще любому, кто хотя бы раз сидел на ретроспективе и думал: «Что я здесь делаю?». Если больше по душе не тексты, а доклады — вот запись 😉
Мы давно не выходили на связь. Исправляемся и не откладываем на 2023. Решили больше рассказывать про Skyeng Tech и брать разные темы.
Уже заготовили крутых постов — потихоньку поделимся. Вдруг вы тоже закинете тем и вопросов? Про что интересно узнать? Может конкретные кейсы на нашем опыте.
🔥 А пока — наверстаем упущенное по статьям. Сделали расшифровку доклада с DUMP’22 про ретроспективы.
Наш тимлид из команды Student Cabinet, Лёша Дидух, поработав в нескольких командах с разными культурами и подходами, собрал в статью все, что знает про ретро.
Будет полезно и тимлидам, и юным скрам-мастерам, да и вообще любому, кто хотя бы раз сидел на ретроспективе и думал: «Что я здесь делаю?». Если больше по душе не тексты, а доклады — вот запись 😉
🔥13👍6