FastInBox | Planejamento de execucao
Plano de Projeto Tecnico
Versao: 2.0 | Modelo incremental por sprint
Plano de execucao com fases, marcos, riscos e controles de qualidade para conduzir o FastInBox do MVP de banca para base de produto escalavel.
1. Estrategia de entrega
O projeto adota modelo incremental orientado a risco. A cada sprint, o criterio de sucesso inclui funcionalidade demonstravel, estabilidade minima e evidencia documentada de conformidade com os requisitos.
- Entrega curta e verificavel por perfil de usuario.
- Convergencia entre backlog funcional e backlog tecnico.
- Uso de docs como mecanismo de governanca e comunicacao.
2. Macro cronograma
| Fase | Objetivo | Entregavel principal |
|---|---|---|
| Fase 1 | Fundacao de arquitetura e acesso | Base de rotas, perfis e estrutura de dados |
| Fase 2 | Nucleo comercial | Cadastro de paciente e criacao de pedido |
| Fase 3 | Conversao e operacao | Pagamento, fabrica e acompanhamento |
| Fase 4 | Governanca e escala | API consolidada, relatorios e observabilidade |
3. Plano por sprint
Sprint 1 - concluida
- Fluxo E2E demonstravel no front.
- Publicacao da aplicacao com ambiente estavel para demonstracao.
- Hub de documentacao publica no GitHub Pages.
Sprint 2 - planejada
- Migrar persistencia local para camada de API e banco.
- Fortalecer autorizacao e controle de sessao.
- Incluir testes automatizados de regressao.
Sprint 3 - planejada
- Adicionar relatorios operacionais e financeiros.
- Implementar trilha de auditoria persistente.
- Refinar painel da fabrica com SLA por etapa.
4. Controle de risco
| Risco | Probabilidade | Impacto | Resposta |
|---|---|---|---|
| Expansao precoce de escopo | Alta | Alto | Gate de aceite por sprint e backlog priorizado. |
| Regressao de fluxo principal | Media | Alto | Checklist de build e teste manual por jornada. |
| Inconsistencia de dados | Media | Medio | Modelagem de estado e regras de transicao. |
| Dependencia de ambiente | Baixa | Medio | Padrao de deploy publico e docs replicaveis. |
5. Criterios de qualidade por entrega
- Compilacao sem erro do modulo alterado.
- Navegacao valida entre as telas impactadas.
- Sem regressao de status operacional no fluxo principal.
- Documento de apoio atualizado quando houver mudanca estrutural.
- Evidencia de publicacao (commit, push, deploy ou action run).
Nenhuma funcionalidade entra como concluida sem comprovacao simultanea de funcionamento e documentacao minima.
6. Governanca e comunicacao
A comunicacao de projeto utiliza artefatos versionados: README, docs no Pages, registros de sprint e estrutura de issues/tasks. Isso evita perda de contexto e reduz dependencia de comunicacao verbal para transferencia de conhecimento.
As decisoes tecnicas relevantes devem possuir justificativa e impacto esperado registrado no repositorio correspondente.
7. Matriz RACI resumida
| Frente | Responsavel (R) | Aprovador (A) | Consultado (C) | Informado (I) |
|---|---|---|---|---|
| Requisitos e escopo | Produto tecnico | Coordenacao do projeto | Engenharia | Stakeholders da banca |
| Implementacao front | Engenharia front | Lider tecnico | Design e QA | Produto |
| Implementacao back | Engenharia back | Lider tecnico | Produto e QA | Time completo |
| Documentacao tecnica | Engenharia/documentacao | Lider tecnico | Produto | Time completo |
| Publicacao e release | DevOps | Lider tecnico | Engenharia | Stakeholders |
8. Marcos de controle por sprint
- Kickoff com escopo fechado e criterio de pronto declarado.
- Checkpoint intermediario com validacao de risco tecnico.
- Congelamento de escopo para estabilizacao da entrega.
- Review com evidencia funcional, commit e publicacao.
- Retrospectiva com licoes aprendidas e acoes corretivas.
Mudancas fora de escopo apos checkpoint intermediario exigem registro de impacto em prazo, risco e qualidade.
9. Plano de validacao de entrega
| Tipo de validacao | Metodo | Evidencia minima |
|---|---|---|
| Compilacao | Build do modulo alterado | Log de build sem erro |
| Fluxo funcional | Teste manual guiado por jornada | Checklist de passos concluido |
| Publicacao | Deploy em ambiente publico | URL respondendo HTTP 200 |
| Rastreabilidade | Commit semantico e referencia de escopo | Hash e descricao objetiva |
| Documentacao | Atualizacao dos artefatos impactados | Diff no repositorio docs |
10. Controle de escopo e mudanca
| Evento | Regra de decisao | Acao obrigatoria |
|---|---|---|
| Novo requisito durante sprint | Entrar apenas se substituir item equivalente | Registrar impacto em prazo e risco |
| Bloqueio tecnico externo | Aplicar contorno temporario documentado | Atualizar sprint review e 5W2H |
| Falha de build ou regressao critica | Congelar novas features ate estabilizar baseline | Priorizar correcao e evidencias de recuperacao |
| Mudanca estrutural de dominio | Exigir revisao de arquitetura e ERS | Publicar artefatos sincronizados |
11. Dependencias e caminho critico
| Dependencia | Impacto no cronograma | Plano de contorno |
|---|---|---|
| Definicao do gateway de pagamento | Bloqueia integracao financeira real | Manter simulacao controlada ate decisao final |
| Schema relacional definitivo | Afeta API, auditoria e relatorios | Usar contrato de dominio atual como ponte |
| Disponibilidade de ambiente publico | Compromete demonstracao e review | Validar fallback e janela de publicacao |
| Atualizacao documental em paralelo | Sem docs, perde-se rastreabilidade academica | Manter gate de release com checklist documental |
12. Criterios de saida por marco
- Marco de MVP: fluxo E2E demonstravel com login, pedido, pagamento e producao.
- Marco de consolidacao: persistencia server-side e transicoes auditaveis.
- Marco de governanca: relatorios minimos, termos revisados e trilha de incidentes.
- Marco de escala: onboarding replicavel para clinicas parceiras e indicadores comparaveis.