Архитектура в тумане: как тимлиду вести research-heavy задачи
Программный комитет ещё не принял решения по этому докладу
Целевая аудитория
Тезисы
Представьте: к вам приходят со словами «нужно запустить сервис Х». Кстати, нужно вчера.
При этом у вас SaaS-экосистема из 13 продуктов, горизонтальные сервисы, легаси и высокие нагрузки. Архитекторы не знают, каким должно быть решение, продукты хотят, чтобы всё работало бесшовно, а команда уже занята другими задачами.
Что делать? Только брать и делать.
В докладе я пошагово разберу через реальный кейс запуска, а что же нам делать.
На каждом этапе кейса остановимся и разберём, какое решение должен принять руководитель: что сначала исследовать самому, когда подключать команду, как декомпозировать неопределённость, о чём договариваться со смежниками и как расширять зону ответственности и не пожечь команду.
Отдельно посмотрим, где в этом процессе помогает ИИ: какие части исследования и декомпозиции ему можно передать, как проверять результат и в какой момент его использование начинает создавать больше шума, чем пользы.
В итоге получится не идеальная схема из учебника, а жизненный цикл сложной research-heavy задачи — с реальными развилками, ошибками и практическими выводами для тимлида на каждом шаге.
Руководит бэкенд-командой Биллинга Яндекс 360 - платформы, отвечающей за все домены монетизации экосистемы Яндекс 360: от тарифов и маркетинга, до платежных механик и оркестрации услуг.
