Velocidade, Prioridade e Qualidade: Os Desafios de Desenvolvimento
Vemos repetidamente as histórias das grandes empresas de tecnologia do mundo. Todas elas se parecem. Existe uma garagem, existe um desenvolvedor fora do normal, existe um produto tão mágico que ninguém pode resistir e, como consequência, um sucesso do dia para noite.
Infelizmente, nem todo mundo vive essa realidade, se é que alguém realmente viveu o que vemos escrito. Muitas empresas vão formando sua equipe dos sonhos ao longo do caminho. E empreendedores vão assumindo papéis para os quais nunca foram preparados formalmente ou sequer almejavam no início de sua jornada.
Comigo e a Clara foi assim. Não começamos como uma empresa de tecnologia e nenhum dos fundadores é desenvolvedor de nascença. Hoje, como várias outras empresas que conheço, temos uma mistureba de responsabilidades divididas entre duas pessoas. Essas funções são, de maneira geral, divididas entre eu e o Thiago, nosso "líder técnico" também auto-intitulado de "revisor de código júnior".
Ele decide como iremos implementar os novos recursos (features), como iremos desenvolver nossa infraestrutura (servidores, linguagem, etc) e também desenha nossos processos de desenvolvimento. Eu acompanho a equipe, fico a frente da contratação e também sou responsável pela priorização dos ciclos de desenvolvimento.
Não sou desenvolvedor, mas, desde 2010, estive em contato com o meio, pois a gente vendia e também desenvolvia para nós mesmos sites feitos no Wordpress. Há 2 anos comecei a liderar nossos projetos de tecnologia e por conta do crescimento dessa área na empresa, fui estudando sobre desenvolvimento ágil, git, Ruby e tudo mais que poderíamos precisar. Por isso, hoje me considero um “conhecedor” de tecnologia.
A minha jornada, e de toda empresa, foi de absorver essa nova realidade para desenvolver algo mais acessível e escalável para os empreendedores. Nesse post vou falar das 3 maiores preocupações que rondam minha cabeça desde que "encarnei" essa função de coordenar nossas iniciativas tecnológicas:
a) Velocidade: Como desenvolver em um bom ritmo
b) Prioridade: Como garantir que o que está sendo feito é relevante
c) Qualidade: Como verificar se aquilo ficou bom
Velocidade
Muito pode ser dito sobre velocidade, passando por contratar bons profissionais até motivação. No entanto, aqui estou assumindo a premissa de que a equipe é boa e está bem. Ou seja, estou focando no processo, na maneira de fazer as coisas mais do que nas pessoas.
1) Necessidades mal definidas
Um grande vilão do desenvolvimento é definir mal o que tem que ser feito exatamente. No nosso caso, isso fica muito mais crítico na entrada de um novo membro.
Quando a equipe já está junta a muito tempo, cria-se uma linguagem particular e todo mundo entende as coisas como “ajeitar minha conta” ou “bug do nome”.
No entanto, quando um novo membro está conhecendo o projeto isso pode ser bem problemático. Na melhor das hipóteses ele vai ter que ficar perguntando milhões de coisas, na pior ele vai desenvolver algo errado.
Para isso, sempre que a comunicação está gerando problemas, nós voltamos a ser mais criteriosos com a descrição das histórias usando o formato de job stories:
Por exemplo, atividade mal descrita:
"Mudar home da minha conta." Isso levanta várias perguntas: qual é a home da minha conta? O que vai ser mudado? Existe só uma maneira de se chegar na minha conta? O que acontece depois?
Como isso é re-escrito usando o método acima:
"Quando eu logo novamente na minha conta, eu quero ver meu histórico de cursos, para continuar de onde eu parei." Nesse caso, praticamente não tem margem para erro, sabem quem, por que e como tudo deve ser feito.
Tem funciona para a gente e se você quiser se aprofundar nesse assunto, existem posts bem interessantes (em inglês) falando sobre o tema:
2) Features gigantescas
Eventualmente nos deparamos com features que são grandes e que precisam ser entregue de uma só vez. O problema disso é que abrimos mão dos princípios do desenvolvimento ágil e começamos a operar dentro da lógica da cascata. A grande fundamental entre as duas abordagens é:
a) Ágil: Você tem muitos riscos e pouco conhecimento. Assim, você deve fazer de tudo para aprender o mais rápido possível. Por isso ele privilegia iterações rápidas, multidisciplinares e validações concretas.
b) Cascata: Você sabe o que tem que ser feito e agora é só questão de fazer. Assim, você deve ter grandes profissionais que fazem tudo perfeitamente. Esse processo privilegia o controle e a previsibilidade do resultado final.
Ambas abordagens existem e são perfeitas dentro de seus respectivos contextos. Você não quer usar um processo de cascata para inovar e descobrir novos mercados, assim como você não quer desenvolver um prédio com métodos ágeis e acabar construindo algo diferente do prometido.
Ou seja, quando essas situações de features gigantescas ocorres, nosso risco aumenta, a moral da equipe diminui e, caso nada seja feito, provavelmente elas acabam nunca sendo feitas. A minha maneira de reagir a essas situações pode ser vista em 3 abordagens:
a) Refletir duramente se existe alguma possibilidade de quebrar em histórias menores.
b) Buscar um passo intermediário da feature, algo diferente que tenha o mesmo intuito. Por exemplo, ao invés de criar um sistema de cupom completo, pode-se criar uma maneira do admin manualmente mudar o perfil de um cliente.
c) Acompanhar mais de perto a equipe que está desenvolvendo com papos semanais sobre andamento
Prioridade
A primeira lição que eu aprendi e gostei comecei a trabalhar com desenvolvimento ágil é a busca incessante para que as tarefas mais relevantes serão feitas antes. Isso é maravilhoso em vários sentidos e eu extrapolo essa lição para a gestão do negócio como um todo.
Se não é importante para ser a prioridade número 1, então não deve ser feito. Se os recursos são sempre escassos, isso é infalível. Até existe um livro inteiro em cima dessa máxima de focar em apenas uma coisa.
O único desafio é que isso, levado ao extremo, vai jogando muita sujeira pequena para baixo do tapete. Com o acumulo, muita coisa pequena acaba tornando-se algo grande e incômodo. É aquela mudança de texto, aquele novo botão, etc…que nunca é feito.
Por muito tempo sofri a cada “limpeza” que precisava fazer, até ler um post sobre o funcionamento da equipe do Basecamp (integra em inglês) no qual eles relatam que se organizam de duas maneiras gerais:
a) A cada 6 semanas eles formam um ciclo de desenvolvimento com grandes histórias.
b) Nesses ciclos, eles fazem 1/2 grandes histórias, mas também incluem pequenos ajustes que foram acumulando
Por isso, hoje me organizo da mesma maneira. A cada ciclo, faço uma limpeza periódica, sem deixar de ter as grandes prioridades avançando de acordo.
O ciclo é definido através de um exercício baseado no livro digital de gerenciamento de produtos da Intercom. Basicamente, nós mantemos constantemente uma lista de grandes recursos da Clara e debatemos em cima de duas óticas para definir a prioridade.
- Facilidade vs Retorno: Quais são os recursos mais fáceis de desenvolver com maior potencial de retorno?
2. Qualidade vs Quantidade: Quais são os recursos que são uma melhoria significativa da experiência atual e afetam mais usuários?
Nesse caso, tivemos o sistema de eventos como a grande prioridade do ciclo e o "Dynamic Gremlins" (sim, damos nomes meio malucos para alguns recursos) em segundo lugar, por ser mais difícil de implementar. Com isso, atualizamos o planejamento geral (Roadmap) conforme a imagem abaixo:
Qualidade
Quando você está desenvolvendo algo para ser usado no longo prazo, a capacidade daquele código evoluir e ser estável é essencial. Embora exista uma tentação de fazer as coisas de qualquer jeito (se pensou, não é XGH) e isso gere um — falsa — sensação de velocidade, nós sabemos que isso tem um preço.
Nós usamos algumas práticas para não correr para entregar algo que precisará ser completamente refeito no futuro, também conhecido como débito técnico. Ele funciona exatamente como um empréstimo financeiro, é como se você pegasse R$20.000,00 agora e ficasse "rico", mas contraindo uma dívida de R$40.000,00. Em alguns casos, empresas vão literalmente a falência por não terem mais como pagar essa dívida com seus produtos.
Aqui, lidamos com isso das seguintes maneiras:
1) Revisão de código: Antes de colocar qualquer código para produção, um desenvolvedor revisa o código do outro para buscar melhorias. Nesse momento especifico já vivemos muitas situações diferentes principalmente de acordo com o tamanho da equipe.
Quando tínhamos 1 desenvolvedor: ele mesmo corrigia seu próprio código com algumas horas de diferença para ter a “cabeça fresca” novamente. Não considero essa situação sustentável.
Quando tínhamos 2 desenvolvedores: um revisava o código do outro. Essa é a unidade mínima de trabalho para as coisas fazerem sentido.
Quando tínhamos 3 desenvolvedores: no começo, o desenvolvedor mais antigo revisava tudo. Depois de um tempo, começamos a aceitar que 2 revisões de quaisquer desenvolvedores era suficiente e isso nos deu mais velocidade sem perder qualidade.
Com 4 desenvolvedores (nosso máximo): Iniciamos com a mesma regra do ponto anterior. Depois separamos a equipe em 2 duplas e a revisão deve ser feita por algum membro do outro time. Assumindo que a sua própria dupla te ajudou a implementar aquele recursos, já houve uma mini-revisão.
2) QA: Sigla que significa em inglês Quality Assurance e que pode ser traduzida como Controle de Qualidade. Esse é um processo no qual um ser humano testa uma nova feature para verificar se ela está com o comportamento desejado. Normalmente eu mesmo faço esses testes com a exceção de features muito específicas de alguma área, nesse caso quem requisitou faz o teste.
De maneira geral, é um processo bem normal. Se todas as etapas anteriores do desenvolvimento deram certo, você não terá problema. O negócio começa a ficar complicado quando a aplicação está disponível em muitos lugares diferentes.
Começamos com a Clara apenas para desktop, dai era só verificar os principais navegadores. Depois, fizemos a versão responsiva do site, adicionando a necessidade de testar para os sistemas iOS e Android. Em breve, estaremos com a Clara no Facebook Messenger, WhatsApp, etc. Talvez a gente vá desenvolver aplicativos nativos...enfim a complexidade só aumenta e garantir que está tudo funcionando torna-se mais complexo. Para me ajudar, tenho usado o Browser Stack que simula diversos ambientes no navegador.
3) Ambiente de Teste: Sei que é padrão em praticamente todas as empresas, mas sendo uma empresa que não nasceu como tecnologia, também sei que às vezes não se segue nem o básico. Hoje, fazemos todo o QA em um ambiente de testes antes de colocar em produção. :P
4) Integrações/Automações: Por fim, utilizamos alguns recursos comuns para garantir que o código novo nunca quebre o código em produção e que as informações sejam distribuídas para todos da equipe. Fora os logs de funcionamento do servidor (New Relic) e da aplicação (Papertrail), também utilizamos um sistema de acompanhamento de bugs (Bugsnag) e outro de continuous integration (Circle CI). Isso tudo é integrado com nosso Slack que parece mais uma árvore de natal quando a equipe tá programando!
Não tem muito a ver, mas também usamos o nosso canal do slack para dar deploy direto nos nossos ambientes de staging e produção sem precisar entrar na AWS ou outra hospedagem.
Quais Desafios Ainda Não Enfrentamos/Resolvemos
Todos os pontos que eu citei acima não possuem respostas absolutas, sempre tivemos que nos adaptar às novas realidades e mudar o processo para continuar tendo bons resultados. No entanto, tenho certeza que novos desafios dentro de todos esses pontos irão surgir conforme a equipe e a complexidade do código cresçam.
Outro ponto que me interessa desenvolver mais no futuro é implementar um sistema de testes mais robustos. Isso significa facilitar a maneira como rodamos testes A/B e também o rolamento de features para partes da base para validarmos antes de distribuir na aplicação como um todo.
De todo modo, o que aprendi é que o mais importante é manter uma comunicação constante com a equipe toda e buscar referências de ideias para testar no processo e ter a liberdade de testá-las para que todos possam aprender e participar.
