В процессе общения с множеством ИТ-специалистов (https://news.1rj.ru/str/qa_mne и https://news.1rj.ru/str/qa_kgd) я заметил интересную закономерность: в компаниях, где сотрудники недовольны, часто есть серьезные проблемы с тестовым окружением.

Почему это важно? Потому что тестовое окружение — это не просто удобство, это ключевой индикатор инженерной культуры компании. Если у вас нет тестового окружения, то вы:

⏳ Постоянно теряете время на разработку и тестирование.

🛠 Не можете проверить все как следует на плохом стенде, что приводит к неопределенности: баг это или стенд снова "упал"?

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

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

💡 Моя мысль: отсутствие тестового окружения — это как канарейка в шахте, сигнализирующая о том, что в компании есть системные проблемы. Это такая быстрая проверка, которая доступна на самых первых днях работы в компании.

А как вы оцениваете такие экспресс-проверки? Делитесь своими в комментариях!

🎉 Хочу поделиться отличной новостью!

Я успешно завершил испытательный срок в компании Adapty.io!
🏆 Уже с первых дней я начал внедрять улучшения и менять процессы, что получило очень хорошую оценку коллег. 🚀

Adapty.io — лидер в области мобильных подписок, и я рад быть частью такой команды. Компания предоставляет мощные инструменты для A/B тестирования, аналитики и управления подписками, помогая разработчикам и маркетологам максимизировать доходы и улучшать пользовательский опыт.

Впереди новые задачи, новые проекты и новые успехи!

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

Давайте поговорим про найм. 👥 Когда компания расширяется и нанимает новых сотрудников, это почти всегда положительный признак: дела идут хорошо, объем работы растет, и нужны новые руки, чтобы справляться с задачами.✅
За последнее время я сам нанял несколько человек, и по моим ощущениям, рынок сейчас больше благоприятен для компаний, чем для кандидатов. 📈

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

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

В таких условиях, по моему опыту, самым эффективным способом поиска новых сотрудников становится нетворкинг (да, тот самый, который раньше называли «блатом»). 🌐 Если вы хотите сменить работу или найти подходящего кандидата, находите профессиональные сообщества, общайтесь, обменивайтесь контактами. Несколько моих друзей, а также я сам, нашли новые возможности именно благодаря нетворкингу.

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

Автоматизация тестирования

В очередной раз в Твиттере поднялся вопрос по поводу автотестов. 🤔 Честно говоря, я не понимаю, в чем сложность начать автоматизировать тестирование.

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

Пришел в автоматизацию я без опыта, но уже через два месяца все падающие тесты были исправлены, и я начал писать новые. 🚀

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

Автоматизация тестирования — это всего лишь оптимизация ручного труда. Да, тест-дизайн остается важной частью процесса, поэтому автоматизация является логическим продолжением ручного тестирования.

Есть баг-хантеры, которые не хотят переходить в автоматизацию. Но чтобы у них было больше времени на поиск багов, нужно экономить время на регрессии. Один раз покрыл функционал автотестом — и можно забыть о рутинных проверках. 🔄

А как вы относитесь к автоматизации тестирования? Если вы еще не начали автоматизировать тесты, то что вам мешает? Делитесь своими мыслями в комментариях!

Парное программирование — недооценённая практика

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

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

Кроме того, это отличная практика для улучшения качества кода. Два взгляда на одну задачу позволяют снизить количество ошибок и улучшить общий результат. Это своего рода "онлайн ревью", которое происходит прямо в процессе написания кода.

Пошаговая инструкция: Как проводить парное программирование

1. Определите роли: "водитель" и "навигатор"

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

2. Меняйте роли регулярно

Меняйте роли, чтобы обе стороны могли внести свой вклад в код и процессы. Это важно для баланса и обучающего эффекта. Если у водителя появилась идея, то он должен "отдать клавиатуру".

3. Работайте над одной задачей

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


4. Используйте инструменты для совместной работы

Для удаленных команд используйте инструменты для совместного кодинга, такие как Visual Studio Live Share или другие, чтобы эффективно работать над одной задачей в реальном времени.

Star Map: инструмент для тимлидов

Если вы уже тимлид и у вас в команде больше 5 человек, то, вероятно, вы сталкивались с проблемой отслеживания навыков сотрудников. 🧑‍💻 Чтобы не держать всё в голове, я рекомендую использовать Star Map.

Этот инструмент помогает визуализировать как хард-скиллы, так и софт-скиллы сотрудников, а также их знания продукта. Всё это можно собрать в одной карте или разделить на несколько. 🌟

Почему это полезно?

Star Map позволяет легко увидеть, кто в команде обладает ключевыми компетенциями, а у кого могут быть пробелы. 🔍
Это особенно удобно для выявления "бутылочных горлышек" — навыков или знаний, которые ограничивают эффективность команды. 🔧

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

Почему успешные тимлиды всегда имеют кадровый резерв?

Вопрос кадрового резерва часто недооценивается, хотя это ключевой элемент стабильной работы любой команды. Кадровый резерв — это группа сотрудников, которые могут взять на себя обязанности других коллег в случае их отсутствия или ухода. Это не просто план "на случай чего", а стратегический подход к управлению и развитию команды.

Почему кадровый резерв важен:

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

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

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

Как создать кадровый резерв:

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

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

Как LinkedIn оценивает ваш успех? Узнайте через SSI!

Вчера я узнал о Social Selling Index (SSI) на LinkedIn, и мое первое впечатление — мир из "Черного зеркала" уже стал реальностью. 🤖

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

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

Посмотрите ваш SSI:
https://www.linkedin.com/sales/ssi?src=li-other&veh=www.linkedin.com%7Cor-search

Добавляйтесь ко мне в LinkedIn, давайте улучшать этот показатель вместе:
https://www.linkedin.com/in/ezhiltsov/

Напишите в комментариях, а какой у вас текущий рейтинг?

Недавняя новость о том, что ABBYY уволила всех сотрудников с российским гражданством, вызвала бурю обсуждений в IT-сообществе. Сокращения произошли неожиданно в офисах на Кипре, в Белграде и Будапеште. Все началось с корпоративной встречи, где отключили чат и микрофоны, и через несколько минут после объявления об увольнении сотрудники лишились всех корпоративных доступов. Эта ситуация вызвала большой резонанс, и десятки релокантов выразили своё негодование в соцсетях, особенно в Twitter.

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

Мой опыт: Несколько лет назад я столкнулся с подобной ситуацией. Компания открыла офис в Индии, а спустя год закрыла наш офис в Калининграде. Когда появляются более дешевые варианты, логика бизнеса, к сожалению, часто работает именно так — сокращать затраты, несмотря на лояльность сотрудников. Специалисты были дешевле, но квалификация была сильно ниже. Ведущий разработчик с 14 годами опыта закрывал онбординг задачу больше месяца.

Поделитесь своими мыслями.

Друзья, хочу лучше понимать, какой контент вам нравится больше всего! 🙌 Пожалуйста, не забывайте ставить реакции на посты — это поможет мне ориентироваться на ваши интересы и создавать еще больше полезных материалов.

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

А если какой-то пост оказался для вас особенно полезным или интересным, буду очень признателен за репост — так о нем смогут узнать и другие! 😊

Ваше мнение действительно важно, и я ценю каждый ваш отклик! 🙏

🚀 Новая публикация на Хабре!

Рад сообщить, что я впервые опубликовал статью на Хабре! 🎉

🔗 Создание эффективной команды QA: Рекомендации для лидеров

В этой статье я делюсь своим опытом и рекомендациями по созданию высокоэффективной команды QA. Обсуждаю следующие темы:

Что такое команда и чем она отличается от просто группы людей.

Какие цели ставятся при создании команды QA.

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

Буду рад вашим комментариям!

Спасибо за поддержку и до встречи в следующих публикациях! 💡

Montenegro IT Show – Episode 6, попытка 3

🚀 Суббота, 5 октября в 21:00

После яркого выпуска с Дмитрием Шером, мы продолжаем нашу серию интересных бесед о мире IT! На следующем эпизоде гостем станет:

🎙 Eugene Zhiltsov @ezhiltsov
QA Lead, основатель сообщества QA_MNE.

Мы обсудим актуальные новости в сфере IT, углубимся в тему тестирования и узнаем, что происходит в сообществе QA в Черногории. Это будет незабываемый вечер, полный полезных знаний и интересных инсайтов!

Где смотреть:

На YouTube
Вживую в DKDK с виски кола в подарок
Не пропустите!

Без CI/CD никуда: ключ к быстрой и качественной разработке ПО

🚀 CI/CD (Continuous Integration / Continuous Deployment) – это два ключевых процесса, которые помогают командам разработчиков автоматизировать сборку, тестирование и доставку программного обеспечения в продакшн.

Что такое CI/CD?

CI (Continuous Integration) – Простыми словами, это процесс написания кода, его тестирования и вливания в основную ветку. Это помогает находить ошибки на ранних стадиях и избегать проблем с интеграцией.

CD (Continuous Deployment) – Непрерывная доставка – это процесс, который позволяет автоматизировать доставку кода в продакшн после успешного прохождения всех тестов. Это значит, что каждое изменение может быстро попасть в релиз, что дает возможность получать обратную связь от пользователей практически сразу.

Почему CI/CD важен?

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

Повышение качества: CI/CD включает тестирование на всех этапах, что позволяет быстро находить и устранять баги.

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



Как внедрить CI/CD?

Начните с малого: Внедряйте CI/CD поэтапно. Начните с непрерывной интеграции, чтобы команда привыкла к регулярным сборкам и автоматическим тестам, затем переходите к непрерывной доставке.

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

Используйте доступные инструменты: Начните с таких инструментов, как Jenkins, GitLab CI/CD, Travis CI или CircleCI. Они помогут быстро настроить процессы автоматизации.

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

Обучите команду: Объясните всем членам команды, зачем нужен CI/CD, и как это влияет на общую эффективность разработки. Вовлеченность всех участников — ключ к успешному внедрению.



А вы используете CI/CD в своей работе?

🚀 Правильный подход к Code Review: как сделать процесс продуктивнее?

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

Стратегии Code Review:

🔹 Стратегия "Патруль"

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

🔹 Стратегия "Напарники"

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

🔹 Стратегия "Спецгруппа"

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

🔹 Стратегия "Доверенное лицо"

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

🔹 Стратегия "Экспертная зона"

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

🔹 Стратегия "Открытый стол"

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

🔹 Стратегия "Свежий взгляд"

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

Почему Code Review важен?

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

Обучение: Команда быстрее развивается, видя различные подходы к решению задач.

Снижение технического долга: Регулярные проверки предотвращают накопление сложных и трудно поддерживаемых решений.

А какие стратегии у вас применяются в работе?

🎯 Целеполагание

Сегодня поговорим про OKR (Objectives and Key Results) — это методология целеполагания, которая помогает достичь согласованности целей на всех уровнях компании. Концепция прекрасно описана в книге "Измеряй самое важное", и ее главная сила в простоте.

Основная идея заключается в том, что Key Results (Ключевые результаты) руководителя становятся Objectives (Целями) для его подчиненных. Это помогает достичь полной согласованности целей на всех уровнях организации.

📋 Пример:

Objective руководителя: Повысить удовлетворенность клиентов на 25% за квартал.
Key Results руководителя:
Увеличить средний рейтинг удовлетворенности клиентов с 4.0 до 4.5.
Сократить среднее время обработки заявок с 8 до 5 минут.
Увеличить процент решений при первом обращении с 85% до 90%.
Для менеджера по поддержке клиентов это будет его Objective:

Objective менеджера: Увеличить средний рейтинг удовлетворенности клиентов до 4.5.
Key Results менеджера:
Ответить на 90% всех запросов в течение 3 минут.
Увеличить процент вопросов, решенных с первого обращения, с 80% до 90%.
Обработать 95% всех заявок за 5 минут или меньше.
Таким образом, каждый понимает свою роль в достижении общей цели, а процесс становится прозрачным и структурированным.

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

💬 А как вы используете целеполагание в своей команде? Пробовали OKR? Делитесь своим опытом в комментариях!

🎯 Целеполагание с использованием SMART: как ставить цели, чтобы их достигать

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

Что такое SMART?
🔹 S (Specific) — Конкретная цель
Задача должна быть максимально конкретной, чтобы было понятно, чего именно вы хотите достичь.
Пример: Вместо "Повысить продажи" — "Увеличить продажи продукта на 15%".

🔹 M (Measurable) — Измеримая цель
У цели должны быть четкие метрики, которые позволят оценить прогресс.
Пример: Вместо "Улучшить качество обслуживания" — "Увеличить рейтинг удовлетворенности клиентов с 4.0 до 4.5".

🔹 A (Achievable/Attainable) — Достижимая цель
Цель должна быть реалистичной с учетом имеющихся ресурсов и обстоятельств. Здесь могут быть разные интерпретации буквы A: кто-то считает, что она означает "Ambitious" (Амбициозная), а другие — "Assignable" (Делегируемая). Это может зависеть от культуры и потребностей компании.
Пример: Вместо "Повысить продуктивность на 100%" — "Повысить продуктивность на 20% за счёт автоматизации рутинных задач".

🔹 R (Relevant) — Значимая цель
Цель должна быть значимой и соответствовать основным приоритетам компании или команды.
Пример: Если компания фокусируется на клиентском опыте, то цель "Сократить время ответа на обращения клиентов до 5 минут" будет более релевантной, чем просто увеличение числа обрабатываемых заявок.

🔹 T (Time-bound) — Ограниченная во времени
Цель должна иметь конкретный срок для выполнения. Это помогает команде сфокусироваться и эффективно распределить время.
Пример: Вместо "Запустить новый проект" — "Запустить новый проект к концу квартала".

Альтернативные подходы к формулированию целей

Хотя SMART — один из самых популярных методов целеполагания, есть и другие подходы, которые можно адаптировать под нужды вашей команды:

🔸 CLEAR — Этот метод фокусируется на гибкости и адаптивности целей, особенно в быстро меняющихся условиях:

C (Collaborative) — Цель подразумевает командную работу.
L (Limited) — Цель имеет чёткие временные ограничения.
E (Emotional) — Цель мотивирует и важна для участников.
A (Appreciable) — Цель можно разбить на более мелкие задачи.
R (Refinable) — Цель можно изменить при необходимости.

🔸 FAST — Этот подход подходит для высокоэффективных команд, акцентируя внимание на динамике:

F (Frequent) — Постоянная проверка прогресса.
A (Ambitious) — Цель стимулирует выход из зоны комфорта.
S (Specific) — Цель чёткая и понятная.
T (Transparent) — Цель понятна всей команде и доступна для отслеживания.

🔸 HARD — Этот метод полезен, когда цели должны быть смелыми и мотивационными:

H (Heartfelt) — Цель важна на личном уровне, вызывает энтузиазм.
A (Animated) — Цель визуализирована, чтобы вдохновлять.
R (Required) — Цель необходима для успеха.
D (Difficult) — Цель должна требовать усилий и работы над собой.


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