Мастер-класс 19 марта «Как настроить отчёты по дополнительным полям в Юздеске. Новый функционал»

Как выстроить саппорт так, чтобы им гордиться

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

Почему ребята выбрали самописную систему, и как все устроено в одном из крупнейших провайдеров облачных сервисов.
А еще в выпуске вы узнаете про ТАМов — без спойлеров, внутри все расскажут.

Самим не верится, что завершили уже 4 сезон! Но не расслабляйтесь, это не на долго, скоро увидимся.
Макс:
Сегодня у нас в гостях Алексей Багаев, операционный директор из компании ДатаЛайн, и Роман Обрядин руководитель техподдержки той же компании. Говорим о том, как выстроить саппорт так, чтобы это был повод для гордости, а главное для чего. Ребята, расскажите нам про себя, про вашу компанию, как давно вы существуете и чем вы занимаетесь, с какими вопросами к вам приходят клиенты и так далее.
Алексей и Роман:
Сама компания существует с 2007-го года мы начинали с одного центра обработки данных, сейчас у нас много локаций, мы одни из самых лидеров на рынке среди центров обработки данных, позапрошлом году мы реализовали объединение РТК ЦОД. Это дочерние компании ростелеком и теперь мы одна единая компания. Помимо, центров обработки данных, то есть центр обработки данных это помещение, приют для сервировки, когда заказчик размещает свои сервера, мы ему даем гарантированное питание, качественное охлаждения, вывод энергопотребления, качественный интернет – создаем микро инкубатор для серверов. Помимо этого мы предоставляем, один из наших основных видов бизнеса это инфраструктура как сервис, это облачные исчислении, и вот все что можно вокруг этого предоставить, мы все предоставляем, это Телеком, это интернет каналы, каналы передачи данных, между точками где-то в Москве и не только, потому что мы сейчас в плотной коллаборации с Ростелекомом и по этим каналам можем предоставить в любую точку не только РФ, но и за ее пределами. Мы постоянно пытаемся расширить пробы и у нас это получается, пробуем расширить наш спектр услуг максимально его сделать, потому что клиенту всегда удобно сделать одно окно, что мы максимальное число перечня сервиса предоставляем и для клиента мы служим как одной точкой отхода, все сервис мы предоставляем им удобно коммуницировать с нами, ему не нужно брать каждую слову в разные компании, а все базовые услуги он может взять у нас, Что удобно для управления. Управление IT инфраструктуры это всегда сложно.

