« HE:labs
HE:labs

Tivemos um cliente insatisfeito, vamos aprender!

Postado por Rafael Lima em 01/10/2013

Nesse final de semana rolou um post no Facebook sobre desenvolvimento MVP em que uma pessoa indica o Startup DEV e um de nossos clientes responde que o nosso serviço "foi uma decepção". Decepcionar um cliente é a última coisa que queremos fazer e por isso vamos conversar sobre o assunto.

O post em questão está no grupo do Startup Brasil do Facebook, ele chegou até a mim por meio dessa imagem abaixo. Leia a conversa até o final antes de prosseguir.

image

Quem quiser visualizar o post, acesse: https://www.facebook.com/groups/supbra/?hc_location=stream

Eu, como idealizador do Startup DEV e dono da empresa, fiquei triste ao ler a discussão e constatar que o André realmente não recomenda os nossos serviços. Sinceramente me surpreendeu saber disso através destes comentários.

Não estou acostumado com essa situação, uma vez que praticamente todos os nossos clientes ficam super felizes ao finalizar o projeto. Cerca de 40% nos contratam novamente para dar prosseguimento no desenvolvimento e alguns deles inclusive gravaram vídeos com depoimentos bancanas. Nenhuma prova maior de satisfação e aprovação que contratar novamente e dedicar um tempo da vida para fazer um vídeo.

Faz parte da cultura da HE:labs o processo de melhoramento contínuo.

Fazemos isso através das reuniões de retrospectiva. No âmbito da empresa, nos reunimos, todos da empresa, a cada 2 semanas para conversar sobre o que esta legal e principalmente o que pode melhorar.

Fazemos isso também para cada iteração de um projeto longo e no caso do Startup DEV, ao final de cada projeto. No caso do Startup DEV, o time se reúne na empresa ou vai para um restaurante confraternizar a entrega do projeto e conversar sobre o que rolou. Nesse momento levantamos os problemas ocorridos, os desafios encontrados, enfim, tudo que rolou nos dias de desenvolvimento e também na reunião. É uma reunião interna de fechamento do projeto.

Na retrospectiva do projeto Timeeline não foi levantado nenhum problema maior. Assim como em todos os outros projetos, parte do que o cliente esperava desenvolver ficou de fora e outra parte foi desenvolvida. O que foi desenvolvido foi legal e está funcionando direitinho. Dado o feedback que o time recebeu e o que havia sido entregue, do nosso ponto de vista o projeto tinha sido um sucesso.

Após ler e reler o histórico da conversa no Facebook eu parei para analisar os pontos que precisamos melhorar em nosso serviço. Minha preocupação é corrigir os nossos erros antes que o problema aconteça novamente. Eu cheguei a algumas conclusões.

A primeira delas é que precisamos explicar melhor o nosso serviço e para isso eu gostaria de aproveitar alguns comentários colocados na discussão para explicitar melhor como funciona o MVP do Startup DEV. Eu vou inclusive pedir para todos os nossos leads e prospects lerem este post antes de nos contratarem, como forma de avaliarem se estão preparados para o projeto. Seguem os comentários da discussão com minhas considerações:

André Coutrim "Eu contratei a HE Labs no Rio e foi uma decepção. Ficou um lixo e tive q engolir assim mesmo, sem nenhuma consideração do prestador de serviço…"

O André Coutrim foi nosso cliente do projeto Timeeline, cuja reunião ocorreu em 24 de abril de 2013 e o desenvolvimento nos dias 25 e 26 de abril, há 5 meses atrás. O projeto está no ar até hoje no endereço http://www.timeeline.com/ mas não está sob nossa custódia, uma vez que o cliente não voltou a nos contratar.

Logo após a entrega, o André me enviou um e-mail pedindo para marcar um reunião para negociar a continuidade do desenvolvimento pois queria desenvolver mais coisas que ficaram de fora do que foi entregue no Startup DEV. Nós enviamos as opções de contratação, mas nenhum contato por parte dele foi realizado em seguida. Ele optou por não nos contratar novamente.

Houve uma grande falha de comunicação, pois o André ficou com uma sensação de que não tivemos nenhuma consideração enquanto nós consideramos o projeto entregue e bem sucedido com os outros.

André Coutrim "... acabou o prazo, foi oq deu p fazer e pronto. N aconselho."

No Startup DEV, o que estamos vendendo é o tempo de trabalho de uma equipe altamente especializada. Para quem está contratando software, essa é a melhor forma de se contratar. O recurso que está sendo comprado é o tempo da equipe. Então de fato, quando o prazo acaba, o projeto acaba, é assim que funciona.

