×Закрыть

Должность support engineer. Стоит ли переквалифицироваться?

Когда речь заходит об ИТшниках, то первым делом вспоминается должность программиста. Через 2 сек вспоминается должность тестера.

Но на этом список ИТшников не заканчивается. Есть должность support engineer, которая предполагает помощь кастомерам в использовании тем или иным ПО, которое разрабатывает компания. Я работаю в саппорте уже довольно долгое время и вижу как коллеги стараются уйти из саппорта в программирование или тестирование. Глядя на этот процесс я несколько недоумеваю. В чем причина? Саппорт вроде нормально оплачивается, нельзя сказать, что эта должность проживет меньше, чем должности тестера или программиста. Также, это хорошая работа для поддержания высокого уровня английского. Но общий тренд, который я наблюдаю — это именно валить из саппорта в программисты/тестеры.

Кто что думает на этот счет? Кто как оцениеваете перспективность данной профессии? Замечаете ли тот же тренд, что и я? Какие плюсы/минусы этой профессии наблюдаете?
Очень интересует опыт тех, кто перешел из саппорта в тестеры/программисты. Довольны ли переходом?
Понятно, что если дев работал последние 5 девом, то переквалифицироваться в саппорта не стоит. Но проработав 5 лет саппортом, стоит ли переквалифицироваться в тестера/дева, начиная все с 0, точнее с позиции junior или даже traniee?

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

Скажите, пожалуйста, есть какие-то общие требования для сапорта? что нужно знать? что подогнать/ почитать?

Все дуже залежить від продукту, структури компанії і відділу тех підтримки зокрема, наприклад на попередній роботі я працював у третій лінії три рівневої тех підтримки, і там було дуже весело зі сторони цікавості завдань, бо там крім траблшутінгу ти відразу писав асемблерівську поправку на код тестів її, і після кількох додаткових процесуальних стадій вона вилітала в світ. Але були на тій позиції мінуси — недоплата, ембедед продукт, що написаний на внутрішній мові, висока завантаженість (90% часу ти сидить над черпанням) + дуже інертні процеси, і навіть якщо ти бачиш як працювати ефективніше і пропонуєш оптимізацію з конкретним шляхом впровадження, то в самому позитивному випадку воно впровадиться за 4-6 місяців, жодного разу не спілкувався з безпосереднім клієнтом. Дехто ці мінуси за плюси порахує, але це те що мені особисто не подобалось і на що я вплив якщо і мав то надто непрямий.
Враховуючи ризики і незадоволення я приймав рішення змінити роботу, таке рішення приймав двічі. Першого разу після 3,5 років попробувався в QA і зрозумів що тех підтримка все-таки моє. Вдруге, щоб змінити на достойну позицію потратив 1,5 роки, при чому я міг потрапити на цю ж позицію і за пів року, та коли вона відкрилась перший раз її закрили внутрішнім ресурсом.
В результаті: третя лінія з чотирьох, SaaS продукт, завантаженість по черпанню 30-40%, більше роботи з другої і першої лінії(контакт з клієнтами і кінцевими користувачами) але в міру 5-10%, і технічний вакуум що з’являється я заміняю написанням скриптів по автоматизації + виділенню статистики що відноситься до клієнтів, за що мені дуже вдячні, як на словах так і по ЗП.
Висновки : якщо відчуваєш що займаєшся цікавою роботою — залишайся в тех підтримці, пробуй змінювати те що тобі не подобається на поточному місці, якщо не виходить — міняй компанію, це досить легко, враховуючи що більшість перекваліфіковується з тех підтримки деінде. На рахунок релокації не парся є достатньо вакансій для тех підтримки на релокацію.

Автор и многие участники беседы не правы в том, что считают support более низкооплачиваемой должностью, чем QA. На примере своей компании могу утверждать, что в отделе тех. поддержки более серьезные требования к знанию предметной области, английского и своего продукта, чем у QA.
Тенденция перехода из Support->QA, вероятно, существует в отдельных взятых проектах, но, уверен, далеко не во всех. У себя мы наблюдаем обратную тенденцию.

