Интерактивный путеводитель по будущей программе

Карта конференции, собранная из реальных болей инженерных команд.

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

Ответов в приоритетной когорте
346
из 468 анкет после очистки
Уникальных респондентов в тематическом слое
316
smalltech / midtech
Аналитических единиц
979
боли, запросы, незакрытые вопросы
Обязательных тем ядра
6
основа будущей программы
Абстрактная карта программы конференции
Must-cover ядро

Стоимость изменений, delivery, legacy, platform/devops, архитектура и лидерство образуют основу программы. AI усиливает её, но не подменяет.

Почему именно такая структура

Сайт показывает не просто набор тем, а логику ответа на самые частые и самые острые боли.

Исследование показало: аудитория smalltech/midtech ждёт не очередную витрину технологических трендов, а программу о том, как выживать, поставлять, модернизировать и расти под ограничениями. Поэтому архитектура конференции строится вокруг операционных и организационных проблем, а не вокруг модных ярлыков.

1-й слой
6 обязательных треков
2-й слой
AI и сквозные усилители

Программа должна объяснять, как снижать стоимость изменений, как строить delivery без enterprise-избыточности, как проходить миграции без разрушения текущего бизнеса, как не терять наблюдаемость и управляемость платформы, и как масштабировать архитектуру и команду одновременно.

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

Аналитический отчёт

Что болит у smalltech и midtech команд: результаты исследования аудитории.

Полная версия отчёта внутри основного гайда: методика, профиль когорты, матрица сигналов между конференциями и практические выводы для программного комитета.

01 · Механика исследования

Исследование собрано из анкет 6 крупнейших ИТ-конференций, глубинных кастдевов с CTO/Head of Engineering и открытых ответов о сложных рабочих кейсах.

Анкет собрано
468
после очистки и дедупликации
Приоритетная когорта
346
smalltech / midtech (73.9%)
Аналитические единицы
979
боли, вопросы, запросы
Уникальные респонденты
316
в тематизированном слое
  • Reach: 70% доля уникальных респондентов + 30% доля аналитических единиц.
  • Intensity: 45% тип сигнала + 35% срочность + 15% current acute + 5% unmet question.
  • Pain Priority Score: 50% Reach + 35% Intensity + 15% широта между конференциями.
DevOpsConf67 анкет
AiConf54 анкеты
GolangConf88 анкет
TeamLead Conf130 анкет
HighLoad++129 анкет
CustDev11 интервью
02 · Когортный анализ

Smalltech/midtech составляют ядро сигнала. Это команды, которым нужны не трендовые обзоры, а прикладные ответы по стоимости изменений, delivery и управляемости при росте.

Smalltech
~180
ИТ-штат до 300
Midtech
~166
ИТ-штат 300-1500
Enterprise
122
ИТ-штат 1500+
03 · Рейтинг болей по приоритету

Полный опубликованный рейтинг тем из отчёта: must-cover ядро и secondary-кластеры, которые усиливают программу.

  1. 01 · MUST-COVER Engineering Economics54.9
  2. 02 · MUST-COVER Delivery & Processes54.4
  3. 03 · MUST-COVER Legacy & Migration52.6
  4. 04 · MUST-COVER Platform & DevOps51.0
  5. 05 · MUST-COVER Architecture & Scalability50.9
  6. 06 · MUST-COVER Leadership & Org Design50.5
  7. 07 · SECONDARY AI in Production48.8
  8. 08 · SECONDARY Cross-functional Alignment47.4
  9. 09 · SECONDARY Security & Compliance46.2
  10. 10 · SECONDARY Learning & Maturity45.9
  11. 11 · SECONDARY Data & Knowledge Systems45.9
  12. 12 · SECONDARY People, Hiring & Career45.8
04 · Must-cover темы: детальный срез
Engineering Economics
96 респондентов · reach 24.5% · intensity 79.1%

Как снижать стоимость изменений и не раздувать платформу.

Delivery & Processes
87 респондентов · reach 22.5% · intensity 80.6%

Как строить delivery без enterprise-избыточности.

Legacy & Migration
65 респондентов · reach 17.2% · intensity 83%

Как мигрировать легаси без разрушения текущего бизнеса.

Platform & DevOps
78 респондентов · reach 20.6% · intensity 80.6%

Как не терять наблюдаемость и управляемость платформы.

Architecture & Scalability
65 респондентов · reach 16.8% · intensity 78.7%

Как масштабировать архитектуру и команду одновременно.

Leadership & Org Design
60 респондентов · reach 15.8% · intensity 78.8%

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

