Suporte vs. Desenvolvimento: um bate-papo com a Objective

Quem trabalha em contato entre as áreas de Suporte e Desenvolvimento provavelmente vai ter algumas lembranças de momentos pouco “amistosos”, ou de pressões sofridas sob protestos de uma ou outra parte. Muitas vezes, as diferenças culturais e de objetivos podem gerar atrito e irritação entre os colaboradores, e o fluxo de valor nem sempre é claro e bem unificado.

No dia 12 de maio de 2021, nós tivemos uma (amigável) discussão sobre esta “polêmica” no webinar Desenvolvimento + Suporte: precisamos falar sobre isso!. Junto ao nosso CEO Omar Branquinho, representando o Suporte, estavam Marcelo Walter e Danilo Garcia, gestores de times ágeis na Objective, representando o Desenvolvimento.

Abaixo, nós separamos alguns momentos da conversa. Vem conferir!

As diferenças entre Suporte e Desenvolvimento

“Qualquer conflito é essencialmente uma diferença de valores”

Omar

O papo começou abordando as diferenças entre as duas áreas, que são muito associadas à própria natureza da execução em cada. Como comentou Omar, enquanto o Suporte normalmente preza pela estabilidade, por ter um sistema funcionando, o Desenvolvimento por vezes olha mais para a evolução e planejamento de melhorias.

Então a conversa rapidamente envergou para uma das principais consequências desta particularidade: a diferença no “ritmo” entre Suporte e Desenvolvimento.

Marcelo ilustrou a seguinte situação: o agente de suporte cobrando uma execução mais rápida do desenvolvimento (para corrigir um bug, por exemplo), enquanto o desenvolvedor está preocupado com os impactos e etapas necessárias até que a correção esteja no ar. Apesar de parecer uma pressão “injusta” por parte do atendente, ele também pode estar sobre pressão pelo cliente que não pode esperar mais.

Algumas vezes a complexidade da solução não está clara para o Suporte, assim como a situação no cliente não é visível ao desenvolvimento. Danilo mencionou ainda as “nightly builds” e outros obstáculos como o linguajar (especificação imprecisa ou insuficiente, por exemplo) que dificultam a transparência entre as áreas.

Sobre integrar dois mundos distintos

Marcelo comentou ainda sobre casos de intercâmbios entre os departamentos, onde desenvolvedores vivenciam a realidade de suporte e vice-e-versa. Desta forma cada time terá uma noção das principais dificuldades enfrentadas pelo outro e poderá agir de forma a amenizá-las.

Outro ponto, discutido a partir de uma pergunta do público, foi sobre como estruturar o “meio-campo” entre as duas equipes. Segundo a regra de bolso do Omar: uma posição onde a única função seja fazer a “troca” de informações, não deveria estar em um processo eficiente.

Veja mais detalhes no vídeo:

Ao falar sobre o “rodízio” de colaboradores entre departamentos, Danilo forneceu alguns exemplos de resultados de integrações bem-sucedidas, como a descrição por parte do atendente dos testes de reprodução, com os procedimentos que devem ser executados pelo desenvolvedor. Outra experiência de integração que vivenciou foi a inclusão do Suporte nas reuniões de retrospectiva de um time de desenvolvedores, reduzindo o ciclo de feedback no projeto.

“Quando você quebra este paradigma de que é só ‘uma coisa chata a se fazer’ e entende que Suporte é uma área necessária para o crescimento do produto, eu vejo a coisa funcionando muito bem.”

Danilo

Apesar da experiência positiva, como lembrou Marcelo, é importante encontrar o equilíbrio entre documentação e dinamicidade para que o andamento do processo não seja prejudicado. Sobre o “rodízio” entre times, nossos participantes concordaram que, apesar de gerar intimidade, não é suficiente para sanar o problema sem outras melhorias no processo.

Então, o que é prioridade na integração entre estes dois mundos?

“Você tocou em um ponto importante, mas que a gente vê bem pouco por aí, que é estar no mesmo fluxo de valor”

Marcelo

Dar visibilidade do fluxo como uma só entrega de valor, e não como áreas com problemas e processos isolados, pode melhorar bastante o relacionamento, pontua Marcelo.

Omar comenta que, na sua empresa anterior, o desenvolvimento trabalhava com uma ferramenta diferente do Suporte e não integrado ao software de helpdesk. Isto gerava um “buraco” não só de integração, mas também de gestão, a partir do momento que existiam dois backlogs (estoques) distintos.

Para resolver esta divergência, todas as demandas precisaram ser correspondidas e reavaliadas. Para gerar o senso de urgência e noção de volume, estes itens foram transformados em post-its e transferidos para uma parede. Como disse Omar: “Não tem coisa mais importante do que o impacto visual de uma parede cheia de post-its de coisas para fazer!”.

Isto possibilitou a construção de uma nova mecânica de trabalho com maior visibilidade para todos os envolvidos, antes de levar tudo para o software do dia-a-dia. Todas as etapas dos trabalhos do Desenvolvedor e do Suporte estavam, agora, mais claros aos dois times.

As funções de cada um

Você provavelmente já entrou em contato com algumas equipes de suporte na sua vida, certo?

