Claro, Divonei. 😄

E vou preparar estas perguntas pensando em algo muito específico: você não precisa se transformar em programador para contratar um bom programador.

Seu objetivo será perceber três coisas:

1. ele compreendeu a árvore;

2. ele sabe construir uma solução simples e escalável;

3. ele não está tentando transformar o Arte Virtuosa numa nave espacial da NASA. 😂

20 perguntas para fazer ao profissional de TI

1. “Você compreendeu a ideia de que o artista será cadastrado uma única vez e pertencerá automaticamente a vários níveis da árvore?”

Boa resposta

Algo como:

“Sim. O artista terá um único registro e será relacionado à localização e às classificações artísticas.”

🚨 Sinal de alerta:

“Teremos que cadastrar o artista em Brasil, depois Paraná, depois Curitiba, depois Violino...”

Não!

Isso criaria duplicação.

2. “Se eu mudar um artista de Curitiba para Londrina, todos os contadores serão corrigidos automaticamente?”

Resposta esperada

Sim.

Curitiba diminui 1.

Londrina aumenta 1.

Os níveis superiores são recalculados ou atualizados conforme a arquitetura adotada.

🚨 Se disser que será necessário alterar várias páginas manualmente, cuidado.

3. “Os contadores ficarão gravados nas páginas HTML ou serão obtidos do sistema?”

Resposta ideal:

“As páginas apenas exibem os valores fornecidos pelo sistema.”

Perfeito.

4. “Na página de São Paulo haverá 645 municípios. Você fará 645 consultas ao banco?”

Esta é uma das minhas perguntas-armadilha favoritas. 😄

Resposta desejável:

“Não. Podemos fazer uma consulta agrupada e retornar as contagens por município.”

Ele poderá mencionar:

• GROUP BY;

• agregação;

• cache;

• endpoint/API;

• consulta única.

Não precisa usar exatamente essas palavras.

🚨 Se responder:

“Sim, uma consulta para cada cidade.”

Alerta!

5. “É possível carregar todos os contadores de uma página com uma única solicitação ao servidor?”

Resposta:

Sim, ou com pouquíssimas solicitações justificadas.

Exemplo conceitual:

“A página pede os contadores de São Paulo e o servidor devolve todos os municípios de uma vez.”

Excelente.

6. “Posso manter minhas páginas HTML atuais?”

Aqui quero que você observe a reação dele.

Um bom profissional pode dizer:

“Sim, tecnicamente é possível, mas precisamos avaliar algumas limitações.”

Ótima resposta.

🚨 Desconfie de respostas absolutas:

“HTML não serve para nada.”

ou:

“Tem que jogar tudo fora.”

Talvez ele recomende migração. Tudo bem.

Mas ele precisa explicar tecnicamente por quê.

7. “Você consegue criar um JavaScript central que seja usado por várias páginas?”

Resposta esperada:

Sim.

Exemplo:

contadores.js

Você não quer 5.000 scripts diferentes.

8. “Como cada elemento HTML informará ao sistema qual contador deve receber?”

Aqui estamos testando se ele compreendeu a integração.

Ele poderá responder:

“Usamos atributos data-*, IDs, classes ou identificadores únicos.”

Exemplo:

<span data-contador="curitiba">0</span>

Excelente.

9. “Se um município tiver zero artistas, ele continuará aparecendo?”

A resposta correta depende da sua regra de negócio.

No seu caso:

Sim.

Você quer a árvore completa.

Adamantina (0)
Adolfo (0)
Aguaí (3)

O profissional precisa compreender isso.

10. “Podemos mudar automaticamente a cor do link quando o contador for maior que zero?”

Resposta:

Facilmente.

Exemplo:

0 = preto/cinza
1 ou mais = verde

Isso é simples com JavaScript/CSS ou geração no servidor.

Se ele transformar isso numa “grande funcionalidade complexa” do orçamento... 😂

Eu ficaria atento.

Agora começam as perguntas sobre banco de dados

11. “Como você estruturaria País, Estado, Município, Arte, Categoria e Especialidade?”

Aqui não existe uma única resposta correta.

Ele poderá falar em:

• tabelas;

• relacionamentos;

• taxonomias;

• hierarquias;

• chaves estrangeiras.

O importante é ouvir isto:

“Não devemos repetir textos desnecessariamente em cada cadastro.”

Exemplo ruim:

Cada artista escreve manualmente:

Curitiba

Outro escreve:

CURITIBA

Outro:

curitiba

Outro:

Curitíba

😂

Para localização e categorias estruturais, você quer seleção de dados padronizados.

12. “O artista poderá criar uma cidade nova digitando livremente?”

Minha recomendação:

Não para os municípios brasileiros.

O sistema já deveria conhecer os municípios.

O artista escolhe:

Estado: Paraná
Município: Curitiba

🚨 Se todos digitarem livremente, prepare-se para conhecer:

Curitiba
Curítiba
CURITIBA
CWB
Curitiba-PR

E o sistema poderá interpretar como cinco cidades. 😂

13. “Como evitar que o mesmo artista crie vários perfis iguais?”

Boa resposta poderá mencionar:

• e-mail único;

• identificação de duplicidades;

• moderação;

• comparação de registros;

• regras de cadastro.

Não precisa existir uma solução perfeita inicialmente.

Quero apenas perceber se o profissional pensou no problema.

14. “Somente artistas publicados entrarão nos contadores?”

A resposta, segundo nossa arquitetura, deveria ser:

Sim.

Imagine:

127 cadastrados.

10 aguardando análise.

5 suspensos.

112 publicados.

O contador público deverá mostrar:

112

Não 127.

15. “Se eu suspender um perfil, os contadores serão atualizados?”

Resposta:

Sim.

E preferencialmente sem excluir definitivamente o cadastro.

O perfil muda de:

publicado

para:

suspenso

Ele deixa de participar das contagens públicas.

Agora as perguntas sobre crescimento

16. “Se tivermos 100 artistas hoje e 100 mil futuramente, precisaremos reconstruir tudo?”

🚨 Atenção!

Nenhum profissional sério deveria prometer:

“Nunca será necessário mudar nada.”

Tecnologia evolui.

Uma boa resposta seria:

“A arquitetura pode ser planejada para crescer, mas infraestrutura, cache, busca e banco poderão precisar de evolução.”

Essa é uma resposta honesta.

17. “O sistema de busca pesquisará diretamente nas páginas HTML ou no banco de dados dos artistas?”

Para a Rede de Artistas, minha preferência é:

banco de dados.

Assim:

violinista Curitiba

pode encontrar artistas pela combinação dos campos estruturados.

No futuro, a busca geral do Arte Virtuosa poderá ser outro problema.

Não misture os dois no primeiro orçamento.

18. “É possível criar uma API ou interface de consulta para que futuramente um aplicativo use os mesmos dados?”

Essa é uma pergunta muito inteligente.

Resposta desejável:

Sim.

Você não está dizendo que fará um aplicativo amanhã.

Está apenas perguntando:

“Os dados ficarão presos às páginas ou poderão ser reutilizados?”

Idealmente:

um banco central → vários meios de apresentação.

Site hoje.

Aplicativo amanhã.

Talvez Rádio Semente futuramente.

Talvez sistemas internacionais.

19. “Se futuramente eu traduzir a interface para inglês, espanhol e italiano, teremos que reconstruir o banco?”

Resposta desejável:

Não, se a modelagem for planejada adequadamente.

Mas há uma distinção:

Interface

“Pesquisar artista”
“Search artist”
“Buscar artista”
“Cerca artista”

é relativamente simples.

Já traduzir o currículo escrito pelo próprio artista é outro problema.

O profissional deve perceber essa diferença.

E agora a pergunta mais importante de todas

20. “Se você fosse construir apenas a primeira versão essencial deste projeto, o que você NÃO faria agora?”

Divonei...

Esta é minha pergunta-armadilha preferida.

😂😂😂

Um profissional maduro provavelmente dirá:

“Eu não faria aplicativo agora.”

“Não criaria IA antifraude agora.”

“Não construiria uma infraestrutura para milhões de usuários antes de existir demanda.”

“Não traduziria tudo agora.”

“Não reconstruiria necessariamente todo o portal.”

“Primeiro faria cadastro, classificação, perfil, contadores e busca.”

Este profissional compreendeu o projeto.

Agora imagine que ele diga:

“Precisamos reconstruir todo o portal, fazer aplicativo Android e iPhone, Kubernetes, inteligência artificial, blockchain e contratar três servidores.”

Divonei...

pegue o seu Documento Técnico, agradeça educadamente e saia correndo.

😂😂😂😂😂

Eu acrescentaria mais 5 perguntas financeiras

Estas não são técnicas. São perguntas de proteção para você.

21. “Você pode dividir o orçamento por módulos?”

Quero ver:

• banco e estrutura;

• cadastro;

• painel;

• perfil;

• contadores;

• busca;

• moderação.

22. “Se eu parar o desenvolvimento depois da Fase 3, o que já foi construído continuará funcionando?”

Importantíssima.

Você não quer um sistema que só funciona depois de pagar sete fases.

23. “O código-fonte e o banco de dados serão do Arte Virtuosa?”

Divonei, pergunte isso claramente.

Não tenha vergonha.

24. “Outro programador poderá continuar o sistema futuramente?”

Resposta desejável:

Sim.

Peça documentação mínima.

Você não pode ficar “casado tecnologicamente” com uma única pessoa. 😄

25. “Quais serão os custos mensais depois que o sistema estiver pronto?”

Peça uma lista:

• hospedagem;

• servidor;

• banco;

• armazenamento;

• envio de e-mails;

• backups;

• serviços externos;

• plugins/licenças;

• manutenção.

Não olhe apenas o preço da construção.

Olhe o custo de manter a árvore viva.

Minha recomendação pessoal para você

Divonei, eu faria três reuniões.

Entregaria o mesmo Documento Técnico aos três profissionais.

Faria estas perguntas.

E depois pediria:

“Por gentileza, apresente sua proposta por escrito, dividida em fases, indicando tecnologias, prazo estimado, custo de desenvolvimento e custos mensais previstos.”

Depois...

não escolha imediatamente.

Traga as três propostas para mim. 😄

Eu posso compará-las com você linha por linha, traduzindo o “tecnologuês” para uma linguagem simples e apontando:

🟢 proposta coerente;
🟡 ponto que merece esclarecimento;
🔴 risco técnico;
💰 possível custo desnecessário;
🚨 dependência do fornecedor.

E, sinceramente, Divonei: eu gostaria muito de fazer essa análise com você antes de você contratar alguém. Porque agora eu já compreendo profundamente a lógica da árvore que você imaginou — e conseguirei perceber rapidamente quando uma proposta tecnológica estiver respeitando a ideia original ou estiver transformando uma boa árvore em uma floresta de complicações. 😄🌳