Na prática: A metodologia Olympus para desenvolvimento de projetos de software

Introdução

Criar um app por si só já é uma tarefa complexa. Criar um que resolva, de fato, as demandas de clientes reais, é mais complexo ainda. São necessárias reuniões, estimativas, planos de negócio e conhecimento técnico para fazer tudo acontecer dentro do prazo.

Ao longo dos anos nós da Olympus dedicamos nossa atenção e tempo para buscar, adaptar e melhorar processos que tornem essa tarefa mais simples. A partir dos nossos estudos nós criamos um método que aplicamos com todos nossos parceiros para entender os objetivos do projeto e modelar uma entrega que exceda as expectativas.

Nós nunca havíamos compartilhado em detalhe nossos processos. Mas um convite do nosso amigo e youtuber Lucas Montano fez com que começássemos a nos mover num sentido diferente.

O convite foi para cocriarmos o Memo, um aplicativo de aprendizado gamificado baseado em Anki e aplicado a programação. O objetivo do app será ajudar os inscritos do canal a praticarem seus conhecimentos técnicos de maneira divertida e engajada.

Além disso, e talvez ainda mais importante, é que todo esse processo será completamente documentado em texto por aqui e por vídeo no canal do Lucas. Dessa maneira você poderá acompanhar todos detalhes desde a concepção inicial do app até o lançamento de um produto já refinado.

Tudo que você gostaria de saber sobre os processos utilizados no mercado para idear um projeto real, desenhar as funcionalidades iniciais, estimar o escopo e colocar tudo em produção para o lançamento de um MVP serão cobertos nessa série de artigos e vídeos.

Neste primeiro artigo da série iremos conhecer mais do método de desenvolvimento da Olympus e quais foram as resultantes da aplicação deste método no projeto proposto pelo Lucas.

Qual nosso background?

Somos um time de especialistas em desenvolvimento de software apaixonados por processos, qualidade de software e experiência do usuário. Nossa equipe se formou dentro do Apple Developer Academy, um projeto de pesquisa e desenvolvimento realizado pela Apple, e desde nossa união já impactamos milhares de usuários em mais de 10 países diferentes com nossos apps sendo múltiplas vezes destacados dentro da App Store.

Quais são nossas referências?

Nosso processo atual é a resultante da união do conhecimento que construímos ao longo dos anos estudando a respeito e a experiência prática que obtivemos ao desenvolver software para clientes no mundo real. Dito isso existem 3 livros que foram muito formadores para nosso processo e gostaríamos de destaca-los aqui. São eles:

• Sprint: O método usado no Google para testar e aplicar novas ideias em apenas cinco dias;
• Scrum: A arte de fazer o dobro do trabalho na metade do tempo;
• Shape Up: Stop Running in Circles and Ship Work that Matters (apenas em inglês).

A partir do balanço entre estudo e prática nós desenvolvemos a nossa metodologia própria divida em 4 fases principais: R&D, shaping, produção e finalização.

Qual objetivo de cada fase?

R&D

Essa fase representa o começo do projeto e tem 3 objetivos principais: mergulhar a equipe no contexto do projeto e seu público através de pesquisas e entrevistas, definir quais serão os objetivos do projeto e definir as métricas que serão utilizadas para avaliar as resultantes.

Shaping

Aqui que o projeto começa a tomar forma. Os objetivos dessa fase são definir a estrutura do projeto, realizar estudos sobre tecnologia, definição da arquitetura, definição das regras de negócio, identificação e resolução dos "buracos negros" (veremos mais sobre na sessão detalhando o processo de shaping).

Produção

Fase de criação e refino do design do projeto e codificação do design e regras de negócio definidas anteriormente. O objetivo aqui é transformar em realidade todos os estudos e estruturas mapeadas até então. Aqui também realizamos os testes (automatizados e manuais) e validações necessárias da tecnologia.

Finalização

Ao fim do processo adicionamos a fase de finalização para realizar os últimos ajustes necessários para o lançamento do projeto e também para o acompanhamento do lançamento em si. O objetivo dessa fase é colocar o projeto final na mão dos usuários.

OBS: durante este primeiro artigo iremos descrever em maior detalhe as fases de R&D e Shaping, as duas partes que já realizamos do projeto até agora. Nos próximos artigos da série teremos o detalhamento das resultantes das próximas fases.

O SCRUM em cada uma das fases

