A História do Jibble
Construir um software que se destaque, seja robusto e cause impacto é difícil. Muitas equipes conseguem fazer uma dessas coisas, algumas conseguem duas, mas raramente vemos uma equipe se unir e fazer todas as três.
Isso é o que eu testemunhei no Jibble.
Uma rápida pesquisa no Google valida meu ponto – o software da empresa tem uma avaliação impressionante de 4,9 no GetApp e Capterra e 4,8 na Apple App Store. Tenho certeza de que há muitas coisas que a empresa pode melhorar, mas a equipe está fazendo algo certo se essas são nossas avaliações. Eu queria entender exatamente o que eles estavam fazendo, então decidi tentar compreender como e por que a empresa estava alcançando esses resultados impressionantes.
Eu percebo que softwares de folha de ponto e controle tempo não são tão atraentes; definitivamente não é o mesmo que trabalhar para uma empresa de jogos como a Activision, que está desenvolvendo o novo jogo do Homem-Aranha.
Porém, o Jibble se orgulha de ser “O Novo Padrão em Controle de Tempo”, uma afirmação ousada, mas que descobri ser fundamentada em fatos. Isso é resultado de esforços exaustivos para tornar interessante algo que é mundano, mas significativo.
Veja bem, indústrias tradicionais são o que a maioria das startups irá transformar, dado que a maioria das inovações imediatas e evidentes já foi alcançada. É por isso que acredito que o Jibble se encontra em uma posição única para capturar um mercado há muito tempo negligenciado tanto por jovens fundadores quanto por investidores experientes.
À primeira vista, o Jibble pode parecer um conceito comum na linha de “OK, você encontrou um problema, vamos fazer algum código, criar uma interface de usuário, anexar uma forma de pagamento e lançar no mundo”. Isso, pelo menos, foi o que eu achei no começo, antes de eu entrar na equipe, mas, como logo aprendi, empresas de SaaS que desenvolvem produtos complexos como softwares de folha de ponto funcionam de forma diferente.
Há MUITOS processos que precisam ser seguidos, e, embora o Jibble não seja o Google, certamente tem uma equipe de indivíduos impressionantes que lideram o desenvolvimento. Esses heróis muitas vezes passam despercebidos.
Você pode ter ouvido que Engenheiros de Software não são grandes comunicadores – geralmente são introvertidos, mestres de seus próprios domínios, e raramente querem ser perturbados por interações humanas. Esse estereótipo é verdadeiro até certo ponto.
A maioria dos engenheiros, para serem bons no que fazem, precisa passar incontáveis horas em frente às suas telas pouco iluminadas, constantemente afiando seus teclados, e nossa equipe não é diferente.
Como já estive em ambos os lados da operação da empresa, tanto no papel de relacionamento com o cliente quanto no de desenvolvedor de produto, me encontro em uma posição única para comentar sobre o porquê das coisas aqui simplesmente… funcionarem e por que vale a pena ficar de olho nessa startup.
Nosso Processo de Desenvolvimento
Nossa equipe passa incontáveis horas refinando cada etapa de seu processo de desenvolvimento, que é o seguinte:
1. Ideação: Encontrando um Ponto de Dor
Nossa equipe gasta uma quantia impressionante de tempo antes de escrever a primeira linha de código, tudo para garantir que não gastemos o dobro desse tempo depois que começarmos a construir. Como disse Abraham Lincoln:
“Se eu tivesse seis horas para cortar uma árvore, gastaria as primeiras quatro afiando o machado.”
2. Pesquisa Externa
Depois de identificar um ponto de dor dentro do domínio de nosso software de controle de tempo, a equipe rapidamente compara o feedback de clientes existentes, as tendências de mercado atuais e projetadas, e as tecnologias relevantes para encontrar pontos em comum que auxiliarão na preparação dos dados necessários para tomar uma decisão informada.
3. Pesquisa Interna: Discussões com a Equipe
Após coletar dados, os acionistas relevantes são envolvidos, incluindo Product Owners, Product Managers, CTOs, Designers Principais e Líderes de Equipe de todas as seções. Depois que a equipe debate internamente os prós e contras, os recursos versus o tempo, e o retorno esperado da decisão que estamos prestes a tomar, todos são convidados a expor suas preocupações e expressar a direção que acham que devemos seguir e por quê.
4. Tomada de Decisão: Fazer Agora ou Depois – Como Vai Afetar o Negócio?
Depois que a poeira baixa e uma conclusão é alcançada, a equipe escolhe a decisão que se alinha com a visão da empresa e suas metas imediatas ou esperadas. Se a decisão não atender a esses critérios, ela não é aprovada.
Decisões muitas vezes (mas não sempre) estão relacionadas a melhorias em recursos existentes ou ao desenvolvimento de novos. Após qualquer uma dessas opções receber o sinal verde, a questão é onde colocá-la no cronograma: fazemos agora, no próximo mês, no próximo trimestre, ou deixamos para um futuro distante?
Aqui, analisamos o impacto que nossa decisão terá sobre os clientes atuais, futuros prospectos e a capacidade atual, e então decidimos.
5. Pesquisa de Design
Após o cronograma do recurso ser decidido, precisamos pensar em ideias sobre como vai ser visualmente. Isso é algo que muitos novos empreendedores e product owners de software erram. Eles se focam demais em como deve funcionar, quando também precisam garantir que todos os recursos se encaixem no quebra-cabeça visual.
6. Especificação
O próximo passo é a maldição dos desenvolvedores de software: documentação. Especificação é onde escrevemos o escopo do projeto que estamos desenvolvendo. É onde a ideia é escrita e desenvolvida em um documento para ser a fonte da verdade para o desenvolvimento, os testes e as verificações de bugs.
Ela especifica o que o recurso será, explica como será visualmente e descreve o objetivo final (por enquanto, não olhamos muito para as métricas). Também há documentação técnica, que é escrita pelos nossos desenvolvedores. É assim que atualmente lidamos com a escrita de especificações:
- Rascunho inicial pelo PM
- Os líderes de equipe revisam as especificações iniciais e deixam comentários sobre viabilidade técnica ou sugestões alternativas
- Edições feitas pelo PM
- Outra discussão (os passos 2-3 podem ser repetidos algumas vezes, dependendo da complexidade do projeto)
A equipe garante que todos os casos de borda sejam também considerados nesse momento, mas, se o design estiver finalizado, interrompemos as discussões sobre as especificações. Até então, é possível iterar.
7. Design do Produto
Nossos brilhantes designers criam vários mockups com uma variedade de opções de exibição. Tudo é gerado tendo em mente a paleta de cores do Jibble.
Cada exibição imaginável — mobile, web, tablet — e uma grande variedade de tamanhos de tela, tudo é levando em conta nessa etapa.
8. Implementação Back-end e Testes de Unidade
A maioria dos recursos começa pelo Back-end. Nosso Back-end precisa suportar o recurso antes de adicionarmos a interface de usuário e a lógica no lado do cliente e adicionarmos à nossa API. Então, sessões de grooming são feitas com a equipe de Back-end para refinar os tickets e tarefas com base nas especificações, e a atribuição de tickets é feita durante o planejamento de sprint do Back-end.
A equipe de Back-end também é responsável por desenvolver testes de unidade para o código que escrevem, garantindo que todos os recursos funcionem como esperado. Neste ponto, a arquitetura do recurso é criada. Um bom modelo de recurso facilita o processo de desenvolvimento para os clientes.
9. Implementação do Cliente e Testes de Unidade
Agora que o Back-end foi implementado, as equipes de desenvolvimento mobile e web começam suas respectivas implementações de Front-end. O processo é quase o mesmo do Back-end, porém, o refinamento dos tickets é feito principalmente fora das chamadas de planejamento.
As equipes de Front-end referem-se principalmente às especificações, designs e estrutura do modelo de Back-end do recurso para implementar seu código. No mobile, temos duas equipes diferentes para a interface de usuário, seguindo um conjunto de lógica compartilhada; isso ajuda a otimizar a entrega e reduzir redundâncias. Os testes iniciais são realizados pela equipe de desenvolvimento e, em seguida, passados para o controle de qualidade para verificações manuais.
10. Testes de Aceitação do QA
Conforme os recursos são desenvolvidos, eles são implantados em nossos ambientes de teste, onde a equipe de QA realiza rigorosos testes de aceitação. É uma forma chique de dizer que testamos os recursos que desenvolvemos para o software de controle de tempo para garantir que funcionem conforme o esperado. Se encontrarmos problemas, é hora de voltar à oficina para revisões e melhorias.
11. Testes de Regressão do QA
Se todos os recursos funcionarem como deveriam, eles são enviados para produção, onde são novamente testados, desta vez para garantir que as correções recentes não quebrem coisas que funcionavam antes.
O Teste de Regressão é definido como um tipo de teste de software para confirmar que uma alteração recente no programa ou código não afetou negativamente recursos existentes. Aqui, no Jibble, realizamos dois tipos de Teste de Regressão: Um é um Teste de Regressão informal ou menor, que é feito no escopo dos tickets de Teste de Aceitação que têm problemas e precisam ser corrigidos. O outro é o Teste de Regressão em iteração de ciclo completo, realizado no final do Sprint, com mais cobertura focada no caminho crítico dos recursos selecionados.
No momento, estamos executando esses testes manualmente, antes que os scripts de automação estejam totalmente prontos.
12. Testes Exploratórios
Como a equipe é ágil no desenvolvimento de seu software de controle de ponto, tudo o que foi mencionado é feito em ciclos de duas semanas. Fora desses ciclos, ou durante períodos em que a carga de trabalho é relativamente baixa, a equipe realiza testes exploratórios — o que significa ficar de olho em tudo e sinalizar qualquer melhoria que precise de correção imediata.
Também realizamos testes exploratórios enquanto testamos os tickets de Teste de Aceitação, cobrindo o escopo ampliado do próprio ticket.
13. Lançamento
Finalmente, depois de dedicarmos todo esse esforço, nossa criação é liberada para o mundo. Você não esperava que demorasse tanto para fazer um software de folha de ponto, não é?
Conclusão
Para criar um produto excelente, você precisa ter uma visão excelente e não se desviar dela quando os ventos mudam. A equipe de controle de tempo do Jibble entende a sabedoria de não ceder rapidamente às tendências; eles são focados, mas estão constantemente procurando melhorar. Ao mesmo tempo, estão executando estratégias com o objetivo de se manterem comprometidos com a visão do que deve ser “O Novo Padrão em Controle de Tempo”. ISSO – eu acho – desempenha um grande papel em seu recente sucesso.
A conclusão final para as equipes que desejam replicar o sucesso do Jibble na construção de um software de controle de tempo confiável é esta: Crie rapidamente, construa equipes fortes e enxutas que se dedicam a realizar pesquisas baseadas em dados antes de tomar decisões e empreguem engenheiros brilhantes que usem as melhores práticas e colaboração global para construir, testar, melhorar e entregar funcionalidades pontualmente. Depois, sente-se e observe a mágica acontecer.