A questão é que sempre conseguimos utilizar muito bem nosso tempo e o processo que criamos, garante que dentro do tempo de trabalho, conseguimos entregar uma primeira versão do sistema online e funcionando de acordo com a priorização feita pelo cliente no dia de reunião.

Respeito a opinião do André de não aconselhar dessa forma, mas eu digo que contratar tempo de trabalho ao invés de fechar o escopo é a melhor coisa que qualquer pessoa pode fazer na hora de contratar um projeto. Para mais informações sobre isso recomendo o vídeo com a nossa visão sobre projetos de software

André Coutrim "Acho q oq falta nesses lances de fazer MVP, é uma avaliação do resultado. Oq aconteceu cmgo foi q ficou claríssimo q o resultado foi um produto q na dava pra utilizar. N servia p nada… daí n houve uma flexibilidade ou bom senso pra entender isso e fazer algo pra melhorar ou amenizar o problema. Os caras simplesmente lavaram as maos e adeus… pague mais 10 mil q consertamos… foi péssimo."

Na nossa visão, o sistema que entregamos já era o suficiente para dar os primeiros passos nas validações do negócio, mas compreendemos e respeitamos a opinião contrária. Isso é muito pessoal e não há certo ou errado. É muito comum que as pessoas achem que precisam de muito mais do que realmente precisam. Eu escrevi um pouco sobre isso nesse post sobre MVP concierge, um caso real.

Se na opinião do cliente o MVP que tem em mãos ainda não é o suficiente para utilizar, se faz necessário a continuação do desenvolvimento. Essa continuação não está prevista na estrutura de custo e proposta do Startup DEV, que possui um preço baixo e fixo. Então, para continuar, é necessário investir mais um pouco.

Somos bastante flexíveis para que qualquer cliente consiga continuar o projeto, independente do tamanho do orçamento. No nosso modelo de trabalho é possível contratar 1 dia, 1 semana, 1 mês ou vários meses de um ou mais profissionais. Mas se o cliente não deseja investir mais, não é possível continuar a trabalhar. Não fazemos filantropia.

André Coutrim "É um formato canibal… … Entao, se o seu mvp for um site simples, e estiver bem resolvido na sua cabeça, talvez dê certo… se nao, terá decepção."

Cada projeto é uma realidade. Já houve um caso em que entregamos um sistema em que o cliente já tinha contratado outra empresa por 6 meses e não tinha tido resultado nenhum. Em um outro caso conseguimos fazer nos 2 dias o que uma equipe interna não tinha conseguido fazer.

De fato, quanto mais o nosso cliente souber o que quer, melhor o tempo de trabalho será aproveitado e por consequência melhor será o resultado. Mas não é nem por isso que deixamos de resolver.

Em alguns casos os clientes não tinham a menor ideia de como queriam implementar, às vezes nem mesmo a clareza do problema e da solução de negócio, e nem por isso deixamos de conseguir extrair o máximo de informações da cabeça dele e transformar em software funcionando e pronto para ser usado.

André Coutrim "Na teoria eles fizeram o serviço. No contrato fica td amarrado. Aliás, eu pagaria 30% se desistisse na reunião de briefing, que precede o trabalho. Ali eu percebi q ia ser complicado, mas entre perder 30% sem ter nada e pagar tudo e ter ao menos um começo, optei por este ultimo."

Essa é uma das grandes vantagens do nosso modelo. Nós fazemos de tudo para reduzir o risco de quem está contratando. A reunião de briefing é na verdade um dia inteiro de trabalho entre o cliente e a equipe. Nessa reunião nós desenhamos telas, escrevemos tarefas, estimamos cada tarefa e elucidamos o cliente em relação ao esforço e desafios técnicos inerentes ao projeto. É comum também adentrarmos no modelo de negócios, caso o cliente se mostre propenso a aceitar sugestões.

É muito melhor ter essa opção de trabalhar com a equipe antes de contratar o valor do projeto total do que fechar um contrato sem ter essas informações, ou com a ilusão de informações não realistas.

O pagamento dos 30% é mínimo para cobrir os custos da equipe nesse dia de trabalho.

André Coutrim "tipo, tava funcional. Mas n ficou bom... é complicado. Nao tinha bugs... só n daria ao usuário a experiencia que deveria. Navegabilidade confusa, recursos importantes ficaram de fora do calculo deles. depois da reunião de briefing, eles avaliam "qto vale" na moeda deles, cada implemento. Dai vc tem direito a 80 tickets, vamos chamar assim... dai oq eu queria fazer dava mais de 120... dai tive q ir capando tudo ate ficar nos 80... e sao dois dias de trabalho onde esses 80 tickets têm q ser entregues... e foram. Mas os q ficou de fora comprometeu totalmente o projeto... dai fiquei meses procurando alguém pra fazer o restante... em RoR."

