02 / Compras · Arquitetura de solução
Quando a decisão deixa de depender da próxima reunião.
Um processo de compras dependia de comitês que se reuniam duas vezes por mês. Ajudei a desenhar um portal no SharePoint para levar esse fluxo ao ambiente já utilizado pela operação.
Como tirar a decisão da agenda de reuniões e preservar suas regras?
01 / O ponto de partida
Antes de desenhar a tela, entender a decisão.
O diagnóstico reuniu documentação, registros do processo, conversas com a operação e a participação de um especialista em procurement. As reuniões em datas fixas condicionavam o andamento das solicitações.
Traduzir isso em software exigia entender quem decidia, quais informações eram necessárias e quais regras precisavam ser preservadas.
02 / Minha contribuição
Arquitetura e permissões eram parte do produto.
Minha responsabilidade se concentrou na arquitetura e nos requisitos de segurança: autenticação, permissões e visibilidade dos votos. Essas escolhas definiam o que cada participante poderia fazer e enxergar.
Usamos o SharePoint, que já fazia parte do ambiente do cliente. Uma equipe de duas pessoas construiu a prova de conceito, com colaboração entre negócio e desenvolvimento.
03 / Como construímos
Detalhar o fluxo para tornar a implementação possível.
O desenvolvimento contou com IA no apoio à escrita de requisitos, especificações, documentação e testes. O trabalho de esclarecer regras e validar o comportamento continuou com a equipe.
O caso mostra a ligação entre desenho de processo e arquitetura: a experiência de uso precisava refletir as regras da decisão, inclusive aquilo que não deveria ficar visível a todos.