Os engenheiros de software também devem atuar como suporte técnico? [fechadas]

Esta é uma questão clássica em empresas que têm um componente de desenvolvimento de software em seu trabalho, sejam empresas de software ou não. Eu luto com isso o tempo todo.

Tendo desenvolvedores envolvidos no suporte à produção

Prós

• Combate síndrome de "desenvolvimento no vácuo" . É valioso ganhar exposição sobre como os usuários usam o aplicativo. Até que eu finalmente vi isso como um desenvolvedor jovem, eu não sabia que desenvolvedor de UI ruim eu era. Tudo o que eu me importava era codificar e não design, análise ou a perspectiva do usuário.
• Os desenvolvedores que não são tão bons quanto eles acham que podem ser humilhados (embora não haja garantia de que você obterá esse benefício; alguns desenvolvedores são realmente alheios, egoístas e teimosos).
• Os desenvolvedores ganharão conhecimento de domínio . Isso é fundamental para que seus desenvolvedores se tornem, eventualmente, melhores em identificar e preencher as lacunas da fase de análise de negócios (supondo que haja alguma).
• Bom apoio é um ponto de marketing. Se você fizer isso bem, os clientes vão gostar disso. E um desenvolvedor completo com habilidades de comunicação e conhecimento de domínio é capaz de fazer isso bem. No entanto, eu ainda preferiria que os aplicativos fossem de qualidade alta o suficiente para não precisarem de suporte. Qualidade superior é a sua própria forma de suporte ao cliente (e também um ponto de marketing).

Contras

• Fator de interrupção . Esta é a falha número um de misturar o trabalho de projeto e o trabalho de suporte, mas nenhum. Os projetos interferem no suporte e o suporte interfere nos projetos. Os projetos dependem de estimativas e progresso, o apoio é imprevisível e pode envolver urgência improvisada. Os projetos são baseados em cronograma e o suporte é baseado em interrupção. Não é uma combinação feliz e muito frustrante para os desenvolvedores lidarem.
• Nem todo mundo é bom em suporte . Alguém que tenha menos experiência com o aplicativo ou empresa, ou alguém cuja personalidade ou habilidades de comunicação sejam de tal forma protegidas contra o acesso do usuário, pode não funcionar bem no suporte.
• Uso ineficiente de recursos . Frank Shearar observou nos comentários que um desenvolvedor que faz um suporte trivial pode ser mais caro do que uma tecnologia de suporte de nível um.

Na minha experiência, a maioria dos desenvolvedores não gosta de suporte. Tendo servido tanto no projeto quanto no apoio, posso simpatizar. Ao ter que fazer as duas coisas ao mesmo tempo, o fator atenuante é, muitas vezes, horas extras, geralmente não pagas, para lidar com emergências de suporte e ainda fazer os prazos do projeto. Os gerentes de projeto adoram horas extras não pagas porque isso significa fazer datas sem custar mais dinheiro, mas para os desenvolvedores, é apenas uma grande tigela de sucção.

No entanto, também acredito que, se os desenvolvedores fizessem um trabalho melhor criando sistemas confiáveis e intuitivos, teriam menos suporte. Então isso cria um estranho argumento circular para misturar os dois. O que eu acho que você deveria fazer se tiver que fazer as duas coisas é encontrar maneiras de evitar que isso seja simultâneo.

Eu acho que os desenvolvedores já usam dois chapéus. O suporte é mais como um filtro usado para proteger o desenvolvimento de problemas triviais, como não ter o computador conectado. No entanto, deve haver um strong acoplamento entre desenvolvimento e suporte. Alguns clientes têm problemas legítimos que talvez resultem de um bug. Deve ser responsabilidade do desenvolvimento ajudar a resolver esses problemas o quanto antes. Então, de certo modo, os desenvolvedores já fazem parte da equipe de suporte ... chame isso de suporte de camada 2.

Enfaticamente, não.
Nós todos sabemos o quão difícil pode ser ter que parar o que você está fazendo para pedir responder a uma pergunta. Eu atendo telefones para um help desk e escrevo alguns aplicativos utilitários.

