Тимлиды в своей работе сталкиваются со специфичными вызовами:

1. Резкая смена парадигмы: многие тимлиды выросли из разработчиков, и внезапно их концепция резко меняется. Теперь им приходится не только писать код, но и управлять командой, принимать стратегические решения и общаться с заказчиками
2. Избыток коммуникаций: они общаются с разработчиками, продуктовыми менеджерами, заказчиками, тестировщиками… Со всеми, кто участвует в проекте
3. Негатив в коллективе: тимлиду приходится разрешать конфликты и управлять эмоциями в команде. Если что-то идет не так, он или она должны нивелировать негативное воздействие на коллектив
4. Профессиональное выгорание: все вышеперечисленные факторы могут привести к выгоранию. Тимлиды должны следить за своими эмоциями, уметь отдыхать и находить баланс между работой и личной жизнью
5. Выгорание сотрудников: тимлиды не только сами подвержены выгоранию, но и должны следить за состоянием своей команды. Поддержка и мотивация коллег —часть их роли

Уже завтра, 18 июля в 20.00 GMT +3 с Анастасией Шнек и Павлом Вейником обсудим это на вебинаре. Еще не поздно зарегистрироваться, задать вопросы и добавить событие себе в календарь.

Call for papers ✉️

Друзья, вы наверное заметили что количество ивентов в H&S Skills растет, теперь мы встречаеся по вторникам, средам и четвергам, а регулярных форматов проведения уже стало 5 - Архитектурые Трепы, Кабанчик, Карьерный навигатор, Конклав и Митапы😱 И вебинары же еще, да!

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

Заполняйте анкету и мы вместе поищем варианты и подходящий для вас формат 🤗

PS. Чтобы поддержать тех из вас, у кого опыта публичных выступлений нет или он небольшой, а выступать хочется, мы разработали мини-курс, который поможет:
✓ сформулировать тему,
✓ определить цели,
✓ создать и оформить презентацию,
✓ а также подготовиться к самому выступлению.

💫Вчера прошел вебинар Team Leadership, с Анастасией Шнек и Павлом Вейником.

Поговорили о ролях доступных для развития по пути менеджера, работе над процессами, выгорании и тех скилах, которые необходимы для роста до уровня Teamlead, Engineering Manager.

Обсудили, как курс Team Leadership поможет стать хорошим Teamlead.

По ссылке запись вебинара

На что смотреть при выборе очереди сообщений?

Задача очереди сообщений (message queue) – передавать данные из одной точки в другую.

В распределенных системах MQ становится прокладкой, снижая зависимость компонентов системы друг от друга (вместо зависимости по API – зависимость по формату данных).

Еще один use case очереди сообщений – буфер перед нагруженной частью системы, в котором скапливаются данные, не перегружая обработчик.

Де-факто, стандартом в индустрии стала Apache Kafka, но для более специфических задач есть другие инструменты – RabbitMQ, Redis, ActiveMQ и еще около полусотни очередей.

Вот, что нужно учитывать при выборе:

🔸 Механизм передачи сообщений – Pub/Sub или Producer/Consumer, P2P или брокер сообщений?

🔸 Объем данных и их формат, throughput, latency, масштабируемость

🔸 Гарантии доставки и порядка сообщений – at most once, at least once, может ли очередь гарантировать, что сообщения будут прочитаны консюмерами в том же порядке, в каком попали в очередь.

🔸 Какие гарантии безопасности дает очередь? Есть ли Routing? Может ли очередь преобразовывать формат сообщений? Может ли очередь выступать в качестве персистентного хранилища (сохранять данные на диск)? Какая инфраструктура – on premise, cloud, managed service?

Выбор правильных инструментов для технических решений – ответственность техлида и архитектора. Для этого нужен кругозор, развитию которого посвящен самый объемный раздел курса [Технический Лидер]. Записывайтесь на консультацию!

Друзья, делимся с вами интересным контентом!

Дима Королев, один из Трех Джедаев H&S Skills и ведущий 24-го Software Craftsmanship митапа про Event Sourcing, недавно поучаствовал в подкасте FaangTalk, где подробно рассказал про System Design Interview и не только. Вот некоторые темы, которые обсуждали:

🔸Что обязательно нужно знать разработчику для System Design Interview?
🔸Почему на интервью дают задачи на проектирование систем с огромным скейлом, когда в реальности таких систем единицы?
🔸System Design – это про soft skills?
🔹Нужны ли вообще System Design Interview?

Еще поговорили про разные инструменты и их use cases: как Discord использует Cassandra, где можно поставить SQLite, почему ни один мессенджер не использует Kafka и почему PostgreSQL подойдет почти везде.

🚀 Как справляться со стрессовыми ситуациями в команде и при чем здесь PCM разбираем на Архитектурном Трепе 111.

Заходите в Google Meet

Файл для зрителей Трепа 👆

Что делать, когда бэклог переполняется техдолгом?

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

Все эти “мелкие” и “небизнесовые” задачи – технический долг. Работа с техдолгом – это баланс между краткосрочными целями бизнеса и его выживанием в долгосрочной перспективе.

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

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

🔺 Выделить спринт или несколько исключительно для задач по техдолгу.
🔺 Создать роль “дежурного”, который будет закрывать небизнесовые задачи. Передавать эту роль между членами команды раз в день/неделю/спринт.
🔺 Создать maintenance team, задача которой – исправление багов, рефакторинг и выполнение “общих” задач.

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

▫️ Донести до product owner-а или других представителей бизнеса, что нельзя бесконечно откладывать рефакторинг и создание качественной документации. Выделять 20-30% спринта на задачи по техдолгу.
🔹 Повышать квалификацию сотрудников и развивать культуру разработки. Члены команды, чьи ошибки приходится исправлять, должны, как минимум, знать об этом и стараться не повторять их.
▫️ По возможности автоматизировать проверку кода – линтеры, авто-тесты в CI/CD пайплайне и т.д. Так промежуток времени между созданием техдолга и его исправлением существенно уменьшится.

Планирование задач команды вместе с PO – функция тимлида, с которой начинающие руководители часто испытывают трудности. Нахождение баланса между потребностями бизнеса и техдолгом – одна из тем в программе курса [Team Leadership]. Старт курса – 6 августа. Успейте записаться на консультацию!