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

Um engenheiro de software também deve atuar como suporte técnico? Ou seja, se uma empresa permitir que seus engenheiros usem chapéus de engenheiro de software e de suporte técnico. Parece que isso eliminaria a capacidade de escrever software se grande parte do tempo de um engenheiro fosse ocupada pelo suporte técnico.

Esse é um problema clássico nas empresas que possuem um componente de desenvolvimento de software em seu trabalho, sejam elas empresas de software ou não. Eu luto com isso o tempo todo.

Ter desenvolvedores envolvidos no suporte à produção

Prós

• Combate a síndrome "Desenvolvimento no vácuo" . É valioso ganhar exposição sobre como os usuários usam o aplicativo. Até que finalmente vi isso como um jovem desenvolvedor, não percebi o quanto eu era um desenvolvedor de UI ruim. Tudo o que importava era codificar e não design, análise ou perspectiva do usuário.
• Desenvolvedores que não são tão bons quanto pensam 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 melhores na identificação e preenchimento das lacunas que a fase de análise de negócios (supondo que exista) falha.
• Um bom suporte é um ponto de marketing. Se você fizer isso bem, os clientes apreciarão. 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 suficientemente alta para que não precisassem de suporte. Qualidade superior é sua própria forma de suporte ao cliente (e também um ponto de marketing).

Contras

• Fator de interrupção . Essa é a falha número um da mistura de trabalho de projeto e trabalho de suporte, exceto nenhum. Projetos interferem no suporte, e o suporte interfere nos projetos. Os projetos dependem de estimativas e progressos marcantes, o apoio é imprevisível e pode envolver urgência inesperada. Os projetos são baseados em cronograma, o suporte é baseado em interrupção. Não é uma combinação feliz e muito frustrante para os desenvolvedores.
• Nem todo mundo é bom em apoio . Alguém com menos experiência com o aplicativo ou empresa, ou alguém cujas habilidades de personalidade ou comunicação sejam mais protegidas do 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 oferece suporte trivial pode ser mais caro que um técnico de suporte de nível um.

Na minha experiência, a maioria dos desenvolvedores não gosta de suporte. Tendo atuado nos lados do projeto e do apoio, posso simpatizar. Quando é necessário fazer as duas coisas ao mesmo tempo, o fator atenuante costuma ser horas extras, geralmente não remuneradas, para lidar com emergências de suporte e ainda estabelecer prazos para o projeto. Os gerentes de projeto adoram horas extras não remuneradas porque isso significa marcar datas sem custar mais dinheiro, mas para os desenvolvedores, é apenas uma grande tigela de merda.

No entanto, também acredito que se os desenvolvedores fizessem um trabalho melhor criando sistemas confiáveis ​​e intuitivos, você teria menos suporte. Portanto, isso cria um argumento circular estranho para misturar os dois. O que eu acho que você deve fazer se precisar fazer as duas coisas é encontrar maneiras de evitar torná-lo 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 a falta de conexão do computador. No entanto, deve haver um forte acoplamento entre o desenvolvimento e o 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 mais rápido possível. Então, de certa forma, os desenvolvedores já fazem parte da equipe de suporte ... chame de suporte de camada 2.

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

Não consigo me concentrar em resolver um problema porque a cada 5 minutos tenho que atender o telefone. Nenhum dos trabalhos é realizado da melhor maneira possível, porque estou constantemente pensando no que posso fazer para resolver um problema e nunca estou trabalhando na programação tempo suficiente para implementar totalmente qualquer solução que eu possa ter.

Mais uma vez, não pude enfatizar o suficiente a importância de poder me concentrar em um aspecto ou outro.

Eu nunca colocaria um desenvolvedor como suporte de primeira linha. O número de interrupções e a quantidade que você terá que repetir fará com que a maioria dos desenvolvedores grite RTFM e desligue a próxima pessoa que ligar. Isso não é algo que seus clientes precisam, nem algo que você deseja que seus desenvolvedores tenham que suportar.

