🎉 Сегодня особенный день! У меня день рождения, и ещё один маленький праздник в нашем сообществе: нас уже больше 100 подписчиков!

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

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

Двигаемся дальше! 🚀

🎯 Performance Review и оценка 360: как с этим работать?

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

🔍 Что такое оценка 360?
Это процесс, в рамках которого сотрудник получает обратную связь не только от своего руководителя, но и от коллег и подчинённых. Цель — получить разносторонний взгляд на эффективность и зоны роста.

Преимущества:

Объективность. Разные перспективы позволяют снизить субъективность оценки.
Развитие soft skills. Коллеги подчеркивают, как сотрудник работает в команде, коммуницирует и решает конфликты.
Пространство для роста. Это помогает лучше понять свои сильные стороны и области для улучшения.
Сложности:

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

📊 Грейдирование: это эффективно?
Многие компании используют грейды как основу для выравнивания зарплат и карьерных возможностей.

Плюсы грейдов:

Прозрачность. Сотрудники понимают, какие навыки и опыт необходимы для продвижения.
Мотивация. Возможность перейти на новый уровень часто стимулирует развитие.

Минусы:

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

🛠 Как максимально использовать оценку?
1️⃣ Воспринимайте обратную связь как подарок. Даже если что-то звучит неприятно, это возможность понять, как вы выглядите со стороны.
2️⃣ Фокусируйтесь на конкретных действиях. Вместо абстрактного «нужно улучшить лидерские качества», ищите примеры и зоны применения.
3️⃣ Постройте план развития. Свяжите результаты оценки с вашими карьерными целями.

💬 А как у вас в компании проходят оценки? Есть ли у вас грейдирование или оценка 360?

Как изменился найм в QA за 10 лет?

В 2013 году, когда я только начинал свою карьеру, войти в тестирование было просто. Достаточно было прочитать книгу Романа Савина «Тестирование dot com», и можно было начинать работать. Тогда курсов и программ по QA было минимум, а вакансий хватало для всех, кто готов был разбираться в новой сфере.

Сейчас всё иначе. Обилие курсов и агрессивная реклама быстрого входа в IT привели к тому, что рынок наводнили начинающие тестировщики. Кажется, что попасть в профессию стало легче, но по факту требования только выросли, а вакансий для джунов меньше, чем желающих.

📌 Сейчас я сам нахожусь в поисках Junior Manual QA. Если у вас есть знакомые, кому это может быть интересно — делитесь вакансией!

👉 Ссылка на вакансию

ИТ-рынок: от хаотичного найма к точечному подходу

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

📉 Что происходит?
Компании начали пересматривать свои подходы: оценивают эффективность проектов и больше не держат внутри команды ради самого факта их существования.

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

⚡️ Чего ждать дальше?
Вероятно, мы увидим возврат к аутсорсинговой модели:
✔️ In-house команды будут становиться компактнее и сфокусированными на стратегии и ключевых продуктах.
✔️ Аутсорсинг возьмёт на себя точечные доработки, вместо того чтобы генерировать поток новых «продуктов ради продукта».

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

Сказка о потерянном времени

Жила-была команда в одном Scrum-государстве. И поручили ей создать новый сервис. Ребята взялись за дело, писали-писали, тестировали-тестировали, обсуждали архитектуру... И вот уже дедлайн стучится в дверь!

Казалось бы, вот он — результат. Только вот нефункциональные требования никто на камне не высек, а в документации и вовсе не прописал. 🤷‍♂️

Тут позвали владыку сервиса, дабы одобрил труды.
Пришёл заказчик, слушает команду:
— А если кеширование побольше сделаем, ошибок станет меньше!

А заказчик вдруг глаза округлил:
— Какое кеширование? Нам же real-time нужен был с самого начала!

И тут команда скручинылась… А их сервис так работать не может.

Так и ушли девять месяцев работы в никуда.

Конец. А кто слушал — молодец! 😌

⚡️ Мораль
Вывод здесь каждый найдет для себя сам.

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

🔥 Как мы превратили хаос в план: моя история о квартальном планировании

Когда-то давно я столкнулся с абсолютным хаосом в квартальном планировании. Задачи поступали в последний момент, без проработки, без оценки – просто список хотелок, который прилетал команде уже после начала квартала. Это был бесконечный стресс: приходилось срочно разбираться, пытаться оценить объем работ, а иногда просто брать задачи "на глаз", чтобы хоть как-то двигаться вперед.

Мы решили, что так продолжаться не может. Вместе с командой выработали четкий регламент:
✅ Дедлайны на подачу задач – к началу квартала все уже проработано.
✅ Обязательная декомпозиция и оценка – никакого «разберемся потом».
✅ Выбор задач заказчиком – есть емкость, есть оценки - берем столько сколько сможем унести.

💡 И это сработало. Появилась прозрачность, спешка снизилась, качество решений выросло.

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

🎯 Поэтому я хочу делать воркшопы, которые реально решают проблемы процессов.

Расскажите, с чем сталкиваетесь в своей работе? Где в вашей работе хаос, который мешает работать эффективно?
👉 Напишите пожалуйста в комментариях или спросите у коллег – ваши ответы помогут мне сделать воркшопы полезными и применимыми.

📢 Будет круто, если поделитесь этим постом! Чем больше мнений, тем лучше я пойму ключевые проблемы. Спасибо!

Вопрос доверия
Мне кажется, что доверие — одна из важнейших вещей в жизни. Но поскольку я менеджер и QA, расскажу историю из своей практики.

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

🛠 Качество кода было высоким, но кто работал с UI-тестами, тот знает, насколько они капризны. В какой-то момент мы столкнулись с проблемой:
✅ Тесты есть
🔄 Тесты запускаются
⚠️ Но если что-то падает — то оно всегда падает...

Мы оказались в ситуации, когда к автотестам не было доверия.

Как мы это исправили?
1️⃣ Подключили Allure Report и начали сохранять историю запусков.
2️⃣ Запускали тесты ночью многократно, собирая статистику и выявляя нестабильные сценарии.
3️⃣ Стабилизировали тесты, снизив количество флапов в несколько раз. Даже у нестабильных тестов вероятность прохождения стала выше 90%.
4️⃣ Добавили 3 перезапуска, чтобы минимизировать ложные срабатывания.

Но самое сложное — это изменить восприятие тестов внутри команды.

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

📢 Национальная система подтверждения ИТ-компетенций в России: почему это плохо?

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

🔴 1. Государственная бюрократия и качество тестов
Все мы знаем, как работают государственные ИТ-проекты. Вспомните ЕГЭ, госзакупки или «Госуслуги» в первые годы. Насколько объективными будут тесты? Кто будет их составлять? Как часто будут обновлять материалы? Можно ли считать серьёзным экзамен на Python, который проверяет «Что выведет print(1+1)?»?

🔴 2. Один сертификат ≠ реальные навыки
Компании, нанимающие ИТ-специалистов, и так проводят тестовые задания, собеседования, проверяют код на GitHub. Будут ли работодатели доверять сертификатам с гос-платформы? Или они станут просто бумажкой, которой можно похвастаться в резюме, но без реальной пользы?

🔴 3. Ограниченный срок действия — способ загнать в систему
Сертификат будет действовать всего год. То есть, если вы не перетестируетесь — ваше подтверждение аннулируется. Это сделано для актуализации знаний? Или чтобы обеспечить стабильный поток «клиентов» в систему?

🔴 4. Возможно ли давление на работодателей?
В России уже были инициативы по «государственной сертификации» сотрудников. Что, если через пару лет скажут: «Без этого сертификата вас не примут на работу»? Это не теория заговора, это реальность регулирования в других сферах.

🔴 5. А что дальше?
Если государство берётся за контроль ИТ-компетенций, то что помешает через пару лет ввести обязательную аккредитацию специалистов? Превратится ли работа программиста в лицензионную деятельность с бюрократией?

❓ Что думаете? Станет ли это инструментом для реальной оценки знаний или ещё одним бюрократическим барьером?

Что будет, если не давать обратную связь?

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

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

И тут меня осенило: ведь в работе происходит то же самое.

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

