O modelo ADDIE na prática: as cinco fases, e o que trava em cada uma

Quase todo projeto de treinamento que dá errado já tinha dado errado antes da primeira tela. Alguém pulou uma pergunta lá atrás, e o problema só apareceu quando o curso estava pronto, com o cliente olhando, no momento mais caro possível para mudar.

O ADDIE é a resposta mais antiga e mais usada para isso. Ele não ensina a fazer um bom curso, e é importante dizer isso logo. O que ele faz é definir em que ordem as decisões precisam ser tomadas, o que evita descobrir na véspera da publicação que ninguém combinou o que a pessoa deveria conseguir fazer no fim.

A sigla que ninguém assinou

Vale começar por uma curiosidade que muda o jeito de usar o modelo.

Em 1975, o Centro de Tecnologia Educacional da Universidade Estadual da Flórida trabalhou com o Exército americano em um procedimento de desenvolvimento de treinamento que atenderia às quatro forças. O documento ficou conhecido como IPISD, e organizava o trabalho em cinco títulos: analisar, desenhar, desenvolver, implementar e controlar.

Repare no quinto. Era controlar, não avaliar. E quem usava aquilo não chamava de ADDIE: chamava de IPISD.

Michael Molenda foi atrás da origem da sigla em 2003 e chegou a uma conclusão desconfortável: ela não tem autor. Não existe artigo fundador, não existe versão oficial, não existe "o livro do ADDIE". A sigla se formou na boca das pessoas e só depois entrou na literatura acadêmica, quando Molenda, Pershing e Reigeluth passaram a usá-la em 1996, justamente por ser o termo que mais ouviam nas conversas da área.

A consequência prática é libertadora: não existe jeito certo de fazer ADDIE. Quem disser que a sua equipe está fazendo errado está comparando com uma versão que ele mesmo escolheu. O que existe são cinco decisões que alguém precisa tomar em algum momento, e é nelas que vale gastar atenção.

Análise: a fase que todo mundo abrevia

Aqui se decide para quem é o treinamento, que problema ele resolve, o que a pessoa precisa conseguir fazer depois que não consegue hoje, e sob quais restrições isso vai acontecer (tempo, plataforma, idioma, se tem celular na operação, se a pessoa tem sala para assistir).

O erro mais comum não é pular a análise. É achar que ela já foi feita porque o conteúdo chegou pronto. Um PowerPoint de 80 slides enviado pela área técnica responde "o que eu sei sobre o assunto", que é uma pergunta diferente de "o que essa pessoa precisa fazer melhor".

Quando essa fase é malfeita, o sintoma aparece lá na frente e disfarçado: o curso fica correto, e ainda assim ninguém muda nada no trabalho. Se essa parte costuma ser corrida na sua empresa, vale olhar como estruturar o levantamento.

Desenho: onde o curso vira decisão, não tela

O desenho transforma o resultado da análise em plano: objetivos de aprendizagem, sequência, como a pessoa vai praticar, como ela será avaliada e em que formato tudo isso acontece.

Duas coisas decidem a qualidade dessa fase. A primeira é o objetivo ser verificável, e não uma intenção genérica. "Conscientizar sobre segurança" não dá para avaliar; "identificar três situações de risco na própria bancada" dá. É o assunto da taxonomia de Bloom, que existe exatamente para isso.

A segunda é decidir a prática antes de decidir a estética. A pergunta que separa curso bom de curso bonito é simples: em que momento a pessoa vai errar em ambiente seguro e receber retorno? Se não houver esse momento, o que você tem é um comunicado com narração.

Desenvolvimento: produzir é executar decisão, não tomá-la

É a fase visível: storyboard aprovado vira tela, áudio, vídeo, interação, pacote publicável.

O erro clássico aqui é a rodada de revisão sem critério. Dez pessoas comentam, cada uma sobre uma coisa, e o projeto passa três semanas ajustando opinião de gosto. Revisão funciona quando volta para o que foi combinado no desenho: este objetivo está sendo cumprido, esta prática funciona, este exemplo é real na nossa operação.

