Lições Aprendidas¶

Unidade 1¶

Nesta unidade, a maior dificuldade residiu na transição da visão teórica para a prática operacional da ONG. Abaixo, detalhamos as reflexões críticas sobre o processo.

Dificuldade na Elicitação com Stakeholders Reais¶

Desafio: Inicialmente, a equipe focou em descrever o fluxo da ONG de forma genérica. Porém, durante a construção do Rich Picture, percebeu-se que não havia entendimento suficiente sobre como o moderador Carlos Vaz lidava com a “promessa” versus a “entrega real” das doações.
Como foi superada: Foi realizada uma entrevista complementar focada especificamente no gargalo causado pelo uso do WhatsApp. A equipe aprendeu que ferramentas visuais como o Rich Picture não servem apenas como ilustração, mas também como instrumento de diagnóstico para identificar falhas no entendimento do problema.

Conflito de Metodologia (RAD vs. Disciplina Acadêmica)¶

Desafio: No início do projeto, o grupo tentou seguir o processo RAD priorizando apenas a velocidade de desenvolvimento, o que resultou em requisitos superficiais.
Erro identificado: A fase de planejamento de requisitos foi subestimada, pois a equipe acreditava que poderia avançar diretamente para o design e prototipação. Isso impactou negativamente a definição do MVP, já que as Histórias de Usuário estavam mal estruturadas.
Aprendizado: A equipe concluiu que teria sido mais eficiente aplicar técnicas como User Story Mapping logo na primeira semana, organizando melhor o backlog antes da discussão tecnológica.

O Desafio da Sustentabilidade (Custo Zero)¶

Desafio: Um dos aprendizados mais relevantes foi perceber o impacto do requisito não funcional de “Custo Zero” sobre as decisões arquiteturais do sistema.
Dificuldade encontrada: Algumas ferramentas inicialmente consideradas pela equipe possuíam custos incompatíveis com a realidade da ONG.
Como foi superada: A equipe priorizou tecnologias com planos gratuitos confiáveis, como MongoDB e Node.js. Essa decisão exigiu adaptações no design técnico para reduzir o consumo de requisições ao banco de dados, demonstrando que a limitação financeira é um requisito tão importante quanto as funcionalidades do sistema.

Análise Crítica da Comunicação com o Cliente¶

Desafio: Durante as reuniões com o stakeholder Carlos Vaz, o uso excessivo de termos técnicos acabou gerando desengajamento e dificuldades na validação das funcionalidades.
Como foi superada: A equipe passou a utilizar uma linguagem mais próxima do contexto da ONG e do negócio. Termos técnicos foram substituídos por expressões mais intuitivas, como “Vitrine de Necessidades” em vez de “Frontend de Visualização de Objetos”, facilitando a comunicação e a validação das propostas apresentadas.

Histórico de versão¶

Versão	Data	Descrição	Autor(es)	Revisor(es)
1.0	12/04/2026	Criação da página	Guilherme	Gustavo