Quando um ticket de suporte requer trabalho de desenvolvimento, o Azure DevOps pode cuidar do que ocorre no lado do desenvolvimento. O desafio é manter esse trabalho conectado à central de atendimento, onde a solicitação original, a comunicação com o usuário e o ciclo de vida do ticket ainda estão registrados.
Uma integração útil entre ITSM e o Azure DevOps precisa ir além da simples criação de um item de trabalho a partir de um ticket. As equipes de suporte precisam de visibilidade sobre o andamento do desenvolvimento, os desenvolvedores precisam do contexto adequado para trabalhar na questão, e as atualizações precisam circular entre os dois sistemas sem gerar trabalho extra.
Isso também levanta uma questão prática: o que o Azure DevOps deve gerenciar e o que deve permanecer na plataforma ITSM?
Este guia explica o que procurar em uma integração com o Azure DevOps, quais recursos são importantes para as equipes de suporte e desenvolvimento e como configurar a conexão para que ambos os sistemas trabalhem juntos sem duplicar o trabalho.
O que o Azure DevOps abrange e onde começa a lacuna
O Azure DevOps é a plataforma da Microsoft para planejar, construir, testar e entregar software. Seus cinco serviços principais abrangem diferentes partes do ciclo de vida do desenvolvimento: Azure Boards para acompanhamento de tarefas, Azure Repos para controle de código-fonte, Azure Pipelines para CI/CD, Azure Test Plans para testes e Azure Artifacts para gerenciamento de pacotes.
Para equipes de desenvolvimento, o Azure Boards é a parte que mais se aproxima do ITSM. As equipes usam itens de trabalho para rastrear Epics, Features, User Stories, Tasks e Bugs, organizá-los em backlogs e sprints, e movê-los pelos quadros Kanban. Um item de trabalho pode conter o contexto técnico que os desenvolvedores precisam para investigar e entregar uma correção, incluindo sua descrição, status, responsável, código relacionado e builds.
É nessa sobreposição que a distinção pode ficar confusa. Um bug no Azure Boards pode representar um problema relatado por um usuário, e uma equipe de desenvolvimento pode usar um item de trabalho para acompanhar a correção. Uma alteração implementada por meio de um pipeline também pode fazer parte de um processo mais amplo de mudança de TI. O Azure DevOps pode, portanto, dar suporte a partes de um fluxo de trabalho de ITSM quando o trabalho chega à equipe de desenvolvimento.
A diferença está no que acontece antes e em torno desse trabalho de desenvolvimento. O Azure DevOps foi desenvolvido com foco na entrega de software, não no Gerenciamento de Serviços de TI para os funcionários e clientes de uma organização. Ele não oferece os recursos de central de atendimento necessários para receber e gerenciar solicitações de usuários, como um catálogo de serviços, um portal de autoatendimento, fluxos de trabalho de incidentes e solicitações específicos do ITSM, SLAs de suporte ou uma base de conhecimento voltada para os funcionários.
Portanto, a questão não é que o Azure DevOps não consiga rastrear um incidente, uma solicitação ou uma mudança. Ele consegue rastrear o trabalho de desenvolvimento associado a cada um deles. A lacuna surge quando é preciso gerenciar o próprio processo de serviço: um usuário relata uma interrupção, a equipe de suporte avalia seu impacto, a solicitação é priorizada em relação aos compromissos de serviço, a equipe certa é designada, os usuários recebem atualizações e a correção final é vinculada de volta ao ticket original.
Na prática, o Azure DevOps responde a uma pergunta como “O que a equipe de desenvolvimento precisa criar ou corrigir?”. Uma plataforma de ITSM responde “O que o usuário precisa, quem é o responsável pelo problema do serviço e como gerenciamos isso até a resolução?”.
Essa distinção é o que torna uma integração útil. O Azure DevOps pode continuar sendo o sistema onde os desenvolvedores gerenciam seu trabalho, enquanto a plataforma ITSM permanece como o sistema onde as equipes de suporte gerenciam a experiência do serviço.
Como funciona a integração entre tickets e work items no service desk
Esse tipo de integração ITSM preenche a lacuna ao criar um link direto entre uma solicitação de suporte e o item de trabalho que acompanha sua correção. A ideia é simples: de dentro de um ticket, um agente anexa o item de trabalho relevante do Azure DevOps, e o ticket então exibe detalhes importantes desse item de trabalho, normalmente seu ID, seu título e seu status atual, extraídos em tempo real do Azure DevOps.
Alguns pontos de projeto definem como essas integrações se comportam na prática:
- Uma referência somente leitura. As integrações do tipo “vincular e visualizar” trazem os dados do item de trabalho para o ticket a fim de proporcionar visibilidade. Elas não enviam as alterações do ticket de volta para o Azure DevOps, de modo que o backlog de desenvolvimento permanece sob o controle da equipe de desenvolvimento.
- Não é necessária licença de desenvolvedor para visualização. Os agentes de suporte leem o status do item de trabalho vinculado diretamente na ferramenta de ITSM. Eles não precisam, individualmente, de uma licença do Azure DevOps para se manterem informados.
- Controles de escopo e permissão. Integrações bem construídas permitem que você decida quais tipos de solicitações podem ser vinculadas a itens de trabalho e quais funções podem criar ou visualizar esses links, mantendo os dados de desenvolvimento visíveis apenas onde devem estar.
O resultado é um ciclo fechado. Quando um desenvolvedor avança um item de trabalho, o ticket vinculado reflete essa mudança. O agente responde ao usuário com informações atualizadas, e a conexão entre o problema relatado e o trabalho em andamento permanece intacta desde a abertura até a resolução.
Conecte os dois mundos com o InvGate Service Management
O InvGate Service Management inclui uma integração nativa com o Azure DevOps que coloca o contexto de desenvolvimento diretamente dentro da sua central de atendimento. Depois de configurada, os agentes autorizados vinculam os itens de trabalho do Azure DevOps (os recursos, requisitos, bugs e problemas de desenvolvimento que seus engenheiros acompanham) às solicitações do InvGate Service Management.
Veja o que isso oferece na solicitação:
- Status em tempo real, ID e título do item de trabalho vinculado, lidos diretamente do Azure DevOps, para que o ticket sempre reflita o estado atual da correção.
- Um título que direciona para o Azure DevOps ou abre a visualização completa dos detalhes dentro do InvGate Service Management para usuários com permissão.
- Não é necessária licença do Azure DevOps para que os agentes visualizem um item de trabalho vinculado.
- Vinculação restrita por categoria, de modo que os itens de trabalho sejam anexados apenas a partir das categorias do catálogo de serviços que você habilitar.
- Permissões baseadas em funções que controlam quem pode vincular itens de trabalho e quem pode visualizar seus detalhes.
- Uma conexão somente leitura, do tipo “vincular e visualizar”, e não uma sincronização bidirecional, para que seu backlog de desenvolvimento permaneça sob o controle da equipe de desenvolvimento.
Vincular itens de trabalho a solicitações é apenas uma das opções. O Azure DevOps também está disponível como um conector de ação integrado no construtor de fluxos de trabalho sem código do InvGate Service Management, permitindo que os administradores importem dados de desenvolvimento em tempo real para um processo sem código personalizado, usando ações como “obter um item de trabalho”, “listar projetos”, “listar compilações”, “listar repositórios” e muito mais. Por exemplo:
- Um processo de habilitação de mudança para um lançamento de software pode exibir o status de um item de trabalho relacionado ou as compilações mais recentes na fase de revisão.
- Um registro de Gerenciamento de Problemas vinculado a um defeito de código pode importar o item de trabalho que acompanha a correção.
A configuração é simples:
- Gere um token de acesso pessoal no Azure DevOps com permissão de leitura para itens de trabalho e Graph.
- Adicione e configure a integração no InvGate Service Management em Configurações > Integrações > Aplicativos — nomeie-a, escolha as categorias do catálogo de serviços, cole o token e defina as funções que podem vincular e visualizar itens de trabalho.
Mantendo o desenvolvimento e o suporte conectados
Uma boa integração entre o Azure DevOps e o ITSM vai além da simples transferência de tickets para outro sistema. Ela deve facilitar o gerenciamento da transferência entre o suporte e o desenvolvimento, sem criar um segundo processo para nenhuma das equipes.
Algumas práticas fazem a diferença:
- Mantenha cada sistema como a fonte de seu próprio trabalho. O Azure DevOps continua sendo o sistema de registro para o desenvolvimento; a plataforma ITSM continua sendo o sistema de registro para a solicitação de serviço e sua relação com o usuário.
- Defina o encerramento separadamente. Um item de trabalho encerrado não deve fechar automaticamente o ticket, o suporte ainda pode precisar validar a correção, atualizar o usuário ou concluir a solicitação.
- Automatize as transferências com regras claras. Criar itens de trabalho, transmitir contexto e sincronizar atualizações de status são bons candidatos para automação, uma vez que as regras estejam bem definidas.
O objetivo não é fazer com que o Azure DevOps e sua plataforma de ITSM funcionem como se fossem a mesma ferramenta. É proporcionar a cada equipe o sistema desenvolvido para seu trabalho e manter as informações que as conectam disponíveis onde forem necessárias.
Quando essa conexão é bem projetada, um problema de desenvolvimento não desaparece no backlog depois que um agente o escala. O ticket, o item de trabalho, as equipes que trabalham neles e o usuário que aguarda uma resolução permanecem parte do mesmo fio condutor.
