O projeto final do curso técnico não pode ser uma apresentação de slides com capturas de tela. Precisa ser um produto funcional, com código público, documentação técnica e — preferencialmente — em uso real. Veja como estruturar isso na escola pública.
O projeto final integrador de um curso técnico em Desenvolvimento de Sistemas é a síntese verificável de todo o percurso formativo: o momento em que o aluno deixa de ser aprendiz de conceitos isolados e passa a ser produtor de software com utilidade real. Não é uma prova, não é uma apresentação de slides, não é uma simulação de projeto. É um produto — com usuário, com problema, com código versionado e com deploy.
Premissa estrutural: um projeto final que não tem usuário real, problema real e código público não é projeto integrador — é exercício avaliativo com nome diferente. A diferença não é cosmética: ela determina o nível de comprometimento, o rigor técnico e o impacto real do que o aluno aprende ao longo do processo.
Por que a maioria dos projetos finais técnicos falha — e o que está errado na raiz
O padrão mais comum de projeto final em cursos técnicos de programação no Brasil segue um roteiro previsível: alunos escolhem um tema genérico no último semestre, desenvolvem um CRUD básico sem usuário real, apresentam para uma banca formada apenas por professores e arquivam o código em uma pasta ZIP jamais acessada novamente.
O problema não está na falta de esforço dos alunos. Está na ausência de três elementos estruturais que transformam um exercício em projeto real:
Problema sem dono real
Projeto sem usuário identificado no início não tem critério de sucesso. O aluno desenvolve para “passar” na avaliação, não para resolver algo que importa.
Processo sem documentação
Código entregue sem histórico de commits, sem decisões registradas, sem iterações visíveis. Impossível avaliar aprendizado real — só produto final.
Produto sem continuidade
Aplicação que funciona na apresentação e morre na semana seguinte. Sem deploy, sem manutenção, sem impacto verificável fora do contexto escolar.
A solução não exige recursos adicionais. Exige uma mudança de arquitetura pedagógica: o projeto precisa começar no primeiro semestre do curso — não no último.
“O projeto final não começa no último semestre. Começa no primeiro commit do primeiro algoritmo.”— Princípio estrutural do curso técnico documentado neste blog
Como estruturar o projeto integrador desde o primeiro módulo
A lógica é simples: se o aluno vai desenvolver um produto real ao final do curso, ele precisa construir os fundamentos técnicos e o repertório de problemas reais ao longo de todo o percurso formativo. O projeto final não é uma etapa — é um destino que orienta todas as etapas anteriores.
A estrutura abaixo funciona para um curso técnico integrado ao Ensino Médio com três anos de duração:
1º Ano — Imersão no problema real antes do código
Antes de escrever uma linha de código com intenção de projeto, o aluno precisa desenvolver a competência de observar problemas com olhar técnico. No primeiro ano, cada módulo de conteúdo é acompanhado por uma atividade de mapeamento: quais problemas da escola, da família ou da comunidade esse conteúdo poderia ajudar a resolver?
O repositório do aluno no primeiro ano tem dois propósitos simultâneos: guardar o histórico de aprendizagem técnica e acumular registros de problemas observados. O README de cada pasta de exercícios inclui uma seção obrigatória: “Problema que este conceito poderia resolver”.
# algoritmos-logica-programacao
## O que aprendi neste módulo
- Variáveis e tipos de dados
- Estruturas condicionais (if/elif/else)
- Laços de repetição (for e while)
- Funções com parâmetros e retorno
## Problemas que este módulo poderia resolver
→ A secretaria da escola usa planilha manual para controlar
falta de professores. Um script poderia automatizar isso.
→ A cantina não sabe quantos alunos pedem cada prato por dia.
Um sistema simples resolveria com dicionários e contagem.
→ A biblioteca não tem controle de empréstimos digital.
Poderia ser feito com listas e condicionais básicas.
## Commits deste módulo
ver histórico no git logAo final do primeiro ano, cada aluno tem um mapa de problemas reais — construído com o repertório técnico que foi desenvolvendo ao longo dos módulos. A escolha do projeto final não é uma decisão aleatória de último semestre: ela emerge naturalmente desse processo de observação sistemática.
2º Ano — MVP funcional com usuário real desde o início
No segundo ano, o aluno já domina lógica de programação, tem base de frontend e Git operacional. É o momento de iniciar o desenvolvimento do projeto com um critério inegociável: o usuário precisa ser identificado antes do primeiro commit de projeto.
“Usuário” aqui não é um personagem fictício de um documento de requisitos. É uma pessoa real na escola ou na comunidade que tem um problema verificável e que vai testar o produto durante o desenvolvimento — não apenas na apresentação final.
Prática concreta: antes de criar o repositório do projeto, o aluno precisa entregar um documento de uma página respondendo três perguntas: Quem é o usuário? Qual problema específico ele tem? Como esse problema é resolvido hoje (mesmo que de forma precária)? Sem esse documento validado, o repositório do projeto não é criado.
3º Ano — Deploy, documentação técnica e apresentação pública
O terceiro ano é o ano do produto em produção. O software precisa estar acessível para o usuário real — não apenas funcionando na máquina do aluno. Deploy em produção, mesmo que em plataformas gratuitas, é requisito não negociável.
Critérios de avaliação que medem o que importa
O maior problema dos critérios de avaliação tradicionais em projetos técnicos é que eles medem produto final — e produto final pode ser copiado, terceirizado ou desenvolvido às pressas na semana anterior à apresentação. O que precisa ser avaliado é processo + produto + comunicação.
| Dimensão | O que avaliar | Como verificar | Peso |
|---|---|---|---|
| Processo | Evolução do código, frequência de commits, qualidade das mensagens, iterações documentadas | Histórico do repositório no GitHub | 30% |
| Produto | Funcionalidade em produção, código legível, segurança básica, responsividade | Teste ao vivo com usuário real durante a apresentação | 35% |
| Documentação | README completo, decisões técnicas registradas, instruções de instalação/uso | README.md e wiki do repositório | 20% |
| Comunicação | Capacidade de explicar decisões técnicas, responder perguntas da banca, apresentar para público não técnico | Apresentação pública com Q&A | 15% |
Critério eliminatório: projeto sem deploy funcional ou sem histórico de commits consistente no GitHub não é aprovado — independente da qualidade da apresentação. Código que só funciona na máquina do aluno no dia da apresentação não é produto técnico. É demonstração.
Estrutura técnica do repositório: o que precisa estar no GitHub
O repositório do projeto final é o portfólio verificável do aluno. Um recrutador que acessa esse repositório antes de uma entrevista de estágio precisa encontrar evidência suficiente para avaliar competência técnica — sem precisar pedir mais nada.
projeto-integrador/
├── README.md # obrigatório — ver template abaixo
├── docs/
│ ├── decisoes-tecnicas.md # por que escolheu cada tecnologia
│ ├── problema-usuario.md # quem é o usuário, qual o problema
│ └── historico-iteracoes.md # o que mudou entre versões e por quê
├── src/
│ ├── frontend/
│ └── backend/
├── .gitignore # sem segredos no repositório
├── requirements.txt # ou package.json — dependências explícitas
└── DEPLOY.md # como está em produção e onde acessarO README precisa responder cinco perguntas sem que o leitor precise abrir mais nenhum arquivo:
- Qual problema este software resolve e para quem?
- Como instalar e executar localmente em menos de 5 minutos?
- Onde está o deploy em produção? (link funcional)
- Quais decisões técnicas principais foram tomadas e por quê?
- Quem desenvolveu e como entrar em contato?
Caso real: o sistema de agendamento do laboratório escolar
O projeto final de uma das turmas do terceiro ano do curso técnico foi um sistema de agendamento de uso do laboratório de informática — problema real, solicitado pela própria gestão escolar, que usava uma planilha manual compartilhada por WhatsApp para controlar os horários de cada professor.
O produto entregue incluía:
Interface web responsiva
Formulário de agendamento, visualização de horários por semana e painel administrativo. HTML + CSS + JavaScript puro, sem framework.
API REST em Python/Flask
CRUD completo de agendamentos com validação de conflito de horário. Banco SQLite. Deploy no Railway (plano gratuito).
11 semanas de desenvolvimento
247 commits no repositório público. Três iterações documentadas com feedback real da coordenação pedagógica entre cada versão.
Em uso desde o lançamento
O sistema substituiu a planilha de WhatsApp. Está em operação. O repositório público é portfólio verificável para todos os 4 alunos do grupo.
O resultado concreto vai além do software: cada aluno que participou desse projeto tem um repositório público com quase 250 commits, código em produção e um caso real documentado que pode apresentar em qualquer processo seletivo de estágio. Isso não é currículo montado para parecer bom — é evidência real de competência técnica.
Como lidar com grupos heterogêneos no mesmo projeto
Turmas de curso técnico em escola pública raramente têm nivelamento homogêneo. Em um grupo de quatro alunos, é comum ter um com perfil técnico avançado, dois com base mediana e um ainda em consolidação dos fundamentos. Tratar todos como iguais no projeto integrador é uma injustiça pedagógica — e técnica.
A solução é a divisão por competência + responsabilidade pública:
| Perfil no grupo | Responsabilidade principal | Entregável individual verificável |
|---|---|---|
| Técnico avançado | Arquitetura, backend, decisões técnicas críticas | Pull requests de feature + documentação de decisões técnicas |
| Técnico intermediário | Frontend, integração, testes manuais | Componentes entregues + issues registradas e resolvidas |
| Em consolidação | Documentação, README, DEPLOY.md, suporte a testes | Documentação completa + commits de atualização de docs |
Princípio orientador: o Git não mente. O histórico de commits por autor revela — com precisão — quem fez o quê e quando. Isso não é ferramenta de vigilância: é instrumento de justiça avaliativa em projetos coletivos. O aluno que contribuiu mais tem evidência pública disso. O aluno que se dedicou menos também.
A apresentação pública como componente pedagógico insubstituível
A banca do projeto final não pode ser composta apenas por professores do curso. Uma banca que só tem professores avalia com critérios internos, fechados, desconectados da realidade do mercado. A apresentação pública do projeto integrador precisa incluir pelo menos um elemento externo à escola.
Possibilidades viáveis para escola pública:
- Profissional de tecnologia da região (egresso da escola, desenvolvedor local, representante de empresa parceira)
- Gestor da escola como usuário real do produto apresentado
- Alunos de turmas mais novas do próprio curso — que avaliam a apresentação como futuros concluintes
- Professor de outra área (Português, Ciências) como representante do público não técnico
- Familiar do aluno convidado formalmente como observador
A presença de público externo transforma a dinâmica da apresentação. O aluno que sabe que vai apresentar para alguém de fora da escola prepara a comunicação com rigor diferente — porque sabe que não pode contar com o professor “completar as lacunas” por familiaridade com o projeto.
Conclusão: o projeto final é a prova de que o curso funcionou
Um curso técnico em Desenvolvimento de Sistemas na escola pública pode ser avaliado por muitos critérios: taxa de aprovação, nota nas avaliações, presença nas aulas. Mas existe apenas um critério definitivo de que o curso funcionou de verdade: o aluno sai com produto real em produção, código público e capacidade de explicar cada decisão técnica que tomou.
Isso não exige laboratório perfeito, internet de alta velocidade ou infraestrutura de escola privada. Exige método estruturado, problema real desde o primeiro módulo, Git obrigatório desde o primeiro commit e a clareza pedagógica de que o que está sendo construído ao longo de três anos não é um conjunto de competências técnicas isoladas — é a trajetória de quem vai entrar no mercado de trabalho com portfólio verificável, não apenas com certificado.
O projeto final integrador é a prova pública de que esse objetivo foi cumprido.
Acompanhe o processo em tempo real
Documentação de aulas, repositórios dos alunos, decisões pedagógicas e erros reais de chão de escola — sem hype, sem abstração.
Acessar o Diário de um POEDPublicado em professorcomia.com.br · Ensino Técnico & Desenvolvimento de Sistemas · diariodeumpoed.com.br