Close Menu
Código Simples .NETCódigo Simples .NET
    Facebook X (Twitter) Instagram
    Trending
    • Por que projetos ainda travam entre equipes, mesmo quando todos produzem mais rápido com IA
    • A IA reduziu o custo de produzir. Não reduziu o custo de alinhar
    • Noisy neighbor: por que multi-tenant não significa simplesmente compartilhar infraestrutura
    • Autoscaling pode ampliar o incidente: por que escalar uma camada não aumenta a capacidade do sistema inteiro
    • Observabilidade de IA com OpenTelemetry: o que realmente deveria aparecer no trace?
    • Rate limiting não é só proteção contra abuso. É contrato de capacidade
    • Feature flag não é interruptor. É dívida operacional com prazo de validade
    • O modelo é infraestrutura: por que LLM deveria ser adapter, não o centro da sua arquitetura
    Facebook X (Twitter) Instagram
    Código Simples .NETCódigo Simples .NET
    Código Simples .NETCódigo Simples .NET
    Home»Boas práticas»Gestão & Produtividade»Por que projetos ainda travam entre equipes, mesmo quando todos produzem mais rápido com IA

    Por que projetos ainda travam entre equipes, mesmo quando todos produzem mais rápido com IA

    Jhonathan SoaresBy Jhonathan Soares11 de setembro de 202619 Mins Read Gestão & Produtividade
    Share
    Facebook Twitter LinkedIn WhatsApp Copy Link

    Há uma situação que provavelmente se tornará cada vez mais comum nas organizações que adotam inteligência artificial em escala. Quando observamos cada equipe isoladamente, quase todas parecem ter ficado mais rápidas. Produto consegue estruturar análises em menos tempo, tecnologia encurta parte do ciclo de implementação, arquitetura compara alternativas com mais facilidade, dados acelera investigações e lideranças conseguem processar volumes maiores de informação antes de uma decisão.

    Mesmo assim, quando medimos o intervalo entre uma iniciativa surgir e produzir algum resultado concreto, o ganho pode ser surpreendentemente pequeno.

    Não há necessariamente uma contradição nisso. Um projeto complexo não é simplesmente a soma do tempo que cada equipe leva para executar sua parte. Ele também incorpora os períodos de espera entre essas partes, as dependências que precisam ser negociadas, a capacidade de áreas compartilhadas e as decisões que alguém precisa tomar antes que o trabalho possa continuar.

    É justamente nesse ponto que produtividade local e velocidade organizacional começam a se separar.

    A inteligência artificial está melhorando rapidamente o desempenho dentro de vários componentes da organização. Isso não significa que tenha redesenhado as interfaces entre eles.

    Quando todos ficam mais rápidos, o projeto não fica necessariamente mais rápido

    Considere uma iniciativa relativamente comum que envolva Produto, Tecnologia, Arquitetura, Dados, Segurança e Operações. Nenhuma dessas áreas precisa estar trabalhando de maneira ineficiente para que o projeto seja lento.

    Produto encerra sua análise na segunda-feira e precisa de uma avaliação técnica antes de assumir determinado compromisso. Tecnologia conclui uma primeira alternativa rapidamente, mas descobre uma dependência de plataforma. A equipe responsável pela plataforma só consegue olhar o assunto na semana seguinte porque já está comprometida com outras iniciativas. Durante essa análise surge uma restrição de segurança que exige uma alteração no desenho original. A mudança afeta parte da jornada e a discussão retorna para Produto.

    Talvez ninguém tenha levado mais do que algumas horas ou dias para executar sua parte. Mesmo assim, várias semanas se passaram.

    Isso acontece porque uma parcela relevante do lead time não estava no trabalho propriamente dito. Estava nos intervalos entre trabalhos.

    Podemos pensar em um exemplo simplificado. Imagine um projeto que historicamente demorava trinta dias, sendo quinze dedicados à produção efetiva e outros quinze distribuídos entre espera, aprovações e dependências. Se a IA reduzir pela metade o tempo de produção, o projeto passa de trinta para 22,5 dias. O trabalho diretamente afetado ficou duas vezes mais rápido, mas o fluxo completo melhorou apenas 25%.

    Se continuarmos otimizando apenas a produção, em algum momento encontraremos um limite. Quando quase todo o tempo restante estiver nas dependências, tornar a execução ainda mais rápida produzirá retornos cada vez menores.

    Para quem trabalha com arquitetura, a lógica é conhecida: depois que um componente deixa de ser o gargalo, continuar otimizando aquele componente não aumenta significativamente o throughput do sistema.

    O que está mudando agora é que esse raciocínio também precisa entrar na agenda de liderança.

    A IA parece atravessar silos, mas não elimina as dependências

    Existe evidência de que a IA consegue reduzir uma parte importante do custo de trabalhar entre diferentes especialidades.

    Um estudo publicado na Organization Science em 2026 acompanhou 791 profissionais trabalhando em desafios reais de inovação. Os participantes foram distribuídos entre condições com e sem IA, trabalhando individualmente ou em equipes. Um dos resultados mais interessantes foi que indivíduos utilizando IA conseguiram, em determinadas dimensões, desempenho comparável ao de equipes sem IA. Os pesquisadores também observaram redução de algumas diferenças tradicionais entre funções: profissionais de perfil técnico passaram a produzir propostas mais equilibradas comercialmente e profissionais comerciais incorporaram melhor aspectos técnicos quando utilizavam IA.

    Isso é muito relevante para organizações estruturadas em funções.

    Parte da colaboração existe porque o conhecimento necessário para resolver um problema está distribuído. Produto procura arquitetura para compreender uma restrição técnica. Tecnologia conversa com negócio para entender uma dinâmica comercial. Uma liderança envolve vários especialistas porque nenhuma pessoa isoladamente domina todas as dimensões necessárias para formular uma boa solução.

    A IA começa a reduzir esse custo. Uma pessoa pode explorar perspectivas fora da própria especialidade antes de acionar outra área. Pode chegar a uma conversa já entendendo conceitos, alternativas e riscos que anteriormente exigiriam várias interações preliminares.

    Esse é um ganho importante.

    O problema é confundir acesso a conhecimento com autoridade para decidir.

    Uma gerente de produto pode utilizar IA para produzir uma excelente análise de segurança. Isso não significa que tenha recebido autoridade para aceitar determinado risco em nome da organização. Um arquiteto pode compreender muito melhor a oportunidade comercial antes de conversar com Produto, mas continua não sendo necessariamente a pessoa responsável por escolher qual mercado a companhia priorizará.

    A IA pode reduzir uma parte do custo de atravessar silos, especialmente aquela relacionada a buscar e interpretar conhecimento. Ela não elimina automaticamente a distribuição de responsabilidade, recursos e autoridade que existe entre eles.

    Organizações também possuem recursos compartilhados

    Há uma analogia particularmente útil para líderes de tecnologia e arquitetura. Grandes organizações possuem algo parecido com recursos compartilhados em sistemas distribuídos.

    Uma proposta esperando a próxima reunião do comitê está em uma fila, mesmo que ninguém a chame assim. Uma iniciativa aguardando revisão de segurança também está. Três produtos dependendo do mesmo especialista formam outra fila. Uma equipe de plataforma atendendo solicitações de vinte squads administra, na prática, uma capacidade compartilhada.

    Quando observamos a organização dessa forma, surge um efeito interessante da IA: tornar os produtores mais rápidos pode aumentar a pressão sobre os recursos que continuam escassos.

    Imagine uma área de arquitetura com cinco pessoas que historicamente recebia dez iniciativas relevantes por mês. Agora várias equipes utilizam IA para investigar alternativas e amadurecer propostas muito mais rapidamente. Em poucos meses, a arquitetura passa a receber vinte e cinco iniciativas no mesmo intervalo.

    Nada necessariamente piorou naquela equipe. Ela pode inclusive estar utilizando IA e analisando cada proposta mais rapidamente.

    Ainda assim, existe uma boa chance de a fila crescer.

    A situação é semelhante à de escalar uma aplicação sem aumentar a capacidade do banco de dados do qual todas as novas instâncias dependem. A origem passou a produzir mais tráfego, mas o gargalo compartilhado permaneceu praticamente igual.

    Nas empresas, esse tipo de saturação aparece de maneiras menos explícitas: calendários cheios, revisões que levam cada vez mais tempo, dificuldade para conseguir uma decisão, dezenas de projetos simultaneamente “em andamento” e uma sensação permanente de atividade que não corresponde ao número de coisas efetivamente concluídas.

    O problema, nesse caso, não será resolvido perguntando como fazer cada equipe trabalhar ainda mais rápido.

    O que os experimentos com IA já estão nos mostrando

    Um experimento de campo envolvendo 7.137 trabalhadores do conhecimento em 66 empresas ajuda a marcar uma fronteira importante. Parte dos participantes recebeu acesso a uma ferramenta generativa integrada às aplicações que já utilizavam para escrever, trabalhar com e-mail e participar de reuniões. Entre os usuários que efetivamente adotaram a ferramenta, houve uma redução aproximada de duas horas semanais no tempo dedicado a e-mail durante a segunda metade do experimento. Fora essas economias individuais, os pesquisadores não encontraram mudanças equivalentes na quantidade ou composição geral das tarefas realizadas.

    A distinção interessa mais do que o número absoluto de horas economizadas. Alterar como eu escrevo um documento é uma decisão que posso tomar sozinho. Alterar o processo pelo qual esse documento será aprovado exige que outras pessoas também mudem.

    Posso utilizar IA para me preparar melhor para uma reunião. Não posso, individualmente, determinar que aquela decisão não exigirá mais a reunião.

    Posso antecipar perguntas de Segurança e preparar respostas excelentes. Não consigo simplesmente remover Segurança de um processo cuja governança formal exige sua participação.

    Posso produzir uma arquitetura em uma tarde. Isso não faz aparecer capacidade no roadmap da plataforma da qual a implementação depende.

    A adoção individual consegue avançar muito rapidamente. Mudanças que atravessam relações de autoridade, processos e fronteiras organizacionais possuem outra velocidade.

    É aí que liderança começa a fazer diferença.

    O problema muitas vezes está nas interfaces, não nas equipes

    Quando um projeto demora demais, uma reação comum é procurar o problema dentro da equipe responsável pela execução. Talvez faltem pessoas, talvez o processo precise ser melhorado, talvez seja necessário automatizar mais tarefas.

    Essas hipóteses podem estar corretas. Mas vale olhar primeiro para os pontos em que o trabalho muda de mãos.

    Interfaces organizacionais ruins obrigam cada iniciativa a reconstruir acordos que deveriam estar resolvidos. Não está claro o que uma equipe pode decidir, então outra área é envolvida por precaução. Critérios arquiteturais permanecem como conhecimento tácito de algumas pessoas, fazendo com que cada decisão relevante precise chegar até elas. Segurança possui boas práticas conhecidas, mas elas continuam sendo aplicadas por reuniões e revisões manuais em vez de políticas reutilizáveis. Uma equipe de plataforma oferece capacidades importantes, mas acessá-las depende de negociação individual com seus integrantes.

    O resultado é uma organização que utiliza especialistas como APIs humanas.

    Toda vez que alguém precisa de determinada decisão, abre-se uma conversa com a mesma pessoa. Quando o volume cresce, essa “API” começa a apresentar latência.

    É uma forma um pouco bem-humorada de descrever o problema, mas ela é bastante próxima da realidade de muitas empresas.

    Uma organização mais escalável tenta transformar parte dessas interações repetitivas em contratos conhecidos. O objetivo não é impedir que especialistas participem. É garantir que participem principalmente quando existe algo novo para decidir.

    Transforme decisões recorrentes em guardrails

    Considere uma equipe que precise envolver Segurança praticamente sempre que lança uma funcionalidade nova. Em cada projeto surgem perguntas sobre exposição de dados, integrações externas, autenticação e credenciais.

    Se a conversa é praticamente igual depois do décimo projeto, talvez não tenhamos mais dez decisões de segurança. Temos uma política de segurança que ainda não foi suficientemente explicitada.

    Em vez de exigir uma nova reunião em cada caso, a organização pode transformar parte desses critérios em guardrails previamente acordados. Certas soluções, dentro de limites específicos, podem seguir autonomamente. Apenas situações que ultrapassem esses limites chegam à avaliação especializada.

    Um produto que utiliza um método de autenticação já aprovado, não adiciona nova exposição externa, não altera determinada classificação de dados e segue um padrão arquitetural conhecido talvez não precise reconstruir toda a discussão.

    Quando alguma dessas condições muda, aí sim existe algo relevante para analisar.

    Para uma liderança de arquitetura, segurança, dados ou plataforma, existe uma pergunta simples e poderosa: quantas das decisões que chegam até mim são realmente novas e quantas são pequenas variações de algo que já decidimos repetidas vezes?

    A segunda categoria é uma excelente candidata a virar padrão, política, self-service ou documentação executável.

    Isso não reduz governança. Na maior parte das vezes, melhora a governança, porque aquilo que antes dependia da memória e disponibilidade de algumas pessoas passa a ser uma regra visível para todos.

    Consultar não é o mesmo que aprovar

    Outro ganho importante aparece quando distinguimos conhecimento de autoridade.

    Uma área pode precisar ser consultada sem necessariamente se tornar parte obrigatória da aprovação.

    Imagine uma iniciativa que aumente custos operacionais. Finanças possui informação importante. Arquitetura precisa avaliar determinadas implicações. Tecnologia precisa estimar esforço. Produto precisa compreender o valor para o cliente.

    É perfeitamente possível que todas essas perspectivas sejam necessárias e, ainda assim, apenas uma pessoa seja responsável pela decisão final.

    Suponha que exista um acordo organizacional segundo o qual a liderança de Produto pode decidir desde que a iniciativa permaneça abaixo de determinado investimento, utilize padrões arquiteturais previamente aprovados e não ultrapasse um nível definido de risco. Finanças fornece informação, arquitetura valida as premissas técnicas e tecnologia informa capacidade, mas nenhuma delas precisa transformar automaticamente sua contribuição em um veto.

    Quando algum dos limites é ultrapassado, a governança muda e a decisão pode subir para outro nível.

    Esse desenho preserva especialização sem tornar consenso obrigatório.

    É uma diferença pequena no papel e enorme no fluxo.

    Muitos processos ficam lentos porque ninguém distingue claramente quem precisa fornecer conhecimento, quem precisa ser ouvido e quem efetivamente possui autoridade para fechar a questão. Quando tudo é tratado como aprovação, cada participante adicional multiplica a possibilidade de espera.

    Para líderes, vale procurar processos nos quais existe uma longa lista de pessoas “obrigatórias”. Em vários deles, talvez cinco pessoas precisem contribuir e apenas uma precise decidir.

    Nem toda dependência pode ser removida. Algumas precisam de capacidade.

    Há situações em que melhorar direitos de decisão e políticas não resolve o problema porque existe uma restrição concreta de capacidade.

    Uma equipe de plataforma pode simplesmente não conseguir atender vinte projetos ao mesmo tempo. Um pequeno grupo especializado pode possuir conhecimento difícil de distribuir no curto prazo. Uma determinada infraestrutura pode suportar apenas algumas iniciativas simultâneas.

    Nesse cenário, pedir mais alinhamento produz pouco efeito. Existe mais demanda do que capacidade.

    A organização precisa escolher entre três caminhos: aumentar a capacidade, reduzir a dependência ou reduzir a quantidade de trabalho concorrendo por aquele recurso.

    Imagine cinco produtos dependendo da mesma capacidade de plataforma. Com IA, todos conseguem amadurecer suas iniciativas mais rapidamente e chegam praticamente juntos à mesma equipe. Se a plataforma consegue absorver apenas duas delas, nenhuma ferramenta eliminará a necessidade de priorização.

    A pior opção é fingir que todas continuam prioritárias.

    Quando isso acontece, prioridade começa a ser determinada informalmente por quem insiste mais, quem possui maior influência ou qual demanda conseguiu chegar primeiro. É uma maneira bastante sofisticada de dizer que não existe prioridade.

    Uma liderança pode preferir investir para tornar aquela capacidade self-service, contratar mais pessoas ou criar uma solução reutilizável. Em outros momentos, a decisão correta será simplesmente admitir que apenas duas iniciativas começarão agora.

    Limitação de capacidade não é falha de colaboração.

    É uma restrição que precisa ser administrada.

    Começar ficou barato. Terminar continua caro.

    Aqui aparece talvez um dos efeitos mais perigosos da IA para organizações que já tinham excesso de trabalho em progresso.

    Se ficou mais fácil analisar uma oportunidade, passamos a analisar mais oportunidades. Se prototipar custa pouco, abrimos mais protótipos. Se produzir propostas executivas leva algumas horas, colocamos mais propostas na mesa.

    Cada uma dessas decisões parece econômica isoladamente.

    O problema é que uma iniciativa não consome recursos apenas quando começa.

    Ela precisa continuar sendo acompanhada, disputar prioridade, atravessar dependências, receber decisões, manter contexto e eventualmente chegar à produção. Quando cinquenta coisas permanecem abertas, a organização paga um custo de coordenação sobre as cinquenta.

    É possível, portanto, utilizar IA para aumentar output e simultaneamente reduzir throughput.

    Há mais documentos, mais protótipos, mais hipóteses e mais projetos em andamento, mas não necessariamente mais resultados chegando ao cliente.

    O relatório DORA de 2025, baseado em quase 5 mil profissionais de tecnologia e mais de cem horas de pesquisa qualitativa, descreve IA justamente como um amplificador das características do sistema no qual ela é inserida. O relatório argumenta que os maiores ganhos dependem menos da ferramenta isolada e mais das capacidades organizacionais que permitem transformar produtividade local em desempenho do produto.

    Essa ideia vale muito além de desenvolvimento de software.

    Se uma empresa já possui dificuldade para terminar aquilo que começa, IA pode tornar extremamente eficiente o ato de começar ainda mais coisas.

    Às vezes, a solução mais tecnológica é começar menos

    Existe uma intervenção surpreendentemente simples para parte desse problema: limitar trabalho em progresso.

    Suponha que uma diretoria historicamente consiga executar bem seis iniciativas relevantes por trimestre. Depois de adotar IA, sua capacidade de estudar oportunidades cresce de quinze para quarenta.

    Isso não significa que agora seja capaz de executar dezesseis iniciativas.

    Talvez a melhor decisão seja continuar selecionando seis, mas escolhê-las com muito mais informação e testando suas premissas antes de comprometer recursos.

    Esse é um aspecto pouco discutido da produtividade com IA. Parte do ganho não precisa ser convertida em mais volume. Pode ser convertida em melhor seleção.

    A organização pode investigar cinquenta oportunidades e executar apenas cinco. Pode analisar dez arquiteturas e construir uma. Pode produzir dezenas de cenários e escolher um.

    Quando o custo de gerar possibilidades cai, selecionar passa a ser mais importante do que gerar.

    Para líderes, isso significa resistir à tentação de transformar cada ganho de produtividade em mais trabalho simultâneo. A capacidade liberada também pode ser usada para pensar melhor, reduzir riscos ou terminar antes.

    Um exemplo: o projeto que parecia ter um problema de execução

    Imagine uma empresa lançando um novo produto digital. A equipe responsável produz uma primeira proposta em três dias com auxílio de IA. O documento está bom, a oportunidade foi analisada e existe uma solução técnica plausível.

    A partir dali, o projeto demora sete semanas para começar.

    Uma análise retrospectiva mostra o seguinte: foram gastos quatro dias com trabalho efetivo de arquitetura, segurança e dados. O restante ficou distribuído entre espera por agenda, duas reuniões canceladas, uma dúvida sobre quem poderia aceitar determinado risco, priorização de uma dependência de plataforma e uma discussão que voltou ao início porque duas áreas haviam entendido de forma diferente o objetivo do lançamento.

    A reação errada seria perguntar como IA poderia acelerar aqueles quatro dias.

    A reação mais útil seria observar as outras seis semanas.

    Talvez o padrão arquitetural utilizado pudesse ter sido previamente aprovado. Talvez o risco tivesse um decision owner claro. Talvez a capacidade de plataforma precisasse ser tratada como dependência de portfólio já no início. Talvez as duas áreas precisassem concordar sobre o objetivo antes de produzir suas respectivas soluções.

    Nenhuma dessas melhorias depende de uma IA mais sofisticada.

    Dependem de uma organização melhor desenhada para transformar trabalho em decisão.

    O papel da liderança é reduzir coordenação desnecessária

    Isso não significa perseguir uma empresa sem dependências. Organizações grandes possuem especialização por bons motivos. Segurança precisa controlar riscos que uma equipe de produto talvez não consiga avaliar sozinha. Arquitetura precisa preservar determinadas propriedades que atravessam produtos. Plataformas compartilhadas evitam duplicação. Lideranças precisam arbitrar investimentos que competem entre si.

    A meta não é eliminar coordenação.

    É parar de pagar repetidamente por coordenação que não adiciona mais valor.

    Uma boa organização faz algo semelhante a uma boa arquitetura: estabelece contratos suficientes para que as partes consigam operar com autonomia e reserva integração mais intensa para situações realmente complexas.

    Algumas decisões merecem várias lideranças na mesma sala. Outras deveriam estar representadas por políticas conhecidas.

    Algumas dependências exigem colaboração entre especialistas. Outras já deveriam ter virado uma capacidade self-service.

    Algumas situações possuem risco suficiente para exigir aprovação. Outras continuam atravessando o mesmo processo simplesmente porque “sempre fizemos assim”.

    Quanto mais a IA acelera a produção, maior fica o custo dessas diferenças.

    Não pergunte apenas quem está trabalhando. Pergunte onde o trabalho está esperando.

    Uma das mudanças mais úteis que líderes podem fazer é começar a observar lead time organizacional com a mesma atenção que observam produtividade.

    Pegue algumas iniciativas concluídas recentemente e reconstrua sua trajetória. Não pergunte apenas quanto tempo cada equipe levou. Pergunte quanto tempo o trabalho permaneceu parado e por quê.

    Talvez descubra que uma iniciativa permaneceu cinco dias esperando uma decisão que levou vinte minutos. Outra ficou uma semana aguardando alguém que nem precisava ser approver. Um terceiro projeto passou por três reuniões diferentes para validar uma regra que já havia sido decidida em projetos anteriores.

    Esses intervalos são difíceis de enxergar porque não aparecem como trabalho. Ainda assim, fazem parte integral do tempo que o cliente espera pelo resultado.

    A IA torna esse diagnóstico mais urgente. Se continuarmos medindo apenas quanto mais cada pessoa consegue produzir, podemos celebrar enormes ganhos locais enquanto a velocidade percebida pela organização muda muito pouco.

    Para uma liderança, portanto, o objetivo não deveria ser fazer todos produzirem o máximo possível.

    Deveria ser fazer o trabalho importante atravessar a organização com o mínimo necessário de espera, retrabalho e negociação.

    A próxima fronteira não é automatizar pessoas. É redesenhar interfaces.

    Durante a primeira fase de adoção de IA, era natural concentrar atenção em produtividade individual. As ferramentas eram novas e havia muito valor óbvio em acelerar atividades que consumiam horas do dia.

    A próxima fase exige olhar para outro lugar.

    Quando produzir uma análise, uma proposta ou uma primeira solução deixa de ser a parte cara, o sistema organizacional que recebe esse trabalho passa a determinar uma parcela maior do resultado.

    Isso coloca temas menos tecnológicos no centro da transformação: direitos de decisão, desenho de processos, autonomia, capacidade compartilhada, quantidade de trabalho em progresso e qualidade das interfaces entre áreas.

    Em alguns casos, IA ajudará diretamente. Pode tornar políticas mais acessíveis, recuperar contexto, antecipar perguntas de outras funções e evitar reuniões puramente informativas.

    Em outros, a solução precisará vir da liderança.

    Nenhum modelo decide sozinho que uma aprovação deixou de ser necessária. Nenhum copiloto redistribui autoridade formal apenas porque detectou um gargalo. Nenhum agente consegue resolver a escassez de uma equipe estratégica se a organização insiste em comprometer cinco vezes sua capacidade.

    Essas são escolhas de desenho organizacional.

    A IA pode tornar cada equipe muito mais rápida e ainda deixar a empresa praticamente no mesmo lugar se o trabalho continuar atravessando exatamente as mesmas filas, aprovações e dependências.

    O verdadeiro ganho começa quando a organização aproveita a produtividade adicional para questionar essas interfaces.

    Porque o objetivo não é ter equipes mais rápidas produzindo trabalho para outras equipes mais rápidas.

    É fazer a empresa inteira conseguir transformar uma boa ideia em resultado com menos atrito.

    E existe um lugar em que boa parte desse atrito acaba ficando visível: a agenda. Quando direitos de decisão são confusos, contexto está fragmentado e dependências são excessivas, a resposta organizacional costuma ser convocar mais uma reunião de alinhamento.

    É justamente por isso que o próximo artigo desta série não será sobre como usar IA para fazer reuniões melhores.

    Será sobre entender por que ainda precisamos de tantas delas.

    Referências

    Dillon, E. W.; Jaffe, S.; Immorlica, N.; Stanton, C. T. Shifting Work Patterns with Generative AI. NBER Working Paper 33795, publicado em maio de 2025 e revisado em novembro de 2025. O estudo conduziu um experimento de campo com 7.137 trabalhadores do conhecimento em 66 empresas.

    Dell’Acqua, F. et al. The Cybernetic Teammate: A Field Experiment on Generative AI and Teamwork. Organization Science, 2026. O experimento acompanhou 791 profissionais em desafios reais de inovação e avaliou desempenho, integração entre especialidades e colaboração com IA.

    DORA. State of AI-assisted Software Development 2025. A pesquisa reuniu respostas de quase 5 mil profissionais de tecnologia e mais de cem horas de dados qualitativos, apontando a IA como um amplificador das capacidades e fragilidades organizacionais existentes.

    ia produtividade projetos
    Share. Facebook Twitter LinkedIn Telegram WhatsApp Copy Link
    Jhonathan Soares
    • Website
    • Facebook
    • X (Twitter)
    • LinkedIn

    Criador do blog Código Simples e com mais 15 anos de experiência em TI, com títulos de MVP Microsoft na área de Visual Studio Development, Neo4j Top 50 Certificate, Scrum Master e MongoDB Evangelist.

    Posts Relacionados

    A IA reduziu o custo de produzir. Não reduziu o custo de alinhar

    Gestão & Produtividade 10 de setembro de 202610 Mins Read

    A arquitetura virou sociotécnica de vez

    Gestão & Produtividade 20 de maio de 202610 Mins Read

    Observabilidade para agentes: por que logs e traces tradicionais já não bastam

    Gestão & Produtividade IA 23 de abril de 202611 Mins Read
    Newsletter

    Digite seu endereço de e-mail para receber notificações de novas publicações por e-mail.

    Junte-se a 24mil outros assinantes
    Posts recentes
    • Por que projetos ainda travam entre equipes, mesmo quando todos produzem mais rápido com IA
    • A IA reduziu o custo de produzir. Não reduziu o custo de alinhar
    • Noisy neighbor: por que multi-tenant não significa simplesmente compartilhar infraestrutura
    • Autoscaling pode ampliar o incidente: por que escalar uma camada não aumenta a capacidade do sistema inteiro
    • Observabilidade de IA com OpenTelemetry: o que realmente deveria aparecer no trace?
    Categorias
    • Arquitetura (39)
      • Microsserviços (3)
      • Testes (4)
    • Asp.net (120)
      • C# (89)
      • Mvc (13)
    • Banco de dados (93)
      • NoSql (60)
      • Sql (38)
    • Boas práticas (39)
      • Gestão & Produtividade (8)
      • Metodologias Ágeis (6)
    • Cursos (53)
    • Dicas (108)
    • Front-End (92)
    • IA (11)
    • Linux (6)
    • NodeJS (4)
    • Post do Leitor (9)
    • Python (5)
    • Seo (12)
    • Tecnologia (30)
      • ITIL (1)
      • Padrões de Projeto (4)
    • Testes (2)

    VEJA TAMBÉM

    Cursos
    12 de fevereiro de 20166 Mins Read

    1000 livros gratuitos sobre programação!

    Olha que dica bacana! A pagina só com livros sobre programação é mantida no GitHub…

    Idempotência em Software: Conceitos, Importância e Aplicações

    Código Simples no Facebook
    Código Simples no Facebook
    • Popular
    • Recente

    1000 livros gratuitos sobre programação!

    12 de fevereiro de 2016

    Google lança versão “invisível” do reCAPTCHA!

    10 de março de 2017

    Mini curso de HTML5 oferecido pela Microsoft

    30 de janeiro de 2014

    O que significa ( !important ) na declaração do CSS ?

    5 de fevereiro de 2014

    Programa para supercompactar arquivos. KGB Archiver.

    6 de fevereiro de 2014

    Por que projetos ainda travam entre equipes, mesmo quando todos produzem mais rápido com IA

    11 de setembro de 2026

    A IA reduziu o custo de produzir. Não reduziu o custo de alinhar

    10 de setembro de 2026

    Noisy neighbor: por que multi-tenant não significa simplesmente compartilhar infraestrutura

    21 de agosto de 2026

    Autoscaling pode ampliar o incidente: por que escalar uma camada não aumenta a capacidade do sistema inteiro

    23 de julho de 2026

    Observabilidade de IA com OpenTelemetry: o que realmente deveria aparecer no trace?

    15 de julho de 2026
    Nosso Feed
    • RSS - Posts
    Fique por dentro

    Digite seu endereço de email para assinar este blog e receber notificações de novas publicações por email.

    Facebook X (Twitter) Instagram LinkedIn

    Type above and press Enter to search. Press Esc to cancel.

    Vá para versão mobile