A tradução do artigo foi elaborada especificamente para os alunos do curso .
A missão da Intercom é personalizar os negócios online. Mas você não pode personalizar um produto quando ele não funciona. . O desempenho é fundamental para o sucesso do nosso negócio, não só porque os nossos clientes nos pagam, mas também porque nós próprios utilizamos . Se nosso serviço não funcionar, literalmente sentiremos a dor de nossos clientes.
O bom funcionamento depende de muitos fatores, como a arquitetura do software e a qualidade do trabalho diário. Porém, muitas vezes tudo se resume ao fato de que a pessoa que está sempre em contato atende ligações de . Esse tipo de suporte técnico pode ser uma ferramenta poderosa centrada no cliente que combina a ajuda dos engenheiros com o que os clientes obtêm quando compram seu produto. Esta é também uma grande oportunidade de aprendizagem e crescimento, porque afinal, falhas e erros podem ser uma boa oportunidade para praticar competências e compreender mecanismos complexos de trabalho.
Estar “sempre ligado” fora do horário de trabalho tem um efeito prejudicial em sua vida.
Mas, ao mesmo tempo, estar “sempre ligado” pode ter um efeito prejudicial na sua vida. Você deve estar pronto para responder com rapidez e competência a um alerta de que algo está quebrado. Mesmo que você não esteja sendo bipado em nenhum momento, estar “sempre ligado” pode criar ansiedade, como sei por experiência própria. Por causa disso, a qualidade do sono se deteriora especialmente. Estar regularmente na zona de acesso a qualquer hora do dia pode levar ao esgotamento, à apatia ou, em geral, ao desejo de nunca mais ver o computador.
História do estado “sempre conectado” na Intercom
Nos primórdios da Intercom, nosso Diretor Técnico, Ciaran, fornecia sozinho uma equipe inteira de suporte técnico XNUMX horas por dia, XNUMX dias por semana, dentro e fora do escritório. À medida que a Intercom crescia, uma força-tarefa foi criada para ajudar Ciaran. Logo depois, novas equipes de desenvolvimento começaram a criar muitos novos recursos e serviços e assumiram todas as responsabilidades de suporte técnico.
Havia muitas pessoas “de plantão” em um determinado momento.
Na época, essa abordagem parecia óbvia porque era uma maneira fácil de dimensionar nossa equipe de suporte técnico a qualquer momento, estava alinhada com nossos valores e se adequava às nossas necessidades. . No final, sem planos, acabámos com quatro ou cinco equipas que contactavam regularmente os clientes fora do horário laboral. O restante das equipes de desenvolvimento não tinha muitos problemas complexos que pudessem gerar um erro, por isso raramente, ou nunca, eram chamados.
Percebemos que estávamos numa situação em que tínhamos mecânicos de suporte técnico dos quais não poderíamos nos orgulhar e uma série de problemas críticos que queríamos corrigir, como:
- Havia muitas pessoas prontas para enfrentar o desafio a qualquer momento. Nossa infraestrutura não era grande o suficiente para exigir um mínimo de cinco engenheiros de desenvolvimento para trabalhar sem folgas regulares.
- A qualidade dos nossos alarmes e procedimentos de chamada não era consistente entre as equipes, e utilizamos processos ad hoc para analisar alertas de problemas novos e existentes. As instruções no runbook (a serem seguidas quando notificado sobre um problema) se destacavam principalmente por sua ausência.
- Dependendo da equipe em que os engenheiros trabalhavam, eles tinham expectativas conflitantes. Por exemplo, apenas a primeira equipe de suporte técnico recebeu alguma compensação por turnos de plantão e fins de semana interrompidos.
- Parecia haver um nível geral de tolerância para chamadas desnecessárias em horários estranhos.
- Finalmente, este tipo de trabalho não é para todos. As circunstâncias da vida às vezes mostravam que as mudanças de plantão não tinham o melhor efeito sobre as pessoas.
Encontrando o estado “sempre ligado” certo
Decidimos criar uma nova equipe virtual que realizaria trabalhos de suporte técnico para cada equipe fora do horário comercial. A equipe será formada por voluntários e não por recrutas de qualquer equipe da organização. Os engenheiros da equipe virtual alternavam aproximadamente a cada seis meses, passando semanas “de plantão”. Felizmente, não tivemos problemas em encontrar voluntários suficientes para montar uma equipe virtual.
Como resultado, nossa equipe de suporte foi reduzida de 30 pessoas para apenas 6 ou 7.
A equipe então concordou e definiu como deveriam ser os alertas e as descrições de problemas no runbook e descreveu um processo para encaminhar alertas para a nova equipe de suporte. Eles definiram todos os alertas no código usando um módulo Terraform e começaram a usar a revisão por pares para cada alteração. Introduzimos um nível de remuneração para o turno semanal que foi bastante satisfatório para os oficiais de plantão. Também criamos uma equipe escalada de segundo nível composta apenas por gerentes. Essa equipe deve ser o único ponto de escalação para os engenheiros de suporte técnico.
Tivemos vários meses de trabalho árduo, durante os quais estabelecemos este processo, como resultado, já não havia 30 engenheiros de plantão como antes, mas apenas 6 ou 7. Durante o horário de trabalho, as equipes lidam de forma independente com problemas em suas funções ou serviços, em Este é o momento em que normalmente ocorre o maior número de avarias, mas nos restantes momentos o apoio técnico é prestado por voluntários.
O que aprendemos
Depois de lançarmos nossa equipe de suporte técnico virtual, esperávamos um fluxo de novas tarefas, como investigar as causas dos problemas ou nos reunir para resolver um único problema que estava causando uma interrupção. No entanto, as nossas equipas de desenvolvimento assumiram total responsabilidade pelos factores que causaram as falhas e qualquer resposta subsequente foi normalmente imediata. Também precisávamos evitar uma situação em que uma tarefa de consulta técnica fosse devolvida à equipe de onde veio, para não forçar o contato dos engenheiros após o expediente.
O número de ligações fora do horário comercial caiu para menos de 10 por mês.
Nosso processo de escalonamento raramente era usado formalmente. Uma crença mais comum era a de que o engenheiro foi ajudado extraoficialmente pela equipe que estava online no momento, especialmente pelo nosso pessoal do escritório de São Francisco. Muitos problemas foram eliminados ou reduzidos por meio do trabalho em equipe e da solução imediata.
Os engenheiros do nosso escritório em São Francisco juntaram-se à equipe em tempo integral e foram além do suporte técnico típico. Enfrentamos alguns custos indiretos, mas espalhar a participação da nossa equipe de suporte em vários escritórios funcionou a nosso favor, pois provou ser uma boa maneira de construir relacionamentos, fortalecê-los e aprender mais sobre a pilha de tecnologia com a qual todos trabalhamos.
O trabalho dos desenvolvedores da Intercom se tornou mais consistente em nossas equipes, e podemos falar com segurança sobre os benefícios de ser engenheiro de sistemas em nosso site , afirmando que não há necessidade de estar sempre conectado, a menos que você queira.
Juntamente com o trabalho fundamental para estabilizar e dimensionar nossos armazenamentos de dados, um foco contínuo na solução de problemas fez com que o número de chamadas fora do horário comercial caísse para menos de 10 por mês. Estamos muito orgulhosos deste número.
Continuamos trabalhando para manter e melhorar nossa equipe de suporte técnico e, à medida que a Intercom cresce, talvez tenhamos que reconsiderar nossas decisões, porque o que funciona hoje não funcionará necessariamente na próxima vez que nossa equipe dobrar. No entanto, esta experiência tem sido extremamente positiva para a nossa organização e melhorou muito a qualidade de vida dos nossos engenheiros de desenvolvimento, a qualidade das nossas respostas às chamadas e, acima de tudo, a experiência dos nossos clientes.
Fonte: habr.com