Carregando
Você sabe programar. Isso já é metade do trabalho. A outra metade: escolher um nicho específico, montar um projeto prático, gravar aulas curtas, e distribuir via YouTube e
Como Criar um Curso de Programação do Zero. Você sabe programar. Isso já é metade do trabalho. A outra metade: escolher um nicho específico, montar um projeto prático, gravar aulas curtas, e distribuir via YouTube e blog.
Dev tem uma vantagem injusta no mercado de cursos que a maioria não percebe: você aprende tecnologias novas constantemente. Qualquer tecnologia que você aprendeu nos últimos seis meses é algo que outras pessoas querem aprender também. Você não precisa ser expert há dez anos. Você precisa estar dois passos à frente do seu aluno.
Além disso, dev sabe o que é uma boa explicação técnica. Você já viu tutorial ruim. Você já ficou travado em documentação confusa. Você sabe o que falta na maioria do conteúdo técnico disponível. Isso é ouro. A sua frustração com o conteúdo existente é o briefing do curso que você deveria criar.
Tem também a questão da credibilidade. Quando você mostra código funcionando na tela, compartilha o repositório no GitHub, e demonstra que fez em produção o que está ensinando, a confiança é imediata. Isso é diferente de coach de marketing que ensina a vender sem ter vendido nada. Você tem a prova de trabalho.
Essa é a decisão que vai definir se o seu curso vai ter demanda ou vai ficar parado. A maioria dos devs erra aqui de duas formas: ou escolhem um tema genérico demais ('curso de JavaScript') ou escolhem um tema técnico que é relevante pra eles mas tem pouquíssima demanda de mercado.
Curso de 'React' compete com dezenas de cursos bem estabelecidos de criadores com audiência de centenas de milhares. Curso de 'React Query para aplicações com dados complexos' tem muito menos concorrência e é exatamente o que alguém no meio da carreira está procurando. Quanto mais específico, menos competição e mais fácil de vender pra quem tem o problema exato.
Nicho específico também facilita a criação do curso. Em vez de tentar cobrir React do zero ao avançado (o que daria 100 horas de conteúdo), você foca em resolver um problema específico. O curso é menor, mais rápido de criar, e mais fácil de completar pro aluno.
Antes de gravar uma aula sequer, valide a demanda. Google Trends: coloque o tema e veja se tem volume de busca crescente ou estável. Volume decrescente é sinal de que o mercado está encolhendo. YouTube: busque o tema e veja se os vídeos existentes têm boa visualização. 10 mil visualizações ou mais em vídeos sobre o assunto indica demanda real.
Comunidades como Reddit, Stack Overflow, e grupos do LinkedIn/Discord de tecnologia são fontes valiosas. Veja quais perguntas se repetem. Perguntas repetidas = problema não resolvido = oportunidade de curso. Se você vê a mesma dúvida aparecendo toda semana numa comunidade de 10 mil membros, tem audiência esperando pela solução.
Com base em demanda observável no mercado brasileiro: autenticação com JWT e refresh tokens (todo junior tem dificuldade com isso), TypeScript para quem já sabe JavaScript mas nunca fez a transição, testes automatizados com Jest e Testing Library (muito negligenciado nos cursos tradicionais), deploy e DevOps básico para devs fullstack (CI/CD, Docker, AWS básico), e APIs com Node.js e boas práticas de arquitetura (não só 'funciona', mas funciona direito).
Estrutura é onde a maioria dos devs perde tempo demais tentando ser perfeito antes de começar. Você não precisa da estrutura ideal, precisa de uma estrutura boa o suficiente pra gravar e lançar. Pode ajustar com base no feedback dos primeiros alunos.
O melhor formato pra curso de programação é construir um projeto real e completo ao longo do curso inteiro. Não exemplos soltos. Não 'agora vou mostrar esse conceito, agora esse outro'. É: vamos construir uma API de gerenciamento de tarefas com autenticação, roles, notificações por e-mail, testes, e deploy. Cada aula avança um pedaço desse projeto.
O aluno sempre sabe onde está no contexto maior. Quando você explica middleware, você explica no contexto de onde ele vai no projeto. Quando explica testes, você mostra testando o código que acabou de escrever. O contexto torna a aprendizagem mais eficaz e o aluno termina com algo funcionando que pode colocar no portfolio.
Módulos de 4 a 6 aulas, cada aula entre 8 e 15 minutos. Isso dá módulos de 40 a 90 minutos de conteúdo total, que uma pessoa consegue concluir numa sessão de estudo. Aulas acima de 20 minutos começam a perder o aluno. Se uma aula está ficando longa, é sinal de que você está cobrindo dois conceitos e devia dividir em duas aulas.
Repositório no GitHub com o código de cada aula é o material complementar mais valioso que você pode oferecer. O aluno pode comparar o código dele com o seu se travar. Exercícios com gabarito aumentam a retenção e fazem o aluno se sentir que está progredindo. Um cheatsheet em PDF com os comandos e padrões mais usados tem valor percebido alto e é fácil de criar.
Aqui vai a boa notícia que você precisava ouvir: gravar aula de programação é mais fácil do que parece porque a câmera fica em segundo plano. O aluno está olhando pra tela, não pro seu rosto. Qualidade de áudio e clareza do código importam mais do que qualquer outra coisa.
Pra aulas de programação, screencast é o formato padrão e o mais eficaz. Você mostra a tela enquanto fala explicando o que está fazendo. O aluno vê o código, o terminal, o browser, tudo em tempo real. Câmera frontal pode aparecer no início de cada módulo pra criar conexão e no final pra recapitular, mas o conteúdo principal é screencast.
OBS Studio é gratuito, open source, e capaz de tudo que você precisa. Configure uma cena com captura de tela inteira e microfone. Fonte do editor de código em 16px no mínimo (alunos vão acessar em telas menores). Tema escuro no editor (menos cansativo pra gravar). Resolução de gravação em 1920x1080. Esses são os únicos ajustes que importam no início.
Um truque de produtividade: grave um módulo completo de uma vez sem pausar pro replay. Erre, corrija, continue. Na edição você corta os erros grandes. Pequenos erros humanos (gaguejou, corrigiu um typo) na verdade ajudam na didática porque mostram o processo real de escrever código, não uma performance perfeita e irreal.
Fale em voz alta o que está pensando enquanto escreve o código. 'Aqui eu preciso verificar se o usuário existe antes de tentar fazer o hash da senha, porque se ele não existir a gente vai retornar um erro 404'. Esse tipo de pensamento explícito é o que separa um screencast útil de um screencast onde o cara só digita em silêncio.
Antecipe as perguntas. Você sabe os pontos onde os alunos vão travar porque você travou nesses mesmos pontos. Aborde explicitamente: 'aqui você pode estar pensando por que eu usei async/await em vez de .then(). Vou explicar isso já'. Isso cria a sensação de que você está lendo a mente do aluno.
O melhor curso do mundo que ninguém sabe que existe não vende nada. Distribuição é metade do trabalho e a maioria das pessoas trata como detalhe de última hora.
Duas a quatro semanas antes de lançar, comece a falar sobre o curso. Não venda ainda. Desperte curiosidade. 'Estou gravando um curso sobre X que resolve o problema Y. Quem tiver interesse em saber quando abre inscrição, deixa seu e-mail aqui'. Uma lista de espera de 200 pessoas com interesse declarado vale mais do que 2.000 seguidores genéricos.
E-mail pra lista de espera com link de compra e bônus de lançamento (acesso à comunidade, sessão de Q&A ao vivo, qualquer coisa extra). Post nas redes sociais com o link. Mensagem direta pra pessoas que demonstraram interesse explícito antes. Monitoramento das vendas por hora. Segundo e-mail no dia seguinte pra quem não abriu o primeiro. Terceiro e-mail no último dia do lançamento com lembrete do encerramento.
Depois do lançamento, peça feedback específico dos primeiros alunos. Não só 'o que acharam', mas 'onde travaram, o que faltou, o que foi mais valioso'. Esse feedback guia a melhoria do curso e vira prova social pra próximos lançamentos. Os primeiros alunos que tiveram resultado são seus maiores ativos de marketing.
Bugs que custaram bilhões