Gestão de condomínio

Vizzo

Plataforma modular de gestão de condomínio para nove públicos. Conduzi a descoberta, o escopo, a arquitetura de permissões e as telas. A pesquisa saiu de documentos reais de um prédio de três torres: convenção, regimento, atas e doze meses de balancete.

Papel: Product Designer, PM e PO. Descoberta, definição de escopo, priorização, arquitetura de acesso e desenho das telas.
O que eu fiz: Pesquisa nos documentos de um condomínio real, catálogo de módulos, matriz de permissões, fluxos e interface, e o acompanhamento da entrega até o ar.
Alcance: Morador e inquilino, portaria e segurança, limpeza e manutenção, zeladoria, síndico e subsíndico, conselho, administradora, contabilidade.
Formato: Plataforma modular. Cada módulo funciona sozinho: portaria, rotina de colaboradores, financeiro, moradores, segurança.

Telas do ambiente de desenvolvimento de um produto em construção, com contas e dados fictícios. O condomínio que serviu de base para a pesquisa não é nomeado, e nenhum número financeiro dele aparece aqui.

Tela inicial do Vizzo. Uma barra lateral agrupa os itens em Condomínio, Portaria, Administração e Configurações; o corpo repete os mesmos grupos em cartões. — Os públicos são **seções da navegação**, e não uma tela de administrador com tudo dentro. Quem entra vê o próprio recorte do prédio: o que não foi liberado não aparece, e nada aqui depende de pedir para o síndico.

01 O contexto e quem era afetado

Nove públicos com necessidades opostas.

Num condomínio o software chega junto com o posto de trabalho e com a chave do apartamento. Ninguém escolheu a ferramenta, e ninguém abre chamado quando ela atrapalha: para de usar e resolve por WhatsApp.

Os nove públicos querem coisas incompatíveis entre si:

a portaria precisa saber quem pode entrar; o morador não quer que a portaria decida isso por ele;
o síndico precisa prestar contas; a administradora precisa dos mesmos números em outro formato;
a contabilidade precisa da folha; a equipe precisa saber a que horas sai;
o conselho precisa conferir; ninguém quer dar ao conselho o poder de alterar.

A saída comum do mercado é uma tela de administrador com tudo dentro, e todo mundo pedindo para o administrador. O resultado é o zelador com a senha do síndico, e nenhum registro de quem fez o quê.

02 O que eu descobri

Quatro descobertas, de documento e de campo.

Pesquisa documental e de campo num condomínio real de três torres: convenção de 33 páginas registrada em cartório, regimento interno, seis atas de assembleia e doze competências de balancete, com 691 lançamentos.

Descoberta 01. Os documentos que governam o prédio não respondem perguntas. A convenção rege três pessoas jurídicas: o residencial e dois conjuntos comerciais, cada uma com síndico, conta e rateio próprios. As três repetem a mesma estrutura de capítulos, então “de quantos anos é o mandato do síndico?” tem três respostas no mesmo arquivo, e duas são de outra pessoa jurídica. A regra da piscina em vigor nem está no regimento de 2017: está numa ata de 2025.

Descoberta 02. Quem trabalha no prédio não senta. A portaria atende de pé, com alguém esperando do outro lado do balcão. A limpeza se move entre torres, com uma mão livre no máximo. Nenhum dos dois lê tabela de cinco colunas no celular, nem acerta caixa de seleção de 18 pixels.

Se o sistema recusa a entrega porque o morador esqueceu o código, o pacote sai do balcão assim mesmo, e ninguém registrou que saiu.

Descoberta 03, e é a tese do produto. Vale igual para a batida de ponto que o GPS recusa: alguém anota o horário no papel e digita depois. Sobra um sistema correto na aparência, que não sabe o que aconteceu.

Descoberta 04. A pergunta de acesso não é quem pode ver, é quem pode escrever. Foi ela que reorganizou a arquitetura. “A portaria pode ver a lista de convidados?” é fácil e pouco útil. “A portaria pode acrescentar um nome à lista?” decide se a lista prova alguma coisa.

03 Por que esse primeiro

Portaria antes do financeiro.

