07-Projeto de aplicativos moveis

Prévia do material em texto

Projeto de aplicativos moveis
Projetos de aplicativos
 
Aplicativos móveis são softwares como quaisquer outros, entretanto,
executados e, dispositivos móveis (celulares, smartwatches etc.).
Trataremos estes aplicativos como Apps mobile, Apps ou simplesmente
App.
Isso quer dizer que a nível de projeto o App pode ser tratado como
qualquer projeto de Software, com seu(s) processo(s) e sua(s)
metodologia(s) de gestão. Entretanto vamos abordar algumas etapas
importantíssimas de um projeto de App, que devem ser consideradas
dentro de nosso processo. Lembre-se que Apps servem para entregar
valor para quem os utiliza, resolvendo suas metas e necessidades e
gerando recursos financeiros para quem os desenvolve e, eventualmente,
até mesmo para os usuários, mesmo que tratados como meio para isso.
Mas como uma ideia se transforma em um App? Há várias técnicas para
isso e para gerarmos um App que represente nossa ideia, tomando muito
cuidado para que ela não cresça desordenadamente a ponto de perder
sua essência. Ideias podem surgir a partir de qualquer inspiração e em
qualquer momento e torná-las reais, ou seja, tirá-las do papel, sem
dúvidas é o mais difícil, mas tudo dependerá de seu esforço e motivações
envolvidas.
Uma forma muito utilizada no mercado para transformar uma ideia em
realidade é a utilização de um produto mínimo viável, o famoso MVP
(Minimum Viable Product), que é muito utilizado para prova de conceito,
se uma ideia realmente é interessante ou apenas uma expetativa.
Um MVP é uma versão simplificada, mínima para demonstração da ideia,
ou seja, é um produto realmente funcional que pode ser evoluído
gradativamente após validação inicial e possui muitas vantagens, como
redução de desperdícios, redução de tempo, redução de custos e,
principalmente, incertezas.
Eric Reis, autor do livro “The Lean Startup”, e onde o conceito de MVP é
definido e lapidado o define como “a versão de um novo produto que
permite uma equipe coletar o máximo de aprendizado validado sobre os
clientes com um mínimo esforço”. É muito importante lembrarmos que
MVP não é um protótipo pois ele é funcional, mesmo que minimamente;
um protótipo não é funcional. Além do mais, é muito importante
entendermos que MVP, também não é sinônimo de mal feito ou feito de
forma corrida, mas sim uma versão bastante simplificada e funcional de
um produto qualquer que nos permite, através da utilização real, validar
suas funcionalidades em relação a ideia original. Um MVP é, portanto,
uma versão menos completa, ou seja, apenas com o mínimo necessário.
Alguns autores o chamo ainda de uma versão enxuta.
Outra vantagem competitiva do MVP é que ele reduz o tempo de
colocação no mercado (TTM – Time do Market) pois os testes iniciais são
feitos com um grupo seleto e real de usuários gerando, portanto,
resultados reais e mensuráveis.
Antes de publicarmos nosso MVP, temos que capturar potenciais usuários
para nosso App. Uma técnica bastante utilizada para isso vem do
marketing digital para captação de leads (potenciais clientes) é a técnica
de utilização de uma landing page, ou seja, uma página única, bastante
simples, mas com muitas informações relevantes sobre o App, imagens
atraentes, vídeos e recursos de retenção do usuário que o convence à
utilizar o produto ou App e, portanto, o próprio usuário preenche um
pequeno cadastro (normalmente bastante simples, somente nome e e-
mail, por exemplo) para aguardar mais informações sobre o assunto. Uma
das principais vantagens de se utilizar este recurso é a captação de
usuários reais interessados no produto, permitindo ainda uma análise (e
constatação) precisa ir real do perfil do público-alvo, além, claro, de uma
análise de penetração do mercado de fatores de impacto.
Quando desenvolvemos projetos, independentemente se for de um App
ou de qualquer tipo de software ou sistema muito maiores, temos sempre
considerar e pensar no famoso triângulo de gestão de projetos, conhecido
também como restrição tripla de gestão de projetos ou, até mesmo,
triangulo de ferro, visto na figura 1. Estatisticamente projetos se apoiam
mais em um dos lados deste triângulo e qualquer fator que afete suas
arestas, afetará, portanto, também seu centro ou seja a qualidade do
projeto. Por muitas vezes temos escopos muito bem definidos e imutáveis
e temos de fazer ajustam do tempo e dos recursos financeiros do projeto,
por outro lado temos por muitas vezes que gerenciar o tempo, pois o
projeto possui uma data bem definida para entrega e, neste caso, temos
que gerenciar cuidadosamente os recursos financeiros e o escopo. Da
mesma forma como temos as vezes um orçamento fixo e imutável, onde
temos que gerenciar o escopo e o tempo. Não são incomuns projetos em
que temos fixos mais de um item, como tempo e recursos financeiros, nos
obrigando a gerenciar o escopo para mantermos a qualidade.
Figura 1 - Restrições triplas de projetos
Conforme as próprias metodologias modernas gestão de projetos
mencionam, após a ideia bem consolidada, é preciso criarmos
mecanismos de comunicação interna eficiente para os envolvidos no
projeto. É muito importante que todos envolvidos saibam os reais objetivos
do App. Precisamos conhecer também o perfil do nosso usuário
profundamente, definir layouts realmente bons e funcionais, com rotas
muito bem definidas. A linguagem visual e utilizada no App precisa ser a
mesma do perfil de nosso usuário.
É muito importante ter em mente logo no início do processo de
desenvolvimento como o App será monetizado, além, dos custos do
desenvolvimento, marketing, publicação do App, jurídico, estimativas de
retorno do investimento (ROI) etc. Escolha tecnologias certas, tomando
cuidado com novas tecnologias que prometem muitas coisas e podem, a
qualquer momento, ser descontinuadas. Teste antes uma e tenha uma
equipe alinhada e comprometida com a tecnologia utilizada.
Conhecer o mercado também é muito importante, para saber onde estão
e quais são os seus concorrentes Silver. Planeja tudo cuidadosamente
com ferramentas necessárias para isso. Use e abuse e de técnicas de
prototipação, storyboard, wireframes etc. Use metodologias de gestão
adequadas, sem deixar de considerar implantação contínua e automação
para um backend eficiente e bem desenvolvido. Insista em testes e não
deixe de documentar todo o processo.
 