В соседней теме айтишник от 5000 баксов носом крутит. Ещё через пару тем кто-то валит в Амазон по рабочей визе на зп 100К+. А какие перспективы у саппортеров?

ну, шо есть какие-то подвижки?

у девелопера, QC, PM или BA фронт работ сильно разнообразнее. рост подразумевает больше двух ступеней(support engineer -> team lead).

а как вообще выглядит развитие на вашей позиции? решать проблемы посложнее и побыстрее?

up, тема скатилась.

Не совсем понятно почему большинство компаний под саппортов набирают бывших студентов, или вообще нулевых ребят без знаний и хотят им платить соответствую зп(особенно это хорошо заметно в местных компаниях). С чем это связано? Саппорт сейчас — это уже давно не «начальная» позиция.

У меня складывается впечатление, что направление саппорта является перспективным. Но на примере своих знакомых саппортов наблюдаю странную тенденцию — свалить из саппорта(зачастую синиор) в джуниор девелоперы. И не могу понять зачем они это делают.

Я разделяю Ваше мнение насчет перспективности. Может в теме отпишется кто-то, кто перешел из саппорта в девы\девопсы. Будет интересно послушать.

Ну, я и так знаю саппортов, которые перешли в дэвы (джун). При этом потеряли в з/п в 2-3 раза. И они довольны.
И я пытаюсь понять зачем они это делают, чем они так довольны. Но конкретного ответа так и не услышал.
Сразу приходит на ум аргумент, что дэвом таким людям работать больше нравится. Но как можно сравнивать работу где есть опыт с работой, где нет опыта?

Посмотрел профиль в линкдине: я так понимаю вы чините всякие линаксы/виндовсы, когда что-то пошло не так. Тут есть несколько вариантов развития ситуации:
— в какой-то момент оказывается что текущие таски как-то уже приелись, но с другой стороны, в свободное от работы время вы ваяли скрипты на ХХХ и в принципе это нравилось. Поэтому, логично, пойти туда где больше нравилось — соответственно в разработчики. Если толковые чуваки — то в джунах они ходить будут не так долго.
— в какой-то момент оказывается что логичным продолжением текущих тасков является уже не «чинить», а «строить». «Строить» по-модному называется DevOps. Вполне возможно что и сейчас, в рамках суппорт-тайтла, на вас валятся таски, которые уже совсем не поддержка, а администрирование. Просто это в силу исторических причин называется поддержкой в отдельно взятой организации.
— ну и наконец: можно расти и в суппорте as is. У RedHat, Cisco, Novell и прочих тоже есть суппорт. Местами крутой. Это тоже наверное интересно, но не факт что в этой стране в шаговой доступности :)

Насчет профайла в линкед-ине, видимо надо его подредактировать, раз складывается такое впечатление )
На самом деле, я саппорчу наше корпоративное приложение, которое конечно использует всякие линаксы/виндовсы.
Насчет Девопса, ситуация на рынке труда немного странная. Никто толком не может сказать что такое DevOps Engineer и это проблема. Получается, в некоторых организациях отдел админов переименовывают в отдел девопсов и нанимают туда девопс инженеров, хотя по сути это может быть обычный сетевой администратор.
Поэтому, при попытке устроиться девопсом надо тщательно выяснять что же под этим термином работодатель подразумевает.
У меня, при попытке понять что такое настоящий Девопс инженер, сложилось впечатление, что это ближе всего к билд или релиз инженеру.

DevOps действительно странная штука. В близкой к оригинальной трактовке: это или админ который умеет дебажить (ок, знает про код больше чем то как его запустить), или программист, с root-правами на проде, который не ведет себя как обезьянка в посудной лавке. Соединение в одном персонаже возникло из двух предпосылок:
— в класическом варианте есть программисты, которые пишут код, и есть по разному называющиеся Ops, которые его как бы запускают, мониторят и так далее. И они друг друга тихо ненавидят, ну или не тихо, и время от времени покидываются друг в друга какашками. При этом любое решение проблем с приложением требует как минимум этих двух персонажей в комнате, потому что один видит проблему, но не может объяснить, от другого ждут объяснений, но без доступа к нужному окружению — это может быть проблемой.
— Continuous Integration, Continuous Delivery и иже с ними. Опять же: те кто знает код as is, в принципе лучше понимают как его релизить, как его безболезненно откатывать, и когда его самое время откатить, если что-то идет не так.