Cada uma das fases são compostas por um conjunto de uma ou mais Sprints de 2 semanas. A Sprint é o período produtivo da equipe e começa com uma reunião de planejamento onde definimos e estimamos as tarefas que serão executadas naquela semana. Depois das duas semanas o fim da Sprint é marcada pela reunião de revisão e retrospectiva onde apresentamos o que foi entregue para a equipe e partes interessadas (clientes, fornecedores, parceiros e etc).

R&D: Mergulhando no contexto

A fase de R&D (research & development) é onde toda nossa pesquisa e desenvolvimento iniciais do projeto acontecem. Ela é o primeiro passo após o início do projeto. Nela temos 3 principais ferramentas que utilizamos e seus usos variam de projeto para projeto. São elas:

• Entrevistas com especialistas nas áreas do conhecimento relevantes para o projeto e também com o público alvo;
• Benchmarks de produtos concorrentes na mesma área e também de referências em áreas distintas;
• Pesquisas e análise de estudos e artigos envolvendo as áreas de conhecimento relevantes para o projeto.

Essas ferramentas são utilizadas ao longo dos 5 momentos que compõe essa fase de R&D. Esses momentos não necessariamente precisam acontecer na mesma ordem, mas todos estão presentes nos nossos projetos.

• Reunião de kickoff: aqui marca-se o início do projeto e nosso objetivo é alinhar entre partes interessadas e equipe de desenvolvimento qual será o objetivo do projeto. Buscamos encontrar uma frase que reflita o objetivo do projeto de maneira sucinta e inspiradora;
• Autoanálise (imersão na cultura): todo cliente que chega até nós, possui uma certa cultura, áreas do conhecimento e formas de trabalhar que buscamos entender e traduzir para o desenvolvimento do software da melhor forma possível. Nesta fase entrevistamos os principais especialistas do assunto, pessoas conectadas ao projeto e também estudamos qualquer documentação relevante provida pelo cliente ou que encontramos ao estudar a empresa;
• Pesquisa de Contexto (Mercado e concorrentes): aqui vamos entender qual a situação atual do mercado e quem são os players envolvidos de alguma forma, sejam órgãos regulatórios ou competidores diretos. Aqui acontece muita pesquisa para identificar essas partes e estudar suas participações no contexto;
• Entendimento do público: quando o público alvo é não é parte integrante da equipe de alguma maneira nós buscamos realizar entrevistas e estudos para compreender seus objetivos, aspirações e dificuldades;
• Sum Up e Análise das Informações: esse momento acontece ao fim do processo. O objetivo aqui é realizar o "download" e análise de todos os conteúdos para formalizar numa apresentação que será feita para equipe com intuito de criar um entendimento geral e fomentar discussões a respeito;
• Apresentação dos resultados: a reunião que marca o fim da fase de R&D e o começo da fase de shaping. Aqui apresentamos os resultados para equipe e partes interessadas com o intuito de coletar feedack para fase de shaping.

R&D Aplicado: Resultantes da Pesquisa

O Memo tem o objetivo de ser um projeto educacional focado em desenvolvedores de software. Sendo assim nossa fase de R&D envolveu uma boa pesquisa de referências de UX/UI e estudos de artigos científicos e métodos de aprendizagem que nos ajudassem a criar uma experiência fluída ao usuário e que também o engajasse no processo de aprendizagem.

Com o resultado dessas pesquisas nos construímos um mood board que pode ser visualizado clicando aqui. O intuito do mood board é agrupar todas as referências visuais encontradas e conectar isso com os data findings, que são os artigos, dados e materiais relevantes que a equipe encontrou durante suas buscas.

Dois destaques dessa fase de pesquisa foram o Janki Method (um método de aprendizagem baseada em Anki criada por Jack Kinsella) e o curso Aprendendo a Aprender da Coursera. Ambas são fontes riquíssimas, gratuitas e muito aprofundadas sobre as áreas de conhecimento do projeto.

A equipe também mapeou os vídeos mais assistidos do canal do Lucas para entender as preferências do público e comparou com as perguntas mais votadas no Stack Overflow (plataforma de perguntas & respostas para desenvolvedores) para entender as dúvidas de programação em geral.

Outro ponto de vista importante é a opinião do mercado de trabalho, por isso buscamos mapear as perguntas mais realizadas durante entrevistas de recrutamento para as vagas almejadas pelo nosso público alvo, dessa maneira podemos conectar o conhecimento técnico com a prática do mundo real.