Projetos de jogos
 
Essa parte de nosso conteúdo foi montada com base no livro se Scott
Rogers, chamado “Level Up, um guia para o design de grandes jogos”,
um importante autor da área, com uma vasta experiência de mercado e
profundidade sobre o tema.
Um jogo, apesar de ser um software, não se limita ao processo
convencional de desenvolvimento devido a suas diversas características
e, por isso, precisamos ilustrar bem o processo de desenvolvimento de
jogos, que vai muito mais a frente, ou seja, além de todos os requisitos
mínimos que precisam ser cumpridos para o desenvolvimento de um App
(que também pode ser através de um MVP), há mais fatores envolvidos.
Por exemplo, o perfil dos jogadores passa a ter um papel importantíssimo
nas regras de negócio do mesmo.
Antes de mais nada temos que definir o que é um jogo. Segundo Rogers
o jogo pode ser definido em três itens: (1) requer, no mínimo, um jogador;
(2) tem regras; (3) tem uma condição de vitória.
Sabendo disso podemos então começar a dar início ao documento do
jogo. Tudo começa com definição de uma ideia e de um estilo para o jogo
(ação, aventura, arcade, luta, corrida, tabuleiro entre muitos outros). Há
várias técnicas para se organizar as ideias, como brainstorm (tempestade
de ideias, onde você pensa em tudo que quer no jogo depois organiza
sistematicamente), mapas mentias (encontre elementos e os relacione)
etc. É muito importante anotar as ideias para que não sejam perdidas ou
descartadas acidentalmente, uma vez que podem vir a qualquer
momento, inclusive com ideias relacionadas.
Rogers afirma que para o desenvolvimento de um jogo é preciso incluir
um documento no processo gramado game design document, documento
de design do jogo, ou simplesmenteGDD. Esse documento tem como
desativo a comunicação bastante clara entre os membros de uma equipe.
Podemos até dizer que o GSDS é comparável ao termo de abertura do
projeto (TAP) do PMBPK. Não existe tamanho mínimo, formato o modelo
padrão para este documento. Muitos autores definem tópicos a serem
abordados, mas nada limpeza de acrescentar o remover itens. O próprio
Rogers propôs dois modelos para o GDD, evoluídos um do outro: O GDD
de página única e o GDD de dez páginas.
Para ROGERS, o documento de página única deverá ter uma visão global
do seu jogo, ou seja, esse documento será lido por diversas pessoas da
sua equipe, então necessita ser informativo, interessante, objetivo e curto.
Qual o tamanho ideal desse documento? Resposta: conter todas as
informações em uma única página. As informações abaixo devem constar
do documento de página única:
 
