Como você "vende" o suporte como uma opção de carreira [fechado]

Achamos relativamente fácil contratar desenvolvedores para trabalhar em vários projetos.

O problema surge quando o projeto é concluído, mas ainda precisa ser suportado.

Realmente lutamos para que as pessoas participem da equipe de suporte. É visto como beco sem saída, limitador de carreira, chato, de segunda classe etc.

Atualmente, contornamos isso fazendo com que a equipe do projeto atribua parte de sua equipe à equipe de suporte por um tempo. Parte da tarefa é fazer um "despejo cerebral" do projeto para que a equipe de suporte o entenda. Isso funciona desde que a atribuição seja apenas por um período fixo.

Tentar contratar pessoas para trabalhar em suporte em período integral é um problema. Existem poucas aplicações e o calibre não é particularmente alto.

(A realidade financeira, porém, é que o suporte pode ser muito lucrativo para uma empresa e, quando você obtém uma reputação, você é abordado por outras empresas para fazer o suporte, mesmo que não estivesse envolvido no desenvolvimento original.)

Não

Para mim, a melhor opção aqui não é separar os desenvolvedores em suporte e não suporte em primeiro lugar. IMHO, existem três razões principais:

• as pessoas que escrevem coisas difíceis de apoiar não aprendem até que tenham que apoiá-las.
• as pessoas que prestam apenas suporte geralmente seguem o caminho de menor resistência para corrigir um erro, mesmo que isso atrapalhe o trabalho futuro.
• a economia de tempo teórico em manter o cronograma no novo desenvolvimento, tendo os desenvolvedores de suporte separados, é sempre mais do que consumida ao fornecer instruções ou repetir o trabalho.

Dentro da equipe de desenvolvimento, você pode ter pessoas que têm tarefas de manutenção ou adotar uma abordagem para permitir que as tarefas de manutenção sejam o campo de treinamento para os membros mais novos da equipe, mas se você tentar vendê-la como o objetivo a longo prazo da posição, você atrairá apenas pessoas que causam azia ou pessoas que em breve estarão saindo.

Sempre precisa haver um caminho claro para sair de uma função de desenvolvedor de suporte 100% e / ou uma certa porcentagem do trabalho de desenvolvimento para manter boas pessoas interessadas.

Você não deseja atrair o tipo de pessoa que é feliz nessa função indefinidamente e nunca convencerá bons desenvolvedores a assumir essa função e mantê-la a longo prazo, a menos que esteja oferecendo o tipo de pagamento que nunca os consideraria uma mudança de carreira.

Torne o trabalho de suporte divertido e valioso para seus desenvolvedores.

Adoro fazer suporte pelos seguintes motivos:

• Eu falo com pessoas de todo o mundo. Fiz muitos amigos assim. Alguns anos atrás, um dos meus clientes me convidou para o casamento dele! Eu costumava ter um mapa do mundo em meu escritório com pinos que os localizavam.
• O suporte é quase o melhor para obter gratificações pelo seu trabalho. Quando você faz os usuários felizes, isso também o torna mais feliz.
• Reclamações são uma maneira útil de melhorar a si mesmo. Levo a sério qualquer reclamação e, na maioria dos casos, posso converter alguém irritado em um cliente / usuário feliz que acabará espalhando a notícia.
• Isso me ajuda a entender o que os clientes / usuários precisam. Então eu posso construir um software melhor.

São apenas algumas razões.

Em relação ao próprio suporte, sugiro implementar um processo fácil de gerenciar.

Quando recebemos um caso de suporte, fazemos o seguinte:

• Se for um bug reproduzível, nós o adicionamos ao backlog e fornecemos seu ID ao cliente / usuário. Também levamos o ID do cliente / usuário para notificá-lo sobre as resoluções e liberar pessoalmente. Isso é fácil se você coletar seu email diretamente.
• Se houver um problema ao usar o software, aproveitamos isso como uma oportunidade para melhorar a documentação. Qualquer resposta é escrita como um artigo da base de conhecimento que adicionamos posteriormente ao nosso banco de dados. O tempo de gravação é triplicado, mas não nos repetimos mais tarde (a maioria dos usuários prefere navegar em KB).
• Se for uma solicitação de recurso, conectamos o usuário diretamente ao proprietário do produto. Isso é muito valioso. É claro que usamos sistemas como uservoice.com, mas conversar diretamente com o usuário é muito melhor.
• Se for uma reclamação, tentamos gerenciar isso fora do processo. Pessoas que reclamam gostam de ser consideradas importantes (mesmo que a reclamação seja trivial).

Por que não pagar apenas aos devs de suporte 5 ou 10k mais que a compilação e esquecer os devs?

Anexando um prêmio extra às funções de suporte; em reconhecimento aos desafios adicionais de "ligação com o cliente" e "manutenção do código de produção"; você não apenas fornecerá motivação extra, mas, mais importante, os papéis serão vistos como tendo mais prestígio. Afinal, um salário mais alto deve significar um papel mais importante e, mesmo que não seja esse o caso, será concedido dessa maneira.

Se você acha que o suporte é um trabalho de segunda categoria, provavelmente terá problemas para contratar pessoas para ele. Se você o tratar como um trabalho de limitação de carreira e beco sem saída, não conseguirá bons candidatos.

