Como lançar um aplicativo de sucesso no mercado

A era digital chegou e com ela a busca em facilitar os serviços que nós utilizamos no nosso dia a dia. Hoje os aplicativos tomam a frente quando se trata de otimizar e inovar nas ações diárias das pessoas. Por exemplo, não precisar mais ir ao banco e ter a facilidade de realizar as atividades que levariam horas em minutos na tela do seu Smartphone. Ou até mesmo, você se lembra qual foi a última vez que você ligou para pedir um táxi? 

Um estudo feito pela Kantar Worldpanel Comtech mostrou que 56% da população brasileira usava Smartphone no primeiro semestre de 2016, em comparação com 6% no ano de 2012,  e esse número só cresce. Os preços dos aparelhos estão cada vez mais acessíveis e com o crescimento pela busca de um celular mais moderno, vem também a busca por funções e facilidades melhores. Dê uma olhada nesses dados sobre de que forma e para que uma pessoa utiliza seu celular atualmente:

utilidades

Os tempos mudaram e agora se uma empresa não inova, não investe na tecnologia, ela fica para trás.  Afinal, isso é essencial para conquistar novos clientes, melhorar seus processos, lançar novos produtos, agilizar o atendimento, entre outros. Então, se você já pensou em investir na área de apps, aqui estão alguns pontos que precisa saber.

Como tirar a minha ideia do papel?

Assim como em todo segmento do mercado, a concorrência na área dos aplicativos é grande. Muitos projetos acabam não indo para a frente porque não correspondem à realidade do que as pessoas realmente necessitam.

A primeira coisa a se fazer antes de começar a produzir o seu app, é saber se a sua ideia resolve algum problema e descobrir se as pessoas necessitam da mesma. A melhor forma de fazer isso é através de uma pesquisa com o público. E também verificar se o que você quer produzir seria algo que eles usariam.

Antes de lançar algo, é essencial que o empreendedor primeiro valide-o através de um Mínimo Produto Viável (MVP). Isso quer dizer, desenvolver um produto apenas com as funcionalidades essenciais para lançar de imediato no mercado. Gastando assim menos tempo, investimento e esforço. É preciso também verificar se ele será utilizado pelas pessoas ou se realmente é uma necessidade. Se não for, é necessário adaptá-lo para a realidade dos consumidores.

mvp1

Mas por que começar pelo MVP?

É extremamente importante para os negócios que ainda não estão estabelecidos no mercado começar com um MVP! Imagine assim, você tem uma ideia e acredita que fará muito sucesso (e deve acreditar mesmo), e devido a isso, investiu muito para fazer o produto perfeito, com todas as funcionalidades que você quer fazer. Mas na hora de lançá-lo, não era uma necessidade do seu público. Ou então, as pessoas acharam ele muito complexo ou confuso e por isso acabou não sendo vendido ou utilizado.

Todos devem confiar na capacidade dos seus projetos, mas não basta só o empreendedor ver esta necessidade, é preciso que o mercado enxergue isso também.

Vamos imaginar um segundo cenário, onde o empreendedor antes de começar com a produção, fez uma pesquisa e verificou se há necessidade. Após isso, ele criou um MVP com o menor investimento possível baseado nas informações que recolheu. Porém, mesmo assim, acabou lançando algo que não era exatamente o que aquele público precisava ou que é muito complexo e confuso.  Devido a isso, as pessoas não souberam exatamente como usar e assim o projeto não obteve o sucesso pretendido no primeiro momento.

Triste, mas acontece não é? Por isso o MVP é importante, enquanto no primeiro cenário gastou-se mais tempo e dinheiro, no segundo cenário, o empreendedor errou antes e gastou pouco. Com isso, ele pôde utilizar o restante do investimento para refazer o que foi produzido ou aprimorar de acordo com o feedback dos clientes.

Independente do tipo de público que você esteja planejando ter como alvo, sempre antes de investir tudo em algo novo é preciso validá-lo primeiro.  No desenvolvimento de aplicativos isso não é diferente.

Tenho a minha ideia para um app, já posso começar a desenvolver?

Como em qualquer negócio, a primeira coisa que você deve ter para desenvolver o produto é o investimento. No mercado de software esse valor pode variar de 30 a 90 mil reais por plataforma (Web, iOS, Android, etc). Esta variação também acontece de acordo com as funcionalidades que você deseja ter no seu aplicativo.

