Привет, Хабр! Это заключительная статья из цикла о трансформации инженерной службы — из хаотичной и недостаточно обученной команды в структурированный профессиональный департамент с автоматизированными процессами.

В первой статье я рассказывал, как вообще навести порядок в хаосе: оценить зрелость команды, создать процессы с нуля и превратить группу разрозненных инженеров в команды, которые реально работают вместе. Вторая была про то, как мы объединили внедрение и техподдержку в единую систему, запустили ботов, ввели клиентских менеджеров и прекратили внутреннюю войну между отделами.

А сегодня — финал. Professional Services 3.0. Это история о том, как мы отказались от классической иерархии в пользу автономных отрядов, научились внедрять проекты круглосуточно и превратили техподдержку из вечно тушащих пожары ребят в проактивную службу, которая решает проблемы до их появления.

Философия PS 3.0: от иерархии к автономным отрядам

Классическая иерархия, которая неплохо работала на 20-30 человек, начала нас откровенно душить. Ребята, которые вполне могли принимать решения сами, ждали одобрения руководителя просто по привычке. В общем, типичная картина разросшейся структуры, когда все процессы начинают буксовать.

Решение пришло из неожиданного источника — от Spotify и их модели с Squad, Tribe и Chapter. Если коротко: вместо классических отделов создаются небольшие автономные команды (Squad), которые объединены в племена (Tribe), с горизонтальными связями через гильдии (Chapter и Guild). Главная идея — дать командам максимальную свободу в принятии решений. Минимум бюрократии, максимум скорости. Автономная команда сама решает, как достигать целей, а руководство только убирает препятствия с пути.

Забегая вперед, скажу, что переход от «классики» к отрядам занял почти полгода. В результате у нас появились небольшие автономные отряды с техлидом во главе. Каждый отряд получил полную ответственность за свой участок: регулярные встречи, разбор тикетов, управление проблемами, авариями, планирование обучения. И самое важное — право на ошибку.

Этап 1. Подготовка

Первым делом я посмотрел на нашу структуру свежим взглядом. Где застревают задачи? Где движение тормозится? Потом начал анализировать, что именно можно делегировать командам без риска все сломать. Потому что делегировать все сразу — это путь к хаосу. А делегировать только мелочи — имитация автономности.

Параллельно готовил техлидов. Честно говоря, не все были готовы — кто-то не был уверен в своих силах, кто-то просто привык получать четкие указания сверху. Нужно было объяснять, в том числе  на примерах, что значит брать ответственность по-настоящему, как принимать решения и как работать с рисками. 

Этап 2. Пилот

Для эксперимента взяли два отряда — один из внедрения, один из поддержки. Дали им полную автономию в рамках их продуктовой зоны. Техлид и команда сами решали все:

• Как обучать новичков;

• Когда и как проводить синхронизацию отряда;

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

• Когда делать ретроспективы.

Чтобы все не скатилось в хаос, ввели минимальный набор правил — «рамки автономии»:

• Все, что влияет на SLA или бюджет, согласовываем с delivery-лидом;

• Если команда уперлась в стену и не может решить проблему — поднимаем флаг, просим помощь;

• Каждая задача должна быть проработана так, чтобы все участники понимали путь решения;

• Новый опыт фиксируем для других команд в базе знаний.

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

Этап 3. Масштабирование

Спустя несколько месяцев пришла пора собирать результаты. И вот что получилось: у пилотных отрядов скорость первых ответов выросла на 23%, показатель «пин-понг» (когда тикет гоняют туда-сюда между специалистами) снизился на 65%, скорость закрытия аварий увеличилась на 70%. Плюс, выросли качество и скорость внедрения.

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

Мы начали масштабировать модель на всю службу. Старая иерархия не исчезла — она трансформировалась. Delivery-лиды и тимлиды стали не начальниками, а тренерами и фасилитаторами, которые убирают системные барьеры.

Проблем при переходе, как ни странно, почти не было. Ну то есть были, конечно, вопросы с расписанием встреч — в какой-то момент некоторые сотрудники оказались привязаны к двум или даже трем отрядам одновременно. Но через несколько итераций перепланирования вышли на рабочую модель.

