rede5/gohorsejobs
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions 1
gohorsejobs/docs/CAREERJET_GAP_ANALYSIS.md

11 KiB
Raw Blame History

Gap Analysis: GoHorseJobs vs Careerjet (2026)

Objetivo

Mapear o que já existe no GoHorseJobs e o que ainda falta para alcançar um fluxo equivalente ao Careerjet, com backlog acionável.

Escopo analisado

  • Busca pública de vagas (home + listagem + detalhe)
  • Filtros e parâmetros de URL
  • Recursos de candidato (alerta, salvar vaga, currículo)
  • Recursos de empresa/recrutador

Achados principais (resumo executivo)

O que já está bom no GoHorseJobs

  1. Fluxo base de busca já existe com listagem, paginação e filtros essenciais (q, localização, tipo, modalidade).
  2. Detalhe de vaga e candidatura já cobrem o núcleo do funil candidato.
  3. Estrutura multi-perfil (candidato/recrutador/admin) e módulo de empresas já está presente.

Lacunas mais críticas para paridade com Careerjet

  1. Compatibilidade de URL estilo Careerjet (s/l) não estava completa de ponta a ponta.
  2. Filtros “Date posted”, empresa e jornada de trabalho ainda não estão consolidados no fluxo público.
  3. Alertas de vaga por e-mail ainda não estão evidentes no fluxo público principal.
  4. Página de empresas pública com foco em descoberta precisa de reforço (seguir empresa, vagas da empresa com filtros rápidos).

Melhorias implementadas neste ciclo

1) Compatibilidade de URL estilo Careerjet

  • Home agora envia também os aliases s e l (além de q e location) para facilitar compartilhamento e importação de links externos.
  • Home também envia workMode além de mode para reduzir inconsistência entre páginas.
  • Página /jobs agora consome s/l/mode/workMode além dos parâmetros antigos.

2) Correção de re-fetch para filtros avançados

  • A listagem de vagas não reexecutava busca ao alterar alguns filtros avançados (salário, moeda, ordenação, suporte a visto).
  • Ajustado para atualizar resultados ao mudar esses filtros.

3) Backend com alias Careerjet

  • Endpoint GET /api/v1/jobs passou a aceitar s como alias de termo de busca e l como alias de localização.
  • Incluído teste automatizado cobrindo esse comportamento.

Backlog recomendado (priorizado)

P0 (alta prioridade, impacto imediato)

  1. Date Posted no backend + frontend
    • Backend: aceitar datePosted (24h, 7d, 30d) e filtrar por created_at.
    • Frontend: filtro visível na listagem com UX similar ao Careerjet.
  2. Filtro por empresa no público
    • Endpoint de jobs com companyId já existe; falta UX forte para seleção por empresa.
  3. Persistência de buscas recentes
    • LocalStorage para anônimos + conta autenticada (sincronização opcional).

P1 (médio prazo)

  1. Alerta de vagas público
    • “Create alert” com confirmação por e-mail e gerenciamento no painel do candidato.
  2. Melhorias na página de empresas
    • Botão “seguir”, filtro por data e exibição de vagas com metadados completos.
  3. Salvar vaga
    • Reforçar botão “Salvar” em cards e detalhe para usuários autenticados.

P2 (evolução)

  1. Navegação Previous/Next no detalhe da vaga
  2. Origem da vaga (source link) quando for agregação externa
  3. Ranking de relevância para ordenação “relevance”

Critérios de aceite sugeridos

Busca / URL

  • Dado um link /jobs?s=Data+Engineer&l=Recife, a tela carrega com termo e local preenchidos e lista filtrada.
  • Dado um link /jobs?mode=remote, o filtro de modalidade entra como “remote”.

Filtros avançados

  • Ao alterar ordenação/moeda/faixa salarial, a lista atualiza sem refresh manual.

Backend

  • GET /api/v1/jobs?s=qa&l=Lisboa retorna os mesmos resultados que q e location equivalentes.

Plano técnico (sprint recomendado de 2 semanas)

Semana 1

  • Implementar datePosted no backend e cobertura de testes.
  • Expor filtro na UI pública e validar UX.
  • Persistir “recent searches” localmente.

Semana 2

  • Criar fluxo de alertas (CRUD mínimo + envio inicial).
  • Melhorar página pública de empresas (seguir + vagas + filtros).
  • Ajustes de observabilidade (métricas de conversão busca → clique → candidatura).

Riscos e dependências

  • Dependência de modelagem de dados para alertas e follows.
  • Qualidade dos dados de salário/empresa impacta filtros e ordenação.
  • Internacionalização: novas labels e mensagens precisam entrar no i18n.

Execução acelerada via Codex (para fechar rápido)

Se a prioridade é concluir o gap com velocidade, este é o recorte que o Codex consegue tocar de ponta a ponta com boa previsibilidade:

O que dá para entregar imediatamente (1–3 dias)

  1. Alerta de vagas público (MVP funcional)

    • Criar endpoints mínimos (create, list, delete) no backend.
    • Conectar formulário simples na listagem pública (/jobs) com CTA “Criar alerta”.
    • Disparo de e-mail inicial de confirmação + log básico de auditoria.

  2. Salvar vaga com destaque forte no funil

    • Reforçar botão “Salvar” no card e no detalhe.
    • Persistir estado no backend para autenticados e fallback local para anônimos.
    • Mostrar feedback visual claro (“vaga salva”).

  3. Melhoria rápida da página pública de empresas

    • Adicionar bloco de vagas da empresa com filtros rápidos (data/tipo/modalidade).
    • Preparar ação “seguir empresa” com endpoint e contador simples.

