Diretora de Produto sénior afirma que as equipas de entrega devem concentrar-se no atrito em vez de perseguirem a automatização

No que diz respeito à entrega de projetos, foco-me em definir o que desenvolvemos e porquê, alinhar as equipas quanto às prioridades e garantir que entregamos de forma fiável e rápida. Isso significa trabalhar em estreita colaboração com a engenharia na execução, mantendo simultaneamente uma atenção constante ao impacto no cliente, à qualidade e à melhoria contínua.

You should also read

• Os fluxos de trabalho de IA do mundo real utilizados pelo Diretor de Entregas de uma agência de implementação do Asana

• Gestor de Projetos e Educador com IA Partilha um Fluxo de Trabalho Simples com IA que Altera Fundamentalmente a Forma como os Projetos Funcionam

Por que motivo a IA transforma a entrega de projetos de reativa em estratégica

A IA transformou profundamente tanto a minha função como a entrega diária de projetos. Antes, a entrega dependia da coordenação manual, da depuração reativa e da análise humana. Atualmente, com a IA integrada nos nossos fluxos de trabalho, o trabalho tornou-se mais estratégico.

Em que passo agora menos tempo:

• Triagem e depuração manuais: anteriormente, identificar as causas dos erros exigia várias trocas entre as equipas. Agora, os sistemas de IA conseguem detetar, classificar e até sugerir correções automaticamente. Isto reduziu significativamente o esforço inicial.
• Escrever especificações detalhadas para todos os casos extremos: em vez de documentarmos exaustivamente tudo à partida, recorremos mais à exploração assistida por IA, a simulações e a iterações rápidas para aperfeiçoar as soluções.
• Acompanhar o estado e coordenar tarefas: o acompanhamento do progresso, a elaboração de resumos e os relatórios estão agora automatizados, reduzindo a necessidade de acompanhamentos constantes.

Saloni partilha

A minha função evoluiu: passei de gerir de perto a execução para definir a forma como os sistemas inteligentes executam tarefas em nosso nome.

Aquilo a que dedico agora mais atenção:

• Definir os problemas e os sinais certos: como a IA consegue agir rapidamente, a qualidade dos dados de entrada é muito mais importante. Dedico mais tempo a pensar no que devemos monitorizar, que sinais são relevantes e como os sistemas devem responder.
• Conceber fluxos de trabalho assistidos por IA: em vez de nos concentrarmos apenas nas funcionalidades, estamos a conceber fluxos de ponta a ponta nos quais os agentes de IA detetam problemas, executam ações e, por vezes, até os resolvem. Esta mudança de ferramentas para sistemas representa agora uma parte significativa da minha função.
• Qualidade e confiança: quando a IA toma ou sugere decisões, garantir a fiabilidade, a explicabilidade e a confiança dos utilizadores torna-se fundamental. Dedico mais tempo a validar os resultados e a definir salvaguardas.
• Rapidez com responsabilidade: estamos a entregar mais depressa do que antes, mas as expectativas também são mais elevadas. Não se trata apenas de avançar rapidamente, mas de fazê-lo sem regressões. Este equilíbrio exige um pensamento de produto mais rigoroso.

De forma geral, eis o que mudou na entrega de projetos: passámos de um modelo reativo orientado por pessoas para um modelo proativo mais apoiado pela IA. Detetamos os problemas mais cedo, os ciclos de resolução são mais curtos e as equipas passam menos tempo a apagar fogos e mais tempo a melhorar o próprio sistema.

Assim, a minha função evoluiu: passei de gerir de perto a execução para definir a forma como os sistemas inteligentes executam tarefas em nosso nome.

Como a IA transforma a triagem de incidentes

Não tentámos automatizar tudo. Em vez disso, concentrámo-nos em áreas frequentes e cognitivamente repetitivas que atrasavam os engenheiros. A triagem de incidentes e a análise da causa-raiz (RCA) eram uma dessas áreas, porque acontecem diariamente, têm um custo elevado em termos de tempo e assentam fortemente em padrões.

A configuração dos nossos agentes inclui um agente de Sinais, que deteta anomalias a partir da telemetria; um agente de Contexto, que recolhe registos, rastreios e execuções relacionadas; um agente de RCA, que gera a causa-raiz e as respetivas evidências; e um agente de Ação, que cria um pedido com todo o contexto. Este foi o ponto de partida mais fácil, porque o sucesso é mensurável através do MTTR.

Isso levou-nos a construir um motor de RCA sobre a nossa camada de observabilidade.

Como os sistemas orientados por IA resolvem a complexidade em casos reais

Construímos um motor de RCA para reduzir o MTTR, mas a verdadeira mudança foi passar da investigação manual para o diagnóstico orientado pelo sistema. O problema era que, quando surgia um erro, os registos estavam dispersos por vários serviços, os engenheiros tinham de reconstruir manualmente o fluxo e a análise da causa raiz dependia muito da experiência individual. Mesmo no caso de problemas conhecidos, o MTTR era inconsistente porque o processo não era repetível.

Como solução, construímos um motor de RCA que funciona sobre a nossa camada de observabilidade e faz automaticamente três coisas:

Interligação do contexto

• Obtém registos, métricas e rastreios de execução de vários serviços
• Reconstrói o percurso exato da falha (passo a passo dentro de um lote ou fluxo)

Correspondência de padrões + deteção de semelhanças

• Compara o problema com incidentes históricos
• Utiliza representações vetoriais para identificar incidentes semelhantes que ocorreram anteriormente

Sugestão da causa raiz assistida por IA

• Classifica o problema (problema de dados, problema de configuração, regressão de código, infraestrutura)
• Sugere a causa raiz mais provável
• Apresenta evidências de suporte, não apenas uma resposta

Porque o impacto da IA depende da qualidade do sistema

No início, partimos do princípio de que uma camada de LLM melhoraria diretamente os resultados. Não foi isso que aconteceu. As primeiras versões ficaram aquém das expectativas. O que aprendemos rapidamente foi que a IA não corrige sistemas desorganizados. Amplifica-os. E aprendemos que a qualidade dos dados é mais importante do que a qualidade do modelo.

Passámos muito tempo a corrigir registos inconsistentes, contexto em falta entre serviços e sinais mal definidos. Assim que os dados subjacentes se tornaram estruturados e fiáveis, até configurações simples de IA funcionaram bem.

A confiança é tão importante como a precisão. Mesmo quando o motor de RCA ou o sistema de triagem se revelava tecnicamente correto, os engenheiros não o utilizavam. Porquê? Porque não explicava as suas conclusões.

No início, partimos do princípio de que uma camada de LLM melhoraria diretamente os resultados. Não foi isso que aconteceu. A IA não corrige sistemas desorganizados. Amplifica-os. A qualidade dos dados é mais importante do que a qualidade do modelo.

Share This Quote on:

• Share on Twitter
• Share on LinkedIn
• Share on Facebook

Saloni MalhotraOpens new window

Gestora de Produto Sénior, equipa de R&D da o9 Solutions

As pessoas não precisam de uma IA perfeita. Precisam de uma IA compreensível. O verdadeiro ganho não é a velocidade — é o foco. Achávamos que a IA nos tornaria simplesmente mais rápidos. Mas os engenheiros não estavam apenas a fechar pedidos mais depressa. Começavam a perguntar: “Porque existe sequer esta classe de problemas?” É um nível de pensamento diferente. O específico e delimitado supera o ambicioso e abrangente. O nosso primeiro impulso foi construir um sistema amplo e inteligente. Falhou. A adoção da IA não aconteceu de uma só vez. Foi uma série de pequenas vitórias decisivas.

Só observámos uma mudança quando associámos evidências (registos, rastreios, comparações) e mostrámos por que razão o sistema chegara a uma conclusão específica. Como resultado, passámos menos tempo em investigações repetitivas e mais tempo a melhorar o sistema ao nível global. Depois, obtivemos resultados positivos ao escolher casos de utilização específicos (como RCA para falhas em lotes), resolvê-los em profundidade e expandir gradualmente.

Como as ferramentas de IA melhoram a eficiência da entrega de projetos

Eis a nossa pilha tecnológica.

Camada de IA e inteligência:

• LLM (modelos da classe GPT) — RCA, sumarização, classificação
• Representações vetoriais + base de dados vetorial (FAISS / Pinecone) — pesquisa de semelhanças, recuperação de incidentes
• Processos RAG — fundamentação dos resultados da IA em registos e dados históricos
• Deteção de anomalias (regras + ML) — deteção de padrões de falha

Observabilidade e dados:

• Registo e monitorização (Elastic / Datadog / OpenTelemetry)
• Sistemas de rastreio distribuído
• Pipeline de dados (Python, processamento de fluxos/lotes)
• Camadas de armazenamento de telemetria e engenharia de funcionalidades

Entrega e fluxo de trabalho:

• CI/CD (GitHub Actions / Jenkins)
• Acompanhamento de problemas (Jira ou semelhante)
• Estruturas de validação de versões / simulação

Produtividade dos programadores:

• Assistentes de programação (GitHub Copilot ou semelhante)
• Copilotos internos de IA para depuração e consulta de sistemas

De um modo geral, a evolução dos últimos 6-12 meses foi:

• De painéis de controlo → informações com assistência de IA
• De triagem manual → RCA automatizada
• De ferramentas isoladas → pipelines ligados
• De depuração reativa → deteção proativa

Como o Claude e o Figma aumentam a produtividade da equipa

Combinar o Claude com o Figma tem tido um impacto surpreendentemente elevado para nós. Antes, utilizávamos um fluxo semelhante a este: o PM escrevia um PRD, o designer interpretava-o e seguiam-se vários ciclos de avanços e recuos.

Agora, introduzimos ideias preliminares, fluxos ou até notas desorganizadas no Claude e pedimos-lhe que estruture os fluxos, sugira casos-limite e desenvolva o raciocínio ao nível dos ecrãs.

Depois, traduzimos isso diretamente para o Figma, onde criamos wireframes muito mais rapidamente, exploramos variações com agilidade e pensamos no microtexto e nos estados.

Porque é que os sistemas leves substituem a gestão de projetos tradicional

Os sistemas tradicionais funcionavam, mas eram lentos a adaptar-se, tinham custos elevados de coordenação e estavam frequentemente desligados do que acontecia no sistema. O que era considerado “tradicional”: PRDs detalhados elaborados antecipadamente (muitas vezes desatualizados ao fim de algumas semanas), planos de sprint fixos com âmbito rígido, acompanhamento manual do estado (reuniões diárias, relatórios, painéis de controlo) e ferramentas separadas para o planeamento, a execução e a monitorização.

Agora, passámos de PRDs extensos para especificações modulares e contexto em tempo real. Com esta nova abordagem, podemos dividir as coisas em: definição do problema, fluxos principais e restrições. Também podemos armazená-las em formatos leves (documentos + tickets) e utilizar LLMs para desenvolver casos-limite e gerar cenários de teste.

Agora passamos muito menos tempo a escrever documentos exaustivos (PRDs de 10–15 páginas no Confluence). Em vez disso, temos um input estruturado de 1 página com o problema, o fluxo do utilizador e as restrições.

Para fazer isto, utilizámos as seguintes ferramentas:

• Confluence (utilização reduzida)
• Jira (fonte principal de referência)
• Camada LLM (modelos da classe GPT através de API)
• Figma
• Claude (para estruturação de fluxos)

Este é o nosso processo:

• Input estruturado de 1 página:
  • Problema
  • Fluxo do utilizador
  • Restrições
• Introduzimo-lo no Claude / LLM para:
  • Desenvolver os fluxos
  • Gerar casos-limite
  • Elaborar critérios de aceitação
• Convertemo-lo diretamente em tickets do Jira + wireframes do Figma

O impacto é o seguinte:

• Redução de aproximadamente 40–50% no tempo entre a ideia → primeira versão
• Menos ciclos de avanços e recuos entre PM, design e engenharia
• Primeira versão das funcionalidades muito mais clara

Como a integração da IA altera os rituais de entrega

Além disso, definir o âmbito passou de exaustivo a direcional. Antes, tentávamos definir tudo antecipadamente e abranger todos os casos-limite nos PRD. Agora, definimos o problema, os fluxos principais e as restrições. Depois, utilizamos a IA para expandir os casos-limite, simular cenários e destacar lacunas. O âmbito já não diz respeito à completude no primeiro dia; trata-se de estabelecer uma direção sólida e permitir um ciclo de aperfeiçoamento rápido.

Daqui a cinco anos, os planos já não serão “escritos” — serão gerados continuamente. Penso que os planos serão sistemas dinâmicos, não documentos. A IA atualizará continuamente as prioridades, os riscos e os prazos com base na execução em tempo real, nos sinais dos clientes e no estado do sistema. O planeamento será dinâmico e estará sempre atualizado, não sendo um exercício periódico.

A Saloni partilha

A IA funciona melhor quando elimina um problema real e diário, não quando é adicionada como uma camada.

Porque é essencial resolver os pontos de fricção antes da adoção da IA

Não comece pela IA. Comece pela fricção.

É tentador perguntar: “Onde podemos utilizar a IA?” Normalmente, esse é o ponto de partida errado. Em vez disso, pergunte: Onde estão as equipas a desperdiçar tempo repetidamente? Onde depende o trabalho demasiado de algumas pessoas? Onde abranda tudo sob pressão? Escolha um desses pontos e resolva-o de forma aprofundada.

A IA funciona melhor quando elimina um problema real e diário, não quando é adicionada como uma camada.

Acompanhe

Pode acompanhar o trabalho da Saloni no LinkedIn.

Em breve, publicaremos mais entrevistas com especialistas no The Digital Project Manager!