Введение
Привет, Хабр. Я Александр Габидуллин. Инженер внедрения в «Группа Астра», но на Techday 2026 я сменил амплуа: стал спикером и рассказывал, как мы с командой пережили массовую миграцию и что из этого вышло.
Оглядываясь назад, я осознал всю прелесть офлайн‑мероприятий. И теперь хотел бы поделиться своим мнением — от первого лица и без прикрас — о том, зачем нужны такие встречи и какую ценность они дают.
Дальше будет взгляд обычного инженера на работу в команде, без «правильных» формулировок, просто мой опыт.
1. Зачем компании «ритуалы»?
В любой растущей IT‑компании рано или поздно наступает момент, когда команды начинают жить сами по себе. У каждого своя архитектура, свои приоритеты, свой язык. Долгое время я думал, что главное — это спринты и доски задач. Но со временем заметил: реальные узкие места возникают не в коде, а в головах.
Незнание контекста соседней команды, дублирование решений, конфликт компетенций — вот что на самом деле тормозит работу.
Я расскажу, как на моих глазах пересобрали корпоративную культуру вокруг единого контекста через форматы Techday и «ТехСреда». И почему для меня главная цель таких встреч — не услышать доклад, а сформировать живые связи.
В индустрии популярен миф о «чистой разработке»: сидишь в наушниках, погружаешься в контекст и выдаёшь элегантное решение. Реальный мир устроен иначе. Самые ценные договорённости случаются за пределами досок задач.
Я обратил внимание: перерывы и кофе‑брейки — это не просто время поесть (хотя, не буду лукавить, кушать любят все). Это смена локации, но общение продолжается. И я даже афтепати теперь считаю частью рабочего процесса, потому что не раз видел: договорённость, родившаяся в баре, часто ценнее той, что записана в протоколе совещания.
2. Иллюзия работы и реальность взаимодействия
Я, как и многие, люблю порядок. Спринты, доски в Jira, дэйлики, ретроспективы, бэклог. Всё это создаёт приятное ощущение управляемости: если закрыли 67 задач — неделя прожита не зря.
Но когда я честно посмотрел на то, что на самом деле определяет скорость и качество работы, картинка изменилась.
Самые долгие задержки случаются не тогда, когда код пишется медленно. А когда две недели не могут согласовать API между командами. Когда тикет висит в статусе «нужен комментарий от архитектора», потому что архитектор занят, а его заместитель не в контексте. Когда заказчик готов к пилоту, но ИБ говорит «так нельзя», а коммерсанты говорят «иначе клиент уйдёт».
Для меня это не проблемы кода. Это проблемы связей между людьми и командами.
ТехCреда: попытка договориться на берегу
Я видел, как многие компании пытались решить это классическими способами: заводили общие чаты (где всё тонет), назначали кросс‑командные митинги раз в две недели (где все отчитываются, только о своей работе).
У нас же родился формат «ТехСреда». Для меня это короткая, ритмичная, еженедельная встреча, где мы не решаем задачи, не принимаем судьбоносных решений и не ставим KPI.
Зачем она нужна на мой взгляд? Чтобы выстроить привычку — говорить на одном языке и слышать друг друга.
Каждую среду. Только 60 минут. Одна команда. Мы пробегаем по тому, с чем столкнулись коллеги и как решили, обсуждаем успешные кейсы и способы их реализации и говорим о новых проектах и их возможностях. Без красивых обещаний, без долгих обсуждений, без долгого предисловия. Только факты и контекст.
И самое важное, что я заметил: на этой встрече не просто делятся проблемами — здесь рождаются точки соединения. Оказывается, у команды аналитики есть инструмент, который идеально ложится на боль пресейла. А девопсы неделю мучаются с тем, что безопасники уже решили полгода назад — просто никто не спросил.
Миф о «чистой разработке»
Часто наблюдаю, как индустрия рисует красивую картинку: сидишь в наушниках, открываешь IDE, погружаешься в контекст и выдаёшь элегантное решение. Никто не мешает. Всё понятно.
Реальный мир устроен иначе. Самые ценные договорённости случаются за пределами досок задач.
Приведу пример из моей практики. Две недели команды спорили в Jira о том, как правильно построить валидацию данных на стыке аналитики и безопасности. Кто‑то хотел строгую схему, кто‑то — гибкий пайплайн. Тикеты ходили по кругу, комментарии разрастались до «Войны и мира».
А потом после выступления одной из команда на «ТехСреде» коллеги поехали вместе в метро. Три станции. Семь минут. В этой тесноте, под гул поезда, без Jira и слайдов, нашли компромисс: делаем гибкую схему, но с обязательным аудитом на выходе.
Почему это сработало? Я думаю, потому что в метро нельзя спрятаться за бюрократию. Ты смотришь в глаза человеку, понимаешь его реальную боль, а не читаешь сухой текст тикета.
Принцип кулуаров
Многие компании, на мой взгляд, совершают одну и ту же ошибку: они организуют выступления, лекции, техдни — и запирают людей в зале по расписанию. Выступление закончилось — все разбежались.
Но настоящая магия происходит не во время доклада. А после.
Я для себя назвал это принципом кулуаров — неформальное пространство, где люди могут остаться, задать «глупый» вопрос, поспорить, уточнить, поделиться сомнением.
И я не раз убеждался: часто «глупый» вопрос в кулуарах оказывается тем самым свежим взглядом, который ломает архитектурный тупик. А случайный разговор между девопсом и тестировщиком за кофе рождает решение, которое не пришло бы в голову ни одному из них по отдельности.
Поэтому я теперь сознательно выделяю время на кофе‑брейки, радуюсь, когда программа не забита до отказа, и даже афтепати считаю частью рабочего процесса. Потому что договорённость, родившаяся в баре, для меня часто ценнее той, что записана в протоколе совещания.
3. Techday 2026: Смена парадигмы
Раньше внутренние конференции выглядели красиво, но… предсказуемо. Руководители показывали слайды с достижениями, инженеры вежливо хлопали, а после обеда все разбегались по своим задачам. Для меня это была иллюзия обмена знаниями.
К Techday 2026 я заметил, что подход перевернули. И мне это дало глоток мотивации и роста.
Убрали деление на «сцену для начальства» и «зрительный зал для подчинённых». Вместо этого сделали ставку на горизонтальное сообщество: архитекторы говорят с разработчиками, безопасники — с пресейлом, продакты — с тестировщиками. И говорят они не о том, какие они молодцы, а о том, какие изменения пришлось внести в свои команды, чтобы вывезти сложного заказчика.
От борьбы с противоречиями — к решению задач заказчика
Я встречал на предыдущих местах работы боль любой компании — внутренние войны. Тестирование vs разработка. Пресейл vs архитектура. Аналитика vs безопасность. Однажды я прикинул: на улаживание таких конфликтов уходит до 30% энергии команды. Для меня это не метафора — это три дня в неделю, потраченные на согласования.
Единственный способ выйти из этого круга, как я понял — сделать заказчика единой точкой сборки. Не «кто прав», а «что нужно клиенту». Если все команды понимают его боль, противоречия теряют смысл. Спор о том, чье решение лучше, умирает, когда прилетает инцидент у enterprise‑клиента с 50 000 пользователей.
На Techday 2026 я для себя сформулировал простую цель происходящего:
Поговорить с командами, которые в обычном рабочем процессе не пересекаются со мной, поговорить с коллегами из продуктовых команд, чтобы рассказать что видел я, и услышать, что сделали они.
И ключевой инструмент для этого — ретроспектива. Я раньше её побаивался, а теперь вижу в ней ценность.
От абстракций к живым трекам
Чтобы ретроспектива не осталась в головах, а превратилась в реальные договорённости, второй день разбили на профессиональные секции. Мне это показалось очень правильным:
Архитекторы и технические директора
Разработчики, DevOps, инженеры по качеству
ИБ/СЗИ
Пресейл, внедрение
Почему это работает на мой взгляд? Потому что человек из пресейла не ждёт, что архитектор скажет что‑то полезное для его ежедневных задач. А на Techday они сидят в одной комнате и слышат одни и те же кейсы. И внезапно архитектор говорит: «А давайте мы для следующего тендера подготовим вот такой компромиссный вариант». Для меня это и есть синергия.
Но главное изменение, которое я отметил — мы перестали бояться говорить о своих успехах, и трудностях, которые возможно остаются не решенными на данным момент. Я рад, что сейчас есть возможности делиться внутренними инструментами, наработками и документацией не ссылками на внутреннюю wiki, а со сцены, под запись, и когда потребуется обсудить вопрос, мы уже можем говорить о конкретике.
4. Повестка как отражение зрелости
Когда я начинал готовиться Techday, я боялся, что может темы будут похожи, или они будут звучать как: «модный доклад про промпт‑инжиниринг», «красивая вёрстка нового интерфейса». Но оказалось иначе.
Доклады не были про «модные слова». Они были про боль. Про то, как промышленный конвейер ИИ наконец‑то перестал быть экспериментом и стал инженерной рутиной. Про то, как enterprise‑заказчик заставил пересмотреть святая святых — подходы при внедрении и проектировании архитектуры. Про то, что полировка интерфейсов больше не спасает, если база данных падает под нагрузкой.
Я увидел, как собрали эту боль воедино и назвали повесткой. Потому что зрелая культура — это когда темы года не спускаются сверху, а вырастают из земли.
ИИ как стратегия, а не эксперимент
Год назад слово «ИИ» в заявке на доклад означало для меня: «поиграли с нейросеткой, получили занятный результат, но в прод не пошло». На Techday 2026 картина стала другой.
Не «посмотрите, как мы прикрутили ChatGPT к чатику». А промышленный конвейер. Люди рассказывали, как они выстроили пайплайны данных, как обеспечили воспроизводимость экспериментов, как интегрировали модели в прод с гарантированной задержкой.
И здесь снова сработал принцип кулуаров. В кулуарах после секции «ИИ» встретились ребята из разных команд, но с одной общей целью. Оказалось, они независимо друг от друга написали очень похожие модули для RAG. Вместо того чтобы дублировать усилия, они за полчаса на кофе‑брейке договорились о совместной работе над технологией. Это не попало в программу, но я видел, как это напрямую повлияло на скорость разработки.
Почему это стало возможным? Я считаю, потому что создали среду, где люди не прячут свои наработки, а выносят их на обсуждение. ИИ перестал быть «командой избранных» — он стал общим делом.
Hard tech only: почему мы отказались от полировки интерфейсов
Потому что соблазн показать красивую картинку, новый UI, плавную анимацию очень велик. Это красиво смотрится на презентации и легко считываются сделанные изменения. Но я заметил, что на Techday сознательно убрали это из приоритетов.
Почему? Потому что настоящие инженеры, включая меня, приходят на такие встречи за другим — за фундаментальными вещами.
5. Энергия мотивации говорить об успехах вслух
Технические конференции внутри компании обычно ассоциируются с обменом опытом, архитектурными батлами или разбором инцидентов. Но есть одна важная вещь, о которой редко говорят вслух — мотивация.
В рутине спринтов, дедлайнов и тикетов я иногда теряю ощущение, зачем мы всё это делаем. Особенно когда сложный проект длится полгода, а результат будет виден только после релиза. Techday оказался для меня неожиданным инструментом, который возвращает энергию.
Культура «шаринга»: почему мы стесняемся успеха
В российских IT‑командах (да и не только) есть особенность: про успехи говорить не принято. Считается, что «и так все знают» или «нечего хвастаться, это просто работа». Я сам через это проходил. В результате даже крутые победы остаются внутри одной команды, а соседний отдел узнаёт о них случайно через полгода.
Я столкнулся с этим, когда готовил программу Techday. На призыв поделиться реальными кейсами многие отвечали: «Ну, у нас ничего особенного, просто сделали свою работу». А когда начинали рассказывать детали, оказывалось, что они вытащили проект, который считался провальным, или нашли неочевидное решение, сэкономившее месяцы разработки.
Поэтому я обрадовался, когда публичное признание успехов сделали частью культуры. Не в формате «похвальная грамота», а в формате живого рассказа: «Вот с чем мы пришли, вот где ошибались, вот как выбрались». И я вижу, что это работает.
Эффект сарафанного радио: легитимность сложности
Самый ценный побочный эффект таких историй для меня — снятие страха. Когда инженер из команды аналитики слышит доклад коллеги из пресейла о том, как они внедрялись у крупного заказчика с дикими требованиями по безопасности, он думает не «какие они молодцы», а «значит, и я такое смогу».
Почему это важно? Потому что в работе многие проблемы кажутся уникальными и от того пугающими. Я сам сидел над сложной задачей, не видел выхода и начинал сомневаться: «Может, я недостаточно компетентен? Может, это вообще нерешаемо?»
А потом приходишь на Techday, слушаешь соседнюю команду — и оказывается, что они прошли через то же самое год назад. У них было такое же чувство тупика, но они нашли компромисс, придумали обходной манёвр, договорились с заказчиком. Их рассказ не даёт готового рецепта (потому что контекст разный), но даёт главное — легитимность сложности. Ты понимаешь, что твоя боль — не твоя личная проблема, а нормальный этап роста. И если другие справились, справишься и ты.
Это работает как сарафанное радио: знания не лежат в вики, которую никто не читает, а передаются из уст в уста, через живые истории. И доверие к таким историям на порядок выше, чем к сухим инструкциям.
Энергия на решение задач, а не на войны
Когда у команд появляется единый контекст, отпадает необходимость в тяжёлых административных согласованиях. Я наблюдаю, как люди начинают договариваться сами — потому что они знакомы лично, уважают экспертизу друг друга и понимают общую цель.
«ТехСреда», Techday, ретроспективы — всё это для меня не самоцель. Это способы сделать неформальные связи частью рабочего процесса. Чтобы ключевая договорённость рождалась не в длинной переписке с копией руководства, а в метро, за кофе или после доклада.
Techday для меня — не ивент. Это индикатор здоровья корпоративной культуры. Если после такого дня люди уходят не уставшие, а полные идей и с новыми контактами в телефоне — значит, мы движемся в правильную сторону. Если расходятся сразу после последнего слайда — что‑то сделали не так.
Я перестал тратить энергию на внутренние войны. Вся она уходит на решение задач заказчика. И это, пожалуй, главный результат, который я для себя вынес.
А как у вас организована передача знаний между командами? Удаётся ли превратить внутренние противоречия в синергию? Делитесь в комментариях — обменяемся опытом.
