pt
Ferramentas, Gerente de projeto
Gerente de projeto de IA: Porque é que construir agentes de IA é apenas mais um projeto de TI
Alguns meses depois de a IA generativa se ter tornado prática o suficiente para construir, algo interessante começou a acontecer no nosso lado do FlexiProject – a equipa de negócios, não a de engenharia. Sem escrever qualquer código, de repente tínhamos agentes a executar silenciosamente partes do nosso trabalho diário: preparar ofertas de clientes, preencher dados de contratos, obter Relatórios da Consola de Pesquisa, atualizar a nossa carteira de produtos após reuniões com clientes, ajudar-nos a gerir o site. Construí-los acabou por ser a parte mais fácil. O que não esperávamos era que a gestão de projectos de IA, tratando cada agente como um verdadeiro projeto de software, com um plano, um ramo partilhado, testes e um passo de entrega, seria tão importante como tudo o que os nossos engenheiros já tinham enviado. Esta é a história do que aprendemos, na ordem em que o aprendemos.
Neste artigo, vais aprender:
|
Como uma equipa empresarial começou a criar agentes de IA
Criar agentes de IA apesar de não sermos informáticos
A reviravolta interessante dos últimos dois anos é que já não precisas de uma equipa de desenvolvimento para lançar uma IA funcional. Uma pessoa de negócios que consiga descrever o que deve acontecer, e copiar alguns exemplos de entradas, pode construir um agente que faça um trabalho real. Não planeámos tornar-nos construtores. Continuámos a encontrar Atividades em que a resposta era obviamente “isto podia ser feito por um agente”, por isso começámos a construir. A primeira tarefa demorou uma tarde. A segunda demorou uma tarde. Depois começaram os problemas – não com o edifício, mas com tudo o que o rodeava.
Os agentes que criámos
A lista cresceu mais depressa do que esperávamos. Temos um agente que preenche automaticamente os dados do cliente nos nossos contratos Padrão. Um agente que prepara o primeiro rascunho das ofertas com base num resumo da conversa de vendas. Um integrador que importa a lista de projectos Excel de um cliente diretamente para o seu ambiente FlexiProject. Um assistente que nos ajuda a gerir partes do nosso sítio Web. Um agente que extrai os dados do Google Search Console para o nosso domínio e os transforma num resumo semanal legível. Um agente que, após as reuniões com os clientes, actualiza o nosso backlog de produtos com o que as empresas específicas sentem que falta, para que as ideias de funcionalidades não se percam entre uma chamada e a próxima sessão de planeamento. E dezenas de outros mais pequenos, ajudantes de uma única tarefa que alguém construiu para si próprio, continuou a melhorar e acabou por partilhar com a equipa.
Quando o mesmo agente estava a ser alargado em paralelo
A fricção não veio dos agentes que construímos uma vez e esquecemos. Vem dos agentes que realmente importavam. Duas pessoas pegavam num agente útil, cada uma com uma ideia diferente sobre como o melhorar, e começavam a alargá-lo independentemente. Uma semana depois, tínhamos duas versões: prompts diferentes, ferramentas diferentes conectadas, casos extremos diferentes capturados – e nenhuma maneira limpa de mesclá-los. Era o mesmo problema que os programadores resolveram há décadas com o Git: não podes ter duas pessoas a trabalhar a partir de um ponto de partida partilhado e a melhorá-lo em direcções diferentes sem um modelo de ramificação. Nós simplesmente não pensávamos que precisávamos de um. Os agentes eram “fáceis”. A expressão Gestão de projectos de IA ainda não tinha entrado no nosso vocabulário.
Porque é que o desenvolvimento de agentes de IA é, fundamentalmente, uma gestão de projectos de TI
Criar agentes é trivialmente fácil
A primeira lição é a mais incómoda: construir um agente é verdadeiramente fácil. Qualquer pessoa que esteja a ler isto pode abrir um modelo e ter algo a funcionar numa hora. A demonstração parecerá mágica. Os primeiros três utilizadores vão adorar. E é exatamente nesse momento que o projeto se torna difícil, porque enviar uma demonstração não é enviar uma ferramenta em que a empresa possa confiar. A diferença entre “funciona com os inputs que experimentei” e “funciona com os inputs que toda a empresa lhe dá” é enorme, e o modelo em si não faz nada para a colmatar. É para isso que serve a gestão de projectos de IA.
Uma equipa empresarial que constrói agentes de IA tem de aprender a gestão de projectos de TI
Quando uma equipa que não é de TI começa a construir software, e um agente é software, herda todos os problemas que as equipas de engenharia passaram cinquenta anos a aprender a resolver. Os requisitos têm de ser escritos. A arquitetura tem de ser desenhada. O código, os avisos ou as definições de ferramentas têm de ser partilhados. Os testes precisam de existir. As alterações têm de ser revistas antes de entrarem em funcionamento. Ignorar qualquer um destes aspectos não os faz desaparecer; apenas faz avançar o custo no tempo. A boa notícia é que o manual já existe. As disciplinas que fazem com que os projectos de TI sejam bem sucedidos aplicam-se sem alterações quando uma equipa empresarial constrói agentes. O único ingrediente novo é a avaliação – a versão específica de testes da IA.
Experimenta o FlexiProject!
O ciclo de vida do projeto do agente de IA
1. Análise inicial – que problema estamos realmente a resolver?
Todos os agentes que vale a pena construir começam com uma fase de análise que não tem nada a ver com IA. Quem é que vai utilizar isto? O que é que eles fazem hoje, passo a passo? Qual desses passos é realmente prejudicial? O que significa “bem feito” – de forma mensurável? Antes de criarmos o agente de preparação de ofertas, escrevemos a sequência manual exacta que a equipa de vendas seguia, assinalámos os passos que eram repetitivos e os que exigiam discernimento, e só depois decidimos o que o agente devia ou não fazer. A análise demorou mais tempo do que a construção. Este rácio é normal.
2. Planeamento – âmbito, integrações, sucursal partilhada
O planeamento é onde decides três coisas: entradas e saídas, as integrações que o agente irá tocar e, mais importante, onde o trabalho reside. Se duas pessoas vão contribuir, elas precisam de uma definição compartilhada de “principal”. Pode ser um único documento com os prompts canónicos e definições de ferramentas, um repositório, uma pasta de competências – o formato importa menos do que o acordo. Escolhe-o no primeiro dia. Decide o que o agente não fará, escreve-o e mantém-no; o scope creep é a razão mais comum pela qual os agentes se tornam impossíveis de manter.
3. Desenvolvimento – a parte enganosamente fácil
A construção em si é rápida. Essa é a armadilha. Escreves os teus prompts, ligas as tuas ferramentas, executas alguns exemplos e sentes-te 80% feito. Estás mais para 30%. Os restantes 70% são tudo o que ainda não testaste: os inputs estranhos, os inputs longos, os inputs noutra língua, os casos em que uma ferramenta devolve um resultado vazio, os casos em que o utilizador muda de ideias a meio da conversa. Nada disto é visível a partir do interior da construção.
4. Testar – e depois voltar a testar
É aqui que os agentes diferem mais do software clássico e é aqui que a maioria das equipas corta caminho. Um agente passa num teste hoje e pode falhar no mesmo teste amanhã porque alteraste uma única linha no prompt ou porque o modelo subjacente foi atualizado. A disciplina de que precisas é a avaliação de regressão: um conjunto guardado de entradas com comportamentos esperados, executado automaticamente, ou pelo menos sistematicamente, após cada alteração. Sem isto, só ficas a saber das regressões quando um utilizador tropeça nelas.
5. Entrega e transferência
Um agente que nunca é oficialmente entregue é um agente que se torna legado no primeiro dia. A entrega significa escrever a documentação voltada para o usuário, definir o que é sucesso na produção e configurar uma maneira de monitorar se o agente ainda é útil três meses depois. Aprendemos isto da forma mais lenta – vê a próxima secção.
MVP, Agile e Scrum em projectos de IA
MVP primeiro – começa com o agente útil mais pequeno
Cada agente que construímos e que teve sucesso começou como a versão mais pequena e útil de si mesmo. Uma Atividades. Uma entrada. Uma saída. Resistimos à tentação de acrescentar o segundo caso de utilização até vermos o primeiro sobreviver ao contacto com utilizadores reais. Os agentes que tiveram dificuldades foram o oposto: ambiciosos desde o primeiro dia, com três capacidades, nenhuma das quais funcionou até ao fim. Os agentes “big-bang” falham exatamente pelas mesmas razões que os projectos de software “big-bang” falham; o fator de forma não altera a matemática. Se retiras apenas uma regra deste artigo, retira esta: um MVP para um agente de IA é suficientemente pequeno para que uma pessoa o possa descrever em três frases e executá-lo de ponta a ponta num exemplo real ao fim de um dia. Depois disso, tudo é iteração.
Porque é que o Agile se adapta naturalmente aos agentes de IA
Os agentes são invulgarmente bem adaptados ao trabalho ágil porque são invulgarmente imprevisíveis. Não é possível especificar totalmente um agente à partida, da mesma forma que se especifica um formulário de pagamento ou um relatório. Faz-se uma pequena versão, observa-se o seu funcionamento no mundo real, vê-se onde falha e corrige-se a próxima coisa. Tentar conceber o agente perfeito no papel antes de o construir é a forma mais rápida de construir o agente errado. A iteração não é uma preferência do Gerente de projeto para a IA; é um requisito estrutural – o mesmo ritmo de Planejar, Fazer, Verificar, Agir que Deming descreveu décadas atrás para qualquer processo que precisa ser melhorado continuamente, apenas aplicado a agentes cujo comportamento não pode ser totalmente previsto.
Executa o trabalho do agente em sprints Scrum
Tratamos cada agente importante como um pequeno fluxo de trabalho ao estilo Scrum. Há uma lista de capacidades que o agente pode ter. Cada sprint escolhe um pequeno número delas. A demonstração do sprint é o próprio agente, executado com dados reais da equipa que o vai utilizar. Se a demonstração não for convincente, o trabalho continua; a cadência força uma conversa real entre o construtor e os utilizadores, em vez de uma construção silenciosa que dura meses.
Erros que cometemos
Construir antes de analisar
Como a construção é tão rápida, parece eficiente saltar diretamente para ela. Mas não é. Os agentes que construímos sem uma análise clara acabaram por funcionar tecnicamente, mas resolveram o problema errado; a equipa que os utilizou foi educada durante algum tempo e depois voltou a fazer o trabalho manualmente. Uma tarde de análise teria poupado uma semana de construção.
Confia no modelo para o resolver
Este foi o nosso erro mais consistente e o mais difícil de desaprender. Partimos do princípio de que se déssemos ao modelo a tarefa em linguagem simples, ele conceberia uma boa solução. Muitas vezes não o fazia – não porque o modelo fosse fraco, mas porque nós próprios não tínhamos feito o trabalho de conceção. O modelo não tem uma visão do contexto da tua empresa, dos dados existentes, das convenções não escritas, do sistema que rodeia a tarefa. Quanto mais disso lhe deres, uma análise real, uma arquitetura real, a estrutura que queres que siga, melhor será o resultado. O modelo é excelente na execução. Não é o teu arquiteto.
Faz um big-bang em vez de começar com um MVP
Sempre que tentámos lançar um agente com todas as funcionalidades no primeiro dia, o resultado demorou mais tempo a construir, foi mais difícil de depurar e foi abandonado com mais frequência do que as versões pequenas que tínhamos desenvolvido deliberadamente. O big-bang parecia mais rápido. Mas não era.
Duas pessoas a desenvolver o mesmo agente em paralelo
Este foi o momento Git. Duas pessoas, o mesmo agente, ideias diferentes, ramos diferentes nas suas cabeças, nenhum “principal” partilhado. Uma semana depois, duas versões que não se conciliavam. Agora tratamos cada agente significativo da mesma forma que os programadores tratam o código: uma versão canónica, um modelo de ramificação explícito quando mais do que uma pessoa trabalha nele e um passo de fusão explícito. Ou, se as ideias divergirem verdadeiramente, uma decisão deliberada de dividir em dois agentes separados em vez de fingir que são um só.
Sem documentação inicial – os utilizadores não sabiam o que o agente fazia
Os primeiros utilizadores internos das nossas competências faziam sempre as mesmas perguntas: o que é que esta coisa faz, o que é que tenho de introduzir, como é o resultado, quando é que a devo utilizar em comparação com a versão anterior. Pensámos que o agente era auto-explicativo. Mas não era. Agora escrevemos uma breve descrição para o utilizador de cada agente no momento da entrega – o que faz, o que deve ser introduzido, o que esperar e o que não faz. Custa dez minutos e evita semanas de utilização confusa.
Experimenta o FlexiProject!
Perguntas frequentes sobre a gestão de projectos de IA
A gestão de projectos de IA é diferente da gestão de projectos de TI normal?
As disciplinas são as mesmas – análise, planeamento, construção, teste, entrega, iteração. As diferenças estão nas fases de construção e teste: os resultados são não-determinísticos, o comportamento pode variar quando o modelo ou as solicitações mudam e o “teste” torna-se “avaliação em relação a um conjunto de casos guardados”. Tudo à volta destas fases parece um projeto normal de TI.
Preciso de uma ferramenta de gestão de projectos para gerir o desenvolvimento de agentes de IA?
Precisas de um local onde cada agente viva como um projeto: com um plano, uma versão atual, um proprietário e um estado de entrega. O facto de esse local ser um sistema de gestão de projectos, um wiki ou uma estrutura de pastas é menos importante do que ter um. Para equipas que executam muitos agentes em paralelo, um verdadeiro sistema de PM paga-se rapidamente.
Qual deve ser o tamanho de um agente MVP?
Suficientemente pequeno para que uma pessoa o possa descrever em três frases e executá-lo de ponta a ponta num exemplo real ao fim de um dia. Se não conseguires, o âmbito é demasiado grande e o MVP é algo mais restrito dentro dele.
Como é que impedes que duas pessoas construam o mesmo agente em paralelo?
Não impedes que duas pessoas contribuam – tornas explícito onde reside a versão canónica, a quem pertence a fusão e quando ideias divergentes devem tornar-se uma bifurcação deliberada em dois agentes separados. A lição da engenharia de software aplica-se um a um: um ramo partilhado, com um processo de fusão acordado.
Quando é que um agente se torna legado?
No momento em que ninguém é responsável por avaliar se ainda ajuda. Um agente que ninguém verifica degrada-se silenciosamente, o mundo à sua volta muda, as entradas evoluem, o modelo subjacente é substituído e um dia está errado e ninguém repara. O legado não é uma idade, é um estado de negligência.
Conclusão
A parte emocionante da construção de agentes de IA, o modelo, os avisos, o momento em que uma demonstração funciona pela primeira vez, é a menor fração do trabalho. As partes menos excitantes são as que transformam uma demonstração numa ferramenta em que toda a empresa pode confiar: uma análise clara, um plano real, um ramo partilhado, testes de regressão, documentação e um ritmo de iteração que mantém o agente útil muito depois de a primeira versão ter sido enviada. Nada disto é exótico. É exatamente a disciplina que tem feito com que os projectos de TI tenham sucesso durante décadas, aplicada sem diluição a um tipo de software ligeiramente mais recente. As equipas que adoptam essa disciplina cedo acabam por ter agentes em que confiam. As equipas que a ignoram acabam por reconstruir o mesmo agente duas vezes. Tratar cada agente como um projeto real, com um plano que podes definir, revisitar e melhorar, é o que a gestão de projectos de IA significa na prática. Fazemos isso no FlexiProject, onde cada agente tem o seu próprio registo de projeto com um plano de ação claramente escrito; seja qual for o sistema que escolheres, trata cada agente como um projeto, não como uma experiência.
AUTOR
Dominik Wrzosek
General Manager at FlexiProject
![O que é um diagrama de Gantt e como criá-lo? [EXEMPLO]](https://flexi-project.com/wp-content/uploads/2024/04/What-is-Gantt-chart-e1714048900401.png)
