Тимлид Леонид

2022-08-26 16:13:10 Привет!
Скоро закончится рубрика «СТО на каникулах» — ведь и лето подходит к концу. А пока делимся классной штукой про 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. Открыть/Комментировать

2022-08-16 12:52:29 Йо, кукусики
Снова выхожу на связь. Это Серёжа, Head of QA Skyeng. Решил поделиться знакомой QA lead\head болью.

За последний месяц дважды столкнулся с реальным непониманием тимлидов команд нашего требования — пускать QA на все синки.

Особое сопротивление с техревью. Как в классическом меме, аргументация часто сводится к: «Этот QA на ревью нам не нужОн!».

Конкретные пункты звучат так:

Да он ничего не поймет. Мы-то тут вон какие штуки делаем, а он максимум тесты пописывает.

Потом ему обязательно (нет) расскажем все тонкости. Смысл ему тратить время? Пусть задачки тестит.

Он будет нас отвлекать, а у нас по 3-4 задачи на ревью.

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

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

Почему на встречах важен QA?

Я бы сходу назвал несколько причин:

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

Если в силе сотрудника есть сомнения, его не стоит изолировать от команды. Лучше развивать или заменять. Задача крутого лида – создать условия, в которых сотрудники хотят причинить пользу продукту, не ждут очереди и не ограничивают себя на основе субъективных оценок.

Каждый инструмент и каждого сотрудника нужно задействовать так, чтобы он давал максимальную пользу за минимальную стоимость. При производстве стоимость ошибки растёт лавинообразно. Получить фидбек раньше и подумать лишние 20 минут над вопросами QA куда лучше, чем потом 5 часов переделывать.

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

А у вас есть такая проблема? Как зарешиваете в своих командах? Открыть/Комментировать

2022-08-12 17:05:08 Всем привет!
Завершим рабочую неделю еще одним постом про инфру

Инфраструктура часто является узким местом в разработке. До тех пор, пока инфра не создаст базу данных или репозиторий, разработчики не запилят новый сервис и не начнут зарабатывать деньги. В этом контексте важно перестать быть узким горлышком и максимально быстро выполнять запросы от разработчиков. Поделюсь, как мы решаем эту задачу в Skyeng.

С чего начать? Откажитесь от дежурства по очереди и выделите одного ответственного за поддержку, чтобы сотрудник точно был заинтересован в автоматизации работы инфры.

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

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

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

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

Итак, Service Desk внедрен и обращения максимально формализованы.

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

И последнее — строим аналитику, с какими запросами приходят чаще всего. Когда у вас появится аналитика и инструкции по работе с обращениями, автоматизация станет простым и понятным процессом: берете самые частые запросы и автоматизируете согласно инструкции.

Автоматизируйте и наслаждайтесь результатом! Открыть/Комментировать

2022-08-08 17:23:36 Привет!

Продолжаем рубрику «‎СТО на каникулах»‎. Сегодня я, Артем Науменко (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. Делитесь в комментах своими подходами. В следующий раз расскажу, как мы автоматизировали работу с инфраструктурой) Открыть/Комментировать

2022-08-03 17:58:06 Привет!

Как вырваться из рутины, вдохновить и сфокусировать команду на достижении долгосрочных целей? Самый простой путь – провести стратсессию

С чего начать
Сформировать запрос. Важно учесть мнение каждого участника команды, убедитесь, что все разделяют цели предстоящей встречи.
Сделать “домашнее задание”: что нужно изучить до стратсессии и подготовить ко встрече для погружения всех в общий контекст.
Составить детальный план проведения встречи. Идеальный тайминг – до 2 часов на блок.
Определить финальный результат. Как правило, это фокусы, цели или крупные проекты на ближайший год.

