From enemies to family: как тимлиду и продакту перестать конфликтовать — новый выпуск «Тимлид позвонит» уже в эфире🎙️

Как тимлиду и продакту договориться о ролях и ответственности? Почему даже сильные команды сталкиваются с напряжением? И нужна ли команде «семейная» атмосфера?

Вместе с ведущим менеджером продукта в «Авито Недвижимости» Андреем Осягиным обсуждаем:
• каким продакта видит тимлид — и наоборот;
• кому на самом деле нужны дейлики;
• когда продакт должен говорить команде «нет»;
• как балансировать техдолг и бизнес-задачи;
• что вообще такое «здоровый продукт». 

Новый выпуск доступен на всех платформах →

🎧 YouTube 🎧 Spotify 🎧 Apple Podcasts 🎧 Mave

Коллеги, доброго времени суток! У нас промокод с мобилки не прокидывается, сможете оперативно подключиться? Заранее спасибо 🙏

Кто не получал в мессенджере такое сообщение от коллеги или руководителя — вы молодец, у вас всё круто с личными границами. Остальных обняли 🤗

В теории, конечно, рабочие и личные каналы связи нужно разделять. Для работы — рабочий мессенджер, для личных переписок — другой, желательно на отдельном телефоне. Но на практике мы все знаем тот самый стартап, где вся переписка ведётся в Телеграме. Кстати, у вас с этим как, всё работает? 👀

Расскажите, как разделяете work-life для баланса!

👍 — общаюсь с коллегами только в рабочих каналах
🔥 — веду рабочие чаты и переписку с друзьями в одном месте

Представьте, что вы QA 🕵️

Залетает тикет от от поддержки: баг в CRM-виджете. Документации по нему нет или она устарела, разработчик занят.

Что будем делать?

🔥 — Идём в поля исследовать вручную
👍 — Стучимся к разрабам, просим объяснить, как это работает
❤️ — Разбираемся сами вместе с ИИ

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

Как тестировщики Skyeng используют Cursor, чтобы понять бизнес-логику и фичи на уровне кода? Как сделать так, чтобы n8n сам выгружал баги из тредов в Jira, а Open WebUI объединял их и другие модели в едином интерфейсе?

🔗 Читайте эпопею в трёх частях — от анализа багов до агентов-автоматизаторов: https://habr.com/ru/companies/skyeng/articles/1001488/

Разрешите представить наших нейроколлег 🤓

Мы снова про ИИ, но с позиции уже не разработчика, а пользователя. Что видит человек, когда просто учится в Skyeng? Залипательные уроки, крутые учителя, домашка, которую хочется сделать. Вот что под капотом:

1. ChatGPT помогает придумывать задачи и упражнения.

2. NanoBanana Pro рисует к ним иллюстрации: и древних римлян, и Менделеева, и его таблицу.

3. Veo3 «снимает» видео со звуком. Герои двигаются, говорят на английском и других языках, помогают запомнить материал.

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

Всё это валидируют учителя и методисты, чтобы не было ошибок. Никаких лишних пальцев на фото и «2 + 2 = 5» 👍

Кстати, благодаря ИИ наши ученики по-прежнему могут заказать урок английского на интересную им тему, например про Формулу-1 или BTS. Вы бы какой заказали? 👀

А-а-а, всё сломалось, ничего не работает 😭

Сказали бы мы, если бы не было дежурных разработчиков! Без них в чате с алертами всплывает уведомление, но кто-то на встрече, кто-то в потоке, а у кого-то срабатывает эффект свидетеля: «Это не мой код, пусть посмотрит кто-то другой».

В итоге получаем целый букет проблем:
➡️ реакция с задержкой;
➡️ расфокус команды, которую постоянно дёргают;
➡️ низкий bus factor и др.

Как дежурство помогает это решить

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

Главное правило: дежурный отвечает в первую очередь за дежурные обязанности. Другие задачи второстепенны. Тогда у человека появляется ресурс «лечить болезнь», а не исправлять «симптомы» с помощью костылей.

Как выбирают дежурных и что они делают

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

Во время дежурства двигаемся по списку приоритетов:
1. Инциденты и алерты (бросаем всё, спасаем прод).
2. Код-ревью (чтобы процессы команды не стопорились).
3. Помощь коллегам по команде и мелкие задачки.
4. Обращения от других отделов (эскалирования от поддержки, вопросы от бизнеса, помощь другим командам).
5. Рутинная чистка техдолга.

Но не всё так просто, сам дежурный тоже может столкнуться с трудностями… Ставьте реакции, если хотите почитать про это больше 👀

🤔 «Подождите, а мы это уже обсуждали?»

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

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

По сути, это «память» проекта, которая всегда под рукой 🧠

👉 Как устроена система и что она меняет в работе команды — разобрали в статье.

Тоже понравилось работать четыре дня в неделю? 💔

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

Например, американский финтех Bolt недавно перешёл обратно на пятидневную рабочую неделю. По словам CEO, компания не смогла перестроиться. Сотрудники просто работали на износ, пытаясь уместить 40 часов задач в четыре рабочих дня, и быстро выгорали.

Вы как, хотите четырёхдневку или ничего не успеваете? 👀

❤️ — хочу так работать каждую неделю
👍 — можно иногда для разнообразия, но не всё время

Ожидание: дежурный мощными лапами разгребает все влёты 🐺
Реальность: был в сети 15 минут назад 🕘

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

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

➡️ Готовимся к дежурству

Сначала проверяем, что у дежурного есть все доступы (k8s, актуальная БД, деплой), чтобы решать проблемы самому, а не бегать по личкам. Выкручиваем уведомления на максимум (в десктопе и в мобилке), чистим календарь от неважных встреч, а бэклог — от больших задач, где нужно погружение. Ставим в статус 👷‍♂️ и начинаем дежурство.

Реакции в каналах тоже должны быть прозрачными:
• 👀 — увидели алерт;
• 🚧 — взяли в работу;
• ✔️ — готово, завершено.

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

➡️ Адекватная эскалация

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

Важно не геройствовать: зашёл в тупик — созваниваемся, шарим экран и решаем проблему вместе. Иначе никто ничему не учится, и bus-фактор так и остаётся низким.

➡️ Бесшовная передача дел

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

➡️ План Б на случай форс-мажора

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

Пришли к такому регламенту методом проб и ошибок. Пока всё (тьфу-тьфу) работает. Если у вас другая схема, расскажите в комментариях 👇🏼

А вы знаете, почему ошибки в коде называют багами? 🐞

🔥 — Да, знаю
🤔 — Не-а, просветите меня

🐞 Fun fact: слово «баг» буквально означает «жук»

И это не совпадение! Термин bug («жук») инженеры использовали ещё задолго до появления современных компьютеров — так они называли любые неполадки в работе техники.

Но настоящую популярность слово получило в 1947 году. Инженер и пионер программирования Грейс Хоппер с коллегами искала причину сбоя компьютера Mark II и обнаружила настоящую бабочку, застрявшую между контактами реле.

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

С тех пор слово «баг» прочно вошло в обиход 😉

Кстати, ловите производственный календарь на 2027 год. Сохраняйте, чтобы не потерять 📌