И идеи в приниципе правильные, и собственно в роли «между двумя мирами» ничего особо нового нет: возникло из практических наблюдений, когда оказалось что иметь таких персонажей очень помогает. Но дальше злые шутки начали играть инструменты и желание продавать.

Инструменты. Программисты на рельсах, которые с рубиновым блеском в глазах пилили свои уютненькие стартапики в конце 2000-х с тревогой заметили, что а) деплоить эту фиговину гораздо сложнее чем писать, б) оно падучее, поэтому чтобы хоть как-то удерживать это на плаву, нужно много инстансов, а деплоить эти инстансы: см а). В какой-то момент кто-то решил шо решать эти проблемы не-хипстеровскими шелл скриптами — как-то не по пацански, и.. так появился puppet, а потом chef. С другой стороны появился AWS и всякие Heroku. Чуть позже оказалось что вообще прикольно не тока запускать много виртуалок на одной физической машине, а неплохо было бы вообще сделать окружение в котором непосредственно работает код более предсказуемым(а то фиг этих линуксоидов знает что они там еще учудят): модный нынче docker.

— «Хм» — почесали умные люди головы, — «Да тут инструментов на отдельную специальность хватит».
— «Да, этим же всегда админы рулили» — сказали другие.
— «Не, админы это не круто, админы уже есть. О! А вот DevOps — это стильно, модно, молодежно. С облаками и as a service получилось, чем это хуже?»
— «Эххъ, была не была» — подумали аутсорсеры, и стали искать «Sr. DevOps’ов, с пятью годами опыта в AWS, Chef/Puppet/Ansible, ну-и-этих-всех-прочих-модных-штуках», забывая что еще пару лет назад оные персонажи были нафиг никому не нужны.

А когда перечитают ІTIL, то еще 100500 специальностей переименуют.

да. и все должны быть с пятью годами опыта.. Скоро и дети в школе в шесть лет должны будут с пятью годами опыта чтения и письма на нескольких языках и \кономику,экономику! чтобы к единице там стремилась, как положено. Булеву алгебру пусть друг другу объяснять во втором классе начинают, а учитель потом протестирует правильно или нет)

А вот еще, что я думаю, по поводу пять лет. Изначально, у нас тут рынок ориентирован на заграничный. туда наши многие стремились и раньше еще. А там всегда требования: пять лет, стронг килс и флюент инглиш. Так наши компании, видимо не придавая значения настоящему бизнес-анализу, начали такие же требования тут выдвигать. Теперь наоборот, туда вынуждены уезжать совсем молодые специалисты. Как обычно никто о нас не заботится на самом деле и не урегулирует это все.

Про года опыта: все просто, чтобы иметь опыт в N лет сейчас, очевидно, что нужно было начинать N лет назад. Для некоторых технологий, это в принципе-то своем значит что вполне возможно вами было принято весьма рисковое техническое решение. Раз уж топик про админов и прочих суппорт девопсов, вспоминается известная книга Эви Немет и компании для системных администраторов Linux/Unix, где они рекомендуют при выборе операционной системы обращать внимание на то:
— будет ли дистрибутив существовать следующие пять лет
— будут ли оперативно устранятся бреши в системе защиты
— будут ли оперативно выпускаться новые версии программных продуктов
— будет ли оказана помощь в решении возникших проблем.

Те же вопросы можно отнести не только к дистрибутивам, а и к языкам программирования, фреймовркам, и прочему. В конце-концов выбирая технологию мы не рассчитываем мигрировать на новую через год, это не имеет большой ценности для бизнеса.

А теперь представим: 3 года коммерческого опыта в node.js или Angular, 1 год в React.js — самые востребованные нынче фронтендеры. Для того чтобы получить этот коммерческий опыт нужно было втащить в свой проект недавно появившуюся на горизонте, сырую штуку, с сомнительными перспективами на будущее. То есть массово ищутся специалисты, которые как специалисты проявили свою «экспертизу» в технологиях не самым лучшим образом. (Не, понятно что можно играться в стартапы, и прочие пет-проджекты, с новыми технологиями итп итд, но это исключения). Правда так же массово они не находятся, потому что не всякий кастомер разрешит тащить к себе все что вчера зарелизили.

Ну и с админами, девопсами и прочим: там еще веселее. Чтобы найти человека с 3-5 годами опыта надо представлять что там было у нас в этой сфере 3-5 лет назад. Типичный remote-админ: это чувак который билдит всякие apache/php/mysql/svn и прочее, возможно какой-то технический суппорт или что-то типа. Amazon и прочий cloud — врядли, разве что только если фриланс или контракты напрямую с буржуями. В более мелких конторах: тоже самое делал девелопер которому больше всех надо, или который лучше других разбирался в Linux (ну то есть знал не две команды, а десяток, и мог сам себе поставить Ubuntu так чтобы она еще и работала). При этом сменить работу было несколько сложно: по большому счету никому это нафиг было не надо, за редкими исключениями. В основном в эту сферу шли те кто интересовался Linux’ами, но программирование не перло. Где ж вы щас возьмете в промышленных количествах людей, обученных новомодным штукам(особенно с учетом первой части про технические решения, админы в этом плане еще более консервативны чем девелоперы)? :)

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

Что такое Sr суппорт? Это Sr в команде суппорта первого уровня, который стоит с кнутом над мидлами и джунами, или это «тот дядька, к которому бегут, если действительно все плохо»?

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

А Team Lead — это тот, кто учит и дает пи***лей ))

А может они видели себя технарями серьезными? Изначально в детстве. Чтобы сказать «Я математик!!» ? Это я так, как вариант. Раз они молчат и не могут объяснить, значит карьерный рост просто им необходим. Иерархия. Кстати, в саппорте есть Тим Лид?

Сейчас вообще начальных позиций ни в чем нет, практически. Или через учебу туда берут. Или отсеивают сразу. Иди читай, говорят... Энциклопедию учить наизусть. Это рынок труда заполнен. Вот и все. Будут новые заказы на разработку ПО. Появятся и вакансии... а так.. упс... нет... мало... совсем мало.

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

Для любого айтишника важно иметь офисы компании за рубежом. Т.е. работать на загранчную компанию. Но не пойму чем это облегчает жизнь именно саппортам.

Тем, что если у тебя есть саппорт за границей в твоей же компании, у тебя есть шанс туда свалить когда-нибудь при желании. Пока я не видел толковых саппортов, из международных компаний, у которых были бы какие-то проблемы. Если голова на плечах есть, сапортишь сложный софт и умеешь калякать по английски, то перспективы очень хорошие. Ничем не хуже девов, а то и лучше.

Да, это понятно. Но при прочих равных условиях дэвы все-равно в бОльшем выигрыше, не так ли? Дэвы тоже могут релокейтится и саппорты не имеют в этом плане преимуществ перед дэвами

Я не совсем понимаю, что ты хочешь услышать? Что девы все в лучших условиях, чем саппорт? Нет, это не правда, старший инженер поддержки 2-3го уровня сам по себе может быть полудев, так же, как и получать может не меньше. Когда мне надоел саппорт 1го левела, я не пошёлв QA, я не пошёл в девы, я пошёл в саппорт 2го левела в другую компанию, там осваивать начал базы данных, скрипты, корпоративный софт, начал участвовать в совещаниях как бизнес аналитик, искал решения в конфигурации по запросам клиентов, но у меня не стоял вопрос QA/DEV, потому как я всегда занимался одним и тем же и мне это всегда нравилось. Ты, похоже, просто свою позицию перерос, я бы на твоём месте поискал другую работу, тоже саппорт, но более технический, более сложный.

Я хочу услышать опыт тех кто перешел в dev/qa из support и какие от этого впечатления. Насколько жизнь стала легче и насколько возросла востребованность на рынке труда.

Либо, другой вариант, хочу услышать как стать senior support. Возможно, этот вопрос такой же вечный и риторический как и переход от junior dev к senior dev. Т.е. никто не знает универсального рецепта, но все его как-то находят для себя ☺
В частности, я не пойму зачем саппорту шарить скрипты. Почти в каждой вакансии senior support вижу, что надо шарить bash/pyton/perl. Что senior support’ы делают на перле и питоне?

как стать senior support. Возможно, этот вопрос такой же вечный и риторический как и переход от junior dev к senior dev.
А что сложного? Работаешь хорошо, чуть смотришь что вообще у вас в конторе надо и по индустрии вообще. Как становится скучновато — ищешь работу на плюспицот. Как освоишься — осторожно разузнать про возможности карьерного роста внутри конторы тоже не вредно.
Работаешь хорошо, чуть смотришь что вообще у вас в конторе надо и по индустрии вообще. Как становится скучновато — ищешь работу на плюспицот.
Недавно так и сделал. Годный рецепт. Причем, очевидный ))

Теперь можно сконцентрироваться на этой части

Как освоишься — осторожно разузнать про возможности карьерного роста внутри конторы тоже не вредно.

Просиживаешь штаны года 3-4 в одной конторе интеллектуально деградируя но получая бонус к «опыту» для своей cv. В один прикрасный миг когда взыграет ЧСВ ищешь работу на плюспиццот, готовишься к интервью, сертификаты там, книжки хорошие, успешно проходишь (ну там хоть и на плюсдвести). В новой более серьезной конторе понимаешь что уровня знаний катастрофически не хватает, начинаешь интересоваться автоматизацией рутинных тасков, сложными скриптовыми реализациями, оптимизацией софтварных интерпрайз решений, свободной работой с sql из консоли со сложными выборками итд итп.
Когда знания будут на уровне начинаешь просто учить и пробовать Ansible, Jenkins/Maven, Docker, потому что это п..ц как модно и востребовано. Через годик все, ты уже крутой devops с пятилетним стажем и спокойно просишь на интервью $2000 со старта с потолком по рынку в $3500 в месяц (зарплаты на примере Минска)

успешно проходишь (ну там хоть и на плюсдвести). В новой более серьезной конторе понимаешь что уровня знаний катастрофически не хватает
Как раз на этом этапе. Через неделю выхожу на новую работу и уже предвкушаю как буду
интересоваться автоматизацией рутинных тасков, сложными скриптовыми реализациями, оптимизацией софтварных интерпрайз решений
В частности, я не пойму зачем саппорту шарить скрипты.

Эмм... а вот это уже очень странный вопрос... А что, в данный момент ты как сапорт первого левела работаешь только с виндой и на телефоне сидишь и поэтому даже не представляешь зачем нужно хорошее знание шела?)) Тогда это даже не первый левел, это нулевой. Для начала нужно минимум год-два поработать в реальном сапорте первого левела по линухе и сетям, это база.

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

А вообще, да, некоторые собеседования так и проходят: «Делаем вам оффер на минуспиццот, раз вы такие вопросы на собеседовании задаете»

зачем нужно хорошее знание шела?
И скажите спасибо за такой оффер!

И мне интересно. А никто не пишет чего-то

А как у вас со сменой работы?
У сферического джава синиора, который писал веб-энтерпрайз, например, в случае чего, без проблем получится сменить работу на другой веб-энтерпрайз, даже если предметная область свосем другая. Смена будет без потери в позиции или ЗП, потому что разработчиков в первую очередь ищут по техническим скиллам.
Но вот стали вы синиор саппортером у себя на проекте, идеально знаете продукт и предметную область, но компания закрывается. Что дальше? Ведь в другой компании будут совершенно другие продукты или даже предметная область, эффективность вашей работы долгое время будет ниже, пока во все не вникнете. Не будет ли потери по ЗП?

При переходе от саппорта к саппорту позиция или ЗП не теряется. Но в целом з/п ниже и работу приходится искать дольше.
Вообще, классический ответ на мой вопрос (уж лучше я напишу это первым☺), звучит так: «надо понять к чему лежит душа». Но, по-моему, так нельзя. Я не могу сравнить саппорт ни с программированием, ни с тестированием, потому что, с одной стороны кроме саппорта никем не работал. С другой стороны, переквалифицироваться только ради того, чтоб попробовать — это слишком. А сравнивать в теории «что вообще в принципе больше нравится» — это не то. Запилить какой-нибудь сайтик на пхп и работать пхп программером — это совсем не одно и то же.