Existe uma certa regra em qualquer posição de atendimento ao cliente. Para quem liga, a primeira pessoa que atende o telefone está errada. Se eles têm o presidente da empresa, a pessoa que desenvolveu o aplicativo ou o gerente de suporte, isso não importa. Quando o cliente obtiver a segunda pessoa, que pode ou não saber o que está fazendo, poderá 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 ocorre depois que a solicitação de suporte é examinada pelas linhas de suporte de primeiro e segundo nível.

Depende da empresa.

Meu trabalho é exatamente assim . Sou desenvolvedor de software, mas como somos uma empresa relativamente pequena, cada desenvolvedor assume uma função de suporte "não oficial", geralmente baseada em seu próprio software. Alguns desenvolvedores precisam dar mais suporte do que outros, dependendo de vários fatores, como quantos produtos eles desenvolveram / enviaram, quão problemáticos são seus produtos e qual a eficácia deles no suporte . Se você puder fornecer ao cliente exatamente o que ele precisa para resolver o problema, eles voltarão 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 permanecer como cliente. Isso é importante para empresas menores.

Temos uma equipe de suporte a sistemas, mas, devido à natureza do que fazemos, eles geralmente precisam lidar com problemas relacionados a hardware. Pessoalmente, em uma empresa menor, esse problema não é tão perturbador quanto se pode imaginar. Claro, você recebe chamadas enquanto tenta elaborar algum recurso importante, mas, ao mesmo tempo, o serviço ao clienteestá muito melhorado; eles podem ter uma voz autorizada 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 uma vez por todas, pode tranquilizá-lo pessoalmente de que implementará uma correção para o bug ou considere a solicitação de recurso para uma versão futura. Você pode obter feedback real diretamente dos usuários do seu software, para que sua próxima versão seja ainda melhor do que você já pensa.

Gosto de pensar que clientes satisfeitos criam uma imagem mais positiva da 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 não querer ligar você a alguém que realmente entende o que está acontecendo. Espero que qualquer grande empresa de aplicativos tenha alguns programadores que trabalhem com o suporte técnico.

Os desenvolvedores devem ser a última linha de suporte.

Somente quando o suporte técnico e nosso departamento de controle de qualidade não puderem ajudar um cliente é que seremos incomodados. E mesmo assim, ele precisa passar pelo nosso sistema priorizado de rastreamento de bugs.

Se for realmente um grande problema, nós o ouviremos.

Eu faria isso apenas se for um novo desenvolvedor ou alguém que não esteja familiarizado com o domínio e a base de clientes. Tornar uma coisa permanente não é uma boa ideia.

Meu último trabalho foi exatamente isso. Apoiamos os sistemas existentes e também escrevemos novos, conforme necessário. Foi um desastre total. Eu seria constantemente interrompido. Meu moral estava tão baixo porque os projetos iniciados levariam uma eternidade para terminar. Além disso, tivemos que transportar um pager para suporte fora do horário comercial sem remuneração extra (isso foi no campo da assistência médica). Acho que a solução (que sugeri ao meu gerente na época) seria ter uma linha de frente de suporte técnico e, se for um bug do software, encaminhe-a aos 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 geralmente dá uma perspectiva que a maioria das pessoas, principalmente os programadores, não tem. O modo como o usuário realmente usa o produto, ou realmente pensa, está muito distante do que o construtor (o engenheiro) pensa que ele faz.

Deve ser por períodos curtos e periódicos, para 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. Não sei se esses talentos têm correlação.

Isso significa que você precisa contratar desenvolvedores com base em sua capacidade de oferecer suporte por telefone ou permitir que seus clientes conversem diretamente com pessoas que não são boas em lidar com clientes e não querem fazê-lo em primeiro lugar. Isso pode ou não ser melhor do que tê-los conversando com um cara com um forte sotaque indiano que lê de um roteiro educado.

