Специфіка роботи техпідтримки модульної системи

Доброго дня!

Мене звуть Олексій, я інженер технічної підтримки. Сьогодні розповім про те, як у нас в «ДоксВижн» вибудувана служба Helpdesk, з урахуванням специфіки платформного. Можливо, ця інформація допоможе компаніям, які вже щільно працюють в Helpdesk, а також тим, хто тільки планує збудувати канал спілкування з замовниками. До речі, ряд партнерів Docsvision вже скористалися нашим досвідом і впровадили Helpdesk з нашою допомогою.



Всі компанії, бізнес яких складається на надання тих чи інших IT-послуг, прагнуть бути клієнтоорієнтованими, і «ДоксВижн» не виняток. Як і багато інші вендори, ми не тільки самі виробляємо програмне забезпечення, але і надаємо послуги з технічної підтримки, прагнемо надавати їх якісно і своєчасно.

Я багато разів стикався з тим, що в компаніях по-різному надають послугу підтримки користувачів з технічної точки зору. На Хабре є кілька статей на цю тему, і ось ще одна, з якої ви дізнаєтеся, як це відбувається у нас.

Початок

Процес розробки ПЗ (і великого ЗА зокрема) може проходити за різними схемами, але в підсумку все зводиться до кількох пунктів і інструментів, які можуть бути використані:
• Середовище розробки;
• Система контролю версій;
• Трекер завдань;
• Системи автоматизованого і ручного тестування;
• Bug tracker;
• Helpdesk.

Звичайно, пункти можна доповнювати, об'єднувати або прибрати зайве, торкнувшись лише кілька аспектів, можна почати невеликий холівар :)
Але мета у мене інша.

Одночасна підтримка декількох версій

Програмне забезпечення необхідно придумати, розробити, протестувати, випустити у велике плавання (як ми говоримо «відвантажити») і почати його підтримку. Так як історія компанії і СЕД Docsvision почалася досить давно, то на 2014 рік ми маємо в підтримці кілька версій нашої платформи:
  • Docsvision 4.5
  • Docsvision 5.0
  • Docsvision 5.1
  • Docsvision 5.2
  • Docsvision 5.3
  • Docsvision 5.Х
У кожній версії платформи є, як мінімум, 2 релизные версії з повною назвою, наприклад, Docsvision 5.3.2529, тобто виходить приблизно 10 версій одночасно. До цього варто додати ще близько40 модулів платформи. Все це різноманіття продуктів і релізних версій Docsvision ми підтримуємо в роботі паралельно і кожен день.
Частина наших клієнтів співпрацює з нами з ранніх версій. Система електронного документообігу на підприємстві передбачає довгострокове партнерство з вендором, і техпідтримка для організацій, у яких потік вхідних і вихідних документів не припиняється ні на день, відіграє істотну роль.

Ранні роки

З перших версій Docsvision і донині технічну підтримку надавали ми самі, і початковою точкою входу була звичайна пошта. Користувачі в листах повідомляли про виниклі труднощі, прикріплюючи скріншоти і логи. У ході листування вирішувалися нагальні питання, накопичувалася база знань, і поступово з розширенням нашої компанії і зростанням кількості клієнтів зростала і кількість звернень від них. Для їх обробки потрібно було рішення (або комплекс рішень), яке допомогло б структурувати всі отримані дані.
Біля витоків процесу helpdesk в компанії і донині стоїть могутній «камінь», ім'я якому DVManagement™. І зараз саме час плавно перейти до того, що ми використовуємо всередині компанії.

Внутрішні інструменти
DVManagement — це сервер з встановленою платформою Docsvision, розташований в надрах нашої компанії, з яким зі своїх робочих місць працюють інженери технічної підтримки (і не тільки вони). Зараз на сервері встановлена остання релізна версія нашої платформи і додані спеціальні «картки», які ми називаємо issue. DVManagement є, по суті, нашою платформою з додатковим функціоналом багтрекер і helpdesk для обробки внутрішніх і зовнішніх зв'язків, до яких можна віднести:
• Запис нових вимог щодо реалізації функціоналу;
• Запис помилок;
• Запис виправлень (база знань);
• Тестові кейси (у невеликій кількості);
• To-do плани (в невеликій кількості).

Так як «платформа» досить велика, не всі підрозділи компанії використовують тільки «наш» багтреккер, частина роботи ведеться в репозиторії Team Foundation Server (а раніше Source Save).

Співробітники ТП щодня працюють з картками Issue, які виглядають приблизно так:



Issue є сполучною ланкою між двома нашими інструментами підтримки, а також служить для взаємодії виду «Інженер ТП-Розробник ПЗ».

У картки є необхідні поля, які повинні бути заповнені (версія продукту, назву фірми-замовника і т.д.)
Є кілька вкладок, в яких міститься додаткова інформація про статус вирішення питання і присутні такі стандартні опції, як:

• Прикріплення файлів і коментарів (з версіями);
• Історія спілкування інженер -> розробник (цей процес також може бути включений тестувальник або аналітик);
• Встановлення статусу «помилки»;
• Запит оперативного виправлення цієї помилки;
• Можливість зв'язати кілька карток.

