Привет, Хабр! Меня зовут Денис Романов, и я руковожу подразделением Professional Services в компании «Базис». Мой путь в IT начался с позиции системного администратора (тогда еще никто не знал слова DevOps), а со временем я перешел на руководящие должности: был IT-директором, директором по развитию, CPO. Несколько лет назад мне предложили возглавить подразделение Professional Services, ответственное за внедрение продуктов «Базис».

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

Поскольку я рассматривал все функции компании как части единого продукта, то подошел к развитию Professional Services как к созданию нового продукта, ориентированного на клиента и управляемого метриками.

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

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

Исходная ситуация

«Базис» — это объединение трех компаний с разными командами, которые занимались развитием своих продуктов, их внедрением и обслуживанием. Каждая команда жила в своей вселенной с ее культурой, подходами к работе и даже языком общения. Одной из главных задач руководства стала настройка процессов взаимодействия команд, создание единого продуктового портфеля и т. д.

Моей зоной ответственности было подразделение Professional Services (PS), занимавшееся на тот момент только внедрением. Тогда оно представляло собой небольшую группу инженеров, каждый из которых знал только часть продуктов. О какой-либо стратегии развития речи не шло вообще. Процессы? Хаотичные и неоптимальные. Управление построено на личных связях — кто кого знает, тот к тому и обращается. Единого хранилища информации о проектах не существовало. Базовые инструменты для эффективной работы отсутствовали, проектных артефактов либо не было вовсе, либо их требовалось полностью переписывать. Сами проекты не имели стандартизированных идентификаторов — каждый называл их как вздумается. Узнать статус проекта без прямого контакта с исполнителем было невозможно. Проектный офис (PMO) имел смутное представление о самих продуктах. В такой ситуации говорить об эффективности подразделения было сложно.

И на фоне этого хаоса разработчики, оказавшиеся едва ли не единственными носителями актуальных знаний о продуктах, практически превратились в многостаночников. Помимо написания кода они внедряли продукты, устраняли аварии, встречались с клиентами, участвовали в приемосдаточных испытаниях и создавали проектную документацию. По сути, выполняли те функции, которыми должны были заниматься специалисты Professional Services (PS).

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

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

Оргструктура съедает стратегию на завтрак

Мне нужно было понять, с какими проблемами мы сталкиваемся, какие потребности есть у клиентов и какие задачи стоят перед подразделением. Для этого я проанализировал услуги, которые компания уже предоставляла, даже если они формально не входили в портфель Professional Services.

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

Я люблю выражение: «Культура съедает стратегию на завтрак». К нему я часто добавляю: «Организационная структура тоже закусывает стратегией». Поэтому первым делом я сосредоточился на базовых элементах — команде и её структуре

Мой подход к развитию был последовательным: сначала — построение эффективной команды, затем — настройка процессов и лишь после этого — работа над продуктом. Без людей нет процессов, а без процессов нет качественного продукта.

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

Полученные данные оказались тревожными — уровень знаний составил всего 19%. Большинство сотрудников были знакомы лишь с несколькими продуктами компании, о других же не имели даже базового представления.

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

Трансформация команды PS v. 1.0

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

Первым делом требовалось разделить команду на два направления (юнита) по флагманским продуктам: Basis Dynamix и Basis Workplace. Неидеальный вариант, но мне нужно было быстро повысить компетенции, поэтому я сфокусировал группы на конкретных продуктах.

Затем я разработал новую организационную структуру, в которую включил новые роли. Разделение не только позволило сфокусироваться на разных продуктах, но и заложило основу для будущих автономных команд. Для каждого юнита я согласовал выделение деливери-лида — человека, отвечающего перед мной за результаты внедрения. Также появилась роль технического лидера.

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

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

От хаоса к системе

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

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

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

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

Следующим шагом стала совместная работа с коммерческим отделом и PMO по созданию в Miro первого процесса для PS. Мы согласовали правила игры: кто и как заводит заявку, как она движется, какие артефакты должны сопровождать этот процесс и по каким критериям он оценивается. Так был сделан первый маленький, но важный шаг, позволивший трем разным службам — продажам, PMO и внедрению — договориться о правилах взаимодействия.

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

Мы модернизировали техландшафт (Свод конфигурации и требований к окружению для инсталляции продуктов Basis): пусть он и остался в таблице, но теперь стал функциональным — с чек-листами, которые объясняют, что и как заполнять. Затем собрали обратную связь от клиентов и внедрили для них онбординг. Все это позволило нам выйти на обновленную версию процесса, более удобную и эффективную.

С коммерческой службой мы договорились ввести уникальные ID для проектов, чтобы отслеживать их судьбу на всех этапах. Другими словами, внедрили базовые стандарты, которые должны были существовать в PS с самого начала.

Разобравшись с основными процессами, я вернулся к управлению проектами. Поскольку таблицы был временным решением, мы решили мигрировать на полноценную систему управления проектами и wiki-платформу.

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

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

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

Формирование корпоративной культуры

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

• прозрачность;

• доверие и автономию;

• свободный обмен знаниями;

• культуру обратной связи;

• признание и благодарность.

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

Для воплощения этого принципа я:

1. открыто разместил стратегию развития PS;

2. сделал информацию о текущих проектах доступной для всей команды;

3. сформировал реестр наших встреч, с указанием целей и ответственных;

4. ввел регулярные ретроспективы, где мы делились мыслями и ставили оценку прошедшему спринту;

5. добавил регулярные встречи, на которых я коротко рассказывал о достижениях департамента и новостях компании;

