Por que antes do como

Neste último fim de semana eu estive na QCon São Paulo, uma ótima conferência feita por desenvolvedores para desenvolvedores.

Nesta conferência eu tive a oportunidade de falar sobre o Guia da Startup.

Martin Fowler (@martinfowler) da ThoughtWorks fez o primeiro keynote. Em um certo momento ele usou uma frase interessante para introduzir o tema de bom design e débito técnico.

Eu normalmente me deparo com desenvolvedores que estão frustrados porque “a gerência quer mais recursos, eles não se preocupam com qualidade”

A citação me chamou a atenção especialmente porque, como um desenvolvedor falando para desenvolvedores em uma conferência de desenvolvedores, Martin se focou na parte da frase que normalmente chama a atenção dos desenvolvedores, a parte do “como”. Ele se focou na palavra “qualidade” para explicar o quanto é importante ter um bom design para evitar o endividamento técnico para que os desenvolvedores possam adicionar mais recursos com mais facilidade. Como eu estou mais focado no lado de gestão de produto, assim que eu ouvi a frase, meu foco foi imediatamente para a parte do “porquê”. Isso me motivou a criar um novo slide na minha apresentação sobre as práticas de gerenciamento de produtos:

Quando eu ouvi a frase, meu foco foi direcionado diretamente para a palavra “funcionalidades” e minha primeira reação foi perguntar “Porque é que estas funcionalidades estão sendo solicitadas?”

Quando nos pedem para implementar uma funcionalidade em um software, a reação natural é pensar como essa funcionalidade pode ser implementada. No entanto, precisamos dar um passo atrás e entender o que estamos tentando obter com essa funcionalidade. Que valor essa funcionalidade traz para os usuários do software? Que valor essa funcionalidade traz para os proprietários de software? Cada novo recurso, não importa quão pequena e quão simples de implementar seja, cria complexidade no nosso código. Qual é o valor que esperamos dessa complexidade? Esta é uma pergunta que não apenas um gestor de produto deve fazer, mas todas as pessoas a quem for pedido para implementar uma nova funcionalidade devem tb fazer a mesma pergunta.

Assim, a minha recomendação para todos os desenvolvedores que recebem solicitações para implementar novas funcionalidades é que, antes de correr para descobrir o “como” a funcionalidades deve ser implementada, pergunte “por que” essa funcionalidade está sendo pedida. Isso ajudará você a compreender a importância da funcionalidade e ajudará quem está pedindo a funcionalidade a reafirmar a motivação por trás dessa funcionalidade.

Quanto tempo levou para fazer o ContaCal?

Já falei aqui como fiz o ContaCal. Para confirmar a importância de fazer rápido o produto web, aqui está um gráfico que mostra quanto tempo levei para colocar o ContaCal na frente de clientes:

Dados do desenvolvimento e lançamento do ContaCal

Dados do desenvolvimento e lançamento do ContaCal

Cronograma:

  • 23/08/2011: Início do desenvolvimento da aplicação pelo pessoal da StartupDev.
  • 25/08/2011: Aplicação pronta e início da adaptação do logo e do template de WordPress.
  • 01/09/2011: Site em WordPress pronto.
  • 02/09/2011: Campanha de AdWords religada. Até aqui eu só tinha usuário de teste. A partir daqui é o momento da verdade, com usuários reais utilizando o sitema.
  • 04/09/2011: Email para pessoas que mostraram interesse.
  • 07/09/2011: Início de campnha no Facebook.

Ou seja, do início do desenvolvimento até religar a campanha no AdWords foram 10 dias! :-)

Resultado

Veja nas telas abaixo a primeira versão do site e da aplicação. Ambos já mudaram significativamente desde essa primeira versão.


Primeira versão do site

Primeira versão do site

Primeira versão da tela de login

Primeira versão da tela de signup

Primeira versão do produto web

Primeira versão do produto web


Boas práticas de engenharia de software

Claro que não adianta você saber exatamente o que vai fazer na versão mínima de seu produto web se você não tiver um ótimo time de desenvolvedores de software e designers de interface do usuário. Só que ter pessoas bem qualificadas por si só não resolve. É preciso que essas pessoas trabalhem usando as melhores práticas de engenharia de software. Vou comentar um pouco sobre algumas dessas práticas aqui, apesar de esse não ser o foco principal deste blog.

Desenvolvimento iterativo de software

A primeira boa prática que quero comentar aqui é o desenvolvimento iterativo de software. Essa forma de desenvolvimento se contrapõe ao modelo de desenvolvimento de software conhecido como waterfall. No desenvolvimento waterfall as fases de desenvolvimento de software são claramente definidas e, uma vez terminada uma fase e iniciada a outra, não se pode voltar atrás. Por exemplo, se você quer desenvolver um produto web, no desenvolvimento waterfall você precisa especificar absolutamente todas as funcionalidade que você vai querer nesse software, pois o desenvolvimento de software é visto como um projeto com começo, meio e fim que acontece em sequência: definição de requisitos, detalhamento e especificação do software, codificação, teste e produção. Já no desenvolvimento iterativo de software, esse mesmo ciclo é reduzido ao seu menor tamanho possível e repetido várias vezes usando o feedback do ciclo anterior para melhorar o próximo ciclo.

Jeff Patton, reconhecido consultor de desenvolvimento de software, fez uma comparação entre waterfall e desenvolvimento iterativo de software fazendo uma analogia com o processo de pintar um quadro. Qual dos dois processos abaixo parece ser mais natural?

Waterfall

Waterfall

Desenvolvimento iterativo

Desenvolvimento iterativo

Esse processo de desenvolvimento iterativo de software acabou sendo uma das bases do Manifesto para Desenvolvimento Ágil de Software, escrito há mais de 10 anos, que acabou se tornando uma revolução na forma de se fazer software:

Estamos descobrindo maneiras melhores de desenvolver software, fazendo-o nós mesmos e ajudando outros a fazerem o mesmo. Através deste trabalho, passamos a valorizar:

  • Indivíduos e interações mais que processos e ferramentas
  • Software em funcionamento mais que documentação abrangente
  • Colaboração com o cliente mais que negociação de contratos
  • Responder a mudanças mais que seguir um plano

Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.

Esse manifesto melhorou em muito a forma como software é desenvolvido, garantindo maior envolvimento da pessoa que define como vai ser o software durante o desenvolvimento desse software.

A partir desse manifesto alguns processos de desenvolvimento de software foram criados de forma a permitir esse envolvimento. Uma das recomendações que veio como consequência do manifesto é os times que desenvolvem software devem se reunir periodicamente para definir o que fazer e para acompanhar o andamento do projeto. Nessas reuniões participam não só os desenvolvedores de software como também as pessoas que definem “o que” e “como” será o produto web. O “o que” é definido pela função de gestão de produto e o “como” é definido pela função de experiência do usuário, funções descritas no post Quem deve criar uma startup de um produto web?. Essas reuniões frequentes são fundamentais para garantir a velocidade de entrega do produto mínimo.

TDD

Outra boa prática muito importante é o TDD (Test Driven Development ou Desenvolvimento Baseado em Testes). Por meio dessa prática se garante não só a qualidade do software que está sendo desenvolvido, uma vez que todas as suas funções têm testes para garantir que o que foi desenvolvido está funcionando conforme esperado, testes esses preferencialmente automatizados, como também aumenta a segurança para futuras modificações nesse software. Quando seu software tem testes, você pode adicionar novas funcionalidades e, por meio dos testes, garantir que o software continue se comportando conforme esperado em todas as situações previstas e cobertas pelos testes.

Entrega contínua

Ter essa cobertura de testes é fundamental para poder executar a terceira boa prática que eu queria comentar, a entrega contínua. Entregar continuamente o software significa ter a capacidade de colocar seu software em produção a qualquer momento de forma simples. Você só poderá fazer isso se:

  • tiver cobertura de testes para garantir que o software que você colocou em produção está fazendo o que se espera dele e;
  • tiver uma forma simples e rápida de voltar atrás, ou seja, se der algum problema com o software que você acabou de colocar em produção, você é capaz de restaurar a versão anterior do seu software em produção.