Немного добавлю, меня зовут Роман, я являюсь руководителем центра системного администрирования компании ДатаЛайн, как уже было сказано, основная моя деятельность это техническая поддержка, организация работы технической поддержки первая и 2-я линия системного администрирования. В 2009-м году компания ДатаЛайн в мае появился первый клиент из тех пор я вошёл в команду и нахожусь в ней более 10 лет. За это время команда сильно выросла, начинали мы порядка 20 – 30 человек, сейчас нас около по 1000, количество клиентов выросла в разы, основной наш вид деятельности это колокейшн, как сказал Алексей дальше стали развивать другие направления и топ два это стало облачные услуги. На базе которых мы стали дальше развивать платформенные услуги, на данный момент у нас порядка 18 ЦОДов распределенных по всей России, об этом чуть позже.
Макс:
Вы сказали что совсем недавно вы масштабировались, объединились с Ростелекомом, расскажите как это все происходило, для вас конкретно – это объединение. Что у вас поменялось в глобальном, насколько выросла команда, как вы все это организовали, делали вы какой-то масштабный процесс унификации при объединении или всё происходило разрозненно.
Роман:
Процесс объединения это всегда тяжелый и долгий процесс, ДатаЛайн вошёл в состав группы компании РТК ЦОД, это центр компетенции ростелекома по облакам, по колокейшн, по системам передачи данных, также в эту группу компаний входит юрлица занимающиеся разработкой программного обеспечения и также программой аппаратного комплекса. ДатаЛайн входит в направлении которая занимается непосредственно дата центрами и все что сними связано, с публичными облаками. Безусловно, при объединении группы компании РБК цод у нас появились дополнительные ресурсы, но также появились дополнительные заказчики, увеличилось количество ЦОДов, если я сейчас не ошибаюсь, порядка 18 ЦОДов у нас сейчас. Количество увеличилось ровно в два раза, было девять сейчас 18, особо хочется отметить, что помимо роста количества ЦОДов у нас появилась геораспределённость, ранее все наши цод располагались в городе Москва, сейчас это и регионы, и Новосибирск, и Екатеринбург, а также Санкт-Петербург. На данный момент команда технической поддержки, объединённой командой технической поддержки проходит процесс трансформации. Этот процесс не быстрый, самое главное здесь не поломать то что мы имеем на данный момент, это может сильно сказаться на уровне оказываемой сервису заказчика.
Катерина:
Расскажите, как у вас Сапорт, так много у вас клиентов, так много сотрудников как это все работает. Начнём с самого начала, заказчику требуется обратиться в сапорт с каким-то запросом на обслуживание, либо с каким-то инцидентом.
Роман:
Заказчик, у него есть единая точка входа, это либо почтой, либо телефон, все эти каналы связи они приходят к службе технической поддержки ДатаЛайн. На передовой это службы находится оператор, он принимает обращение от заказчиков, обрабатывает его, авторизует заказчиков, авторизует контактные лица заявителя и после этого маршрутизирует заявку, создаёт заявку, создает параметры на основе данных, которые предоставляет заявитель и маршрутизирует эту заявку в ту или иную группу. Про группу производства, Алексей упоминал, например эта группа сети, группа виртуализации Microsoft Linux и так далее. На первой линии, в этой группе имеется инженеры, они принимают вновь пришедшую заявку, они производят её, читают её, обрабатывают её, если это какая-то типовая операция они готовы с ней справиться по инструкции они выполняют, если видят что инцидент какой-то сложный, то есть запрос на обслуживание выходит за рамки их компетенций, ему по регламенту необходимо эту заявку отсканировать на 2-ю линию. 2-я линия это инженеры, выросшие из первой линии, более опытная, работающий от года и достаточно технической компетенции, эти люди они также подключается к решению заявок клиентам и если даже у них не получается, всегда есть ведущий старший инженеры которые формируют, у них есть переходящие роли инженера 3-й линии и всегда можно обратиться к ним. Ну и если даже инженер третий линии не может помочь, то мы идём уже к вендорам.Первая, вторая, 3-я линия это всё что касается IT сервисов, отдельно у нас существует ещё группы дежурных инженеров, они работают непосредственно в цоде и как правило это связано с услугой и колокейшн. Встретить заказчика на Проходной, вынос и внос оборудование, заказать пропуск и тому подобное, также есть услуга удалённый руки, когда у заказчика нет необходимости приезжать в цод, чтобы выполнить какое-то действие, они могут обратиться в саппорт, чтобы с помощью рук дежурных инженеров выполнить то или иное действие.
Катерина:
Насколько мы знаем у вас специфичная роль в компании как тамы, расскажите поподробнее что это за люди, чем они занимаются и как это расшифровывается.
Алексей:
Смотрите какая история, у нас есть оно преимущественно занимается эксплуатацией сервиса и конечно развитие оно присутствует, но базово это всё-таки эксплуатация. И когда мы расширяем свой набор пакет услуг, чем больше услуг, тем сложнее начинаются проблемы, с управлением этих услуг, например появляется клиенты которые берут почти все услуги, это может быть облако, Колокейшн, интернет, хранилище, базы данных как сервис и представляете всем этим надо управлять, всё это надо соединить в одно единое и чтобы оно работало качественно. При этом при всём у клиента постоянно возникает необходимость в изменениях этих схем взаимосвязь, добавление новых услуг, удаление новых услуг, какой-то переделывание, миграции из их офиса к нам и кучи всего другого. Нам до появления тамов приходилось подключать архитекторов, потому что у нас институт архитекторов это ребята которые подключаются к работе на этапе проселенга заказчика, то есть заказчик приходит извне и он говорит мне нужно то и то и мы подключаем архитектора – если это сложный кейс, если это сложный запрос. Архитектор начинает прорабатывать на этапе продажи набор услуг начинается огранка этого вида инфраструктур, как оно будет после того как заказчик подпишет заказ. А когда уже заказчик в эксплуатации, совершенно и возникает какая-то необходимость комплексного мнения, нам приходилось снова подключать архитекторов, при этом нужно было подождать время для понимания а как сейчас у него есть, потому что он на этапе продаж подключался, но прошел год или полгода и человеку нужно опять изучать инфраструктуру, чтобы предложить какие-то изменения, чтобы провести все это бесшовно, без проблем. Для того чтобы решить эту задачу, мы пошли решили пойти на эксперимент, забегаю вперёд и скажу что это успешный эксперимент. Два года назад мы решили рассмотреть такую возможность, когда мы берём среднего инженера и ведущего инженера, которая обладает определенными софт скилами, которым хочется общаться с внешним миром, заказчиком. Мы говорим 30 % времени теперь будешь уделять вот этому конкретному заказчику. Мы берём конкретного инженера, проводим с ним собеседование, подбираем его, когда обучаем и дальше мы его прикрепляем к одному из наших комплексного заказчика, у нас есть список заказчиков которые совсем совсем комплексный и при любом изменение требуется подключать много людей и чтобы этого не делать, мы берём инженера, закрепляем за этим заказчиком и он его постоянно ведёт, по техническим вопросам и это называется техникал аккаунт менеджер.И когда он уже постоянно в теме, когда у заказчика возникает тот или иной вопрос та или иная проблема, это потребность в изменениях и он знает, он отслеживает каждый шаг ему гораздо проще провести эти изменения, он видит все проблемы этого заказчика и более того он постоянно общается заказчиком, на разные проблемы, и постоянно держит руку на пульсе. Поэтому даже когда у заказчика возникает какой-то вопрос, он может адресовать это нашему таму и наш инженер всегда ему поможет, причём оперативно и быстро, в комфортные сроки, потому что он погружен в особенности и проблемы этой инфраструктуры заказчика. Если говорить о этой функции техникал аккаунт менеджер, у неё три задачи. Первое, это функционал проджект менеджера этого заказчика, персонально выделенный, которые помогают Бесшовная провести какие-то изменения, решить проблему, какие-то вопросы. А второе, это контроль качества по услугам, которые предоставляет заказчик, он раз в месяц берет и составляет сервис дсг, анализирует все тикеты, подбивает, что можно улучшить, какие были проблемы, а здесь быстро ответили, здесь медленно, вот здесь сломалось, что мы будем делать. На этой почве он коммуницирует с заказчиком и таким образом мы помогаем заказчику и мы развиваем в его инфраструктуре, в его сервисе, в его потребности, мы развиваем и в этом основная роль техникал аккаунт менеджера. Третье, это такой мостик между сервисом менеджером нашим, между аккаунтов менеджером, между заказчиком, между техническим и производством, то есть подразделением IT сервисов, до этого бывали такие разрывы, есть клиент есть сервис менеджер и много наших технических подразделений и сервис менеджер не всегда просто с координируют действия, потому что у него задача больше про бизнес. По истечении двух лет у нас порядка 20 человек имеет такой функционал, 20 инженеров, которые помогают нашим топовым заказчикам развивать свои сервисы, мы помогаем развивать эко системы заказчиков, основной прикольный бонус от этой функции, что техника аккаунт менеджер позволяет нам выявлять потребности заказчика, даже те услуги потребности которые сейчас мы не можем предоставить. Например, в перечне наших услуг Чего-то нет и тогда техникал аккаунт менеджер поднимает флаг и говорит, у заказчика есть такая потребность, у нас такого нет чем можем помочь. Мы все начинаем думать как нам помочь, даже бывает доходит до того, что мы внедряем какой-то новый тип услуги, которые потом с удовольствием потребляют ещё ряд заказчиков, не только этот заказчик.
Эти три основные вещи которые делает там он реализует, особенности этой штуки, что инженер тратит свое время, мы говорим примерно в какое время, примерно 30 % своего времени рабочего и он уделяет это время клиентам в рамках функционала, как там, остальное свое время он работает в своей системной группе, по своим задачам инженерским. Таким образом, мы позволяем ребятам попробовать себя в какой-то другой ипостаси и вот он был инженером, больше работал внутри, здесь есть отличная возможность попробовать себя и показать свои софт скилы. Софт Скилл это коммуникация, навыки презентации, навыки координации, навыки проджект, менеджмента это позволяет не отрываясь от своей какой-то текущей базовой истории, не выходя из зоны комфорта, попробовать себя в новом направлении. Это в целом позволяет нам повысить клиентоориентированность против заказчиков это прикольная штука.
Катерина:
А в связи с этим, два вопроса, первый как вам удается найти таких софт скиловых ребят, существует миф о том, что технические специалисты как правило интроверты не хотят общаться с клиентами, как вам удается выявить кто действительно хочет, кто может это делать, даете вы какие-то обучающие курсы для них – насколько есть вообще проблема найти таких которые хотят поговорить с клиентом по телефону?
Алексей и Роман:
Очень интересный вопрос, мы сами не знали и у нас были опасения на этапе пилота, эксперимента. Первое что мы делали, мы спрашивали всех ребят, текущих и прибывших хотите ли вы попробовать, то есть мы держим их в курсе что есть такая программа, есть такая функция и двери открыты. Когда только инженер проявляет первый интерес к этой истории мы берём его в оборот, если он сам проявил инициативу. Значит ему интересно, одновременно ему страшно и непонятно и некомфортно и так далее, то есть как только мы замечаем первые дуновение что ему интересно мы берём его в оборот, начинаем с ним общаться. Если человек изъявляет желание и его хватает, у него есть в том числе хард скилы, есть задатки софт скилов мы его запускаем в программу обучения. У нас есть внутренние программы обучения, сразу начинаем тренировать ребят в ораторских, навыков публичных выступлений, это основная история по которым можно всегда свободно можно рассказать презентацию, как в онлайн режиме, так и в офлайн. Естественно мы объясняем, это полезно даже если вы не свяжет свою жизнь с какими-то менеджерскими скилами, всегда будете инженерами, это все равно понадобится, потому что вы общаетесь с другими отделами, внутри отдела и у них есть же история рендап, карьерной лестнице, они могут повернуться в сторону менеджера, может остаться в технике, но он может дорасти от младшего инженера до архитектора в компании. Архитектор в двух разных местах, чтобы быть архитектором необходимо обладать навыками коммуникации развития, потому архитектор должен собирать информацию, анализировать и предлагать варианты решений, утверждать их и это всё обучение. Есть ещё методики сапортом тамов, что получается, что не получается мы разбираем проблему, выявляем причины и иногда эти причины могут быть распространены на других тамов и мы корректируем всю программу развития.

