Как стать автором
Обновить
82.09
Skyeng
Крутой edtech с удаленкой для айтишников
Сначала показывать

Когда игра учит больше, чем уроки

Уровень сложностиПростой
Время на прочтение8 мин
Количество просмотров4K


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

Мы хотели проверить, что будет, если совместить игру-песочницу с образовательным контентом. Сможем ли мы научить ребёнка языку так, чтобы он этого даже не заметил? Примерно так, как дети учат первый язык в жизни: взаимодействуя со средой, слушая взрослых и решая свои собственные детские задачи в стиле «если я хочу получить что-то, мне нужно знать, как это называется».

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

Что касается метрик, то мы работаем над временем сессии и средним временем, которое игроки проводят в игре за неделю. Эти метрики мы считаем опережающими к LT. И если ученики будут много играть и игра сильно увеличит среднее время в неделю, то мы сможем оставить игру бесплатной для наших учеников.
Читать дальше →
Всего голосов 14: ↑13 и ↓1+14
Комментарии9

Апгрейд и рефакторинг PHP-проектов — теперь это просто с Rector

Уровень сложностиСредний
Время на прочтение14 мин
Количество просмотров25K

Привет! В статье поделюсь, как инструмент автоматического рефакторинга Rector помогает обуздать легаси и автоматизировать обновление PHP проектов и пакетов, чтобы процесс проходил эффективнее и малой кровью. 

Статья написана на основе доклада с PHP Russia 2022.

Читать далее
Всего голосов 54: ↑54 и ↓0+54
Комментарии13

Готовим версионирование API в PHP-фреймворках: разбор способов и работа с организацией кода

Уровень сложностиПростой
Время на прочтение13 мин
Количество просмотров8.5K

Привет! Меня зовут Олег Мифле. В Skyeng работаю над проектом Skypro. В IT я уже больше десяти лет, семь из которых пишу на PHP. За плечами десятки разных проектов: e-commerce, финтех, CRM, а недавно добавился и EdTech. Были и классические фуллстек-проекты, и проекты, где фронтенд и бэкенд «живут» отдельно и коммуницируют друг с другом по API. Боль от отсутствия версионирования я испытал на себе. Хочу поделиться, как избежать проблем, как всё структурировать и организовать.

Обсудим:

• Что такое API.

• Зачем версионировать API и нужно ли вообще.

• Какие способы версионирования существуют и как его организовать — и с точки зрения подходов, и с точки зрения кода.

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

Читать далее
Всего голосов 19: ↑19 и ↓0+19
Комментарии11

Итоги третьего ежегодного опроса PHP-сообщества (и по традиции — слон)

Время на прочтение7 мин
Количество просмотров7.8K

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

Удалось собрать 1215 ответов. Расспросили сообщество, на какой версии PHP сидят в командах, какой фреймворк выбирают для рабочих, а какой для личных проектов, многие ли посматривают на Go. И не только.

- Итоги 2021

- Итоги 2020

Читать далее
Всего голосов 43: ↑43 и ↓0+43
Комментарии3

Багоцид и Zero Bug Policy — как мы побеждали баги, а они нас

Уровень сложностиПростой
Время на прочтение9 мин
Количество просмотров5.2K

Кадр из фильма «Космический десант». Начало войны с багами.

Принцип такой: если баг обнаружен, то мы его либо исправляем в рамках SLA, либо сразу решаем, что фиксить не будем — когда это особенность продукта, тривиальная ошибка или стоимость фикса выше, чем последствия бага. Если исправление занимает больше нескольких часов или откладывается на конец спринта, должен быть точный запланированный срок, чтобы поддержка могла ответить клиенту не «мы в курсе, работы идут», а «мы в курсе, завтра в 17:30 починим».

Мы решили раскатить это на всю компанию.

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

Стало приятно и весело, но ненадолго. Эффект надо было сохранить.