Somos muito produtivos e conseguimos entregar em um espaço de tempo o que nenhum outro time do Brasil se mostrou capaz. Não dá pra competir com o prazo. Mas também não dá pra fazer tudo.

Nós criamos esse sistema de pontuação como uma ferramenta de comunicação para poder apresentar para o cliente o esforço de desenvolvimento de cada parte do sistema. Com o esforço em mãos o cliente pode priorizar o que é mais importante e o que vale a pena ser feito. Lembrando que nosso sistema de pontuação em nada se assemelha a pontos de função.

O objetivo é chegar nas escolhas de melhor relação custo x benefício. Nós sabemos o custo e o cliente sabe o benefício. Com a lista das tarefas pontuadas em mãos, o cliente prioriza o que acha mais importantes e tem 80 pontos para somar entre as tarefas.

Todos os 60 projetos que entregamos até hoje eram maiores do que seria possível desenvolver em 2 dias. Dentro da nossa pontuação, não teve nenhum projeto que ficou abaixo de 100 pontos no somatório total. O exercício é escolher o que é mais importante e também, por consequência, escolher o que não vai ser desenvolvido.

Esse é o objetivo de um MVP, fazer o mínimo que seja viável para os próximos passos. Eu garanto que 80 pontos dentro do nosso sistema de cálculo é mais que o dobro do que deveria ser suficiente para um MVP. É por esse motivo, inclusive que nós mudamos o modelo e estamos trabalhando com menos esforço e com o valor do projeto mais barato. Mais informações em: http://startupdev.com.br/pt/servicos-para-startups/mvp/

Murilo Azevedo "isso é complicado.. pela minha experiência é dificil dar certo pelos motivos: - você sempre esquece de um detalhe ou outro que podem impactar na regra de negócio; - você pode errar na arquitetura e isso pode impactar lá na frente;

O que a gente sugere por aqui é trabalhar com prazo mais realista, geralmente de 3 meses. Mas dessa maneira o cliente consegue validar as etapas, apontar bugs e conseguimos corrigi-los, dentro do escopo que foi fechado."

Nós concordamos com o Murilo. E vou além, não é difícil dar certo, é impossível! É por isso que sempre dizemos que o MVP do Startup DEV é apenas o primeiro passo.

Nós também sugerimos trabalhar com prazos maiores, mas quando se está afim de desenvolver o projeto e quando se tem orçamento para tal. Trabalhar 3 meses é mais caro que trabalhar 2 dias.

O Startup DEV é uma excelente saída para quem quer reduzir os riscos e desenvolver o mínimo para as primeiras validações e apresentações, gastando muito pouco. Claro que muito e pouco é relativo, mas desenvolver software no geral é caro, muito caro. Então dentro dos padrões de mercado, dado o preço do MVP do Startup DEV e todas as vantagens em redução de risco que ele oferece, ele se torna barato.

Conclusão

Nós sempre tomamos o máximo de cuidado para gerenciar a expectativa de nossos clientes e de conseguir mostrar como software funciona e como se deve encarar um desenvolvimento sob demanda, mas dessa vez de fato falhamos. Essa é a parte mais difícil do processo, por que o software é algo completamente intangível e difícil de mensurar.

Vender software da maneira correta é um desafio enorme. Não é à toa que ainda nos dias de hoje vemos fábricas de software, que para mim é como senzalas do século XXI.

Na HE:labs e no Startup DEV ainda precisamos melhorar a nossa comunicação com os clientes. Ler essa discussão no Facebook é de certa forma um grande aprendizado.

Eu agradeço o André por ter explicitado suas opiniões e ter respondido o meu e-mail explicando a sua visão. Foi muito útil pra gente ouvir isso tudo e nos forçar a parar para pensar sobre nossa empresa.

Precisamos melhorar nossa conversa pré-venda bem como nosso contato pós projeto. Estamos constantemente trabalhando para melhorar os nossos serviços, descobrir as maneiras mais produtivas de produzir e executar um serviço de excelência.

Nossa missão é transformar o mercado de software e esse é um investimento de longo prazo. Ainda temos muito o que melhorar para quem sabe um dia conseguir satisfação de 100% de nossos clientes.

Compartilhe

Sabia que nosso blog agora está no Medium? Confira Aqui!