Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×

5 важливих уроків для інженера служби підтримки

П’ять важливих уроків, які я здобула на шляху до посади старшого інженера служби підтримки клієнтів.

Мене звати Марія Швецова і я приєдналась до команди ІТ підтримки Sigma Software три роки тому. До цього в мене був деякий досвід роботи в ІТ в сфері менеджменту і маркетингу, але саме в сапорті я змогла застосувати найбільше своїх вмінь і отримала декілька надзвичайно важливих уроків. Саме ці уроки допомогли мені пройти шлях від джуна, який ніколи не працював в сапорті, до сеньора за три роки. Я вдячна своїм колегам і менторам, які увесь цей час давали мені поради і розповідали свої історії з життя. Сьогодні ж спробую побути такою людиною для тих, хто тільки розпочинає кар’єру у службі підтримки. Тож ось здобуті мною уроки і історії про те, як я усвідомила їх важливість.

Урок 1: Вивчіть вашу команду та стейкхолдерів
Так, це може здатися очевидним, та насправді це надзвичайно важливо — розуміти стейкхолдерів, їхні цінності, вплив та ролі на проекті. Стейкходери, це всі ті, хто приймають рішення на проекті, мають вплив та вигоди від нього . Щойно ви познайомитеся з ними (власником продукту, лідерами, замовниками тощо), ви зможете пристосувати головні потреби бізнесу до свого підходу і, як результат, краще розуміти і виконувати свою роль.
Чим краще ви знаєте команду, тим легше ви спілкуєтеся та знаходите рішення і, таким чином, надаєте рішення і послуги високої якості.

Якось одного разу такий урок повністю змінив атмосферу і відношення на одному проекті. Раніше проект був складним і ресурсозатратним, але після того як ми переосмислили відносини зі стейкхолдерами, він став одним з моїх улюблених. В чому ж була проблема? З початку співпраці у нас були напружені відносини з ПМом на боці клієнта. Ми виконували свою роботу в рамках SLA і досягали потрібних KPI, але завжди відчували мікроменеджмент, від клієнта часто надходили негативні коментарі про нашу роботу. Ми дуже хотіли налагодити взаємодію і встановити довіру між командою і ПМом. Тоді ми спробували піти на випередження і запропонували провести для нас тренінг з best practices і поділитись досвідом роботи з тікетами. І це стало чарівною пігулкою, яка все розставила на свої місця. Під час тренінгу ми краще познайомились з менеджером і його досвідом, а він — ближче з командою. Спілкування на тренінгу допомогло нам налагодити хімію між командою і менеджментом, покращити комунікації і в цілому зробити роботу над помилками у відносинах з клієнтами.

Урок 2: Розвивайте ваші навички: технічні і комунікаційні
Важко уявити професіонала, який роками залишається на одному і тому ж рівні. Постійний ріст — ознака справжнього професіонала незалежно від років досвіду. Розвивайте ділове спілкування, мовний рівень та інші комунікаційні навички, разом з вашою технічною експертизою. Саме так з’являються нові ідеї, пропозиції з поліпшення роботи, досягається висока продуктивність тощо.

Урок 3: Збирайте зворотний зв’язок та вимірюйте результати
Кожний проект має свої KPI та принципи, якими слід керуватись, та не завжди вони можуть дати вам повне бачення вашої роботи. Вивчайте відгуки кінцевих користувачів, замовників і керівництва, навіть ваших колег. Аналізуйте повну картину, щоб визначити потенційні слабкі місця та проблеми, що виникають. Навіть негативний зворотний зв’язок — джерело поліпшень.

