Привет! Перекинем мостик в 2022 и продолжим тему про инфру.

Меня зовут Артем Науменко. В Skyeng руковожу ИТ-инфраструктурой.

Недавно к нам в московский офис зашли в гости коллеги из ITGLOBAL. Расспросили, как Skyeng вырос в три EdTech-бренда, как строим нашу инфраструктуру, что по технологиям и какие планы на будущее. Заодно мы обсудили, как руководить большой распределенной командой и правильно обращаться с инцидентами, без которых жизнь инфраструктуры — не жизнь)

И, конечно, прогулялись по офису. Больше — в интервью по ссылке.

Привет!

На связи Виталий Леонов, СТО Skyeng.

Не секрет, что основная работа руководителя – это управление командой, и хороший менеджер всегда наполовину HR 😉

Что я вкладываю в управление людьми? В первую очередь, управление результативностью или performance management:
1. Формирование ожиданий: каких результатов сотрудник должен достичь, как это будет измеряться и какие компетенции для этого необходимы.
2. Составление плана развития: какие компетенции нужно развивать сотруднику для достижений целей, и как именно он будет это делать.
3. Работа над достижением результатов: здесь важен регулярный мониторинг и обратная связь.
4. Подведение итогов: оценка результатов сотрудника – что получилось хорошо, а чего достичь не удалось, а также корректировка трека развития.
5. Возвращаемся к 1 пункту и запускаем новый цикл!

Это и есть цикл управления результативностью: Plan-Act-Monitor-Review из замечательной книги “Performance Management. Key Strategies and Practical Guidelines” от Майкла Армстронга. Если вы хотите стать успешным руководителем, то не забывайте про свою команду :)

Делитесь в комментариях своими инструментами по управлению результатами команды 🚀

Всем привет!

Было довольно много вопросов после поста про перфоманс менеджмент, поэтому предлагаю продолжить диалог на эту тему 🙂

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

Самый надежный подход – описать ожидания в виде метрик. Например, увеличить покрытие автотестами на 10%, снизить отклик главной страницы до 100ms, снизить стоимость инфраструктуры на 5%.

К сожалению, не всегда можно измерить результат и не всегда под рукой есть необходимые метрики, в таком случае ожидания нужно зафиксировать в виде четко прописанного Definition of Done (DoD): набор критериев, по которым можно судить о результатах.

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

Делитесь в комментариях своими инструментами работы с командой 🚀

Привет!

Поговорим сегодня про второй шаг цикла управления результативностью: составление плана развития сотрудника.

Мы в Skyeng исповедуем философию lifelong learning – непрерывного обучения 🚀 Как это работает – через личный план развития (PDP), в котором личные цели или мечты человека синхронизируются с рабочими задачами.

Что важно учесть в PDP:
1. Составляйте план развития вместе с сотрудником так, чтобы в нем были учтены личные интересы человека и цели команды/компании. При таком подходе у сотрудника будет высокая мотивация в развитии и достижении результата.

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

2. Используйте “звездную карту компетенций”, чтобы сбалансировать знания и навыки в команде.

3. При составлении плана развития не забывайте про 3 типа навыков:
🔥Hard-скиллы – профессиональная экспертиза. Это те компетенции, ради которых мы берем программиста: умение писать хороший код, проектировать качественную архитектуру и т.д.

🔥Soft-skills – социальные навыки. То, как сотрудник подходит к своей работе: коммуникабельность, командная работа, тайм-менеджмент и пр.

🔥Личностные черты: характер, жизненные установки, ценности. Их практически невозможно изменить у взрослого человека, т.к. они "вшиты" в его личность. Если понимаете, что человек по своим личностным качествам не подходит вашей команде, то через развитие их не исправить.

Делитесь в комментах, используете ли вы PDP в своей работе или нет? И почему?

Всем привет!

Ну что ж, продолжим раскручивать колесо перформанс менеджмента 🎡

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

🔥если у сотрудника что-то не получается, тогда важно отстроить работу через обратную связь. Не забываем про основные правила фидбека: искренность, конкретность, своевременность, объективность и последовательность.

🔥если внешние условия изменились и не позволяют достичь заявленной цели, то ее нужно вовремя скорректировать. Как говорится "планы – ничто, планирование – всё".


Следите за балансом: чтобы не замучить сотрудника микроменеджментом, но и не бросить его на произвол судьбы. Действуйте гибко, например, для новичка в компании мониторинг может быть еженедельным или даже ежедневным, а для опытного бойца будет вполне достаточно пары синков в квартал. Определиться со стратегией управления поможет ситуационная модель лидерства Херси и Бланшара.

И конечно, обязательно хвалите людей за крутые результаты! Ведь успех компании созидается из успехов ее сотрудников 💪

Привет!

Сегодня завершаем небольшой экскурс по перфоманс менеджменту. Итак, как подводить итоги?! ✌️

Во многом это зависит от принятой в компании культуры оценки результатов сотрудников: от столь нелюбимого всеми Performance Review до более гуманной версии Talent Snapshot, который делает Spotify. Если общепринятой практики нет, то вполне подойдет встреча в формате 1-to-1.

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

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

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