Честно несколько раз пытался стать программистом. Понял, что писать код — невыразимо скучное занятие (по крайне мере для меня).
Может зарплатная планка и пониже, но работа, как по мне — на порядки интереснее. А «не расту как девелопер» — странно, потому как всегда есть что автоматизировать и улучшать, особенно если поддерживать что-то сложнее офиса с 1Ской. Ну и немаловажно общение с людьми. С машиной постоянно общаться скучно и предсказуемо :)

Платят примерно как програмистам, работа для людей со стойкой психикой и постоянно под стрессом. У нас примерно так.

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

дев об этом не думает =)
токо сроками на вчера могут напряграть

Сроки «на вчера» — несколько огорчают

Работал в саппорте в крупной компании 3 месяца, после чего уволился и сейчас работаю Junior Android developer-ом.
Причины моего ухода:
1) График. В компании, где я работал, у техподдержки строго определенный график с 9 до 18. Приходят новые инциденты, их нужно обрабатывать как можно быстрее.
2) Больше половины времени (!) уходит на общение с клиентами. С коммуникацией проблем нет, поначалу даже очень нравилось, что такой опыт получаю. Но через пару месяцев стало надоедать, очень мало прогрессировал как девелопер.
3) Приходит новый инцидент — ставишь его себе в график. Приходит критический инцидент — бросаешь всё, разбираешься с ним. Бывает, по несколько раз в день меняешь приоритеты задач. Получается рваная работа, ты должен уметь быстро переключаться между тасками. Со временем начала от этого болеть голова, был вымотан.
4) ЗП. Обычно она меньше, чем у программистов с тем же опытом работы.

Это что касается саппорт.
А самым важным для меня была большая тяга перейти в мобайл, именно в прод. Переходом очень доволен — интересный проект, бурный рост, гибкий график, классная команда, повыше ЗП. В общем, в удовольствие! И чувствую, что здесь я могу лучше реализовать свои возможности.

Потому что должен быть бек-офис, который принимает заявки и настоящий программер, который исправляет. То есть в паре работать. А так как экономия. Вот и тянет две должности и бегает то к почте, то скайпу и телефону, то кодить... Это для людей, которые любят сами выявлять проблему пользователя, общаться и не засиживаться над монотонным процессом разработки. Просто, вот для смешанного типа психологии холерико-меланхоликов и сангвинико-флегматиков в пропорции 50 на 50%

свалить в программисты и быстро срубить бабок — можно.
но в перспективе у нас — саппорт — тим лид — СТО. Это вин! :) развитие программиста? жун — мидл — синьор — тим лид — архитектор.

саппорт — тим лид — СТО. Это вин! :)
Это вин для тех кто любит болтать и не боится ответственности, причем не только за себя.

Типа у саппорта дорога до тимлида и СТО быстрее? ))
Вообще, у меня такое ощущение, что направление саппорта должно развиваться. Раньше были одни программисты. Потом появились тестеры. А потом еще и саппорт. Хотя, скорее, востребованными будут саппорты-полудэвы, а не просто саппорты в том виде как они есть сейчас.
P.S.: Это чисто субьективная попытка предсказать развитие ИТ.

Саппорт-тестер тоже вариант) Я сейчас парт-тайм саппорт. Очень круто прокачивает скиллы общения с кастомерами и подтягивает английский.

Саппорт-тестер
Это какая-то уникальная позиция. Наверное всречается нечасто.
Было бы хорошо иметь побольше переходных позиций, чтоб люди, которые в сомнениях, могли бы посидеть на 2х стульях и понять что для них лучше. Но я такого не встречал.
Вы первый кто о такой позиции написал ☺

Структура саппорт-тестер зависит от компании. Где-то саппорт это первый уровень поддержки, чисто поговорить и зарегистрировать инцидент, а где-то саппорт это и доступ к базе данных, и развёртывание серверов с софтом, и какой-никакой девелопмент.

Раньше были одни программисты. Потом появились тестеры. А потом еще и саппорт.

