Зображення сайту easywebstudio.ru
Напевно, більшості читачів доводилося чути скарги програмістів з приводу того, наскільки їм не подобається виконувати функції технічної підтримки. У багатьох компаніях їм все ж доводиться це робити. Іноді подібні вимоги прописуються в тексті вакансій. Однак нерідкі випадки, коли нові обов'язки звалюються на розробника вже після його працевлаштування.
Так чи інакше, перспектива суміщення техпідтримки і розробки програмного забезпечення радує далеко не всіх програмістів. Робота фахівця технічної підтримки часто надається серйозним випробуванням для нервів розробника. Більш того, таке суміщення часто позначається на його результативності. Головному мозку потрібен час для перемикання з однієї діяльності на іншу. Для багатьох програмістів це означає кілька втрачених годин, які витрачаються на те, щоб повернутися зі світу людей у світ алгоритмів і кодування. А невдале спілкування з розгніваним користувачем і зовсім може вибити деяких розробників з колії на весь день.
Однією з причин відходу програмістів з компанії, як не дивно, може стати саме необхідність поєднувати технічну підтримку з розробкою. В одній з компаній, наприклад, для розробників були введені своєрідні «чергування»: кожен повинен був відпрацювати в підтримці певну кількість годин на тиждень. Ситуацію погіршувало те, що це доводилося робити не кожен день, і психіка розробника не встигала виробити стійку звичку. Як розповідав один зі співробітників цієї компанії, кожне чергування перетворювалося на відбування тяжкої повинності.
Можливо, ситуація, коли фахівець поєднує підтримку і розробку щодня, комусь здасться менш болючою. Але в цілому, суті це не змінює: доводиться виконувати додаткову, найчастіше неприємну, роботу на шкоду основній.
Зображення сайту stihi.ru
Ще один шлях до згаданого сумісництва - це, як не дивно, підвищення. Коли розробника підвищують до гордого звання «провідного програміста», серед його нових обов'язків може виявитися і підтримка. Принаймні, так заведено в деяких компаніях. У довершенні до всього, ця людина стає негласною «службою підтримки» для молодших за званням програмістів.
Більшість співробітників, які висловлюють невдоволення з приводу такого суміщення, аргументують його не тільки особистою неприязню до роботи з людьми, а й відсутністю необхідної кваліфікації. Якщо людині не дані такі здібності від природи, то без спеціального навчання робота на цій позиції дійсно викликає напругу.
Більш того, результати цього фахівця на терені розробки в цьому випадку теж почнуть знижуватися, що призведе до переробок, а можливо, до більш нервозної обстановки у всій команді. Крім цього, у розробника-сумісника не вистачить часу на особисте саморозвиток в плані програмування і вивчення нових технологій. Це загрожує зниженням вартості цього фахівця на ринку праці і також робить його менш корисним компанії.
Керівництво допускає такі ситуації, в тому числі, тому, що не ставиться до технічної підтримки досить серйозно. На території СНД поширені дві крайності - в підтримці працюють люди, які вміють спілкуватися, але не володіють знаннями в предметній галузі; у підтримці працюють кваліфіковані фахівці, які не вміють правильно вибудувати спілкування з розгніваними користувачами.
Безумовно, технічна підтримка - це така ж спеціальність, як і інші. Але часто цим очевидним фактом нехтують, сподіваючись таким чином заощадити, або просто недооцінюючи роль підтримки у своєму бізнесі.
Зображення сайту alexandrgilenko.com
Але навіть ті, хто намагається звернути увагу на техпідтримку, хочуть не одного і того ж: комусь потрібно ввічливе спілкування і психологічна допомога, а хтось вірить, що первинна ефективність і швидкість вирішення конкретної проблеми користувача. Останні навіть стверджують, що перші плутають технічну підтримку з «телефоном довіри».
Таким чином, у кожній компанії пріоритети шикуються по-різному. У тому випадку, коли техпідтримка є ще й активним двигуном маркетингової стратегії, навряд чи піде на користь участь розробника продукту. Нехай, він знає предметну область краще за всіх, але в цій ситуації потрібні інші знання і навички. Тоді, навіть розробники, які горять бажанням попрацювати в підтримці, навряд чи принесуть велику користь.
Але якщо техпідтримка покликана швидко вирішувати конкретні проблеми користувача, то розробник при бажанні (це варто підкреслити), може згорнути гори на цьому терені.
Щоб не протиставляти різні види підтримки, відзначимо очевидний факт: вони часто співіснують. Але, знову ж таки, в силу різних причин не всі вміють гармонійно розвивати ці напрямки. Крім того, залежно від фінансового становища компанії керівництво може зосередитися на тому чи іншому вигляді підтримки, заощадивши на інших.
Але якщо розробник все-таки став заручником такої «оптимізації» бізнес-процесів компанії і на нього звалився тяжкий тягар техпідтримки, у нього ще залишається надія на порятунок.
Зображення сайту videoforme.ru
Якщо в якості інструментів застосовуються e-mail, спеціалізовані helpdesk системи, чати і соціальні мережі, то більшості програмісту буде набагато легше освоїтися. Більш того, якщо і користувач, і розробник вміють зв'язно викладати свої думки в письмовому вигляді, вони швидко знайдуть рішення проблеми. Адже в письмово зафіксованому запиті будуть на виду деталі, які можуть стати в нагоді для вирішення проблеми.
При усному спілкуванні не можна гарантувати, що не будуть пропущені критично важливі деталі. Не кажучи вже про те, що часто користувач все одно змушений відправляти скріншоти або відео, тому що на словах описати проблему набагато важче.
«Привчивши» клієнтів до письмового спілкування, компанія може сподіватися, що розробник-саппортер заощадить собі нерви, буде швидше перемикатися між двома типами діяльності. Для цього достатньо організувати свою роботу так, щоб листи користувачів оброблялися в зручний час, не перериваючи хід глибоких сермяжних думок програміста і його процес розробки в цілому.
Зображення сайту journal.ib-bank.ru
Якщо дивитися на це без зайвої драматизації, до багато чого можна звикнути. Мова йде лише про те, як було б ефективніше використовувати ресурси компанії та особисті ресурси кожного співробітника. Якщо функції саппорту вішаються на розробника примусово, немає гарантії, що через місяць він не знайде іншу роботу. А якщо він ще й хороший розробник, то його відхід може обійтися компанії дорожче, ніж додатково найняти фахівця-техпідтримки на півставки.
Варіантів розвитку подій може бути багато. Не всі розробники однаково корисні. Деякі програмісти, навпаки, йдуть у техпідтримку з головою. Хтось, виявляється, однаково хороший і в розробці, і в саппорті. Тому ніхто не закликає мислити стереотипно, але увагу до загальних тенденцій і зворотного зв'язку співробітників ще нікому не зашкодило.
Кількість ресурсів компанії завжди обмежена, але зазвичай їх можна якось комбінувати, перетасовувати, знаходячи схеми найбільш ефективної взаємодії. Іншими словами, цілком може виявитися, що функції саппорту краще в даному компанії не доручати розробнику, а делегувати іншому фахівцеві.
Часто буває, що роботу в технічній підтримці органічно може поєднувати фахівець з тестування програмного забезпечення. Загалом-то, успішність такого підходу нам і показує практика. Тестувальник знає програмний продукт, його вузькі місця і взаємодіє з ним з точки зору користувача. Найчастіше цей фахівець краще знає, як обійти ці вузькі місця, він зможе підказати користувачеві і нюанси роботи з продуктом. «Прокачана» увага тестувальника до деталей буде як не можна до речі при аналізі користувальницьких скарг, запитів.
В одній компанії довелося спостерігати, як технічною підтримкою займався системний адміністратор. Він відмінно справлявся з цим. Іноді навіть виникали сумніви, в якій з двох ролей він виглядає краще.
А в якихось випадках, до технічної підтримки краще залучити менеджера проектів. Особливо, коли підтримка не «надто технічна» - така, де більш важливі спілкування і досягнення якихось домовленостей.
Подібні міркування з приводу «перетасовки» кадрів актуальні, швидше, для невеликих компаній, або для великих, але ощадливих фірм. Крім того, як відомо, чіткого поділу повноважень не варто чекати і від стартапів, де кожен співробітник цілком може виконувати кілька функцій.
P.S.
Справедливості заради, зазначимо, що історії відомо набагато менше випадків залучення фахівців підтримки до програмування. Однак точно відомо, що деякі з них були б не проти. Окремо варто згадати компанії, що займаються 1С-розробкою. Там дійсно поширена схема переходу з консультантів у програмісти. Звичайно ж, після відповідного навчання. Ну і саму роботу консультантом амбітні особистості сприймають як етап навчання.
А в середньому по лікарні, з великими труднощами можна знайти скарги (якщо вони взагалі є) на примус співробітників саппорту до програмування.
Зображення сайту joyreactor.cc
P.S.S.
«Ти ж програміст» - ця фраза давно стала мемом. Так чи інакше, кожен ІТшник періодично надає техпідтримку своїм родичам, друзям, друзям друзів і так далі. Іноді це виконується безкоштовно або за «шоколадку» і іноді викликає роздратування, коли таке відбувається занадто часто. Так що, якщо раптом на роботі пропонують займатися подібними речами на постійній основі, у багатьох «тиж-програмістів» спливає накопичений негатив.