O suporte geralmente não é tão divertido quanto o novo desenvolvimento, e se você tiver equipes de desenvolvimento e suporte separadas, as equipes de suporte terão que aceitar o que o desenvolvimento lhes oferece, o que geralmente não é divertido. (Trabalhei em um local em que a P&D nos entregava algum software que fazia algo bacana, mas que geralmente precisava de um novo design para ter qualidade de produção, e não tivemos tempo suficiente para fazer isso, por razões políticas. Diversão.)

Se o suporte realmente for crítico para os negócios, você deve tratá-lo como tal. Se você insistir em ter equipes de suporte separadas, e é importante ter boas, precisará resolver esses problemas. Verifique se há um plano de carreira em andamento. Divulgue o dinheiro que você está ganhando com o apoio, em parte por sua auto-estima, em parte para fazer com que outras pessoas percebam seu valor, em parte para que possam colocar valores em dólares por suas atividades em seus currículos. Estabeleça padrões e permita às equipes de suporte alguma contribuição para saber se um projeto está pronto para ir do desenvolvimento ao suporte. Como o trabalho é menos divertido e possivelmente mais importante, pague-os melhor. (Teria mais simpatia pelos gerentes que reclamam "não podemos obter os candidatos de que precisamos", se não costumam traduzir como "não podemos atender aos candidatos de que precisamos barato".)

Embora eu concorde que o suporte geralmente seja péssimo, muitos desenvolvedores podem realmente desfrutar do prestígio que acompanha a "propriedade" do projeto, mesmo que não tenham escrito o software. Esse programador se torna o vencedor desse projeto e realmente se torna um especialista inestimável no sistema. Embora eu esteja envolvido principalmente em novos desenvolvimentos na empresa em que trabalho, muitos de meus colegas que são mais do que competentes são realmente respeitados pela manutenção do nosso software de missão crítica. Afinal, o software atualmente suportado é provavelmente o que está ganhando dinheiro (um pássaro na mão vale dois no mato).
Eu diria apenas que nem todo mundo vê o apoio como um trabalho de masmorra terrível para programadores sub-par, e eu usaria esse sentimento para atrair mais pessoas.

Algumas reflexões:

1) Você diz que é visto como beco sem saída e limitador de carreira. Se isso não for verdade e as pessoas passaram a outras coisas (desenvolvimento, gerenciamento de projetos, administração da equipe), tenho certeza que você tem exemplos que pode usar. Se você não tiver exemplos, talvez seja necessário aceitar que é um beco sem saída e uma carreira limitada e precisa resolver esses problemas.

2a) Se o suporte inclui correção de bugs, por que eles estão separados? Se alguém codificou mal para começar, então o que você está ensinando a eles, entregando a bagunça a alguém para resolver? Além disso, se os desenvolvedores de suporte não são tão bons quanto os desenvolvedores, como você pode esperar que eles consertem o que os desenvolvedores não conseguiram? Sério, a regra deveria ser que você escreveu, você corrige.

2b) Se o suporte não inclui a correção de bugs, eles são trabalhos muito diferentes e enfatizam habilidades diferentes. Você não deve se preocupar em passar por aqui mais do que em passar entre desenvolvimento e limpeza.

3) Você diz que é lucrativo para a empresa e, em seguida, é lucrativo para as pessoas envolvidas. Isso pode ser por meio de dinheiro melhor, melhor treinamento, melhor kit e fornecer a eles tudo o que eles precisam para fazer essas coisas muito bem. Se houver dinheiro disponível, faça um ótimo trabalho.

O problema de ler sua postagem é que você não acredita que seja um bom trabalho. Se isso for verdade, não é de admirar que você não possa vendê-lo como um.

O apoio é um trabalho difícil, nenhum corpo gosta de ouvir as pessoas reclamarem o dia todo. Encontrar pessoas boas pode levar tempo, mas depois que você tiver, precisará mantê-las

1. Pague um bom dinheiro, mesmo bem acima das taxas do setor para manter boas pessoas
2. Proporcionar um bom ambiente de trabalho, pequenas coisas como almoço e bebidas fornecidos pelo trabalho ajudam
3. Não coloque toda a sua equipe de suporte em uma sala pequena e barulhenta

Acho que o zappos.com mostrou que um trabalho não precisa ser ruim quando você trabalha para uma boa empresa. A pior parte de apoiar é não poder ajudar alguém. Se você estragou os usuários com o contrato de serviço de impressão fina ou o software de buggy enviado que não será corrigido tão cedo, o suporte será péssimo. Eles precisam ser incentivados a encontrar soluções para os problemas; tipo de programação.

Apoiei por alguns anos minha primeira empresa fora da faculdade. O que me levou a me inscrever por alguns anos foi:

1. A carreira necessária para se tornar um engenheiro de software.
2. Eu precisava de tempo para atualizar o idioma principal da empresa (Fortran, circa 1989)
3. Eu não era casado, então poderia sair se descobrisse que não gostava da empresa ou do trabalho.

Que tal uma mistura de desenvolvimento e suporte (papéis divididos)? Acho que você ainda lutará para conseguir adesão por causa dos motivos já mencionados (desenvolvedores! = Pessoal de suporte ao produto). Mas se o seu produto se basear em um amplo entendimento da tecnologia interna, talvez 80% de desenvolvimento, 20% de suporte seria uma troca justa. Ou algum tipo de orientação / acompanhamento para novos funcionários para garantir que eles obtenham informações corretas sobre o produto.