Ter entrega contínua é muito importante para que você possa, após ter seu produto web funcionando e com usuários, fazer rapidamente modificações nesse seu produto web baseado nos feedbacks que você receber desses usuários.

Como disse acima, quis incluir aqui no blog um rápido comentário sobre as boas práticas de desenvolvimento de software mas eu recomendo que, caso você não tenha ouvido falar dessas práticas, procure conhecer mais lendo blogs, indo a cursos, lendo livros e participando de eventos sobre desenvolvimento de software.

Recapitulando: fazer rápido o produto web = saber o que fazer + boas prática de engenharia de software

Por melhores que sejam os desenvolvedores e os designers de interface que trabalharem no seu produto, se você não escolher com muito cuidado que funcionalidades colocar e não selecionar um conjunto mínimo de funcionalidades, as chances de você desperdiçar tempo de desenvolvimento são muito grandes. A definição clara de seu produto mínimo é fundamental, e você só vai conseguir fazer isso conhecendo bem o problema do seu cliente e sabendo exatamente o que você está resolvendo para ele. Além disso, mesmo os melhores profissionais com a mais clara definição do que vão fazer precisam de boas práticas de desenvolvimento de software para poder desenvolver com rapidez um produto web de qualidade.

Pense em startup como experimento, e não como negócio

A dica rápida de hoje veio do Paulo Silveira, da Caelum. Ele me mandou um post interessante de um rapaz chamado Vinicius Vacanti que tem uma startup e descreve nesse post as inúmeras desculpas que fizeram ele demorar para lançar logo o produto:

  • Não está bom o bastante.
  • Não queremos dar uma má impressão para os usuários.
  • Precisa de mais algumas funcionalidades.
  • Precisamos de alguns mess para construir o back-end do produto.
  • Precisa escalar para acomodar centenas de mil hares de usuários.
  • Alguém via ver e via copiar.
  • Um investidor potencial vai ver.
  • TechCrunch via escrever sobre a gente e o site não está pronto.

No final do post ele termina com uma frase que define muito bem o que é uma startup:

Pense em startup como experimento, e não como negócio.

Startup é um experimento. Vc deve experimentar para encontrar a solução para o problema de seus clientes e para garantir que esses clientes vão lhe gerar o retorno financeiro suficiente para que vc continue oferecendo essa solução. Quando vc achar que não deve mais experimentar, ou deve diminuir o ritmo de suas experiências, provavelmente vc já encontrou um retorno mensal dentro do que vc esperava e nesse momento vc estará fazendo a transição de startup para um negócio.

Próximo post

Amanhã vamos falar sobre como atrair visitantes para o seu site.

Comentários

Já tinha pensado em startup dessa forma? Ajuda a ver que temos que, já que é uma experiência, devemos experimentar logo, não é?

Se vc não tem vergonha da primeira versão de seu produto, vc demorou demais para lançar.

Nos dois últimos posts falamos sobre porque devemos fazer rápido um produto web e que não basta ter bons profissionais, bons equipamentos e boa metodologia, é fundamental definir o produto mínimo, ou seja, que funcionalidades entram e que funcionalidades ficam de fora da primeira versão de seu produto web.

Reid Hoffman, fundador do Linkedin disse certa vez que:

Se vc não tem vergonha da primeira versão do seu produto, vc demorou demais para lançar.

Para ilustrar essa frase, que de certa forma sumariza os dois posts anteriores, resolvi pegar prints da tela da primeira versão de alguns serviços bem conhecidos.


Google em 1998

Google em 1998

Twitter em 2006

Twitter em 2006

Linkedin em 2005

Linkedin em 2005

Tela de login do Facebook em 2005

Tela de login do Facebook em 2005

Facebook em 2005

Facebook em 2005

Buscapé em 1999

Buscapé em 1999

Locaweb em 2002

Locaweb em 2002


