Как вам «продать» поддержку как вариант карьеры [закрыто]

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

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

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

В настоящее время мы справляемся с этим, заставляя команду проекта назначать часть своей команды в службу поддержки на некоторое время. Часть задания состоит в том, чтобы выполнить «мозговой сброс» проекта, чтобы команда поддержки поняла его. Это работает до тех пор, пока назначение только на фиксированный период.

Попытка нанять людей для работы на полную ставку - проблема. Приложений мало, а калибр не особо высокий.

(Однако финансовая реальность такова, что поддержка может быть очень прибыльной для компании, и как только вы получите репутацию, другие компании обращаются к вам за помощью, даже если вы не участвовали в первоначальной разработке.)

не

Для меня лучший вариант здесь не разделять разработчиков на поддержку и не поддержку в первую очередь. ИМХО есть три основные причины:

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

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

Всегда должен быть четкий путь для выхода из роли разработчика на 100% поддержки и / или определенного процента новых разработок, чтобы заинтересовать хороших людей.

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

Сделайте работу поддержки интересной и полезной для ваших разработчиков.

Я люблю делать поддержку по следующим причинам:

• Я общаюсь с людьми по всему миру. У меня появилось много таких друзей . Несколько лет назад один из моих клиентов пригласил меня на свою свадьбу! Раньше у меня в офисе была карта мира с булавками, на которых они были расположены.
• Поддержка чуть ли не лучшая, получайте вознаграждения за вашу работу. Когда вы делаете пользователей счастливыми, это действительно делает вас счастливее.
• Жалобы являются полезным способом улучшить себя. Я серьезно отношусь к любой жалобе, и в большинстве случаев я могу превратить злого человека в счастливого клиента / пользователя, который в конечном итоге распространит информацию.
• Это помогает мне понять, что нужно клиентам / пользователям. Тогда я смогу создать лучшее программное обеспечение.

Это всего лишь несколько причин.

Что касается самой поддержки, я предлагаю реализовать простой в управлении процесс.

Когда мы получаем поддержку, мы делаем следующее:

• Если это воспроизводимая ошибка, мы добавляем ее в очередь и указываем ее идентификатор клиенту / пользователю. Мы также берем идентификатор клиента / пользователя, чтобы уведомить его о принятых решениях и выпустить персонально. Это легко, если вы соберете его электронную почту напрямую.
• Если это проблема с использованием программного обеспечения, мы используем это как возможность улучшить документацию. Любой ответ пишется как статья базы знаний, которую мы добавляем в нашу базу данных впоследствии. Написание письма занимает в три раза больше времени, но мы не повторяем его позже (большинство пользователей предпочитают просматривать в КБ).
• Если это запрос функции, мы напрямую связываем пользователя с владельцем продукта. Это очень ценно. Конечно, мы используем такие системы, как uservoice.com, но гораздо лучше общаться с пользователем напрямую.
• Если это жалоба, мы пытаемся решить ее вне процесса. Людей, которые жалуются, любят считать важными (даже если жалоба тривиальна).

Почему бы просто не заплатить разработчикам поддержки на 5 или 10 тысяч больше, чем сборка, и забыть разработчиков?

Добавив дополнительную премию к ролям поддержки; в знак признания дополнительных проблем, связанных с «обманом клиентов» и «обслуживанием производственного кода»; Вы не только обеспечите дополнительную мотивацию, но, что более важно, роли будут выглядеть более престижными. В конце концов, более высокая зарплата должна означать более важную роль, и даже если это не так, она будет воспринята таким образом.

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

Поддержка, как правило, не так интересна, как новая разработка, и если у вас есть отдельные группы разработчиков и поддержки, группы поддержки должны принять то, что дает им разработка, что часто не весело. (Однажды я работал в одном месте, где R & D передавали нам какое-то программное обеспечение, которое делало что-то классное, но, как правило, требовало редизайна для обеспечения качества производства, и у нас не было достаточно времени для этого по политическим причинам. веселье.)