Був у нас проект, на якому аудит якості оброблених тікетів проводився кожного місяця. Та одного разу, обробляючи результати, ми помітили, що якість роботи нашої команди падає, незважаючи на досвід. Як таке може бути? Почали розбиратись. Ретельно вивчили оцінки та різні ситуації і зрозуміли, що на проекті стало більше документації, виріс скоуп і кількість додатків, з якими треба було працювати.
Виконувати постійну кількість завдань і разом з тим вивчати нові процеси банально не було часу, а це призводило до помилок і невдач. Невдачі ж у свою чергу придушували цікавість до роботи, увагу і мотивацію.
Ми розробили регулярні knowledge sharingтренінги і внутрішні сесії для супервізії тікетів. Знання про нові процеси презентувались вчасно і за планом, а помилки можна було розібрати на сесіях. І це спрацювало: якість роботи покращилась, а клієнт був настільки вражений успіхом, що попросив нас поділитися нашим підходом із іншими командами.

Урок 4: Поставте себе на місце кінцевого користувача
Коли я починаю проект, перше, що я роблю — оцінюю його з точки зору кінцевого користувача. Я намагаюся замовити товар в магазині, пройти реєстрацію, запустити гру — роблю все, аби зрозуміти, який саме досвід отримує кінцевий користувач. Це важливо тому, що саме кінцеві користувачі створюють прибуток та успіх проекту. Користування продуктом або сервісом так, як це зробили б кінцеві користувачі, дозволить вам зрозуміти, з якими проблемами вони можуть зустрітись, що може бути незручно або незрозуміло.

Вже більше двох років ми підтримуємо сайт, на якому бренди купують рекламу в блогерів. За цей час ми пережили разом з клієнтом ріст і зміни, налагодили тісні стосунки з їх командою і завжди on the same page зі стейкхолдерами.
Обробляючи запити і проблеми кінцевих користувачів (брендів і блогерів), помітили, що лише відповідей у FAQ недостатньо. Багатьом би хотілось мати відповіді на питання тут і зараз, а не шукати їх у FAQ. Тому ми запропонувати додати навчальні тури, які допомагали б швидше освоїтися і почати користуватись площадкою більш ефективно. Тур можна було проходити знов і знов у разі потреби. Усі нові функції одразу додавались до туру. Після введення навчальних турів кількість проблем пов’язаних в питаннями на кшталт «як це працює» зменшилась, а активність на платформі зросла на 30%.

Урок 5: Проявіть ініціативу
Не бійтеся проявляти ініціативу і висловлювати свої ідеї! Страх може бути проблемою як для новачків, так і для досвідчених співробітників будь-де у світі. Насправді, кожен замовник оцінить вашу увагу до проекту і бажання зробити його кращим.

Розповім як прийняття ризику та ініціатива відкрили для нас багато нових дверей. У пошуку нових сфер для розвитку відділу підтримки і клієнтів для нас, запропонували клієнту оптимізацію Jira для вже існуючого проекту. Клієнт погодився і, завдяки проведеній нами оптимізації, зекономив більше 2 тисяч доларів.
На цьому ми не зупинились і запропонували наші послуги з адміністрування продуктів Atlassian іншим проектам в Sigma, активізуючи співпрацю між департаментами. Так почала розвиватись нова експертиза — Atlassian products administration, яка принесла нам нових клієнтів. Не маючи доведеного досвіду в цій області, ми ризикували, що клієнти не оцінять належним чином наші пропозиції і відмовлять нам на самому початку. Проте наші побоювання не справдилися, а результат виявився вартим ризику.

Якщо ви можете розглядати усі наведені вище поради комплексно — ви знаєте свого замовника, застосовуєте свої навички ділового спілкування і досвід роботи з кінцевими користувачами та їх проблемами, а також відстежуєте, що треба поліпшити. А це вже шлях до успіху на будь-якому проекті.

Діліться своїм досвідом та цікавими кейсами!

👍ПодобаєтьсяСподобалось4
До обраногоВ обраному1
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

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

Яке епічне бла-бла-бла. А чого це в сапорті вже «інженер», а не «менеджер»? Стара личка зламалася, треба давати нову?

А ну, скажіть як у ваших Сігмах прибиральниця називається?

Діліться своїм досвідом та цікавими кейсами!

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

