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

Вы наверняка слышали это на собеседованиях.
Я слышу всё чаще: «Меня просто бросили в огонь с первого дня».
Или: «Дали доступ в вики - и сказали: иди, читай».
Никто не объяснил, кто за что отвечает. Ни один вопрос не получил ответа.

Что остаётся у новичка?
Вопросы - в воздухе.
Команда - как чужая.
Стресс - как единственный спутник.

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

Раньше я слышал от инженеров на испытательном сроке :
«Боялся, что меня уволят - потому что чувствовал себя тупым».
Не потому, что они не могли.
А потому, что им не дали ни карты, ни компаса.

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

Но мы не оставляем его в этом состоянии.
Мы даём ему путь.
Не бросаем в огонь - проводим через него по надёжному маршруту.
Обещаем: через три месяца ты освоишься.
Через шесть - уже будешь приносить реальную пользу.
И не просто выполнять задачи - а улучшать то, что раньше работало хуже, чем должно.

А как построить онбординг, который не ломает, а заряжает?

Вот как мы это делаем.
▪️Шаг первый: личная встреча с руководителем.
Не формальность. Не ритуал.
Разговор один на один - где объясняют не только, какие системы использовать, но и: что здесь ценят, а что - нет.
Где закладывается фундамент.
Потому что человек, который чувствует, что его видят - не как ресурс, а как человека - уже на полшага ближе к тому, чтобы остаться.

▪️Шаг второй: знакомство с командой.
Не просто добавить в десяток чатов.
А представить так, чтобы новичок почувствовал: его ждали.

▪️Шаг третий: наставник.
Не просто старший инженер.
Тот, кто знает, как объяснить сложное просто.
Кто не отвечает «прочитай вики» - а говорит: «Давай сядем. Я покажу».

Шаг четвёртый: Ключевой. Структурированное погружение.
Трёхмесячный курс - как путешествие.
Первый день - что делать.
Первая неделя - что изучить.
Первый месяц - что понять.
Всё: от Service Request до Incident Management, от Linux до сетевых диаграмм.
Каждый модуль - тест.
Не для оценки.
Для обратной связи.
Результаты автоматически приходят руководителю и наставнику.
Ни один пробел не остаётся незамеченным.
Ни один вопрос - без ответа.

Шаг пятый: фидбек после завершения.
После успешного прохождения - не просто «молодец».
Сообщение на команду. Поздравляем.
Спрашиваем: что помогло? Что мешало? Что нужно изменить?
Потому что онбординг - не разовая акция.
Это живой процесс. И если он не улучшается - он умирает.

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

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

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

Эта стратегия окупается.
С головой.

P.S.
Читал статью на Indeed: средняя стоимость обучения одного сотрудника - около $1252 при 33 часах обучения.
Рекомендации: удержание через комфортную среду, найм квалифицированных кадров, цифровизация документооборота, целенаправленное обучение на основе оценки.
#TechSupport #Onboarding

Зачем руководителю поддержки читать книги?

Большинство думает: «Зачем читать? У меня и так X лет опыта!»
Отлично! Опыт - это здорово.
Но опыт без рефлексии - это как бег по кругу с граблями в руках. Вы уже наступили на них сотню раз. А книги? Это чужие грабли, аккуратно выложенные на стол. С подписями: «Тут споткнулись - не повторяйте».
Зачем наступать самому, если можно заранее увидеть яму?

Клиентский сервис - это не про «реагировать».
Это про проектировать.
И книги - это не сборник советов «как быть вежливым».
Это как строить системы, которые уже работают.

Книги дают вам:
▪️Процессы вместо хаоса: не «как ответить на гневное письмо», а как создать схему, чтобы такие письма просто не появлялись.
▪️Метрики, которые имеют смысл: не просто «удовлетворённость», а точки влияния на неё - от первого ответа до решения проблемы.
▪️Карту клиентского пути: где на самом деле ломается опыт, и как это починить - на уровне логики, а не эмоций.
▪️Инструменты масштабирования: как растить команду, не теряя качества. Не магией, а процессами.

Когда вы читаете про компании - ДОДО, Southwest, ВкусВилл и др. - вы видите не «улыбки».
Вы видите систему решений.

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

Читайте. Внедряйте. Систематизируйте.

Ваш автор, который верит в силу книг, систем и здравого смысла.

#TechSupport #Книги

Как небольшой пиццерии из Сыктывкара удалось стать лидером рынка и попасть на страницы мировых изданий?

История «Додо Пиццы» - это не история удачи, а результат выстроенной системы.

Когда основатель Фёдор Овчинников пришёл работать в Papa John’s, он не искал «секретный соус». Он искал систему.
Потом он создал свою.

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

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

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

Компания борется с «ресурсным мышлением». Вместо того чтобы в час пик требовать больше сотрудников, команда ищет узкие места в процессах. Оптимизация, подготовка заготовок, умный трекинг с помощью ИИ заказов и голосовой помощник «Оленька», которая говорила: «Поторопитесь!» или «Так держать!», которые позволяют повышать эффективность без раздувания штата.

Такая надёжная операционная основа позволяет «Додо» экспериментировать с инновациями. Компания первой в мире испытала доставку пиццы квадрокоптером. Мировые СМИ - от The Washington Post до Le Monde - написали об этом.

Поэтому при выборе партнёров для франшизы «Додо» смотрит не на размер инвестиций, а на готовность разделить этот подход. Готов ли будущий партнёр начать с работы на кухне? Принять принцип тотальной открытости? Улучшать процессы, а не наращивать ресурсы?

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