Ближе к завершению встал вопрос синхронизации между отрядами. Решили так:

• Ежедневные встречи полностью превратились во встречи внутри отрядов;

• Ретро — тоже внутри отрядов;

• С тимлидом и delivery-лидом встречаются лидеры отрядов;

• Завели общую Kanban-доску с разбивкой по отрядам;

• Добавили встречи для синхронизации между отрядами и обмена опытом.

И еще одна мелочь, которая оказалась важной — мы дали отрядам право выбрать себе названия. Захотели называться «Фантик»? Пожалуйста! Вроде бы ерунда, но работает на вовлечение. У людей появилась идентичность.

Новая матрица зрелости

О первой попытке измерить зрелость команды я рассказывал в первой части. Вкратце, я оценивал, кто из инженеров в каких продуктах разбирается. Примитивно, но на тот момент работало — мне просто нужно было быстро понять картину. Для PS 3.0 этого было недостаточно, возникла необходимость в более серьезном инструменте.

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

Оценка выставляется в процентах, от 0 до 100, и включает 5 уровней с четкими критериями. Переход между уровнями подтверждается экзаменами и лабораторными работами. От тестов отказались — они плохо отражали реальные знания. Чтобы достичь пятого уровня и получить звание эксперта, нужно закрыть все предыдущие этапы и набрать минимум 90% по компонентам продукта. Это непросто. Это реально сложно. И все же в команде уже есть ребята, которые дошли до этой отметки. Их мало, и это нормально — мы не стремимся превратить всех в суперэкспертов.

Компоненты продуктов разбили на девять ключевых категорий:

• BASE — базовые настройки системы

• AUTH/LDAP — аутентификация и авторизация

• CLUSTER/LOADBALANCING — кластеризация и балансировка нагрузки

• WEB — веб-серверы и приложения

• DB — базы данных (Mongo, Postgres и другие)

• STORAGE — системы хранения

• VIRT — виртуализация

• NETWORK — сети

• DISPLAY — графическая подсистема

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

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

Во-вторых, это создаст на инженеров нагрузку, которой они не просили. Люди пришли работать, а не учиться 24/7. И если ты начнешь требовать от всех постоянного обучения и бесконечных экзаменов, получишь не команду экспертов, а выгоревших людей, которые уйдут при первой возможности.

Идеальная структура команды напоминает бриллиант: много Middle-специалистов в ядре, достаточное количество Senior на вершине, а внизу пространство для Junior, которые будут расти. 

Матрица зрелости стала основой для грейдов и карьерного пути. И вот это, кстати, дает один из самых ценных эффектов: каждый инженер теперь видит, какие компетенции нужно развить для перехода на следующий уровень. Хочешь стать senior? Вот список требований. Не абстрактный «надо больше опыта», а конкретные навыки и знания. Прозрачно и понятно. Либо ты выполнил требования, либо нет. И это работает на мотивацию куда лучше, чем любые корпоративные тренинги по вовлеченности.

Инженерная гильдия

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

Ключевое слово — «самоорганизующаяся». Участие добровольное. Потому что помним про нагрузку на инженеров, да? Если ты заставишь людей участвовать в гильдии принудительно, получишь ровно то, что обычно получается от принудительных корпоративных активностей — скучающие лица, формальные отписки и минимальную вовлеченность. Руководителя в гильдии нет, вместо него — фасилитатор (эта роль может ротироваться внутри команды). Его задача не управлять, а помогать процессу двигаться вперед. 

Приведу пример того, к чему мы стремимся. Допустим, в нескольких проектах по внедрению Basis Dynamix инженеры сталкиваются с одной и той же проблемой: при обновлении кластера вылезает ошибка TLS handshake timeout. Сейчас каждый решает ее по-своему — кто-то перезапускает ноды вручную и надеется, что поможет, кто-то начинает менять таймауты в конфигах методом тыка, кто-то сразу зовет коллег из Solution и перекладывает проблему на них.

А вот как должно работать в идеале — и к чему мы идем:

1. Инженер не молчит, а поднимает проблему на встрече гильдии

   Не просто «у меня тут что-то не работает», а делится логами, своим решением (увеличил timeout в cluster.conf), объясняет контекст и выдвигает гипотезу — при большом объеме данных TLS-рукопожатие не укладывается в стандартные 10 секунд. То есть не просит решить за него, а предлагает свое видение и просит валидации.

2. Коллеги добавляют контекст

   Инженер из поддержки говорит: «Стоп, у нас пять тикетов за последний месяц с точно такой же проблемой». Архитектор из Solution подтверждает — это известная проблема при обновлении кластеров больше 50 нод, и предлагает более надежное решение через флаг --tls-async, который появился в последнем релизе.

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

3. Гильдия формирует общее решение

   Не просто «ок, запомнили», а пишется инструкция «Обновление крупных кластеров Basis Dynamix с автоматической проверкой размера кластера и подстановкой нужного флага». Плюс Bash-скрипт для безопасного применения, чтобы следующий инженер не изобретал велосипед заново.

4. В течение трех дней решение проходит валидацию и публикуется

   Скрипт проходит code review в гильдии (потому что если ты публикуешь скрипт, который все будут использовать, он должен быть качественным). Решение публикуется в базе знаний с тегом #basis-dynamix #update #tls. И автоматически добавляется в онбординг-чеклист для новых инженеров.

5. Эффект масштабируется

   Через две недели ошибка исчезает из тикетов. Solution больше не получает запросов по этой теме — люди сами справляются по инструкции. А PS заводит задачу в разработку — предлагает включить флаг --tls-async по умолчанию в следующем релизе, чтобы проблема вообще перестала существовать.

Вот это идеальная картина. А что у нас сейчас? Сейчас у нас есть профильные чаты по продуктам, где инженеры оперативно делятся кейсами. Уже прогресс по сравнению с тем, что было раньше — разрозненные знания в головах отдельных людей, которые работают как черный ящик: «Вася знает, как это чинить, но он в отпуске». Специалисты Solution берут эти обсуждения, превращают их в статьи для базы знаний и обучают нашего «цифрового техлида» — ИИ-ассистента, который помогает инженерам быстрее находить решения. Однако до полноценной гильдии — с регулярными техтоками, культурой коллективного обучения, когда инженеры сами активно пишут инструкции и проводят воркшопы — нам еще расти и расти.

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

Переходим в режим 24/7

Ключевая идея PS 3.0 — универсальные инженеры и система ротации. И внутри отрядов, и между продуктовыми направлениями. У нас одинаковый технологический стек, продукты разные, но базовые принципы схожи. С помощью матрицы зрелости можем быстро подтянуть нужные компетенции инженера и повысить его универсальность.

Нужно усилить техподдержку? Берем инженеров из внедрения. Большой проект требует дополнительных рук? Подключаем специалистов из поддержки. Вместо бесконечного найма получили гибкость.

Универсальность нужна нам, например, для запуска круглосуточного внедрения. И это не метафора. Помните отряд на востоке страны из прошлой статьи? Камчатка, Владивосток — там день, когда у нас глубокая ночь. Мы провели обучение процессам и задачам внедрения для ряда инженеров этого отряда. Провели аттестацию — и теперь можем запускать круглосуточный процесс внедрения. По-настоящему.

Допустим, проект внедрения начинается в Москве. Вечером московская команда передает эстафету коллегам с Дальнего Востока, которые продолжают работу. Утром москвичи получают готовый результат и двигаются дальше. Круглосуточная разработка — штука известная, а вот круглосуточное внедрение — это действительно новое слово.

Процессы выстроили так, чтобы между отрядами была синхронизация с учетом временных зон. Задачи формируются в системе управлению проектами, они декомпозированы и персонализированы. Дальше — обычная модель передачи задачи «от смены к смене». Ничего сложного, но работает.

Program-менеджеры расширяют горизонты

Раньше мы видели проекты за месяц-два вперед. Максимум. Для операционного планирования этого катастрофически мало. КАМы (клиентские менеджеры) приносили задачи, когда контракт уже почти подписан, клиент ждет старта на следующей неделе, а мы судорожно думаем: «А кто это будет делать? А у нас вообще есть свободные инженеры?»