O financeiro é o primeiro pedido do síndico e o que menos muda a vida de quem mora: o balancete já existe, só está num PDF que ninguém abre. Portaria e normas são o contato diário com o prédio, e é ali que o sistema ganha ou perde a equipe. Um sistema que a portaria abandona na primeira semana não chega ao financeiro.

Duas coisas ficaram fora de propósito: o módulo de unidades, que troca o rateio médio pelo exato, e o de avisos. Os dois estão no catálogo marcados como não implementados, e toda tela que depende deles declara o que ainda não faz. Por isso o custo por apartamento aparece rotulado como média, e não como rateio.

04 O formato do produto

Cinco módulos que funcionam sozinhos.

Prédio pequeno não compra plataforma inteira, e prédio grande não troca tudo de uma vez. O sistema é um catálogo de módulos: liga o que o condomínio precisa agora, e o resto entra depois, sem migração e sem segunda base de dados.

O catálogo é uma estrutura do sistema, não embalagem comercial: é dele que a navegação nasce. Cada item da barra lateral é um módulo liberado, e o que não foi contratado não aparece para ninguém. Não fica cinza nem pede upgrade: não existe.

Portaria

Encomendas com código de retirada, visitantes do dia e a lista de convidados que o morador escreve. É o módulo de uso diário da equipe, e o que decide se o sistema fica de pé no prédio.
Rotina de colaboradores

Checklist por ambiente e por turno, ocorrências com foto, ponto com espelho e a escala de quem trabalha no prédio. Roda sem um morador sequer cadastrado.
Financeiro

O balancete da administradora classificado, competência a competência, com plano de contas, comparação entre meses e simulador. Entra sem depender da portaria.
Moradores

Cadastro com dependentes, veículos e pets declarados pelo próprio dono, reserva de espaços e as normas do prédio em texto pesquisável. É o módulo que o morador enxerga.
Segurança

A camada que atravessa as outras quatro: matriz de permissões por módulo, trilha de auditoria com o antes e o depois, e registro de ponto que o banco recusa alterar.

Telas A mesma barra lateral, em dois contratos de acesso

Barra lateral do sistema na conta da síndica: dezoito itens, agrupados em Condomínio, Portaria, Administração e Configurações. — **A síndica** alcança as quatro frentes, e os grupos da barra são os módulos liberados para ela.

Barra lateral do sistema na conta da portaria: seis itens, sem o grupo Administração. — **A portaria** vê seis itens. O grupo Administração não fica desabilitado: ele não é desenhado, e o vazio embaixo mostra que não há porta escondida.

O catálogo também lista o que não existe. Dois módulos estão marcados como não implementados, e toda tela que depende deles declara o que ainda não faz. É por isso que o custo por apartamento aparece rotulado como média, e não como rateio.

Painel financeiro com caixa, receita, despesa e resultado do mês, fundo de reserva e despesa por unidade, e um gráfico de receita contra despesa em doze meses. — O eixo do gráfico começa em R$ 71.000,00, e não em zero, que é o que deixa o cruzamento visível. A escolha está escrita embaixo dele, junto com o número de meses em que a despesa passou a receita. O cartão de despesa por unidade se rotula sozinho: **média entre 144 unidades, não é rateio**.

Tela de rotinas do dia com contadores de programados, concluídos, pendentes, atrasados e não realizados, e os checklists de cada ambiente abaixo. — **Pendente** e **atrasado** são contados em colunas separadas, e **não realizado** é uma terceira. Juntar as três num “não feito” apagaria a única diferença que interessa a quem gerencia: o que ainda dá tempo, o que passou da hora e o que a equipe declarou que não foi feito.

05 Decisões de design

Cinco decisões de design, e a origem de cada uma.

5.1

Registrar em vez de bloquear

A tese virou regra de implementação, aplicada igual no produto inteiro:

retirada de encomenda sem o código é permitida, e fica marcada como não conferida;
o perímetro do ponto classifica a batida em cinco estados (dentro, fora, impreciso, sem coordenada, permissão negada) e nunca recusa nenhuma;
o totem da portaria é o caminho normal, e a batida por celular é exceção contada;
a chegada de convidado é aceita até seis horas antes ou depois do evento, porque janela exata empurra o registro para fora do sistema;
a chegada tem desfazer. O erro típico do balcão é clicar no nome de cima, e sem desfazer a correção vira “deixa assim”.

