Pedido do cliente → código entregue

Do pedido do cliente ao código entregue — em uma só ferramenta

Um cliente relata um problema. Ele vira uma tarefa, um desenvolvedor o corrige na IDE, o commit fica vinculado à tarefa, o trabalho passa por revisão e testes — e, quando chega à etapa final, o cliente é avisado de que está pronto. O Vi liga cada elo dessa corrente, então nada é copiado à mão e ninguém precisa lembrar de enviar uma atualização.

Onde um pedido de cliente costuma se perder?

Um pedido de cliente costuma se perder nas passagens entre ferramentas: o suporte o registra em um helpdesk, alguém o copia para o rastreador de issues, um desenvolvedor o corrige no Git, e o cliente só recebe retorno se alguém lembrar de voltar à primeira ferramenta. Cada passagem perde contexto — qual cliente pediu, o que exatamente pediu, qual commit corrigiu — e o cliente continua escrevendo "alguma novidade?" porque, do lado dele, nada andou. A solução não é um helpdesk melhor nem um rastreador melhor; é um único registro que vai do pedido do cliente até o código.

A corrente, elo por elo

Cada etapa é feita por uma pessoa diferente, e cada uma passa o mesmo registro para a próxima — sem copiar, sem um segundo sistema.

  1. 1
    Cliente

    Envia um e-mail para o endereço do Vi da sua organização ou preenche um formulário do portal do cliente, e recebe na hora um número de acompanhamento e um link para uma página de status. No plano Business, uma issue aberta em um repositório GitHub conectado chega da mesma forma; nesse caso, as respostas da equipe e o resultado aparecem na própria issue.

  2. 2
    Líder da equipe

    Analisa o pedido na caixa de triagem e o converte em trabalho real, escrito nas palavras da equipe: uma tarefa ou — se descrever vários problemas — um épico com as tarefas necessárias, até 20. A mensagem original do cliente fica na conversa da solicitação, em vez de ser colada em uma tarefa.

  3. 3
    Fluxo de trabalho

    A tarefa entra no seu fluxo de trabalho, é atribuída automaticamente à pessoa menos carregada com a função certa e começa a contar o SLA — exatamente como qualquer outro trabalho que sua equipe entrega.

  4. 4
    Desenvolvedor

    Escolhe a tarefa no VS Code, no Visual Studio, no RAD Studio ou no Lazarus e clica em Iniciar. Quando o trabalho está pronto, clica em Concluir: o Vi faz o commit da alteração com uma mensagem como "[#123] Título da tarefa", faz o push se o repositório tiver um remoto Git e marca a etapa dele como concluída. A tarefa avança — ainda não está encerrada.

  5. 5
    Revisor / QA

    Revisa, testa ou aprova nas próximas etapas do seu fluxo — quantas o seu processo exigir. Rejeitar devolve a tarefa com um motivo; aprovar a faz avançar.

  6. 6
    Fluxo de trabalho

    Quando a tarefa — ou, em um pedido dividido, todas as tarefas do épico — chega à etapa final do fluxo, o pedido conta como concluído. Um desenvolvedor concluir a própria etapa nunca encerra sozinho o pedido do cliente.

  7. 7
    Cliente

    Recebe um e-mail dizendo que o pedido foi resolvido, e a página de status o mostra como concluído. Uma pesquisa de satisfação de um clique vem separadamente. Se ele escrever de novo depois disso, a mensagem vai para a caixa de triagem e sua equipe decide se reabre o trabalho ou começa algo novo.

Duas visões do mesmo registro

Seu cliente e sua equipe olham para o mesmo pedido, mas cada um vê só o que é útil para si.

O que seu cliente vê

Um número de acompanhamento, um de quatro estados simples — recebida, em andamento, resolvida, encerrada —, um percentual de progresso e, em um pedido dividido, quantas partes estão prontas ("2 de 3"). No painel do cliente: as respostas que sua equipe escolheu enviar, mais as mensagens e anexos dele. Sem nomes de atendentes, sem etapas internas do fluxo, sem discussão interna.

O que sua equipe vê

A tarefa completa: etapa do fluxo, responsável, SLA, comentários internos, aprovações, tempo gasto — e, na seção Entregue da tarefa, cada commit feito para ela, com hash, branch e contagem de linhas. Um cartão de solicitação do cliente na tarefa (e no épico, em um pedido com várias tarefas) mostra o número de acompanhamento, exatamente o que o cliente está vendo agora, o resultado da satisfação e a conversa com o cliente, onde a equipe responde.

Como o pedido do cliente é ligado ao código?