Сама стратсессия – это 3-4 дня активной работы:
День 1. Погружение участников в общий контекст, обсуждение ключевых проблем, вызовов. К концу дня все должны быть “on the same page” :)
День 2. Генерация целей, проектов, проблем и решений. Задача – войти в “зону стонов”, выкинуть лишнее, сформировать финальное видение стратегии.
День 3. Докрутка стратегии: определение результата в цифрах (KPIs, DoDs) и ответственных за достижений целей, а также за нерешенные вопросы.

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

Перед проведением стратсессии советую прочитать книгу “Руководство фасилитатора: как привести группу к принятию совместного решения” или посмотреть, как это делают профессионалы, например, Сергей Артюхов. Открыть/Комментировать

2022-07-22 13:38:22 Привет!

26 июля (вторник) в 18.30 заглядывайте на митап Avito для тимлидов, поговорим про насущное:

Чего ждут коллеги разных уровней от тимлидов? — доклад, а потом дискуссия, где будет участвовать Дмитрий Кузнецов, Dev Unit Lead Skyeng.

Во второй части — доклад про осознание себя в роли руководителя тимлидов. И следом тоже крутое обсуждение.

Где: онлайн на ютубе. Регистрация не нужна) Открыть/Комментировать

2022-07-20 18:06:38 Привет!

Я Deputy CTO Сергей Сафонов и сегодня расскажу, как мы в Skyeng регулярно оптимизируем расходы на инфраструктуру.

Зачем мы это делаем? Чтобы убрать неоправданные расходы и уменьшить затраты на инфру без ущерба качеству и стабильности. За множество итераций мы выработали 3 простых шага, которые помогают делать это эффективно

Анализ расходов в разных плоскостях: по дата-центрам, серверам, командам, функции (базы данных, кластер, очереди), нагрузке и т.д.
Выбор основных направлений для более глубокого анализа и проведение анализа.
Формирование задач и проектов, сведение их в единый роадмап.

А теперь к результатам) Вот часть изменений, которые в сумме с другими позволили сэкономить около 5% годового бюджета на инфраструктуру:

Увеличили среднюю пиковую нагрузку на кластер с ~15% до 60%
Сократили расходы на сервисы за счет отказа от сервиса, части функционала, сокращения пользователей или смены тарифа
Начали использовать прерываемые виртуальные машины в Yandex Cloud
Передали в команды с большими расходами задачу оптимизировать используемые ресурсы и затраты
Переехали с bare-metal серверов на k8s

На что еще можно обратить внимание при оптимизации расходов:
Переосмыслить целесообразность расходов с точки зрения актуальных потребностей бизнеса. Например, вы храните большое количество метаинформации, но у компании нет запроса на ее использование. Стоит ли тратить деньги на ее хранение?!
Обсудить цены с текущими партнерами и провести переговоры с другими поставщиками. Открыть/Комментировать

2022-07-07 16:10:02 Привет!

Как вообще управлять разработчиками (читай – интеллектуалами)? На этот вопрос нет простого и понятного ответа, а потому мы решили собрать в одну статью наш опыт и самые частые ошибки

Сейчас мы практикуем “управление результативностью”, потому что верим, что каждый человек вносит важный вклад в бизнес-результаты компании. И разработчики не исключение)

Читайте, критикуйте и делитесь своими подходами в управлении людьми в командах разработки Открыть/Комментировать

2022-06-23 13:01:22 Привет!

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

Так собралась статья про 70+ актуальных ресурсов для PHP-разработчика: книги, блоги, каналы с комментариями от организаторов сообществ и авторов крупных чатов. Списки проранжированы — самые упоминаемые ресурсы идут первыми в разделах.

Если у вас есть рекомендация, которая не вошла в список — делитесь в комментариях Открыть/Комментировать

2022-06-15 18:00:28 Привет!

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

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

Делитесь в комментариях своим удачным и не очень опытом работы с тимлидами. Нам это очень поможет, потому что мы все еще ищем ответ на вопрос – как делать хороших тимлидов и как правильно учить всю команду Открыть/Комментировать