Competições Senac RS · Seletiva 26
Módulo 10 · Apostila teórica
Módulo 10 — Apresentação e defesa
Onde esse módulo entra. É o Módulo D da prova: apresentação individual, até 10 minutos, em português, com pitch técnico e demonstração ao vivo. O cronograma trabalha isso no fim de outubro, depois de todo o sistema já estar lapidado (módulo 08). É a única parte da prova que não é escrever código, e é onde muita gente boa perde ponto por não treinar. Dá pra ter o melhor sistema da sala e apresentar mal: a banca avalia o que você mostra e conta, não o que está na sua cabeça. O sistema já está impecável; esse módulo transforma o impecável em nota na frente da banca. Natureza 🆕 novo, porque exige uma habilidade diferente de programar: comunicar sob pressão, no tempo, com o sistema rodando ao vivo.
1. O que a banca realmente avalia
Não é teatro nem discurso decorado. A apresentação é uma prova de julgamento (J), então a banca pontua de 0 a 3 (o mesmo descritor de todo o resto da prova), e a diferença entre o 2 e o 3 é exatamente onde esse módulo joga. Três coisas estão sendo medidas ao mesmo tempo:
- Que você construiu e entende o que construiu. Sabe explicar como o sistema funciona por dentro, não só clicar nos botões. A banca fareja decoreba em dez segundos.
- Que você tomou decisões conscientes. Por que separou em camadas, por que aquela regra no banco, por que a tela é assim. Decisão com motivo, não por acaso.
- Que você comunica com clareza. Consegue pegar algo técnico e explicar de um jeito que a banca acompanha, no ritmo certo, no tempo certo.
Como isso vira nota de julgamento, na prática:
| Nota | Como a apresentação se parece |
|---|---|
| 0 | Não apresenta, ou lê a tela sem explicar nada. Não demonstra o sistema. |
| 1 | Mostra telas soltas, descreve "aqui tem um cadastro, aqui uma lista", sem dizer por que nem como funciona por dentro. Estoura ou desperdiça o tempo. |
| 2 | Demonstra o fluxo funcionando e descreve o que faz. Fala com clareza, mas fica no "o quê": não justifica decisões nem mostra o que acontece por baixo. |
| 3 | Conduz uma demo em forma de história, narra o fluxo de dados pelas camadas, justifica as decisões técnicas com "porquês", administra o tempo e responde à arguição com segurança, inclusive quando não sabe. |
🎯 Isso é a UC7 na prática. "Elaborar orientações técnicas orais" é exatamente isto: falar de tecnologia de um jeito que o outro entende. É a mesma competência do inglês oral do módulo 09, agora em português e com o próprio sistema na frente. Quem treinou o vocabulário técnico do 09 chega aqui com meio caminho andado, porque os termos certos (endpoint, constraint, hash, componente) saem naturais.
2. A anatomia do Módulo D
Antes do roteiro, entender a logística, porque ela muda como você prepara:
- Slot de ~2 horas, mas a fala é até 10 minutos por competidora. O resto do tempo é preparação, ordem das apresentações e arguição da banca. Dez minutos é o teto, não a meta: melhor 9 minutos redondos do que 10 atropelados.
- Em português. O inglês entra só se você quiser citar um termo técnico, e aí é natural (o vocabulário do módulo 09), não obrigação.
- Demonstração ao vivo do próprio sistema. Não é slide sobre o sistema, é o sistema rodando. Por isso o ambiente (banco povoado, servidor no ar) faz parte da preparação.
- Arguição depois da fala. A banca pergunta. É metade do jogo: é onde os "porquês" que você guardou (§6) e o protocolo de "não sei" (§8) valem ponto.
⚠️ Pega-ratão de logística: chegar no Módulo D com o sistema do jeito que ficou no Módulo C, sem preparar o palco. Banco vazio, servidor caído, aquele bug pequeno que você ia arrumar "depois". A apresentação não é só falar: é falar com o sistema pronto pra brilhar. Meia hora de preparo de palco vale mais que meia hora de ensaio de fala.
3. A estrutura dos 10 minutos
Dez minutos evaporam. Sem estrutura, o tempo some numa parte só e falta pro resto (quase sempre falta pros destaques técnicos, que é justo o que mais pontua). Uma divisão que funciona, com marcos de relógio pra você saber se está no ritmo:
| Tempo | Parte | O que fazer |
|---|---|---|
| 0:00–0:30 | Abertura | O que é o sistema e pra quem serve. "O Wedding Pass gerencia um casamento, da lista de convidados ao check-in na porta." Situa a banca em uma frase. |
| 0:30–1:00 | Panorama técnico | A stack e a arquitetura em uma pincelada. "Front em HTML, CSS e JavaScript, uma API no back e banco MySQL, separado em camadas." |
| 1:00–5:30 | Demo da jornada | O sistema funcionando de verdade, seguindo a jornada real de um convidado. É o coração (§4). |
| 5:30–8:00 | Destaques técnicos | As decisões das quais você se orgulha, com o porquê (§6). É o trecho que mais separa 2 de 3. |
| 8:00–9:00 | Honestidade e visão | O que daria pra evoluir, o que não deu tempo mas está preparado pra receber. |
| 9:00–9:30 | Fechamento | O que o sistema resolve, em uma frase. |
| 9:30–10:00 | Buffer | Folga pra imprevisto. Se não usar, ótimo, sobra pra respirar. |
🛠️ Gambiarra boa: um marco na cabeça. Você não precisa cronometrar as sete linhas. Precisa de um marco âncora: "aos 5 minutos e meio eu tenho que estar saindo da demo pros destaques". Se nesse ponto você ainda está demonstrando, corta e avança. Um único marco no meio segura o ritmo inteiro sem você virar refém do relógio.
4. A demo que conta uma história
O erro clássico é mostrar tela por tela solta: "aqui é o login, aqui a lista, aqui o cadastro". Vira uma lista de features, e a banca desliga. A demo boa segue a jornada de um convidado, do convite até a festa, e o sistema aparece como um todo coeso.
O roteiro da jornada no Wedding Pass:
- Entra como organizadora (login). Já mostra que tem autenticação e perfis.
- Cadastra uma convidada e a coloca numa mesa. Mostra o CRUD e a máscara de telefone funcionando enquanto digita.
- Gera o convite com código único e "envia". Mostra a regra de negócio.
- Abre a página pública de RSVP (como se fosse a convidada no celular) e confirma presença. Mostra o fluxo que sai do sistema e volta.
- Vira recepcionista e faz o check-in na porta. É o clímax técnico: é onde mora a proteção contra dupla entrada.
- Fecha no dashboard, com os números se movendo (confirmados, presentes, ocupação das mesas). Mostra o todo funcionando.
🛠️ Gambiarra boa: a demo é uma narrativa, não um tour. Seguir uma convidada do convite à festa faz a banca acompanhar uma história com começo, meio e fim, em vez de decorar um menu. Fica mais claro, mais natural, e prova que o sistema é um organismo, não pedaços costurados. Escolher uma convidada de nome fácil ("vou seguir a Marina aqui") e levá-la até o fim amarra tudo.
⚠️ Pega-ratão: demonstrar cadastrando na hora, do zero, com o banco vazio. Cadastro ao vivo trava, erra digitação, e o dashboard no fim aparece vazio, sem impacto. A demo nasce de um banco já povoado (o seed do módulo 03); você cadastra uma convidada nova em cima de dezenas que já estão lá, e o dashboard fecha cheio.
5. Narrar o fluxo de dados: provar que entende por dentro
O que separa "sei usar meu sistema" de "sei como meu sistema funciona" é narrar o caminho do dado. Durante a demo, ao executar cada ação, dizer em voz alta, em uma frase, o que acontece por baixo. São 15 segundos que provam que você enxerga as camadas trabalhando juntas (o que os módulos 03 a 07 construíram). Frases prontas pra adaptar:
No login:
"Quando eu entro, o back confere a senha comparando com o hash guardado no banco, nunca com a senha em texto, e devolve um token que identifica meu perfil nas próximas telas."
No cadastro da convidada:
"Esse telefone está formatado na tela pela máscara, mas o que vai pro banco é só o número limpo. E a validação não está só aqui no front: se alguém chamar a API direto, o back barra do mesmo jeito."
No RSVP público:
"Essa página não pede login, ela abre pelo código único do convite. A convidada confirma, e o status daquele convite muda de pendente pra confirmado no banco, protegido por um ENUM que só aceita esses valores."
No check-in (o clímax):
"Aqui é o ponto sensível. Se duas recepcionistas escaneiam a mesma convidada no mesmo segundo, o sistema não pode registrar duas entradas. Eu garanto isso em duas camadas: uma verificação atômica no back e uma constraint UNIQUE no banco como última muralha. Mesmo que o back falhe, o banco não deixa passar."
No dashboard:
"Esses números não são chute nem contagem no front: são agregações que o próprio banco calcula com GROUP BY e devolve prontas. Se a festa tem 400 convidadas, a conta é do MySQL, não do navegador."
🎯 É aqui que os "detalhes de nível 3" pagam. A condição de corrida (módulo 04), o CASCADE vs RESTRICT (módulo 03), a validação no back (módulo 04), a lista branca no ORDER BY (módulo 08): a banca talvez nem teste esses detalhes na correção do código. A apresentação é onde eles viram ponto, porque você conta que pensou neles. Guardar dois ou três desses pra soltar durante a demo é ouro puro de julgamento.
6. O banco de porquês: "por que" vale mais que "o que"
Qualquer um descreve o que fez. Nível 3 é explicar por que. O hábito mais valioso da apresentação é completar, pra cada parte do sistema, a frase "eu fiz assim porque...". Esse é o banco de munição pra demo e, principalmente, pra arguição. Cada linha é uma decisão real dos módulos 03 a 08 com o porquê pronto pra falar:
| Decisão (módulo) | O porquê, pra soltar na hora |
|---|---|
DECIMAL(10,2) pra valores em dinheiro (03) |
"Porque FLOAT arredonda errado e dinheiro não pode arredondar. Um centavo perdido em relatório é erro visível." |
ENUM pro status do convite (03) |
"Porque o banco garante que só entra 'pendente', 'confirmado' ou 'recusado'. Valor inválido nem chega a ser gravado." |
Constraint UNIQUE no check-in (03, 07) |
"Porque é a última muralha contra dupla entrada. Mesmo que o código acima falhe, o banco não deixa duas presenças pro mesmo convidado." |
| Verificação atômica no check-in (04) | "Porque duas recepcionistas escaneando junto criam uma condição de corrida, e eu resolvo no back antes do banco precisar barrar." |
Hash de senha, bcrypt / password_hash (04) |
"Porque se o banco vazar, a senha não vaza junto. Ninguém, nem eu, consegue ler a senha original." |
| Validação também no back (04) | "Porque validar só no front protege quem usa a tela, não quem chama a API direto. O back nunca confia no que chega." |
| Prepared statements (04) | "Porque concatenar valor em SQL abre injection. Com parâmetro preparado, o valor nunca vira comando." |
| Autorização por perfil no middleware (07) | "Porque esconder o botão no front não impede a chamada. Quem barra de verdade é a checagem de perfil na rota." |
| Arquitetura em camadas / MVC (04) | "Porque separar responsabilidade deixa fácil achar bug e mexer numa parte sem quebrar a outra." |
Tokens de cor no :root (06) |
"Porque a identidade visual muda num lugar só. Trocar a cor da marca é uma linha, não cinquenta." |
| Os quatro estados de tela (05) | "Porque tela branca no carregamento parece travada. Carregando, vazio, erro e sucesso fazem o usuário sempre saber o que está rolando." |
| Componente de confirmação reusável (08) | "Porque ação destrutiva sem confirmar é acidente esperando acontecer, e um componente só mantém o padrão em todo lugar." |
🎯 Todo "o quê" ganha um "porque". Treinar isso é pegar cada parte do sistema e completar "eu fiz assim porque...". Numa apresentação de nível 3, praticamente toda frase de destaque técnico carrega um porquê. É o que transforma uma descrição passiva numa defesa de decisões, que é o que a banca quer ouvir de quem sabe o que está fazendo. Leve esse banco decorado; ele é 80% da arguição.
7. A arguição: perguntas prováveis e como responder
Depois da fala, a banca pergunta. Não é pegadinha, é conferir se o que você mostrou você entende. As perguntas quase sempre saem do banco de porquês (§6), então quem decorou aquilo já tem as respostas. As mais prováveis, com um modelo de resposta:
- "O que acontece se dois recepcionistas fizerem check-in do mesmo convidado ao mesmo tempo?" → "É a condição de corrida que eu tratei. A verificação no back e a constraint UNIQUE no banco garantem uma entrada só. O segundo recebe um aviso de que já entrou."
- "Onde a senha fica guardada?" → "Como hash, nunca em texto. No login eu comparo o hash, então nem eu consigo ver a senha original."
- "Se eu chamar sua API sem passar pela tela, o que acontece?" → "O back valida de novo tudo que a tela já validava e checa o perfil pela rota. O front é conveniência; a segurança está no servidor."
- "Como você garante que só o admin cria usuário?" → "Autorização por perfil no middleware da rota. Mesmo que o botão apareça, a rota barra quem não é admin."
- "Por que MySQL e não outro banco?" → "Porque os dados são relacionais, convidado pertence a mesa, convite pertence a convidado, e eu quero integridade referencial garantida por chave estrangeira. É o que a prova pede e o que o problema pede."
- "Como você testou isso?" → "Com o checklist do sabotador (módulo 08): usei o sistema de propósito errado, campo vazio, valor absurdo, dupla ação, e cada quebra virou um caso de teste que eu corrigi."
- "O que você faria diferente com mais tempo?" → responder de verdade, com visão: "Paginação na lista pra escalar melhor, e um envio de convite por e-mail de verdade. A estrutura já está pronta pra receber."
Quando você não sabe a resposta: não inventa e não congela. O protocolo:
"Isso eu não cheguei a implementar / não tenho certeza agora, mas o caminho que eu seguiria é [o raciocínio]."
Mostrar o raciocínio mesmo sem a resposta pronta vale muito mais que chutar. A banca distingue na hora quem pensa de quem decorou, e um "não sei, mas resolveria assim" é resposta de nível 3. Fingir que sabe e errar é o pior dos mundos.
⚠️ Pega-ratão: responder defensivo, como se a pergunta fosse ataque. A arguição é chance de ganhar ponto, não julgamento pessoal. "Boa pergunta, foi uma escolha consciente: eu fiz X porque Y" é uma resposta que vira a pergunta a seu favor.
8. A demo ao vivo: o que dá errado e o plano B
Demo ao vivo é a parte mais arriscada da prova inteira: pode travar, dar erro, faltar dado, cair a conexão. Não dá pra eliminar o risco, dá pra ensaiar o contorno. Blindagem em quatro camadas:
- Seed pronto (módulo 03): chegar com o banco já povoado. Dashboard vazio não demonstra nada; dashboard com convidadas variadas, mesas cheias e check-ins feitos brilha. O seed do Módulo B é o palco do Módulo D.
- Roteiro testado: ensaiar a demo no mesmo caminho, várias vezes, até sair fluida e caber no tempo. Saber exatamente qual botão clicar em que ordem. Decoreba de caminho, não de fala.
- Backup do fluxo: ter um plano pra quando a demo cair, prints ou uma gravação curta do fluxo funcionando no celular. Se o servidor morrer ao vivo, você narra por cima do backup e não perde a demonstração. É a rede de segurança que quase ninguém prepara.
- Frases de contorno prontas: "esse ponto às vezes demora, enquanto carrega eu explico o que ele faz por baixo". Transforma a espera em conteúdo, em vez de silêncio nervoso.
⚠️ Pega-ratão que já custou competição: improvisar a demo na hora, "porque eu conheço meu sistema". Conhecer o sistema não é conhecer a apresentação dele. O nervoso encurta o raciocínio, o tempo foge, a ordem embola. Demo boa é demo ensaiada, e a banca perdoa um bug ao vivo, não perdoa quem trava junto com ele.
9. Gestão do tempo e postura na fala
O tempo. O limite é rígido. Estourar é problema; deixar metade da nota por gastar tempo demais numa parte também. Ensaiar com o relógio na frente, umas três vezes, calibra o ritmo. Você descobre onde gasta demais (quase sempre a abertura e a demo) e onde corre (quase sempre os destaques técnicos, que é o que mais pontua). O marco âncora dos 5 minutos e meio (§3) resolve 90% disso.
A postura. Não precisa ser orador, precisa ser claro e seguro:
- Falar pausado. O nervoso acelera a fala. Respirar e ir devagar já melhora tudo, e ainda ganha tempo de raciocínio.
- Olhar pra banca, não só pra tela. Você está conversando com pessoas, não narrando pro monitor.
- Assumir o que não deu tempo. "Não deu tempo do filtro por data, mas a estrutura já recebe" é honesto e maduro, e vale mais que fingir que não existe ou pedir desculpa cinco vezes.
- Termos técnicos com naturalidade. Usar as palavras certas (endpoint, constraint, hash, componente, middleware) mostra domínio, desde que você saiba o que significam. É o vocabulário do módulo 09 saindo em português.
🎯 Confiança tranquila é o tom. Nem arrogante, nem inseguro. Alguém que construiu algo, entende o que construiu e está contando com clareza. A banca sente isso, e a nota de julgamento reflete. Segurança não é falar bonito, é falar sabendo por quê.
10. Checklist do dia da prova
Antes de abrir a boca, o palco tem que estar montado. A lista mínima:
- [ ] banco povoado com o seed (dezenas de convidadas, mesas, alguns check-ins já feitos)
- [ ] servidor no ar e testado no caminho exato da demo, do login ao dashboard
- [ ] backup do fluxo pronto (prints ou vídeo curto), caso a demo caia
- [ ] roteiro da jornada na cabeça: qual convidada seguir, em que ordem clicar
- [ ] o marco âncora definido ("aos 5:30 eu saio da demo")
- [ ] dois ou três porquês técnicos na ponta da língua (§6), escolhidos pra soltar na demo
- [ ] o protocolo do "não sei, mas resolveria assim" ensaiado
- [ ] respirar antes de começar; abrir devagar
11. Como o CIS enxerga a apresentação
A apresentação é transversal: é o único momento em que você toca todos os critérios de uma vez, porque narra o sistema inteiro. O que a banca de julgamento observa, e onde cada coisa pontua:
| O que a banca observa | Onde vira nota |
|---|---|
| Demonstra o sistema funcionando ponta a ponta | Funcionalidade, robustez |
| Narra o fluxo de dados pelas camadas | Domínio técnico, back e banco |
| Justifica decisões com "porquês" | Julgamento técnico (o coração do 2→3) |
| Responde à arguição com segurança, inclusive o "não sei" | Maturidade técnica, comunicação |
| Administra o tempo e conduz com clareza | Comunicação (UC7) |
| Usa o vocabulário técnico certo | Domínio, ligação com o inglês (módulo 09) |
🎯 O 2 vira 3 aqui de novo, e de forma mais barata. No código, subir de 2 pra 3 custa horas de lapidação. Na apresentação, custa preparo: um roteiro ensaiado, doze porquês decorados, um backup no celular. É a hora da prova com a melhor relação esforço/ponto de todas, e é a que mais gente ignora. Quem trata o Módulo D com o mesmo respeito que trata o código sai na frente.
12. Autoavaliação do módulo
Responder em voz alta, de preferência apresentando de verdade pra alguém com o cronômetro na mão:
- Quais as três coisas que a banca avalia na apresentação, e como isso vira nota de 0 a 3?
- Como é a logística do Módulo D (tempo de fala, idioma, arguição)?
- Descreve a estrutura dos 10 minutos com os marcos de tempo. Qual é o marco âncora?
- Por que seguir a jornada de uma convidada é melhor que mostrar tela por tela?
- Narra, em uma frase cada, o que acontece por baixo no login, no check-in e no dashboard.
- Escolhe cinco decisões técnicas do teu sistema e completa "eu fiz assim porque..." pra cada.
- Como você responde quando a banca pergunta algo que você não sabe?
- Quais as quatro camadas de blindagem da demo ao vivo?
- O que precisa estar pronto no palco antes de você começar a falar?
- Por que a apresentação é a hora da prova com a melhor relação esforço/ponto?
Fim da apostila. As dez peças estão na mesa: como a prova funciona, o ambiente, o banco, o back, o front, a UX, as funcionalidades novas, a lapidação, o inglês e a apresentação. A teoria fez a parte dela. Agora é o que apostila nenhuma faz sozinha: treinar, treinar, treinar, e usar a autoavaliação de cada módulo pra transformar teoria em nível 3. Quem chegou até aqui construiu um sistema impecável e sabe contar por que cada peça está onde está, em português e em inglês. É isso que a banca chama de nível 3. Volta pro índice sempre que precisar situar onde a gente está no cronograma.
Referências do módulo
- Plano de curso, UC7 — Elaborar orientações técnicas orais. A competência de comunicação técnica que ancora tanto este módulo quanto o 09: organizar e transmitir informação técnica de forma clara pra um público que precisa acompanhar.
- Projeto-Teste, Módulo D (Apresentação Individual) e CIS de julgamento. O descritor oficial da prova (Competições Senac RS / referência WorldSkills): o que a banca observa e como pontua de 0 a 3. É a fonte primária de tudo que este módulo cobra.
- Módulos 03 a 08 desta apostila. O banco de porquês (§6) e as narrações de fluxo (§5) saem inteiros das decisões técnicas tomadas lá. A apresentação não inventa conteúdo novo: ela conta, com clareza e no tempo, o que já foi construído.
- Módulo 09 — Inglês técnico. O vocabulário técnico e a prática de comunicação oral que fazem os termos certos saírem naturais na defesa.