O pedido do cliente é ligado ao código pela tarefa: o Commit & Close escreve o número da tarefa na mensagem do commit como [#123] e informa os metadados do commit a essa tarefa, então o pedido, a tarefa e seus commits formam uma linha rastreável. Só metadados saem da máquina do desenvolvedor — hash, mensagem, branch e contagem de linhas, mais os nomes dos arquivos se a sua organização ativar isso. O código-fonte, nunca.

E se um pedido for, na verdade, vários trabalhos?

Se um pedido for, na verdade, vários trabalhos, converta-o em um épico e liste as tarefas necessárias, ou divida depois uma tarefa existente em até 20 tarefas separadas. Cada tarefa é atribuída pelo seu fluxo normalmente, e nenhuma tarefa provisória é criada só para guardar a conversa — a conversa pertence à solicitação. O cliente continua vendo um único pedido, com o progresso mostrado como partes prontas sobre o total; ele só conta como resolvido quando todas as partes estiverem.

Para quem isto é — e para quem não é

Combina bem

Equipes de software que constroem um produto e elas mesmas dão suporte aos clientes — software houses, estúdios de produto e equipes internas em que o desenvolvedor que corrige um bug está a poucos passos do cliente que o relatou. Se os seus pedidos de suporte viram alterações de código com frequência, esta corrente elimina a maior parte do trabalho manual em torno deles.

Não é a melhor escolha

Um grande departamento de suporte independente, que resolve a maioria dos tickets sem engenharia, ou que precisa de telefone e chat ao vivo, centrais de ajuda para várias marcas ou macros em milhares de tickets por dia — uma suíte de helpdesk dedicada vai atender melhor. O Vi também não faz deploy do seu código: a corrente termina no commit, no push e na etapa final do seu fluxo.

De qual plano você precisa?

O Commit & Close e as extensões de IDE estão disponíveis em todos os planos, inclusive o Free. O lado do cliente da corrente — e-mail para tarefa com e-mail de ticket nos dois sentidos, a caixa de triagem, o portal do cliente, as páginas de status, o painel do cliente e os e-mails automáticos — faz parte do plano Business. As contas de clientes nunca ocupam vaga, e o e-mail funciona no endereço do Vi da sua organização, sem helpdesk ou serviço de e-mail externo.

Perguntas frequentes

O Concluir de um desenvolvedor avisa o cliente?

Não — o Concluir de um desenvolvedor encerra a própria etapa dele no fluxo e move a tarefa para a próxima; o cliente só é avisado quando a tarefa chega à etapa final do fluxo. Assim, o cliente ouve "resolvido" depois da revisão e dos testes, e não quando chega o primeiro commit.

O cliente pode ver commits ou código?

Não — o cliente vê apenas o status do pedido, o progresso e as respostas que sua equipe envia. Os commits aparecem dentro da tarefa para a sua equipe, e mesmo ali o Vi guarda apenas os metadados dos commits, nunca código-fonte.

Quais IDEs suportam o Commit & Close?

O Commit & Close já está disponível para VS Code, Visual Studio, RAD Studio 13 e Lazarus. Em cada uma, o desenvolvedor inicia a tarefa, clica em Concluir quando a parte dele está pronta, e o Vi faz o commit com o número da tarefa, faz o push se houver um remoto Git configurado e move a tarefa para a próxima etapa do fluxo.

Todo e-mail vira tarefa automaticamente?

Não — todo e-mail aguarda na caixa de triagem, mesmo o de alguém que já tem conta na sua organização, até que um administrador o converta em tarefa ou épico, ou o rejeite. O administrador escreve a tarefa nas palavras da equipe; o e-mail original fica na conversa da solicitação.

O que o cliente recebe, e ele precisa de uma conta?

O cliente recebe um número de acompanhamento, uma página de status que abre sem login e e-mails quando o pedido é recebido, resolvido ou encerrado — sem conta nem vaga paga. Se quiser ver todos os pedidos, responder ou anexar arquivos, ele entra no painel do cliente com um link de uso único enviado para o e-mail dele.

Qual é a diferença entre isto e a página de helpdesk do Vi?

A página de helpdesk descreve as próprias ferramentas de suporte — a caixa de entrada, a triagem, o CSAT e as respostas prontas —, enquanto esta página acompanha um pedido de ponta a ponta, pela IDE do desenvolvedor e pelas suas etapas de revisão, de volta ao cliente. As duas descrevem o mesmo produto: no Vi, um pedido de suporte é uma tarefa.

O Vi faz o deploy da correção em produção?

Não — o Vi para no commit, no push e na etapa final do seu fluxo; o deploy continua com o seu CI/CD atual. Se a publicação fizer parte do seu processo, adicione uma etapa como "Publicado" como etapa final do fluxo, para que o cliente só seja avisado depois que a correção estiver no ar.

Continue explorando: helpdesk e e-mail para tarefa · como o Commit & Close funciona · segurança do código-fonte · faça um piloto focado · planos e preços

Feche o ciclo com o seu cliente — do pedido ao código e de volta

Comece grátis em dois minutos. Sem cartão de crédito.

Comece grátis