Entrega - Unidade 2¶

Esta seção reúne os artefatos, apresentações e registros de validação referentes à segunda unidade do projeto.

Apresentação da Unidade¶

Vídeo da Apresentação¶

Slides¶

Reuniões e Validações com a Cliente¶

Abaixo estão os registros, players de gravação e atas das reuniões realizadas com a cliente, documentando a evolução desde a concepção do escopo até a priorização final do MVP.

1. Revisão e Validação Inicial do Documento de Visão¶

Objetivo: Validar o problema central, os objetivos e o escopo preliminar do projeto (Iteração 1).

Resumo da Reunião: Nesta primeira validação, a equipe apresentou à cliente o mapeamento inicial do escopo do projeto. A discussão foi centrada no alinhamento das expectativas quanto às necessidades da comunidade Munduruku, validando a premissa de que a aplicação precisa de mecanismos sociais e interativos para reter usuários. Os primeiros tópicos do Documento de Visão foram consolidados.

2. Alinhamento sobre Capacidade Técnica e Tecnologias¶

Objetivo: Mapear gargalos técnicos da arquitetura legada (Flask) e validar a capacidade da equipe de propor melhorias estruturais.

Resumo da Reunião: Sessão dedicada ao alinhamento técnico do projeto. A equipe debateu com a cliente o estado atual da base de código, as integrações e as tecnologias empregadas no desenvolvimento original. O objetivo foi assegurar que as novas funcionalidades propostas fossem técnica e arquiteturalmente viáveis antes de avançar para a fase de elaboração dos requisitos detalhados.

3. Análise e Validação das User Stories (MoSCoW)¶

Objetivo: Apresentar as Histórias de Usuário derivadas da visão inicial e iniciar a classificação de valor.

Resumo da Reunião: Avançando para a Fase de Elaboração (Iteração 2 e 3), a equipe traduziu as Características do Produto (CPs) em Histórias de Usuário. Durante a sessão, as "User Stories" foram avaliadas pela cliente utilizando a técnica MoSCoW, separando o que é essencial para o sucesso do projeto daquilo que pode ser tratado como diferencial (desejável) em entregas futuras.

Priorização MoSCoW¶

4. Validação de Funcionalidades¶

Objetivo: Demonstrar o fluxo de usabilidade das novas mecânicas de interação (Feed Social e Gamificação) para captura de feedback (Iteração 3).

Resumo da Reunião: Foco na experiência do usuário e na validação das funcionalidades ligadas ao OE1 (Aumentar engajamento). A equipe discutiu as regras de negócio por trás do Feed Social Comunitário (CP2) e dos Mecanismos Interativos (CP1). Foram debatidas as formas de interação (curtidas, comentários) e a estrutura de criação de eventos para garantir que se adequassem à realidade de uso da aldeia.

5. Validação dos Requisitos Funcionais¶

Objetivo: Revisão da lista final de 49 Requisitos Funcionais, focando em permissões, segurança e multimídia (Iteração 4).

Resumo da Reunião: Passagem formal pela Especificação Suplementar consolidada. A cliente validou processos críticos do OE2 (Segurança) e OE3 (Experiência). Destaques da validação: * Controle de Usuários e Denúncias (CP3 e CP4): Validação dos fluxos de banimento, alteração de cargos e gestão de denúncias para manter um ambiente seguro. * Multimídia (CP5): Definição estrita de que apenas os usuários com perfil de Professor devem ter o poder de associar vídeos e áudios diretamente às traduções no processo educacional.

6. Priorização Final e Definição do MVP¶

Objetivo: Aplicar a Matriz de Quadrantes (Impacto no Negócio vs. Dificuldade Técnica) para estabelecer a Baseline oficial do backlog e definir o escopo do MVP (Iteração 4).

Resumo da Reunião: Nesta sessão de encerramento da Fase de Elaboração, a equipe realizou a priorização estratégica do backlog por meio de uma Matriz de Impacto no Negócio vs. Dificuldade Técnica, estabelecendo o escopo do Minimum Viable Product (MVP). Cada um dos requisitos foi avaliado sob a ótica do valor entregue aos objetivos do projeto (como engajamento, preservação linguística, acessibilidade e segurança) em equilíbrio com a complexidade de engenharia envolvida (dependências do legado em Flask, persistência no Firebase e gerenciamento de mídias).

Os itens foram mapeados em quatro quadrantes orientadores para a tomada de decisão:

Alto Impacto e Baixa Dificuldade Técnica: Considerados de prioridade máxima por entregarem valor imediato com riscos reduzidos.
Alto Impacto e Alta Dificuldade Técnica: Classificados como importantes, demandando planejamento detalhado, validações contínuas e fatiamento em entregas incrementais.
Baixo Impacto e Baixa Dificuldade Técnica: Identificados como requisitos complementares, a serem desenvolvidos segundo a disponibilidade da equipe.
Baixo Impacto e Alta Dificuldade Técnica: Definidos como menor prioridade devido ao alto esforço de engenharia sem retorno proporcional imediato para o produto.

Essa abordagem serviu como uma organização inicial e ponto de partida para debates técnicos amadurecidos. Cruzando os dados da matriz com os alinhamentos de regras de negócio feitos com a cliente e as dependências estruturais do sistema, a equipe obteve uma visão holística que evitou escolhas arbitrárias ou individuais, blindando o planejamento e selecionando os requisitos mais críticos para consolidar a experiência principal do aplicativo de forma estável.

Board do Miro¶

Matriz de valo e impacto