Lições da construção de tecnologia educacional

Há uma estatística que deveria preocupar todos os líderes de P&D que consideram a tecnologia de aprendizagem personalizada: de acordo com uma pesquisa do Standish Group, cerca de 66% dos projetos de software não atendem às expectativas ou são totalmente abandonados. Na tecnologia educacional, onde os riscos envolvem os resultados dos alunos e os dólares dos contribuintes, esse número deveria ser inaceitável. Mas aqui está o que a maioria das pessoas erram sobre o motivo do fracasso dos projetos EdTech. Raramente é a codificação. Raramente é o orçamento. Quase sempre são as decisões de arquitetura do eLearning – as decisões fundamentais tomadas nas primeiras duas semanas de um projeto que determinam tudo o que se segue.

Passei mais de uma década desenvolvendo software personalizado, com uma parte significativa desse tempo focada em tecnologia educacional para instituições de ensino fundamental e médio e redes de escolas charter. As plataformas bem-sucedidas compartilharam um conjunto de padrões arquitetônicos comuns. Os que falharam compartilharam um conjunto diferente. Aqui está o que aprendi.

Neste artigo…

1. Projete para o fluxo de trabalho do professor, não para a lista de desejos do administrador

O erro mais comum no desenvolvimento de plataformas EdTech é construir de cima para baixo. Um administrador ou líder distrital define os requisitos. Uma equipe de desenvolvimento constrói de acordo com essas especificações. A plataforma é lançada. Os professores odeiam isso.

Isso acontece porque os administradores pensam em termos de dados: números de inscrições, relatórios de conformidade, métricas de desempenho. Os professores pensam em termos de fluxo de trabalho: “Preciso anotar a presença, distribuir a tarefa de hoje, verificar quem está atrasado e comunicar-me com os três pais antes do almoço.”

Quando você primeiro toma decisões sobre a arquitetura da plataforma de eLearning em torno dos fluxos de trabalho dos professores, algo interessante acontece: os dados administrativos de que os administradores precisam emergem naturalmente como um subproduto do trabalho dos professores. Dados de frequência, métricas de engajamento, tendências de desempenho: tudo isso é capturado sem adicionar um único clique extra ao dia do professor.

• A lição prática
  Antes de escrever uma única linha de código, acompanhe três a cinco professores durante um dia inteiro cada. Mapeie seu fluxo de trabalho minuto a minuto. Em seguida, projete seu modelo de dados para capturar o que os professores já fazem, em vez de pedir aos professores que façam algo novo.

A investigação da Sociedade Internacional para a Tecnologia na Educação (ISTE) mostra consistentemente que a adesão dos professores é o indicador mais forte do sucesso da adoção da tecnologia nas escolas. As decisões de arquitetura de eLearning que respeitam os fluxos de trabalho dos professores não são apenas um bom design – são a base da adoção.

2. Construir conformidade com FERPA na camada de dados, não na camada de aplicativo

A Lei dos Direitos Educacionais e Privacidade da Família (FERPA) rege como os registros educacionais dos alunos são tratados. A maioria das equipes de desenvolvimento trata a conformidade com a FERPA como um recurso – algo que você adiciona a uma plataforma de trabalho. Esta abordagem cria dois problemas sérios.

Primeiro, fixar a conformidade em uma arquitetura existente cria inevitavelmente lacunas. Quando os dados dos alunos fluem através de um sistema que não foi projetado para privacidade desde o início, é quase impossível garantir que as informações de identificação pessoal (PII) não vazem através de sistemas de registro, relatórios de erros, análises de terceiros ou respostas de API em cache. Em segundo lugar, a conformidade com o retrofit é dispendiosa. Já vi organizações gastarem mais em uma auditoria de conformidade da FERPA de uma plataforma existente do que gastariam construindo-a corretamente do zero. A solução é arquitetônica: a conformidade deve residir na própria camada de dados.

