Por que a ZF System decidiu atender só óticas

A ZF System nasceu dentro de uma ótica, a ZF Vision, para resolver o problema do nosso próprio balcão: guardar a receita junto do cliente e acompanhar a ordem de serviço até a entrega do óculos. Por um tempo, porém, a ZF tentou ser também um sistema de gestão para comércio em geral: cadastro de produto, estoque, PDV, loja virtual e as integrações que todo mundo pede. Funcionava, atendia lojas de segmentos diferentes e crescia devagar.

O problema com o "em geral" é que ele parece uma vantagem até você olhar de perto.

O pedido que se repetia

A gente começou a notar um padrão nos pedidos de funcionalidade. As óticas pediam coisas que nenhum outro segmento pedia, e pediam sempre as mesmas: a ficha com o grau e a ordem de serviço que a gente já usava no balcão da ZF Vision, e mais o prazo do laboratório, o carnê próprio e o histórico de receita.

E, mais importante: quando a gente entregava, elas usavam todo dia. Não era funcionalidade de vitrine. Era o trabalho delas.

Ao mesmo tempo, os pedidos dos outros segmentos puxavam para lados incompatíveis. Restaurante quer comanda e cardápio; ferragem quer venda por metro; roupa quer grade de tamanho. Cada um desses é um sistema inteiro, e atender todos significa fazer todos pela metade.

A decisão

Em algum momento a conta ficou clara: dava para ser razoável em dez segmentos ou bom em um. Escolhemos ser bom em um.

Escolhemos ótica por três motivos concretos. Primeiro, é um segmento com necessidade real e específica: não dá para resolver com sistema genérico, e isso é justamente o que torna a especialização valiosa. Segundo, o vocabulário a gente aprendeu no balcão da ZF Vision: DP, DNP, eixo, adição, surfaçagem, refação. Terceiro, e mais decisivo: a cadeia é inteira. Ótica, laboratório e rede de ótica são três operações ligadas, e conseguir atender as três com o mesmo sistema resolve o problema de verdade, não um pedaço dele.

O que a especialização mudou na prática

Coisas que só fazem sentido quando você atende um segmento só:

• A O.S. carrega grau, DP/DNP, altura, índice e tratamento em campos separados, com conferência automática do que é impossível (eixo sem cilíndrico, por exemplo).
• O estoque separa armação (variação por cor e tamanho, na prateleira) de lente (encomenda por venda).
• O crediário calcula limite por histórico, cobra sozinho e recusa a venda antes de baixar o estoque quando a regra não fecha.
• O painel do laboratório mostra produção por etapa e fatura por ótica atendida.
• A garantia distingue adaptação e armação, com uma refação por óculos.
• O provador virtual desenha a armação no rosto do cliente pela câmera do celular, e a foto sai com a marca da ótica para ele mandar a quem ajuda a escolher. O caminho inteiro está em o que o provador virtual de óculos muda na ótica.

Nada disso é diferencial de marketing. É o que a operação exige, e nenhuma dessas seis coisas existiria se a gente ainda estivesse tentando servir a todos.

O que perdemos com isso

Clientes. De verdade: recusar segmento é recusar receita, e a gente recusou. Também perdemos a resposta fácil para "vocês atendem qualquer loja?", que hoje é "não".

O que ganhamos foi conseguir dizer sim para pedidos que antes eram "vamos ver". Quando uma ótica pede algo do dia a dia dela, a chance de já estar pronto é alta, e quando não está, entra na fila de verdade, porque serve a todos os nossos clientes, não a um.

Apagar código pronto foi a parte mais difícil

Fechar o foco não é só parar de vender para outros segmentos. É apagar o que já estava construído, e isso é bem mais desconfortável do que parece de fora.