O outro movimento que salva projeto é testar cedo com gente de verdade. Cinco pessoas do público real passando por um módulo ainda em rascunho mostram em uma tarde o que a equipe não veria em um mês, porque quem desenhou já sabe demais para se confundir com a própria tela.

Implementação: o curso encontra a empresa

Publicação no LMS, inscrição, comunicação, prazo, papel do gestor, suporte a quem trava. É a fase que mais se subestima, porque parece logística.

Só que é aqui que o projeto encontra a realidade: o link que não abre na rede da fábrica, o colaborador sem e-mail corporativo, a liderança que não sabia do treinamento e trata como interrupção. Nenhuma dessas coisas é problema de conteúdo, e todas derrubam a conclusão do curso.

Uma regra prática: implementação começa a ser desenhada junto com o curso, não depois. Quem decide o formato sem saber como a pessoa será convocada decide no escuro.

Avaliação: a fase que virou o E

A avaliação tem dois momentos. Durante o projeto, ela serve para corrigir enquanto ainda é barato (é o teste com cinco pessoas do parágrafo anterior). Depois da publicação, serve para responder se aquilo funcionou.

E "funcionou" precisa de definição. Pesquisa de satisfação mede se a pessoa gostou, que é informação útil e não é aprendizagem: o assunto está em o que as suas avaliações de reação realmente medem. Para ir além disso, o caminho passa por medir resultado de treinamento.

Volte agora à curiosidade do começo: no documento de 1975, esta fase se chamava controle. A troca de nome conta uma mudança real de intenção. Controlar é manter o sistema em conformidade; avaliar é perguntar se valeu a pena. A segunda pergunta é mais difícil, e é a que a empresa faz hoje.

O que quebra o ADDIE dentro da empresa

A versão original era hierárquica: uma fase começava com a anterior fechada. Já em meados dos anos 1980 apareceram versões com idas e voltas, e é essa que vale seguir, mas o hábito da fila ficou.

O problema é que aprovação corporativa não funciona por documento. O cliente assina o storyboard, a produção acontece, e quando ele finalmente vê a tela pronta descobre que imaginava outra coisa. Não é má-fé: ninguém enxerga um curso lendo a descrição de um curso. Quando isso acontece no fim, a mudança custa o triplo e a equipe chega esgotada no ajuste.

SAM, a resposta ágil ao mesmo problema

Michael Allen tratou disso de frente no livro "Leaving ADDIE for SAM", de 2012, escrito com Richard Sites. A proposta é o Modelo de Aproximações Sucessivas.

Na versão simples, é um ciclo curto de avaliar, desenhar e desenvolver, repetido cerca de três vezes, em que cada volta produz algo que dá para ver. Na versão para projeto grande, o trabalho tem uma preparação rápida, uma fase de desenho iterativo que começa por uma reunião de ideias com as pessoas que decidem, e uma fase de desenvolvimento também em ciclos, com versões que vão de protótipo a entrega final.

O que o SAM resolve de verdade não é velocidade, é o momento da discordância. Ele força o desacordo a aparecer na terceira semana, diante de um protótipo feio, em vez de no terceiro mês, diante do curso pronto.

Como usar o ADDIE sem virar refém dele

Três ajustes resolvem a maior parte do atrito, sem trocar de metodologia:

Trate as fases como decisões, não como etapas. O que não pode acontecer é produzir sem ter definido objetivo e prática. A ordem no cronograma é negociável; a ordem das decisões, não.

Coloque um protótipo navegável antes da aprovação do desenho. Uma tela real de cada tipo, com a interação funcionando, vale mais que trinta páginas de storyboard aprovado por e-mail.

Combine o critério de revisão antes da primeira revisão. Quem comenta o quê, e com base em que decisão já tomada. Isso sozinho encurta projeto.

O ADDIE continua útil porque dá vocabulário comum a gente que não faz a mesma coisa: quem contrata, quem entende do assunto e quem produz passam a saber se estão discutindo objetivo ou cor de botão. Ele não é o único caminho, e vale conhecer os vizinhos em cinco métodos clássicos de desenho instrucional.

E depois de decidir como conduzir o projeto, ainda falta decidir se aquilo vira curso, vídeo, simulador ou pílula, que é outra conversa.