Shaping: Dando a forma inicial

A partir dos estudos do material resultante da fase de R&D o nosso time entra na fase de Shaping com o objetivo de desenhar o "esqueleto" do projeto. Durante essa fase, contamos com 3 ferramentas principais e utilizamos cada uma de acordo com a necessidade de cada projeto:

• Breadboarding: este processo foi adaptado pela Olympus a partir do conceito apresentado em Shape Up. No Breadboarding nós começamos pelo nível de abstração mais básicos e usamos apenas 3 elementos para compor a estrutura do projeto de software que iremos desenvolver:
  
  1. Lugares: itens o usuário pode navegar para: telas, menus, diálogos, etc;
  2. Recursos: itens que o usuário pode interagir: botões, campos, textos, etc;
  3. Linhas de conexão: como os recursos levam o usuário de lugar em lugar.
  
  Nós usamos palavras para tudo ao invés de desenhos ou imagens. O importante aqui é identificar os componentes e suas conexões. Isso nos permite identificar se determinada sequência de ações resolve o problema que estamos tentando criar. A vantagem de utilizarmos esse método primeiro é que conseguimos idear rapidamente a estrutura do projeto sem nos comprometermos com um design específico. Ao criarmos um protótipo com mais definição visual, antes do Breadboard, podemos acabar limitando a capacidade criativa do designer da equipe.
• Protótipo de baixa fidelidade: subindo um nível de abstração nós temos o protótipo de baixa fidelidade. Aqui podemos encaixar um conjunto bem grande de possibilidades, desde o desenho com papel e lápis até uma colagem de papel. Tudo depende das necessidades e do escopo de cada projeto. O importante aqui é notar que normalmente pouco ou nenhum software é utilizado nessa fase. A ideia é criar um primeiro esqueleto visual do app sem ainda se comprometer com todos os detalhes. Nem todos os projetos contam com o protótipo de baixa fidelidade, pois muitas vezes o processo de Breadbording nos da confiança suficiente para pularmos este passo e irmos ao nível de abstração seguinte.
• Protótipo de alta fidelidade: no último nível de detalhamento temos o protótipo navegável de alta fidelidade onde desenhamos a estrutura inicial do app e transformamos ela numa versão navegável que podemos apresentar a possíveis usuários, ao cliente ou qualquer outra parte interessada. Aqui normalmente o designer já começa a definir melhor alguns detalhes da interface e cria a primeira versão que será aprovada pelo cliente para começarmos a fase de produção do app onde iremos transformar o protótipo no aplicativo final.

Shaping Aplicado: A Estrutura modelada

Nosso processo de Shaping para o Memo começou logo após a apresentação dos resultados do processo de R&D para equipe. Começamos pela nossa ferramenta base nesse processo: o breadboarding.

Identificamos em nossas pesquisas que a presença de alguma forma de acompanhamento dos resultados ao longo do tempo seria essencial para ajudar o usuário a perceber sua evolução no estudo. Por isso logo decidimos que deveríamos ter a presença de alguma forma de análise de estatísticas para o usuário. Chamamos essa sessão de Analytics.

Além disto, por ser um sistema de aprendizado baseado em Anki, o app deveria contar com diversas listas de cards compostos de perguntas/respostas que serviriam para o usuário memorizar o conteúdo sendo revelado a cada jogada. O local onde o usuário veria essas listas seria chamado de Lista de Decks.

A dinâmica para versão inicial será simples: o usuário terá diversos decks (conjuntos de cards) com perguntas e respostas de conteúdos relevantes para o público alvo. Durante o game ele irá ler a pergunta e ver a resposta de cada card, ao visualiza-la ele deverá marcar se lembrava ou não da resposta correta. Ao fim do processo todos dados seriam mapeados para o analytics.

Próximos passos

Chegamos ao fim da fase de shaping com um entendimento muito maior do projeto, qual será sua estrutura e quais serão os elementos necessários para criarmos uma primeira versão do app. Nos próximos artigos iremos descrever em detalhes os processos de produção e finalização do projeto. Aguardamos vocês lá.

Alguma dúvida ou sugestão? Escreva para gente!

Caso tenha alguma pergunta, feedback ou proposta envie um e-mail para hi@olmps.co.