Елена, спасибо, что поделились! По опыту звучаших очень нелепо некоторых законов в разных Штатах, понимаю, что, скорее всего, ранее были преценденты :)))

Аналогічно, також реєструюсь на усіх сайтах, з якими доводиться мати справу, коли працюю, згодом, коли включили до команди сапортів, що проходили навчання у тестувальників та QA, виявилося що спіймали баг або недоробку писменника при розробці нашої платформи :) Майже два роки у чудовій команді датської платформи минули швидко та несумно, знайти схожу команду та роботу без нічних змін — проблема.

Аревик, спасибо, что поделились своим опытом и инетресным кейсом. Мы тоже стараемся не проходить мимо багов, так и свою экспертизу прокачиваем, и команде помогаем.
Обратите, пожалуйста, внимание на эту вакансию — career.sigma.software/...​-engineer-english-german.
У нас очень уютно и на эту позицию без ночных смен :)

Спасибо, Мария :) посмотрела, увы, с немецким у меня ноль :(

Тогда предлагаю оставаться на связи, у нас часто открываются вакансии :)

Найголовніший урок: Не варто починати кар’єру в support.

Support — він різний буває. Дуже.

Игорь, возможно, вам не повезло с компанией или командой. Приходите к нам, будем рады показать светлую сторону Support :)

Где вам предстоит из букв О,П,Ж,А сложить слово «вечность».

Вас, напевно, там привʼязували до радіатора опалення і годували раз на день? А як ні, то для чого аж так узагальнювати?

Можу говорити про саппорт свєї компанії: 1) найвиваженіший менеджмент (бо інакше не працює); 2) змога колупатися у продукті досхочу і коммітити в нього (внєзапно); 3) ріст на одному рівні з іншими працівниками, включаючи девелоперів; 4) час для сторонніх проектів; 5) ніхто ні в чому, власне, не обмежує, аби робота робилася.

Это да, там только до спеца по сексу по телефону прокачаться можно. Или до коллектора.

А от і спєци підвалили.

Це неправильний урок. Саме там і треба. Але звісно ж вчитися треба реальному використанню влади нижнього рівня, а не мистецтву «ефективного менеджменту».

Сапорт в більшості випадків ніякий не сапорт. Це — зворотний зв′язок, свята святих управлінського процесу. Якщо компанія це галера, то сапорт — її киль.

L-1 рівень типовий «ефективний менеджмент» :
Поклацали на кнопки, не працює передали далі.
L −2 рівень. Побачили що не працює почитали продуктову документацію, поманіпулювали конфігурацією. Не допомогло відправили далі в кращому випадку описали сценарій проблеми.
L −3 рівень Пошукають логи, подивляться як воно працює в коді. В кращому випадку, знайдуть проблему опишуть і відправлять девам.

І тільки на цьому етапі з’являється людина яка може щось реально вирішити, а саме пофіксити баг.

І тут постає дилема ролі support. Між L1/L3 і девом простягається прірва у знаннях і функціональних обов’язках. То чи треба починати кар’єру в support коли врешті прийдеш до усвідомлення того що треба бути тією людиною яка має скіл вирішення проблеми?

Тільки на третьому рівні з′являється людина, яка може прочитати опис проблеми, а не вигадати її, побачивши знайомі слова. На перших двох самі тушканчики, які взагалі не знають про що мова та в руках продукт не тримали.

Як «ефективно» вирішити проблему по-совиному? Поставити бота, щоб навіть на 1 рівень не кожен міг добратися. Або й взагалі залишити лише бота.

Lifecell, це про вас. На новорічні свята вони залишили бота як у чаті, так і на телефоні, прибравши із IVR оператора взагалі.

Але ж я знаю, де ви ховаєтеся. Поспілкувався у фейсбуці з їхніми SMMщиками. Дарую лайфхак: вони і є справжня ланка зворотного зв′язку. Якщо є час та натхнення, можна навіть Укрпошті додати диму під хвіст.

Підписатись на коментарі