В первой части я рассказал, как вместе с командой превратил небольшую группу инженеров в структурированное подразделение Professional Services (PS). Вкратце: за год подняли зрелость команды, сократили время внедрения продуктов и почти полностью освободили разработчиков от задач, не связанных непосредственно с разработкой.
Казалось, многое уже выполнено, и надо реализовывать планы по дальнейшему улучшению PS, но жизнь внесла коррективы — мне предложили взять на себя еще и техническую поддержку. До этого в состав PS уже вошла команда проектного офиса (PMO) – что вполне логично, ведь мы работали с проектами – и это заметно усилило PS. Сначала я сомневался, стоит ли браться за техническую поддержку, ведь до этого моя карьера была сосредоточена на разработке и продуктах. Однако взглянув на ситуацию с высоты (тот самый helicopter view из предыдущей статьи), я увидел возможность значительно улучшить качество оказываемых заказчикам услуг.
Техническая поддержка (ТП) — это искусство превращать «упало, пропало, не запускается» в «работает, дышит, живет». Это перекликалось с моим видением PS, и, оценив стратегические возможности, я понял, что присоединение ТП — это правильный шаг для создания целостного продукта вокруг клиента. Мы в PS не только проектируем и внедряем решения, но и обеспечиваем их жизнеспособность на всех этапах — от первого контакта до долгосрочной поддержки. Таким образом, заказчик получает единую точку входа на всем цикле использования продукта.
В этой статье расскажу, как мы создали PS 2.0 — объединили внедрение и техподдержку в цельную команду, добавили автоматизации и помощников, а также организовали процессы так, чтобы команда работала круглосуточно, но без ночных смен.
Вступаем в наследство
Когда я погрузился в существующие процессы техподдержки, стало ясно, что мы столкнулись с амбициозной задачей — трансформировать команду, в которой доминировали ручные процессы и разрозненные коммуникации. В таких условиях каждое направление поддерживалось буквально единицами, а большинство сотрудников занималось решением «горящих» задач. Времени на остановиться, подумать, запланировать и сделать правильно просто не было. Это напомнило мне первые дни в PS, но и вдохновило: ведь мы уже проходили этот путь и знали, как выстроить систему, которая работает.
Еще одна проблема — «борьба бастионов». Клиент обращается в техническую поддержку с запросом, и начинается… Техподдержка отвечает: «Это вопрос для внедрения». Специалисты PS говорят: «Проект уже закрыт — это задача поддержки». В результате клиент перекидывается между отделами, решение его запроса недопустимо затягивается.
Кто же в ТП помогал решать самые сложные проблемы? Опять разработчики. Их постоянно привлекали к разгребанию аварий, ребята работали по ночам, разбирались с проблемами, которые должна была решать техническая поддержка. Ситуацию нужно было срочно менять. К счастью, помимо дежа вю, работа в PS дала мне опыт, а также важное преимущество — команду инженеров, прошедших огонь, воду и медные трубы. Наконец, у меня было ясное понимание того, куда двигаться.
Поэтому образ на этот год был вот таким:
Объединяем активы
Интеграция двух команд — это не только изменение в структуре, но и важный шаг в формировании единой культуры, без разделения на «ваших» и «наших». Уже существующие юниты по направлениям я дополнил группами ТП, что позволило в короткие сроки повысить качество обработки задач по продуктам.
Ввели совместные встречи с инженерными командами группы внедрения, осуществили небольшую ротацию специалистов из этой группы в группу поддержки. Параллельно запустили тот же цикл, что и ранее: оценка зрелости, аттестация, онбординг. К сожалению, часть команды пришлось заменить — одни не хотели меняться, другие просто не дотягивали до нужного уровня. Сильных инженеров подняли в техлиды, изменили систему мотивации, запустили управление знаниями и улучшили принцип работы ночных смен.
На последнем остановлюсь отдельно. По моему опыту, на ночные смены чаще всего выходят либо специалисты с особыми предпочтениями в графике работы, либо те, для кого такая работа — временная ступень в карьере. Текучка кадров в результате высокая, поэтому выстроить устойчивый и качественный сервис в таких условиях — крайне сложно.
У прошлого руководителя была отличная идея, которую мы довели до ума: инженерные бригады с востока страны. Камчатка, Владивосток — там уже вполне белый день, когда у нас еще ночь, и никого не нужно «убивать» бессонными дежурствами. Удаленная работа в компании приветствовалась, поэтому мы продолжили поиск сотрудников именно в той части России (спойлер: нашли).
Помогаем клиенту
Одним из самых важных нововведений стало появление клиентских менеджеров — наших «бизнес-партнеров клиента» внутри компании. Такой менеджер отстаивает интересы конкретного заказчика, знает статусы его проектов и еженедельно готовит аналитические отчеты, на регулярной основе собирает обратную связь о качестве нашего сервиса и продуктов.
Эта роль требует развитых навыков коммуникации, поскольку задача менеджера — выступать связующим звеном между компанией и клиентом, находя баланс между их целями. Поэтому я всегда видел клиентского менеджера как канатоходца.
Клиентский менеджер знает все: где что делается, кто за что отвечает, когда будет результат и даже что нужно улучшить. Конечно, у клиента есть свой проектный менеджер, но именно клиентский менеджер видит картину целиком и всегда рядом, если что-то непонятно. Его цель — обеспечить customer care, когда клиент чувствует, что его интересы не просто услышали, а действительно поддерживают. И вы бы видели, как они защищают интересы своего клиента и действительно «топят» за него! Или предупреждают о возможных проблемах. Получить сообщение «Денис, чувствую, что через неделю будет эскалация», конечно, не очень приятно, но при этом клиентский менеджер объясняет причину, и у нас появляется возможность решить проблему до того, как она перерастет в кризис.
Развиваем собственные компетенции
С развитием PS возникла потребность в создании промежуточного уровня — команды, которая могла бы брать решение сложных вопросов на себя, вместо того чтобы носить их разработчикам. В прошлой статье я упоминал, что совсем отказаться от их помощи у нас не получилось, зато получилось ее минимизировать и упорядочить. И все благодаря Solution Services — центру компетенций, объединяющему специалистов с глубокими знаниями о продуктах. Он стал вышеупомянутым промежуточным уровнем.
Постепенно роль центра компетенций выросла от внутренней поддержки до полного замещения разработки в ряде внешних задач. Он эволюционировал в самостоятельное направление внутри PS, играющее ключевую роль в масштабировании и устойчивости сервиса, а также автоматизации под наши задачи.
Одновременно мы договорились с технической дирекцией: как только чувствуем себя готовыми — начинаем участвовать в планировании задач для разработчиков. Чтобы команда видела, куда двигаются продукты, и могла заранее готовиться и отстаивать свои задачи. Теперь, когда свежий билд готов, он не сразу уходит в прод. Сначала мы «проходимся» по нему глазами — не ищем баги (это задача QA), а смотрим как его внедрить, поддерживать и донести информацию о нем клиенту. Если коротко, то QA тестирует работу релиза, а мы — его применение в реальном внедрении.
Автоматизируем результат...
Без автоматизации техподдержка — это бесконечные звонки, путаница и выгорание. С ней — быстрая реакция, четкие процессы и возможность увидеть проблему до того, как она превратится в аварию. Выбор был очевиден, поэтому далее приступили к автоматизации управления инцидентами.
Мы разработали и утвердили первую версию «Аварийного регламента», а затем автоматизировали этот процесс. Теперь при обращении клиента через тикетную систему бот автоматически запускает большую часть шагов из регламента. Он создаёт чат с участием деливери-лида, техлидов, инженеров и клиентского менеджера, ведет реестр аварий, координирует ход устранения инцидента, а в случае задержки — осуществляет эскалацию внутри команды. После устранения аварии контролирует подготовку отчета, а также создает пространство для проведения ретроспективы. Таким образом, мы минимизировали ручные операции и повысили скорость реакции на инциденты.
У бота есть стандартная карточка: название компании, описание аварии, кто зарегистрировал, когда произошла, какой продукт, симптомы проблемы, ссылка на технический чат, ссылка на wiki, где будет карточка аварии и ретроспектива.
...и добавляем нейронку
Про использование нейросетей в техподдержке я уже рассказывал во всех подробностях, поэтому здесь коротко об основных достижениях в контексте объединения команд.
Итак, мы начали внедрять цифровых помощников на базе нейросетей. Для этого полностью переработали базу знаний — убрали жаргон, ввели единые шаблоны статей, настроили умный поиск. Затем использовали получившиеся материалы для обучения цифрового помощника. В итоге инженеры поддержки получили доступ к экспертизе PS, а специалисты внедрения — к накопленному опыту решения проблем. Новички быстрее входят в курс дела, а опытные сотрудники экономят время на поиске информации.
Одна из актуальных на тот момент проблем заключалась в том, что многие инженеры сидели в общем чате с разработкой и постоянно задавали вопросы, зачастую одни и те же. Один спросил, получил ответ, ушел, забыл написать статью в базу знаний. Пришел другой — и снова тот же вопрос с тем же результатом. Очевидно, с этим надо было заканчивать, поэтому мы выстроили новый процесс:
Инженер ищет в базе знаний;
Не нашел — идет к техлиду;
Техлид не знает — обращается в Solution Services;
Если и там нет ответа — заводится заявка в разработку.
Когда разработка возвращает ответ, бот автоматически создает инженеру задачу написать статью в базу знаний. Статья проходит валидацию в Solution Services — и мы обогащаем знания, обучаем нейронку.
Вот статистика за последний период, которую мы собрали по результатам изменения процесса. Всего в Solution Services поступило 194 запроса, из которых консультации — 28 (14%), баги — 94 (49%), доработки — 72 (37%). Из общего количества запросов 69 было направлено в разработку, из них консультации — 8 (12%), баги — 36 (52%), доработки — 25 (36%). Итого — количество обращений в разработку снизилось на 65%.
Понимая, что на данном этапе полностью исключить привлечение разработчиков невозможно, мы совместно с технической дирекцией организовали аварийную группу — специализированную команду (назвали ее Ninja team), куда при необходимости подключаются разработчики для решения критически важных задач, выходящих за рамки компетенций PS.
Одним из ключевых принципов взаимодействия стало правило: разработка получает только подготовленные запросы, содержащие полный контекст и историю инцидента. После устранения инцидента проводится внутренняя ретроспектива, цель которой — выявить, какие действия со стороны PS могли предотвратить ситуацию или решить ее без привлечения разработчиков.
Проводим измерения
Через полгода после объединения мы начали собирать количественные и качественные метрики, чего раньше в ТП никто не делал. CSI, NPS, SLA, T2M, T2D, AFRT и множество других аббревиатур — все то, что позволяет видеть проблемы глазами клиента. На первых порах показатели не всегда получались красивые, но они были необходимы. Метрики стали для нас ориентиром — показали, с чего начать.
Далее у нас появился свой полноценный дашборд с метриками PS, и мы стали шаг за шагом повышать и улучшать показатели. Одна из моих самых любимых актуальных цифр: 45% тикетов мы решаем день в день. Наша цель — все проблемы, которые можно закрыть в течение дня, должны быть закрыты в течение дня.
Со временем у нас появились метрики Definition of Ready и Definition of Done. Раньше задачи двигались неполными, создавали путаницу, а теперь задача не может перейти из статуса в статус до выполнения определенных критериев.
PS 3.0: автономные отряды
К концу прошлого года мы перешли на модель автономных отрядов — это адаптация модели Spotify под инженерную среду. Отряд — это техлид с группой инженеров. В его задачи входят регулярные встречи с командой, анализ тикетов, обучение согласно матрице зрелости, планирование развития инженеров. К отряду «прикрепляются» архитекторы по продуктам из Solution, проектный или клиентский менеджер, исходя из подразделения.
Следующий шаг — ротация и универсализация. У нас одинаковый стек (Linux); продукты разные, но с помощью матрицы зрелости можно подтянуть нужные компетенции. Универсалы дают гибкость: нужно усилить техподдержку — передаем людей из внедрения. Нужно больше внедренцев — берем из поддержки. И да, для критичных проектов мы сможем запустить процесс внедрения в режиме 24/7.
Однако о версии 3.0, автономных отрядах, инженерной гильдии и новой матрице зрелости расскажу подробнее в следующей статье — там есть что обсудить.
Коротко об результатах работы
Разработчики почти перестали участвовать в авариях. Если это все же происходит, значит, действительно нужна их уникальная экспертиза, а не просто «кто-то должен разобраться, позовем самого знающего».
Клиенты получили единую точку входа для всех технических вопросов, больше никого не перебрасывают от отдела к отделу.
Команда техподдержки значительно выросла в профессиональном плане, и этот прогресс стал измеримым.
Мы создали автономные отряды с тимлидами, которые могут решать проблемы без эскалации.
Объединять команды ради красивой оргструктуры — трата времени. Настоящий смысл проделанных изменений — обеспечить качественный сервис, предсказуемый и удобный. Когда внедрение и поддержка работают как одно целое, выигрывают все: заказчики, команда и бизнес.