·Título do jogo
·Plataformas pretendidas
·Faixa etária dos jogadores
·Classificação indicativa
·Resumo da história do jogo, focando no Gameplay
·Modos distintos do Gameplay
·Diferenciais de vendas
·Produtos concorrentes
 
Outra forma de apresentar O GDD, segundo Rogers, é o documento de
dez páginas. Uma vez criado o rascunho do jogo pela documento de
página única, direcionamos o trabalho para o documento de dez páginas
que é a espinha dorsal do seu jogo. Aqui o importante é fazer com que os
leitores entendam o básico do produto final do jogo, sem entrar em
detalhes aprofundados. ROGERS sugere a criação do documento de dez
páginas utilizando um software de apresentação de slides como o Power
Point da Microsoft, porque irá ajudar na formatação e ajudará em uma
reunião ou mesmo imprimir como um folheto. Sempre que redigir o
documento de dez páginas faça a seguinte pergunta: "Qual é o meu
público-alvo?". Abaixo seguem os elementos que devem constar em cada
página ou slide do documento. Página 1: Título do Jogo: A primeira página
deverá constar os seguintes itens:
 
·Título do Jogo;
·Plataformas em o jogo será executado;
·Idade dos jogadores;
·Classificação ESRB ou classificação indicativa brasileira pretendida;
·Data de lançamento do jogo.
 
ROGERS sugere que ao criar o título do jogo já pensar na criação do
logo. Para o título do jogo, pense em utilizar uma fonte apropriada, pois a
fonte de escrita poderá descrever o gênero do jogo, mesmo sem utilizar
imagem, por exemplo, qual fonte de escrita foram utilizadas nos jogos
God of War e Diablo? São fontes comuns?
Página 2: Rascunho do Jogo: Os itens que devem constar na página 2
são:
Resumo da história do jogo - aproveitando o documento de página única,
aqui deverá ser descrito em alguns parágrafos o resumo da história, tendo
em mente que a história deverá conter um início, um meio e um fim; fluxo
do jogo - ROGERS sugere um exemplo bem descritivo sobre o fluxo do
jogo Tomb Raider. "Tomb Raider: Legend é um jogo de ação e aventura
em terceira pessoa que coloca Lara Croft, nossa heroína, procurando
tesouros desbravando as selvas da Bolívia até as montanhas do Tibete,
pela chave Ghalali; um artefato misterioso que poderá ser a chave para
encontrar a sua mãe desaparecida a anos". Quais as características
podemos perceber no exemplo de ROGERS?
 