6. публиковал результаты регулярных встреч.

Все хорошо? Да ладно!

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

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

Помню, спрашиваю:

— Что было сложно в этом спринте?

— Все хорошо.

— Не может быть, чтобы все было идеально! Вот здесь мы не уложились в срок, а там клиент остался недоволен.

Ретроспектива стала важным этапом не только в развитии процессов, но и в адаптации команды к новому способу работы.

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

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

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

Позже я ввел практику оценки завершившегося спринта и возможность оставлять комментарии. Так шаг за шагом в инженерной среде были реализованы практики из разработки: оценка, планирование, списание времени, стендапы (которые стали называть дейли), ретроспективы. Затем мы ввели метрики по результатам ретроспектив, перешли на специальные онлайн-сервисы и организовали подобные встречи с коммерческим блоком.

За год мы автоматизировали создание плана-графика и декомпозицию проекта на группу подзадач для инженерной Kanban-доски. Когда инженеры списывают время, план-график у PM меняет цвет в зависимости от скорости выполнения задач — краснеет при отставании или зеленеет при опережении графика. Менеджеру проекта больше не нужно было дергать инженеров вопросами о статусе задач.

Добро пожаловать на борт

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

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

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

Завершает процесс обязательная аттестация и обратная связь от самого новичка — мы оцениваем не только его готовность, но и качество самого онбординга. На момент написания статьи внутренний NPS (индекс удовлетворенности) составлял более 70% со средней оценкой 8,9 из 10.

Раньше новичок мог потратить на обучение несколько месяцев, зачастую получая при этом обрывочные и неактуальные знания. Аттестация не проводилось вообще, решение о готовности к работе руководитель принимал «на глаз». Благодаря новому процессу мы сократили срок адаптации сотрудников и быстрее выводим их «в поля» — но только после успешной аттестации. Например, время обучения перед первым проектом сократилось вдвое — до 2–3 недель. Первым деливери-лидам и инженерам я проводил аттестацию лично, потом делегировал эту задачу самим деливери-лидам.

Результаты трансформации

Нам удалось поднять уровень зрелости команды с 19% до 87% — это серьезный скачок. Сейчас мы пересматриваем сам подход к оценке: в 2022 году была важна оперативная диагностика, а к настоящему моменту мы разработали новую модель — «Зрелость 2.0». Она предлагает более детальную методику, адаптированную под новые вызовы и масштабирование направления.

Среднее время внедрения проектов сократилось на 40%. Полностью исключить участие разработчиков за этот год пока не получилось, но объем запросов к ним значительно снизился — и они это отметили и оценили.

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

Блеск и нищета PS

Как упоминал выше, одновременно с построением единой команды и выстраиванием процессов я работал над стратегией. В ее основу легли три ключевых принципа: адаптивность, эффективность и управляемость. На момент моего прихода «Базис» уже успешно работал как продуктовая IT-компания, но в развитии направления Professional Services я увидел нечто большее, чем просто дополнительный источник дохода.

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

Финансовая сторона тоже выглядела привлекательно: услуги могли увеличить LTV клиента и снизить зависимость от продажи лицензий. Но главным стимулом стала возможность создать на базе отечественного вендора сервис уровня западных компаний и обеспечить «Базису» серьезное конкурентное преимущество.

Я не хотел, чтобы Professional Services был просто техподдержкой, внедрением продуктов или центром компетенций. Моя цель была более амбициозной — превратить его в стратегический инструмент, который поможет компании масштабироваться, удерживать клиентов и адаптироваться к изменениям.

Через несколько месяцев после начала работы я разработал полноценную стратегию развития Professional Services на 2023 год (как давно это было!). В ней четко обозначил цели, принципы реструктуризации команды, новые процессы и описал, каким через год должен стать продукт под названием Professional Services.

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

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

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

Это сложно? Не просто сложно — чертовски тяжело.

Стало ли нам лучше? Да — значительно лучше.

Будет ли еще лучше? Обязательно.

О том, какие еще шаги были сделаны и какие цели мы ставим перед собой на ближайших этапах, расскажу в следующих материалах.

Вместо заключения: как из хаоса создать команду

Подводя итоги, предлагаю список рекомендаций из моего опыта:

• Начните с helicopter view — посмотрите на ситуацию с высоты, чтобы увидеть картину целиком, а не детали (отдельные проблемы).

• Разработайте стратегию — определите долгосрочные цели и пути их достижения.

• Оцените зрелость команды — поймите, откуда именно стартуете. Это не только точка отсчета для измерения прогресса, но и карта проблемных зон.

• Разделите команду на юниты по продуктам — это обеспечит фокус и поможет людям стать настоящими экспертами в конкретной области.

• Запустите обучение продуктам — люди должны досконально знать то, с чем работают. Иначе как они будут принимать верные решения?

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

• Создайте единое место управления проектами — хотя бы табличку на первое время.

• Наладьте управление потоком задач — для их своевременного решения, обеспечения прозрачности и оптимизации ресурсов.

• Внедрите спринты — работа итерациями позволяет быстрее получать обратную связь и корректировать курс.

• Введите оценку — это обязательный элемент (пусть даже экспертную на начальном этапе).

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

• Внедрите Daily — команда должна регулярно синхронизироваться и обсуждать, насколько ближе она стала к цели.

• Внедрите ретро — без анализа ошибок вы будете вечно наступать на одни и те же грабли.

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

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

• Создайте систему онбординга — чем быстрее новички станут эффективными, тем лучше для всех.

• Измеряйте все, что можно измерить, — то, что не измеряется, не улучшается.