05 · Корреляции тем и конференций

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

Тема DevOps AiConf Golang TeamLead HighLoad CustDev
Engineering Economicsstrongstrongstrongstrongstrongstrong
Delivery & Processesstrongmediummediumstrongstrongstrong
Legacy & Migrationmediumlowmediummediumstrongstrong
Platform & DevOpsstronglowstrongmediummediummedium
AI in Productionmediumstrongmediumlowmediummedium
Leadership & Org Designlowlowlowstrongstrongmedium
06 · Выводы и действия комитета
  • Фокус на operational pain: программа про выживание, управляемость и рост под ограничениями.
  • CFP по сценариям боли: путь команды, ошибки, рабочие решения и цена решения.
  • Форматы по типу задачи: case study/war story для маршрутов, panel/AMA для спорных тем, clinic/workshop для инструментов.
  • AI как прикладной слой: AI усиливает ядро, но не подменяет delivery, economics и leadership.
Рекомендуемый баланс программы
Must-cover ядро 60%
Important secondary 30%
Экспериментальные форматы 10%
"Сильная программа — это последовательность решений от боли команды к полезному формату, а не список модных технологических ярлыков."
Карта треков

Шесть обязательных направлений ядра и один прикладной AI-блок.

Выбери трек, чтобы увидеть его исследовательское основание, ключевые вопросы, рекомендуемые форматы и портрет спикера.

Схема маршрутов между треками программы
Форматирование опыта

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

Там, где нужны маршруты и ошибки, работают case study и war story. Там, где нет одного правильного ответа, лучше панель или AMA. Там, где аудитория хочет унести инструмент, нужен workshop или clinic.

Аналитические панели и секционные слои
Формат
Case study
migration, architecture, AI, platform

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

Формат
War story / failure talk
legacy, delivery, leadership

Позволяет разбирать тупики, откаты, сопротивление и ошибки без полировки reality gap.

Формат
Panel discussion
leadership, AI, security, alignment

Подходит темам, где нет одного правильного рецепта и важны сравнительные практики.

Формат
Workshop / clinic
observability, testing, AI quality, process setup

Даёт участнику конкретный инструмент, фреймворк или метод разбора ситуации.

Формат
AMA / office hours
migration, platform, leadership

Закрывает незакрытые вопросы и помогает дожать сложные нюансы без лишней сцены.

Формат
Benchmark / patterns talk
efficiency, org design, delivery

Нужен там, где аудитории важны ориентиры, зрелостные модели и сопоставимые паттерны.

Сквозные слои

Второй эшелон тем должен усиливать ядро, а не дробить программу на лишние автономные треки.

Cross-functional alignment

Встраивать внутрь leadership, delivery и AI — там, где нужно выравнивать бизнес и технологию.

Security & compliance

Делать обязательным прикладным слоем внутри platform/devops, migration и AI, а не отдельной абстракцией.

Learning & maturity

Усиливать leadership, platform и architecture темами роста экспертизы, mentoring и инженерной зрелости.

Data, knowledge & search

Собирать как специальные блоки внутри AI и architecture, частично — как самостоятельные доклады.

People, hiring & career

Оставлять как leader-oriented секцию и HR-сателлит, но не превращать в стержень всей программы.

Постер программы конференции
Решения для комитета

Что делать программному комитету дальше, чтобы из структуры получилась сильная сетка конференции.

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

Рекомендуемый баланс программы
Must-cover ядро 60%
Important secondary темы 30%
Экспериментальные / нишевые форматы 10%
4 ключевых действия
1

Собирать CFP не вокруг хайповых технологий, а вокруг инженерных и организационных сценариев боли.

2

Приоритизировать кейсы компаний, которые росли под ограничениями, а не только зрелые enterprise-истории.

3

Требовать от спикеров ответа на вопрос «что команда делала, где ошиблась и что теперь работает».

4

Сбалансировать программу так, чтобы технические треки не существовали отдельно от лидерства, стоимости и delivery-логики.

Кого приоритизировать в поиске спикеров
Трек Профиль спикера
Engineering EconomicsCTO, Head of Engineering, Platform Lead
Delivery & ProcessesEM, Delivery Manager, Head of Development
Legacy & MigrationArchitect, Staff Engineer, Infra Lead
Platform & DevOpsPlatform Engineer, SRE, DevOps Lead
Architecture & ScalabilityArchitect, Principal Engineer
Leadership & Org DesignCTO, VP Eng, Director of Engineering, Head of R&D
AI in ProductionAI Lead, Applied ML Lead, Product/Engineering leader