Спойлер: у нас не вышло. Но прогресс есть.
Читать дальше →
Всего голосов 23: ↑23 и ↓0+23
Комментарии7

Измеряем команду с JIRA и Grafana: sprint reports, грейдирование и не только

Время на прочтение10 мин
Количество просмотров9.6K

Всем привет! Меня зовут Дмитрий Шкилёв, я тимлид команды Teachers Platform. Мы занимаемся личным кабинетом преподавателя и внутренними ресурсами, которые необходимы для обеспечения работы преподавателей. 

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

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

Читать далее
Всего голосов 14: ↑14 и ↓0+14
Комментарии21

Как багатон снизил нам количество багов с 900 до 950

Время на прочтение7 мин
Количество просмотров8.1K

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

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

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

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

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

Как вы уже можете догадаться по заголовку, кое-что пошло не так.
Читать дальше →
Всего голосов 37: ↑37 и ↓0+37
Комментарии15

Вышел PHP 8.2: разбираем главные изменения

Время на прочтение7 мин
Количество просмотров40K

Вместе с PHP-разработчиками Александром Макаровым (@SamDark), Валентином Удальцовым (@vudaltsov) и наставником Хекслета по PHP Владленом Гилязетдиновым (@funkylen) разбираемся, какие новые фичи появились в PHP 8.2, насколько эти изменения глобальны и какую роль в них сыграл проект РHP Foundation.

Эта статья — саммари стрима YouTube-канала PHP Point. Кстати, ежегодный опрос русскоязычного PHP-сообщества с итогами года запущен! Результатами поделимся в конце января.

Читать далее
Всего голосов 49: ↑49 и ↓0+49
Комментарии69

Ценный QA Automation – кто он на самом деле? Загадка от Жака Фреско

Время на прочтение7 мин
Количество просмотров11K

Всем привет! Меня зовут Иван и я Head of QA Automation в Skyeng. Я регулярно занимаюсь обучением Manual QA и менторством начинающих QA Automation (далее – QAA) и часто слышу от падаванов вопрос: «А как же мне, собственно, стать QAA?»

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

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

Однажды приходит осознание, что нужно расти. Но куда?

Читать далее
Всего голосов 9: ↑8 и ↓1+8
Комментарии4

Язык диаграмм

Время на прочтение6 мин
Количество просмотров13K
На проектах я часто вижу диаграммы от коллег. Это доносит техническую мысль. Проблема в том, что мы их рисуем как пойдёт, а у них есть стандарт и язык.

Мы часто изобретаем собственный язык, без знания которого диаграмма не считывается. Это системная проблема, даже архитекторы ею страдают. Например, я видел диаграмму, к которой авторы нарисовали легенду, чтобы сделать понятной для непосвящённых. Но всё учесть не смогли. Сидишь и думаешь: «Что значит эта стрелочка? Какое отношение между этими двумя сущностями?»



Задача передачи мысли от одного разработчика другому с помощью диаграмм стоит давно. Умные дяденьки не раз её обдумывали и изобрели специальный универсальный язык диаграмм — UML (Unified Modeling Language): это такой междисциплинарный способ рисования схем, который одинаково понятен всем, кто этот язык знает.

Расскажу, как с этим живётся на практике.
Читать дальше →
Всего голосов 36: ↑33 и ↓3+34
Комментарии14

Ретроспектива. Doin’ It Right

Время на прочтение12 мин
Количество просмотров6.7K

Привет! Меня зовут Лёша Дидух, я тимлид команды личного кабинета в Skyeng. Это текстовая адаптация моего доклада про ретроспективы на DUMP-2022 в Екатеринбурге. 

Когда я пришёл в компанию пару лет назад, то немножко обалдел от разницы в подходах к управлению проектами и командами между моей прежней работой и Skyeng. Такой скачок между диаметрально противоположными культурами заставил меня переосмыслить и собрать воедино всё, что я знаю о ретроспективах. Будет полезно и тимлидам, и юным скрам-мастерам, да и вообще любому, кто хотя бы раз сидел на ретроспективе и думал: «Что я здесь делаю?».

