Рубрика «Блог компании Skyeng»

image
Ачивка «Терминатор»: прибить проект, потому что проще заново

У нас есть внутренний продукт для оценки сотрудников. Он сменил три проджекта, три тимлида разработки, двух дизайнеров. Я была третьим проджектом в этой наследной цепочке.

Что пошло не так? Ну, в какой-то момент пришёл бизнес и сказал: чуваки, вот у нас замечательное ТЗ, его нужно сделать. Команда в первом составе собрала аналитику, прикинула список действий, заложила 15% времени на непредвиденное и приступила к разработке.

А в декабре бизнес сказал, что мы должны запуститься через месяц.

Мы катастрофически не успевали, стали выпускать поэтапно и седеть. В этот месяц родилось то, что мы очень вежливо называем MVP. Он был настолько прекрасен, что части бека выполнялись на фронте. Потому что фронтендер помогал, чем мог, и делал математику для обработки данных прямо в формах ввода этих данных.

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

Второй тимлид выгорел и уехал в условный Гондурас.

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

Короче, мы посовещались и пристрелили к чертям весь проект.

Мечта была в том, чтобы написать его заново.Читать полностью »

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

Вместе с PHP-разработчиками Александром Макаровым (@SamDark), Валентином Удальцовым (@vudaltsov) и наставником Хекслета по PHP Владленом Гилязетдиновым (@funkylenЧитать полностью »

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

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

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

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

Расскажу, как с этим живётся на практике.
Читать полностью »

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что смотрели и читали по PHP в 2021: список от сообщества - 1

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

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

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

Мы учим не только английскому, но и математике, и другим предметам. Вдруг выяснилось, что для ряда занятий нужно собирать больше 10 человек, и при этом нужно иметь возможность разговаривать с каждым. Понятно, что учителю можно дать толстый канал в 1 Мбит/с, а ученикам — каналы потоньше: в 144p или 240p, например, но всё равно квадратичный рост трафика выглядел угрожающе.

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

Вы же тоже хотите посмотреть, как быстро он упадёт, да?
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js