Раніше, до впровадження зовнішніх інструментів взаємодії, вся переписка з клієнтами переносилася з пошти в DVManagement. Зараз це все збережено і використовується як велика база знань. З приходом зовнішніх сервісів процес трохи видозмінився: картці до issue були додані додаткові поля і опції. При кожній зміні статусу issue, а також при зміні будь-яких полів, автор цього issue одержує поштові повідомлення про зроблені зміни. Іншими словами, ніщо не залишиться непоміченим.

На поточний момент в системі вже близько 7000 створених issue, використовуваних співробітниками техпідтримки, а всього в системі близько 60000 об'єктів, створених за період з 2006 по 2014 роки. Не стверджую, що «чим більше, тим краще», але щодня база знань поповнюється. Це дуже допомагає, наприклад, при навчанні нових співробітників підтримки.

Зовнішні інструменти (Повний Дзен)

Поряд з DVManagement нам потрібен був інструмент, що дозволяє більш зручно фіксувати приходять заявки — і був обраний Zendesk, працювати в якому ми почали в 2011 році.



Zendesk поставляється як сервіс (SaaS), у вигляді сайту, доступного як нам, так і нашим замовникам. Це система з високою доступністю (хоститься на Amazon), спрямована саме на роботу з зверненнями, заявками або «тікетами», як іменуються питання всередині Zendesk.
У «ДоксВижн» є власний портал технічної підтримки, який доступний для ознайомлення навіть без реєстрації. А зареєстровані користувачі можуть написати нам на форум, і, при оплаченому пакеті оновлень, створювати заявки протягом усього цього терміну (наприклад, протягом року).

Деякі ключові моменти:
• Для роботи необхідно створити облікові записи інженерів підтримки, іменовані «агентами». Всього в «ДоксВижн» близько трьох десятків таких агентів.
• Є розгорнута система форумів, в яких клієнти можуть задавати питання і отримувати відповіді від інженерів підтримки, а також спілкуватися між собою — типовий приклад форуму по розробці (необхідна реєстрація). Всього у нас таких розділів більше десятка.
• Розширена система поштових повідомлень подій.
• Підтримка настроюваних SLA.
• Система контролю доступу (є різні категорії облікових записів — агент, кінцевий користувач, адміністратор форуму, глобальний адміністратор).
• Зручна прив'язка кінцевих користувачів до своїх компаніям.
• При бажанні, кілька користувачів з однієї компанії можуть брати участь в листуванні паралельно.
• Розширені статуси заявок (крім «відкрито», «закрито», «вирішене»), очікують якихось подій ззовні.
• Система макросів і тригерів (приклад: розподіл заявки на більш «вільного інженера»).
• Розширені звіти по багатьом подіям.
• Мобільні додатки для всіх платформ (тепер ми можемо відповідати на запити, перебуваючи в будь-якому місці).
• Інтеграція з соціальними мережами.


приклад мобільного додатки для Windows Phone 8

Нижче представлений скріншот інтерфейсу агента підтримки:



Користувачі, зареєстровані на порталі, можуть створювати заявки, які автоматично будуть взяті в роботу. Точкою входу в цьому випадку є сам портал підтримки (доступний за адресою) і електронна пошта: лист, відправлений на спеціальну адресу, відразу перетворюється в заявку — це ще одна особливість Zendesk.

При створенні заявки в helpdesk, користувач повинен заповнити певні поля, описати суть проблеми, і при бажанні прикріпити додаткову інформацію (це може бути скріншот або якийсь лог), ось як це виглядає Інтерфейс подачі заявки

Zendesk дозволяє мати абсолютно настроювані поля в створюваному тикеті: це може бути випадаючий список, радіо кнопка, або, наприклад, вибір зі списку встановлених адміністратором значень.
Всі заявки, створені в цій системі, обробляються в рамках зазначеного SLA і в залежності від придбаного пакета послуг. До речі, рівень критичності користувач має можливість вибрати сам.

Якщо говорити про динаміку кількості запитів, то її можна спостерігати на картинках нижче (нагадую, 2011 — рік впровадження Zendesk). Для прикладу взято 2013 рік, який за кількістю заявок поки «лідирує».





Більш цікаво спостерігати кількість вирішених заявок по місяцях. На графіку вище можна побачити, скільки було створено в місяць, і яка їх частина в цьому ж місяці вирішена.

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

Особливості Helpdesk в розрізі СЕД

Zendesk допомагає нам будувати канал спілкування із замовниками і клієнтами на новому рівні. Заявка, створена користувачем, буде опрацьована з урахуванням наявного SLA (Service Level Agreement — визначає взаємні відповідальності провайдера ІТ-сервісу і користувачів цього сервісу). І, якщо вже ми заговорили про відповідальність, згадаю і NDA (Non-Disclosure Agreement): перед замовниками, яких турбує конфіденційність переданих нам даних, ми зобов'язуємося не передавати їх третім особам. Також в Docsvision є інструменти, що дозволяють «знеособити» дані користувачів, передані нам у процесі роботи: інженер ТП не зможе побачити особистих даних користувачів або прочитати конфіденційну інформацію в довідниках клієнта.