Я преподаю курс "QA Lead" в OTUS, где начинающие менеджеры учатся этому навыку. После каждого вебинара у них есть возможность оставить фидбек, но из 30+ человек его дают единицы.

🔹 Обратная связь – это навык.
🔹 Это инструмент управления.

Если её нет, то:

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

Тренируйтесь давать обратную связь везде, где это возможно:

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

💡 Чем больше качественной обратной связи в команде, тем быстрее она развивается. Начните с себя – и увидите, как вокруг всё начнёт меняться.

Как деление на команды «встряхивает» процессы и почему это не страшно

Сейчас в моей текущей компании снова идёт «разделение» людей на разные команды. Для кого-то это может быть стрессом, а мне всё это уже знакомо — в DealerSocket мы делали подобное раз в 9 месяцев. Постоянно нанимали новых специалистов, и каждые полгода-год возникала необходимость «переформировать» составы.

🚀 Что было в DealerSocket

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

✅ Команды не засиживались
Когда в команду вливается 1–2 новых человека, они приносят свои наработки и опыт. Происходит «мини-встряска».

✅ Люди старые, а энергия новая
Первый месяц после ротации — адаптация, зато потом команда оживает в обновлённом драйве. Это все еще те же люди в компании, но атмосфера изменилась и это придает новый импульс.

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

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


⚙️ Важные моменты

🔹 Планируйте заранее
Заранее определите, какие команды будут переформированы и зачем. Заранее сообщите людям, чтобы они понимали, что их ждёт и как это улучшит работу.

🔹 Собирайте обратную связь
Узнайте, кто в команде давно «пересидел» и кому, наоборот, хочется сменить обстановку. Так вы сможете "перезапустить" конкретных людей.

🔹 Давайте время на притирку
Первое время не ожидайте максимальной эффективности: людям нужно привыкнуть к новым коллегам и процессам. Запланируйте этот «стартовый» период в спринтах.

🔹 Сохраняйте культуру и ритуалы
Переносите существующие Scrum-ритуалы, доски и правила в новую конфигурацию — это даёт командам ощущение преемственности и снижает хаос.

🚀 4-дневная рабочая неделя — миф или будущее?

📊 Исследования говорят, что 4-дневная рабочая неделя снижает уровень стресса и повышает продуктивность. Проверил на себе — подтверждаю. ✅

📅 На прошлой неделе у меня случайно получилась 4-дневная рабочая неделя. И знаете, что? Это был кайф. 😌

За три выходных я успел не просто отдохнуть, но и сделать все накопившиеся дела. Обычно двух дней мне едва хватает на бытовые задачи, а тут — полноценное восстановление.

Что с продуктивностью? Все задачи, которые требовали от меня 5-дневной недели, я закрыл без проблем. Это заставляет задуматься: а так ли нужны нам эти пять дней работы? 🤔

А теперь вопрос к вам: вы бы пожертвовали 20% зарплаты, чтобы работать 4 дня в неделю? Или это того не стоит?

Давай обсудим в комментариях! 👇

🖼 Фото из поездки, где я отлично провел выходные.

📌 Почему в стрессе сложно учиться (и как это влияет на работу)

На этой неделе было много стресса, не связанного с работой. Решил послушать лекцию, но… вообще ничего не понял. Мысли перескакивали, внимание рассеивалось, а информация просто не усваивалась.

В этот момент вспомнил фразу преподавателя по менеджменту:
👉 «Когда мы в стрессе – мы не учимся».

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

Где это ещё работает?
✅ Онбординг сотрудников – не перегружайте новичка в первые дни. Сначала комфорт, потом детали.
✅ Обучение – если человек завис, возможно, дело не в сложности, а в его состоянии.
✅ Работа с командой – в кризисные моменты важнее поддержка, чем новые знания.


Всем хороших выходных и поменьше стресса.

🚀 Начинаю консультировать и проводить вебинары!

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

1. Руководителям команд и С-level:
✅ Аудит и выстраивание процессов QA, управления релизами и технической поддержки.
✅ Внедрение системы Performance Review и составление индивидуальных планов развития (ИПР) для сотрудников.
✅ Помощь в найме и подборе специалистов в QA.

