LEITURA DE CENÁRIOS A HIPÓTESES – 10 minutos

O CENÁRIO
Uma empresa especializada em tecnologia e inovação deseja desenvolver um
aplicativo para facilitar a organização de eventos. O aplicativo deve oferecer
uma plataforma para que os usuários possam organizar todos os aspectos de
um evento em um só lugar, incluindo lista de convidados, lista de fornecedores,
confirmação de presença dos convidados, controles orçamentários,
programação, tarefas e informações importantes sobre o evento, divulgação
nas redes sociais, dentre outras.
.

O CONTEXTO DO PROBLEMA
Organizar um evento pode ser uma tarefa complexa e trabalhosa, com diversas
etapas e informações a serem gerenciadas. Muitas vezes, os organizadores
enfrentam dificuldades em lidar com a quantidade de informações e tarefas
envolvidas, encontrar os fornecedores certos e os melhores orçamentos, além
de enfrentar problemas com erros e esquecimentos de tarefas importantes para
assegurar o sucesso do evento. A empresa acredita que uma plataforma que
reúna todas as informações e tarefas em um só lugar pode facilitar muito a
organização de eventos, melhorar a eficiência dos organizadores e o contribuir
significativamente para o sucesso do evento..
OBJETIVO DO PROJETO:
O objetivo do projeto é criar um aplicativo inovador e eficiente que facilite a
organização de eventos, eliminando a necessidade de gerenciar uma grande
quantidade de informações em diferentes plataformas.

CAUSAS DO PROBLEMA:
 Dificuldade em manter informações organizadas em diferentes
fontes.
 Falta de comunicação efetiva entre organizadores e convidados.
 Dificuldade em lidar com imprevistos e mudanças de última hora.

CONSEQUÊNCIAS DO PROBLEMA:
 Atrasos e problemas na organização do evento.
 Estresse e sobrecarga para os organizadores.
 Prejuízos financeiros devido a erros e imprevistos.
 Experiência ruim e frustração dos organizadores e convidados.

PESSOAS IMPACTADAS PELAS CONSEQUÊNCIAS:

 Organizadores de eventos.
 Convidados e participantes dos eventos.
 Fornecedores e prestadores de serviços envolvidos nos eventos.

PESSOAS ENVOLVIDAS NAS CAUSAS:

 Desenvolvedores de aplicativos.
 Empresas de organização de eventos.
 Pessoas envolvidas na produção e execução de eventos, como
fornecedores, cerimoniais, prestadores de serviços e equipes de
apoio.

POR QUE ESSE PROBLEMA É IMPORTANTE PARA O GRUPO DE

EMPRESÁRIOS DESCRITO NO CONTEXTO:
 O desenvolvimento de um aplicativo que facilite a organização de
eventos pode ser uma oportunidade de negócio lucrativa.
 Um aplicativo que ofereça uma solução eficiente e intuitiva pode
se destacar em um mercado competitivo.
 Uma solução de organização de eventos mais eficiente pode ser
atraente para os organizadores de eventos e seus clientes.

MÉTRICAS E INDICADORES DE QUE O PROBLEMA FOI RESOLVIDO DE

FORMA EFICAZ:
 O número de usuários do aplicativo.
 O nível de satisfação dos usuários do aplicativo.
  A taxa de sucesso na organização de eventos.
 O retorno sobre o investimento dos empreendedores.

VISÃO DO PRODUTO
"Nós estamos desenvolvendo um aplicativo para facilitar a organização de
eventos, permitindo aos usuários gerenciar a lista de convidados, atividades,
tarefas e informações em um só lugar. Nosso objetivo é oferecer uma solução
mais eficiente e intuitiva para os organizadores de eventos, permitindo-lhes
economizar tempo e esforço na organização de seus eventos. Com nossa
abordagem ágil e centrada no usuário, estamos comprometidos em oferecer
um aplicativo de alta qualidade e que atenda às necessidades dos nossos
usuários."

HIPÓTESES
Aqui estão algumas possíveis hipóteses de negócio que poderiam ser
validadas para o cenário do desenvolvimento de um aplicativo para
organização de eventos:

1. Hipótese de demanda: há demanda suficiente no mercado para um

