Ricardo Fernandes Luiz

Agile, desenvolvimento de software, gestão, marketing, e tecnologia em geral

Não à ditadura do desenvolvimento

with 12 comments

 

Saudações pessoal!

Como sabem sou da área de desenvolvimento de software, mas neste post farei o papel do advogado do diabo  =D

Vou começar com uma analogia:

Você está morrendo de fome e depois de andar um pouco entra no primeiro restaurante que encontra, sua vontade é de comer um hamburguer, na verdade você até gostaria de um prato melhor, mas a fome é tanta que a velocidade de ter um hamburguer torna o prato mais interessante que você pode imaginar…

Você não sabe, mas quem vem atender é um dos melhores chefs do mundo, estudou por anos com os melhores chefs e aprendeu as mais variadas receitas, conhece todas as tendências da culinária e faz com maestria os mais refinados pratos, ele ouve o pedido diz que fica pronto em 10 minutos e vai para a cozinha.

Quando começa a pegar os ingredientes pensa: “Não! Ele não vai querer um hamburguer! Ninguem mais esta comendo este tipo de comida hoje em dia! É comprovado que faz mal a saúde a longo prazo! Ele quer satisfazer a fome, eu entendi isto e vou fazer de uma forma melhor, vou preparar um Blanquette de veau , (digamos que o preço do prato seja o mesmo) vou levar apenas 10 minutos a mais e além de satisfazer a fome dele, ele terá um prato saudável, com mais vitaminas e que os mais variados chefs recomendam.”

O chef volta e o cliente já revoltado pelo prato ter demorado mais do que ele esperava olha e vê que não é o que ele queria, manda ele voltar para a cozinha e fazer o hamburguer que havia pedido.

O chef perplexo argumenta “Não é possível, o prato é bem melhor, mais saudável, por que você vai querer um hamburguer? Agora que fiz um prato melhor vou ter que refazer de uma forma pior?”

Você fica com tanta raiva que não quer mais argumentar tudo o que quer é o maldito hamburguer.

Parece engraçado, mas no mundo do desenvolvimento isto às vezes acaba acontecendo. Estudamos tanto a melhor forma de fazer um software, que às vezes acabamos sequer perguntando ao cliente se é realmente isto que ele quer.

Você pode pensar, eu sou de TI, portanto sei o melhor para o meu cliente, assim como o chef pensou, porém tenho a mesma opinião expressada pelo Kent Beck no livro Programação Extrema Explicada, capítulo 14: “Mesmo que a escolha de uma tecnologia pareça ser em princípio uma decisão técnica, ela é na verdade uma decisão de negócios, mas que deve ser levado em conta informações do Desenvolvimento. O cliente precisará viver com um fornecedor de um banco de dados ou uma linguagem por muitos anos e ele precisa sentir-se confortável com a relação tanto a nível de negócios quanto no nível técnico. Se um consumidor me diz: ‘Nós queremos este sistema, e você precisa usar este banco de dados relacional e esta IDE Java’, minha função é apontar as consequências dessas decisões. Se eu penso que um banco de dados orientado a objetos e C++ é a melhor escolha, eu faço as estimativas do projeto dos dois jeitos, E então as pessoas de negócios podem tomar uma decisão de negócios.”

É nosso dever argumentar sobre um benefício que outra alternativa teria, no entanto se o cliente mesmo assim querer um hamburguer, faça o hamburguer! Não fique preso ao que os demais chefs apontam como tendência, ou o que eles vão pensar se souberem que você fez um hamburguer. Além de mostrar que você entende do seu mercado, vai satisfazer seu cliente e quem sabe faze-lo voltar outro dia para apreciar o Blanquette de veau .

Written by Ricardo F. Luiz

17/09/2010 às 3:31 am

Publicado em Carreira, Gestão, Reflexões

12 Respostas