Vem da descoberta 03

Telas O ponto, de quem bate e de quem confere

Tela de celular do ponto, com um botão grande de registrar entrada, o total de horas do dia e um botão para avisar que esqueceu de bater ou bateu errado. — **Quem bate** tem um botão só e, embaixo dele, *“esqueci de bater, ou bati errado”*. O erro tem caminho dentro do sistema. Sem ele, a correção vira papel no bolso da encarregada.

Espelho de ponto de uma funcionária. Dois avisos acima da tabela: uma marcação fora do perímetro e onze marcações fora do totem da portaria. — **Quem confere** recebe os dois avisos acima da folha: **uma marcação fora do perímetro** e **onze fora do totem**. Nenhuma foi recusada, e todas estão contadas.

5.2

Quem escreve o quê

A lista de convidados é escrita pelo morador, na reserva dele, e apenas lida pela portaria. Não existe rota que deixe o balcão acrescentar um nome. Uma portaria que pudesse acrescentar poderia liberar quem o morador não liberou, e a lista deixaria de provar qualquer coisa.

A mesma regra vale para o perfil do morador: dependentes, veículos e pets. Só o dono edita, e nem o administrador escreve no dado de outro. A consequência é assumida: dado errado, só o dono corrige, e a administração pede a correção. A tela de consulta explica isso, senão seria lida como tela inacabada.

A única exceção é a unidade do apartamento, que é da administração: unidade autodeclarada é o caminho mais curto para receber a encomenda do vizinho. O telefone é o inverso, dado do próprio usuário, e não do papel que ele ocupa.

Vem da descoberta 04

Agenda mensal dos espaços do condomínio, com bolinhas de situação em cada dia e uma legenda de livre, parcialmente ocupado, sem horário livre, em manutenção e sua reserva. — A frase embaixo da legenda é a regra escrita na tela: **a agenda mostra apenas se o espaço está livre ou ocupado, nunca de quem é a reserva**. O vizinho precisa saber se o sábado está livre, não quem reservou.

5.3

Código de retirada dimensionado para a voz

O código tem seis caracteres e nenhum I, L, O ou U, que são as letras confundidas quando alguém lê a tela em voz alta. Ele aparece inteiro, sem hífen: agrupar ajuda quem lê e atrapalha quem dita. A entrada tolera hífen e espaço, a saída não produz nenhum dos dois.

O código não aparece em nenhuma tela da portaria, nem na lista, nem no detalhe, nem na auditoria. Se aparecesse, bastaria dizer “sou do 1204” para levar o pacote do vizinho.

Vem da descoberta 02

Telas A mesma encomenda, vista pelos dois lados

Tela de celular do morador, com o código de retirada em letras grandes e um QR code abaixo. — **O morador** vê o código e o QR, com a frase que avisa que outra pessoa pode retirar por ele. A portaria registra quem levou.

Tela da portaria com a fila de encomendas: apartamento, tipo, chegada e situação. Nenhuma coluna mostra o código de retirada. — **O balcão** vê a fila e um campo para digitar o que o morador apresentar. O código não está em lugar nenhum desta tela.

5.4

Alvo de toque na linha inteira, não no controle

No checklist da equipe o rótulo inteiro é área de toque, com folga para passar de 44 pixels mesmo com uma linha de texto. Nenhuma tabela em tela estreita: cinco colunas em 375 pixels viram rolagem horizontal, e é rolando na horizontal com uma mão só que se perde o lugar na lista.

A validação que o servidor faria vira interação antes da requisição: o item que exige observação abre o campo em vez de mandar e receber recusa. O servidor continua recusando, mas a recusa deixa de ser a primeira notícia.

Vem da descoberta 02