Саппорт появился ровно в тот момент, когда программист с доу забыл написать коммент в овнокоде, т.е. через секунду после появления программиста.

в этом году с десяток support engineers компания, в которой я работала, перевезла в долину на зп 110-120к. Нужны наверное

А что делает support engineer? Просто у нас Support Developer — это программер не очень высокого уровня, но который может экранировать заказчика, в случае хорошего уровня — он решит проблему заказчика, в случае плохого уровня — он просто съэкономит время обычного разработчика, сгрузив ему уже пережеванную проблему заказчика, если это не тривиальный багфикс.

Как пример того, что он делает у нас: www.linkedin.com/...bs_jserp_job_listing_text

В одній досить великій компанії бачив реальні ЗП, які отримують працівники підтримки (Linux, Windows, Cisco, MySQL, Oracle...) та програмісти (PHP, JavaScript, Java). В рядових програмістів ЗП як у начальника відділу підтримки...

Это до тех пор, пока ты не встретил саппорта какого-нибудь корпоративного софта или реально толкового цискаря или ораклиста. Может ламера девы и получают больше, чем ламера админы, а бородатый админ-линуксойд в зелёном свитере ральф лорен может получать вполне прилично.

Якраз таки «саппорт корпоративного софта», причому не слабенко такого банка, який дозволяє собі платити повністю білу ЗП абсолютно усім своїм співробітникам, а також розплачується з партнерами «білими платежами». Загальна кількість співробітників (не лише ІТ) до тисячі чоловік.

Белой ЗП по курсу 25 только на сапоги и хватит. Раздели эту ЗП на 8, добавь знак $ и получишь то, что получает такой же админ, но в нормальной конторе.

У нас з тобою відрізняються поняття “нормальной конторы”. Не уважний ти якийсь, або просто ватний. Бо як ти по-іншому можеш знати яку суму ділити на 25 і на які “сапоги” вистачить результату ділення?

Наверняка ти один із тих “кому государство Украина нифига не дало. Так почему они должны платить налоги и, упаси Господи, воевать в АТО?”

Я по курсу 8 получал 3500$ белой зарплаты. По курсу 25 сам посчитаешь, сколько я получал $? Вот то же самое с твоим админом. А получал бы я 3500$ зарплаты СПД, получал бы их и дальше и не пришлось бы переходить туда, где платят $. Точно так же и с твоим админом. Пойди в epam/luxoft/GL или любую другую приличную аутсорсинговую контору, и посмотри сколько там получает старший инженер поддержки бизнес софта 2-3го уровня.

Пойди в epam/luxoft/GL или любую другую приличную аутсорсинговую контору, и посмотри сколько там получает старший инженер поддержки бизнес софта 2-3го уровня.

А сколько? 2К дол вроде потолок
Или нет?

Если 2к потолок, то как я получал 3.5?) Как мои коллеги получали 2.5к 6 лет назад?) 2.5-3к получать можно, лид будет и больше получать. Но про первый уровень поддержки винды речи не идёт, нужно саппортить бизнес софт, и лучше всего саппортить каких-нибудь америкосов.

получал 3.5
При курсе 8 ? :)
Что ж, надо будет пересмотреть что там в
epam/luxoft/GL
Хотя я хорошо запомнил как искал в мае 2015 го вакансии саппорт в GL. Была аж 1 вакансия Junior linux support и ситуация не менялась месяц (дальше не следил)
Как мои коллеги получали 2.5к 6 лет назад?
6 лет назад курс был 8 и хорошим спецам аж бегом пятнашку давали с перспективой. Даже 1С-никам.
2.5-3к получать можно, лид будет и больше получать
Теоретически, работая в бодишопе и на саппорте буржуев. На практике же буржуи влегкую нанимают на такие должности смуглых братьев, как афишная тумба обклееных всеми возможными МС-Циско-Редхат-ВМВарь-етц. дипломами, но по рейту в 10-12 баксов против 25-30 хотелок наших бодишопов и админов.
А на критическую инфраструктуру, где зарплаты реально хороши (типа американской госухи), никто аутсорса и на пушечный выстрел не подпустит.
На местном же рынки жизни нет. Сейчас для реально хорошего админа даже штука за счастье.
Вот и бегут в девы все кому не лень. Не от хорошей жизни.
Теоретически, работая в бодишопе и на саппорте буржуев. На практике же буржуи влегкую нанимают на такие должности смуглых братьев
В плане «смуглых братьев» есть разница между дэвами и саппортом?
Смуглые братья не хотят быть дэвами?
В плане «смуглых братьев» есть разница между дэвами и саппортом?
Видимо дело в том (это мое мнение), что в разработке нет карго-культа сертификатов вендоров сотоварищи и сито реальных интервью украинцы проходят значительно лучше.
В администрировании-поддержке же кандидат, предьявивший ворох дипломов от МС-Циско-Оракл-етц. по умолчанию считается скиловым, невзирая на повальное брейндампанье и прочие читерства большинства из них в тропических (да и не только, чего уж греха таить) широтах.
Ну а без реальной оценки скила смуглые братья сильно выигрывают по цене и взаимозаменяимости (могут поменять за день на такого же следующего, в отличие от).