Subscribe to comments with RSS.

  1. Achei muito boa a analogia, recentemente atuei por um período curto em um Projeto desenvolvido em Access VBA, no qual não é uma das melhores ferramentas e plataforma para se manter um sistema grande que acabou se tornando!

    Anteriormente, no inicio deste projeto no qual também participei foi indicado o desenvolvimento em .Net com integração via Web, no inicio já se previa o tamanho que este sistema ficaria. o Cliente decidiu que seria em Access VBA por ser mais “barato”, e foi feito em Access VBA e antes mesmo de terminar o Projeto e um ano após o inicio, o único cara que desenvolveu este projeto saiu fora, e deixou a bomba na mão do cliente e da consultoria, neste caso quem levará a culpa por este acontecimento? Independentemente da plataforma desenvolvida, é preciso ter pessoas competentes envolvidas no projeto para que casos como este não se repitam e não estraguem uma imagem de uma Consultoria!

    Jorge Cavalcante

    17/09/2010 at 3:59 am

    • O problema do cara que saiu ser o único a desenvolver o sistema já foi um erro da consultoria, que concentrou todo o sistema em uma só pessoa.
      Mas com certeza, sem pessoas competentes e compromotidas nenhum projeto tem sucesso!
      Quanto à escolha da tecnologia talvez o cliente não tenha tido informações suficientes, o cliente talvez tenha recebido uma proposta de menor valor para o desenvolvido em linguagem estruturada, porém não foi demonstrado a elo o custo a longo prazo de manter essa aplicação, se informassem que a longo prazo mudanças de negócio que seriam aparentemente simples quando realizadas no sistema orientado a objetos com uma boa modelagem de domínio e que o mesmo não seria verdade no sistema estruturado e que ele precisaria reescrever todo o sistema se houvessem muitas mudanças, talvez ele teria escolhido o sistema orientado a objetos…

      ricardofluiz

      17/09/2010 at 11:29 pm

  2. Ótima reflexão Ricardo. Acho que isso tem a ver com a ideia falsa de que surpreender o cliente é o objetivo.

    O melhor é respeitar a inteligência do cliente e fornecer as informações que ele precisa para tomar as decisões.

    grande abraço,
    Claudio Br

    Claudio Br

    17/09/2010 at 4:00 am

  3. Interesante a analogia, eh assim mesmo q funciona, parabens!

    Alexsandro Nunes

    17/09/2010 at 4:06 am

  4. Boa Ricardo,

    Está aberto o combate a persuasão certo ?🙂

    Por isso gosto de user stories, elas são mais um convite ao diálogo do que uma documentação formal que dá ainda mais brecha pra esse tipo de problema.

    Abs.

    Luís Fernandes

    17/09/2010 at 4:42 am

    • É verdade, porém mesmo em times ágeis e usando user stories já vi isto acontecer, porque as vezes queremos discutir as decisões de negócios, mas quando chegam as decisões técnicas acabamos tomando sozinhos. Não devemos esquecer que o convite para o diálogo deve ser uma mão de duas vias tanto nas questões de negócios quanto nas questões técnicas.

      ricardofluiz

      17/09/2010 at 11:41 pm

  5. Muito bom Ricardo !!!

    Nitidamente você evolui cada dia mais como profissional da área de tecnologia e desenvolvimento.

    Essa visão que as vezes temos de que “usuário bom é usuário morto” e de que “todo usuário é burro e não sabe o quer” está fadada ao fracasso.

    Vale muito mais a pena ouvir muito o cliente, apresentar o que pensamos ser melhor e deixa-lo decidir com as informações em mãos, do que simplesmente decidir por ele.

    Seus posts demonstram um excelente amadurecimento. Parabéns !!!

    Abs,

    André Nascimento

    André Nascimento

    17/09/2010 at 7:28 pm

  6. Muito bom! As vezes me pego na ditadura do desenvolvimento de software, mas com errros a gente vai aprendendo.

    Parabens, este e o tipo que coisa que precisa realmente ser falada!

    Raphael Molesim

    14/10/2010 at 8:25 am

    • É verdade Raphael, eu mesmo já cometi este erro várias vezes, na ânsia de resolver o problema às vezes acabamos não ouvindo quem mais importa e criando outro problema. Mas reconhecer o erro é o primeiro passo para tentar não cometê-lo novamente!

      ricardofluiz

      18/10/2010 at 7:48 pm

  7. Não concordo com o texto. Concordo mais com o Steve Jobs, quando ele diz que o cliente não sabe o que quer até que vc mostre pra ele o que ele quer.
    No caso da história, se o tempo para se preparar um Blanquette de veau, fosse o mesmo de se preparar um hamburguer, e o cliente não ficasse satisfeito, o que ele deveria fazer é se dirigir para uma lanchonete mais próxima.
    Acredito que se tenho como um dos meus valores fazer as coisas da melhor forma possível, não devo abrir mão disso por causa de um cliente morrendo de fome. Ele pode até não gostar do Blanquette de veau e ir embora, mas se o cheff for mesmo bom, o restaurante não vai lamentar a perda deste cliente.

    André

    05/01/2011 at 3:37 pm

    • Isto funciona bem com desenvolvimento de produtos, no chamado “oceano azul”, onde o número de concorrente é menor e o valor agregado é grande. Se você tiver este tipo de pensamento em uma empresa de desenvolvimento de software (que infelizmente é tratado como commodity e se encontra no “mar vermelho”) sua empresa não sobreviverá por muito tempo. Ao menos eu não conheço nenhuma empresa que vende desenvolvimento de software que tenha durado mais de 5 anos com este pensamento, conheço várias startups que não sobrevivem ao teste do tempo. Você conhece alguma que tenha mais de 5 anos?

      ricardofluiz

      05/01/2011 at 4:26 pm

  8. […] A publicação original você encontra nesta página […]


Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: