Muitos especialistas na área de desenvolvimento de software acreditam que é impossível combinar desenvolvimento e suporte ao usuário em uma equipe. Um ou outro. Em geral, o suporte deve ser fornecido aos indivíduos.
Hoje, quero falar sobre como nós do Odobrim.ru conseguimos combinar o incompatível, ou melhor, como a equipe de desenvolvimento pode dar suporte aos produtos. Isso deve ser de 2 a 3 linhas de suporte ao mesmo tempo.
O Odobrim.ru é um serviço online gratuito para seleção de cartões de crédito, empréstimos e empréstimos para pessoas físicas, independente de bancos.
Nossa tarefa : ajudar o cliente a obter e manter o produto de empréstimo ideal que resolve as tarefas do cliente.
O processo de tratamento de chamadas está estruturado da seguinte forma
1. O “Serviço de Atendimento ao Cliente” cuida de nossos clientes - a primeira linha de suporte. Sim, sim, em bons lugares existe :))
O "Serviço de atendimento ao cliente" ajuda os usuários com todas as perguntas que surgem ao trabalhar com o serviço. Qualquer empresa que se preocupa com seus clientes deve ter uma primeira linha de suporte, com a qual você pode entrar em contato para obter assistência o tempo todo.
Se o "Serviço de Atendimento ao Cliente" puder ajudar o cliente, a próxima linha não será iniciada. Caso contrário, o recurso é iniciado e transmitido para a próxima linha. Nada sobrenatural até agora.
E depois disso, geralmente existem mais duas linhas de suporte, mas temos uma: combinamos a segunda e a terceira linhas de suporte. Isso aconteceu depois que o produto entrou no mercado e, portanto, vivemos há cerca de dois anos. E nós vivemos perfeitamente!
2. O monitoramento das solicitações do usuário é realizado regularmente.
O engenheiro de serviço é chamado voluntariamente para uma chamada semanal de serviço.
Um quadro de referência é semelhante ao quadro Kanban.
Tudo é muito convenientemente configurado:
3. A classificação inicial do recurso é feita pelo engenheiro de serviço e, com base em seus resultados, é criado separadamente Bug (bug com referência à documentação / requisitos) ou Story (tarefa). Eles estão ligados à circulação. Temos os prazos para a correção de erros e o atendente está tentando pegá-los.
4. Na próxima etapa, o bug corrigido é corrigido pelos desenvolvedores (bloqueador, crítico). Em seguida, a verificação e confirmação da correção são realizadas pelo engenheiro de serviço
5. A história (tarefa) é transferida para o pedido de compra (proprietário do produto) para priorização.
Por 2 anos, a equipe de desenvolvimento processou mais de 270 chamadas de diferentes prioridades de nossa unidade de negócios e usuários, dentre as que a primeira linha de suporte não conseguiu atender.
Prós desta abordagem
- Os apelos de clientes e unidades de negócios não são perdidos e são coletados em uma placa.
- A equipe vê todos os principais problemas do produto e está interessada em resolvê-los, ou seja, está se aproximando dos usuários de seu serviço, o que afeta positivamente a qualidade do serviço e do produto como um todo.
- Todo desenvolvedor, percebendo que terá que estar de plantão, tenta escrever melhor o código para não criar problemas adicionais para ele e seus colegas.
- Sempre há um engenheiro responsável.
- O envolvimento da equipe na resolução de problemas comuns de produtos está aumentando.
- Monitoramento constante sem regulamentos adicionais.
Contras desta abordagem
Os membros da equipe precisam de um alto nível de profissionalismo, responsabilidade e interesse. E a coragem de ser chamado de plantão.
Se você encontrou esquemas semelhantes de organizações de suporte, compartilhe sua experiência nos comentários.