Когда разработчику вредно совмещать программирование и техническую поддержку ПО
Изображение сайта easywebstudio.ru
Наверняка, большинству читателей приходилось слышать жалобы программистов по поводу того, насколько им не нравится выполнять функции технической поддержки. Во многих компаниях им все же приходится это делать. Иногда подобные требования прописываются в тексте вакансий. Однако нередки случаи, когда новые обязанности сваливаются на разработчика уже после его трудоустройства.
Так или иначе, перспектива совмещения техподдержки и разработки программного обеспечения радует далеко не всех программистов. Работа специалиста технической поддержки зачастую оказывается серьезным испытанием для нервов разработчика. Более того, такое совмещение часто сказывается на его результативности. Головному мозгу требуется время для переключения с одной деятельности на другую. Для многих программистов это означает несколько потерянных часов, которые тратятся на то, чтобы вернуться из мира людей в мир алгоритмов и кодирования. А неудачное общение с разгневанным пользователем и вовсе может выбить некоторых разработчиков из колеи на весь день.
Одной из причин ухода программистов из компании, как ни странно, может стать именно необходимость совмещать техническую поддержку с разработкой. В одной из компаний, например, для разработчиков были введены своеобразные «дежурства»: каждый должен был отработать в поддержке определенное количество часов в неделю. Ситуацию усугубляло то, что это приходилось делать не каждый день, и психика разработчика не успевала выработать устойчивую привычку. Как рассказывал один из сотрудников этой компании, каждое дежурство превращалось в отбывание тяжкой повинности.
Возможно, ситуация, когда специалист совмещает поддержку и разработку ежедневно, кому-то покажется менее болезненной. Но в целом, сути это не меняет: приходится выполнять дополнительную, зачастую неприятную, работу в ущерб основной.
Изображение сайта stihi.ru
Еще один путь к упомянутому совместительству — это, как ни странно, повышение. Когда разработчика повышают до гордого звания «ведущего программиста», среди его новых обязанностей может оказаться и поддержка. По крайней мере, так заведено в некоторых компаниях. В довершении ко всему, этот человек становится негласной «службой поддержки» для младших по званию программистов.
Большинство сотрудников, которые высказывают недовольство по поводу такого совмещения, аргументируют его не только личной неприязнью к работе с людьми, но и отсутствием необходимой квалификации. Если человеку не даны такие способности от природы, то без специального обучения работа на этой позиции действительно вызывает напряжение.
Более того, результаты этого специалиста на поприще разработки в этом случае тоже начнут снижаться, что приведет к переработкам, а возможно, к более нервозной обстановке во всей команде. Помимо этого, у разработчика-совместителя не хватит времени на личное саморазвитие в плане программирования и изучения новых технологий. Это грозит снижением стоимости этого специалиста на рынке труда и также делает его менее полезным компании.
Руководство допускает такие ситуации, в том числе, потому, что не относится к технической поддержке достаточно серьезно. На территории СНГ распространены две крайности — в поддержке работают люди, которые умеют общаться, но не обладают знаниями в предметной области; в поддержке работают квалифицированные специалисты, которые не умеют правильно выстроить общение с разгневанными пользователями.
Безусловно, техническая поддержка — это такая же специальность, как и остальные. Но часто этим очевидным фактом пренебрегают, надеясь таким образом сэкономить, либо просто недооценивая роль поддержки в своем бизнесе.
Изображение сайта alexandrgilenko.com
Но даже те, кто пытается обратить внимание на техподдержку, хотят не одного и того же: кому-то нужно вежливое общение и психологическая помощь, а кто-то верит, что первична эффективность и скорость решения конкретной проблемы пользователя. Последние даже утверждают, что первые путают техническую поддержку с «телефоном доверия».
Таким образом, в каждой компании приоритеты выстраиваются по-разному. В том случае, когда техподдержка является еще и активным двигателем маркетинговой стратегии, вряд ли пойдет на пользу участие разработчика продукта. Пусть, он знает предметную область лучше всех, но в этой ситуации нужны другие знания и навыки. Тогда, даже разработчики, которые горят желанием поработать в поддержке, вряд ли принесут большую пользу.
Но если техподдержка призвана быстро решать конкретные проблемы пользователя, то разработчик при желании (это стоит подчеркнуть), может свернуть горы на этом поприще.
Чтобы не противопоставлять разные виды поддержки, отметим очевидный факт: они часто сосуществуют. Но, опять же, в силу различных причин не все умеют гармонично развивать эти направления. Кроме того, в зависимости от финансового положения компании руководство может сосредоточиться на том или ином виде поддержки, сэкономив на остальных.
Но если разработчик все-таки стал заложником такой «оптимизации» бизнес-процессов компании и на него свалилось тяжкое бремя техподдержки, у него еще остается надежда на спасение.
Изображение сайта videoforme.ru
Если в качестве инструментов применяются e-mail, специализированные helpdesk системы, чаты и социальные сети, то большинству программисту будет намного легче освоиться. Более того, если и пользователь, и разработчик умеют связно излагать свои мысли в письменном виде, они быстро найдут решение проблемы. Ведь в письменно зафиксированном запросе будут на виду детали, которые могут пригодиться для решение проблемы.
При устном общении нельзя гарантировать, что не будут пропущены критически важные детали. Не говоря уже о том, что часто пользователь все равно вынужден отправлять скриншоты или видео, потому что на словах описать проблему гораздо труднее.
«Приучив» клиентов к письменному общению, компания может надеяться, что разработчик-саппортер сбережет себе нервы, будет быстрее переключаться между двумя типами деятельности. Для этого достаточно организовать свою работу так, чтобы письма пользователей обрабатывались в удобное время, не прерывая ход глубоких сермяжных мыслей программиста и его процесс разработки в целом.
Изображение сайта journal.ib-bank.ru
Если смотреть на это без излишней драматизации, ко многому можно привыкнуть. Речь идет лишь о том, как было бы эффективнее использовать ресурсы компании и личные ресурсы каждого сотрудника. Если функции саппорта вешаются на разработчика принудительно, нет гарантии, что через месяц он не найдет другую работу. А если он еще и хороший разработчик, то его уход может обойтись компании дороже, чем дополнительно нанять специалиста-техподдержки на полставки.
Вариантов развития событий может быть много. Не все разработчики одинаково полезны. Некоторые программисты, наоборот, уходят в техподдержку с головой. Кто-то, оказывается, одинаково хорош и в разработке, и в саппорте. Поэтому никто не призывает мыслить стереотипно, но внимание к общим тенденциям и обратной связи сотрудников еще никому не повредило.
Количество ресурсов компании всегда ограничено, но обычно их можно как-то комбинировать, перетасовывать, находя схемы наиболее эффективного взаимодействия. Другими словами, вполне может оказаться, что функции саппорта лучше в данном компании не поручать разработчику, а делегировать другому специалисту.
Часто бывает, что работу в технической поддержке органично может совмещать специалист по тестированию программного обеспечения. В общем-то, успешность такого подхода нам и показывает практика. Тестировщик знает программный продукт, его узкие места и взаимодействует с ним с точки зрения пользователя. Чаще всего этот специалист лучше знает, как обойти эти узкие места, он сможет подсказать пользователю и нюансы работы с продуктом. «Прокачанное» внимание тестировщика к деталям будет как нельзя кстати при анализе пользовательских жалоб, запросов.
В одной компании довелось наблюдать, как технической поддержкой занимался системный администратор. Он отлично справлялся с этим. Иногда даже возникали сомнения, в какой из двух ролей он смотрится лучше.
А в каких-то случаях, к технической поддержке лучше привлечь менеджера проектов. Особенно, когда поддержка не «слишком техническая» — такая, где более важны общение и достижение каких-то договоренностей.
Подобные рассуждения по поводу «перетасовки» кадров актуальны, скорее, для небольших компаний, либо для крупных, но бережливых фирм. Кроме того, как известно, четкого разделения полномочий не стоит ждать и от стартапов, где каждый сотрудник вполне может выполнять несколько функций.
P.S.
Справедливости ради, отметим, что истории известно гораздо меньше случаев привлечения специалистов поддержки к программированию. Однако точно известно, что некоторые из них были бы не против. Отдельно стоит упомянуть компании, занимающиеся 1С-разработкой. Там действительно распространена схема перехода из консультантов в программисты. Конечно же, после соответствующего обучения. Ну и саму работу консультантом амбициозные личности воспринимают как этап обучения.
А в среднем по больнице, с большим трудом можно найти жалобы (если они вообще есть) на принуждение сотрудников саппорта к программированию.
Изображение сайта joyreactor.cc
P.S. S.
«Ты ж программист» — эта фраза давно стала мемом. Так или иначе, каждый ИТшник периодически оказывает техподдержку своим родственникам, друзьям, друзьям друзей и так далее. Иногда это выполняется бесплатно или за «шоколадку» и иногда вызывает раздражение, когда такое происходит слишком часто. Так что, если вдруг на работе предлагают заниматься подобными вещами на постоянной основе, у многих «тыж-программистов» всплывает накопленный негатив.
Комментарии (3)
redmanmale
21 июля 2016 в 13:25
0↑
↓
Всегда?
claygod
21 июля 2016 в 13:41
0↑
↓
Помимо минусов есть и плюс, если программист на саппорте получает горячие багрепорты.
Wedmer
21 июля 2016 в 13:59
0↑
↓
Это только в том случае, если багрепорты не в том виде, когда хочется обратившегося послать кое куда, чтобы там медведи делали с посылаемым кое что.