Quando se trata de desenvolvimento de software, assim como de um edifício, mais importante do que “o que desenvolver” é “como desenvolver”. Por isso, antes de partir para o desenvolvimento de qualquer funcionalidade, é necessário que você comece pelo design dele. Este design irá definir como funcionará o aplicativo, e traçará o fluxo de cada uma das telas do mesmo. Apenas com o design é possível para a maioria das empresas de desenvolvimento de software, inclusive a Jera, passar um orçamento mais preciso.

Na Jera, o período médio para realizar o design é de duas semanas.

semana-1

Pense no design como a planta de um edifício, antes de passar para a construção, é preciso você ter este planejamento de como ele irá ficar, para saber qual será a melhor forma ou técnica que o construtor deverá utilizar para fazê-lo. O mesmo é com o desenvolvimento de software! Portanto, o design é a primeira etapa para tirar a sua ideia do papel.

E se você está procurando por investidores, o design das telas será um grande aliado seu. Pois com esses desenhos você pode apresentar algo mais palpável para o seu futuro investidor, algo mais real e visual. E com isso aumentar as suas chances de obter um maior investimento para realizar o desenvolvimento.

Quero começar o desenvolvimento, mas não tenho muito dinheiro. Existe alguma opção mais em conta?

Existem duas formas de desenvolver um aplicativo: híbrido ou nativo. O híbrido é o mais recomendável para quem tem um orçamento limitado ou ainda está validando o produto. Ele é desenvolvido em uma plataforma só (a web) e depois encapsulado para Android ou iOS.  Para utilizá-lo, o usuário deve ter acesso à internet, porque quando ele entra no app, na verdade ele está entrando em uma página da web que foi adaptada para a tela do celular. Mas não precisa se preocupar se isso irá atrapalhar a experiência do usuário na hora de navegar pelo celular. Ele fica parecendo que foi desenvolvido nativamente, mal dá para notar a diferença.

O nativo é aquele que é desenvolvido nas linguagens nativas do Android e do iOS. Normalmente o orçamento para desenvolver este tipo é mais caro que o normal. Isto porque ele é feito em duas plataformas e leva o dobro do tempo, diferente do híbrido.

Mas tenho uma notícia boa, se você quiser lançar rápido a sua ideia, você pode, na maioria das vezes, alocar dois times para desenvolver paralelamente nas duas plataformas e assim otimizar o tempo. Mas saiba que desenvolver um app não é algo que pode ser feito da noite para o dia. Aqui na Jera, por exemplo, leva-se normalmente de 2 a 3 meses por plataforma.

nativoxhibrido

Se o seu aplicativo precisar utilizar funcionalidades nativas do celular, como câmera, GPS, etc, o mais indicado é desenvolver  nativamente. Pois assim, as ferramentas próprias do celular funcionarão melhor e tornarão a experiência do seu usuário mais satisfatória.

É só ter um app para o meu negócio que o sucesso está garantido?

Calma lá, não é bem assim! De fato, este tipo de serviço te ajuda a expandir sua empresa. Só que para isso acontecer, não basta apenas ter a mercadoria, deve também possuir um diferencial. É um erro pensar que só é preciso desenvolver um aplicativo e ele fará dinheiro sozinho. Não se esqueça que a tecnologia é feita para as pessoas. Investir em tecnologia, mas não proporcionar um atendimento qualificado para seus clientes e não aprimorar a forma como eles experimentam o seu produto, de nada adianta.

Junto com a tecnologia, também tem que vir a experiência que as pessoas terão com a sua empresa. E eu tenho certeza que você deseja que ela seja extraordinária!

*Icons created by Guilherme Simoes from the Noun Project

 

5 estratégias para a retenção de talentos da sua organização

Saber as estratégias certas para aumentar a retenção de talentos é um problema enfrentado por diversas empresas atualmente. A área de Gestão de Pessoas tem consolidado cada vez mais sua função estratégica junto às organizações. Contudo, para assumir esse papel encontra uma série de desafios. Um dos maiores é a criação e aplicação de práticas que garantam que a sua organização consiga garantir a retenção dos contratados.

Em geral, muitas instituições têm dificuldade em entender as necessidades de seus colaboradores. Por isso, a área responsável pela gestão de pessoas não consegue definir o ponto de partida para melhorar a felicidade da equipe. E assim, consequentemente, muitas pessoas de alto potencial acabam saindo.

