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.
Candidate: Matheus Leite Divino
Date: 03/26/2024
Intended Position: Product Owner
Challenge: Create an analysis of the following situation: Your client needs a form to register
participants for the event, where the participant can select the ticket and the date they will
attend. In the end, your client will need to know how many customers registered, which tickets
were purchased, and for which days.

As Product Owner of the team responsible for developing the product, I would conduct the
following actions:

1. Understanding Customer Requirements:

Initially, I would have a meeting with the client to fully understand the requirements and
objectives of the registration form. Together with stakeholders, I would clarify which
information is essential for the product, such as the total number of participants, types of
tickets sold, and selected dates, thus defining the necessary functionalities to create the
Product Backlog.

Examples of functionalities that could be defined:

• Registration Form with fields for name, email, optional phone number, ticket selection,
and event date.

• Data validation to ensure that mandatory information is provided correctly.

• Automatic counting of registered participants.

• Detailed reports on the number of participants, types of tickets, and selected dates.

2. Prioritizing Functionalities:
I would prioritize the functionalities that have been identified and included in the Product
Backlog, based on customer requirements and user needs. I would develop user stories and
prioritize the product backlog to organize functionalities in order of importance (I particularly
use the MoSCoW technique for prioritizing the product backlog).

Example of Prioritized Product Backlog, using the MoSCoW technique:

1. Development of the basic registration form.

2. Implementation of data validation and automatic participant counting.

3. Creation of basic reports on registered participants.

4. Refinement of the user interface for better usability.

5. Integration of security and compliance measures.

3. Definition of Acceptance Criteria:
I would define acceptance criteria to ensure that all functionalities and requirements expected
by the customer are adequately met in the delivery of the final product.

Example of acceptance criteria that I would adopt:

Participant Registration:

Acceptance Criterion: The form allows participants to fill in all mandatory fields, and
the data is correctly stored in the system.

Data Validation:

Acceptance Criterion: All mandatory fields are properly validated, ensuring the
integrity of the data provided by the participants.

Automatic Participant Counting:

Acceptance Criterion: The system maintains an accurate count of the total number of
registered participants, updating automatically as new registrations are made.

Detailed Reports:

Acceptance Criterion: The generated reports present clear and accurate information
about the number of participants per ticket type and per event date.

Usability:

Acceptance Criterion: Participants can fill out the form intuitively, without
encountering difficulties in navigation or field completion.

Security and Compliance:

Acceptance Criterion: The system ensures the security of participant data and complies
with privacy regulations, such as LGPD.

4.Transparency and Communication with the Team:

I would work closely with the development team to ensure a clear understanding of the project
requirements and priorities. I would hold regular planning and review meetings to align
expectations and ensure development progress.

5. Incremental Iterations:
I would adopt an iterative approach, releasing incremental versions of the form for continuous
feedback from customers and users. I would prioritize delivering high-value functionalities first
and iterate based on feedback from users and customers.

6. Product Validation:
I would continuously test the product in development to ensure it meets customer
requirements and user expectations. I would conduct usability tests and collect user feedback
to identify areas for improvement.
7. Change Management:
I would be prepared to deal with changes in customer requirements as the project progresses. I
would assess the impact of proposed changes and collaborate with the team to adjust the
product plan as necessary.

8. Metrics and Continuous Improvement:

I would define success metrics to evaluate the performance of the registration form, such as
the number of completed registrations and user satisfaction. I would regularly monitor these
metrics and adjust the product based on results to ensure a process of continuous
improvement.

9. Conclusion:
Following this analysis, it would be possible to create a product that effectively meets the
customer's needs. By fully understanding customer requirements, prioritizing functionalities
based on business value, and defining clear acceptance criteria, I believe that as a Product
Owner, I would be able to guide the development team in creating a registration form for
events that is intuitive, functional, and capable of providing valuable information to the
customer. By adopting an iterative and collaborative approach, with continuous feedback from
customers and users, the product could be adjusted and improved over time to meet emerging
needs. This ensures that the final product is successful and delivers tangible value to the
customer.
MoSCoW Technique
The MoSCoW technique is a prioritization approach used to determine the relative importance
of requirements or functionalities in a project. The term "MoSCoW" is an acronym representing
the four prioritization categories: Must have, Should have, Could have, and Won't have. Here's
a detailed explanation of each of these categories:

1. Must have: These are the requirements essential for the success of the project. If these
requirements are not met, the product will not be functional or will not meet the
needs of the customer.

2. Should have: These are important requirements, but not essential for the initial
release of the product. They add significant value to the product, but their absence will
not prevent delivery.

3. Could have: These are desirable requirements, but not critical to the success of the
project. They can be included in the product if time and resources allow, but they are
not considered priorities for the first version.

4. Won't have: These are the requirements that will not be included in the scope of the
current project. They may be considered for future iterations or versions of the
product, but they are not an immediate priority.

I have been using the MoSCoW technique for prioritization for about a year, and it has always
worked very well for me.