Почему рост IT — это не про новые команды и инструменты, а про структуру, ответственность и управление сложностью
Привет, Хабр!
Константин Густов, IT-бизнес-партнёр MANGO OFFICE, принял участие в подкасте «Подкаст-подкаст».
В компании Константин отвечает за архитектурные решения и помогает превращать бизнес-задачи в работающие IT-продукты — от оргмодели и команд до платформ и инструментов разработки.
Ниже — основные выводы из разговора про оргструктуру IT-департамента, SAFe-трансформацию, платформенные команды и внедрение ИИ — как в продукты, так и в процесс разработки.
Оргструктура IT-департамента
IT в MANGO OFFICE — отдельный департамент. Он не распределен по бизнес-подразделениям. В его штате около 400 человек.
Внутри департамента четыре отдела по экспертизам: разработка, архитектура, тестирование и инфраструктура.
Роль IT-бизнес-партнёра совмещена с управленческой. Константин Густов руководит архитектурой и курирует часть продуктового портфеля.
Вертикаль управления: руководитель отдела → руководитель направления → техлид. Возглавляет всё CIO.
Как менялась роль: от архитектуры к бизнес-партнёрству
Изначально Константин пришёл в компанию руководить архитекторами и заниматься стратегическим проектированием — подготовкой архитектурных русел в терминологии SAFe.
Постепенно у менеджмента появился запрос на более тесную связь между IT и развитием продуктов. Руководители отделов начали брать на себя роль IT-бизнес-партнёров.
Главное изменение — глубина погружения. Раньше работа была горизонтальной: провели архитектурное исследование, передали в разработку.
Теперь ответственность покрывает и архитектуру, и разработку, и метрики — лидтайм, предсказуемость выполнения планов.
Команды: Scrum внутри SAFe
Компания использует SAFe (Scaled Agile Framework). В основе — обычные скрам-команды от 5 до 9 человек.
В их составе: разработчики, тестировщики, аналитики, дизайнеры. DevOps и SRE (Site Reliability Engineering) организационно стоят отдельно, но функционально относятся к командам.
Особенность SAFe — разделение продуктовой роли:
Product Manager отвечает за стратегию и ценность для бизнеса
Product Owner — за планирование и работу команды
Это помогает синхронизировать продуктовое видение и ежедневное исполнение.
В классическом Scrum или LeSS (Large-Scale Scrum) это одна роль.
Квартальная работа делится на шесть двухнедельных спринтов. В начале периода проводится Product Increment Planning, где каждая команда определяет обязательства. В конце — результат или перенос в следующий цикл. Такой ритм повышает прозрачность, предсказуемость и согласованность между командами.
У команды разработки в agile виртуальная структура. Разработчики, тестировщики, DevOps и владельцы продукта подчиняются разным отделам, но объединяются в команды.
Для визуализации используются инструменты от Confluence до собственных разработок.
Системные команды и SLA
Продуктовая команда отвечает за сопровождение конкретного продукта. Им помогают системные команды.
Техподдержка работает как первая и вторая линия — отсеивает значительную часть инцидентов. Команда системной интеграции поддерживает Kubernetes и GitLab. Администраторы следят за серверным парком.
Ключевой показатель работы — доступность систем. Он измеряется в «девятках». За этим следят не только IT-подразделения, но и отделы продаж.
Такой подход снижает риски сбоев, ускоряет решение инцидентов и позволяет продуктовым командам сосредоточиться на развитии функций, а не на поддержке платформы.
Платформенные команды
Книга Team Topologies во многом описала то, что на практике и так происходило: на одних продуктовых командах далеко не уедешь. Есть задачи, для которых нужна особая экспертиза, – именно из-за них и появляются платформы.
Основная платформа MANGO OFFICE — телефония. Коммутационная часть позволяет звонку проходить через Виртуальную АТС. Низовая инфраструктурная часть реализует протокол VoIP и обеспечивает SIP-телефонию.
Но это не всё.
Сейчас компания запускает решение для разработчиков — единый интерфейс для разрозненных инструментов. Например, ИИ-ассистентов и в перспективе ИИ-агентов.
Ещё одно перспективное направление — Core Reliability Platform. Оно объединит мониторинг, инцидент-менеджмент и чейндж-менеджмент в одном месте.
Усложнение IT-ландшафта усиливает потребность в таких решениях.
Типичная ситуация: две продуктовые команды используют общий компонент, но ни одна не считает его «своим». Отсюда рождается идея новой платформы.
Глазами рядового инженера
Разработчик работает в небольшой кросс-функциональной команде. Основной круг взаимодействия — техлид и владелец продукта.
Первый помогает с вопросами, которые инженер не может закрыть сам. Product owner обеспечивает, чтобы фича дошла до пользователя вовремя.
При выкатке кода подключается DevOps, при инфраструктурных вопросах — администраторы. Продакт-менеджер и руководитель направления нужны для планирования и решения сложных задач.
Все важные задачи обсуждаются на PI Planning — квартальном планировании. Там же команды показывают результаты на демо, а топ-менеджмент дает обратную связь.
Такой порядок снижает риски: разработчик не остаётся один на один с проблемами. Команда работает слаженно, фичи доходят до пользователей быстрее, а критические вопросы решаются на нужном уровне.
Карьерный рост
В MANGO OFFICE развивают сотрудников через Манго Академию. Она отвечает за тренинги, внешние курсы и конференции.
Повышение грейдов привязано к ежегодному пересмотру окладов и согласованию с менеджером и техлидом. Формальных списков критериев нет — решения принимаются исходя из уровня ответственности и показателей сотрудника.
Рост в управленческие роли происходит через наблюдение: талантливые специалисты постепенно получают больше ответственности и новые позиции.
Конкретный пример: человек пришёл разработчиком, через год стал техлидом, ещё через год — получил предложение возглавить группу архитекторов. Из пяти руководителей направлений трое выросли внутри компании.
ИИ в продуктах: вендоры, собственные модели и RAG
В MANGO OFFICE довольно давно поняли – без ИИ продукты потеряют конкурентоспособность.
Компания пошла по пути вендорских решений — например, Речевая аналитика работает на технологиях Яндекса и 3i.
Причина — экономика: содержать собственную инфраструктуру и ML-специалистов было дороже. Решение оказалось рабочим.
Параллельно разрабатываются собственные модели: например, HR-бот полностью работает на нашем «движке». В будущем планируется внедрение своих RAG-решений.
ИИ в разработке: инструменты и ожидания
В разработке ИИ появляется с задержкой в пару лет по сравнению с продуктами.
Как субъект критической инфраструктуры, компания не может отправлять исходный код в западное облако.
Поэтому мы сравнили российские ИИ-решения с Cursor как эталоном. По итогам исследования мы пилотируем GigaCode от Сбера — на взгляд компании, наиболее зрелый облачный ИИ-ассистент на отечественном рынке.
Основные метрики, на которые хочется повлиять с помощью искусственного интеллекта: лидтайм, качество и предсказуемость. Дополнительно — удовлетворённость разработчиков через опросы.
В компании преобладают специалисты уровня middle+ и senior. По бенчмаркам, они получают от ИИ-ассистентов меньший прирост, чем начинающие разработчики. Ожидание — улучшение лидтайма на 15–20% в горизонте ближайшего года.
В будущем за ассистентами последуют агенты – они начнут автоматизировать отдельные функции разработчика. Роль разработчика будет напоминать работу DevOps-инженера — человека, который собирает инструменты в надёжный конвейер доставки.
Agile как часть культуры, а не инициатива IT
SAFe в MANGO OFFICE — фреймворк для всей компании, а не инициатива IT-департамента. Решение о внедрении принимал лично генеральный директор.
Agile охватывает продуктовые и бизнес-подразделения, но не бухгалтерию, продажи, клиентское обслуживание и административные функции.
Опыт показывает: если Agile существует только внутри IT, а остальная компания работает проектно – эффект минимален.
Почему SAFe и как проходил переход
До внедрения SAFe компания работала по водопадной модели: команды получали длинные ТЗ и планировали работу на месяцы вперёд. Это мешало быстро выпускать фичи и видеть реальный прогресс.
Нужен был фреймворк для всей компании, который структурирует роли, процессы и путь поставки ценности.
Нам подошел SAFe. Его роли и зоны ответственности чётко описаны. А внедрение проще и дешевле, чем LeSS или Nexus. Без привлечения внешнего консалтинга.
Переход прошёл постепенно: вместо длинных ТЗ появились пользовательские истории и совместная проработка. Команды адаптировались к новым ритмам, а изменения внедрялись без стресса и «ломки» компании.
Шероховатости SAFe
SAFe работает, но не без нюансов.
Разделение Product Manager и Product Owner создаёт вопросы на стыках ответственности. Компания пробовала два варианта — горизонтальное взаимодействие и вертикальное. Остановились на модели, где PM управляет PO: стратегическое видение должно воплощаться в delivery.
Роль системного архитектора в SAFe отличается от привычной. Это не помощник техлида, а человек на уровне нескольких команд – он задает направление технического развития.
На стыках между архитектором, PM и PO задачи иногда «проваливаются в зазор». Пример: для продуктовой фичи нужен enabler, но его никто не подготовил — «чужая» зона ответственности.
Квартальная каденция создаёт свой эффект: фичи тяготеют к планированию, PBR (Product Backlog Refinement) накапливаются к концу квартала, а в начале могут не проводиться вовсе. Новым сотрудникам нужно время, чтобы понять границы ролей и взаимодействия.
Эти шероховатости не блокируют работу, но требуют внимания к координации. Команды учатся взаимодействовать и выравнивать процессы, чтобы доставка фич оставалась предсказуемой.
Вместо заключения
SAFe — не идеальный фреймворк, но рабочий инструмент. Он помогает масштабировать agile за пределы одной команды и делает процессы прозрачными.
ИИ в разработке и продуктах уже не вопрос «зачем», а вопрос «как именно». Ограничения критической инфраструктуры сужают выбор инструментов, но не останавливают движение вперёд.
Если у вас есть опыт работы с SAFe, платформенными командами или ИИ-инструментами, поделитесь им в комментариях. Это поможет сравнить практики и обсудить реальные кейсы.