Além disso, quando você torna o trabalho desagradável (e eu não conheço nenhum desenvolvedor que realmente goste de suporte de primeira linha), alguns de seus desenvolvedores irão embora. Geralmente, são eles que conseguem outros empregos com mais facilidade: ou seja, os bons. À medida que esse processo prossegue, você acaba com uma loja cheia de pessoas menos talentosas, tornando ainda menos agradável para o competente permanecer além da primeira oferta de emprego de outra pessoa.

Quanto ao desenvolvimento sério, esqueça-o se houver interrupções frequentes. Minha esposa se queixou muito da expectativa de desenvolver e dar suporte aos usuários simultaneamente.

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

Eu acho que a melhor estratégia geral (sem considerar o tamanho ou recursos da empresa) é usar equipes de suporte para solucionar problemas de problemas pendentes e os problemas mais comuns ("Você já tentou desligar e ligar?"). Os engenheiros devem trabalhar com os clientes nos problemas mais complicados que exigem conhecimento de como o sistema funciona, além de um suporte mais orientado ao desenvolvedor (APIs, ferramentas de desenvolvedor etc.). Você pode fazer com que a pessoa de suporte atue como uma "ligação", mas acho que geralmente é mais problemas do que vale a pena.

Enquanto eu não acho que seja apropriado para devs uso como suporte todo o tempo, eu acho que há algo a ser dito para ter um dev fazer o apoio inicial de um aplicativo. Isso deve incluir especificamente o suporte fora do horário comercial. Também acho que pode ser útil agendá-los regularmente para o suporte após o horário de expediente para seus aplicativos.

Não há nada como várias chamadas às 3 da manhã para fazer você perceber o efeito que determinadas decisões de design e / ou atalhos têm na capacidade das pessoas de dar suporte e manter seu código.

Idealmente, não pelas razões mencionadas acima, mas sim enquanto o projeto é incipiente, porque os desenvolvedores podem fornecer resoluções rápidas, geralmente esperadas pelos negócios, o que dá suporte à melhoria contínua do software. Valorizo ​​os desenvolvedores que fornecem suporte de maneira inteligente: aqueles que emprestam suas habilidades analíticas, por exemplo, a uma equipe de suporte em tempo integral mais formal e aqueles que respondem aos negócios de maneira a demonstrar espírito de serviço e cooperação. As chaves para esse sucesso, porém, incluem o gerenciamento reconhecendo e formalizando o suporte de primeiro e segundo nível para descarregar rapidamente os desenvolvedores do que deve ser apenas o seu papel de curto prazo. Os desenvolvedores que demonstram talento para desenvolvimento e suporte devem ser cultivados como suporte de terceiro nível ou suporte para o pessoal de suporte. Então deveria depende do tempo, depende do talento e do desejo e é gerenciado com eficácia.

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

Entrei nessa armadilha quando entrei para uma empresa com um bom salário. Durante a entrevista, fui informado de que haverá 70% de desenvolvimento e 30% de suporte, e aceitei a oferta. Pode ser que seja a empresa ou o ambiente em que estou trabalhando atualmente. Mas, na verdade, 90% suportam e 10% desenvolvem. Já faz alguns anos que perdi o controle do desenvolvimento. Lamento ter aceitado esta oferta.

Mas sinto que perdi o controle da codificação por muitas novas tecnologias e estruturas. Agora não sei por onde começar de novo. Continuo me preparando, mas esses exemplos do mundo hellow não são suficientes para ter uma boa experiência prática e está realmente ficando difícil atualizar meus conhecimentos e experiências. Eu não posso nem deixar meu trabalho para começar de novo por causa de compromissos familiares.

Infelizmente estou em um impasse.

Não aceite papéis se você não gosta ou não está interessado.

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

1) Estragando seus clientes

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

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

Quem já lidou com clientes sabe que é um pré-requisito poder mentir para eles. Há um erro com uma correção de 1 linha que pode ser feita em 5 minutos. Uma pessoa de suporte ao cliente seria treinada para gerenciar as expectativas do cliente - que levaria até três dias para resolver o problema.

Como desenvolvedor, se você precisar 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á um aspecto técnico.

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

Prós

1) Pare os chorões de choramingar

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

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