Pensando nisso, existe uma série de práticas adaptáveis a realidade de qualquer entidade. Essas estratégias podem garantir o aumento da retenção de talentos. A seguir listamos cinco pontos que consideramos fundamentais para isso:

1. Dicas para Retenção de Talentos: Atraia pessoas alinhadas à cultura da organização

Em primeiro lugar, toda instituição deve ter clareza sobre sua missão, visão e seus valores. Pois a partir disso poderá entender o que constitui sua cultura e buscar pessoas que se conectem a ela.

Durante o processo de seleção, é importante que seja dada atenção ao alinhamento entre o perfil do candidato, a cultura organizacional e a oportunidade de trabalho em aberto. Uma boa forma de se fazer isso é utilizar o modelo de entrevista por competências.

Com isso, será reduzida a possibilidade da pessoa contratada não se adaptar ao cotidiano do local de trabalho e sair precocemente.

2. Dicas para Retenção de Talentos: Cálculo do Turnover

O Cálculo do Turnover é uma importante ferramenta para que a equipe de Gestão de Pessoas consiga visualizar de forma concreta o índice de rotatividade na organização. Também ajuda a pensar em estratégias para melhorar a retenção de talentos.

A forma de realizar este cálculo, bem como a periodicidade e a porcentagem de turnover esperada, deve ser definida de acordo com a realidade da entidade. Mas pode-se tomar por base a fórmula abaixo:

