13. Lições Aprendidas

Unidade 1

Na Unidade 1, a equipe aprendeu a importância de escolher um processo de desenvolvimento de forma consciente. Inicialmente, havia a tendência de adotar o Scrum apenas por familiaridade, mas o estudo de alternativas como RAD e OpenUP mostrou que o processo precisava se adequar à realidade do projeto e ao contato disponível com a cliente.

Também tivemos dificuldade em compreender o problema central do Nativo. No começo, a equipe pensava muito em telas e funcionalidades, como gamificação e feed social, sem entender completamente o objetivo por trás delas. Com debates internos e reuniões de alinhamento, ficou claro que o foco principal era aumentar a retenção e o uso contínuo da língua Munduruku, o que ajudou a estruturar melhor os Objetivos Específicos e o Documento de Visão.

Unidade 2

Na Unidade 2, a equipe amadureceu o processo de elicitação, análise e consenso dos requisitos. O principal desafio foi sair da visão limitada do sistema legado, focado apenas na tradução textual, e identificar funcionalidades mais alinhadas à retenção e ao engajamento dos usuários.

Também aprendemos a importância de controlar o escopo. Como surgiram muitas ideias, como feed social e gamificação, foi necessário filtrar os requisitos com base em valor de negócio e complexidade técnica, utilizando a Matriz de Quadrantes.

Por fim, a equipe percebeu que backlog e rastreabilidade precisam estar alinhados desde o início. Relacionar requisitos, características do produto e objetivos específicos ajudou a visualizar melhor o que seria priorizado e construído.

Unidade 3

A inspeção do projeto da outra equipe, somada aos feedbacks sobre nosso documento de Verificação e Validação (V&V), mostrou a necessidade de refinar os artefatos do projeto. A equipe fez uma revisão nos requisitos, além de reorganizar as funções ligadas a cada nível de acesso.

Também ficou evidente a importância de manter rastreabilidade e evidências contínuas para sustentar decisões e validações. Por fim, a equipe reforçou que o uso de ferramentas de Inteligência Artificial deve atuar apenas como apoio, exigindo revisão crítica e participação autoral na produção documental.

Unidade 4

Na Unidade 4, a equipe percebeu a importância de manter a documentação alinhada ao produto realmente implementado. A revisão final dos Casos de Uso, requisitos, regras de negócio, rastreabilidade e evidências mostrou que decisões tomadas durante o desenvolvimento precisam ser registradas e conectadas às funcionalidades correspondentes.

Também aprendemos que evidências como reuniões, validações com a cliente, prints, vídeos, PRs, DoR e DoD devem ser organizadas ao longo das iterações, evitando retrabalho no fechamento da entrega. Como esta foi a primeira vez da equipe documentando um projeto com esse nível de detalhe, ficamos admirados com o quanto as transcrições das reuniões ajudaram a recuperar decisões, lembrar justificativas e evitar que os mesmos pontos fossem discutidos repetidamente.

Outro aprendizado veio da própria experiência da equipe. Muitos integrantes trabalham e a maioria também participa de empresas juniores, o que nos fez perceber como problemas de elicitação de requisitos são comuns em diferentes ambientes. Quando necessidades, decisões e mudanças não são bem registradas, o desenvolvimento fica mais difícil, decisões precisam ser retomadas e o projeto perde fluidez.

Por fim, entendemos que a documentação final, deve ser um registro fiel do produto entregue, das mudanças realizadas e das validações feitas com a cliente.