·Com quem está jogando? Lara Croft;
·Qual o ângulo da câmera? Terceira pessoa;
·Gênero do gameplay? Ação e aventura;
·Locações do jogo? Bolívia e Tibete;
·Objetivos do jogo? Encontrar a chave Ghalali e solucionar o mistério do
desaparecimento da mãe de Lara Croft
 
Outras questões que devem ser respondidas pelo fluxo do jogo: Quais os
principais desafios que o jogador irá enfrentar e quais métodos serão
utilizados para superar esses desafios? Qual a condição de vitória para o
jogador? Salvar o Mundo? Matar todos os inimigos? Colecionar 50 baús?
Caso o jogo não possuir um personagem, você deverá se concentrar nos
ambientes e nos níveis do jogo.
Na página 3: Personagem, ou seja, a descrição bem como as
características das personagens deve ser descrita na página 3,
informações como idade, sexo como outras informações que agreguem e
que sejam pertinentes ao personagem. Algumas perguntas devem ser
respondidas como:
 
·Como é a aparência do seu personagem?
·Qual o histórico das personagens do seu jogo?
·O que o personagem fez para entrar nessa enrascada?
·Como é a personalidade do personagem?
·Como o personagem responde ao desafio do jogo?
·Como o personagem se relaciona com o Gameplay?
·O personagem tem algum ataque, movimento, habilidade ou mesmo
algum armamento especial ou particular?
 
Nesta página será importante mostrar um mapa básico dos controles do
personagem, se for um jogo para mobile, mostre onde e como o jogador
irá controlar o personagem na tela do dispositivo móvel. Se o jogo for para
computador ou console, utilize uma imagem de um controle (joystick) e
mostre para que servem cada botão do controle.
Na página 4: Gameplay. Nessa página serão descritos os gêneros do seu
jogo, bem como os diferenciais de venda do documento de uma página.
ROGERS sugere que o texto seja iniciado detalhando como a sequência
do jogo será apresentada. Na história existirão vários capítulos? O jogo é
dividido em níveis ou rounds? Existe cenários que despertem a
curiosidade do jogador como dirigir enquanto atira ou mesmo fugir de um
Ogro gigante? Esses detalhes devem ser destacados
Na Página 5: Mundo do Jogo. Aqui você deverá apresentar imagens e
descrições do mundo do seu jogo, listando os ambientes mencionados na
história. O importante é fornecer descrições curtas que mostre o que o
jogador irá encontrar no seu mundo. Pense no seguinte: Como as
locações se amarram na história? Qual o clima será evocado no seu
mundo? Seu personagem conseguiria viver no seu mundo?
Na página 6: Experiência de Jogo, ou seja, as experiências dos jogos
podem ser representadas como as sensações que o seu game passa ao
jogador, por exemplo, Terror, Hardcore, Eletrizante, Assustador, Sexy. A
sensações devem ser passadas desde o início do jogo, logo na tela de
abertura por exemplo. Algumas perguntas devem ser respondidas nessa
etapa da descrição do documento de dez páginas; qual é a primeira coisa
que o jogador irá ver quando inicia o game? Quais emoções ou climas
serão invocados no seu jogo? Como a música e os sons serão utilizados
para criar o ambiente do jogo?
Como o jogador irá navegar pelas telas do jogo? Nesse caso um
diagrama simples de navegação responderá à pergunta.
Na página 7: Mecânicas do Gameplay. Para ROGERS, dois termos são
essenciais para descrever as mecânicas do Gameplay: mecânica e
perigo. Mecânica - é algo ou uma ação que o jogador interage para criar
ou auxiliar o Gameplay. Exemplos: plataformas móveis, portas que abrem,
cordas que balançam. Perigo - é uma mecânica que não tem inteligência,
mas pode matar ou ferir o jogador. Exemplos: buracos com estacas, jatos
de fogo, lâminas de guilhotina que balançam. Nesta etapa citando três
mecânicas serão suficientes, mas devemos pensar também: Que tipo de
mecânica é utilizada em seu jogo? Como estas mecânicas serão
utilizadas no ambiente? Os power-ups e os itens coletáveis devem ser
destacados na página 7. Um power-up é um item a ser encontrado e
coletado pelo jogador para ajudá-lo no gameplay, por exemplo: munição,
vida extra. Coletáveis - são itens que serão coletados que não tem uma
ação imediata no gameplay. Exemplos: moedas, estrelas, peças de um
quebra-cabeça, itens de um troféu, pedaços de uma relíquia. Para os itens
acima, ROGERS sugere novas perguntas a serem respondidas: O que o
jogador coleta? Qual o benefício de coletar esses itens? Os itens
coletados, como moedas, podem ser usados para comprar algo como
novos itens, habilidades ou destravar algum tipo de material no decorrer
do jogo? Colecionando esses itens, o jogador ganhará algum troféu ou
conquista? Se o jogo tiver algum sistema de compra e venda, deverá ser
descrito e forma abreviada!
Na página 8: Inimigos, onde serão descritos os personagens inimigos do
jogo, ou seja, quais inimigos você encontrará no jogo? Quais as
característicasfazem desses inimigos únicos? O que o jogador deve fazer
para superar esses inimigos? Um inimigo do final do jogo conhecido como
BOSS, são maiores e devem ser bem mais assustadores que os demais
inimigos, porque tem personalidades únicas. Se puder mostrar um
desenho do BOSS, mas interessante será seu documento.
Na página 9: Cenas de Corte; aqui serão descritas as cenas de corte do
jogo, ou seja, uma sequência animada que o jogador não terá acesso,
apenas ficará assistindo, que é utilizada para avançar na história, ou
mesmo uma cena para criar uma atmosfera, um diálogo ou mesmo para
revelar pistas no jogo.
Finalmente na página 10: Materiais e Bônus. A última página deverá
conter informações sobre os materiais e bônus do jogo, informações que o
jogador deverá conhecer para continuar ou voltar a jogar, fases ou
conteúdos que podem ser baixados, um novo episódio por exemplo. Hoje
em dia se fala muito em DLC (downloadable content, conteúdo que se
pode baixar), por exemplo o jogo Destiny vai liberar uma nova DLC em 19
de maio de 2015, com isso foram liberados diversos videos mostrando as
fases e os novos modos de jogo que faz com que os jogadores, como o
autor desse material por exemplo, fiquem na expectativa para chegar ao
dia que a DLC estará disponível.
 
 
 
