O cliente tá certo?

Por Cesar Brod

Data de Publicação: 17 de Março de 2009

Muitos já sabem que a BrodTec, sob contrato da editora Campus-Elsevier, está traduzindo para o português o clássico livro The Mythical Man Month, do Fred Brooks, Jr.. O livro de Fred é tido, como muitos, como o pontapé inicial para o desenvolvimento de metodologias ágeis. Eu mesmo já falei sobre ele em vários de meus artigos.

Traduzir um livro é muito diferente do que simplesmente lê-lo. Especialmente no caso do "The Mythical Man Month", com o qual tenho uma relação de longa data. Comprei o primeiro exemplar em 1988, em minha primeira visita aos Estados Unidos. Gostei tanto do livro que emprestei-o para muita gente. Alguém não devolveu -- não sei quem, até hoje! Em 1995 foi lançada uma edição de aniversário, da qual só fui saber em 2003, em um seminário de desenvolvimento de software livre que fizemos na Unicamp, onde a livraria Tempo Real tinha um estande. Eu não tinha dinheiro para comprar a nova edição, mas fiquei devendo para o André Wolff, então sócio da empresa, e comprei mesmo assim. Acho que levei dois anos para pagá-lo, mas paguei pelo preço de capa, e não pelo preço já com desconto. O André sabia da minha relação de carinho com o livro e, hoje, como editor da Campus-Elsevier, convidou-me para traduzi-lo. Para saber mais, esperem o livro chegar nas livrarias! ;)

Mas, como um teaser nunca é demais, lá vai um parágrafo do capítulo "Não Existe Bala de Prata":

"(...) a função mais importante que os construtores de software exercem, para seus clientes, é a extração iterativa e o refinamento dos requerimentos do produto. Mas, verdade seja dita, os clientes não sabem o que querem. Eles normalmente não sabem quais perguntas devem ser respondidas e quase nunca pensaram detalhadamente sobre o problema que deve ser especificado. Mesmo a simples resposta - 'Faça o novo sistema de software funcionar como o nosso antigo sistema manual de processamento de informações' - é , de fato, simples demais. Os clientes nunca querem exatamente isto. Sistemas complexos de software são, mais do que isso, algo que age, que se movimenta, que trabalha. As dinâmicas desta ação são difíceis de se imaginar. Assim, ao planejar qualquer atividade de software, é necessário permitir uma iteração extensiva entre o cliente e o projetista como parte da definição do sistema."

O cliente pode não saber exatamente como se expressar, mas sabe exatamente o que quer. Em uma relação com seu fornecedor de sistemas, o que mais se presta à criação de uma linguagem comum entre ambos é o protótipo. Quanto mais prematuro este protótipo, melhor. Para começar, um protótipo de papel (com o qual o cliente e o desenvolvedor podem exercitar a interação possível em um programa real) pode ser o ideal. Exemplos de tela em um programa de apresentação, como o Impress do BR-Office, também ajudam. Kris Jordan dá boas dicas em seu artigo 10 Minute Mock Prototyping, usando o PowerPoint como base -- estas dicas podem muito bem ser adequadas a outros programas de apresentação.

Na maior parte das vezes, um cliente que está descontente com um determinado sistema é o melhor cúmplice e colaborador no desenvolvimento de um novo. Ele espera a mesma cumplicidade e colaboração do desenvolvedor, mas será tão mais compreensivo com o processo de desenvolvimento quanto mais sentir-se envolvido com ele. Isto não quer dizer que o cliente queira estar envolvido em cada aspecto da programação em PHP, JavaScript ou HTML de seu portal. O que ele quer é saber, em uma linguagem humana, sobre o que pode esperar e quando.

Veja a relação completa dos artigos de Cesar Brod


PDF	RSS	Imprimir

Currently 3.32/5
1
2
3
4
5

Avaliação: 3.3 /5 (93 votos)

Opinião dos Leitores

Lincoln Zuljewic Silva
10 Jun 2009, 17:08

Henry Ford disse uma vez "Se eu tivesse perguntado aos meus clientes o que eles queriam, eles teriam dito 'Nós queremos cavalos mais velozes'".

Imaginem se ele tivesse escutado os clientes?!

João Barbosa
03 Jun 2009, 10:26

Concordando com Mabs e complementando, eu diria que todos os desenvolvedores devem ter conhecimentos de UML por forma a poderem comunicar de formar perceptiva com o cliente. Incluir o cliente como peça fundamental no projeto de desenvolvimento, não só no início do projeto com os requisitos mas, durante todas as fases do projeto...

Daniel Lago
21 Abr 2009, 12:44

* o que o cliente quer: um carro que anda a 300 Km/h
> o que a Engenharia sugere: um Porsche
* quanto o cliente quer gastar: o preço de um Fusca 86
> o que Vendas oferece: uma réplica de Porsche em fibra de vidro com motor de fusca
* o cliente aceita, depois reclama, pois até o Golf usado dele é melhor
> a Engenharia tem que turbinar o motor de Fusca da réplica, com uma turbina usada pois não tinha dinheiro para isso no projeto

faltou o comentário do que faz a equipe de manutenção quando a "réplica" do Porsche (obviamente) falhar

Téo
19 Mar 2009, 10:10

Bah César, que sacanagem!
Te falei que o livro ainda está comigo - e muito bem cuidado por sinal! - já fazem algumas semanas, numa de nossas 'reuniões' no BierDog... Porém sei que caipirinhas e cervejas o efeito de 'filtrar' lembranças, então tá desculpado! Prá te devolver ele refaço o antigo convite do churras lá em casa, assim podes dar uma atenção prá afilhada que até já tá reclamando de saudades! Abraços

Cesar Brod
17 Mar 2009, 18:48

Mabs, perfeita a sugestão! Devidamente acatada! Obrigado mesmo!

Samuel
17 Mar 2009, 17:00

Por favor pessoal da campus-elsevier, traduzam a 6º edição do Hackers Expostos!

_
17 Mar 2009, 16:53

Mabs
17 Mar 2009, 15:06

requerimentos não é a melhor tradução, nesse contexto.
Sugiro, humildemente, que se traduza requeriments como requisitos.
Há a Engenharia de requisitos, inclusive, muito importante para a especificação de projetos ou para a especificação do produto.

*Nome:
Email:
	Me notifique sobre novos comentários nessa página Oculte meu email
*Texto:

	Para publicar seu comentário, digite o código contido na imagem acima