В конце статьи можно найти запись доклада по теме.

Начнем издалека (но не просто так)

В 2000 году влиятельные ребята из мира IT, среди которых были Роберт Мартин (автор принципов SOLID и огромного числа книг про программирование) и Джеф Сазерленд (один из авторов Scrum), встретились, чтобы, как говорит сам дядя Боб, лучше узнать друг друга в надежде, что тесное общение приведет к чему-то интересному. 

Читать далее
Всего голосов 17: ↑16 и ↓1+16
Комментарии0

Чем заменить New Relic: 11 альтернатив и наш выбор

Время на прочтение8 мин
Количество просмотров10K

Это лишь часть таблицы инструментов, которые мы рассматривали. Подробнее по ссылке.

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

Отказаться от New Relic хотели давно. Главная причина — он стал дорогой. Весной добавилась вторая причина — мы из России. Запереживали, что нас могут отключить. А мы в команде инфраструктуры стараемся все сервисы держать на своей стороне.

В августе закончился договор с New Relic, так что заранее стали искать ему замену. И вот, как оно было.

Читать далее
Всего голосов 26: ↑26 и ↓0+26
Комментарии16

Кризис рынка преподавателей английского: для чего там ИТ (ответ Хабру)

Время на прочтение7 мин
Количество просмотров4.9K


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

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

Ещё одна причина — это непрекращающийся дефицит хороших (и укладывающихся в понятие разумных цен) преподавателей. Их просто не хватит каждому! Мы и так вычерпали почти весь рынок подходящих преподавателей ещё в 2018 году, так в марте этого года спрос на изучение языка вырос ещё — и вырос сильно.

В общем, когда вы говорите, что у нас что-то не так — да, мы знаем, где автоматизация косячит. Но это достаточно малая цена в сравнении с невозможностью изучать язык или изучением его по учебнику без помощи человека.
Читать дальше →
Всего голосов 25: ↑23 и ↓2+23
Комментарии12

Делаем эффекты в видеосвязи, используя Canvas API и MediaPipe

Время на прочтение7 мин
Количество просмотров3.9K

Привет! На связи Влад из команды видеоплатформы Skyeng. Мы отвечаем за аудио и видео коммуникацию в образовательных продуктах, применяем WebRTC и реализуем фичи вокруг Video Conferencing. О реализации одной из них хочу рассказать: мы сделали видеоэффекты для веба.

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

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

Все сошлось. Решили делать.

Читать далее
Всего голосов 14: ↑14 и ↓0+14
Комментарии1

Как вообще можно управлять отдельными людьми в команде разработки?

Время на прочтение7 мин
Количество просмотров8.7K


Перформанс — это результативность команды. Начиная с этого места понятийный аппарат разваливается. Чтобы измерять результативность, нужно знать какую-то метрику. Метрика «строчки кода» определённо не подходит, а метрика «готовые фичи» измеряет продуктолога или команду, а не индивидуального разработчика. И вот этим «чем-то» ещё нужно управлять. Логика в том, чтобы разработчик разрабатывал нужное и с понятной скоростью, чтобы на него можно было полагаться в задачах.

Управлять можно, например:

  • Балансом между костылями и оверинжинирингом.
  • Балансом между тестированием кода и быстрой выкаткой на прод.
  • Балансом между техническим долгом и TTM.
  • Балансом между «пиши код» и «развивай своего джуна» и так далее.

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

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

Собственно, вот эта тонкая грань и есть перформанс-менеджмент.
Читать дальше →
Всего голосов 29: ↑26 и ↓3+25
Комментарии6

Как прокачаться в PHP: 70 ресурсов из опроса русскоязычного сообщества

Время на прочтение8 мин
Количество просмотров35K