Próximo post

No próximo post entramos na segunda parte do mão na massa, a parte que fala sobre gerenciar o produto web. Uma vez que produto web está pronto, o que fazer?

Comentários

E aí, se divertiu revendo as imagens acima? Tem mais imagens bacanas? Compartilhe!

Como fazer rápido o seu produto web?

Já entendemos porque é importante fazer rápido o produto web. Agora precisamos saber como fazer isso! Será que precisaremos de bons desenvolvedores de software? Com certeza. E bons designers de interface do usuário? Sem dúvida alguma!

Contudo, só ter bons profissionais te ajudando não é o segredo para vc fazer o produto rapidamente. O que você precisa fazer é definir quais são as funcionalidades mínimas necessárias para o seu produto. Esse é a principal responsabilidade da função de gestão de produtos que, como eu comentei anteriormente no post sobre as diferentes áreas de conhecimento envolvidas em uma startup, é uma das únicas funções que não podem ser terceirizadas. Quem tem que fazer isso é vc.

A importância de conhecer o cliente e o seu problema

Nesse momento fica claro a importância de se conhecer muito bem o cliente e o seu problema. Vc vai ter que entender muito bem qual é o problema e qual é a solução mínima que vai resolver o problema desse cliente. Fica claro também a vantagem de se trabalhar em um problema próprio, pois sendo vc mesmo o cliente, é mais fácil definir o que é mínimo para resolver o problema.

Tome cuidado pois, como com software dá para fazer muitas coisas legais, é muito fácil a gente cair na tentação de querer colocar “só mais essa funcionalidade” antes de lançar o produto. Pense bastante se essa funcionalidade não terá um custo muito alto de desenvolvimento em termos de tempo, energia e dinheiro – vc se lembra das curvas de retorno de investimento do post anterior? – para o benefício que ela pode trazer para a solução do problema do cliente.

Para ilustrar isso de forma clara, vou citar dois exemplos.

Cursos online da Caelum

A Caelum é uma empresa bastante conhecida pelos seus cursos presenciais de desenvolvimento de software. Há uns 3 anos começou a surgir demanda por cursos online mas Paulo e Guilherme Silveira, sempre preocupados com a qualidade de ensino, não queriam dar esse passo até encontrar uma forma de oferecer cursos online com uma qualidade satisfatória. No início de 2011 encontraram um formato que lhes pareceu interessante. Resolveram então desenvolver o produto web de educação online com esse formato. O desenvolvimento começou em fevereiro de 2011 e a versão para usuários gratuitos ficou pronta no final de julho de 2011, totalizando 5 meses de desenvolvimento. Paulo ainda estava inseguro quanto a lançar na QCon em setembro, sentia que ainda precisava colocar várias funcionalidades, dentre elas a cobrança. Eles correram para colocar alguma forma de cobrança que ficou pronta literalmente no dia do lançamento que foi no primeiro dia da QCon. Várias funcionalidades que eles queriam ter colocado para o lançamento da versão paga acabou não entrando no lançamento.

Resultado: o primeiro cliente pagante veio somente depois de duas semanas, ou seja, a cobrança não era tão necessária para o lançamento. Agora em março de 2012, é uma funcionalidade bem necessária! Já são quase 130 cursos vendidos e um total de 400 alunos distintos. Contudo, a cobrança poderia ter sido desenvolvida após o lançamento. As outras funcionalidades que eles queriam ter colocado não fizeram falta para o lançamento do produto e, quando houve clientes reais utilizando, o que esses clientes deram de retorno acabou orientando o desenvolvimento do produto web.

ContaCal

Quando usei o pessoal da StartupDEV para fazer o ContaCal, eu não tive a opção de tentar fazer mais desenvolvimento e gastar mais tempo, eu tinha direito a apenas 48 horas. Eu mostrei para o time de desenvolvedores o que eu queria e eles estimaram quanto tempo cada pedaço do sistema ia levar. Obviamente que fazer todo o sistema ia ultrapassar as 48 horas que eu tinha direito, então tive que escolher.