aplicativo de organização de eventos, e os potenciais usuários estão
dispostos a pagar pelo acesso aos recursos e serviços oferecidos.
2. Hipótese de recursos: os recursos disponíveis, incluindo o orçamento
para o desenvolvimento, a equipe de desenvolvimento, os prestadores
de serviços e as ferramentas de desenvolvimento, são suficientes para
criar um aplicativo de alta qualidade.
3. Hipótese de concorrência: a concorrência no mercado de aplicativos
de organização de eventos é suficientemente baixa para permitir que
nosso aplicativo se destaque.
4. Hipótese de usabilidade: o aplicativo é fácil de usar e atende às
necessidades dos usuários, incluindo a capacidade de gerenciar a lista
de convidados, atividades, tarefas e informações do evento.
5. Hipótese de segurança: o aplicativo é seguro e confiável, protegendo
as informações pessoais dos usuários e evitando a perda de dados.
6. Hipótese de escalabilidade: o aplicativo é escalável e pode lidar com
um grande número de usuários e eventos ao mesmo tempo.
7. Hipótese de integração: o aplicativo pode ser integrado com outras
ferramentas e serviços de organização de eventos, como ferramentas de
gerenciamento de projetos e plataformas de venda de ingressos.
8. Hipótese de valor: o aplicativo oferece valor suficiente aos usuários
para justificar o preço e a assinatura, se houver.
BACKLOG (ALTO NÍVEL)
1. Realizar uma pesquisa de mercado para identificar as tendências e
necessidades dos usuários do mercado de organização de eventos.
2. Implementar as funcionalidades e recursos do aplicativo principais, como
a capacidade de gerenciar a lista de convidados, atividades, tarefas e
informações do evento e lançar no mercado.
3. Criar um protótipo do aplicativo e realizar testes de usabilidade para
validar sua usabilidade e capacidade de atender às necessidades dos
usuários.
4. Definir o design e a interface do usuário do aplicativo.
5. Desenvolver o aplicativo e integrá-lo com outras ferramentas e serviços
de organização de eventos, se necessário.
6. Testar e depurar o aplicativo para garantir que ele seja seguro e
confiável.
7. Criar um sistema de suporte e atendimento ao usuário para ajudar a
resolver problemas e responder a perguntas dos usuários.
8. Realizar testes de desempenho e escalabilidade para garantir que o
aplicativo possa lidar com muitos usuários e eventos ao mesmo tempo.
9. Definir um modelo de monetização para o aplicativo, como um preço de
compra único ou uma assinatura.
10. Criar uma campanha de marketing para promover o aplicativo para os
usuários e maximizar a adoção do mercado.
11. Implementar um sistema de feedback dos usuários para permitir que os
usuários forneçam feedback sobre a usabilidade do aplicativo e quais
recursos eles gostariam de ver adicionados no futuro.
12. Realizar testes de usabilidade do aplicativo com usuários para identificar
possíveis problemas ou melhorias.
13. Desenvolver uma estratégia de monetização do aplicativo para gerar
receita, como opções de compra dentro do aplicativo ou parcerias com
patrocinadores de eventos.
14. Integrar o aplicativo com outras plataformas de mídia social e serviços
de e-mail para facilitar a comunicação com os convidados e promover o
evento.
15. Desenvolver um sistema de notificação para alertar os usuários sobre as
próximas tarefas e eventos importantes.
16. Criar uma opção de calendário para sincronizar as datas dos eventos
com o calendário pessoal dos usuários.
17. Oferecer suporte técnico e atendimento ao cliente para resolver
problemas e fornecer orientação aos usuários.
18. Implementar um sistema de segurança para garantir a proteção dos
dados dos usuários e a privacidade das informações do evento.
19. Desenvolver uma campanha de marketing para promover o aplicativo e
aumentar o número de downloads.
20. Entrar em contato com os fornecedores buscando parcerias para iniciar
a integração da plataforma.
ATIVIDADE 1: TIME SCRUM (10 minutos)
Decidam quem será o Product Owner do grupo.
O Product Owner é um dos três papéis do Scrum e sua principal
responsabilidade é maximizar o valor do produto. Durante a Sprint Planning, a
responsabilidade do Product Owner é definir os itens do backlog que serão
trabalhados durante a Sprint e priorizá-los com base no valor que cada item
traz para o produto.
Mais especificamente, durante a Sprint Planning, o Product Owner deve
trabalhar em conjunto com os Desenvolvedores para:
 Definir o objetivo da Sprint: o Product Owner deve definir o objetivo da
Sprint, que deve ser alcançável e alinhado com os objetivos de longo
prazo do produto. No caso de nosso exemplo, o Objetivo será validar a
hipótese priorizada pelo time.
 Selecionar os itens do backlog: o Product Owner deve facilitar a
discussão com o restante do time para definir os itens do backlog que
serão trabalhados durante a Sprint com base no valor que cada item traz
para o produto e nas necessidades do cliente, tendo como referência
sempre o Objetivo a ser validado.
 Priorizar os itens do backlog: o Product Owner, a partir dos