Eu não posso me concentrar em resolver um problema porque a cada 5 minutos estou tendo que atender o telefone. Nenhum trabalho é feito tão bem quanto pode ser porque eu estou constantemente pensando sobre o que posso fazer para resolver um problema, e nunca estou trabalhando na programação por tempo suficiente para implementar completamente qualquer solução que eu possa ter.

Mais uma vez, eu não pude enfatizar o suficiente o quão importante é ser capaz de se concentrar em um aspecto ou outro.

Eu nunca colocaria um desenvolvedor como suporte de primeira linha. O número de interrupções e o valor que você terá que repetir-se farão com que a maioria dos desenvolvedores clamem RTFM e desliguem no próximo pessoa que chama. Isso não é algo que seus clientes precisam, nem é algo que você quer que seus desenvolvedores tenham que suportar.

Existe uma certa regra em qualquer cargo de atendimento ao cliente. Para uma pessoa irritada, a primeira pessoa que atende o telefone está errada. Quer tenham o presidente da empresa, a pessoa que desenvolveu o aplicativo ou o gerente de suporte, isso não importa. Quando o cliente recebe a segunda pessoa, que pode ou não saber o que está fazendo, o cliente será capaz de se acalmar e explicar o problema com mais clareza.

Este não é um ambiente que você deseja manter bons desenvolvedores. Existe valor em ter um desenvolvedor interagindo com um cliente em um problema particularmente difícil que vai além de "por que meu porta-copos não funciona mais"? Absolutamente. Mas isso após o pedido de suporte ter sido verificado nas linhas de suporte da primeira e da segunda linhas.

Depende da empresa.

Meu trabalho é exatamente assim . Sou desenvolvedor de software, mas como somos uma empresa relativamente pequena, cada desenvolvedor assume um papel de suporte "não oficial", geralmente baseado em seu próprio software. Alguns desenvolvedores precisam fazer mais suporte do que outros, dependendo de vários fatores, como quantos produtos eles desenvolveram / enviaram, como seus produtos são enganados e como eles são eficazes no suporte . Se você puder fornecer ao cliente exatamente o que ele precisa para resolver o problema, ele continuará voltando para você para resolver os problemas o mais rápido possível. Espada de dois gumes? Sim. Você sofre de produtividade reduzida, mas o cliente está feliz e tem mais chances de continuar sendo um cliente. Isso é importante para empresas menores.

Temos uma equipe de suporte de sistemas, mas devido à natureza do que fazemos, eles geralmente precisam lidar com problemas relacionados a hardware. Pessoalmente, em uma empresa menor, essa questão não é tão perturbadora quanto se imagina. Claro, você recebe chamadas enquanto está tentando desenvolver algum recurso importante, mas, ao mesmo tempo, o serviço ao cliente é muito melhor; eles podem ter uma voz autoritária que sabe (em muitos casos) como resolver seu problema em vez de alguém com informações de segunda mão e um script de suporte. Se você não conseguir resolver o problema de vez em quando, pode tranquilizá-los pessoalmente para que você implemente uma correção para o bug deles, ou considere sua solicitação de recurso para uma versão futura. Você pode obter um feedback real direto dos usuários do seu software, para que sua próxima versão seja ainda melhor do que você já pensa.

Eu gosto de pensar que clientes satisfeitos criam uma imagem mais positiva de sua empresa, o que geralmente leva a mais clientes . E é por isso que, como engenheiro de software, gosto de suporte técnico.

Não há nada mais frustrante do que o suporte técnico de informática que não esteja disposto a ligar-se a alguém que realmente entenda o que está acontecendo. Espero que qualquer grande empresa de aplicativos tenha alguns programadores que trabalhem em suporte técnico.

Os desenvolvedores devem ser a última linha de suporte.

Somente quando o helpdesk e nosso departamento de QA não puderem ajudar um cliente, seremos incomodados. E, mesmo assim, ele tem que passar pelo nosso sistema prioritário de rastreamento de bugs.

Se for um problema realmente grande, ouviremos isso.

Meu último trabalho foi exatamente isso. Apoiamos os sistemas existentes e também criamos novos, conforme necessário. Foi um desastre total. Eu seria constantemente interrompido. Minha moral estava tão baixa porque os projetos começados levariam uma eternidade para terminar. Além disso, tivemos que carregar um pager para o suporte de horas de folga sem pagamento extra (isso foi no campo da saúde). Eu acho que a solução (que eu sugeri ao meu gerente na época), teria sido ter uma linha de frente de suporte técnico, e se for um bug de software, encaminhe para os desenvolvedores. Escusado será dizer que durou apenas um ano e meio até que finalmente saí para um melhor trabalho de desenvolvimento!

Algumas vezes, definitivamente sim. Enfrentar o cliente muitas vezes dá uma perspectiva que a maioria das pessoas, especialmente os programadores, não tem. Como o usuário realmente usa o produto, ou realmente acha que é frequentemente muito diferente de como o construtor (o engenheiro) pensa que ele faz.

Deve ser para períodos curtos periódicos, de modo a não interromper a tarefa real de desenvolvimento.

Existem talentos e habilidades que você precisa para desenvolver software e talentos e habilidades que você precisa para ser eficaz no suporte de primeira linha. Eu não sei se esses talentos têm alguma correlação.

Isso significa que você precisa contratar desenvolvedores com base, em parte, em sua capacidade de fazer suporte por telefone ou de permitir que seus clientes conversem diretamente com pessoas que não são boas em lidar com clientes e não querem fazer isso. primeiro lugar. Isso pode ou não ser melhor do que conversar com um cara com um strong sotaque indiano que lê um roteiro educado.

Além disso, quando você torna o trabalho desagradável (e eu não conheço desenvolvedores que realmente gostem de suporte de primeira linha), alguns de seus desenvolvedores irão embora. Estes são geralmente aqueles que conseguem outros trabalhos mais facilmente: isto é, os bons. À medida que esse processo avança, você acaba com uma loja cheia de pessoas menos talentosas, o que torna ainda menos agradável para os competentes passarem a primeira oferta de emprego de outra pessoa.

No que diz respeito a obter um desenvolvimento sério, esqueça-o se houver interrupções frequentes. Minha esposa reclamou muito sobre o desenvolvimento esperado e o suporte a usuários simultaneamente.

Eu só faria isso se fosse um desenvolvedor novo ou não familiarizado com o domínio e a base de clientes. Tornar isso uma coisa permanente não é uma boa ideia.

Eu acho que muito disso depende da empresa. Sua típica empresa BigCo geralmente pode se dar ao luxo de ter pessoas de suporte para isolar os desenvolvedores. Por outro lado, uma startup com três pessoas total simplesmente pode não ter recursos para fornecer suporte separado às pessoas.

Acho que a melhor estratégia geral (sem levar em conta o tamanho da empresa ou recursos) é usar as equipes de suporte para solucionar problemas relacionados aos produtos e aos problemas mais comuns ("Você tentou desligá-los e ligá-los?"). Os engenheiros devem trabalhar com os clientes nos problemas mais complicados que exigem conhecimento de como o sistema funciona, além de mais suporte orientado ao desenvolvedor (APIs, ferramentas para desenvolvedores, etc.). Você poderia ter a pessoa de apoio agindo como uma "ligação", mas eu acho que geralmente é mais problema do que vale a pena.

Embora não seja apropriado usar devs como suporte all , acho que há algo a ser dito para que um desenvolvedor faça o suporte inicial de um aplicativo. Isso deve incluir especificamente o suporte após o expediente. Eu também acho que pode ser útil para que eles sejam agendados para o suporte depois de horas para seus aplicativos em uma base regular.

Não há nada como várias chamadas 3AM para fazer com que você perceba o efeito que certas decisões de design e / ou atalhos têm na capacidade de as pessoas darem suporte e manterem seu código.

