Мы находим относительно легко нанять разработчиков для работы над различными проектами.
Проблема возникает, когда проект завершен, но все еще нуждается в поддержке.
Мы действительно боремся за то, чтобы люди присоединились к команде поддержки. Это рассматривается как тупик, ограничение карьеры, скучно, второй класс и т. Д.
В настоящее время мы справляемся с этим, заставляя команду проекта назначать часть своей команды в службу поддержки на некоторое время. Часть задания состоит в том, чтобы выполнить «мозговой сброс» проекта, чтобы команда поддержки поняла его. Это работает до тех пор, пока назначение только на фиксированный период.
Попытка нанять людей для работы на полную ставку - проблема. Приложений мало, а калибр не особо высокий.
(Однако финансовая реальность такова, что поддержка может быть очень прибыльной для компании, и как только вы получите репутацию, другие компании обращаются к вам за помощью, даже если вы не участвовали в первоначальной разработке.)
Ответы:
не
Для меня лучший вариант здесь не разделять разработчиков на поддержку и не поддержку в первую очередь. ИМХО есть три основные причины:
В команде разработчиков вы можете иметь людей, у которых есть задачи по обслуживанию, или подходить к тому, чтобы задачи по обслуживанию были тренировочными площадками для новых членов команды, но если вы попытаетесь продать его в качестве долгосрочной цели позиции, вы будете привлекать только люди, у которых изжога, или люди, которые скоро уйдут.
Всегда должен быть четкий путь для выхода из роли разработчика на 100% поддержки и / или определенного процента новых разработок, чтобы заинтересовать хороших людей.
Вы не хотите привлекать людей, которые счастливы в этой роли на неопределенный срок, и вы никогда не будете убеждать хороших разработчиков взять эту роль и сохранить ее на долгое время, если вы не предлагаете такую плату, которая никогда не заставит их задуматься карьерный ход.
источник
Я люблю делать поддержку по следующим причинам:
Это всего лишь несколько причин.
Что касается самой поддержки, я предлагаю реализовать простой в управлении процесс.
Когда мы получаем поддержку, мы делаем следующее:
источник
Почему бы просто не заплатить разработчикам поддержки на 5 или 10 тысяч больше, чем сборка, и забыть разработчиков?
Добавив дополнительную премию к ролям поддержки; в знак признания дополнительных проблем, связанных с «обманом клиентов» и «обслуживанием производственного кода»; Вы не только обеспечите дополнительную мотивацию, но, что более важно, роли будут выглядеть более престижными. В конце концов, более высокая зарплата должна означать более важную роль, и даже если это не так, она будет воспринята таким образом.
источник
Если вы считаете, что поддержка - это второстепенная работа, у вас, вероятно, возникнут проблемы с наймом людей. Если вы рассматриваете это как ограничивающую карьеру и тупиковую работу, вы не получите хороших соискателей.
Поддержка, как правило, не так интересна, как новая разработка, и если у вас есть отдельные группы разработчиков и поддержки, группы поддержки должны принять то, что дает им разработка, что часто не весело. (Однажды я работал в одном месте, где R & D передавали нам какое-то программное обеспечение, которое делало что-то классное, но, как правило, требовало редизайна для обеспечения качества производства, и у нас не было достаточно времени для этого по политическим причинам. веселье.)
Если поддержка действительно важна для бизнеса, вы должны относиться к ней как к таковой. Если вы настаиваете на наличии отдельных групп поддержки, и важно иметь хорошие команды, вам необходимо решить эти проблемы. Удостоверьтесь, что есть путь карьеры. Публикуйте деньги, которые вы зарабатываете на поддержке, отчасти для их самооценки, отчасти для того, чтобы другие люди осознали свою ценность, отчасти для того, чтобы они могли размещать цифры долларов за свою деятельность в своих резюме. Установите стандарты и дайте командам поддержки некоторую информацию о том, готов ли проект перейти от разработки к поддержке. Поскольку работа менее увлекательна и, возможно, важнее, платите им больше. (Я бы больше сочувствовал менеджерам, которые жалуются, что «мы не можем получить нужных нам кандидатов», если это обычно не переводится как «мы не можем заявителям, нам нужны дешевые».)
источник
Хотя я согласен с тем, что поддержка, как правило, отстой, многие разработчики могут на самом деле пользоваться престижем, который сопутствует «владению» проектом, даже если они сами не пишут программное обеспечение. Этот программист становится участником этого проекта, и они действительно становятся бесценным экспертом по системе. Хотя я в основном занимаюсь новыми разработками в компании, в которой я работаю, многие из моих коллег, которые более чем компетентны, на самом деле весьма уважаются за поддержку нашего самого критически важного программного обеспечения. В конце концов, поддерживаемое в настоящее время программное обеспечение, вероятно, в настоящее время зарабатывает деньги (птица в руке стоит двух в кустах).
Я бы просто сказал, что не все считают поддержку ужасной работой в подземельях для программистов, не соответствующих стандартам, и я бы проигнорировал это чувство, чтобы привлечь больше людей.
источник
Несколько мыслей:
1) Вы говорите, что это рассматривается как тупик и ограничение карьеры. Если это не так, и люди занялись другими делами (разработка, управление проектами, управление командой), то я уверен, что у вас есть примеры, которые вы можете использовать. Если у вас нет примеров, вам, возможно, придется признать, что это тупик и ограничить карьеру, и вам необходимо решить эти проблемы.
2a) Если поддержка включает исправление ошибок, то почему они раздельные? Если кто-то плохо закодировал это для начала, то чему вы их учите, передавая их беспорядок кому-то другому, чтобы разобраться. Более того, если разработчики поддержки не так хороши, как разработчики, как, черт возьми, можно ожидать, что они исправят то, что разработчики не могли сделать правильно? Серьезно, правило должно быть, вы написали это, вы исправите это.
2b) Если поддержка не включает исправление ошибок, то они очень разные работы и подчеркивают разные навыки. Вам не следует беспокоиться о переходе здесь больше, чем о переходе между разработкой и очисткой.
3) Вы говорите, что это выгодно для компании, а затем делаете это выгодным для вовлеченных людей. Это может быть за счет лучших денег, лучшей подготовки, лучшего снаряжения и предоставления им всего, что им нужно для того, чтобы сделать это действительно очень хорошо. Если есть свободные деньги, сделайте это отличной работой.
При чтении вашего поста проблема заключается в том, что вы, похоже, не верите, что это хорошая работа. Если это правда, то неудивительно, что вы не можете продать его как единое целое.
источник
Поддержка - трудная работа, никто не любит слушать, что люди жалуются весь день. Поиск хороших людей может занять некоторое время, но как только вы это сделаете, вам нужно
источник
Я думаю, что zappos.com показал, что работа в хорошей компании не должна быть глупой. Худшая часть поддержки - это невозможность помочь кому-то. Если вы запутали пользователей с помощью мелкого шрифта контракта на обслуживание или поставили программное обеспечение с ошибками, которое не будет исправлено в ближайшее время, поддержка будет отстойной. Их необходимо поощрять к поиску решений проблем; вроде как программирование.
источник
Я пару лет поддерживал мою первую компанию после колледжа. Что заставило меня зарегистрироваться на пару лет было:
источник
Как насчет смеси развития и поддержки (разделение ролей)? Я думаю, вы по-прежнему будете бороться за получение бай-ина за это по уже упомянутым причинам (разработчики! = Люди, отвечающие за поддержку продукта). Но если ваш продукт опирается на широкое понимание внутренних технологий, может быть, 80% разработки, 20% поддержки будет справедливым компромиссом. Или какое-то наставничество / слежка за новыми сотрудниками, чтобы гарантировать, что они получают правильную информацию о продукте.
источник