Desenvolvedor no Suporte

Depois de começar a trabalhar na Atlassian eu tive contato com algumas práticas muito interessantes. Uma delas é colocar cada desenvolvedor para trabalhar no suporte do produto que ele desenvolve por algum tempo. Chamamos isso de developer on support, ou DoS.

Funcionamento

Basicamente, a equipe que desenvolve o produto deve ceder um desenvolvedor para trabalhar em conjunto com o suporte por um período de tempo, num esquema de revezamento.

Ao final do seu período de trabalho, cada desenvolvedor tem a responsabilidade de passar o bastão para o próximo continuar com as correções e investigações de erros que estavam sendo feitas.

É necessário um bom nível de organização com as práticas de suporte, pois novos desenvolvedores devem rapidamente conseguir aprender a usar as ferramentas, realizar as investigações e obter acesso aos ambientes necessários.

Responsabilidades

O trabalho não é de atender clientes, mas solucionar ou pelo menos encontrar as causas dos problemas mais difíceis, que estão além da capacidade investigativa da equipe de suporte por exigirem conhecimentos internos do sistema, do código, etc.

Na Atlassian, isto é feito através de um processo de "escalação", isto é, quando um problema não é resolvido pelo suporte básico, ele é “escalado” para um suporte de mais alto nível.

Funciona mais ou menos assim:

• Os analistas de suporte fazem uma primeira investigação.
• Se o problema não for solucionado, eles redirecionam para um analista sênior.
• Se ainda assim o problema não for solucionado, então ele é escalado para o desenvolvedor no suporte.

O desenvolvedor no suporte é a última linha de investigação, afinal, se o desenvolvedor não pode resolver o problema, quem poderia?

Nos casos onde o problema é relacionado a algo de responsabilidade de outra equipe, o desenvolvedor pode simplesmente documentar a investigação realizada e redirecionar a resolução para aquela equipe, monitorando o problema até que seja efetivamente solucionado.

Conhecimentos necessários

Além das ferramentas internas, específicas de cada empresa, o processo de investigação de um problema complexo exige conhecimentos pelo menos básicos dos diferentes aspectos do sistema.

Claro que em alguns momentos é preciso consultar os colegas desenvolvedores, mas você deve saber no mínimo identificar o tipo de erro, isto é, se é algo no banco, nas regras de negócio, nos scripts, na rede, etc.

No meu tempo como DoS eu gastei muito tempo usando a ferramenta do desenvolvedor do meu navegador. Alguns bugs eram relacionados à forma como as requisições eram feitas.

O Google Chrome, por exemplo, permite que o usuário grave e exporte todas as operações de rede num arquivo HAR (HTTP Archive). Isso é extremamente útil pois você pode pedir ao usuário para reproduzir o erro e enviar essas informações, o que já elimina de cara qualquer mau uso por parte dele. Um arquivo HAR permite ver exatamente os cabeçalhos e conteúdos das requisições e respostas efetuadas.

Também usei muito ferramentas como Eclipse MAT e JVisualVM para analisar Heap Dumps, isto é, mapas de memória extraídos de JVMs que apresentaram problemas. Um heap dump contém todas as stack traces (pilhas), o uso de memória e os objetos e seus estados no momento em que foi extraído. Isso permite verificar os valores que levaram o sistema a se comportar de maneira inesperada. Com as ferramentas mencionadas é possível realizar queries no mapa da memória, procurando por certos objetos ou valores. Algo muito útil é o parâmetro -XX:+HeapDumpOnOutOfMemoryError da JVM que cria um heap dump automaticamente se houver estouro de memória, o que facilita enormemente na identificação da causa sem precisar recorrer ao usual processo de adivinhação e tentativa-e-erro.

Enfim, também há muita criatividade envolvida, já que você simplesmente precisa dar um jeito de encontrar a causa do problema o mais rapidamente possível. Isso ajuda a desenvolver aquelas habilidades que geralmente ficam dormentes logo que você está confortável trabalhando somente com o que já conhece.

Benefícios

Pessoalmente, colhi vários benefícios:

• Aprendi muito sobre o sistema, partes que geralmente eu nunca colocaria a mão, mas que podem ajudar de forma geral nos trabalhos futuros.
• Também fiquei muito mais hábil com as ferramentas de investigação e agora posso usá-las melhor ainda durante o desenvolvimento.
• Deixar seu trabalho “normal” e embarcar numa experiência nova refresca a cabeça. É como tirar férias, mas trabalhando em outra coisa.
• Conheci pessoas novas, o que além de aumentar meu círculo de contatos na empresa, potencialmente aumenta meu círculo de amigos.
• E o que mais me chamou a atenção: entender o tipo de problema que os usuários enfrentam na prática. Isso muda um pouco a sua cabeça. Às vezes você pensa que os usuários estão sedentos por novos recursos quando, na verdade, eles estão morrendo à míngua porque coisas básicas falham frequentemente por motivos diversos. Agora você tem o poder de fazer a diferença.

Para a empresa, os benefícios são incalculáveis:

• Promover a integração entre diferentes áreas da empresa. Acaba-se com essa divisão ridícula entre suporte e desenvolvimento que não se conversam ou até se confrontam.
• Os clientes ficam mais satisfeitos porque as respostas vêm mais rápido e as soluções mais certeiras.
• O pessoal do suporte aprende com o desenvolvedor e muitas vezes isso evita novos erros semelhantes sendo escalados.
• O desenvolvedor aprende com o suporte a lidar com problemas e várias outras coisas, tipo a ter mais paciência, sabe? Sério, pessoas que dão suporte geralmente são excelentes pessoas, final elas precisam ter muita paciência e deveriam ganhar prêmios só por causa disso.
• O desenvolvedor aprende sobre o uso real do sistema e vai levar essa carga para o próximo projeto.

Dificuldades

Claro que nem tudo é fácil.

Empresas com equipes pequenas ou com muitos projetos por equipe teriam dificuldades em arcar com os custos de manter um desenvolvedor no suporte em tempo integral. Neste caso, pode-se fazer isto por períodos de tempo menores, como reservar algumas horas por dia, alguns dias na semana ou uma semana por mês.

Além disso, há desenvolvedores que simplesmente odeiam esse tipo de coisa. Eu sei que cada um tem suas razões particulares, mas a maioria dos casos que conheço, na prática, se resume em dificuldades para deixar a zona de conforto. A solução neste caso é tornar isso uma prática comum da empresa como um todo, mostrando os benefícios e fazendo disso algo normal, assim não tem desculpa para quem quer trabalhar ali. Um “agradinho” não faz mal — eu mesmo ganhei uma camiseta. 🙂

Considerações

Deixar o meu trabalho cotidiano e ir para o suporte pareceu algo bem estranho a princípio, mas foi uma das melhores experiências que tive. As razões estão descritas acima.

Eu recomendo fortemente que todos os desenvolvedores tenham contato com o suporte em algum nível. A experiência que descrevi acima é apenas uma das muitas formas que isto pode assumir.

De forma geral, acredito que o desenvolvedor deve aprender, de uma forma ou de outra, a ter mais responsabilidade sobre aquilo que ele faz, evitando assim uma cultura de conflitos entre desenvolvedor, cliente e suporte.