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

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

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

И если вы подумали: «Эта ваша мораль и этика вовсе не про бизнес, а мы тут деньги зарабатываем», у меня для вас новости.

Инклюзивность — это действительно +100500 к карме, а еще способ сыграть на метриках и получить прибыль. Как? Погнали читать!

Привет! Меня зовут Наташа Красильникова, я старший аналитик команды Operations Analytics в Skyeng. Мы завязаны на работе с сотней сервисов компании: забираем данные из сервисов и интегрируем много локальных документов с бизнесовыми маппингами, таргетами, а иногда и просто какими-то дополнительными данными.

Когда пришло время мигрировать наше многолетнее легаси на новый DWH… что ж, мы пережили целый спектр острых эмоций. И, конечно, выработали ноу-хау, чтобы сгладить переход и сделать его менее болезненным. В статье расскажу, что придумали и как применяли.

Привет! Меня зовут Олег Мифле. Одной из команд, где удалось поработать за 7 лет с PHP, стала Customer Support. Мы автоматизировали анализ тысяч задач в день и оператору больше не нужно думать и включать голову для того, чтобы понять, какая задача прямо сейчас важна. О том, как работает приоритизация и что такое дерево игры, расскажу в статье.

На старте погружу в предметную область. Она непростая, но постараюсь быстро. Эта статья по моему докладу с PHP Russia 2022. Вот запись.

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

Обсудим:

• Что такое API.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Операторам и менеджерам приходилось вручную создавать задачи. Такая рутина забирала много времени. Ошибиться проще простого.

В июне этого года наш онлайн-университет выпустил первый поток студентов по системе ISA (Income Share Agreement), а на днях — уже второй. Ребята бесплатно обучались профессии «Инженер по тестированию» и получили помощь в трудоустройстве. Однако есть нюанс: за все это они должны будут платить в течение двух лет 17% от зарплаты, но только если она превысит 50 тысяч рублей.

Мы встретились со Светой Шиманской, руководителем программ ISA в Skypro, и узнали, каково это — платить за студентов из своего кармана и брать на себя ответственность за их трудоустройство. В статье расскажем о первых шагах проекта, ошибках и выводах, которые помогут нам сделать следующие потоки лучше. 

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

Если вам знакомы описанные выше синдромы, можем вас поздравить (а точнее, посочувствовать), вы заработали себе синдром эмоционального выгорания — бич 21 века и одно из самых страшных ментальных расстройств профессионального работника.

А как хорошо всё начиналось…

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

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

Ручные тестировщики и начинающие автоматизаторы из компании часто спрашивают у меня, как им определиться с дальнейшим развитием. Я выделил 7 проблем, с которыми сталкивался сам, постарался рассказать, как боролся с ними и как можно обратить некоторые из своих слабых сторон на пользу себе и окружающим. Учиться на своих ошибках — хорошо, а на чужих — еще лучше. Надеюсь, мой рассказ поможет вам пойти вторым путем :)

Знакома ситуация, когда работа с документами в компании превращается в игру "Что? Где? Когда?" с непредсказуемым результатом? Внедрение электронного документооборота (ЭДО) раньше, чем бумажные процессы начнут тормозить бизнес - не самая тривиальная задача. А в условиях карантина и тотальной "удаленки" сотрудников она становится гипер-сложной!

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

Конечно, в какой-то момент инциденты вышли за пределы наших команд, и мы задумались о едином подходе работы с ними. Ответственным за процесс организации оказался я — Дима Кузнецов, один из юнит-лидов в Skyeng. Так в декабре 2019 года мы создали MVP этого проекта, и к TechLead Conf 2020 получили первые результаты, о чем я и рассказал на конференции. Сегодня я опишу, каким был процесс и что мы получили в результате.

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

Но на практике, мы не всегда умеем. Боимся испортить отношения с теми, кто круто перформит, но не очень софтскилловый. Возможно, как-то выдали критику и она сработала не в ту сторону. Я изучил порядка 30 моделей, выбрал самые, на мой взгляд, понятные - о них и пойдет речь. 

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

Давайте отбросим эмоции. И посмотрим, что можно быстро предпринять, чтобы облегчить страдания.