Foi o que fizemos: o código de dois módulos inteiros saiu do sistema, um de delivery para restaurante e um de CRM para energia solar, junto com outras onze ferramentas que existiam na tela como promessa e não como produto. Nenhuma delas estava quebrada. Todas custavam alguma coisa: espaço na tela de quem só quer vender óculos, tempo de manutenção a cada atualização, e uma pergunta a mais em toda conversa de vendas.

A parte que ninguém vê é a que mais pesa: cada uma daquelas ferramentas foi construída porque alguém achou que era boa ideia, e apagá-la é admitir isso por escrito. Mas manter ferramenta que não é usada não é neutro. Ela aparece no menu, gera dúvida, e mais cedo ou mais tarde alguém pergunta por que aquilo está ali.

Como uma funcionalidade nasce aqui

Quase nada do que existe hoje veio de um planejamento de produto. Veio de um relato: alguém contando o que estava atrapalhando naquele dia, geralmente com um exemplo concreto e um horário: "ontem à tarde a vendedora fez isso e o sistema deixou".

O que fazemos com isso tem uma etapa a mais do que corrigir. Toda regra que já custou caro vira texto escrito, dentro do próprio código, explicando não só o que fazer mas por que a alternativa óbvia estava errada. E toda regra escrita ganha um teste, que primeiro precisa ser visto falhando, senão não prova nada. Teste que nunca foi visto vermelho é decoração: ele passa até no dia em que o defeito volta.

Isso deixa o trabalho mais lento e é deliberado. Num sistema em que a mesma tela toca estoque, dinheiro e nota fiscal, o erro caro raramente é o que trava: é o que continua funcionando com o número errado.

Quando dois pedidos se contradizem, e isso acontece, o desempate é declarado: ganha o que serve a mais óticas e, entre dois que servem a mesma quantidade, ganha o que mexe com dinheiro. Estoque, caixa, crediário e nota fiscal vêm antes de conforto de tela. Não é que conforto não importe: é que erro de conforto se contorna no mesmo dia, e erro de dinheiro se descobre semanas depois, quando já virou diferença de saldo. Dizer isso na hora é melhor do que a resposta educada de "vamos colocar na lista", que todo lojista já ouviu e ninguém mais acredita.

O que a gente aprendeu migrando ótica de sistema antigo

Boa parte de quem chega não está começando: está saindo de outro sistema, às vezes de um que nem existe mais no mercado. E a migração ensinou uma coisa que a gente não teria descoberto de outro jeito: o que dói perder não é o cadastro de produto.

É o histórico. O grau que aquele cliente usou há dois anos, as compras que ele fez, o que ele deve. Produto se recadastra numa tarde; histórico de receita não se recria, e é justamente ele que faz o cliente voltar em vez de pesquisar preço na loja da esquina.

Por isso a migração é feita em rodadas e conferida por amostra antes de valer: primeiro cadastro e catálogo, depois o que tem dinheiro dentro: vendas e contratos de crediário em aberto, com o saldo batendo com o que a loja tem anotado. Conferir uma amostra custa um dia; descobrir uma diferença de saldo depois de a loja já estar operando custa a confiança que a troca de sistema toda inteira depende.

E a virada não é o fim: as primeiras semanas são as que revelam o que não foi perguntado. É quando aparece o cliente com o carnê antigo na mão, a receita de 2023 que ninguém tinha migrado e o relatório que a loja usava e a gente nem sabia que existia.

Como a gente trabalha hoje

Somos uma equipe pequena e isso tem um efeito prático: quem responde no suporte é quem desenvolve. Não existe primeiro nível lendo roteiro. Isso limita o tamanho da fila, mas encurta radicalmente o caminho entre "isso aqui está atrapalhando" e a correção.

Cada funcionalidade nova nasce de uma dor que alguém contou. É por isso que a lista de recursos do sistema parece específica demais para quem vem de fora, e familiar demais para quem tem ótica.

Se você tem uma ótica ou um laboratório e quer ver funcionando, é só chamar. A gente mostra na tela, sem compromisso. E, se não for para você, a gente fala.