(# Desligados Passivos ou Ativos)
____________________________________________________
# Total de Funcionários

Se o cálculo do turnover de desligados passivos (pessoas demitidas) for alto, em geral, isso representa problemas no processo de recrutamento e seleção. Se o cálculo de desligados ativos (pessoas que pediram demissão) for alto, isso se relaciona mais às estratégias da empresa para reter talentos. Entretanto, ambos impactam diretamente na retenção de talentos.  

3. Dicas para Retenção de Talentos: Clima Organizacional

Podemos definir o clima organizacional como um conjunto de fatores internos que influenciam na percepção das pessoas sobre o ambiente de trabalho. Apesar de ser algo subjetivo, isto interfere de várias formas na motivação dos colaboradores. Por isso, a área de Gestão de Pessoas deve buscar constantemente analisá-lo.

A forma mais eficaz de identificar como anda o clima na sua instituição é por meio da Pesquisa de Clima Organizacional. Ela pode ser aplicada trimestralmente, semestralmente ou anualmente, dependendo da sua necessidade e realidade.

4. Dicas para Retenção de Talentos: Plano de carreira

Diversas entidades, encontram grande dificuldade em clarificar para seus funcionários os caminhos que eles podem seguir internamente. Isso acontece especialmente com as empresas de pequeno porte.

Sem essa clareza a tendência é que os bons profissionais busquem oportunidades externas que proporcionem seu crescimento. É importante que as organizações definam como podem contribuir para que as pessoas se desenvolvam profissionalmente após contratadas. Portanto, deve-se difundir entre os colaboradores um plano de carreira, para que entendam as oportunidades internas e o que precisam desenvolver para atingi-las.

5. Dicas para Retenção de Talentos: Valorização de Pessoas

Por fim, é fundamental que os gestores compreendam que as pessoas não podem ser tratadas como meros recursos. Elas dependem de diferentes estímulos para se sentirem realizadas, motivando-as a continuarem na instituição.

Desse modo, deve-se buscar vários meios para que as pessoas sejam valorizadas e reconhecidas por seus esforços. A ideia de que apenas o salário basta para motivar a equipe torna-se cada vez mais ultrapassada. E quando o gestor não compreende isso, sem dúvidas, terá péssimos resultados e um baixo índice de retenção de talentos.

Texto: Diego Ungari

Como entregamos um produto valioso utilizando as metodologias do Design Thinking — Capítulo 3

Nesta série dividida em três capítulos, nós, designers da Jera, relataremos nossa experiência com o projeto New App. Pelo qual utilizamos técnicas do Design Thinking e trabalhamos em conjunto com os desenvolvedores durante todo o processo de design.

No capítulo anterior relatamos como trabalhamos na resolução da falta de engajamento do cliente da Jera com a nossa ferramenta de gerenciamento. E o erro que cometemos que deixou nosso cliente insatisfeito.

Neste capítulo contaremos como trabalhamos para corrigir os nossos erros e qual foi resultado da segunda fase de testes. Relataremos também, nosso esforço para chegarmos a solução da falta de foco das equipes da Jera na Sprint 0 e Sprint Final.

Capítulo 1

Capítulo 2

Começamos tudo de novo

Após a “bronca” que levamos dos nossos clientes, vimos que a tentativa de solucionar vários problemas de uma só vez e em tão pouco tempo foi “um tiro no pé”. Assimilamos os erros cometidos e concluímos que era preciso reduzir funcionalidades, que menos era mais.

Com o foco centralizado no usuário, fizemos um Mapa de Empatia, entendendo melhor quem é o nosso cliente, o meio em que vive, suas expectativas, medos e o que ele realmente precisa. Assim, ficou mais simples entender o que realmente seria importante para ele. Decidimos então que funcionalidades deveríamos focar:

  • Acompanhar o andamento das Sprints do projeto;
  • Visualizar tarefas pendentes;
  • Acesso a documentos e protótipos;
  • Relatar problemas;

Com isso em mente, começamos os rabiscos de novo, pensando em facilitar qualquer atividade que o usuário precisaria fazer. O que antes era um tela cheia de informações que eram ignoradas, tornou-se uma tela com 4 botões simples, que levaria o usuário a um caminho mais claro antes dele concluir a tarefa desejada.

mockup_new_app
Tela principal do nosso segundo protótipo

 

Protótipo pronto, partimos para a segunda fase de testes.

Solução do problema de falta de foco

Antes de revelar como foram os testes. Contaremos como chegamos a solução da falta de foco das equipes da Jera na Sprint 0 e Sprint Final.

A Sprint 0 e Sprint Final é um período importante em que a equipe deve se concentrar. Porém poucos estavam realizando estas etapas efetivamente, por vários motivos, tais como: resolver problemas de outros projetos, distração com mídias sociais e auxílio a outros colegas quando estavam sem tempo (alguns tinham dificuldade em dizer “não”).

A solução encontrada foi identificar as equipes que estavam nestes períodos por meio de uma bandeirinha. Desta forma, quem estivesse com a bandeira teria um sinal que deveria focar no projeto em que está trabalhando e quem estivesse de fora não incomodaria o time com a identificação.

Além da sinalização da Sprint 0 e Final, sentimos a necessidade de incluir outra situação, quando a equipe está atropeladas de tarefas a serem realizadas no projeto e o tempo de entrega está quase no fim. Denominamos este caso de “Projeto Explodindo”.

O processo de produção das bandeiras foi o mais interessante, pois deixamos de criar soluções digitais para criar soluções físicas. Largamos o computador para fazer um trabalho artesanal que nos lembrou a época da escola. Recortamos papel, cortamos madeira, colamos papel e plástico, e nos divertimos muito com isso.

producao-das-bandeirinhas

Após terminar a produção, fizemos quatro bandeiras para sprint 0 e final com a cor amarela e três bandeiras para o caso de o projeto estar atrasado com a cor vermelha.

Hoje, as equipes estão utilizando as bandeiras e já tivemos bons feedbacks, muitos dizendo que as interrupções foram reduzidas e que a concentração para os projetos está sendo bem maior.

Segunda fase de testes

Ansiosos para saber como seria o resultado, colocamos o segundo protótipo para ser testado, desta vez, com pessoas que se encaixavam no perfil dos nossos clientes e com atividades mais focadas nas principais funções. Realizamos o mesmo procedimento do primeiro teste.

O resultado foi surpreendente, a diferença entre os dois testes foi “gritante”. Os usuários realizavam as tarefas rapidamente, um ou outro demoraram mais que um minuto. Um bom exemplo foi a função de visualizar as tarefas pendentes, em que a média caiu de 1min31s para apenas 17s.

Abaixo é possível visualizar a comparação da média de tempo na realização das tarefas entre o primeiro e o segundo teste:

media_testes_de_usuário
Média de tempo na realização das tarefas do primeiro e segundo protótipo

 

Mesmo com a melhora significativa, tivemos que corrigir alguns pequenos detalhes que trouxeram alguma dificuldade para os usuários.

Entrega da última sprint

Chegou a hora tão esperada. Ao mesmo tempo que estávamos confiantes pelos bons feedbacks, estávamos nervosos, porque sempre há alguma tensão quando nosso trabalho é avaliado.

Primeiro apresentamos as bandeirinhas, e tivemos uma boa resposta dos nossos clientes. Eles elogiaram a solução a que chegamos e a forma de como a executamos. Que dessa vez, deu pra ver que trabalhamos em equipe.

Depois apresentamos o aplicativo. Muita calma nessa hora. E…

O Jeff e o Ney gostaram também do resultado que apresentamos e ficaram surpreendidos com a diferença entre os dois testes. E deram sinal verde para que os desenvolvedores começassem o desenvolvimento do aplicativo. Este feedback nos deixou aliviados.

O que aprendemos

Ao utilizar metodologias do design thinking, ir a fundo no projeto, estudar e selecionar os reais problemas, propor soluções com uma base técnica bem definida, realizar testes e pesquisas com os usuários, ajudou-nos a fugir da subjetividade e tomar decisões com argumentos concretos, tendo a certeza de estar no caminho certo e entregar um produto valioso ao nosso cliente e ao usuário final dele.

A experiência de trabalhar em conjunto com os desenvolvedores trouxe-nos uma visão mais lógica na construção de um produto. Com a opinião técnica deles do que é possível ou não fazer, era fácil para nós, designers, desenharmos uma solução.

A redução de documentação também foi algo positivo, já que o desenvolvedor estava ao nosso lado e entendia o projeto todo, participando da criação, compreendendo tudo aquilo que foi feito e não simplesmente executando algo que caía em suas mãos.

O projeto New App foi um grande aprendizado para todos e levaremos este conhecimento para o restante das nossas carreiras.


É isso! Chegou ao fim nossa jornada.

Gostaríamos de receber seu feedback. O que achou do nosso processo? O que podemos melhorar? O que podemos acrescentar? O que podemos fazer de diferente?

Autores: Carol Cabral e Vinicius Rocha

como lançar um aplicativo de sucesso

Como entregamos um produto valioso utilizando as metodologias do Design Thinking — Capítulo 2

Nesta série dividida em três capítulos, nós, designers da Jera, relataremos nossa experiência com o projeto New App. Pelo qual utilizamos técnicas do Design Thinking e trabalhamos em conjunto com os desenvolvedores durante todo o processo de design.

No capítulo anterior contamos como surgiu a oportunidade de trabalhar no projeto New App e o árduo processo na escolha do nome da nossa ferramenta de gerenciamento de projetos, Active Collab.

Neste capítulo diremos como trabalhamos na resolução da falta de engajamento do cliente da Jera com a nossa ferramenta de gerenciamento. E o erro que cometemos que deixou nosso cliente desapontado.

Capítulo 1

Capítulo 3

Processo de Ideação — produção do app para nosso cliente

Decidido o nome e alguns problemas internos solucionados, era a hora de focarmos na falta de engajamento do cliente com a ferramenta de gerenciamento.

Desde o início do projeto, batemos na tecla que a solução poderia ser um ajuste comportamental e não necessariamente um app, mas a mão dos devs e designers coçavam para “codar” e “leiautar” e a vontade era desenvolver um aplicativo. Esta ansiedade acabou se tornando um erro, que iremos relatar mais a frente.

Resolvemos desenvolver o app, porque percebemos que ele seria um facilitador para os clientes, que em sua maioria estão ocupados e não conseguem parar, sentar em frente a um computador e acompanhar todo o processo de seu projeto. Com isso, nos concentramos em funções básicas e que gostaríamos que tivessem o engajamento do cliente:

  • Acompanhamento das discussions (conversas);
  • Pendências do próprio cliente;
  • Alternar projetos;
  • Acompanhar projetos;

Após a definição das funcionalidades, começamos a rabiscar, devs e designers desenhando e colocando suas ideias no papel. Colhemos, misturamos e discutimos as soluções, chegando a um resultado que todos julgaram a melhor alternativa.

Processo de Prototipação

Com a sensação de ter feito a escolha perfeita. Largamos o lápis e o papel e botamos a mão na massa.

Talvez por costume, dividimo-nos mais uma vez em designers e desenvolvedores, cada um sentado no seu cantinho, fazendo o que melhor sabe fazer, antes mesmo de validarmos as hipóteses apontadas. Enquanto os devs “codavam”, nós designers terminávamos de montar o protótipo (sem código) no InVision com todas as telas e simulações.

Tela principal do nosso primeiro protótipo
Tela principal do nosso primeiro protótipo

 

Primeira fase de testes

Protótipo pronto era a hora de validá-lo. Buscamos testar com pessoas próximas, pois infelizmente não foi possível entrar em contato com o nosso público alvo (clientes).

Para realizar os testes, chamamos alguns colegas e familiares para serem nossa “cobaias”. A metodologia que empregamos baseava-se em um roteiro no qual descrevíamos um cenário e tarefas que usuário deveria fazer para cada funcionalidade que queríamos por em prova.

Em uma sala privada, uma pessoa da equipe fazia o papel de facilitador, responsável por ler o roteiro e comunicar-se com o usuário e outro era o observador, responsável por analisar as ações e expressões do usuário. Para cada funcionalidade cronometrávamos o tempo.

testes com usuarios

Infelizmente o resultado não foi o esperado. A maioria dos usuários se perdiam e não conseguiam realizar a tarefa da forma que queríamos. Até mesmo para um usuário com grande afinidade com interfaces de aplicativos móveis, demorou cerca de cinco minutos para realizar uma funcionalidade. Não houve nenhuma atividade onde a média tenha sido menor que de 1min30s.

Entrega da sprint


Com o resultado nada bom, fomos apresentar tudo o que foi feito para o Jeff e o Ney que não gostaram do que foi entregue. E ainda levamos uma “bronca”, porque não focamos em soluções que estavam previstas, e por não trabalharmos efetivamente junto aos desenvolvedores, que começaram a “codar” antes de validarmos as hipóteses por meio do protótipo.

Depois de entregarmos um trabalho nada satisfatório, entendemos que deveríamos trabalhar juntos até chegarmos a uma solução ideal.


No último capítulo da nossa jornada, contaremos o que fizemos na terceira sprint para corrigir nossos erros. Como foi o resultado da segunda fase de testes e se os nossos clientes ficaram satisfeitos ou não com a solução que entregamos.

Autores: Carol Cabral e Vinicius Rocha

 

como lançar um aplicativo de sucesso

Como entregamos um produto valioso utilizando as metodologias do Design Thinking  –  Capítulo 1

Nesta série dividida em três capítulos, nós, designers da Jera, relataremos nossa experiência com o projeto New App. Pelo qual utilizamos técnicas do Design Thinking e trabalhamos em conjunto com os desenvolvedores durante todo o processo de design.

Neste primeiro capítulo contaremos como surgiu a oportunidade de trabalhar neste projeto e como foi o desenrolar da nossa primeira sprint.

Capítulo 2

Capítulo 3 

Como tudo começou

Durante os cinco anos de Jera, o processo de desenvolvimento tem evoluído constantemente. Com esta crescente sentiu-se a necessidade do processo de design também acompanhar esta evolução, para entregar ao cliente uma solução de grande valor e não entregar mais só pastel de carne ou de queijo.

De olho neste aprimoramento, em setembro de 2015, nosso diretor de tecnologia (CTO) e designer, Ney Ricardo, ministrou um workshop de Design Thinking e Lean UX para todos os designers da Jera, no qual ele nos passou técnicas para centrarmos a construção de um produto no usuário.

O workshop foi ótimo, aprendemos muito, porém até o final de 2015, não tivemos oportunidade de aplicar o que nos foi ensinado. Até que apareceu a chance…

Nosso diretor de operações (COO), Jefferson Moreira (mais conhecido como Jeff), queria resolver alguns “abacaxis” que incomodavam bastante na Jera. Então, ele aproveitou que nossa equipe estava sem projeto e nos passou a grande missão: resolver estes problemas utilizando a metodologia do design thinking e, ainda, trabalhar em conjunto com os desenvolvedores durante todo o processo de design.

Iniciou-se então o projeto New App 1.0. A equipe responsável por ele foi formada por nós, designers Carol Cabral, Kevin Tosli e Vinicius Rocha e pelos desenvolvedores Vitor Mesquita e Victor Robertson. Nossos clientes foram o Jeff e o Ney e teríamos três sprints (semanas) para realizar o projeto.

Início do projeto  – levantamento de problemas

Começamos nossa jornada levantando os problemas da Jera. Em um processo de imersão, com todos da equipe do projeto, time de QA (garantia de qualidade) e o Jeff, listamos todos os problemas que incomodavam a equipe Jera, desde os pequenos até os grandes, sem julgamentos.

Após o levantamento, utilizamos um diagrama (imagem 1) para classificar os problemas em: essenciais, desejáveis e dispensáveis. Depois usamos a Matriz de Retorno (imagem 2) para avaliar o nível de retorno que a solução deles iria nos trazer.

Imagem 1
Imagem 1
Imagem 2
Imagem 2
No final decidimos solucionar os seguintes problemas, os quais, julgamos serem os mais críticos:

 

  1. Visão mal documentada;
  2. Funcionalidades feitas para uma plataforma e não na outra;
  3. Projetos sem Kickoff e Visão;
  4. Cliente não sabe onde estão os entregáveis (documentos e protótipos);
  5. Nome da ferramenta Active Collab;
  6. Cliente não participa durante o processo de desenvolvimento;
  7. Descrição e checklist de pequenos processos;
  8. Equipe Jera esquecendo algumas etapas do processo de atendimento ao cliente ou desenvolvimento;
  9. Facilitação com novos recursos na ferramenta;
  10. Falta de foco da equipe na Sprint 0 e Sprint Final.

Para os artigos não ficarem muito extensos, contaremos nossa empreitada para solucionar os três problemas que trouxeram uma ótima experiência para nós: nome da ferramenta (tratado neste primeiro capítulo), falta de engajamento do cliente e falta de foco da equipe na Sprint 0 e Sprint Final (estes dois últimos falaremos no segundo e terceiro capítulo desta série).

Escolha do nome da ferramenta

Desde que começamos a utilizar a nova versão do Active Collab  – ferramenta que utilizamos para gerenciar os projetos dos clientes e produção  – tínhamos um problema com o nome dela. O nome anterior era “Projeto”, ele causava confusão, pois quando mencionava-se o nome, não sabia-se se a pessoa estava se referindo ao projeto do cliente ou à própria ferramenta. Outra problemática era que quase todos a chamavam por “Active Collab”.

A escolha de um nome era algo que parecia ser simples e rápido no início, mas nos ocupou três dias de trabalho e algumas “dores de cabeça”.

Reunimos nossa equipe e sentamos junto ao Jeff, e fizemos um brainstorming para levantar opções de nomes. Após surgirem umas 20 ideias, selecionamos quatro alternativas: Asgard, Pipe, Oráculo e Colab. Decidimos então, lançar uma pesquisa de opinião a todos da Jera, na qual perguntamos se gostavam ou não dos nomes selecionados e o motivo.

Infelizmente tivemos uma péssima resposta, muitos reclamaram que não puderam opinar, outros simplesmente não gostaram, mas no geral obtivemos feedbacks valiosos. O importante é que entendemos que não iríamos agradar a todos, então levantamos pontos importantes para a escolha do nome:

  • Novo: não pode ser um nome que já foi utilizado pela Jera, como: “Hunter”, “Projeto” ou “Atendimento”;
  • Simples de pronunciar, escrever e lembrar;
  • Objetivo e que reflita funcionalidades da ferramenta;
  • Aderência por parte da equipe, não confundindo com outros termos já utilizados;
  • Ideia de colaboração: principal valor que a Jera quer ao implementar o uso da ferramenta;

Após o levantamento dos pontos, reunimo-nos mais uma vez para propor outras sugestões. Levamos todas as propostas para uma nova pesquisa, desta vez, a fizemos com alguns colegas e pessoalmente. Mostramos os nomes e perguntamos o que sentiam e entendiam por cada um. Pudemos avaliar as reações e sensações deles ao dizer cada nome.

Consideramos os argumentos e expressões de cada um fundamentais para tomarmos nossa decisão. E todos tiveram uma boa reação ao ouvir o nome Painel. 

Após muitas discussões, batemos o martelo. Decidimos pelo nome Painel que preenchia os requisitos que elencamos e que teve maior aceitação pelos entrevistados.

Apresentação do nome

Com o nome escolhido, era a hora de anunciar. Um momento de grande apreensão, porque o pessoal da Jera é bem crítico e se não gostassem do nome, com certeza não o utilizariam, tornando nosso duro trabalho um fracasso.

No entanto, para nossa alegria, a aceitação da equipe foi boa, e em pouco tempo já estavam utilizando o novo nome ao invés de “Active Collab”, cumprindo nosso objetivo.


No próximo capítulo contaremos como foi o desenrolar da segunda sprint, na qual trabalhamos na resolução da falta de engajamento do cliente da Jera com a nossa ferramenta de gerenciamento. E o erro que cometemos que deixou nosso cliente desapontado.

Autores: Carol Cabral e Vinicius Rocha

como lançar um aplicativo de sucesso