Serviços de backend para aplicações móveis
 
Tecnologias de backend estão cada vez mais avançadas e existem
muitos serviços que podem facilitar demais nossa vida quando estamos
desenvolvendo Apps. São os famosos BaaS, ou backend as a
service (backend como serviço).
O BaaS usufrui da arquitetura clássica cliente-servidor, incluindo uma
camada de abstração que fornece uma série de serviços rápidos e de fácil
acesso.
Na arquitetura clássica cliente-servidor, o browser ou App faz uma
requisição (que chamamos de request), através da internet para um
servidor. Este recebe, faz todo o processamento, consultas em bancos de
dados, abre e lê arquivos etc., gerando assim uma resposta (que
chamamos de response), que é devolvida para o cliente através, também,
da internet.
No BaaS o processo é essencialmente o mesmo, entretanto todo o
backend, processamento, consulta à bancos de dados, gestão de
memória etc., são feitos por softwares prontos os quais não precisamos
nos preocupar em nossas aplicações móveis, ou seja, apenas enviarmos
as requisições e recebemos respostas, sem a necessidade de nos
preocupar com a modelagem do banco de dados, como os dados e
arquivos são persistidos etc.
Existem vários serviços de BaaS disponíveis no mercado, como o Google
Firebase (um dos mais famosos e utilizados), o Back4App, Amazon
Lambda, Azure Mobile Cloud Apps, Heroky, MongoDB Stitch etc.
 
Prototipação de aplicações móveis
 