В результате нельзя заранее подготовить людей, подтянуть нужные компетенции. Увидеть, что через три месяца у тебя образуется провал в ресурсах, а еще через два — наоборот, простой. Живешь от аврала к авралу, постоянно все срочное, постоянно кто-то кому-то что-то должен был вчера.

Решением стало создание новой роли — Program Manager (PRM). Эти специалисты работают с КАМами на самом раннем этапе — когда появляются лиды, а не готовые контракты. Когда клиент только начал разговор, когда еще идут переговоры о цене и сроках, PRM создает задачи в системе управления проектами задолго до подписания договора. 

Да, там куча неопределенности. Может закроется, может нет. Но PRM показывает вероятность закрытия, предполагаемые сроки, степень готовности проекта к запуску, нужные компетенции. И мы видим всю воронку. Можем заранее планировать обучение, привлечение подрядчиков или перераспределение ресурсов между отрядами. Из режима постоянного цейтнота перешли к стратегическому планированию. Выдохнули, в общем.

Сейчас прорабатываем метрики для оценки эффективности PRM. Насколько точны их прогнозы? Сколько лидов реально закрываются в сделки? Как это влияет на загрузку команды? Но уже понятно без всяких метрик — эта роль сработала. Она разгрузила КАМов от операционки. Раньше они параллельно пытались продавать, вести переговоры и еще следить за ресурсами для проекта. Теперь продажами занимаются КАМы, а ресурсным планированием — PRM. Каждый делает свое.

И она сделала наш бэклог прозрачным и управляемым. Мы знаем, что нас ждет. Не на 100%, но достаточно, чтобы не тушить пожары каждый день.

Больше чем поддержка

Professional Services 3.0 — это не только «ваш звонок очень важен для нас» и «перезагружать пробовали?». Это проактивная помощь. Лучший пример — наша работа с мониторингом клиентских систем.

Оказалось, что у многих заказчиков проблемы с мониторингом наших продуктов. Причины разные: от банальной нехватки экспертизы до нежелания тратить на это ресурсы. Мы могли бы пожать плечами — мол, не наша зона ответственности, разбирайтесь сами. Но быстро поняли: отсутствие мониторинга у клиента означает больше аварий и внеплановых звонков для нас. Хорошо если не в три утра по Москве.

Поэтому разработали набор шаблонов для Zabbix, специально заточенных под наши продукты. Приходим к клиенту и говорим: «Вот готовая библиотека для мониторинга, берите, используйте». Если у заказчика есть собственные наработки — обмениваемся опытом, забираем интересные решения к себе.

Выигрывают все: клиент получает качественный мониторинг, мы — меньше звонков ночью. Сейчас эту услугу упаковываем в отдельную опцию — помощь в настройке системы мониторинга с последующей передачей ее службе эксплуатации заказчика.

Следующий шаг — разработка ИИ-агентов, которые будут анализировать состояние продуктов у клиентов и предиктивно реагировать на потенциальные проблемы. Не ждать аварии, а предотвращать ее до того, как что-то сломается. Вот к чему мы движемся.

Заключение: от хаоса к стратегическому преимуществу

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

PS 1.0 научил нас превращать хаос в порядок, создавать команды и процессы с нуля. PS 2.0 показал, как объединить разные функции в единую систему, автоматизировать рутину и сделать клиентский опыт бесшовным. PS 3.0 довел эволюцию до логического завершения — мы получили гибкую, автономную структуру, способную быстро адаптироваться к любым вызовам.

Команда универсальных инженеров, которые могут работать в любом направлении. Система круглосуточного внедрения, которой нет ни у кого на рынке. Проактивная поддержка, которая решает проблемы клиентов до их появления. Горизонт планирования на год вперед вместо хаотичных авралов.

Три года назад разработчики тратили половину времени на проблемы, которые должен был решать Professional Services. Сегодня они занимаются тем, что умеют лучше всего — создают продукты. А мы обеспечиваем их успешное внедрение и поддержку на уровне, которого ожидают клиенты.