В чаты по PHP часто приходят с вопросами про развитие: какие книги стоит прочитать в первую очередь, на какие каналы подписаться, какие курсы хороши. Если повезет, в ответ чат поделится парой рекомендаций. Мы решили агрегировать их в список и собрали 150+ мнений по актуальным ресурсам для PHP-разработчика. 

Без длинных интро. Самые упоминаемые ресурсы идут первыми в разделах, а те, которые советовали новичкам, отмечены флажком 🚩. 

Читать далее
Всего голосов 27: ↑24 и ↓3+29
Комментарии5

Наш опыт, как не надо растить тимлидов (не делайте как мы)

Время на прочтение11 мин
Количество просмотров31K


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

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

В общем, мы решили в этих условиях обучать своих тимлидов. Сейчас расскажу, что из этого получилось.
Читать дальше →
Всего голосов 41: ↑38 и ↓3+40
Комментарии13

Где именно лежит граница между зарплатными грейдами: как это устроено у нас

Время на прочтение9 мин
Количество просмотров23K


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

В итоге мы сделали опросник из 14 пунктов, по которому за несколько минут можно оценить себя. То же самое делает про вас тимлид, и если оценки совпадают, то всё отлично, есть грейд и зарплата в нём (у нас по три уровня внутри каждого грейда, например, джун-джун, опытный джун и джун 80-го уровня). Если оценки не совпадают — начинается процесс переговоров с приведением примеров для синхронизации по части оценки и ожиданий, чтобы потом на следующей итерации они всё-таки совпали.

Пока мы попробовали этот подход на 120 разработчиках. Выглядит многообещающе. Но я хотел бы показать вам сам опросник, детали системы и обсудить, насколько прозрачной получилась такая система. Дальше в посте — предпосылки её создания, разбор каждого из параметров и ссылка на форму, которая показывает результат по нашей системе грейдов.
Читать дальше →
Всего голосов 36: ↑31 и ↓5+31
Комментарии40

Как мы перевели операторов на единую платформу и стали закрывать по 240 тысяч задач в месяц

Время на прочтение11 мин
Количество просмотров5K

Так масштабировался сервис с марта 2020. Каждый цвет — группа операторов.

В Skyeng есть несколько отделов, которые сопровождают учеников. Например, отделы, отвечающие за входящую телефонную линию и техподдержку в чате на сайте. Есть группа Awake, работающая с учениками, которые брали перерыв в обучении. Есть группа Quality Control — она проверяет кейсы качества: например, что-то случилось на уроке и ученик оставил жалобу.

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

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

О жизни с внешними сервисами


Для работы с обращениями мы использовали такие системы как Usedesk, Omnidesk и Google Sheets. Это накладывало ограничения:

  • Операторам и менеджерам приходилось вручную создавать задачи. Такая рутина забирала много времени. Ошибиться проще простого.
Читать дальше →
Всего голосов 22: ↑22 и ↓0+22
Комментарии0

Функциональные тесты на проекте: жизнь до и после (на примерах)

Время на прочтение13 мин
Количество просмотров9.6K

Наша команда отвечает в Skyeng за личный кабинет и CJM пользователя до оплаты. Изначально проект был написан на Symfony 4.4 и представлял собой набор слабо связанных компонентов, которые были ответственны за правила работы для фронтенда.

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

У нас были лишь юнит-тесты: каждый покрывал логику одного класса. Все тесты вместе давали покрытие основной логики кода и гарантию, что все работает правильно. Но 100% покрытие кода тесты не обеспечивали. И сейчас не обеспечивают.

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

И мы обратились к функциональным.

Читать далее
Всего голосов 22: ↑22 и ↓0+22
Комментарии5

Информация

Сайт
job.skyeng.ru
Дата регистрации
Дата основания
Численность
1 001–5 000 человек
Местоположение
Россия
Представитель
Alisa Kruglova