O ideal é que não pelos motivos citados acima, mas sim enquanto o projeto é incipiente, porque os desenvolvedores podem fornecer resoluções rápidas, geralmente esperadas pelas empresas, que dão suporte à melhoria contínua do software. Eu valorizo os desenvolvedores que fornecem suporte de forma inteligente: aqueles que emprestam suas habilidades analíticas por exemplo a uma equipe de suporte em tempo integral mais formal e aqueles que respondem ao negócio de forma a mostrar um espírito de serviço e cooperação. As chaves para esse sucesso, no entanto, incluem o gerenciamento reconhecendo e formalizando o suporte de primeiro e segundo nível para descarregar rapidamente os desenvolvedores do que deveria ser apenas sua função de curto prazo. Desenvolvedores que demonstrem habilidade para desenvolvimento e suporte devem ser cultivados como suporte de terceiro nível ou suporte para o pessoal de suporte. Portanto, deve depender do tempo, do talento e do desejo, e ser gerenciado de maneira eficaz.

O meu próprio interesse tem sido responder às difíceis questões de suporte e aproveitar o que aprendi com a experiência para reduzir a necessidade de suporte geral, o que beneficia tanto os usuários finais quanto o suporte primário.

Eu entrei nessa armadilha quando entrei para uma empresa com bons salários. Durante a entrevista me disseram que haveria 70% de desenvolvimento e 30% de apoio e eu aceitei a oferta. Pode ser a empresa ou o ambiente em que estou trabalhando atualmente. Mas na verdade suporta 90% e 10% de desenvolvimento. Já faz alguns anos que perdi o controle do desenvolvimento. Lamento ter aceitado esta oferta.

Mas eu sinto que perdi o controle de programar mais muitas novas tecnologias e frameworks. Agora não sei por onde começar de novo. Continuo me preparando, mas esses exemplos de helloworld não são suficientes para ter uma boa experiência prática e está realmente ficando difícil atualizar meu conhecimento e experiência. Eu nem posso deixar meu trabalho para começar de novo por causa dos compromissos familiares.

Infelizmente, estou em um impasse.

Por favor, não aceite papéis se você não gosta ou não está interessado em.

Contras - supondo que você tenha que lidar diretamente com os clientes.

1) Estragando seus clientes

Se for o suporte de primeira / segunda / terceira linha (eu realmente quero dizer suporte de linha borrada) onde os desenvolvedores lidam diretamente com os clientes, então é um grande engodo. Os desenvolvedores têm o conjunto de habilidades necessário para depurar problemas ou desenvolver soluções para resolver problemas. Se os clientes tiverem acesso completo aos desenvolvedores (linha borrada) - não há como impedir que os clientes "abusem" desse privilégio - resultando em clientes estragados, exigentes e privilegiados que não pagam mais do que qualquer outro cliente.

2) Condicionando seus desenvolvedores a mentir e inventar histórias.

Qualquer pessoa que tenha lidado com clientes sabe que é um pré-requisito poder mentir para eles. Há um bug com uma correção de 1 linha que pode ser feita em 5 minutos. Uma pessoa de suporte ao cliente teria sido treinada para gerenciar as expectativas do cliente - que levaria até 3 dias para resolvê-lo.

Como desenvolvedor, se você tiver que lidar diretamente com os clientes, precisará pensar em maneiras criativas de apaziguar ou enganar os clientes quando seu trabalho principal for resolver problemas técnicos e garantir que o sistema esteja funcionando sem problemas.

3) Seu Curriculum Vitae Sofre.

A menos que você esteja mudando de engenheiro de software para analista de negócios / consultor de TI / gerenciamento de projetos, seu currículo sofrerá com um aspecto técnico.

O trabalho de suporte pago que gira entre a equipe é uma história diferente.

Prós

1) Pare de chorões de choramingar

Desenvolvedores que fazem o que odeiam farão com que eles apreciem muito mais a codificação. Tem um programador que está constantemente choramingando? Coloque-os na linha direta por um mês.

Sim, porque eles fazem. Eu lol'd quando eu li essa pergunta? Eu estava tipo como isso é mesmo uma questão (não que eu esteja questionando seu direito de fazer a pergunta OP), mas é bastante retórico porque quase todo Dev que eu já conheci teve algum tipo de trabalho de suporte técnico implícito dentro dele ou sua função de trabalho. Você simplesmente não pode evitá-lo. Na maioria dos casos, você é a pessoa mais tecnicamente competitiva, não apenas no seu domínio funcional, mas em termos de TI em geral. É muito difícil evitar completamente.