O mapa antes do código

Situação concreta: “faça um aplicativo de manutenção”

Uma gestora percebe que chamados urgentes ficam escondidos em uma planilha. Ela pede: “faça um aplicativo com inteligência artificial para priorizar as ordens de serviço”. A frase parece clara, mas ainda não diz quem usa o sistema, o que significa urgente, de onde vêm os dados, qual erro é inaceitável ou como saber se a prioridade ficou correta. “Aplicativo” e “inteligência artificial” já são propostas de solução. O problema talvez possa ser reduzido primeiro com uma regra simples, uma mudança de processo ou um formulário melhor.

Começar pelo código nesse momento transforma suposições em comportamento. Um programador pode entender “urgente” como ordem mais antiga; a gestora, como risco à vida; o técnico, como equipamento parado. Todos trabalham, mas constroem coisas diferentes. Pensamento computacional é o conjunto de práticas usado para tornar essa situação manipulável: separar o problema da solução, destacar informações relevantes, dividir o trabalho e criar uma forma de verificar o resultado.

Pré-requisitos e objetivos

Você não precisa saber programar. Precisa apenas reconhecer uma sequência de trabalho do cotidiano, como abrir um chamado ou organizar uma fila. Ao final, deverá conseguir:

1. explicar uma necessidade sem citar uma tecnologia;
2. identificar entrada, saída, regras e limites;
3. dividir o processo em partes que ainda entreguem valor;
4. executar uma regra pequena em Python;
5. mostrar evidência de que ela acerta e de como ela falha.

Vocabulário antes da prática

• Situação é o que se observa: “chamados críticos esperam demais”.
• Problema é uma diferença relevante entre o estado atual e o desejado: “a triagem não identifica risco à vida antes da distribuição”.
• Entrada é o dado conhecido quando o processo começa, como risco informado e equipamento afetado.
• Saída é o resultado produzido, como prioridade e responsável.
• Estado é a informação que muda ao longo do tempo, como “aberta”, “em atendimento” e “concluída”.
• Restrição limita soluções possíveis: a decisão deve sair em até dois minutos.
• Invariante é uma propriedade que nunca pode ser violada: risco à vida sempre recebe prioridade máxima.
• Algoritmo é uma sequência finita e não ambígua de passos.
• Heurística é uma regra útil que pode errar, como procurar a palavra “fumaça” na descrição.
• Hipótese é uma afirmação que pode ser contrariada por evidência: “essa regra reduz o tempo de resposta”.
• Oráculo é o mecanismo usado para decidir qual resultado era esperado: uma regra aprovada, um cálculo conhecido ou revisão de especialistas.
• Caso de borda ocorre no limite: entrada vazia, número zero, duplicidade ou duas alterações simultâneas.
• Contraexemplo é um caso que derruba uma afirmação geral.

Modelo mental: um mapa útil, não uma cópia da realidade

Pense em um mapa de metrô. Ele preserva estações, linhas e conexões, mas omite árvores, fachadas e distâncias exatas. Essa remoção deliberada chama-se abstração. Ela reduz detalhes para responder a uma pergunta. O mesmo mapa falha para quem precisa saber a distância a pé ou a existência de elevador. Portanto, não existe “a abstração correta” isoladamente; existe uma abstração adequada a uma finalidade declarada.

O diagrama não afirma que todo projeto é linear. Na prática, novas evidências fazem a equipe voltar e reformular o problema. Ele também não substitui conversas com usuários: dados descrevem parte do trabalho, enquanto pessoas conhecem exceções, consequências e atalhos informais.

Progressão: da névoa a um contrato verificável

1. Nomeie ator e consequência

Pergunte “quem sente o problema?” e “o que acontece se nada mudar?”. No exemplo, o ator primário é o supervisor de manutenção; técnicos e ocupantes também são afetados. A consequência não é “a planilha fica feia”, mas “um risco pode esperar enquanto uma solicitação cosmética é atendida”. Isso muda a prioridade do projeto.

2. Delimite evento, entrada e saída