Na prática, isso significa implementar a classificação de dados no nível do esquema. Cada dado que entra no sistema é marcado em uma das três categorias: informações de diretório (geralmente compartilháveis), registro educacional (protegido pela FERPA) ou dados desidentificados (agregados e anônimos). Os controles de acesso, o registro de auditoria e as políticas de retenção de dados operam automaticamente com base nessas classificações, independentemente de qual recurso do aplicativo está acessando os dados.

• A lição prática
  Se o seu parceiro de desenvolvimento não conseguir explicar sua estratégia de classificação de dados na primeira reunião de arquitetura, ele está planejando reforçar a conformidade mais tarde. Isso é uma bandeira vermelha.

3. Separe o mecanismo de aprendizagem da camada de conteúdo

Uma das decisões de arquitetura de eLearning mais importantes é a forma como a lógica de aprendizagem (avaliações, acompanhamento de progresso, caminhos adaptativos) está acoplada ao próprio conteúdo (aulas, vídeos, questionários, materiais de leitura). Sistemas fortemente acoplados – onde a lógica do questionário é incorporada diretamente no conteúdo da lição – são mais rápidos de construir inicialmente. Eles também são um pesadelo para manter. Quando um currículo muda (e sempre muda), atualizar sistemas fortemente acoplados significa tocar tanto no conteúdo quanto na lógica simultaneamente, o que introduz bugs e exige o envolvimento do desenvolvedor no que deveria ser o trabalho de um editor de conteúdo.

