Desde que li o Getting Real insisto nisso por aqui.

Mas como é difícil fazer as pessoas entenderem o óbvio…

Você é um fanfarrão.

Se o cliente te pede algo, que vai melhorar quase tudo no site, onde todas as respostas de benefícios é “sim” você quer dizer pra ele “não” ?

Putz, que lógica mais bizarra.

“Nao vou perder meu tempo com isso” == “Isso dá muito trabalho e to com preguiça”.

Fala sério…

Bruno.

Só um adendo ao comentário anterior:

É por isso que o netcarreiras.com é melhor que o carreirasTI.com.

Tomara que aprenda mais uma
Abraços,

Bruno

Não disse?

Bruno, são coisas bem diferentes. Pense bem.

Não vai ser com respostas proféticas sem sentido ou explicação que você irá convencer qualquer pessoa sobre qualquer coisa.

Ao invés de perder tempo fazendo mapinha de cidade, poderia ter implementado os campos a mais, as ordenações melhores, etc e feito a vida de quem publica vagas mais alegre.

O foco é no que dá valor ao cliente, no que é pedido, não no que a gente acha que é importante.

Meh, isso é óbvio demais…

Bom, sempre há o fator gosto.

Eu penso que o NetCarreiras tem uma usabilidade pífia e é complicado demais pra uma pessoa que trabalha com RH e não tem a “manha” que nós temos com sistemas informatizados.

Há também o fato do design incremental. Para o Carlos esses recursos não foram interessantes naquele momento (por prazo, gosto ou qualquer outro fator). Mas isso não quer dizer que seja uma decisão definitiva. Se houver demanda suficiente por uma funcionalidade, é claro que ela deve ser implementada.

É dessa diferença que eu estava falando.

Bruno é tudo muito simples, se você acha que o netcarreiras é melhor, use ele ao invés de usar o carreirati.

Se você acha que deve implementar cada idéia babaca que seu cliente lhe pede, faça assim. Você não é obrigado a concordar comigo em nada, e nem aceitar o que eu digo como uma verdade absoluta e é aí que está a graça.

Só que eu acredito que quando se é bom o bastante, não precisa ter medo de dizer não para o cliente.

Não é uma questão de preguiça, e sim de real necessidade. Eu tenho certeza, por minha experiencia com o meu produto, que se separar em campos o cadastro de ofertas vou complicar mais do que ajudar, e ainda posso tirar a flexibilidade de alguns clientes. Não é porque poucas pessoas me pediram uma funcionalidade que devo correr para implementá-la. A idéia do artigo é que você não deve fazer nada porque é legal e sim porque é útil.

Cara, o programador não pode ser a pessoa que prioriza as historias/requesitos. Isso é responsabilidade do dono do produto. O cara que tem a visão do produto, e sabe (ou deveria saber) qual o retorno que aquilo traz para ele. Se o seu dono do produto não sabe, ai ferrou. Todo mundo começa a mandar em tudo, o desenvolvedor dizendo o que entra ou não entra no produto e o dono do produto dizendo quanto tempo e como será feito tal coisa.

E não podemos confundir simples com simplorio.

Steve Jobs deu uma pequena apresentação sobre o iTunes Music Store para um pessoal de uma gravadora independente. Minha fala favorita nesse dia foi quando as pessoas insistiam em levantar a mão perguntando, "Ele faz [x]?", "Você planeja adicionar [y]?". Finalmente Jobs disse, "Calma, calma - abaixem seus braços. Ouçam: Eu sei que vocês tem milhares de idéias de funcionalidades bacanas para o iTunes. Nós também. Mas não queremos milhares de funcionalidades. Isso seria horrível. Inovação não é dizer sim para tudo. É dizer NÃO para tudo exceto as funcionalidades mais cruciais."
http://www.oreillynet.com/onlamp/blog/2004/08/say_no_by_default.html

É disso que estou falando. Quem vai ousar dizer que o Steve Jobs estava enganado?

Se você trabalha para uma companhia que encara um programador como um simples digitador de código e que não leva em consideração a sua opinião, sinto muito por você. E aceite o meu conselho, saia logo daí, porque com certeza você não tem valor algum para eles.

É claro que seu cliente entende melhor do negócio dele do que você, da mesma forma como você entende melhor de tecnologia do que ele. Muito provavelmente o seu cliente nem sabe exatamente o que ele quer. E um bom programador e/ou designer entende isto e cria exatamente o que o cliente precisa, e não tudo que ele “pensa” que precisa.

Não estou dizendo para brigar com seu cliente, ou se recusar a fazer algo, muito pelo contrário, estou dizendo que qualquer programador pode fazer exatamente do jeito que o cliente pediu, mas os bons não, eles fazem melhor.

Pessoal, há uma boa diferença entre “não fazer nada” e “fazer somente o necessário”.

Leitura recomendada: http://www.37signals.com/svn/archives2/getting_real_forget_feature_requests.php

Carlos,

Você disse: “Seria legal ter campos separados para cada tipo de informação? Seria. O site ficaria bem mais organizado? Sim. Poderíamos criar filtros mais específicos usando estas informações? Seria uma boa.”

O que eu acho:

- O cliente queria algo melhor e você não fez.
- O cliente queria algo de valor para ele e você não fez.
- O site ia ficar melhor, mais organizado e mais coerente, mas você não fez.

Quem prioriza esse tipo de coisa é o cliente e não você. Ele te paga, como você falou, para você fazer o melhor. Mas você não fez.

Enfim, você está errado.

[ ]s, Guilherme

Bom, como já parece que eu estou defendendo o Carlos (estou defendendo a filosofia), lá vai mais um comentário:

Imagine, numa base de 5000 clientes, que você atendesse a cada pedido individual de “um campinho legal”, “um filtro a mais”.

O que essa “filosofia” prega é que uma requisição só deve ser atendida se for pedida constantemente por grande parte dos clientes. É um bom sinal de que algo realmente importante está faltando.

Note que isso se aplica principalmente em software como serviço (SaaS). Em um projeto “tradicional”, isto é, feito sob encomenda, o melhor, na minha opinião, é fazer o que metodologias como XP/Scrum fazem: pedir que o cliente priorize, discutir com ele o que você acha que é importante ou não (sim, sua opinião como especialista em tecnologia também conta) e ir deixando as coisas sem importância para o final. Muitas vezes essas coisas acabam nem mesmo sendo implementadas.

Se a Apple seguisse o pensamento do Guilherme, o iPod hoje seria pior que aqueles players bizarros que a Sony fazia:

“Bem que seria legal botões pra controlar o volume não é? E pra controlar grave e agudo! Pô, porque não um teclado??” É assim que bons produtos vão para o lixo…

Lucas,

1) Não estamos falando da Apple e de milhares de usuários. Não compare repolhos com laranjas. No caso que o Carlos falou havia um e somente um cliente. Se este cliente pediu mais um campo, o Carlos concordou que era bom e não fez, ele está errado! “Keep it simple” é muito bom mas como o José Peleteiro falou não se pode confundir o simples com o simplório.

2) Agora falando sobre o caso da Apple, quando você têm vários clientes/usuários desse jeito você vai ter que ter um “product owner” em algum lugar responsável por filtrar o que os usuários pedem, verificar o que é bom ou ruim e priorizar ou não a implementação. Realmente muitas coisas podem nem ser implementadas e quem decidirá se serão ou não é o product owner. Você pode até dar sua opinião e ela com certeza conta, mas ele é o OWNER e é quem bate o martelo no final.

Com este cenário configurado voltamos ao ponto inicial onde temos apenas um cliente que vai te solicitar uma feature em algum momento. Se o product owner quiser que você faça alguma coisa e você não fizer está errado (ainda mais se você sabe e concorda que é uma coisa boa para o projeto)!

Eu não sei nada de engenharia cívil, mas se eu mandar um pedreiro derrubar uma parede na minha casa e por acaso ele descobrir que existe uma coluna naquele lugar, o que ele deve fazer? Se a casa ruir de quem é a culpa? Quem é o profissional?

No caso que você citou acima, quero te lembrar que o carreiraTI é um projeto meu e eu estou com quase 400 clientes. Três deles me pediram esta alteração, mas e os outros 397? E os futuros clientes? Eles realmente precisam de campos separados, você realmente precisa procurar alguma informação em um campo especifico? Isto implicaria em criar mais uma tela só para pesquisa avançada, vc precisa mesmo disto?

Não fazia o menor sentido criar campos que não seriam usados, criar filtros que nínguem usaria, tanto é que eu não fiz e meus clientes continuam usando o meu sistema e nunca mais me pediram isto, se fosse tão importante eles não teriam pedido denovo?

Não sou dono da verdade. Posso estar errado? Claro!

O ponto é que nem sempre o cliente tem a razão. Quantas vezes você já comprou algo por impulsso e depois se arrependeu? Eu mesmo já fiz isto mais de uma vez.

Quantas vezes você já desenvolveu algo que sequer foi usado depois? Quantas vezes teve de refazer alguma coisa? É aí que está a questão, dizer “Não”, é bom para o cliente, uma nova funcionalidade deve provar o seu valor e sua real necessidade. Se algo for realmente importante para o seu cliente, ou para o negócio, você vai sentir isso, porque o seu cliente vai lhe lembrar a todo instante da importância daquilo.

Mas a funcionalidade que seu cliente “acha” legal, se você “deixar para depois”, muito provavelmente ela será esquecida e vai se provar não tão importante.

Apenas para finalizar o comentário acima:

Eu em momento algum disse que nós devemos dizer: “Isto não é importante” para tudo, o que devemos fazer é analisar antes e não ter medo de dizer se REALMENTE não for importante.

Guilherme, só vi o seu último comentário agora. Talvez seja este o motivo da discussão, estamos falando em contextos diferentes.

Todos os meus comentários e o próprio post é pensando no meu software e na minha empresa, onde eu tenho poder de decisão e o que eu espero de um programador que trabalhe para mim.

Acho que está explicado. Pelo seu post o que parecia era que você estava trabalhando para uma só empresa.

Eu estava falando de maçãs e você de bola de futebol.

Agora sim, acabou o ruído.

Guilherme, concordo com seu ponto de vista também, em casos de projetos de outros tipos. Estávamos em contextos diferentes mesmo.

Lembrando que toda a “teoria” divulgada pela 37signals baseia-se na experiência deles com SaaS, como o Basecamp e Highrise, categoria na qual se enquada o CarreiraTI, do Carlos.

Olá Carlos,
post e discussão muito interessantes,
legal mesmo…
Estou iniciando na área por isso não tenho muito o que falar… mas ver os vários pontos de vista é muito interessante pra quem está começando…
Legal, parabéns…

É assim mesmo Fausto, nesta profissão cada um tem seu ponto de vista, e o melhor é que nínguem tem medo de se expressar, então de vez em quando, temos algumas discussões mesmo!

Mas são saudáveis como você pode ver acima…

[...] eu havia lido este artigo publicado pelo Carlos Brando em seu blog sobre Ruby on Rails, o qual fez-me parar e analisar os [...]