Смотря какой саппорт и в какой организации.
Вектор развития у саппорта только один — Админ.
Если цель дорасти до админа ( и в организации есть такая возможность ) - из поддержки наверное самый оптимальный вариант пробиться.
Если же админом вы себя не видите тогда это работа так сказать «в никуда» + возможное проф. выгорание.

Вообще не вижу каким образом саппорт развивается в админа. Как по мне более логичное развитие что-то менеджерское, т.к. прокачивается бизнесс английский и скиллы общения с клиентами.

Вектор развития у саппорта:

Менеджмент (а менеджмент поддержки это гораздо ближе к менеджменту, чем менеджмент девов, потому что менеджер девов работает с шелезяками, а менеджер саппорта работает с клиентами)
Внедрение софта, если хватило ума саппортить именно корп софт, а не винду
QA
DEV
Support 2-3-4 уровня

Как видим, вариантов масса.

То вы не видели корпоративные инфраструктуры на винде. Или вы думаете админить Винду это из разряда поменять раскладку и поднять упавший explorer ?

Что там и где админить не моё дело, я последний раз с виндой работал лет десять назад и админил сетку из 50 компов, колл центр IP и т.д. После этого я винды не видел, более того, гуляя по всяким walmart/staples/bofa и иже с ними, я вижу, что сидят они далеко не на винде. Да и в мои времена виндовым админам платили меньше, чем юниксойдам. И щас я в консоли сижу, а не в винде, и за консоль эту платят мне $$$.

Менеджмент
Надо будет выжить своего текущего начальника? ))
QA
DEV
В этом и вопрос. Стоит ли переходить в эти направления?
Support 2-3-4 уровня
Ну да, я уже давно саппорт не 1го уровня

Сам для себя реши. Если тебе нравится DEV/QA — то стоит, если нравится саппорт, то не стоит. Мне нравится саппорт и я 10 лет саппортом занимаюсь и мне это нравится. И с клиентами общаешься, и с разработчиками, и самому поковырять можно и софт, и базы и всё что угодно. И платят прилично. Сейчас занимаюсь больше менеджментом, и всё равно тянет ковырять что-то, слава Богу возможность есть. Мозги работают, деньги платят, что ещё надо? Главное развивайся как саппорт, а не превращайся в махеша хавкенайхелпю, который при любом вопросе эскалирует заявку.

А что вы делаете в менеджменте? Точнее, что там нового для вас?

Саппорт вроде нормально оплачивается
Але менше, “чем должности тестера или программиста”.
Также, это хорошая работа для поддержания высокого уровня английского
Не всі працюють в англомовній підтримці.

Тренд всюди один і той самий, у нас теж багато людей попереходило — в тестування, ПМи, продажі.
Перспектив мало, кар’єрний ріст тяжчий в порівняні з технічними, мінусів купа, а плюсів майже не бачу.

Кто-то смотрит спорт по телевизору, кто-то сам бегает по утрам и ходит в спортзал. То же самое и с сапортом/программистами — каждому свое.

Не совсем корректное сравнение :) Если из мира спорта, я бы сказал про спортсменов и судей/комментаторов.

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