2. Специалистам (от Junior до Head of QA):
✅ Подготовка к техническим интервью на русском языке.
✅ Разработка персонального ИПР для развития навыков и карьеры.

3. Agile-командам и Scrum-мастерам:
✅ Внедрение Agile и Scrum: от выявления проблем до отлаженных процессов.

🎤 Также провожу корпоративные вебинары:
– Agile и Scrum: от знакомства до внедрения.
– Квартальное планирование и другие темы по запросу.

📩 Если откликнулось — пишите, обсудим детали!

🔥 Как мы синхронизировали понимание критичности багов через игру

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

Как это работало:
1️⃣ Взяли реальные баги из багтрекера и выписали их на карточки.
2️⃣ Подготовили поле с четырьмя столбцами: Low, Medium, High, Critical.
3️⃣ Начали играть по простым правилам:

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

💡 Почему это работает?
Наш мозг отлично справляется с задачами вида "больше/меньше/равно", но плохо работает с абсолютными оценками. Когда нам нужно оценить критичность багов или даже качество кофе, проще сравнивать два варианта, чем присваивать каждому фиксированное значение.

📌 Где это еще можно применить?

Оценка приоритетов задач в бэклоге
Оценка бизнес-рисков

Вместо долгих споров можно просто расставить варианты и дать людям сравнивать их.

🔥 Решил собрать несколько самых обсуждаемых и полезных постов канала, чтобы можно было быстро найти и вернуться к нужной мысли:

1️⃣ Почему нельзя планировать спринты в Story Points? и Инструкция как планировать спринт в часах 📊

2️⃣ Как мы синхронизировали понимание критичности багов через игру 🎲

3️⃣ Вопрос доверия 🤝

4️⃣ Как мы превратили хаос в план: моя история о квартальном планировании 📅

5️⃣ Почему в стрессе сложно учиться (и как это влияет на работу) 🧠

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

Расскажите, какой из постов оказался для вас полезным или запомнился больше всего?

🔥 Мастермайнд: Встречи единомышленников для обмена опытом и поддержки

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

🚀 В январе этого года идея внезапно вернулась, и я понял, что для дальнейшего развития мне может помочь майстермайнд – уже не в роли ведущего, а как активный участник. Оказалось, что уже есть офлайн встречи, которые проводятся регулярно, и я решил присоединиться.
Некоторые изменения в канале, появились в результате мастермайнда.

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

✅ Если вы ищете пространство для обмена опытом и поддержки, а так же способ "начать, что-то делать", рекомендую попробовать формат «мастермайнд». Возможно, именно он станет вашим источником вдохновения и поможет открыть новые перспективы.

🧠 Фасилитация — это не про стикеры. Это про стоимость времени.

У меня много встреч. Особенно групповых. А теперь просто прикиньте: 6 человек × 1 час = 6 человеко-часов. Если умножить это на среднюю ставку часа, сразу становится понятно — встреча стоит дорого. Иногда очень дорого.

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

Но сэкономить получается не всегда.

Простой бытовой пример:
Вы с друзьями собираетесь на прогулку и заранее два часа обсуждаете маршрут. Где встретимся, куда пойдём, во сколько вернёмся. А потом сама прогулка длится час.
Ирония в том, что вы потратили времени вдвое больше, чем на само мероприятие.

Теперь пример более прикладной:
Вы проводите планирование задач. Распределили тикеты, вроде бы всё обсудили. Но сами задачи никто не открыл. Про критерии готовности не поговорили. Деталей по реализации — ноль. Как тестировать не обсудили.
Формально цель встречи достигнута. Но по сути — команда ничего не понесла с собой в спринт. Вы потратили полтора часа времени всей команды, а сэкономили в лучшем случае пять минут каждому — и то не факт.

📌 Поэтому я всё чаще смотрю на фасилитацию не как на модный термин из Agile, а как на способ управлять инвестициями времени команды.

Что помогает:

– задавать правильный фрейм: «Для чего мы здесь?»
– фиксировать результат: «Что конкретно уносим с этой встречи?»
– учитывать вклад каждого: «Кого точно стоит звать, а кого — нет»