Tela de celular com quatro cartões de ambiente (Torre A, Torre B, área de lazer), cada um com um botão grande de abrir checklist. — Um cartão por ambiente, o botão ocupando meia largura da tela e o dia resumido numa pílula. A rotina pertence ao **posto**, não à pessoa: a limpeza do hall não deixa de existir porque quem a faz tirou férias.

5.5

Leitura das normas fora da matriz de permissões

É a inversão deliberada do resto do sistema. O módulo de normas concede escrever, e ler o que está publicado exige apenas estar logado. Permissão de leitura obrigaria uma linha na matriz para cada morador, e um síndico que precisasse liberar o regimento pessoa por pessoa não liberaria. A regra da piscina não é sigilo.

A regra aprovada em assembleia virou documento próprio, com data própria, em vez de ser emendada no regimento antigo. Fundir os dois apagaria a data em que a regra passou a valer, que é o que se pergunta quando uma multa é contestada.

Vem da descoberta 01

06 Como saiu do papel

React e Fastify, com contrato compartilhado.

React com Vite e TypeScript no navegador, com CSS próprio e nenhum framework de componente. Fastify e Postgres do outro lado, com Drizzle, sessão e bloqueio de tentativa no Redis, senha em argon2id. Os contratos de dados são schemas em Zod compartilhados entre as duas pontas, então tela e API não divergem em silêncio.

A rota valida e autoriza, o serviço tem a regra, o repositório é o único que toca o banco. Rota sem verificação de autenticação quebra o build: um teste varre a árvore de rotas e falha se achar uma desprotegida.

07 Qualidade e escala

Quatro mecanismos de autorização, nenhum por cargo.

Autorização por cargo é o que produz o zelador com a senha do síndico. São quatro mecanismos, e cada um cobre um caso que os outros três não cobrem:

Mecanismo	Onde ele é o certo
Matriz por módulo	o caso comum: moradores, encomendas, financeiro. Liberado usuário a usuário.
Só a sessão	ler as normas publicadas. Exigir permissão aqui seria uma linha por morador.
Papel declarado	atas e prestação de contas, onde a lista de quem alcança é curta e estável.
Vínculo com um cadastro	o checklist da equipe. Vale para quem está ligado a uma pessoa ativa, então desligar o cadastro já revoga o acesso.

Tela de usuários com contadores de pessoas na equipe, próprios, terceirizados e com conta no sistema, e a tabela de pessoas com função, vínculo e conta. — Dez pessoas na equipe e **três com conta no sistema**. As outras sete aparecem com *“sem conta, não marca a própria rotina”* escrito na linha. Estar cadastrado como pessoa e ter acesso são coisas separadas, e desligar o cadastro revoga o acesso sem passar por permissão nenhuma.

O registro de ponto é append-only no banco. Uma trava recusa UPDATE e DELETE, o número sequencial não tem lacuna e cada marcação carrega o hash da anterior. A legislação de ponto descreve o que o registro precisa ser, e isso é requisito de software.

A trilha de auditoria guarda o antes e o depois de cada mudança de permissão. Só o depois responde o que passou a valer, e em qualquer incidente a outra metade da pergunta é quem tirou o acesso de alguém.

Trilha de auditoria com quando, ação, status, autor, alvo e origem de cada evento, incluindo logins e o registro de uma encomenda. — **Autor** e **alvo** ficam em colunas separadas porque são pessoas diferentes na maioria das linhas, e é aí que a trilha responde alguma coisa. O nome técnico do evento aparece junto do rótulo em português: quem confere um incidente precisa do identificador, não da tradução.

A tela declara o que não sabe. O espelho de ponto é gerencial, não folha: não calcula adicional noturno em dinheiro, e a hora noturna sai como insumo, em coluna própria, com o aviso escrito. Mesma postura do custo por apartamento, declarado como média.

O que vem a seguir no produto

O módulo de unidades é o próximo, e é ele que troca a média pelo rateio exato: a fração ideal de cada apartamento está nos quadros da convenção, esperando virar cadastro. Depois dele, a chamada de capital deixa de ser aproximação.

Quer ver o sistema rodando

As telas desta página são do sistema, e o resto dele também roda. Demonstração ao vivo, módulo por módulo, é conversa de trinta minutos.

Falar comigo Voltar ao início