O que dá para adiantar em paralelo (3–5 dias)

  1. Status pós-pagamento da vaga

    • Implementar transições pending_review, active, failed_payment.
    • Garantir trilha de auditoria (quem alterou, quando, motivo).

  2. Comprovante/registro de transação

    • Gerar registro transacional persistido e exibir no painel da empresa.
    • Expor endpoint para consulta do último pagamento da vaga.

  3. QA automatizado dos critérios pendentes

    • Cobrir validações obrigatórias por etapa do fluxo de publicação.
    • Validar regras condicionais de candidatura e salário.

Sequência recomendada (ordem para reduzir risco)

  1. Alertas MVP → 2. Salvar vaga → 3. Status pós-pagamento → 4. Comprovante → 5. Empresas pública.

Definição de pronto (DoD) para cada item

  • Código implementado + testes automatizados passando.
  • Mensagens i18n em pt-BR e en para novos textos.
  • Checklist de QA correspondente marcado como concluído neste documento.

Checklist evoluído — Publicação de vaga no padrão Careerjet

Referência funcional para o portal GoHorseJobs no fluxo de publicação:
1) Detalhes da vaga → 2) Pré-visualização → 3) Informações de faturamento → 4) Pagamento.

1) Detalhes da vaga (escopo obrigatório)

Identificação da vaga

  • Título da vaga

    • Regra: obrigatório, texto claro e conciso, até 65 caracteres.
    • Validações: bloquear excesso de pontuação, abreviações promocionais e termos de marketing (ex.: “IMPERDÍVEL!!!”).

  • Localidade da vaga

    • Regra: obrigatório, uma única localidade por anúncio.
    • Validações: cidade/município válido, sem múltiplas localidades no mesmo campo.

  • País

    • Regra: obrigatório, selecionado de lista de países.
    • Dependência: país deve dirigir moeda padrão e preço do anúncio (quando aplicável no billing).

Modelo de contratação

  • Tipo de contrato

    • Opções-alvo: Permanent, Contract, Training, Temporary, Voluntary, Any.

  • Jornada de trabalho

    • Opções-alvo: Full-time, Part-time, Any.

Salário

  • Modo de pagamento

    • Opções: Salary range ou Fixed salary.
    • Validação: exibir campos condicionalmente conforme o modo.

  • Moeda

    • Regra: obrigatório quando salário informado.
    • Opções: lista internacional (USD, EUR, BRL etc.).

  • Período do salário

    • Opções: por hora, dia, semana, mês ou ano.

Conteúdo da vaga

  • Descrição da oferta
    • Regra: obrigatório, editor rico.
    • Recomendação UX: suporte a parágrafos e listas para habilidades e qualificações.

Sobre a empresa (opcional, com ocultação)

  • Nome da empresa
  • Site da empresa
  • Número de empregados
    • Opções-alvo: Self-employed, 1–10, 11–50, 51–200, 201–500, 501–1000, 1001–5000, 5001–10000, 10000+.
  • Ano de fundação
  • Descrição da empresa
  • Toggle “Ocultar dados da empresa”
    • Regra: quando ativo, ocultar bloco de empresa na visualização pública da vaga.

Recebimento de candidaturas

  • Canal de candidatura

    • Opções: E-mail, Link externo, Telefone.
    • Validação condicional:
      • E-mail: validar formato RFC básico.
      • Link externo: exigir URL HTTPS válida.
      • Telefone: validar DDI + número.

  • Requerer envio de currículo

    • Opções: Obrigatório, Opcional, Não solicitado.

  • Idioma da descrição da vaga

    • Regra: obrigatório.
    • Recomendação: idioma deve ser compatível com o país selecionado.

Extensões locais (GoHorseJobs)

  • CNPJ da empresa (Brasil)
    • Regra: opcional/obrigatório por política comercial.
    • Validação: máscara e dígitos verificadores.
  • Benefícios (multiselect)
  • Área de atuação (taxonomia do portal)

2) Pré-visualização

  • Exibir versão final da vaga com todos os metadados selecionados.
  • Indicar claramente campos ocultos (ex.: dados de empresa) antes de prosseguir.
  • Permitir voltar para edição sem perda de dados.

3) Informações de faturamento

  • Capturar dados fiscais (pessoa/empresa, documento, endereço de cobrança).
  • Exibir plano/preço por país e duração (ex.: US$130/30 dias para EUA, quando aplicável).
  • Validar consistência entre país da vaga e país de faturamento conforme regra de negócio.

4) Pagamento

  • Seleção de método de pagamento disponível no país.
  • Confirmação final com resumo: vaga + faturamento + valor.
  • Geração de comprovante/registro de transação.
  • Definição de status da vaga pós-pagamento (pending_review, active, failed_payment).

Critérios de aceite (checklist de QA)

Validação de formulário

  • Não permite avançar sem campos obrigatórios da etapa atual.
  • Exibe mensagens de erro específicas por campo.
  • Mantém dados preenchidos ao navegar entre etapas.

Regras de negócio

  • Salário fixo/range respeita lógica condicional dos campos.
  • Canal de candidatura valida apenas o tipo selecionado.
  • Idioma e país possuem validação mínima de compatibilidade.

Publicação

  • Pré-visualização reflete exatamente o payload persistido.
  • Após pagamento aprovado, vaga segue para status esperado.
  • Logs/auditoria registram criação e transição de status.