O evento é a criação de uma ordem. As entradas mínimas podem ser risco à vida, equipamento parado e horário de abertura. A saída inicial é uma classe de prioridade. Nome, fotografia e custo talvez sejam relevantes depois, mas não são necessários para testar a primeira regra.

3. Declare invariantes e fora de escopo

“Risco à vida sempre vem primeiro” é invariante. “Recomendar o técnico” pode ficar fora do primeiro incremento. Fora de escopo não significa sem importância; significa que não será prometido nesta entrega.

4. Escreva exemplos antes da implementação

Uma ordem com risco à vida deve retornar prioridade 0. Equipamento parado sem risco retorna 1. Uma lâmpada queimada retorna 2. Inclua também descrição vazia, horas negativas e campos ausentes. Exemplos tornam palavras discutíveis em resultados comparáveis.

5. Decomponha por valor observável

Decomposição não é simplesmente “primeiro todo o banco, depois toda a API, depois toda a tela”. Uma fatia útil atravessa o necessário: receber uma ordem, calcular prioridade e exibir o resultado. Ela pode ser demonstrada e corrigida. Depois outra fatia registra justificativa; outra permite revisão humana. Cada uma preserva a visão do todo.

6. Escolha a solução mínima e a evidência

Se uma regra explícita satisfaz os exemplos, ela é uma referência melhor que um modelo complexo. Registre entradas, resultado esperado, resultado observado e versão da regra. Só acrescente complexidade quando uma falha medida justificar.

Antes e agora

Antes, era comum escrever uma especificação extensa, entregar por camadas técnicas e testar apenas no fim. Isso ainda pode ser necessário em ambientes contratuais, mas adia descobertas. Hoje, equipes maduras combinam documentação suficiente com pequenas fatias verticais, protótipos para dúvidas específicas e testes contínuos. A mudança importante não é “não documentar”; é tratar documentação como hipótese verificável e atualizável.

Com IA generativa, ficou fácil produzir muito código a partir de uma frase. Isso aumenta, e não reduz, a necessidade do mapa. Um modelo pode completar lacunas de modo convincente sem conhecer as regras reais. A IA ajuda a propor perguntas, casos de borda e implementações; pessoas responsáveis continuam definindo consequências, permissões e critérios de aceite.

Exemplo simples em código, bloco a bloco

Crie um arquivo chamado prioridade.py. A primeira parte define o formato aceito:

from dataclasses import dataclass

@dataclass(frozen=True)
class Ordem:
    risco_vida: bool
    equipamento_parado: bool
    horas_aberta: int

dataclass cria uma estrutura de dados. frozen=True impede alteração acidental depois da criação. Cada campo possui um tipo esperado. Isso não valida todas as regras, mas torna o contrato visível.

Agora valide e calcule:

def calcular_prioridade(ordem: Ordem) -> int:
    if ordem.horas_aberta < 0:
        raise ValueError("horas_aberta não pode ser negativa")
    if ordem.risco_vida:
        return 0
    if ordem.equipamento_parado:
        return 1
    return 2

A validação recusa uma entrada impossível. O primeiro if de negócio protege o invariante. A ordem das condições importa: se equipamento parado fosse verificado antes, uma ordem com os dois sinais receberia 1, violando a regra de segurança.

Por fim, acrescente exemplos executáveis:

assert calcular_prioridade(Ordem(True, True, 0)) == 0
assert calcular_prioridade(Ordem(False, True, 3)) == 1
assert calcular_prioridade(Ordem(False, False, 72)) == 2

try:
    calcular_prioridade(Ordem(False, False, -1))
except ValueError:
    print("entrada inválida recusada corretamente")

No terminal, entre na pasta do arquivo e execute python prioridade.py. Ausência de mensagem nos assert significa que passaram; a mensagem final confirma a recusa. Um teste não prova ausência total de defeitos. Ele demonstra apenas os casos e propriedades examinados.

Aplicação em manutenção e ERP

Um sistema de planejamento de recursos empresariais (ERP, do inglês enterprise resource planning) pode ser a fonte oficial das ordens. A nova aplicação não deve escrever diretamente nas tabelas do ERP só porque conhece o banco. Uma integração aprovada pode receber a ordem por uma interface de programação de aplicações (API), calcular uma recomendação e devolver prioridade mais justificativa.

A regra precisa de dono: segurança do trabalho define risco; manutenção define impacto operacional; tecnologia implementa e registra. Se a prioridade for automática, guarde versão da regra, entradas utilizadas e revisão humana. Se for apenas recomendação, a tela deve dizer isso. Dados históricos podem refletir atrasos e vieses; “o que ocorreu antes” não é automaticamente “o que deveria ocorrer”.

Quando falha: diagnóstico, não adivinhação

Imagine que uma ordem com risco retornou 1. Preserve o caso exato sem dados pessoais, execute-o novamente e localize a primeira divergência:

1. Sintoma: esperado 0, observado 1.
2. Entrada: risco_vida=True, equipamento_parado=True.
3. Hipótese: a condição de equipamento foi avaliada antes.
4. Experimento: teste somente essa combinação.
5. Correção mínima: restaurar a precedência do invariante.
6. Proteção: manter o teste para impedir regressão.

Alterar pesos aleatoriamente poderia esconder o sintoma e criar outro. Também investigue a camada anterior: talvez a interface tenha enviado a palavra "sim" em vez do booleano true. A primeira divergência pode estar na coleta, transformação ou regra.

Segurança, privacidade e custo

Colete somente os dados necessários à decisão. Não copie nomes, telefones ou fotografias para logs de teste. Restrinja quem altera regras e quem vê ordens sensíveis. Uma recomendação de prioridade não deve executar ações perigosas sem autorização. Mantenha alternativa manual quando o serviço estiver indisponível e registre alterações para auditoria.

Complexidade também tem custo: mais componentes significam mais falhas, operação e treinamento. Uma regra legível pode ser mais segura que IA quando o domínio possui poucas regras estáveis. Use IA somente se avaliações mostrarem ganho e houver controle para respostas erradas.

Exercício guiado

Escolha “impedir cadastro duplicado de equipamento”. Escreva:

1. ator e consequência do erro;
2. evento, entradas e saída;
3. dois invariantes;
4. três exemplos válidos e três contraexemplos;
5. duas soluções diferentes, sem escolher ainda;
6. evidência que permitiria comparar as soluções.

Em seguida, destaque palavras ambíguas. “Duplicado” significa mesmo número patrimonial, mesmo número de série ou nomes parecidos? Pergunte quem decide nos conflitos. Revise o cartão até outra pessoa prever corretamente os seis resultados.

Desafio e evidência de competência

Modele a priorização sem usar código. Entregue um problem-card.md, uma tabela com dez casos e um fluxograma. Depois troque a regra: equipamento de combate a incêndio parado também deve receber 0. Marque quais exemplos mudam e quais permanecem. A evidência de competência é o conjunto reproduzível, não a afirmação “entendi”.

Critérios de aceite:

• ator, consequência, entrada, saída e fora de escopo estão explícitos;
• todo termo ambíguo possui definição ou pergunta aberta;
• cada invariante tem ao menos um caso positivo e um negativo;
• outra pessoa obtém os mesmos resultados;
• limitações e decisão seguinte estão registradas.

Conclusão e recuperação ativa

Pensamento computacional começa antes da linguagem. Você reduz a névoa, cria uma abstração adequada, decompõe por resultados observáveis, implementa a menor referência e compara comportamento com evidência. Feche o capítulo e explique: qual é a diferença entre problema e solução? Quando uma abstração se torna omissão perigosa? Por que uma heurística não deve decidir sozinha em um caso de alto impacto? Se não conseguir dar um exemplo próprio, retorne à situação concreta.

Fontes oficiais e primárias

• ACM, IEEE-CS e AAAI — Computer Science Curricula 2023: competências, práticas e contexto curricular contemporâneo.
• Edsger W. Dijkstra — Notes on Structured Programming: fonte primária sobre decomposição e raciocínio sobre programas.
• Python — More Control Flow Tools: referência oficial para condicionais e funções usadas no exemplo.