aprendizados obtidos e juntamente com a visão do restante do time,
deve priorizar os itens do backlog com base no valor que cada item traz
para o produto e nas necessidades do cliente. É importante lembrar que
os itens do backlog devem ser trabalhados na ordem de prioridade.
 Esclarecer as dúvidas dos Desenvolvedores: o Product Owner deve
estar disponível para esclarecer quaisquer dúvidas que os
Desenvolvedores tenham em relação aos itens do backlog selecionados
e às prioridades definidas.
 Definir os critérios de aceitação: o Product Owner deve definir os
critérios de aceitação para cada item do backlog, para que todos saibam
quando um item é considerado concluído.
 Garantir que os itens selecionados são factíveis: o Product Owner deve
garantir que os itens selecionados são factíveis e que os
Desenvolvedores tem a capacidade necessária para trabalhá-los
durante a Sprint.
Em resumo, o Product Owner é responsável por garantir que o time Scrum
esteja trabalhando nos itens de maior valor para o produto e para os
stakeholders, assegurando que o trabalho dos Desenvolvedores está alinhado
com as expectativas do cliente e objetivos do negócio.
ATIVIDADE 2: PRIORIZAÇÃO DE HIPÓTESES (60 minutos)
O objetivo desta atividade é avaliar as hipóteses de negócio levantadas e
priorizá-las com base na sua importância e viabilidade. A priorização das
hipóteses é fundamental para garantir que o time esteja focado em validar as
hipóteses mais críticas e relevantes para o sucesso do produto.

 Passo 1: Revisão das hipóteses (5 minutos)

O Product Owner deve apresentar as hipóteses de negócio levantadas
para o time. É importante que todos tenham uma compreensão clara do
contexto e das hipóteses antes de começar a avaliar e priorizá-las.

 Passo 2: Critérios de priorização (10 minutos)

O time deve definir critérios de priorização para avaliar as hipóteses.
Alguns exemplos de critérios podem ser: impacto no negócio, facilidade
de validação, risco envolvido, entre outros. Os critérios devem ser
definidos em conjunto pelo time e devem refletir os objetivos do produto
e as necessidades dos usuários.

 Passo 3: Avaliação e priorização (15 minutos)

O time deve avaliar cada hipótese com base nos critérios definidos e
atribuir uma pontuação para cada uma delas. A pontuação pode ser um
número de 1 a 10 ou uma escala qualitativa (alta, média, baixa, por
exemplo). Depois de avaliar todas as hipóteses, o time deve priorizá-las
com base na pontuação atribuída.

 Passo 4: Discussão e definição (15 minutos)

Após a priorização, o time deve discutir as hipóteses mais importantes e
definir quais serão as hipóteses validadas na próxima sprint. O objetivo é
selecionar as hipóteses mais importantes e viáveis, levando em
consideração o tempo disponível e a capacidade do time.

 Passo 5: Atualização do Backlog (10 minutos)

O Product Owner deve atualizar o backlog do produto com as hipóteses
validadas para a próxima sprint. As hipóteses não selecionadas devem

ser mantidas no backlog para avaliação futura.

A atividade de priorização das hipóteses é uma etapa importante para garantir
que o time esteja focado nas hipóteses mais críticas e relevantes para o
sucesso do produto. A avaliação e priorização devem ser feitas de forma
colaborativa pelo time, garantindo que todos tenham uma compreensão clara
das hipóteses e dos critérios de priorização.

ATIVIDADE 3: PRIORIZAÇÃO DO BACKLOG (20 minutos)

1. Reúna o time e apresente a hipótese que foi selecionada para validação.
2. Juntos, priorizem os itens de backlog com base na sua importância e
valor para o projeto, considerando a hipótese escolhida.
3. A partir da priorização, selecionem os itens que serão trabalhados
durante a Sprint, levando em consideração a visão MoSCoW;
a. Must Have – itens cruciais para validarmos a hipótese.
b. Should Have – itens muito importantes, mas não cruciais, para
validarmos a hipótese.
c. Could Have – itens desejáveis, mas dispensáveis, caso seja
necessário descartar, para validar a hipótese.
d. Won’t Have – itens totalmente dispensáveis para validar a
hipótese
4. Selecione, no máximo 3 Must, 3 Should e 2 Could.

ATIVIDADE 4: APRESENTAÇÃO (30 minutos)

Cada grupo terá de 5 a 10 minutos para apresentar:
 Qual será a estratégia da primeira release e por que priorizamos essa(s)
hipótese(s)
 Como saberemos se a hipótese foi validada (metas e métricas)
 Qual seria a próxima hipótese, caso a primeira seja validada
 Quais itens MoSCoW foram selecionados para validar a primeira
hipótese.
FOLHA DE RESPOSTAS

Participantes do Grupo:

Atividade 1:

Atividade 2:
Atividade 3:
Atividade 4: