Seções iMasters
Agile + Carreira + Desenvolvimento + Gerência de Projetos

Não à ditadura do desenvolvimento

Saudações, pessoal!

Como sabem, sou da área de desenvolvimento de software, mas neste artigo 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 o 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 seu pedido, diz que fica pronto em 10
minutos e vai para a cozinha.

Mas, quando o Chef começa a pegar os ingredientes, pensa: “não! Ele não vai querer
um hamburguer! Ninguém mais está comendo esse tipo de comida hoje em
dia! É comprovado que faz mal a saúde a longo prazo! Ele quer satisfazer
a fome, eu entendi isso 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 o chef voltar
para a cozinha e fazer o hamburguer que havia pedido.

O chef, perplexo, argumenta: “Não é possível! Este prato é bem melhor e 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 seu hamburguer.

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

Você pode pensar, “eu sou de TI, portanto sei o melhor para o meu
cliente”, assim como o chef da minha estória pensou. Porém, tenho a mesma opinião
expressada por Kent Beck no livro “Programação Extrema Explicada”, no
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 em 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 em nível de negócios quanto no nível técnico. Se um
consumidor me diz que quer um sistema e que eu devo usar o banco de dados relacional XDB e uma 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 tenho que fazer 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 ainda assim o cliente quiser 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 o seu mercado, vai
satisfazer seu cliente e, quem sabe, fazê-lo voltar outro dia para
apreciar o Blanquette de veau.

Mensagem do anunciante:

Torne-se um Parceiro de Software Intel®. Filie-se ao Intel® Developer Zone. Intel®Developer Zone

Comente também

6 Comentários

Depende do cliente, muitos não estão interessados nesses “detalhes”.
E, outra coisa, ao meu ver esse paralelismo não vingou, pois, na estória do chef, C++ não seria o hamburguer mas sim a chapa em que este será assado.
Porém, realmente, as vezes é interessante o cliente estar a par das tecnologias usadas e não só do produto final.

    Jonas Ribeiro

    Guilherme,
    na estória do chef o hamburger é o xdb com ide java.
    Um bd orientado a objetos e C++ é o Blanquette de veau.

    O paralelismo ao meu ver, vingou.

    Leitura e compreensão fáceis, além de um curto texto. Parabéns Ricardo!

A experiência acaba nos fazendo incrementar ao problema do cliente várias possibilidades. Em geral, oferecer ao cliente uma possibilidade que ele não pensou é um diferencial.
Apresentar a solução ao cliente e discutir, antes de partir para o desenvolvimento, é sempre a melhor solução.
Em disciplinas de gerenciamento de projeto, chamam de escopo bem definido.

Porém, complementando o texto, ainda que seja somente um hamburguer, faça o melhor hamburguer.

Camilo Lopes

opa fernando, achei muito bom seu post e a ideia que passou. Realmente é comum esse problema e tenho visto isso nos ultimos anos bem frequente, a questão do nosso lado técnico é que a maioria do profissionais de TI, nao entendem de negocio como deveria e sempre vai para o lado de tendencias tecnicas e isso pode atrapalhar a relacao com o cliente, para nós que respiramos é facil ver que Blanquette de veau é melhor que o hamburguer, mas para o cliente nao passa de uma refeição. decisões como a do chef eu só tomaria qdo houvesse espaço e tempo suficiente para discutir q X é melhor q Y, do contrario seria o que o cliente pediu e trabalho done.
parabens!

DCG

Muitas vezes o cliente não tem noção da sua necessidade, não tem definido o seu processo de trabalho e não possui controle a cerca de mudanças (fatores externos, politicos, legais, financeiros e etc).
Na teoria é tudo muito bonito e fácil, mas conside algo agravante: MUDANÇAS.
Sou responsável por uma área técnica, e muitas vezes a necessidade chega de forma mascarada, tenho limitações para atingir o público-alvo do sistema (burocracias e fatores politicos), problemas de orçamento e até falta de recursos humanos disponíveis.
De quem é a culpa ? Da equipe de negócios ? Do cliente ? Da equipe de Requisitos ? Da equipe técnica ?
Acredito que cada uma das partes interessadas tenha a sua parcela de responsabilidade, e o trabalho deveria ser focado em PARCERIA, porque na prática parece que é um campo de batalha, o produto final certamente é comprometido, e cada um fica tirando o seu da reta.
Podem criar inúmeros livros a cerca de metodologias de desenvolvimento, framework de trabalho próximos a perfeição que contemplam inúmeras arquiteturas, mas, enquanto existir essa barreira entre a teoria e a prática … o hamburger solicitado pode ser entregue ao cliente como uma bolacha de agua e sal.
Parabéns pela matéria, mas esse assunto vai muito além do que foi exemplificado.
Abraços.

    Ricardo Fernandes Luiz

    Olá DCG, obrigado pela contribuição!
    Com certeza há muitos assuntos a tratar no cenário complexo que é o desenvolvimento de software, mas o foco deste artigo é enfatizar que a comunicação deve ser um via dupla.
    Sobre mudanças, isto não se trata de um agravante, mas de uma certeza, sempre existirão mudanças. A questão é deixar claro logo no início como serão tratadas e ter feedback rápido para validar se o que está sendo construído está a gosto do consumidor.

Qual a sua opinião?