Quantas delas resolveram o problema na hora? Quantas precisaram encaminhar a solução à outros departamentos?

Esta foi uma questão levantada pelo Marcelo: até que ponto o atendimento (em empresas de TI) deve “colocar a mão na massa” e fazer de tudo para resolver o problema do cliente sem depender de outro departamento, como o desenvolvimento?

A resposta para esta questão, como ficou claro na discussão, não é tão simples: existem pós e contras de se dar autonomia e concentrar tarefas nas mãos de um mesmo agente, e a resposta tangencia também a gestão de conhecimento abordada nas seções anteriores.

“O Chuck Norris do atendimento tem dois problemas: replicar o Chuck Norris é difícil, e o Chuck Norris não é imortal. O processo precisa estar acima das pessoas, mesmo sem tirar o protagonismo.”

Omar

O “atendente Superman”, como apelidado pelo Omar, encontra problemas na sustentabilidade a médio e longo prazo. Mencionando o artigo sobre o ciclo de vida do atendimento (este aqui), ele lembrou do momento em que a equipe cresce e o contexto passa a estar distribuído, dificultando a gestão do conhecimento. Logo, embora o atendimento que atua em outras áreas (vendas, desenvolvimento, entre outras) seja uma vantagem em equipes novas e pequenas, ele representa um problema de produtividade visto que pode esconder um processo ineficiente.

Em suma, processos não podem depender inteiramente de alguns colaboradores, as informações e procedimentos devem estar bem estabelecidos e claros para que seja possível escalar.

Outro ponto que foi discutido, desta vez a partir do comentário do público: a função do atendimento, antes de “segurar” o cliente, é de alinhar as suas expectativas, e esta é uma fonte de conflito entre as duas equipes.

Logo a conversa chegou ao SLA, ou Service Level Agreement. Como fazer com que a expectativa do cliente esteja alinhada com um processo que depende de duas (ou mais equipes)?

Marcelo lembrou que falar de expectativa de prazo é falar de previsibilidade e, portanto, em minimizar a variabilidade do fluxo de entrega.

“A partir do momento que você diminui a variabilidade, passa a ter mais previsibilidade. Na boa, o pessoal diz que desenvolvimento é um processo completamente artesanal, mas não é.”

Marcelo

Dentro deste raciocínio, ocorrências que saem do esperado são raras e assim é possível ter uma certeza bastante alta do tempo necessário para a entrega a partir dos dados do próprio sistema.

Veja a discussão completa no vídeo abaixo:

Omar ainda acrescentou que o SLA não é apenas medir e calcular a partir do seu próprio processo, mas trazer a expectativa e necessidade do cliente, forçando um padrão de qualidade desejado.

Metas compartilhadas entre Suporte e Desenvolvimento

“Dado que a melhor maneira de medir o atendimento é o SLA e a satisfação, uma coisa que é muito boa na minha visão é você ter metas compartilhadas entre as duas equipes.”

Omar

A partir do momento que Suporte e Desenvolvimento estão em um mesmo fluxo de valor, que os processos já foram estruturados de forma transparente e com experiências compartilhadas entre os departamentos, você passa a olhar o processo como um só. Sendo assim, faz todo sentido que as principais métricas sejam compartilhadas.

Confira o depoimento completo:

Após a fala do Omar, o Danilo ofereceu um exemplo de como a visibilidade do fluxo entre Suporte e Desenvolvimento permite identificar e tratar os gargalos. Naquele caso, apesar de todas as suspeitas apontarem para uma demora no trabalho dos desenvolvedores, verificou-se que a etapa mais custosa em termos de tempo era a devolução pós-desenvolvimento.

“Como diz a Teoria das Restrições, o processo sempre tem gargalos. Em processos de serviços, qualquer fila pode ser um gargalo a qualquer momento, e monitorar estes processos é ainda mais importante do que no processo fabril, onde os padrões são mais claros.”

Omar

Logo após a questão dos gargalos, Marcelo trouxe a conversa para a priorização. Ressaltou a importância de tratamentos adequados à cada “classe de serviço” (ou “categoria”) e como estas diferentes categorias terão, portanto, metas (sobretudo SLAs) diferentes.

Falando mais um pouco sobre a definição do SLA, Omar mencionou que já viu muitas equipes de suporte que não mediam o SLA por medo do número e como isto inevitavelmente vai resultar em prazos impostos, e não acordados.

Conclusão e outras dicas

Apesar de tantos temas abordados, ao final do webinar, ainda não foi possível falar de todos os pontos planejados.

O relacionamento entre duas equipes tão importante para o suporte e entrega de valor ao cliente é um tema complexo, claro, e merece muita atenção.

Se você quiser conhecer mais sobre as duas empresas envolvidas neste conteúdo, se liga nas dicas:

Deskflows

O objetivo da Deskflows é fazer equipes mais produtivas através da tecnologia.

Confira nosso site, e baixe sua cópia gratuita da nossa Planilha de Filas para dimensionar o seu processo em busca de gargalos!

Objective

A Objective é uma desenvolvedora de software que oferece consultoria a fim de gerar processos mais ágeis.

Saiba mais sobre o serviço e confira também nosso artigo sobre Fluxo Unificado, que tem muito a ver com o assunto discutido aqui.