Как мы в SOFROS строили отдел поддержки, а получили сопровождение

Меня зовут Николай Лямин. В IT я уже 25 лет, в SOFROS —  с 2023 года. За это время успел поработать с системной интеграцией, электронным документооборотом, построением крупных команд поддержки и мониторинга для высоконагруженных продуктов ЭДО и электронного факторинга. Работал как с российским, так и с европейским рынком, а также участвовал в развитии решений для электронной коммерции в сегментах FMCG и DIY.

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

Реальность оказалась другой – модель начала ломаться.

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

Сообщение может успешно выйти из внешнего сервиса и дойти до интеграционной платформы, но не обработаться в 1С, REST API может честно отвечать 200 OK, а данные при этом будут падать в ошибку, ERP может принять пакет, но бизнес-процесс на этом все равно остановится.

Очевидно, что специалисту на линии недостаточно понимать только работу самого ПО, маршруты и брокер сообщений. Для нормальной диагностики ему нужно разбираться еще и в 1С, REST API, форматах обмена, авторизации, а иногда и в особенностях конкретного бизнес-процесса клиента. Нужен человек-оркестр.

Каждый интеграционный проект уникален, а контекст проекта критически важен. Проблема почти всегда находится где-то «между», а специалист, который знает только программный продукт, на котором построена интеграция, просто не способен полноценно диагностировать проблему от начала до конца.

При этом бизнесу совершенно не важно, на чьей стороне произошел сбой. Для него существует только одна проблема — сервис не работает.

Перестройка

Линии отлично работают там, где инциденты типовые, а контекст обращения минимален, можно внедрить ИИ помощника. Проще говоря — для монопродукта с понятным набором функциональности.

Интеграционные проекты, если рассматривать их как продукт, устроены иначе. Одна и та же проблема может одновременно потребовать знания самой интеграционной платформы, понимания 1С, особенностей REST API, бизнес-процесса клиента, работы БД и сетевого взаимодействия. Именно поэтому я принял решение расформировывать линии и объединять специалистов в выделенные команды поддержки.

Логика была простой: команда — это люди с разной специализацией, которые дополняют друг друга. Один лучше знает продукт и маршрутизацию, другой —  1С и бизнес-логику, третий — API и базы данных.

Появился результат. Контекст перестал теряться, а накапливался в команде, диагностика ускорилась, сложные инциденты начали решаться совместно, а не через бесконечные переадресации, но почти сразу всплыла новая проблема.По своей сути мы начали двигаться в сторону Scrum и Agile-подхода не в смысле спринтов и «стори поинтов», а в самой идее кросс-функциональной команды, которая совместно решает сложные задачи, но и здесь возникла нестыковка.

Scrum отлично показывает себя в разработке продукта. Мы же строили поддержку:
с инцидентами, SLA, эксплуатацией и постоянным операционным потоком.

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

Просто «собрать людей вместе» недостаточно.

Мы родили монстра!

После всех экспериментов с линейными моделями, командами и «бессознательной» попыткой внедрить Scrum  в процесс поддержки мы провели  мозговой штурм.

Главный вопрос был простой :
«Чем на самом деле занимается служба сопровождения интеграционных проектов?»

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

Во – первых, управление инцидентами и проблемами. Это классическая эксплуатационная история: обмен встал, данные не дошли, бизнес-процесс сломался, интеграция начала работать нестабильно, но поддержка – это не только «тушение пожаров».

Интеграционный контур – живой. Меняются системы, API, форматы, бизнес-процессы и сами регламенты обмена. Поэтому вторым важным направлением стало управление изменениями.

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

Третьим направлением стало управление знаниями.

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

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

Для задач развития и изменений мы сохранили концепцию команды и Agile-подход. Но уже без попытки «натянуть Scrum на поддержку». Agile начал использоваться как инструмент организации работы с изменениями и разработкой.

При этом в каждой команде появился тим-лид. Но не в роли «главного эксперта», через которого проходит все, а в роли сервис-менеджера.

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

Это резко снизило хаос и позволило сохранить гибкость команд без потери управляемости.

А практики ITSM дали самое главное — сервисное мышление.

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

В итоге модель начала выглядеть примерно так.

Если происходит инцидент, он сразу попадает в выделенную команду, которая знает проект и контекст. Команда быстро «гасит» инцидент, потому что в эксплуатации инциденты всегда приоритет №1.

После локализации появляется другая сущность – проблема, которая привела к инциденту. Если для ее устранения нужны изменения, инициируется запрос на изменение (ЗНИ). Он попадает в бэклог команды и далее планируется уже в рамках Agile-процесса.

Если же заказчик приходит с новой потребностью, например, подключить новую систему или изменить процесс обмена – это уже запрос на разработку (ЗНР), который также уходит в бэклог.

При этом любое изменение фиксируется, документируется и обновляет базу знаний.

По сути, на стыке нескольких лучших практик у нас постепенно родилась собственная модель:
ITSM дал сервисное мышление и эксплуатационную управляемость, Agile – кросс-функциональные команды и гибкость изменений, а управление знаниями позволило сохранить контекст и устойчивость эксплуатации.

И, как ни странно, именно этот «монстр» в итоге оказался самым эффективным из всего, что мы пробовали до этого, сформировал обратную связь от Заказчиков, как комфортную и качественно новую культуру услуги сопровождения.

Итог

Плюсы

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

Для клиента появилось настоящее «единое окно» без: «это не наша зона», «мы передали дальше» и бесконечного «пинг-понга» между линиями.

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

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

За счет этого коммуникация стала быстрее, прозрачнее и комфортнее.

Отдельно хорошо сработало самообучение внутри команд.

Поскольку сложные задачи регулярно решались совместно, знания начали распространяться естественным образом. Снизился «фактор автобуса», новые специалисты стали быстрее погружаться в проекты, а сами команды оказалось проще масштабировать под растущий объем задач.

Минусы

Главный — очень долгая перестройка мышления: перейти от  «мы поддерживаем программный продукт» к  «мы сопровождаем сервис и создаваемую им ценность» оказалось намного сложнее, чем внедрить новые процессы или изменить оргструктуру.

Второй минус — время формирования команды.

По нашему опыту, чтобы команда  накопила контекст, научилась работать совместно, распределила роли, начала нормально обмениваться знаниями и стала действительно эффективной, требовалось около 5 месяцев.

Ну и третья проблема – рабочая нагрузка.

Интеграционные проекты в промышленной эксплуатации редко развиваются равномерно. Где-то начинается всплеск инцидентов, где-то идет активная фаза изменений, а где-то, наоборот, наступает временное затишье. Поэтому периодически команды могут простаивать. Для нас это решилось наполнением проектного портфеля команды. Максимально эффективно оказалась схема, когда в команде 1 тим-лид плюс 4 инженера по сопровождению, а в их портфеле 24 проекта. В  такой схеме простои минимальны.

И, наверное, главный вывод, к которому в итоге пришли:

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