Uma dos estudos de caso da SLLConf que eu esperava bastante era o do Ash Maurya, da WiredReach. Ash escreve ótimos posts em seu blog,  especialmente sobre práticas e aprendizados específicos da aplicação dos conceitos de Customer Development e Lean Startup no mais novo produto da sua empresa, chamado CloudFire.

Quando assisti ao vivo, achei que a apresentação ficou muito cheia, e consequentemente, corrida demais. Já quando vi pela segunda vez com mais calma, pude perceber uma série de ótimos insights escondidos nas entrelinhas dos slides. Faço a seguir o resumo e deixo no final o vídeo e os slides da apresentação.

Como maximizar o progresso em uma Lean Startup?

Ash começou a palestra relembrando a definição do Eric Ries sobre progresso em uma Startup: Aprendizado Validado sobre Clientes. Ou seja, para maximizar o progresso, temos que buscar maximizar o aprendizado ao longo do processo de desenvolvimento.

O problema é que muitas vezes o desenvolvimento do produto acaba “atrapalhando” o aprendizado. A figura abaixo mostra como isso acontece quando usamos processos tradicionais de desenvolvimento.

Onde ocorre o Aprendizado no processo tradicional de desenvolvimento

A ideia central do Continuous Deployment é minimizar o tempo gasto na parte intermediária deste ciclo, e consequentemente, aumentar a quantidade de aprendizado ao longo do processo.

Continuous Deployment diminuindo o tempo no ciclo de desenvolvimento

O Antes e Depois da Aplicação de Continuous Deployment na WiredReach

Antes: Ciclos de desenvolvimento de duas semanas
Depois: Múltiplos releases todo dia

Antes: Área comum (centralizada) de testes pré-produção
Depois: Sandboxes individuais, possibilitando escalar a infraestrutura de desenvolvimento horizontalmente

Antes: Releases eram “eventos de um dia inteiro”
Depois: Releases não são “eventos”.
(Obs. Quando os releases vão para o ar, eles monitoram as métricas por algum tempo e revertem caso alguma coisa ruim aconteça. Há medidas automáticas e manuais para essa reversão.)

Antes: Tamanho médio de um Release – centenas de linhas de código
Depois: Tamanho médio de um Release – menos de 25 linhas de código

Antes: Mais Releases de emergência
Depois: Menos “apagar incêndio”

Antes: “Dias de Programação” vs. “Dias de Clientes” (atividades de Customer Development)
Depois: “Dias de Programação” E “Dias de Clientes” juntos
(Obs. Ash mencionou o artigo do Paul Graham: Maker´s Schedule, Manager´s Schedule.  Ele concentra suas atividades de programação nas horas iniciais da manhã, enquanto deixa as atividades de clientes e marketing para mais tarde. Para mais sobre esse assunto, recomendo a leitura desse post dele.)


Dicas para começar a implementar Continous Deployment

- A coisa mais importante: Dividir a programação em lotes muito pequenos (no caso dele, esse tamanho é definido como o resultado de 2 horas de programação);

- Fazer antes as modificações que não envolvam a interface com o usuário (banco de dados, APIs, etc.), diminuindo o risco geral de integração;

- Não tentar alcançar 100% de automação desde o início. Fazer o deploy manualmente primeiro, e depois ver o que vale a pena automatizar. Isso também ajuda a estabelecer confiança aos poucos na parte automática do processo;

- Monitorar o tempo do ciclo de Release;

- Esteja pronto para “parar a linha de produção” em caso de falha nos testes. Não subestime o fato de que os testes estão falhando, já que em pouco tempo eles serão a única linha de defesa do sistema;

- Construir, devagar e incrementalmente, um Cluster Immune System. (sobre isso, recomendo a leitura desse artigo do Eric Ries no Venture Hacks sobre Five Why´s e Immune System)

Como construir as Funcionalidades

Ash lembrou que Continuous Deployment ajuda na tarefa de diminuir o tempo em que uma funcionalidade é construída, mas não diz nada sobre quais são as funcionalidades certas para entrar em desenvolvimento. (o que lembra a proposição do Kent Beck para inverter a ordem do Loop da Startup para Learn->Measure->Build).

Para isso, na WiredReach eles criaram duas regras simples:

Regra #1: Não “empurrar funcionalidades”
Para isso, 20% do esforço é aplicado na construção de novas funcionalidades, enquanto 80% do esforço vai para as melhorias das funcionalidades atuais. A demanda pelas novas funcionalidades deve ser validada por atividades de Customer Discovery.

Regra #2: Restringir o número de funcionalidades que entra na fila
- Novas funcionalidades não podem ser desenvolvidas sem que as funcionalidades anteriores possam ser validadas.
- Para entrar no Backlog, a funcionalidade deve ser pedida por mais de um cliente. Isso aumenta a resistência para entrar uma nova feature no software (ajudando a regra #1) e evita que se faça customizações para clientes específicos, atividade que não escala e ainda tem o risco do efeito “colcha de retalhos”.

Como validar uma Funcionalidade?

Fila de desenvolvimento de funcionalidades

Depois de desenvolvida, é importante validar a funcionalidade, ou seja, saber responder se ela atendeu de fato o problema que o cliente tinha. Especialmente quando não se tem uma massa de usuários muito grande, a validação Qualitativa (conversa com o cliente) é mais importante do que a Quantitativa (métricas).

Para Validação Qualitativa, Ash sugere que se contate os clientes que pediram a funcionalidade e disponibilize-a só para eles, coletando feedback depois do uso. As duas perguntas que ele procura responder são: Essa feature funciona de forma a resolver o problema que o cliente tinha? E em um nível mais macro, ela afeta a capacidade de fazer ou manter uma venda para ele?

Se não conseguir extrair um sinal positivo para essas perguntas, é importante tentar entender o porquê: se a funcionalidade foi mal implementada ou se o problema foi mal interpretado. No caso desse último, a sugestão do Ash é matar a funcionalidade imediatamente.

Para Validação Quantitativa, ele sugere a combinação do uso de ferramentas como Mixpanel, KISSMetrics e Google Analytics, mas focando mais no macro-efeito da implementação da funcionalidade (resultado nas métricas de negócio) do que nos dados de taxa de Click-Through ou uso da mesma.

Para fechar a apresentação, Ash lembrou que os benefícios do uso de Continuous Deployment são incrementais, e que o quanto antes iniciar a sua prática no desenvolvimento do produto, melhor.

Deixo agora o vídeo e os slides da apresentação:

Continuous Deployment: Startup Lessons Learned