🔥Если результаты достигнуты, то поблагодарите человека. Ведь искренняя похвала руководителя – отличный мотиватор для сотрудника.

А дальше запускаем следующий виток цикла: планируем цели, строим планы развития, мониторим прогресс, подводим итоги. И так шаг за шагом к достижению новых крутых результатов! 🚀🚀🚀

Привет!

А не поговорить ли нам про онбординг, друзья 😉

Есть такая замечательная метрика – Time to productivity (TTP). Это время от первого дня работы нового сотрудника до его выхода на максимальную эффективность. Чем меньше TTP, тем лучше!

Сокращение Time to productivity позволяет компаниям серьезно экономить. Например, зарплата ИТ-специалистов исчисляется сотнями тысяч рублей в месяц. Уменьшая время выхода сотрудника на полную производительность с нескольких месяцев до нескольких недель, вы высвобождаете внушительные финансовые ресурсы, которые можно направить на другие цели.

Но, как известно, дьявол кроется в деталях. В теории ТТР считается очень просто:
☀️ 1. Определите целевой уровень производительности сотрудников
☀️ 2. Посчитайте время от выхода новичка до достижения этого уровня
☀️ 3. Возьмите среднее значение по всем новичкам

Однако, на практике совершенно непонятно что такое целевой уровень производительности программиста и как его измерить. К счастью, Spotify предложил неплохое решение — измерять время до 10-го пул-реквеста. Да пул-реквесты бывают разными, у каждого разработчика свой подход к написанию кода и у всех команд свои особенности в работе с пул-реквестами. Но на большой выборке – 200 и более человек – вы увидите вполне релевантную картину.

Делитесь в комментариях, что вы думаете про Time to productivity и сталкивались ли с такой метрикой в своей работе? В следующий раз я расскажу о том, как мы измерили ТТМ в Skyeng и что из этого вышло ✌️

Всем привет!

24 февраля в мире случился “черный лебедь”, который оказал сокрушительное влияние на экономику России и все мировое сообщество. Мы осознанно взяли паузу, потому что говорить о привычных вещах было невероятно сложно, непросто и теперь, но мы попробуем начать.

Проблема “черных лебедей” в том, что предсказать такие события практически невозможно. Менеджменту остается лишь одно ー принимать ситуацию постфактум и гибко реагировать. Вопрос, который волновал и меня, и многих моих коллег – с чего начать?

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

📍Забыть про текущие долгосрочные цели и определить приоритеты в новых условиях – что важно сделать здесь и сейчас для сохранения устойчивости бизнеса.

Одна из первостепенных задач для Skyeng в первые дни и недели кризиса – обеспечить работоспособность продукта несмотря на отключение внешних сервисов. Наша команда инфраструктуры успешно справилась с этой задачей.


📍Не бояться сложных решений. Продолжать или заморозить плановое повышение зарплат? Увеличить ли цены на образовательные услуги из-за роста инфляции? Переходить ли со Slack на self-hosted решение? Запускать ли новые продукты или ограничиться поддержкой текущих? Это важные и сложные вопросы, ответы на которые необходимо было найти в условиях полной неопределенности.


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

Пожалуйста, делитесь в комментариях, какими были ваши первые шаги?!

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

Привет!

В конце февраля мы сделали пост про онбординг и измерение Time to productivity: что это и зачем нужно бизнесу. Но не успели рассказать про наш опыт, делимся сегодня.

Мы консолидировали данные с 2018 по 2021 год и проанализировали достигнутые результаты (на графике к посту отражено время от 1 до N-го пул-реквеста):
📍Целевой уровень производительности нашей команды – один пул-реквеста в 2 дня
📍Скорость выхода на этот уровень постоянно сокращается: если в 2018 году разработчику требовалось больше недели до решения первой задачи, то сейчас до 4 дней
📍Время с момента выхода на работу до 10-го пул-реквеста снизилось с 92 до 37 дней

Как мы этого добились? Секрет прост: мы шаг за шагом повышали качество онбординга новичков:
1. Консолидировали в формате коротких интерактивных роликов информацию о Skyeng, ее миссии и целях.
2. Создали чек-листы с документацией, подходами, фреймворками и инструментами, которые используются в компании. Во время онбординга сотрудник обязательно их изучает.
3. Внедрили систему наставничества. За каждым новичком закрепляется ментор и рекрутер, которые находятся в тесной связи с человеком и помогают в решении любых вопросов.
4. Договорились, что у каждого новичка будут четко прописаны цели на испытательный срок и критерии его успешного прохождения.
5. The last, but not the list! Мы постоянно прокачиваем Developer experience и делаем инфраструктуру максимально дружелюбной для разработки.

Эти усилия многократно окупились! Новички легче адаптируются в компании и выходят на максимальную эффективность в 2,5 раза быстрее, а стало быть раньше вносят ценный вклад в развитие бизнеса 💪

Привет!

Если вы хотите развиваться как технические руководители, то вам важно повышать свою насмотренность. Это удобно делать, читая статьи про опыт тимлидов в других компаниях. Подписывайтесь на канал моего бывшего коллеги Егора Толстого – 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.