Привет!

Если вы хотите развиваться как технические руководители, то вам важно повышать свою насмотренность. Это удобно делать, читая статьи про опыт тимлидов в других компаниях. Подписывайтесь на канал моего бывшего коллеги Егора Толстого – Techlead Good Reads. Каждый день он публикует один материал про управление людьми, процессы или фреймворки. Вот подборка классных материалов из канала за последнее время:

📌Лоу-перформеры не всегда бездельники
📌Таблица грейдов для инженеров выше senior
📌Принципы обеспечения качества в GitLab
📌Почему сеньоры не добиваются успеха в компаниях
📌Алгоритм работы с командой в кризисный период
📌Рекомендации тимлидских книг

Всем привет!

Прочитал замечательную книгу консультанта и бизнес-тренера Александра Фридмана "Вы или вас. Профессиональная эксплуатация подчиненных"

В книге автор описывает 4 типа операционного менеджмента для эффективного корпоративного управления:

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

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

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

📍Регулярный менеджмент. Все, что делается — записано, все что записано — делается. Постановка задач, контроль, методики выполнения, система поощрений и наказания формализованы и внедрены. Системность в процессах приводит к предсказуемости результатов, быстрому масштабированию, прозрачности процессов для всех участников. Обратная сторона медали — низкая гибкость и скорость реакции в условиях высокой неопределенности.

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

Привет!

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

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

📘🐘 Если у вас есть опыт в PHP или вы готовы отправить ссылку коллегам — вот опрос. Всего 3 пункта, займет пару минут.

Результатами поделимся на phpcommunity.ru и в статье на Хабре.

Привет!

В Skyeng мы стремимся принимать решения на основе данных. Если в управлении продуктами этот подход широко распространен – проведение А/В тестов, сбор продуктовых метрик, исследование клиентов и т.д., то в разработке дела обстоят иначе)

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

Однако, любое упоминание о метриках в среде разработчиков вызывает у коллег тревожность. Дескать, если начали собирать метрики, то они попадут в личные KPI, а стало быть придется ломать голову над достижением “красивых” цифр в отчете.

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

Ключевое слово здесь оценивать, т.к. любая метрика никогда не будет точной на 100%. То, что при закрытии старых задач у какой-то команды вырастет Lead Time не говорит о том, плохо это или хорошо. Она лишь объективно показывает ситуацию в команде, а уже тимлид будет решать, стоит ли что-то менять в процессах или нет.

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

Лично мне поменять майндсет в этом направлении помогли эти книги:
1. Как измерить все, что угодно. Оценка стоимости нематериального в бизнесе
2. Статистическое управление процессами. Оптимизация бизнеса с использованием контрольных карт Шухарта

Надеюсь, и вам пригодится 💪

Привет!

Команда разработки Slack выложила отличный разбор своего инцидента, произошедшего 22 февраля.

Если кратко, то суть в следующем: обновление Consul привело к сбросу кэша, что стало причиной беспрецедентно высокой нагрузки на БД неоптимальными запросами. Настоящий эффект бабочки — обновление версии софта вызвало взрывной рост нагрузки.

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

Какие выводы я сделал из этого разбора:
✒️ 1. Невозможно предусмотреть и закрыть все возможные отказы в таком крупном проекте как Skyeng. Инцидент может случиться где угодно, когда угодно и почему угодно.
✒️ 2. Нужно больше уделять внимания инструментам, которые позволят быстрее узнавать об инцидентах и их митигировать: чувствительные мониторинги, детальные логи, подробные Disaster Recovery Plan и команда дежурных, готовых отработать инцидент 24/7.

Привет!

19 мая Skyeng примет участие в митапе по мобильной разработке Ozon Tech Mobile Meetup.
Артем Новичков из Skyeng расскажет, как работает новая модель многопоточности, и на примерах разберет, что нового появилось в Swift и как это подружить со своим кодом.

А также Александр Свиридов из Ozon расскажет, какие метрики собираются и как ребята борются за перформанс приложения и Владимир Шедько презентует, как в Ozon делали плавный скролл для нагруженного UI.

Регистрируйтесь по ссылке и подключайтесь 19 мая в 18:00.

Привет!

А мы снова с митапами🙂
На этот раз мы участвуем в Avito Analytics meetup #6 вместе со спикерами из Яндекс Маркета и Авито. Евгения Дубровина из Skyeng поделится нашим опытом работы со сплит-тестами на разветвлённой клиентской базе с многоэтапной воронкой.

А еще в программе огненные доклады про оценку медиамаркетинговых кампаний и оптимизацию юнит-экономики экспресс-доставки.

Регистрируйтесь по ссылке и подключайтесь 24 мая в 18:00.

Всем привет!

На прошлой неделе прошла конференция TeamLead Conf, где было много крутых докладов про управление командами, мотивацию и развитие сотрудников, оптимизацию процессов и многое другое 🚀

