O principal erro de uma startup « Agile Way


28 de Julho de 2011

O principal erro de uma startup

A maioria dos meus leitores sabe que eu tenho uma startup, a Woompa. Criei minha empresa em junho de 2010 e desde então estamos trabalhando nas nossas soluções para a web. Nosso foco é no setor da construção civil. Estamos finalizando nosso produto chamado Pixel Quadrado, um conjunto de serviços para facilitar a entrada de construtoras e incorporadoras na internet. Temos outros sistemas saindo do forno, em fase de desenvolvimento.

Passados 1 ano e 2 meses de empresa, eu olho pra trás e vejo uma sucessão de erros que cometemos. Mau planejamento, gold plating, escopo sem fim, avaliações erradas de pessoas, falta de tino para vendas, enfim. A lista seria grande.

Mas eu percebi que há um erro que nós cometemos e que foi imperativo para nossa atual dificuldade.

A falta de uma deadline.

Durante minha estada como gerente de projetos de um grupo de pesquisas na PUCRS, uma das minhas maiores frustrações foram em vivenciar projetos sem fim, que tinham cronogramas de 2 anos, em média. Era frustrante aquela sensação de passagem dos dias e perceber que estávamos longe do final. Não havia real pressão para entrega, pois estávamos desenvolvendo algo que não tinha mercado ainda. E talvez nem tivesse.

Em seguida, fui gerente de projetos de uma agência digital, onde os projetos nasciam e tinham que ser entregues em média a cada 3 ou 4 meses. Com prazos apertadíssimos, como qualquer agência. Era uma loucura, uma correria, mas a sensação era excelente. Víamos o projeto nascer, se desenvolver e ser entregue.

Aquilo me fez jurar que jamais eu viveria novamente a sensação de viver um projeto de 1 ano.

Pois na Woompa, acabei vivenciando isso. De novo. E foi novamente frustrante.

Então, olho para trás e percebo que o motivo principal por essa demora é a falta de um deadline. E principalmente de uma pressão real para essa entrega. Uma pressão do mercado, que fizesse o conceito de deadline ficar latente e nos tirasse o sono. Nosso Pixel Quadrado não tinha clientes e nem um mercado demandando pela sua entrega. E isso nos atrasou dia após dia.

O que acontecia aqui na empresa era normalmente isso:

“Dia 05 de março temos que finalizar tudo, ok?”. Daí o dia 5 de março chega, e não temos as coisas prontas. “Ah, ok, vamos então tentar para o dia 20”. E assim se seguiu.

Quando o que devíamos ter feito era definir a data e então enquanto a equipe desenvolvia, eu deveria ter preparado todo o lançamento do produto, gerando expectativa no mercado. Dessa forma, geraria uma pressão interna, criaria um “cliente” que iria exigir aquele prazo. Seria uma corrida contra o tempo, mas no fim iríamos finalizar o sistema e entregá-lo. Pois é só assim que funcionamos.

Se não há pressão, nós tendemos a não andar pra frente, mas estagnar. É natural do ser humano, por mais que alguns não admitam.

Portanto, se você está criando a sua startup e está desenvolvendo o seu produto, lembre-se disso. Você só vai finalizá-lo e entregá-lo quando estiver pressionado.

E se essa pressão não existir, de fato, crie ela você mesmo.

Ou perca seu tempo e dinheiro andando em passos de tartaruga. Como eu.



2 Comentários para “O principal erro de uma startup”

  1. guilherme diz:

    vejo que ter statup na maioria das vezes é aprender apanhando hehe.

    mas aí, legal o px2.
    como um chato da qualidade e olhando por esse lado, tenho considerações:

    1. vocês não acham que estão utilizando muito as palavras seu/sua no site? dá a ideia de site próprio etc, mas só na 1ª página a palavra seu/seus aparece 7 vezes e a palavra sua/suas aparece 4!

    2. não consegui ver os layouts no /assine.

    3. no /conheca, ao passar o mouse (alt) no icone de agilidade, fala de ‘poucos minutos’, depois no icone de email fala em ‘poucas horas’!! hehe. O alt do atendimento fala sobre layouts.

    4. em /ajuda, tem um link para voltar ao topo que já tá no topo da página.

    abraço!

  2. Gabriel diz:

    Muito bem colocado a questão da pressão para a entrega. Mas deve-se ter cuidado com a intensidade de cobrança e pressão, evitando desmotivar a equipe, e com os impactos dos erros ou bugs do produto.

Comentar