Коли розробнику шкідливо поєднувати програмування та технічну підтримку ПО


Изображение сайту easywebstudio.ru

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

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

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

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


Изображение сайту stihi.ru

Ще один шлях до згаданого сумісництвом – це, як ні дивно, підвищення. Коли розробника підвищують до гордого звання «провідного програміста», серед його нових обов'язків може виявитися і підтримка. Принаймні, так заведено в деяких компаніях. У довершенні до всього, ця людина стає негласної «службою підтримки» для молодших за званням програмістів.

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

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

Керівництво допускає такі ситуації, в тому числі, тому, що не відноситься до технічної підтримки досить серйозно. На території СНД поширені дві крайності – у підтримці працюють люди, які вміють спілкуватися, але не володіють знаннями в наочній області; в підтримці працюють кваліфіковані фахівці, які не вміють правильно вибудувати спілкування з розгніваними користувачами.

Безумовно, технічна підтримка – це така спеціальність, як і решта. Але часто цим очевидним фактом нехтують, сподіваючись таким чином заощадити, або просто недооцінюючи роль підтримки в своєму бізнесі.


Изображение сайту alexandrgilenko.com

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

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

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

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


Изображение сайту videoforme.ru

Якщо в якості інструментів застосовуються e-mail, спеціалізовані helpdesk системи, чати і соціальні мережі, то більшості програмісту буде набагато легше освоїтися. Більш того, якщо користувач, і розробник вміють зв'язно викладати свої думки в письмовому вигляді, вони швидко знайдуть рішення проблеми. Адже в письмово зафіксованій запиті будуть на виду деталі, які можуть знадобитися для вирішення проблеми.

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

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


Изображение сайту journal.ib-bank.ru

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

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

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

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

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

А в певних випадках, до технічної підтримки краще залучити менеджера проектів. Особливо, коли підтримка не «занадто технічна» – така, де більше важливі спілкування і досягнення якихось домовленостей.

Подібні міркування з приводу «перетасовки кадрів актуальні, швидше, для невеликих компаній або для великих, але ощадливих фірм. Крім того, як відомо, чіткого поділу повноважень не варто чекати і від стартапів, де кожен працівник цілком може виконувати кілька функцій.

p.s.

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

А в середньому по лікарні, з великим трудом можна знайти скарги (якщо вони взагалі є) на примус співробітників саппорта до програмування.


Изображение сайту joyreactor.cc

P. S. S.

«Ти ж програміст» – ця фраза давно стала мемом. Так чи інакше, кожен ИТшник періодично надає технічну підтримку своїм родичам, друзям, друзям друзів і так далі. Іноді це виконується безкоштовно або за «шоколадку» і іноді викликає роздратування, коли таке відбувається дуже часто. Так що, якщо раптом на роботі пропонують займатися подібними речами на постійній основі, у багатьох «тыж-програмістів» спливає накопичений негатив.
Джерело: Хабрахабр

0 коментарів

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