Para muitas empresas, principalmente empresas desenvolvedoras de algum tipo de solução tecnológica, o time de Suporte atua em constante contato (e por vezes conflito) com o time de Desenvolvimento.
É muito comum que estas equipes estejam em busca de soluções, mas é raro vê-las atuando em conjunto na identificação e tratamento das dores comuns que mais comprometem a qualidade da entrega final.
Por isto, hoje iremos tratar desta “zona de guerra” em potencial: a fronteira entre os times de atendimento e desenvolvimento.
Boa leitura!
As diferenças entre as equipes começam na motivação de cada, ou na cultura.
Geralmente, os agentes de suporte são mais inclinados a estabilidade, podendo ser mais avessos à mudanças radicais. O desenvolvimento provavelmente está interessado em tratar problemas estruturais mais relevantes para o produto, enquanto o suporte pode ser mais sensível a detalhes incômodos na experiência do usuário.
Em geral, a componente “cliente” está mais evidente ao suporte. O agente de suporte pode não se preocupar tanto com a evolução e futuro do produto, mas ele conhece as funcionalidades que geram mais problemas e o que precisa melhorar para atender melhor à necessidade do cliente.
Como trazer, então, esta perspectiva para o desenvolvimento? Basicamente, é necessário que todos entendam seus papéis na solução da dor do cliente, que o objetivo, afinal, não seja atingir a máxima efetividade dentro do seu escopo mas fazer o melhor dentro de um contexto amplo, de entrega de valor.
Talvez isso pareça muito intangível ou subjetivo, mas tentaremos explicar melhor a seguir.
Um componente crítico no trabalho conjunto do Desenvolvimento com o Suporte é o backlog, ou o repositório de tarefas a serem executadas. O backlog deve ser mantido organizado, o que basicamente significa dividir as tarefas por prioridade de execução.
A priorização é um elemento essencial para um bom fluxo de entregas. No mundo real, não temos capacidade de fazer tudo que poderíamos, então priorizar é, na essência, decidir o que não será feito, ou o que deverá ser deixado para depois. Esta nem sempre é uma decisão tranquila ou óbvia.
Os critérios de priorização devem ser totalmente pensados de acordo com fluxo de valor, do qual falamos há pouco. O que gera maior resultado para o cliente? O que está de acordo com nossa diretriz de entrega valor?
A priorização deve ser tangível, baseada em métricas de acompanhamento para entender se a solução está atendendo ao cenário desenhado, devemos prosseguir (ou não) de acordo com o resultado e parâmetros objetivos.
É comum a existência de um “Guardião”, ou aquele que organiza as demandas das diferentes frentes de acordo com uma filosofia única e clara, uma maneira em comum de priorizar demandas de Suporte, Desenvolvimento, Customer Success, etc.
A adoção de uma cultura de priorização pode ser terrível. No começo, haverá quebra de expectativas e dor, haverá conflito, mas isto não deve impedir o avanço pois nos levará à maturidade necessária. Lembre-se de que reuniões são caras e reuniões com múltiplas equipes, mais caras ainda! Não perca tempo com discussões subjetivas quando o assunto for priorização.
A felicidade do cliente não se dará pela simples soma das partes, mas pela forma como as interações (internas e externas) ocorrem.
Um Suporte proativo pode identificar não apenas os bugs e disfuncionalidades na usabilidade, mas também melhorias que possam atender às principais dores do cliente, aproveitando-se da sua visão externa privilegiada.
O Suporte também deve dar apoio ao Product Owner (P.O.) com os dados do seu sistema de helpdesk, ajudando na identificação dos problemas mais recorrentes por exemplo.
Todas as sugestões e solicitações devem ser suportadas por argumentos claros de alinhamento com a diretriz de valor, o que geralmente significa trazer números (dados) para a conversa.
Desde nossa educação na escola, somos treinados para pensar em “módulos”, com matérias bem segregadas e delimitadas. No entanto, dentro da realidade das empresas, os processos são sistêmicos, e não lineares. Como disse Leandro Garcia, da i9 Flow: “a felicidade do cliente não se dará pela simples soma das partes, mas pela forma como as interações (internas e externas) ocorrem”.
Ao invés de trabalhar apenas para seu departamento, é necessário “passar o bastão”, mesmo que o foco de cada área seja diferente, a gestão deve incentivar e avaliar de acordo com objetivos em comum, como veremos a seguir.
Meta é do time, não da pessoa. Não incentive uma competitividade negativa entre agentes, pois é possível que, caso seja avaliado e recompensado com base apenas em seu desempenho individual, este funcionário se descole do fluxo de valor.
O modelo de avaliação e recompensa deve ser baseado no resultado percebido pelo cliente, e isto não é algo simples.
Uma boa maneira de perseguir este ideal é através do compartilhamento de metas entre times. Processos que envolvem uma visão mais ampla e possuem interações entre departamentos (basicamente qualquer processo) devem ter metas em comum.
Um exemplo de métrica é o lead time. O lead time nada mais é que uma medida de tempo média, geralmente adotada pela perspectiva de uma equipe (por exemplo, tempo entre a entrada e entrega de um item no fluxo de desenvolvimento). Acontece que o lead time pode ser medido pela visão do seu time ou pela visão do cliente, e para o cliente pouco importa em que etapa do seu processo interno está o problema, se foi a equipe X ou Y que atrasou: a sua empresa é uma “caixa preta”, e a reputação que está em jogo é a da sua marca.
Avançar rumo a maturidade de processo não é fácil, mas a partir do momento em que as pessoas entendem que fazem parte de um processo, que não é possível fazer tudo e que as rotinas têm de atender dinamicamente a necessidade cliente, o seu processo de priorização e execução muito provavelmente já estará alinhado à sua entrega de resultado.
Temos também um artigo mais recente com um bate-papo realizado com a Objective sobre este tema, dá uma olhada aqui!