Хоча за регламентом у служби ТП 8-годинний робочий день, робота інженерів побудована таким чином, щоб годинники всіх інженерів були розподілені і охоплювали максимально можливий час: наприклад, з 8:00 до 20:00. Це обумовлено тим, що допомога техпідтримки може знадобитися клієнтам в іншому часовому поясі.

В залежності від часу доби активність також змінюється:


Як видно, пік припадає на середину робочого дня. Робота кипить.

З-за великої кількості одночасно працюючих у наших замовників версій Docsvision, інженери повинні мати «під рукою" всі можливі версії Docsvision і комбінації встановлених модулів. Для таких випадків ми використовуємо близько 40 віртуальних машин. Гіпервізор використовуємо технології VmWare.

Але часто навіть великого «зоопарку» всіх версій ОС Windows, всіх Net Фреймворків і сканерів штрих-кодів (це ми теж використовуємо) в якийсь момент може не вистачити.

Наприклад, може статися, що буде знайдено неочікуване поведінку, яка стабільно відтворюється тільки на фізичних машинах (а віртуальних — ні) або на пристроях з тачскріном (моноблоки).

Гнучкість оперативних виправлень
У разі знаходження критичних помилок в роботі системи, у ряді випадків у наших партнерів і користувачів) немає можливості чекати виходу нової версії продукту або оновлювати всю систему — найчастіше це трудомістко, та й чекати не всі готові.
Багато помилки, усунення яких не вимагає великої трудомісткості, ми вирішуємо за допомогою оперативних виправлень. Якщо мова йде про сервер, то достатньо змінити одну-дві бібліотеки, і латка буде встановлена. З клієнтськими робочими місцями все ще простіше. Виправлення можуть бути отримані як за запитом, так і розміщені у вільному доступі у вигляді кумулятивних патчів.

Екстрена технічна підтримка
Для мінімізації простою критично важливих систем (документообіг на підприємстві — не виняток) у «ДоксВижн» існує послуга підтримки в екстреному режимі. Ми починаємо взаємодія з замовником в рамках більш швидкого SLA — час реакції в таких випадках не перевищує 1 години, а здебільшого інженери працюють онлайн. У цьому випадку, ми використовуємо всі можливі способи зв'язку з замовником (Skype, Lync, віддалені підключення) для оперативного вирішення проблем. При необхідності робота буде проведена у позаробочий час. Таким чином, значно скорочується час локалізації проблеми та випуску (при необхідності) виправлення.

Technical Account Manager
Під такою назвою працює виділений фахівець з боку служби технічної підтримки. У цьому випадку підвищується керованість процесом взаємодії між замовником і технічною підтримкою. Інженер є координатором заявки (заявок) від одного замовника, він спостерігає за вступниками заявками і, за необхідності, вживає заходів для більш ефективного вирішення. Виникає т.зв. «єдине вікно», в яке можна встановлювати як стандартні, так і суміжні питання. Інженер в цьому випадку представляється у вигляді «універсального солдата» і бере на себе як технічні, так і організаційні питання (організувати конференц-дзвінок, надати звіт за тижневої виконану роботу і т.д.)

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

Після кожного виконаного тікета користувачеві, що створив його, пропонується оцінити роботу інженера, натиснувши «мені подобається» або «мені не подобається». Сформований таким чином рейтинг тримається в районі 96%-99% — він доступний для всіх на окремій сторінці (дані динамічно змінюються).

Згідно внутрішнім регламентам, кожен квартал ми опитуємо користувачів (за допомогою Polldaddy) і просимо оцінити роботу по таким пунктам, як чуйність, ввічливість, повнота інформації, час першої реакції і т.д. Збираючи ці дані, ми отримуємо відгук, на основі якого робляться певні висновки. Одне з цікавих вимог — це можливість спілкуватися в режимі реального часу з агентами (Чат або Skype прямо всередині Zendesk), можливість ескалірувати проблему на більш високий рівень, можливість інтегруватися з іншими системами helpdesk або будувати звіти (з боку замовників).

Але, крім технологічних інструментів, на роботу співробітників helpdesk можна вплинути і по-іншому: я думаю, що відмінним візуальним інструментом був би якийсь Dashboard, який дозволяє інженерам (і керівників) відстежувати «гарячі» заявки в режимі реального часу, наприклад, на екрані телевізора у вигляді наочних графіків.

Також у планах на майбутнє — проводити щоденні зустрічі (за аналогією з SCRUM), в яких можна обговорювати поточну роботу, до речі, у наших колег з відділів QA та Development такі зустрічі вже давно проходять.

Модель helpdesk, вибудувана в нашій компанії, зручна для клієнтів і, до речі, знаходить відгук у наших партнерів, адже кожен з них на певному етапі стикається з питанням організації внутрішньої підтримки. Кілька компаній-партнерів вже впровадили у себе подібну helpdesk за допомогою нашого досвіду і знань.

Якщо ви готові поділитися своїм досвідом, прошу в коментарі — подискутуємо.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.