Мое выступление было о том, как построить people management на данных и сократить текучку в IT. Делюсь ключевыми поинтами)))

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

В случае с текучкой, мы собрали данные об уходе сотрудников в IT-команде за год – в январе 2021 показатель составил 38% – и измерили его в деньгах. При этом перенаем одного инженера на тот момент стоил компании ~1.3млн руб. Таким образом, высокая текучка айтишников обходилась бизнесу в сотни миллионов рублей в год. Проблема провалидирована, надо решать.

🍀 Дальше важно провести анализ, чтобы понять первопричины проблемы. В рамках борьбы с текучкой мы взяли данные из опроса вовлеченности, показатель eNPS и разбили их по командам. Так мы увидели ключевые факторы, влияющие на показатель – недостаток обратной связи от руководителей и непрозрачные карьерные возможности для сотрудников.

🍀 Выработка решений. Пожалуй, главная рекомендация на этом этапе – направлять свой ресурс именно в те причины, которые оказывают наибольшее влияние на проблему и не распыляться на остальные. Для борьбы с текучкой мы реализовали несколько инициатив: запустили курсы по обратной связи для руководителей, внедрили прозрачные карьерные треки для инженеров, провели интенсивы по составлению PDP (персональный план развития) среди тимлидов, провели грейдинг команды и составили для каждого планы по развитию.

🍀 Этап, про который очень часто забывают. Перепроверьте, что ваши усилия были не напрасны и проблема решилась.

Какие результаты мы получили:
📌вовлеченность выросла на 4%, в частности пункт про карьеру увеличился на 11%,
📌 eNPS вырос на 7,5%,
📌 ну и самое главное, годовая текучка упала на 30%.

Profit 💪

Ребят, и оффтопом немного про ближайший викенд)

Эти выходные у многих пройдут под лейтмотивом конференции CodeFest в Новосибе) Skyeng тоже в ней участвует, заходите послушать доклады и познакомиться!

Завтра (28 мая) в 11.00 я – Виталий Леонов – буду открывать секцию Management, расскажу о том, как построить приборную панель тимлида, все оцифровать и спать спокойно. Приходите поддержать и буду рад со всеми пообщаться в перерывах между треками.

29 мая в 11.00 Head of Mobile Platform Слава Слуцкер расскажет про SwiftUI + Combine и как же все же начать писать простой и тестируемый код.

Привет! Меня зовут Сергей Никифоров, я руководитель гильдии QA внутри компании Skyeng.