Quando desenhei os wireframes do ContaCal para passar para o pessoal da StartupDEV desenvolver a aplicação web, os slides 4 e 5 tinham dois gráficos, uma para mostrar a evolução das calorias e outro para mostrar a evolução do peso. Não tinha como caber os dois. Eu tinha que escolher um dos dois, ou gráfico de evolução de calorias, ou gráfico de peso. Lembro que foi uma decisão difícil, e depois ainda conversamos sobre fazer versão de 7 dias e versão de 30 dias.

Decidi por implementar o relatório com evolução de controle de calorias, com visualização de 7 dias e 30 dias. Recebo com alguma frequência pedido de clientes que gostariam de ter alguma forma de acompanhar seu peso no contaCal. É a funcionalidade que deixei de implementar. Por outro lado, de todos os pageviews que a aplicação tem, 4,6% são pageviews dessa funcionalidade, ou seja, uma funcionalidade que tem um uso razoável, ainda mais comparado com 31,4% de pageviwes da página principal da aplicação:

Pageviews do ContaCal

Pageviews do ContaCal

Só que a dúvida ficou, será que relatório era de fato uma funcionalidade essencial para ter numa versão mínima do produto? Será que as pessoas gostam mais do produto por ter essa funcionalidade. Tem algumas formas de saber. Uma delas é fazendo uma pesquisa segmentada, ou seja, conversando com usuários que usam e com usuários que não usam a funcionalidade para saber dos que usam o que gostam e porque usam e dos que não usam, porque não. Outra forma é simplesmente desligando essa funcionalidade por algum tempo e ficando antenado para reclamações e comentários.

Minha opinião é que o ContaCal poderia ter sido lançado até mesmo sem a funcionalidade de relatório e que isso não teria impactado o número de usuários que se cadastram e que depois se tornam assinantes.

Falo isso devido a outra funcionalidade que implementei no ContaCal após o lançamento. Muitos usuários comentaram que seria muito bom ter a possibilidade de controlar não só a quantidade de calorias ingeridas como também a quantidade de calorias gastas. Em novembro, dois meses e meio após o lançamento, coloquei essa funcionalidade no ContaCal, de registro de atividades físicas. Anunciei para a base de usuários existentes, destaco isso como uma das funcionalidades que o sistema tem e várias pessoas acham bacana, mas a curva de novos usuários que se cadastram para testar o sistema, bem como de usuários que decidem virar assinantes não mudou em nada! Para confirmar, acabo de ver na base de dados que 1,8% dos registros feitos são de atividades, 98,2% são registro de alimentos.

Recapitulando: fazer rápido o produto web = saber o que fazer

Por melhores que sejam os desenvolvedores e os designers de interface que trabalharem no seu produto, se vc não escolher com muito cuidado que funcionalidades colocar e não selecionar um conjunto mínimo de funcionalidades, as chances de vc desperdiçar tempo de desenvolvimento são muito grandes. A definição clara de seu produto mínimo é fundamental, e vc só vai conseguir fazer isso conhecendo bem o problema do seu cliente e sabendo exatamente o que vc está resolvendo para ele.

Próximo post

O próximo post vai ser surpresa! Já tenho ele montado e ele tem por objetivo confirmar que é preciso lançar logo um produto. Só não vou contar como será o post para não estragar a surpresa! :-P

Comentários

Vc conhece algum exemplo de produto que, quando foi lançado, era mínimo mas já resolvia um problema de cliente? Compartilhe nos comentários.

Por que é preciso fazer rápido o produto web?

Já falamos em alguns posts aqui no Guia da Startup sobre algumas definições e requisitos para se ter uma startup. Depois falamos sobre como ter ideias de produtos para a startup e que essas ideias vêm de problemas que as pessoas têm e e estão dispostos a pagar por essa solução. Estamos entrando agora no capítulo da mão na massa, na parte sobre como fazer um produto web.

E a primeira pergunta que vem à mente quando falamos em fazer um produto web é:

Por que é preciso fazer rápido o produto web?