A prototipação, de um App ou sistema, está intimamente ligada a geração
de um protótipo, que é algo feito pela primeira vez, um modelo preliminar e
é muito utilizado para prova de conceito e planejamento.
Para produtos físicos podemos utilizar várias técnicas, com modelagem
argila, madeira, confecção manual, maquete etc. Para as engenharias
arquitetura são utilizados softwares de CAD (Computer-aided design), por
exemplo. E para software? Como criamos protótipos de interfaces? Para
isso existem as diversas técnicas e ferramentas de prototipação.
Não podemos esquecer que softwares precisam ser planejados
cuidadosamente. Se há hardware em nosso projeto, também precisamos
planejá-los cuidadosamente, através de protótipos e muitos testes. Para
software, especificamente, utilizamos as ferramentas de prototipação que
nos permitem criar wireframes e, os próprios protótipos, que são
representações visuais (muitas vezes muito detalhadas) de nossas
aplicações.
Há muitas vantagens em criar alguns protótipos para nossos Apps, sites e
softwares como:
 
Redução de ciclos de redesign
Análise de viabilidade
Redução de riscos e incertezas
Comunicação eficiente entre equipes distintas e redução de dúvidas
Validação de escopo e requisitos
Clientes podem validar e dar feedbacks
 
Uma das técnicas de prototipação para software é a utilização
de wireframes, que são representações visuais de uma interface utilizadas
para comunicar a estrutura, o controle, hierarquia de informação,
funcionalidade e comportamento de muito fácil. É bastante simples e
normalmente representada apenas por uma estrutura de “arames”. Jakob
Nielsen afirma ainda que os wireframes são “técnicas de design de baixo
custo, rápidas interativas, que oferecem um dos melhores métodos para
se conseguir obter conhecimentos iniciais de um projeto”.
Outra forma bastante comum de se prototipar aplicações e Apps é com o
auxílio de ferramentas profissionais para este fim. Algumas destas
ferramentas permitem ainda a exportação para uso no projeto de
desenvolvimento, facilitando ainda mais o trabalho dos desenvolvedores.
Algumas das ferramentas mais utilizadas no mercado são o Figma, o
Adobe XD, Marvelapp, Mockflow, Lucidchart, Lunacy, Protopie, Sketch
entre outras.
 
 
 
Atividade extra
 
Leia mais sobre a criação do GDD (Game Design Document) em
referências interessantes e relevantes, como:
https://producaodejogos.com/gdd/
https://www.senacrs.com.br/cursos_rede/planejamento_de_jogos_digitais_para_multiplataformas/htm
https://www.crieseusjogos.com.br/como-criar-um-gdd-game-design-
document-modelo-para-download/
 
 
 
Referência Bibliográfica
 
 
 
PMI – Project Management Institute. Guia PMBOK: Um Guia para o
Conjunto de Conhecimentos em Gerenciamento de Projetos, 6ª ed.,
Pennsylvania: PMI, 2017.
https://producaodejogos.com/gdd/
https://www.senacrs.com.br/cursos_rede/planejamento_de_jogos_digitais_para_multiplataformas/html/gdd/gdd/index.html
https://www.crieseusjogos.com.br/como-criar-um-gdd-game-design-document-modelo-para-download/
ROGERS, Scott. Level UP: um guia para o design de grandes jogos. São
Paulo: Blucher, 2012.
NOVAK, Jeannie, Desenvolvimento de games. São Paulo: Cengage
Learning, 2011.
WINDMILL, Eric. Flutter in action. Nova Iorque: Manning publications,
2020. E-book. Disponível em: https://learning.oreilly.com/library/view/flutter-
in-action/9781617296147/. Acesso em: 23 mar. 2020.
Nielsen J., Budiu, R., Usabilidade Móvel, Editora GEN LTC; 1ª ed., 2013
Ries, E., The Lean Startup: How constant innovation creates Radically
Successful Businesses, ed. Portfolio Penguin, 1ª. ed, 2011