За свою историю в QA я провел сотни собеседований, как на QA/QAA разных уровней, так и на QA Lead (далее – QL). Помимо этого, мы помогали прокачивать курсы по QA в Skypro (наши курсы про #войтивайти), создали собственную платформу стажировок, систему грейдирования и программу обучения по автоматизации.

Не поверите, но понять уровень профессионализма специалиста вам поможет ответ на один простой вопрос: Скорость или качество?

Почему именно этот вопрос? Давай копать 😎

Этот вопрос одновременно отражает знание процессов управления разработкой продукта, показывает опыт человека в решении конфликтов и отстаивании своей точки зрения. Почти всегда – 20 из 24 QL – выбирали один из вариантов, большинство голосовало за «качество».

При попытке объяснить выбор, на меня часто смотрели как на дурака и выдавали аргументы про:
📍Ну, я QL, я про качество.
📍Кроме меня никто на качество смотреть не будет, а качество важно, я должен его контролировать
📍Наш клиент должен получать качественный функционал, это самое важное.

Бесспорно, бывали и варианты про приоритет скорости:
📌 Мы должны следить за качеством, но не мешать своей работой разработке и бизнесу
📌 Качество важно, но мы не влияем на сроки, сказали быстро — делаем быстро
📌 Если у нас спринты, то мы должны успевать, а баги править будем позже

И в том, и в другом случае проблема одна — QL/QA не видит своё влияние на весь процесс. Для него работа в команде это постоянное противостояние между командой «скорости» (чаще всего — разрабы и их тимлид) и «качества» (QA и QL), которые на протяжении 457 серий делают продукт. Это приводит к тому, что человек чаще всего работает с процессами в рамках только этапа тестирования и не думает о счастье пользователя.

Так, а какой ответ верный, спросите вы? А об этом мы поговорим завтра, друзья, не переключайтесь😊

PS. Делитесь в комментах своими подходами 💪

Привет!

Итак, возвращаемся к теме «Качество vs скорость». Каким же должен быть ответ на этот вопрос?!

Важно, чтобы QA/QL сказал, что «скорости не бывает без качества» и сможет это аргументировать, например, так:
🍀 Хорошие процессы приводят к хорошим решениям, которые легко разрабатывать (тестирование требований, груминг, исследования)
🍀 Качество — это и поставка нового крутого функционала в сжатые сроки. Клиент должен быть доволен сроками появления фич или исправлением неудачных решений.
🍀 Можно сделать быстро и некачественно, но исправление ошибок тоже жрет время, а следовательно итоговое решение придет все равно позже
🍀 Я должен влиять на сроки, ускоряя производство через качественные процессы, а полученное время команда может использовать для новых задач, рефакторинга и т.д.

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

Привет!

Мы продолжаем рубрику “СТО на каникулах” и сегодня я, Сергей Никифоров, Head of QA, расскажу, как мы в Skyeng боремся с багами и каких результатов удалось достичь🚀

Если у вас рабочий zero bug policy или lead time от создания до закрытия всех багов меньше недели – перематывайте, вы и так все знаете!

3 года назад для Skyeng нормальным явлением было 5000 багов в бэклоге, и этот тренд уверенно рос. Это нормально для всех стартапов и компаний, где нет иной ценности кроме скорости.

Чаще всего пренебрежение бэклогом сознательное и на то есть несколько причин, давайте назовем их всадниками багоапокалипсиса:
📍 Лень: чем меньше делаешь, тем лучше.
📍 Гордость: баги не мои и вообще такой ерундой разработчик заниматься не хочет.
📍 Отстраненность: ощущение непричастности к продукту и что исправление 1 бага не изменит положение вещей.
📍 Недальновидность: обязательно исправим, но потом.

Давайте разбираться, что и как можно сделать с каждым всадником.

🔥 Лень. Самый коварный противник, но мы его победили. И вот почему: значительную часть багов в core сервисах мы не решали как баги. QA “вспоминали” про их существование при планировании фичи, аргументируя это тем “слушай, ты же все равно полезешь в N, там вот еще это не работало, тебе быстро будет поменять”. И действительно, формулировка “раз ты всё равно полез, поправь попутно” работает лучше, чем отдельно стоящий bug в трекере, который отображается на доске.

Такое поведение создает привычку отдавать готовый продукт и меньше использовать костыли, плюс усиливает code review (ребята сами начинают подсвечивать проблемные зоны без QA друг-другу).

🔥 Гордость. Для большинства крутых разработчиков исправление багов не является интересной задачей. Им хочется запускать ракеты в космос, спасать принцесс, что-то делать с драконами, вот это вот всё.

Этот “всадник” отлично побеждается соревновательным элементом. Введите обязательные политики по жизни багов, SLA по их выполнению и сравните команды между собой, чтобы сильные дяди могли помериться своей силой)

Главное, чтобы все правила задавались “извне”, а не навязывались одной команде другой, чтобы все были в равных условиях.

Завтра поговорим про отстраненность и недальновидность, а также я расскажу, чего мы достигли, выиграв бой у всех “всадников”. Пока делитесь в комментариях своими всадниками багоапакалиписиса 😅

Привет!
Итак, как мы сражались с остальными всадниками.

🔥 Отстраненность. Чаще всего этим “недугом” страдаю команды, у которых разработка идет более 2-х лет. Эйфория от “запуска” уже давно прошла, задачи стали рутинными, а баги на вентилятор продолжают падать.

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

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

Здесь важно посчитать урон он тех багов, которые должны быть действительно исправлены и договориться об итерациях определения “уровня сервиса” для ваших команд. Условно, это выглядит как ступеньки, по которым команда проводит продукт, например от большего к меньшему:
Продукт работает, мы можем упасть, но быстро поднимемся
Пользователи сталкиваются с проблемами, но мы не можем упасть
Люди пользуются с удовольствием, редко сталкиваются с проблемами и получают быстро решение
На рынке нет более крутого продукта

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

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

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

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

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

К каким же результатам мы пришли в Skyeng:
🍀 количество багов в беклоге снизилось с 5000 до 1300 по всем продуктам и проектам. Это до сих пор непозволительно много, но динамика положительная :)
🍀 Появились SLA (срок жизни бага в днях/часах), в которых участвуют команды разработки на фикс багов, мы можем прогнозировать и сообщать пользователям примерные сроки решения проблем.
🍀 Про наш инцидент-менеджмент можно почитать здесь, он тоже помогает в решении пропущенных багов и их скорейшего исправления
🍀 В некоторых платформенных проектах подкрадываемся к Zero Bug Policy. Пока больно, но мы обязательно к этому придем.

Безусловно, эта история про то, что мы смогли пропустить, но мы работаем над тем, чтобы ничего не пропускать 😜

Привет!

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

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

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

Привет! 📚

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

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

Если у вас есть рекомендация, которая не вошла в список — делитесь в комментариях ✌️

Привет!

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

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

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

Привет!

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

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

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

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

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

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

Привет!

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

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

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

Где: онлайн на ютубе. Регистрация не нужна)

Привет!

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

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

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

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

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