Bom, precisar, não precisa. Como a startup é sua, é vc quem define suas metas e objetivos. Só que tudo o que a gente conversou até aqui está no campo da teoria. Mesmo as conversas com pessoas que têm um problema que vc vai resolver com seu problema web, mesmo a pesquisa que vc fez para decidir se seguia adiante com sua ideia de produto web, tudo isso é teoria. Vou lhe dar então 3 razões para vc fazer rápido o seu produto.

Razão 1: Vc só vai aprender alguma coisa útil sobre seu produto web quando as pessoas estiverem usando.

Quanto mais tempo vc demorar para colocar seu produto na rua, mais tempo vc vai demorar para aprender com pessoas reais se vc está no caminho certo. E pior, mais passos vc certamente estará dando na direção errada. Vc só vai saber se o produto web que vc fez realmente resolve o problema de algumas pessoas se essas pessoas usarem seu produto. Quanto mais tempo demorar para isso acontecer, mais tempo vai demorar para saber se seu produto é ou não é a solução do problema.

E se não for, o que vc faz? Conserta, ajusta, muda! Quanto mais cedo vc souber que o que vc está desenvolvendo não está no caminho certo, melhor, pois menos tempo, energia e dinheiro vc vai desperdiçar indo no caminho errado.

Razão 2: Quanto mais funcionalidade um produto tiver, mais difícil é de entender esse produto.

Existe um limite de funcionalidades que o usuário consegue entender. Quando colocamos funcionalidades demais, ao invés de criarmos uma solução para o problema do cliente, acabamos criando um novo problema para ele. Kathy Sierra, uma reconhecida instrutora de programação e de experiência do usuário, criou um gráfico de funcionalidades que ilustra de forma clara e divertida como a satisfação do usuário diminui à medida que aumentamos a quantidade de funcionalidades de um produto.

Razão 3: Quanto mais tempo vc demorar para lançar, mais tempo vai demorar para ter receita e, consequentemente, mais tempo demora para ter o retorno do dinheiro que vc investiu.

Quanto mais tempo seu produto web demorar para ter usuários e, consequentemente, clientes que em algum momento irão pagar pelo seu produto web, mais vc terá que investir do seu próprio bolso. Veja abaixo um gráfico típico de retorno de investimento de um produto. Enquanto vc não lançar seu produto e não tiver receita, tudo o que vc terá é custo, ou seja, vc estará na parte de investimento da curva abaixo. Isso só muda quando vc começar a ter receita e essa receita for maior que os custos mensais, aí vc entra na área descrita abaixo como rentabilidade mensal. Só depois de alguns meses nessa área é que vc terá o retorno do seu investimento. Veja como o caminho é longo.

Retorno de investimento de um produto web

Retorno de investimento de um produto web

Agora veja no gráfico abaixo, como um atraso de 3 meses em obter receita pode atrasar em 6 meses a obtenção do retorno do investimento. Será que esses 3 meses de atraso em obter receita valem a pena? O que vc vai fazer nesses 3 meses realmente compensam 6 meses de atraso no retorno do investimento?

Impacto do atraso do lançamento do produto no retorno do investimento

Impacto do atraso do lançamento do produto no retorno do investimento

Por outro lado, veja só o que vc ganha se conseguir acelerar o desenvolvimento de seu produto e o lançar 3 meses antes do planejado. Vc ganha 6 meses de retorno do investimento! E a explicação para isso não é só pq vc adiantou a entrada de receita, é pq vc gastou menos para poder lançar o produto mais rápido. Veja no gráfico abaixo.

Retorno do investimento de lançar um produto mais cedo

Retorno do investimento de lançar um produto mais cedo

Próximo post

Acabamos de entender as 3 razões de se fazer rápido um produto web. Amanhã vamos falar sobre como fazer rápido esse produto web. É preciso bons desenvolvedores? Bons designers de interface do usuário? O que é esse tal de MVP que tudo mundo fala?

Comentários

Vc tinha ideia que lançar rápido um produto web era tão importante? Vc conhecia essas 3 razões? Comente!