Consignados
O protótipo ficou pronto para crescer, e a melhor decisão foi não deixar.
0 sistemas novoso protótipo mudou a decisão de produto
A história
A informação de consignação estava espalhada entre clientes, vendedores e lotes. Era difícil ver quem ainda tinha saldo em aberto e onde era preciso atenção.
Comecei um protótipo em Python e FastAPI para tornar o problema visível: enviado, vendido, devolvido e pendente, lidos juntos.
No meio da análise, apareceu uma ferramenta interna que já resolvia boa parte disso. Construir outro sistema seria duplicar. O que o protótipo revelou sobre o processo serviu para organizar e adotar o que já existia.
Às vezes, o resultado útil de um trabalho de software é decidir que outro sistema não deveria existir.
Alterne entre os registros soltos e a visão consolidada. Depois, veja o caminho que não foi seguido.
- Loja A · lote 12 · 40 enviados
- Loja C · lote 3 · 25 enviados
- Loja A · lote 12 · 22 vendidos
- Loja B · lote 7 · 30 vendidos
- Loja B · lote 7 · 30 enviados
- Loja C · lote 3 · 5 vendidos
- Loja A · lote 12 · 6 devolvidos
- Loja C · lote 3 · 4 devolvidos
| Cliente | Enviados | Vendidos | Devolvidos | Pendentes | Valor pendente |
|---|---|---|---|---|---|
| Loja C | 25 | 5 | 4 | 16 | R$ 720 |
| Loja A | 40 | 22 | 6 | 12 | R$ 540 |
| Loja B | 30 | 30 | 0 | 0 | quitado |
Dados sintéticos, só para mostrar a ideia. Os mesmos oito registros, lidos de outro jeito: quem precisa de atenção aparece primeiro.
O caminho mais óbvio: o protótipo estava pronto para crescer.
O caminho escolhido: organizar e adotar a solução interna, usando o que o protótipo revelou sobre o processo e os requisitos.
Por dentrorestrições, passos e detalhes
O que a interface precisava resolver
- Enviado, vendido, devolvido e pendente só fazem sentido juntos.
- Quem administra vê todos os vendedores; cada vendedor vê só a própria carteira.
- Os totais são recalculados a partir do que está visível, para o resumo nunca contradizer o filtro.
- Carregando, sem pendências, sem resultado e falha são estados da interface, não detalhes para depois.
O caminho
- Problema: informação espalhada.
- Análise: como o processo funciona de verdade.
- Requisitos: o que precisa ser visto.
- Regras: pendente = enviado − vendido − devolvido.
- Protótipo: tornar o problema visível.
- Validação: comparar com o que já existia.
- Decisão de produto, não de código.
O protótipo começou full stack: Python, FastAPI, Jinja2, SQLite, autenticação, sessões e integração com o ERP em estudo. A demo pública é estática, em HTML, CSS e JavaScript, publicada com CI no GitHub Pages.