Processo de Desenvolvimento de Sistemas – USECASE
1. Objetivo
Estabelecer o fluxo padrão para abertura, planejamento, desenvolvimento, acompanhamento e entrega de projetos de software da USECASE, garantindo alinhamento com o cliente, previsibilidade de prazo e custo, qualidade técnica e rastreabilidade das horas e tarefas executadas.
2. Escopo
Aplica-se a todos os projetos de desenvolvimento de sistemas, módulos, aplicativos, integrações ou melhorias estruturadas realizados pela USECASE.
3. Definições
RT – Requisito Técnico / Funcional: Documento inicial contendo a necessidade do cliente.
Protótipo de Baixa Fidelidade: Representação inicial do sistema em Excel ou similar, com descrição de telas, processos e fluxos.
Protótipo de Alta Fidelidade: Desenho navegável em Figma e/ou Protopie, representando o sistema em sua forma final.
Iniciativa: Macrodemanda cadastrada no Sistema de Apontamento de Horas, contendo orçamento, prazo e descrição do projeto.
Cards Secundários (Planner): Microtarefas vinculadas à iniciativa, utilizadas para microgerenciamento da execução.
Sprint: Ciclo de desenvolvimento (1 a 2 semanas) contendo o conjunto de cards priorizados.
4. Responsabilidades
UX / Produto
Receber RT, conduzir reuniões técnicas, criar protótipos e validar escopo.
Arquiteto / Tech Lead
Definir arquitetura, modelagem de dados e orientar times de backend e frontend.
Desenvolvedores
Executar tarefas atribuídas, registrar horas, participar das dailies e garantir a qualidade do código.
Gerente de Projetos / PO
Organizar Planner, acompanhar execução, gerenciar sprints e comunicação com o cliente.
Cliente
Validar protótipos, aprovar escopo, validar entregas e cumprir prazos de homologação.
5. Procedimento
5.1. Abertura do Projeto
5.1.1. Recebimento do Requisito
Cliente envia a Requisição Técnica (RT) ou documento equivalente.
O PO/UX agenda reunião técnica de entendimento.
5.1.2. Reunião Técnica
Detalhamento da necessidade, fluxos, regras de negócio e escopo preliminar.
Registro de todas as pendências e esclarecimentos.
5.2. Protótipo de Baixa Fidelidade
UX cria o protótipo em Excel (ou ferramenta equivalente), contendo:
Abas do processo
Campos de cadastro
Fluxos
Estruturas de dados
O documento é apresentado ao cliente.
Realiza-se quantas rodadas forem necessárias até que o protótipo esteja 100% aderente ao requisito.
Ao final, ocorre o Gate 1 – Aprovação do Protótipo de Baixa Fidelidade.
5.3. Protótipo de Alta Fidelidade
Com o protótipo de baixa fidelidade aprovado, inicia-se a criação do protótipo de alta fidelidade no Figma.
O protótipo deve conter:
Todas as telas
Navegabilidade
Componentes e padrões de design
Regras de negócio incorporadas
O protótipo é validado com o cliente e servirá como:
Escopo definitivo do projeto
Contraprova para evitar solicitações fora de escopo
O protótipo aprovado gera o Gate 2 – Escopo Fechado.
5.4. Cadastro do Projeto e Estimativa de Horas
O protótipo aprovado é vinculado à nova Iniciativa no Sistema de Apontamento de Horas.
A iniciativa recebe:
Cliente
Projeto
Descrição
Orçamento em horas aprovado comercialmente
Data teórica de início e fim
A equipe técnica avalia o protótipo e realiza o detalhamento das horas, quebrando a iniciativa em macroáreas:
Backend
Frontend
Modelagem de banco
Arquitetura
Integrações
Define-se a duração prevista do projeto (ex.: 90 dias).
5.5. Criação dos Cards Secundários (Planner)
O PO cria a estrutura completa de cards no Planner, representando todas as tarefas de desenvolvimento.
Cada card deve conter:
Nome da tarefa
Descrição detalhada
Responsável
Estimativa de horas
Dependências
Cada card secundário deve mencionar o código da Iniciativa no sistema de apontamento.
5.6. Execução do Desenvolvimento
5.6.1. Daily Meeting
Reunião diária obrigatória com toda a squad.
Duração: 15 min.
Discussão sobre:
O que foi feito
O que será feito
Impedimentos técnicos
5.6.2. Reunião de Sprint
Realizada semanal ou quinzenalmente.
Define quais cards serão executados na Sprint seguinte.
Permite reorganizar prioridades e garantir alinhamento com o cliente.
5.6.3. Apontamento de Horas
Todo desenvolvedor deve lançar horas diárias na Iniciativa correspondente.
O sistema gera:
Total de horas executadas
Comparativo com horas orçadas
Desvio de orçamento
Previsão de término
O gestor monitora riscos de extrapolação de horas ou atraso.
5.7. Reuniões com o Cliente
Reuniões periódicas para apresentação de evolução do desenvolvimento.
Ajustes finos de regras de negócio (desde que dentro do protótipo aprovado).
Discussões de design e componentes quando necessário.
5.8. Entregas Parciais
O sistema pode ser dividido em entregas parciais (Ex.: Entrega 1, 2 e 3).
Após cada entrega:
Cliente recebe versão em ambiente de homologação.
Cliente deve validar em até 30 dias.
5.8.1. Política de Bugs em Entregas
Durante o período de 30 dias:
→ Quaisquer bugs encontrados serão corrigidos sem custo.Após 30 dias sem validação:
→ Correções serão cobradas como horas adicionais.
5.9. Encerramento do Projeto
Todas as entregas devem estar validadas.
É gerado relatório final contendo:
Horas orçadas vs. horas realizadas
Desvios de prazo
Inventário de funcionalidades
A iniciativa é encerrada no sistema.
Caso haja itens pendentes, abre-se nova iniciativa comercial.
6. Indicadores de Performance (KPIs)
Horas orçadas vs. executadas
Aderência ao prazo
% de cards concluídos por sprint
Nº de bugs encontrados pós-entrega
Satisfação do cliente
Eficiência da equipe (horas produtivas x improdutivas)
7. Controles e Sistemas Envolvidos
Sistema de Apontamento de Horas (Iniciativas)
Planner (Microsoft)
Figma Protoy
Ambiente de Deploy / Homologação
Ferramentas de reunião (Teams / Meet)
8. Anexos
ANEXO A – Modelo de Protótipo de Baixa Fidelidade
ANEXO B – Modelo de Card no Planner
ANEXO C – Fluxograma Macro do Processo
ANEXO D – Política de Validação e Correções