Что болит у smalltech и midtech команд
Исследование аудитории шести крупнейших ИТ-конференций: 468 анкет, 3 глубинных кастдева, 979 аналитических единиц. Цель — понять, о чём должна быть программа следующей конференции, чтобы ответить на самые острые боли инженерных команд.
анкет собрано
468
после очистки и дедупликации
приоритетная когорта
346
smalltech / midtech (73.9%)
аналитических единиц
979
боли, вопросы, запросы
уникальных респондентов
316
в тематизированном слое
Как собирались и обрабатывались данные
Три типа источников: анкетные опросы участников конференций, глубинные кастдевы с CTO и Head of Engineering, и открытые ответы на вопросы о сложных профессиональных задачах.
Reach
70% × доля уникальных респондентов + 30% × доля аналитических единиц
Насколько широко тема распространена в когорте.
Intensity
45% тип сигнала + 35% срочность + 15% current acute + 5% unmet question
Насколько остро ощущается боль.
Pain Priority Score
50% × Reach + 35% × Intensity + 15% × широта между конференциями
Итоговый приоритет темы для программы.
источники данных
DevOpsConf
янв 2026
67 анкет
AiConf
янв 2026
54 анкет
GolangConf
янв 2026
88 анкет
TeamLead Conf
фев 2026
130 анкет
HighLoad++
фев 2026
129 анкет
CustDev
апр 2026
11 анкет
Кто составляет приоритетную когорту
Smalltech/midtech — компании с ИТ-штатом менее 1500 человек. Эта когорта составила 73.9% всей выборки и формирует основной сигнал для программы.
Smalltech
52%~180
ИТ-штат до 300 анкет
Midtech
48%~166
ИТ-штат 300–1500 анкет
Enterprise
35%122
ИТ-штат 1500+ анкет
12 тематических кластеров по силе боли
Каждая тема оценивается по охвату когорты, силе боли и широте присутствия между конференциями. Топ-6 формируют must-cover ядро программы.
Engineering Economics
стоимость, ресурсы, эффективность
Delivery & Processes
поставка, процессы, качество
Legacy & Migration
модернизация, миграции
Platform & DevOps
инфраструктура, observability
Architecture & Scalability
системный дизайн, рост нагрузки
Leadership & Org Design
лидерство, команды, оргдизайн
AI in Production
прикладной AI, не хайп
Cross-functional Alignment
коммуникация, выравнивание
Security & Compliance
безопасность, соответствие
Learning & Maturity
рост, зрелость, экспертиза
Data & Knowledge Systems
данные, знания, поиск
People, Hiring & Career
найм, рост, карьера
Шесть обязательных треков ядра
Стоимость изменений, delivery, legacy, platform/devops, архитектура и лидерство образуют основу программы. AI усиливает её, но не подменяет.
Engineering Economics
54.9стоимость, ресурсы, эффективность
resp.
96
reach
24.5%
tier
must
Delivery & Processes
54.4поставка, процессы, качество
resp.
87
reach
22.5%
tier
must
Legacy & Migration
52.6модернизация, миграции
resp.
65
reach
17.2%
tier
must
Platform & DevOps
51.0инфраструктура, observability
resp.
78
reach
20.6%
tier
must
Architecture & Scalability
50.9системный дизайн, рост нагрузки
resp.
65
reach
16.8%
tier
must
Leadership & Org Design
50.5лидерство, команды, оргдизайн
resp.
60
reach
15.8%
tier
must
Разные боли требуют разных сценических форм
Программа не должна состоять только из докладов. Там, где нужны маршруты и ошибки, работают case study и war story. Там, где нет одного правильного ответа — панели и AMA.
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
Нужен там, где аудитории важны ориентиры, зрелостные модели и сопоставимые паттерны.
Что делать программному комитету дальше
Рекомендуемый баланс программы
4 ключевых действия
- 1
Собирать CFP не вокруг хайповых технологий, а вокруг инженерных и организационных сценариев боли.
- 2
Приоритизировать кейсы компаний, которые росли под ограничениями, а не только зрелые enterprise-истории.
- 3
Требовать от спикеров ответа на вопрос «что команда делала, где ошиблась и что теперь работает».
- 4
Сбалансировать программу так, чтобы технические треки не существовали отдельно от лидерства, стоимости и delivery-логики.
«Сильная программа — это последовательность решений от боли команды к полезному формату, а не список модных технологических ярлыков.»