#Книги

Так, а теперь о деньгах и карьере в БигТехе.

Нашёл два разбора, кому и сколько платят в IT-сфере:
Зарплаты в IT-2025
Куда уходят айтишники: анализ 30 000 резюме

А теперь - про техническую поддержку. Недавно давал комментарий для одного дружелюбного медиа про саппорт и операторов:

Хочешь в техпод? Сначала спроси себя: «А моё ли это?»

Всё начинается с простого, но главного: кем я хочу быть? Что меня зажигает?

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

Работа отнимает львиную долю жизни. Она должна приносить удовольствие. Неважно, поддержка это, разработка или тестирование. Если дело по душе - ты сам тянешься за знаниями, следишь за трендами, растешь. Ты на острие, а значит - растешь в скиллах и в зарплате.

Вот правда: если перестанешь прокачивать хард- и софт-скиллы - за тобой придёт ИИ. Быстро. Не через пять лет, а через год-два. Рутина уровня L1 уходит в историю. Это эволюция. Держи себя в тонусе.

А что с деньгами?
Инженеры L2/L3 - те, кто знают продукты и инфраструктуру наизнутрь.
Зарплаты от 100 до 400+ тысяч - не редкость. Потолок определяешь ты сам. Глубиной знаний. Скоростью реакции. Умением видеть корень проблемы.

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

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

P.S. Запомнилась фраза:

«Я твёрдо верю в удачу. И я заметил: чем больше я работаю, тем я удачливее».
— Томас Джефферсон

Удачи. Побольше.

Источник

#Карьера

Переосмысление мониторинга.
От метрикориентированного ада к клиентоцентричности и бизнес влиянию.

Коллеги, давайте честно: сколько раз вы видели в ночном алерте «CPUThrottlingHigh 99.93%» и первые 7 минут тратили не на решение проблемы, а на расшифровку - какой клиент сейчас страдает или на что это влияет?

Метрикоцентричные алерты: "Что это? Разберём за 3 минуты"
Эти алерты - классика "метрикориентированного ада". Они фокусируются на сырых цифрах или статусах, без контекста. Инженер видит - бежит гуглить, что за workflow или метрика. Пользователь/бизнес? Им плевать, пока не упадёт SLA.

Примеры:
▪️CRITICAL❗️: node_exporter_target_down{instance="10.45.12.87:9100"} #
Перевод для дежурного: «Что-то где-то упало. Найди в инвентаре, что это за IP, потом пойми, зачем оно нужно».
▪️High🔥: kube_pod_status_phase{phase="Pending"} > 5 for 10m
Перевод: «В кластере 5 подов висят. Клиенты не могут загрузить корзину? Не могут оплатить? Или это фоновые воркеры для отчетов? Удачи разобраться за 3 минуты до эскалации».
▪️CRITICAL❗️: http_request_duration_seconds{quantile="0.99"} > 5s
Перевод: «Медленно. Где? Для кого? Что именно не работает - логин, оплата, выгрузка данных?»
▪️ALERT⚠️: postgresql_locks_waiting > 0
Перевод: «База под нагрузкой». А клиент в это время видит вечный спиннер при сохранении заказа. Но алерт об этом молчит.

Видите? Кто страдает? Какой impact? Сколько клиентов/денег под угрозой? Названия как из логов или стандартных шаблонов мониторинга - технарь поймёт(возможно), но on-call инженер в 3 ночи подумает: "А это влияет на клиентов или просто шум?"
Такие алерты заставляют инженера тратить драгоценные минуты на перевод с «метрического» на «человеческий» - а клиент в это время уже звонит в поддержку с вопросом «Почему не проходит оплата?».

Что имеем в итоге? MTTR растёт, SLA падает, клиенты злятся.
Это не мониторинг - это "охота за метриками".

Клиентоцентричные алерты: когда название алерта = инструкция к действию.
Алерт должен кричать: "Кто? Что? Последствия!"
▪️[CRITICAL][IMPACT:PAYMENTS] Payment processing unavailable for 100% of Enterprise customers
→ Действие: Срочно эскалировать в платежную команду + информировать менеджеров по работе с корпоративными клиентами

▪️[WARNING][RISK:ORDER_RECOVERY] There are no backup copies of orders from 01.02 - in case of failure, customers will lose 14,000 unpaid carts without the possibility of recovery.
→ Действие: Проверить retention policy, подготовить сценарий восстановления из cold storage

▪️[CRITICAL][IMPACT:ALL_USERS] SSO authentication failure rate 92% - users cannot access any application modules
→ Действие: Активировать fallback-механизм аутентификации, запустить массовую коммуникацию через статус-страницу

Почему это работает?
Когда дежурный видит [CRITICAL][IMPACT:PAYMENTS], он не думает - он действует. И это сокращает не только MTTR, но и количество звонков в поддержку от разъяренных клиентов.

Как внедрить:
1. Аудит: Определите метрики по влиянию на клиентов.
2. Перепишите алерты: Добавьте шаблоны "[SEVERITY][STATUS] Service - impact for [audience])".
3. Тестируйте: Симулируйте в Chaos Engineering, измерьте MTTR до/после.

Подытожим:
Алерты должны говорить на языке бизнеса и боли клиентов: не «CPU загружен на 99%», а «пользователи не могут оформить заказ». Потому что в 3 ночи клиенту всё равно, какая метрика упала - ему важно, чтобы его платеж прошел. А ваша задача как руководителя/инженера - сделать так, чтобы команда увидела проблему глазами клиента до того, как клиент позвонит вам.

#monitoring #bestpractices