Добавлю ещё один момент, что тамы нам существенно помогает при оказание технической поддержки, часто запросы от заказчиков носят не формализованный вид, чтобы разобраться с тем что же у заказчика случилось что за проблема, или же какой запрос от него пришел иногда опыта ведущих недостаточно мы в таких случаях обращаемся к нашим тамам. У каждого сложно комплексного заказчика у всех есть там и помимо всего прочего, Скилов софтовых они выбираются как правило с таким учётом что у какого больше продуктов услуг заказчик куплено, соответственно кто больше частью администрирует какая группа и из этих групп выбирается там. Он максимально погружен в технические аспекты заказчика. Если у клиента куплено много сетевых услуг, как правило, там инженер из сетевых групп, если заказчика куплено много услуг по безопасности, то там обычно является инженером группы безопасности. Как правило, в таких ситуациях когда требуется понять всё-таки что в запросе заказчика и что он хочет от нас, какая проблема возникла мы тамов и это очень сильно облегчает жизнь.
Катерина:
Расскажите как вы вообще общаетесь заказчиками, когда процесс происходит и главное в каком формате. Вот и сказали что там помогают организовать формат, ну как формат происходит, строить стороны поддержки. Потому что тем у вас довольно сложная техническая, как у вас этот процесс настроен. Как вы обучаете своих сотрудников.
Алексей:
С технической точки зрения общения заказчиком в большинстве случаев происходит через нашу систему Айтисем. Это система сервисдеск, позволяет вести диалог в самом интерфейсе с точки зрения инженера, а заказчик получает почтовые сообщения. Как правило этого достаточно иногда возникают ситуации когда высокая срочность, либо никак мы не можем найти общий язык в переписке, тогда просто звоним по телефону, контакты как правило подсвечены в самой системе от заявителя и мы можем с ним связаться, или мы связываемся с заявителем через сервис менеджера. Каждый инженер который приходит к нам в команду технической поддержки проходят первоначальный инструктаж и обучение, помимо хордовых скилов, которые требуются для работы, также проходит инструктаж потому как ввести себя заказчиком, как с ним разговаривать, у нас есть небольшая памятка которую мы показываем инженерам, в которой отражены основные моменты.Например, всегда нужно отождествлять себя как часть компании, заказчик когда обращается в техническую поддержку, к конкретному инженеру он обращается к компании, а не к конкретному какому-то инженеру. Ответ не знаю запрещен, если инженер сам не знает, он не должен об этом говорить у него всегда есть лесенка эскалации по которым он должен пойти и это описано в регламентах процедуры. Если вдруг инженер понимает, что заявка ошибочно попала на него он также не должен об этом говорить, помимо этого банальные вещи как вежливость, нельзя грубить, всегда улыбаться и быть вежливым вне зависимости от сложившейся ситуации. Если ситуация накаляется всегда можно взять паузу и связаться сервис менеджером для того чтобы обрисовать сложившуюся ситуацию. Также помимо коммуникации есть набор рекомендаций, который человек должен использовать при работе заявками заказчика, например, видишь повод эскалируй. Начал выполнять заявку – нажми в работу, первым делом инциденты, обслуживание потом - что-то в этом роде. Это дублирует слова которые описаны у нас в инструкции в регламентах, но иногда короткие фразы кричащие лучше заходит инженерам, которые работают. Помимо этого мы стараемся контролировать что же всё-таки пишет инженеры стороны заказчика, у нас есть специальная система дашборды, в которых мы можем просматривать последние энное количество комментариев инженеров в сторону клиента, бывает что оттуда какие-то несуразности можно вытащить и приходится проводить дополнительные работы с инженером о том что так делать лучше не надо. Вообще конечно когда клиенты обращаются на support было бы очень хорошо, чтобы общение с клиентом сводилась к минимуму, для этого по-хорошему заявка должна быть достаточно формализовано, в нашем случае всех сложности, сложности тех систем который мы в саппортим, часто бывает наоборот. Иногда заказчик может написать у нас поломалась почините пожалуйста или ссылку, по которой даже самый ведущий инженер не может распознать о какой услуги идёт речь и вообще о чем это, тут тамы и помогают, как правило там один а запросов много и приходится вести коммуникацию этим самым отсрочивается срок выполнения заявки. Лайфхак как сделать так чтобы ваше обращение было выполнено максимально быстро, чтобы помочь нам быстрее качественнее обработать запрос, и желательно указать в нём номер договора по которому вы обращаетесь и услуга по которой вы обращаетесь. Дело в том что у нас у некоторых заказчиков может быть несколько договоров и каждому привязано энное количество разных услуг и чтобы правильно инициировать услугу, идентифицировать заявку нам требуется информация по номеру договора и его услуги на входе. Конечно бывают случаи когда какие-то ключевые слова, фразы самому обращение они подсказывает нам и мы можем большинстве случаев, в таких ситуациях распознать что это за услуга и мы можем маршрутизировать заявку правильно, но когда это явно указано, это существенно облегчает жизнь. Так что уважаемые заказчики по возможности при обращении в службу технической поддержки указывайте номер договора и услугу в рамках которой вы обращаетесь. Это +10 скорости выполнения и +20 качеству.
Катерина:
Здесь я на самом деле тоже согласна, потому что кроме того что поддержка должна быть хорошей, но и клиенты должны тоже помогать поддержки решить их вопрос. Расскажите пожалуйста, про какой-нибудь кейс может быть из вашего опыта, необычные нестандартные, когда удалось помочь клиенту.
Алексей:
Давайте я расскажу вам про кейс когда к нам пришел тестовый заказчик протестировать услугу, облачную услугу. После непродолжительного, может быть недели две мне приходит информация что заказчик, потенциальный заказчик остался не очень хороший. Я попросил с ним связаться, мне помог с этим сейл, который с ним работал. После непродолжительной беседы с заказчиком выяснилось, что ему недостаточно было информации для настройки в связке облака с его оборудованием, Оборудование у него специфичное, ему не хватило инструкции, чтобы осуществить настройку этого оборудования. Мы попросили взять паузу, чтобы мы собрали информацию для составления этой инструкции и потом в дальнейшем связались бы с ним для оценки того что у нас получилось. В течение некоторого времени мы нашли специалистов под эту систему, мы составим подробную инструкцию, повторно связались с заказчиком, он у нас ничего не купил.Собрали обратную связь, инструкция понравилась, собрали дополнительную связь улучшили её и опубликовали у себя на странице. Почему было такое принято решение с моей стороны, потому что я встретил подобное, два подобных кейса буквально за полтора-два месяца именно про эту систему и поэтому, чтобы в дальнейшем не возникало таких неприятных ситуаций, мы решили сделать подробнейшую инструкцию по настройке связки, этого специфического оборудования и разместили на общем ресурсе, для того чтобы каждый мог это посмотреть и осуществить настройку самостоятельно.
Эти три основные вещи которые делает там он реализует, особенности этой штуки, что инженер тратит свое время, мы говорим примерно в какое время, примерно 30 % своего времени рабочего и он уделяет это время клиентам в рамках функционала, как там, остальное свое время он работает в своей системной группе, по своим задачам инженерским. Таким образом, мы позволяем ребятам попробовать себя в какой-то другой ипостаси и вот он был инженером, больше работал внутри, здесь есть отличная возможность попробовать себя и показать свои софт скилы. Софт Скилл это коммуникация, навыки презентации, навыки координации, навыки проджект, менеджмента это позволяет не отрываясь от своей какой-то текущей базовой истории, не выходя из зоны комфорта, попробовать себя в новом направлении. Это в целом позволяет нам повысить клиентоориентированность против заказчиков это прикольная штука.
МАКС:
Вы уже говорили что у вас есть определённый сервис деск, дашборд, насколько я понял это какие-то самописные системы, можете как-то рассказать как вы на неё решились и почему не стали использовать готовые решения?
Алексей:
Да действительно это так, мы с 2018 г. ввели в эксплуатацию самописную отечественную систему, называется на сервис деск два ноль и до сих пор мы её используем это не просто в сервис деск в вакууме, он не живёт сам по себе. Эта система должна обязательно быть интегрирована во все другие системы, которые формируют информационную компании, например эта система синди Би, какой-то справочник. Дополнительные системы, например этой системы обхода. Все эти системы требует глубокой интеграции, поясню, общество систем также самописный и тогда их пытались интегрировать с какими-то сталкивались с очень большими проблемами при интеграции, это время, это внешний подрядчик, Насколько я помню он был тогда один. У нас есть хорошая статья на хабре про это. Таким образом, для решения проблемы интеграции со всеми системами, для гибкости, одно из самых больших преимуществ самописных это гибкость, то есть всегда при возникновении того или иного изменения мы всегда оперативно неделю-две или месяц мы вносим эти изменения в систему. Предвижу вопросы что есть риск, написанных систем это от зависимости команды разработки, это псевдо экономия по деньгам, потому что кажется мы напишем сами, нам не надо покупать лицензию, в таких расчётах никогда не учитывают, как правило, трудозатраты программистов и команды программистов, которые идут на написание и поддержание этой системы. В тот момент, три года назад, когда принималось решение были взвешены все факторы и принято решение о том, что мы будем приходить на самописная система. Насколько я понимаю, у коллег, имею в виду разработку, уже были достаточно хорошие наброски движка этой системы, требовали совсем небольшие изменения чтобы запустить полноценный релиз. И ещё момент, насколько я помню одним из камней, последней капли терпения было когда перестали, когда перестало хватать лицензии на текущий на тот момент сервис деск, порядка 100 лицензий и нам стало это не хватать и наверно это было одно из последних капель, которые перевесили в пользу самописной системы. Система сервис деск с критикал системой поэтому при её разработки были учтены такие факторы, как отказоустойчивость, вся система зарезервирована, несколько плетей кластеров, все это надёжно работает, разнесена по площадкам и отказа систем сервис деск крайне мало, я даже не помню когда у нас она отказывала. Можно конечно поплевать через плечо три раза на всякий случай.
Добавлю ещё один момент, что там нам существенно помогает при оказание технической поддержки, часто запросы от заказчиков носят не формализованный вид, чтобы разобраться с тем что же у заказчика случилось что за проблема, или же какой запрос от него пришел иногда опыта ведущих недостаточно мы в таких случаях обращаемся к нашим тамам. У каждого сложно комплексного заказчика у всех есть там и помимо всего прочего, Скилов софтовых они выбираются как правило с таким учётом что у какого больше продуктов услуг заказчик куплено, соответственно кто больше частью администрирует какая группа и из этих групп выбирается там. Он максимально погружен в технические аспекты заказчика. Если у клиента куплено много сетевых услуг, как правило, там инженер из сетевых групп, если заказчика куплено много услуг по безопасности, то там обычно является инженером группы безопасности. Как правило, в таких ситуациях когда требуется понять всё-таки что в запросе заказчика и что он хочет от нас, какая проблема возникла мы тамов и это очень сильно облегчает жизнь.
Катерина:
Спасибо большое, есть последняя рубрика называется что почитать, у наших гостей спрашиваем совет, какой-то полезный по вашему мнению контент для бизнеса, поддержки, сервиса, руководители – это может быть все что угодно книга, курс, блог, какая-то статья посоветуйте нашим слушателям и нам что-нибудь.
Алексей:
В свое время, мне про IT, про сапорт про проектную деятельность понравился роман Демарко дедлайн, думаю большинство людей читало который тем или иным образом связано с этим, классические книги, в частности по управлению инцидентами. Про руководителей, тема менеджмента мне понравилась книжка Владимира Тарасова искусство управленческой борьбы, книга составлено виде так называемых описаний китайских стратагем, классическая книга всех времён и народов эффективный руководитель, об эффективности руководителей. Про бизнес, мне в свое время очень зашла книга это в одно касание, про стратегии таких бизнес гигантов Amazon, Google, Microsoft. Лично мне зашла книжка самый богатый человек Вавилоне, большинство такой литературы в принципе об одном и том же, но разный подход подходит тем или иным людям. Эта книга мне очень зашла, хотя про это я читал других произведениях. Недавно прочёл книгу про нескучные финансы, очень зашло, всегда было интересно что такое дебиторка, кредиторка и как это финансисты общаются с бизнесом, как управляется бизнес с помощью цифр, цифр отчетов. Ещё скажу про YouTube канал, наш коллега, он сейчас не работает, но был некоторое время назад, в группе Microsoft начал ввести канал по администрированию систем на базе Microsoft Windows и этот канал называется рэй анти хат. Обычно мы туда отправляем инженеров первой линии для обучения для саморазвития, для получения нужной информации. Довольно систематично, структурировано выложена информация.
Поделиться с коллегами:
Поделиться с коллегами:
Подпишись на новые выпуски подкаста Юздеска
Уже 9 765 подписчиков