Os sistemas fracamente acoplados separam as preocupações: os editores de conteúdo gerenciam o conteúdo por meio de uma camada de gerenciamento de conteúdo, enquanto o mecanismo de aprendizagem lida de forma independente com o sequenciamento, a pontuação da avaliação e o acompanhamento do progresso. Os dois se comunicam por meio de interfaces bem definidas – geralmente usando padrões como (SCORM, xAPI ou LTI para garantir a interoperabilidade entre a camada de conteúdo e os sistemas externos. Essa separação rende dividendos de três maneiras específicas:

1. As atualizações curriculares tornam-se tarefas de conteúdo, não tarefas de engenharia
   Professores ou especialistas em currículo podem atualizar aulas sem suporte do desenvolvedor.
2. O mecanismo de aprendizagem pode ser reutilizado em vários programas
   Uma rede de escolas charter, por exemplo, pode usar o mesmo mecanismo de avaliação e acompanhamento de progresso em diferentes campi com currículos diferentes.
3. A análise se torna mais significativa
   Quando a lógica de aprendizagem é separada do conteúdo, você pode comparar o desempenho dos alunos em diferentes versões de conteúdo – dados poderosos para melhoria do currículo.

• A lição prática
  Pergunte à sua equipe de desenvolvimento se um especialista em currículo poderia atualizar uma lição sem preencher um ticket de suporte. Se a resposta for não, seu conteúdo e lógica estão fortemente interligados.

4. Instrumente tudo desde o primeiro dia

Na minha experiência, o aspecto mais subvalorizado da arquitetura da plataforma EdTech é a instrumentação – a prática de incorporar pontos de coleta de dados em todo o sistema para capturar como alunos e professores realmente interagem com a plataforma. A maioria das equipes planeja “adicionar análises mais tarde”. Isso é um erro por um motivo simples: você não pode capturar retroativamente dados sobre interações que já aconteceram. Se você lançar em setembro sem instrumentação e perceber em dezembro que precisa de dados de engajamento do primeiro semestre, esses dados desaparecerão. A instrumentação eficaz em plataformas educacionais vai além das visualizações de páginas e da contagem de cliques. As métricas que realmente informam os resultados da aprendizagem incluem:

• Tempo gasto na tarefa por tipo de conteúdo
  Os alunos estão gastando mais tempo assistindo vídeos ou lendo? Isso informa sobre a eficácia do formato do conteúdo.
• Padrões de tentativa de avaliação
  Quantas tentativas antes do domínio? Onde os alunos abandonam as avaliações? Isso revela picos de dificuldade curricular.
• Comportamento de busca de ajuda
  Quando os alunos pedem ajuda e por qual canal? Isto indica onde o apoio instrucional é necessário.
• Padrões de sessão
  Quando e por quanto tempo os alunos se envolvem? Isso informa as decisões de agendamento e ritmo.

A principal decisão da arquitetura de eLearning é construir um pipeline de dados orientado a eventos que capture essas interações em tempo real sem afetar o desempenho da plataforma. Isso normalmente significa implementar um barramento de eventos assíncrono que grava dados de interação em um armazenamento de dados analítico separado, mantendo o aplicativo primário rápido enquanto cria um conjunto de dados rico para análise. À medida que os recursos de IA moldam cada vez mais o software educacional de ensino fundamental e médio, esses dados de instrumentação se tornam ainda mais valiosos – eles alimentam os modelos de aprendizagem adaptativos que personalizam as experiências dos alunos.

• A lição prática
  Defina sua estratégia de instrumentação antes de sua lista de recursos. Os dados que você coleta nos primeiros três meses de implantação são os dados que determinarão se sua plataforma está realmente melhorando os resultados de aprendizagem.

5. Planeje o off-line no nível da arquitetura

Esta é a decisão que separa as plataformas construídas por pessoas que visitaram escolas daquelas construídas por pessoas que não o fizeram. A conectividade com a Internet nas escolas não é confiável. Não é confiável nos distritos rurais. Não é confiável em distritos urbanos durante o pico de uso. Não é confiável quando 30 alunos transmitem vídeo simultaneamente em uma sala de aula projetada para cargas de Internet da década de 1990. Apesar desta realidade, a maioria das plataformas de aprendizagem são arquitetadas como aplicações puramente baseadas na nuvem que requerem uma ligação constante à Internet. Quando a conexão cai – e isso acontecerá – a plataforma se torna inutilizável. Os alunos perdem trabalho. Os professores perdem tempo de aula. A frustração aumenta. A adoção cai.

Arquitetar para recursos off-line não significa construir um aplicativo totalmente off-line. Isso significa implementar uma estratégia de aprimoramento progressivo em que os fluxos de trabalho principais (fazer avaliações, visualizar conteúdo carregado anteriormente, registrar presença) continuem a funcionar durante lacunas de conectividade e, em seguida, sincronizem quando a conectividade retornar.

A abordagem técnica envolve o armazenamento em cache de conteúdo crítico no lado do cliente e um sistema de sincronização baseado em fila que lida com a resolução de conflitos de maneira elegante. Isso adiciona complexidade à arquitetura inicial, mas elimina a reclamação mais comum dos educadores que usam plataformas de aprendizagem personalizadas.

• A lição prática
  Pergunte ao seu provedor de plataforma o que acontece quando um aluno está no meio da avaliação e o WiFi cai. Se a resposta envolver perda de trabalho, a arquitetura não está pronta para salas de aula reais.

O fio comum

Estas cinco decisões partilham uma filosofia comum: construir sobre como a educação realmente funciona, e não como gostaríamos que funcionasse. Os professores estão ocupados. Os dados dos alunos são confidenciais. Os currículos mudam constantemente. A aprendizagem acontece em ambientes imperfeitos com infraestrutura imperfeita. As plataformas bem-sucedidas são aquelas cuja arquitetura reconhece essas realidades desde a primeira conversa sobre design.

Se você é um líder de P&D que avalia tecnologia de aprendizagem personalizada, estas cinco perguntas fornecem uma estrutura para avaliar se uma plataforma foi construída para o mundo real da educação:

1. A plataforma foi projetada em torno dos fluxos de trabalho dos professores ou dos requisitos do administrador?
2. A conformidade está integrada na camada de dados ou incorporada como um recurso?
3. O conteúdo pode ser atualizado independentemente da lógica de aprendizagem?
4. Quais dados de interação foram capturados desde o primeiro dia?
5. O que acontece quando a internet cai?

As respostas a essas perguntas lhe dirão mais sobre a viabilidade de uma plataforma a longo prazo do que qualquer lista de recursos ou demonstração jamais poderia.

Leitura adicional:

Construindo um LMS personalizado: quando as plataformas prontas para uso ficam aquém