|
Professor Seleznov
|
Введение
Привет, Хабр. Я Александр Габидуллин. Инженер внедрения в «Группа Астра», но на 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 для меня — не ивент. Это индикатор здоровья корпоративной культуры. Если после такого дня люди уходят не уставшие, а полные идей и с новыми контактами в телефоне — значит, мы движемся в правильную сторону. Если расходятся сразу после последнего слайда — что‑то сделали не так.
Я перестал тратить энергию на внутренние войны. Вся она уходит на решение задач заказчика. И это, пожалуй, главный результат, который я для себя вынес.-А как у вас организована передача знаний между командами? Удаётся ли превратить внутренние противоречия в синергию? Делитесь в комментариях — обменяемся опытом.-Источник
|
