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

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

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

Читать далее

https://habr.com/ru/post/714246/?utm_source=habrahabr&utm_medium=rss&utm_campaign=714246

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



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



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



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



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



Как вы уже можете догадаться по заголовку, кое-что пошло не так.
Читать дальше →

https://habr.com/ru/post/711304/?utm_source=habrahabr&utm_medium=rss&utm_campaign=711304

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

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

Читать далее

https://habr.com/ru/post/705194/?utm_source=habrahabr&utm_medium=rss&utm_campaign=705194

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

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

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

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

Читать далее

https://habr.com/ru/post/705190/?utm_source=habrahabr&utm_medium=rss&utm_campaign=705190

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

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

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

Читать далее

https://habr.com/ru/post/699980/?utm_source=habrahabr&utm_medium=rss&utm_campaign=699980

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

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

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

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

Читать далее

https://habr.com/ru/post/690602/?utm_source=habrahabr&utm_medium=rss&utm_campaign=690602

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



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



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



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

https://habr.com/ru/post/684336/?utm_source=habrahabr&utm_medium=rss&utm_campaign=684336

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

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

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

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

Читать далее

https://habr.com/ru/post/678068/?utm_source=habrahabr&utm_medium=rss&utm_campaign=678068

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



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

• Балансом между костылями и оверинжинирингом.


• Балансом между тестированием кода и быстрой выкаткой на прод.


• Балансом между техническим долгом и TTM.


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

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



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



Собственно, вот эта тонкая грань и есть перформанс-менеджмент.
Читать дальше →

https://habr.com/ru/post/669292/?utm_source=habrahabr&utm_medium=rss&utm_campaign=669292

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



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



В общем, мы решили в этих условиях обучать своих тимлидов. Сейчас расскажу, что из этого получилось.
Читать дальше →

https://habr.com/ru/post/668510/?utm_source=habrahabr&utm_medium=rss&utm_campaign=668510

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



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



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

https://habr.com/ru/post/667740/?utm_source=habrahabr&utm_medium=rss&utm_campaign=667740

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



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



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



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

https://habr.com/ru/post/666414/?utm_source=habrahabr&utm_medium=rss&utm_campaign=666414

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

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

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

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

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

Читать далее

https://habr.com/ru/post/659559/?utm_source=habrahabr&utm_medium=rss&utm_campaign=659559

«Бюрократия» — про обычные кадровые процессы. Мы в Skyeng всегда работали удалённо с основания. С ростом встала задача удобного поддержания HR-процессов, так как в ручном режиме поддерживать их стало невозможно: сотрудникам было неудобно и непонятно, а HR валился от количества заявок.



Что сделали:

• Продукт, где находятся все базовые запросы сотрудников. По нажатию пары кнопок можно получить все нужные справки, доступы, отметить отпуск, отгул или вообще оформить увольнение. То есть не надо ни с кем разговаривать. Каждое действие запускает набор скриптов, который создаёт все нужные задачи в Джире или автоматически оформляет все нужные документы.


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


• SLA на каждое действие. Как только есть описанный процесс — можно назначать ответственных и сроки. Теперь, если вам нужна какая-то бумажка от кадров, не вы заходите и спрашиваете, готово ли, а уже кадры должны уложиться в свои SLA, и у каждого шага есть ответственный.


• Бота, который в первые дни работы «ведёт» сотрудника.


• Автоматизацию микромоментов. Например, за день до ухода в отпуск в слаке проставляется соответствующий статус плюс у сотрудника становится видно в профиле, кто за него работает и по каким вопросам.

Знаете что? Получилось удобно!
Читать дальше →

https://habr.com/ru/post/656287/?utm_source=habrahabr&utm_medium=rss&utm_campaign=656287

Вы когда-нибудь встречали такие операторы, как materialize и dematerialize в RxJS? А что насчет класса Notification? Вероятно, многие слышали, но не до конца представляли, где их можно применить на практике.

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

Читать далее

https://habr.com/ru/post/661709/?utm_source=habrahabr&utm_medium=rss&utm_campaign=661709

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



У нас 12 тысяч учителей английского в Skyeng, и каждый из них имеет своё представление о том, как именно измеряется уровень ученика. Вводить единую методику и контролировать её выполнение на таком количестве человек не представляется целесообразным, но показывать ученику, где он находится и сколько ему потребуется для достижения цели, необходимо. Нужны были объективные метрики, которые можно было бы снимать в автоматическом режиме.



Поэтому я занялся большим почти научным проектом, начавшимся в 2017-м году и длящимся по сей день:

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


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


3. Наложил карту навыков на контент, чтобы каждое упражнение автоматически учитывалось в оценке прогресса (о, это было долго и сложно).


4. Провалидировал на тысячах внутренних тестов, не зависящих от системы оценки прогресса.


5. Заложил адаптацию для учеников разных языковых групп, поскольку родной язык ученика даёт ему какие-то навыки сразу, а какие-то делает очень сложными.


6. Семь раз усложнил, а после существенно упростил систему.

В итоге каждый урок моя система скорит каждому ученику баллы опыта в разные ветки навыков.
Читать дальше →

https://habr.com/ru/post/655729/?utm_source=habrahabr&utm_medium=rss&utm_campaign=655729

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

Читать далее

https://habr.com/ru/post/659849/?utm_source=habrahabr&utm_medium=rss&utm_campaign=659849