Если поддержка действительно важна для бизнеса, вы должны относиться к ней как к таковой. Если вы настаиваете на наличии отдельных групп поддержки, и важно иметь хорошие команды, вам необходимо решить эти проблемы. Удостоверьтесь, что есть путь карьеры. Публикуйте деньги, которые вы зарабатываете на поддержке, отчасти для их самооценки, отчасти для того, чтобы другие люди осознали свою ценность, отчасти для того, чтобы они могли размещать цифры долларов за свою деятельность в своих резюме. Установите стандарты и дайте командам поддержки некоторую информацию о том, готов ли проект перейти от разработки к поддержке. Поскольку работа менее увлекательна и, возможно, важнее, платите им больше. (Я бы больше сочувствовал менеджерам, которые жалуются, что «мы не можем получить нужных нам кандидатов», если это обычно не переводится как «мы не можем заявителям, нам нужны дешевые».)

Хотя я согласен с тем, что поддержка, как правило, отстой, многие разработчики могут на самом деле пользоваться престижем, который сопутствует «владению» проектом, даже если они сами не пишут программное обеспечение. Этот программист становится участником этого проекта, и они действительно становятся бесценным экспертом по системе. Хотя я в основном занимаюсь новыми разработками в компании, в которой я работаю, многие из моих коллег, которые более чем компетентны, на самом деле весьма уважаются за поддержку нашего самого критически важного программного обеспечения. В конце концов, поддерживаемое в настоящее время программное обеспечение, вероятно, в настоящее время зарабатывает деньги (птица в руке стоит двух в кустах).
Я бы просто сказал, что не все считают поддержку ужасной работой в подземельях для программистов, не соответствующих стандартам, и я бы проигнорировал это чувство, чтобы привлечь больше людей.

Несколько мыслей:

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

2a) Если поддержка включает исправление ошибок, то почему они раздельные? Если кто-то плохо закодировал это для начала, то чему вы их учите, передавая их беспорядок кому-то другому, чтобы разобраться. Более того, если разработчики поддержки не так хороши, как разработчики, как, черт возьми, можно ожидать, что они исправят то, что разработчики не могли сделать правильно? Серьезно, правило должно быть, вы написали это, вы исправите это.

2b) Если поддержка не включает исправление ошибок, то они очень разные работы и подчеркивают разные навыки. Вам не следует беспокоиться о переходе здесь больше, чем о переходе между разработкой и очисткой.

3) Вы говорите, что это выгодно для компании, а затем делаете это выгодным для вовлеченных людей. Это может быть за счет лучших денег, лучшей подготовки, лучшего снаряжения и предоставления им всего, что им нужно для того, чтобы сделать это действительно очень хорошо. Если есть свободные деньги, сделайте это отличной работой.

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

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

1. Платите хорошие деньги, даже намного выше отраслевых ставок, чтобы держать хороших людей
2. Обеспечить хорошую рабочую обстановку, такие мелочи, как работа, обед, напитки и помощь
3. Не забивайте весь свой вспомогательный персонал в маленькую шумную комнату

Я думаю, что zappos.com показал, что работа в хорошей компании не должна быть глупой. Худшая часть поддержки - это невозможность помочь кому-то. Если вы запутали пользователей с помощью мелкого шрифта контракта на обслуживание или поставили программное обеспечение с ошибками, которое не будет исправлено в ближайшее время, поддержка будет отстойной. Их необходимо поощрять к поиску решений проблем; вроде как программирование.

Я пару лет поддерживал мою первую компанию после колледжа. Что заставило меня зарегистрироваться на пару лет было:

1. Требуемая карьера для того, чтобы стать инженером программного обеспечения.
2. Мне нужно было время, чтобы освежить основной язык компании (Фортран, около 1989)
3. Я не был женат, поэтому я мог уйти, если бы обнаружил, что мне не нравится компания или работа.

Как насчет смеси развития и поддержки (разделение ролей)? Я думаю, вы по-прежнему будете бороться за получение бай-ина за это по уже упомянутым причинам (разработчики! = Люди, отвечающие за поддержку продукта). Но если ваш продукт опирается на широкое понимание внутренних технологий, может быть, 80% разработки, 20% поддержки будет справедливым компромиссом. Или какое-то наставничество / слежка за новыми сотрудниками, чтобы гарантировать, что они получают правильную информацию о продукте.