Candidato: Matheus Leite Divino

Data: 26/03/2024
Cargo pretendido: Product Owner
Desafio: Criar uma análise da seguinte situação: Seu cliente precisa de um formulário
para cadastrar participantes do evento, onde o participante possa selecionar o
ingresso e a data que participará. Ao final, o seu cliente precisará saber quantos
clientes se cadastraram, quais ingressos foram comprados e para quais dias.

Como Product Owner da equipe responsável pelo desenvolvimento do produto, eu conduziria

as seguintes ações:

1. Entender os Requisitos do Cliente:

Em primeiro momento teria uma reunião com o cliente para entender completamente os
requisitos e objetivos do formulário de cadastro.

Esclareceria junto stakeholders, quais seriam as informações essenciais para o produto, como o
número total de participantes, tipos de ingressos vendidos e datas selecionadas, definindo
assim as funcionalidades necessárias para criar o Product Backlog.

Exemplos de Funcionalidades que poderiam ser definidas:

• Formulário de Cadastro com campos para nome, e-mail, telefone (opcional), seleção
de ingresso e data do evento.

• Validação de dados para garantir que informações obrigatórias sejam fornecidas

corretamente.

• Contagem automática de participantes cadastrados.

• Relatórios detalhados sobre o número de participantes, tipos de ingressos e datas

selecionadas

2. Priorizar Funcionalidades:
Priorizaria as funcionalidades que foram identificadas e incluídas no Product Backlog, com base
nos requisitos do cliente e nas necessidades dos usuários.

Elaboraria user stories e priorizaria o product backlog para organizar as funcionalidades por
ordem de importância (eu particularmente utilizo a técnica MoSCoW para priorização do
product backlog).

Exemplo de Product Backlog Priorizado, utilizando a técnica MoSCoW:

1. Desenvolvimento do formulário básico de cadastro.

2. Implementação da validação de dados e contagem automática de participantes.
3. Criação de relatórios básicos sobre os participantes cadastrados.
4. Refinamento da interface do usuário para melhor usabilidade.
5. Integração de medidas de segurança e conformidade.
3. Definição de Critérios de Aceite:
Definiria critérios de aceitação para garantir que todas as funcionalidades e requisitos
esperados pelo cliente sejam adequadamente atendidos na entrega do produto final.

Exemplo de critérios de aceite que eu adotaria:

Cadastro de Participantes:
Critério de aceite: O formulário permite que os participantes preencham todos os
campos obrigatórios e os dados são corretamente armazenados no sistema.
Validação de Dados:
Critério de aceite: Todos os campos obrigatórios são devidamente validados,
garantindo a integridade dos dados fornecidos pelos participantes.
Contagem Automática de Participantes:
Critério de aceite: O sistema mantém uma contagem precisa do número total de
participantes cadastrados, atualizando automaticamente conforme novos cadastros
são feitos.
Relatórios Detalhados:
Critério de aceite: Os relatórios gerados apresentam informações claras e precisas
sobre o número de participantes por tipo de ingresso e por data do evento.
Usabilidade:
Critério de aceite: Os participantes conseguem preencher o formulário de maneira
intuitiva, sem encontrar dificuldades na navegação ou no preenchimento dos campos.
Segurança e Conformidade:
Critério de aceite: O sistema garante a segurança dos dados dos participantes e está
em conformidade com as regulamentações de privacidade, como LGPD.

4. Transparência e Comunicação com a equipe

Trabalharia em estreita colaboração com a equipe de desenvolvimento para garantir que haja
um entendimento claro dos requisitos e prioridades do projeto.

Realizaria reuniões regulares de planejamento e revisão para alinhar as expectativas e garantir

o progresso do desenvolvimento.

5. Iterações Incrementais:
Adotaria uma abordagem iterativa, lançando versões incrementais do formulário para feedback
contínuo do cliente e dos usuários.

Priorizaria a entrega de funcionalidades de alto valor primeiro e iteraria com base no feedback
dos usuários e do cliente.

6. Validação do Produto:
Testaria continuamente o produto em desenvolvimento para garantir que atenda aos requisitos
do cliente e às expectativas dos usuários.

Realizaria testes de usabilidade e coletaria feedback dos usuários para identificar áreas de
melhoria.
7. Gerenciamento de Mudanças:
Estaria preparado para lidar com mudanças nos requisitos do cliente à medida que o projeto
avançasse.

Avaliaria o impacto das mudanças propostas e colaboraria com a equipe para ajustar o plano
do produto conforme necessário.

8. Métricas e melhoria contínua:

Definiria métricas de sucesso para avaliar o desempenho do formulário de cadastro, como o
número de inscrições concluídas e a satisfação do usuário.

Monitoraria regularmente essas métricas e ajustar o produto com base nos resultados para
garantir um processo de melhoria contínua.

9. Conclusão
Seguindo essa análise, seria possível criar um produto que atende às necessidades do cliente
de forma eficaz e eficiente. Ao entender completamente os requisitos do cliente, priorizar as
funcionalidades de acordo com o valor para o negócio e definir critérios de aceitação claros,
acredito que, eu como Product Owner conseguiria guiar a equipe de desenvolvimento na
criação de um formulário de cadastro para eventos que seja intuitivo, funcional e capaz de
fornecer informações valiosas ao cliente.

Ao adotar uma abordagem iterativa e colaborativa, com feedback contínuo do cliente e dos
usuários, o produto poderia ser ajustado e melhorado ao longo do tempo para atender às
necessidades que fosse surgindo. Isso garante que o produto final seja bem-sucedido e
entregue valor tangível ao cliente.
Técnica MoSCoW
A técnica MoSCoW é uma abordagem de priorização usada para determinar a importância
relativa de requisitos ou funcionalidades em um projeto. O termo "MoSCoW" é um acrônimo
que representa as quatro categorias de priorização: Must have, Should have, Could have e
Won't have

Aqui está uma explicação detalhada de cada uma dessas categorias:

1. Must have (Deve ter): São os requisitos essenciais para o sucesso do projeto. Se esses
requisitos não forem atendidos, o produto não será funcional ou não atenderá às
necessidades do cliente.

2. Should have (Deveria ter): São os requisitos importantes, mas não essenciais para o
lançamento inicial do produto. Eles agregam valor significativo ao produto, mas sua
ausência não impedirá a entrega.

3. Could have (Poderia ter): São os requisitos desejáveis, mas não críticos para o sucesso
do projeto. Eles podem ser incluídos no produto se o tempo e os recursos permitirem,
mas não são considerados prioritários para a primeira versão.

4. Won't have (Não terá): São os requisitos que não serão incluídos no escopo do projeto
atual. Eles podem ser considerados para futuras iterações ou versões do produto, mas
não são uma prioridade imediata.

Eu utilizo a técnica MoSCoW para priorização a cerca de 1 ano, e sempre funcionou muito bem
para mim.