O problema da linguagem em nosso ramo: buscando novas metáforas

Muito bom!

Vale mto a pena a leitura!

post bem escrito, gostei, inclusive respondi lá.

Grande post, é incrível como você consegue juntar programação e conceitos filosóficos tão bem!

E realmente, o que as grandes empresas sempre procuraram foi especializar e mecanizar todos os processos o máximo possível, pra justamente ganhar em produtividade e deixar o trabalhador “manso”…

Mas em software cada caso é um caso, e é aí que acontecem os pepinos. O gestor ensina a ser robô, e passa um serviço que exige raciocínio. O desenvolvedor trabalha como foi treinado, e no final das contas paga o pato…

Bacana que tenham gostado, mas na opinião de vocês, quais metáforas poderíam entrar no lugar da que descrevo no post?

Algum tempo atrás li um livro chamado “Hackers and Painters”, do Paul Graham sobre o assunto. Nele é usada a metáfora do pintor que, assim como o desenvolvedor, vai criando seu software a partir do processo de tentativas sucessivas até que se chegue ao ponto em que tenha atingido o objetivo final. Acho que é algo mais neste caminho.

Na minha opinião, talvez alguma aproximação com o ambiente literário também é válida, porque o que fazemos, assim como na literatura, é imaterial, intelectual e não se encaixa em uma linha de montagem.

Ótimo post.

Desculpe ainda não poder participar da discussão. Li o post rapidamente e achei muito interessante. Portanto, vou ler novamente em casa e com certeza darei um feedback.

Abç.

kicolobo:

Bacana que tenham gostado, mas na opinião de vocês, quais metáforas poderíam entrar no lugar da que descrevo no post?

Algum tempo atrás li um livro chamado “Hackers and Painters”, do Paul Graham sobre o assunto. Nele é usada a metáfora do pintor que, assim como o desenvolvedor, vai criando seu software a partir do processo de tentativas sucessivas até que se chegue ao ponto em que tenha atingido o objetivo final. Acho que é algo mais neste caminho.

Na minha opinião, talvez alguma aproximação com o ambiente literário também é válida, porque o que fazemos, assim como na literatura, é imaterial, intelectual e não se encaixa em uma linha de montagem.

A questão de artesanato que você também colocou no post pra mim é a que mais se encaixa com a realidade do desenvolvedor…

Tanto no artesanato como no desenvolvimento, mesmo que você o mesmo “produto” 2 vezes, eles vão ter lá suas diferenças, pois geralmente existem meios diferentes pra se chegar ao mesmo fim…

Eu por exemplo já notei isso na prática. Já fiz 3 vezes o mesmo programa para o mesmo fim(um trabalhinho de curso), e a cada vez que fazia achava um modo diferente e mais adequado à situação para chegar ao mesmo fim…

É interessante isso, e realmente não se assemelha nem de longe a processos industriais…

Olá. Parabéns pelo artigo.
Vou dar uma de advogado do diabo, mas de qualquer forma achei ele válido.

Na verdade todos esses problemas já são bem conhecidos nas empresas e por boa parte dos gerentes de TI. A questão é que não existe solução (Não existe, ou até hoje ninguém encontrou, a famosa bala de prata). Não acredito que o problema principal seja a linguagem, mas a nossa incapacidade de dar uma solução definitiva para o problema do desenvolvimento de software.
A comparação com o artesanato é interessante se a gente pensar um pouco nessa analogia.
basta observar que a produção artesanal não é mais a responsável por sustentar as necessidades do mercado. Durante um tempo ela foi suficiente, mas hoje em dia é preciso produzir em uma escala muito maior. A produção artesanal jamais daria conta de atender o mercado atual. A mesma coisa acontece com desenvolvimento de software. Desenvolver software de forma análoga à produção artesanal já não atende ao que o mercado precisa.
O P.F. é uma tentativa de atender uma necessidade do mercado. Infelizmente ele é uma grande mentira, mas é uma mentira que todo mundo aceita e que ninguém ousa questionar.
Alguns vao dizer que o problema na verdade é o modo que ele é usado, que no fim ele é só mais uma métrica, determinar o tamanho funcional do software e etc. Isso tudo é verdade. Mas ainda assim ele vai continuar sendo usado para estimar o esforço necessário para o desenvolvimento. A generalização aqui é matematicamente comprovada por metodos estatisticos. É muito complicado argumentar contra provas matemática. O problema é que todos temos a sensação de que ou tem algum erro na equação ou que então na matemática do desenvolvimento de software 1 + 1 não é 2. Ele definitivamente não é capaz de estimar o esforço necessário para produzir um software e mesmo uma generalizando matematicamente fundamentada é tão confiável quanto um chute qualquer. Mas isso é o mais próximo de alguma certeza que podemos fornecer ao mercado. Infelizmente é essa minha conclusão.

Oi immortalSoul, legal que gostou, valeu.
E muito obrigado por dar uma de advogado do diabo, porque assim a gente da uma apimentada na discussão!

sabe, ai que tá: a visão que temos de um assunto é muito influenciada pelo vocabulário que usamos quando vamos descrevê-la.
No caso, é importante lembrar que quando você usa uma metáfora baseada em artesanato, não quer dizer que vai ser artesanato, mas sim vai ter características dele.

Na minha opinião, é um passo no bom caminho sim, porque é aplicada em uma área muito próxima a nossa, a literária, com relativo grau de sucesso e, ao mesmo tempo, mantendo as características que todo negócio deve ter: prazo, custo, etc.

Fala Henrique,

achei muito interessante a sua linha de raciocínio. Sinceramente, não sei se buscar novas metáforas seja o ideal, justamente porque elas podem nos levar novos erros e desentendimentos.

Se pensarmos nos tempos “pré-Engenharia de Software”, os programas, e até o hardware eram construídos sob medida para resolver problemas muito específicos (se eu não me engano, o ENIAC foi montado para cálculos de balística). Boa parte da pesquisa do meu ex-orientador por exemplo, era desenvolver soluções numéricas para equações ordinárias cujas soluções analíticas eram muito difíceis. Enfim, percebemos nestes casos que não há necessidade alguma de metáforas para descrever esse trabalho de pesquisa, muito pelo contrário. Programação e algoritmos são tidos como mais um conjunto de ferramentas com características únicas, que funcionam melhor em alguns contextos e não tão bem em outros.

Bom, é claro que desenvolver software para o mercado e para o meio acadêmico tem suas diferenças, mas elas estão muito mais relacionadas a questões como escopo, entrega de valor, prazos e etc. do que nas técnicas propriamente ditas, ou seja, no fim das contas, é tudo programação. Na minha opinião, o primeiro passo seria abandonar as metáforas de uma vez por todas e olhar para a nossa profissão como uma atividade única e começar a enumerar suas características e propriedades, assim como seus problemas. O passo seguinte, seria fazer uma análise da atividade de desenvolvimento dentro de cada contexto específico, e assim por diante.

immortalSoul:

Olá. Parabéns pelo artigo.
Vou dar uma de advogado do diabo, mas de qualquer forma achei ele válido.

Na verdade todos esses problemas já são bem conhecidos nas empresas e por boa parte dos gerentes de TI. A questão é que não existe solução (Não existe, ou até hoje ninguém encontrou, a famosa bala de prata). Não acredito que o problema principal seja a linguagem, mas a nossa incapacidade de dar uma solução definitiva para o problema do desenvolvimento de software.

O que está sendo perdido desse movimento é o porque ele existe. Há um foco enorme nas técnicas e práticas e tem se deixado de lado os princípios. E nisso essa boa parte dos gerentes de TI tem contribuído bastante para o erro. “Pra ser agil tem que ter sprint de uma ou duas semanas”. Não! Pra ser ágil tem que ter feedback rápido, uma, duas ou quatro semanas depende de uma série de coisas, como complexidade das funcionalidades, numero de equipes envolvidas, disponibilidade do cliente/analista de negócios.

Se eu tenho contato diario com meu cliente eu não preciso de uma sprint, eu posso validar cada funcionalidade no instante em que estiver pronta.

Esse é só um exemplo de como as coisas podem ser distorcidas. O mesmo acontece em várias outras práticas ditas ágeis, como pair programming, integração continua, testes, planejamento.

Há um foco grande na prática e não nos princípios. E acaba se cometendo os mesmos erros, só com nomes diferentes. Por isso para muitos as coisas continuam não dando certo.

Ponto de vista interessante. Já tinha ouvido falar da comparação entre criação de software e artesanato e não me agradou muito. Talvez seja esse mesmo o ponto. Eu não gostei muito dessa metáfora porque artesanato normalmente não é coisa que se faz em equipe e quando se envolve uma equipe essa comparação perde força.

O fato de muitos aceitarem não faz com que seja menos mentira. E talvez este seja o ponto que me leva a minha metáfora preferida. Algo que se faz em equipe e que não se estima nada e há milhares de anos tem dado certo.

Fazer software é como produzir uma peça teatral. Você tem um texto que deve ser seguido, todos o conhecem e discutem sobre ele. Todo mundo vê o todo e vendo o todo cada um faz sua parte. Há o diretor que procura manter a “big picture” da leitura que ele quer do texto. Há os atores, talentosos, que usam da sua criatividade para dar vida aos personagens sem fugir muito da visão do diretor. Há os cenógrafos, maquiadores, figurinistas que entendem o contexto pra chegarem ao resultado final.

E o melhor de tudo, o prazo já vem dado. A estréia é no dia tal e naquele dia tudo deve estar pronto. E mesmo assim a peça irá evoluir durante a temporada, a medida que os atores forem entendendo melhor a reação do público, colocando e retirando uma palavra aqui e ali.

Acho que esse é o contexto que melhor se encaixa com desenvolvimento de software. Não que sejamos artistas, embora existam as divas entre nós, mas o processo de evolução do produto é parecido com o teatro.

Grande kicoloco! Bom artigo! Meus comentários, sendo objetivo:

1. O cara que respondeu: “Ah, é um negócio que eu uso pra definir as propriedades dos meus beans.” ou não tem curiosidade para descobrir como as coisas funcionam realmente ou teve acesso a uma documentação tosca ou ambos. Uma coisa que eu sempre defendi é que documentação (português ou inglês) é tão ou mais importante que o código fonte (Java ou Ruby). Então seja lá onde ele leu sobre Spring, e ainda bem que não foi o seu livro, a explicação deve ter sido muito ruim.

2. Prática é mais importante que Teoria na minha opinião, porque com muita prática vc acaba deduzindo a teoria. Só teoria com nenhuma prática não te leva a lugar nenhum, por isso que vc deve focar mais na prática. Mas isso não quer dizer que teoria não seja importante. O cara que começa a trabalhar com Spring sem saber o que é Inversion of Control vai se enrolar.

Aí que entra o importante papel do “explicador”, do cara que escreve a documentação do framework ou um livro. Tem que explicar direito, se não ferrou.

Vou tentar (não é fácil) explicar o que é IoC em 3 linhas ao invés de usar um livro. Para quem quiser ver a prática da teoria de uma maneira bem leve e simples pode dar uma lida aqui tb: http://mentacontainer.soliveirajr.com

Sem IoC vc espalha detalhes da implementação pelo código inteiro, pois toda vez que vc faz isso:

UserDAO userDAO = new JdbcUserDAO(conn);

vc chapou (hardcodeou) que vc quer utilizar a implementação JdbcUserDAO para o seu contrato UserDAO. Vc criou uma instância de uma classe concreta na mão via new.

Com inversão de controle, ao invés de espalhar isso pelo seu código inteiro, vc usa um container de IoC (Spring, Guice, Pico, MentaContainer, etc) para CENTRALIZAR essas informação num lugar só e inverter o controle sobre as instâncias. Agora quem cria as instâncias não é vc, mas o container de IoC e injeta elas onde elas forem necessárias. Então o código acima com o MentaContainer ficaria assim:

MentaContainer container = new MentaContainer(); // esse cara vai ser compartilhado globalmente pela aplicação
container.ioc(UserDAO.class, JdbcUserDAO.class); // esse cara vai ser feito num lugar centralizado quando a aplicação for iniciada
UserDAO userDAO = container.get(UserDAO.class); // agora é assim que vc pega a instancia do seu UserDAO, ou seja, o controle foi invertido!

E aí por tabela entra Injeção de Dependência, mas aí a coisa começa a se alongar muito, acho que a explicação acima é o mínimo que o cara tem que entender e bem.

Agora vc que está escrevendo um livro sobre isso, Kico, me fala onde essa explicação pode ser melhorada e se ela contem algum erro e dá ela para o cara lá que não sabe o que é IoC ler para ver se agora ele entende.

Oi Saoj, legal que tenha gostado.

Ai que tá: eu acredito que a metáfora da fábrica gera um efeito destruidor no profissional que está começando a sua carreira neste tipo de ambiente.
Minha visão é a de que a tentativa de se trazer a linha de montagem para o ambiente de desenvolvimento gera uma pressão tão grande por produtividade no indivíduo que ele acaba se transformando nisto que você falou: um preguiçoso. Hegel usa um termo muito bacana pra isto: “preguiça do conceito”, aquele negócio do indivíduo não querer saber o “quê” da coisa, mas somente o “como”, e rápido.

Dado que a pressão para a produção é grande, nós começamos a ver algumas coisas muito sinistras ocorrendo:

• A diminuição do papel do programador, que passa a ser visto como pião (e surge o papel artificial do arquiteto, que na prática acaba sendo um programador mais experiente)
• A diminuição da própria vontade de se aprofundar nos assuntos porque o ambiente é estafante.

O que observo é que neste tipo de contexto, você transforma fácil um indivíduo curioso, com vontade de aprender em um desmotivado completo que, ao dar a hora de ir pra casa, a últiam coisa que quer fazer é saber do trabalho e coisas relacionadas.

Meu medo é justamente esta alienação do ato de pensar que menciono no post. Por isto é importante novas metáforas, para que as ruins sumam, impressões cretinas como a que descrevo diminuam e, com elas, nossa área tenha um comportamento mais humano, que é o que deveria ter desde sempre, saca?

Acho que a solução tem que partir da gente. O cliente quer porque quer, o patrão cobra, então vc tem porque tem que fazer. Não adianta explicar que produzir software de qualidade requer tempo, mas que vai gerar menos custo de manutenção e blá blá blá.

Eu tenho uma política de não aceitar nada “para ontem”. Sou autônomo, mas isso quer dizer que posso me dar a esse luxo? Eu acho que não é luxo, e sim necessidade. Necessidade de recusar serviço! Explico porquê.

Esses dias um cliente meu começou a dar uma pressionada de leve. Sabe quando ele sorri e fala “então vai dar pra terminar até segunda”? Eu tive que mudar o tom, lembrá-lo do prazo que eu pedi para fazer o serviço e disse que se ele contasse mesmo com isso, era melhor esquecer. Apenas 2 semanas, programa pequeno mas que deu um certo trabalho - imagine integrar um sistema Clipper legado com uma aplicação de coleta de dados para ser acessada em campo através de iPad. Isso cai naquilo que o Kico falou no blog dele: Qualidade requer tempo para se obter o conhecimento a respeito da essência do problema, ou seja, para entender com o quê estamos lidando.

O cliente ficou meio sem graça, mas eu tinha achado a atitude dele tão abusada (e isso é muito comum) que eu dei a cara a tapa mesmo, arrisquei perder o serviço.

Existe uma armadilha nas relações humanas, e essa armadilha é mais forte na questão do trabalho:

• quem tem o $$$$ decide
• quem quer ganhar o $$$$ aceita as condições que o outro impõe, sob pena de perder serviço, ficar de filme queimado, ser demitido no caso de não-autônomos

Nos últimos tempos venho me questionando: eu estou precisando do $$$ do cliente X? Por “precisar” entenda-se não estar passando necessidade, mas sim no sentido de que todos precisamos de grana e é desenvolvendo software que eu ganho a vida.

Se os desenvolvedores resolvessem recusar fazer milagres, aí sim viraríamos o jogo. Uma quantidade assombrosa de serviços seriam recusados pelos autônomos, e outra massa de gente iria pedir as contas/ser demitida. Já pensou faltar mão de obra para fazer software? Agora juntando as peças: acredito que é dessa forma que eles (os que nos solicitam os serviços) ouvirão o que nós falamos. Quando nós fizermos falta, deixaremos de ser “fábrica de software” e poderemos de verdade colocar para o mundo todos os argumentos que foram discutidos neste tópico.

Pode parecer um tanto radical, mas a nossa área é extremamente incompreendida. Da mesma forma que eu preciso de grana, eles precisam do meu serviço. Quem quer muito ganhar o bem do outro é o mais frágil da relação; quem se dispõe a recusar o negócio é o lado mais forte.

YvGa:

immortalSoul:

Olá. Parabéns pelo artigo.
Vou dar uma de advogado do diabo, mas de qualquer forma achei ele válido.

Na verdade todos esses problemas já são bem conhecidos nas empresas e por boa parte dos gerentes de TI. A questão é que não existe solução (Não existe, ou até hoje ninguém encontrou, a famosa bala de prata). Não acredito que o problema principal seja a linguagem, mas a nossa incapacidade de dar uma solução definitiva para o problema do desenvolvimento de software.

Eu acho que a solução existe sim e está aí, mas ela não é tão simples como muita gente espera. Ok, não é a bala de prata que cobrirá todos os problemas. Mas os mais comuns ela tem amenizado e alguns até eliminado. O movimento ágil é uma revolução dentro da industria do software.

O que está sendo perdido desse movimento é o porque ele existe. Há um foco enorme nas técnicas e práticas e tem se deixado de lado os princípios. E nisso essa boa parte dos gerentes de TI tem contribuído bastante para o erro. “Pra ser agil tem que ter sprint de uma ou duas semanas”. Não! Pra ser ágil tem que ter feedback rápido, uma, duas ou quatro semanas depende de uma série de coisas, como complexidade das funcionalidades, numero de equipes envolvidas, disponibilidade do cliente/analista de negócios.

Se eu tenho contato diario com meu cliente eu não preciso de uma sprint, eu posso validar cada funcionalidade no instante em que estiver pronta.

Esse é só um exemplo de como as coisas podem ser distorcidas. O mesmo acontece em várias outras práticas ditas ágeis, como pair programming, integração continua, testes, planejamento.

Há um foco grande na prática e não nos princípios. E acaba se cometendo os mesmos erros, só com nomes diferentes. Por isso para muitos as coisas continuam não dando certo.

Ponto de vista interessante. Já tinha ouvido falar da comparação entre criação de software e artesanato e não me agradou muito. Talvez seja esse mesmo o ponto. Eu não gostei muito dessa metáfora porque artesanato normalmente não é coisa que se faz em equipe e quando se envolve uma equipe essa comparação perde força.

O fato de muitos aceitarem não faz com que seja menos mentira. E talvez este seja o ponto que me leva a minha metáfora preferida. Algo que se faz em equipe e que não se estima nada e há milhares de anos tem dado certo.

Fazer software é como produzir uma peça teatral. Você tem um texto que deve ser seguido, todos o conhecem e discutem sobre ele. Todo mundo vê o todo e vendo o todo cada um faz sua parte. Há o diretor que procura manter a “big picture” da leitura que ele quer do texto. Há os atores, talentosos, que usam da sua criatividade para dar vida aos personagens sem fugir muito da visão do diretor. Há os cenógrafos, maquiadores, figurinistas que entendem o contexto pra chegarem ao resultado final.

E o melhor de tudo, o prazo já vem dado. A estréia é no dia tal e naquele dia tudo deve estar pronto. E mesmo assim a peça irá evoluir durante a temporada, a medida que os atores forem entendendo melhor a reação do público, colocando e retirando uma palavra aqui e ali.

Acho que esse é o contexto que melhor se encaixa com desenvolvimento de software. Não que sejamos artistas, embora existam as divas entre nós, mas o processo de evolução do produto é parecido com o teatro.

Em primeiro lugar, gostei da analogia com o teatro. A principio acho que poderia ser observada pra começar a pensar em uma solução para o problema causado pela linguagem, conforme alertado pelo KicoLobo.

Quanto ao movimento agil, conheço de ouvir falar (apesar de não ter tido a oportunidade de trabalhar com ele) e concordo que ele é o melhor que temos para grande parte do desenvolvimento de software.
Mas lembre-se que o que falei é que não temos a solução definitiva. Infelizmente existe uma série de barreiras que impende um alcance mais amplo deste movimento.
Creio que o maior problema é o fato das empresas não aceitarem que o desenvolvimento de softawre não é uma atividade ‘deterministica’. Boa parte do mercado não nestá preparado para aceitar isso e não sei se um dia vai estar.

MarkKnopfler:

Pode parecer um tanto radical, mas a nossa área é extremamente incompreendida. Da mesma forma que eu preciso de grana, eles precisam do meu serviço. Quem quer muito ganhar o bem do outro é o mais frágil da relação; quem se dispõe a recusar o negócio é o lado mais forte.

Concordo plenamente com voce. É uma visao dificil de por em pratica, principalmente pra quem é pequeno, mas é necessaria.

Mas a de se ter cuidado com essa frase do kiko:

Sim, qualidade requer tempo, mas deve se tomar cuidado com o ficar procrastinando em cima do papel e não fazer nada com a desculpa da busca da qualidade. Só se entende o problema de fato com algo concreto para ser demonstrado, não com discussões vagas, desenhos, reuniões. Um protótipo de tela feito em 10 minutos vale mais do que horas de reunião. Uma implementação rápida, de uma hora, de uma funcionalidade chave para ser discutida com o cliente vale muito mais do que toneladas de requisitos assinados e acordados.

Eu não tenho essa aversão a palavra produtividade como o kiko, eu tenho aversão a forma como ela é medida.

Esse fazer de qualquer jeito não traz produtividade, na verdade diminui. Eu sempre digo a tal “fase de manutenção”, quando haverá o ganho, começa bem antes do sistema em produção. Ou seja, tudo que for feito de qualquer jeito cobrará seu preço bem antes do que muita gente julga. E atrasará, ao invés, de acelerar a entrega do produto.

Os melhores programadores que eu conheci eram os mais produtivos. Eles invariavelmente eram mais rápidos e produziam com mais qualidade que os outros. Porque sabiam escrever código de qualidade que não os atrasava.

Resumindo: sempre que me falam em produtividade eu pergunto: Como você mede isso? Exatamente?

Sem chance do mercado aceitar isso. Mas talvez o melhor caminho seja mesmo o que o rmendes falou. Vamos esquecer as metáforas e construir nossa própria forma de trabalhar.

Oi YvGa,

eu não tenho aversão à produtividade: tenho aversão à visão aplicada sobre o assunto. (seria contra-senso ter aversão a uma qualidade)

Com relação à criação de novas metáforas ou cair na prática, acho interessante partir pra primeira.
Tudo bem que a teoria surge a partir da prática e blá blá blá, mas ao mesmo tempo, a imagem que passamos aos nossos clientes de nós mesmos é profundamente influenciada pelos termos que usamos para descrever nosso trabalho, entende?

O interessante é que a questão da linguagem é na realidade epistemológica, está diretamente relacionada à nossa maneira como percebemos o mundo e, consequêntemente, interagimos com ele.
Sendo assim, é um ponto básico que está sendo subvertido e precisa ser corrigido o quanto antes, de preferência a partir de agora enquanto nossa área é nova e ainda dá tempo de evitar a cristalização total destas metáforas ruins que mencionei acima.

YvGa:

Fazer software é como produzir uma peça teatral. Você tem um texto que deve ser seguido, todos o conhecem e discutem sobre ele. Todo mundo vê o todo e vendo o todo cada um faz sua parte. Há o diretor que procura manter a “big picture” da leitura que ele quer do texto. Há os atores, talentosos, que usam da sua criatividade para dar vida aos personagens sem fugir muito da visão do diretor. Há os cenógrafos, maquiadores, figurinistas que entendem o contexto pra chegarem ao resultado final.

E o melhor de tudo, o prazo já vem dado. A estréia é no dia tal e naquele dia tudo deve estar pronto. E mesmo assim a peça irá evoluir durante a temporada, a medida que os atores forem entendendo melhor a reação do público, colocando e retirando uma palavra aqui e ali.

Acho que esse é o contexto que melhor se encaixa com desenvolvimento de software. Não que sejamos artistas, embora existam as divas entre nós, mas o processo de evolução do produto é parecido com o teatro.

Dos projetos de software que participei, o fato de que a “peça vai ao ar” porque chegou o dia da “estréia” e não porque o produto ficou pronto, é a principal causa de equipe frustrada e usuários insatisfeitos.

Ainda assim acredito que a analogia entre teatro e artesanato é apta porque salienta um problema real: a falta de especificações detalhadas sobre o produto, o que ele deve fazer e principalmente, o que significa estar pronto.

Em áreas mais tradicionais como construção civil todos sabem quando um prédio está pronto porque ele se parece e funciona igual o protótipo diz que deve parecer e funcionar, e não porque estorou o prazo do projeto.

Não entendo essa fixação em medir produtividade. Alguém já viu um projeto de software que fracassou porque atrasou?

Um ponto interessante, mas o problema é que tempo é dinheiro, não? Um projeto que atrasa geralmente fica mais caro, as pessoas ficam mais ansiosas, a pressão aumenta, etc.

A qualidade de um projeto não é influenciada pelo tempo que ele tomou para ser desenvolvido. Mas isso não quer dizer que tempo não tem custo.

Dois projetos com a mesma qualidade: um feito em em 3 meses e outro em um ano. O que foi feito em 3 meses tem mais valor eu diria.

Mas isso talvez seja porque a abordagem não espera que seja assim. Porque tentam construir software como se fosse prédio e quando não se consegue gera essa frustração. Quando se tem o dia da estréia há um foco nas coisas que são importantes para a estréia.

Eu nunca participei de um grupo teatral, mas imagino que uma peça, assim como um software, nunca está de fato pronto no dia da estréia. Depois da estréia ele ainda vai ser melhorado muito.

YvGa:

Sim, qualidade requer tempo, mas deve se tomar cuidado com o ficar procrastinando em cima do papel e não fazer nada com a desculpa da busca da qualidade. Só se entende o problema de fato com algo concreto para ser demonstrado, não com discussões vagas, desenhos, reuniões. Um protótipo de tela feito em 10 minutos vale mais do que horas de reunião. Uma implementação rápida, de uma hora, de uma funcionalidade chave para ser discutida com o cliente vale muito mais do que toneladas de requisitos assinados e acordados.

A questão é que, lendo todos esses posts, percebe-se que é um problema generalizado, o tal do prazo e do atraso: o cliente simplesmente não quer esperar o tempo necessário para um software ficar pronto. Sim, um protótipo feito em 10 minutos (mesmo no papel) para se discutir com o cliente é uma ótima saída, não é à toa que metodologias como XP começam pelo desenho das telas no papel (estou enganado? Não trabalho com XP, apenas informação que tenho).

Mas o que acontece comigo vez após outra, e deve acontecer com todos vcs tb, é o cliente ser arisco, escorregadio, nunca ter tempo para detalhar nada com vc. Vc quer discutir e ele te passa correndo as coisas, “vê aí como que é”, e em cada dúvida que vc tenta esclarecer surgem 1000 detalhes e regras de negócio novas que vc nem fazia ideia. Sério, é só comigo que isso acontece? rsrsrsrsrsrsrsrs

No meu caso, no sistema que estou prestes a entregar e pensando se vai atrasar ou não (embora esteja saindo e ele gostando do resultado até aqui), o que era para ser um “formulário de pedido” (produto, preço unitário, quantidade, total do item e total do pedido) virou um hiper-aplicativo de integração com o sistema legado em Clipper do cara, que gerava os tais pedidos. E eu tinha que colocá-los na web para poderem ser acessados por um iPad. Solução? Algum aplicativo de cloud com sincronização automática dos arquivos, como o SkyDrive. Eu nunca tinha mexido com isso, lá vou eu ralar e aprender o básico para poder cumprir a tarefa. Mas no final de tudo gostei, aprendi uma coisa que pode ser muito útil para mim no futuro.

Insisto no que o Kico Lobo falou no post dele: Qualidade requer tempo para se obter o conhecimento a respeito da essência do problema, ou seja, para entender com o quê estamos lidando. Porque eu estimei um preço e um prazo correndo para ele, baseado em um “formulário simples de pedido”, como ele próprio me disse. Até eu “entender com o que estava lidando”, eu tive que insistir muito com o sujeito pra ele me dar mais informações (e ele nunca responde direito, fico com uma raiva!! kkk). Para o cliente tudo é fácil. Eles têm que aprender mesmo que nós não somos fábrica, o nosso trabalho é intelectual, de criação.

Uma metáfora que sugiro: “vou pensar um software para vc”.

Opa, pra enriquecer a discussão, to postando aqui um link muito interessante da Wikipédia sobre a hipótese de Sapir-Whorf.
Esta teoria diz que as pessoas vivem em universos distintos que são expostos a partir da sua linguagem. É um assunto que me fascina há uns bons 11 anos, então estou compartilhando com vocês:

Não tenho muito a acrescentar, exceto tornar um pouco mais explícito o que o artigo já diz de maneira nem tanto implícita: A culpa dessa analogia é de nós mesmos.

Bem dito Vinícius, cabe a nós agora tentar arrumar a bagunça.

Mark, eu vou fazer alguns comentários sobre o que você escreveu, mas não quero que seja visto como acusatório, nem nada assim. Esses que você citou são sim problemas comuns, mas que na maioria são ocasionados por nós mesmos e em muitos casos, se não todos, são consequência da metáfora a que o kiko se refere no começo do tópico.

Eu vou dizer você pra ficar mais claro no exemplo, mas isso serve para nós todos, para mim inclusive, não especificamente para você.

Só pra comentar, XP não prescreve que seja assim, nem diz que não deve ser. Mas vamos ao que importa.

Sim, há o problema generalizado do prazo/atraso. Não, o cliente não quer esperar o tempo necessário para um software ficar pronto. E ele está certo. Ele não vai acreditar em você se você chegar sentar duas horas com ele, escrever um monte de coisas e for embora. E dali a seis meses você volta com tudo pronto. Ele não quer isso ainda que seis meses seja um tempo razoavel para que tudo fique pronto.

E ele começa com essa impaciência desfigurando a nossa metáfora. Pois, segundo ela, trata-se de um projeto e este projeto deve ter suas fases respeitadas. Mas veja como nada se encaixa se o compararmos com o projeto de uma casa, por exemplo.

Numa casa, o engenheiro/arquiteto vai até ele, olha o terreno, o espaço, ouve as idéias do cliente, procura entender o que ele quer e vai embora.

No seu caso, você vai até o seu cliente, ouve os requisitos, se esforça para entendê-los e vai embora.

Alguns dias depois o engenheiro volta com um desenho/projeto da casa, com a fachada, a planta, um modelo 3d no autocad e seja lá mais o que for. Esse modelo dá uma noção exata ao cliente do que será feito, o cliente vislumbra o modelo pronto, ele sonha com aquilo, projeta a família chegando, cachorro, grama e tudo mais. Ou seja, ele entende o que é aquilo, muda o que acha que deve mudar a coisa continua. Ele não achava que o engenheiro traria a casa pronta pra ele.

Você vai até ele com um monte de papel escrito de forma desconexa, tudo que ele já tinha falado e pergunta se está ok. Pode até ter alguns desenhos de tela, mas pra ele aquilo não significa nada e por mais que ele leia e se esforce pra entender ele não vai ver ali como aquilo ficaria pronto, nem vai conseguir sequer imaginar aquilo resolvendo seus problemas.

O engenheiro então começa a construir. E todo dia o cliente vai ver como anda a obra, ele acompanha, as vezes muda tudo no meio do caminho, se irrita com a demora, vai tirando fotos do andamento para um dia mostrar pros filhos.

Você colhe a assinatura dele e vai embora, dizendo que dali a seis meses volta com tudo pronto.

Então me diga, é certo ele ter paciência?

A solução é parar de usar metáfora em POO, brincadeiras a parte ótimo artigo, parabéns.

kicolobo,

Que post bacana cara! Apesar de você abordar o problema da linguagem de uma forma que eu nunca tinha visto, esse problema não é novo. O velho problema da comunicação entre desenvolvedor e usuário acontece porque usamos diferentes linguagens. Por isso temos metodologias e técnicas para tentar solucionar isso, como DDD e a Ubiquitous Language - linguagem única entre desenvolvedor e usuário.

Mas voltando ao assunto que você abordou, não é um problema só de linguagem. Nós como desenvolvedores temos uma história muito recente, os primeiros desenvolvedores de software como conhecemos começaram a aparecer apenas na década de 40. E durante muito tempo trabalhamos como uma fábrica. Apenas dos anos 2000 pra cá, nós viemos com outras metodologias e novos abordagens de como desenvolver software.

É engraçado como história e línguas são tão interligadas não? Cabe a nós mostrar que a história mudou que a o programador “chão-de-fábrica” não existe mais. Mas antes de convencer os outros, temos que convencer a nós mesmos. O que tem de empresa ainda seguindo essa filosofia de fábrica de software por aí não é brincadeira e tem muito desenvolvedor que ainda defende esse tipo de metodologia.

kicolobo, ótimo artigo mesmo. Parabéns

Eu concordo. O problema é que muitas vezes os donos e/ou gerentes das empresas são pessoas ultrapassadas (e extremamente leigas na área) que não estão dispostas a entender o desenvolvimento de software de maneira diferente, ainda mais (pasmem!) quando quem tenta explicar isto é um desenvolvedor de software.

Eu acho que o assunto abordado pelo kicolobo (aliás, ótimo texto) é fundamental. Entretanto - posso estar sendo pessimista demais - acho para algumas pessoas não tem mais volta. Simplesmente não querem entender as coisas de outra maneira.

Legal seu post!! Tenho alguns amigos assim e sempre questinava-os sobre isso… hahahauahau
Mas como o próprio autor falou, a realidade é outra. As empresas obriga ao individuo a ser esse tipo de profissional, visando somente o lucro imediato, e em meu ponto de vista, barato!

alexwog:

Legal seu post!! Tenho alguns amigos assim e sempre questinava-os sobre isso… hahahauahau
Mas como o próprio autor falou, a realidade é outra. As empresas obriga ao individuo a ser esse tipo de profissional, visando somente o lucro imediato, e em meu ponto de vista, barato!

O que o YvGa comentou no seu ultimo post está certinho.

Qual é o problema do contratante visar o maior ROI e o mais rápido possível? Se voce estivesse contratando uma equipe de pedreiro para levantar sua casa, voce também não ficaria monitorando de perto e ficaria extremamente irritado com qualquer gasto a mais que o necessário? (a comparação com a engenharia foi intencional!)

Somos nós que temos dificuldade em demonstrar o ROI de forma adequada. A linguagem que utilizamos de fato contribui para isso (pois leva o cliente a um entendimento inadequado do que será feito), mas também creio que o problema vai além da linguagem ou das metaforas.
Como é possível ver nesse tópico, muitos programadores tem dificuldade em entender que o software que ele está desenvolvendo não é o fim, mas só um meio. Nós queremos contar com um tempo indeterminado para fazer uma aplicação ideal conforme nós mesmo entendemos por ideal, mas não percebemos que a aplicação ideal para quem ta contratando é aquela que vai trazer o maior lucro no menor tempo possível.
Assim temos um programador que não entende a linguagem do cliente e um cliente que não entende a linguagem do programador.

Eu concordo. O problema é que muitas vezes os donos e/ou gerentes das empresas são pessoas ultrapassadas (e extremamente leigas na área) que não estão dispostas a entender o desenvolvimento de software de maneira diferente, ainda mais (pasmem!) quando quem tenta explicar isto é um desenvolvedor de software.

Eu acho que o assunto abordado pelo kicolobo (aliás, ótimo texto) é fundamental. Entretanto - posso estar sendo pessimista demais - acho para algumas pessoas não tem mais volta. Simplesmente não querem entender as coisas de outra maneira.

Wagner, acho que essa recusa pode ser bem mais do que cultural. Os gerentes muito dificilmente aceitarão esse tipo de visão, principalmente vida de um desenvolvedor, justamente por não quererem. As empresas que começam a trilhar este caminho começam a ver que muita gente que hoje faz parte do processo é desnecessária nele.

E os gerentes, da forma como temos hoje, são um exemplo clássico disso, pois em boa parte dos casos só tumultuam e em nada contribuem para o produto, não passando de cães de guarda dos diretores, para que possam manter a ilusão de que tudo está andando normalmente.

Ou seja, essa recusa se deve bem mais a instinto de sobrevivência do que a questões culturais. Para que eles durem no mercado eles precisam fazer com que pareçamos menos importantes e menos inteligentes que eles. Pois uma vez que dominamos uma técnica, que diferentemente do operacional das engenharias, poucos são capazes de fazer, e eles mesmos não são, se nos aceitarem tão importantes e inteligentes quanto eles qual será então a razão para que eles existam?

Mais um ótimo post kikolobo, que bom.

Minha opinião: falar disto é parecido com aquela história sobre o cego pegar no rabo de elefante e achar que é uma simples cordinha.

Este tipo de coisa não é típico da área de TI, já foi e é questionado a tempos; para entender o que estou falando deverá ler sobre as seguintes celebridades: Taylor, Fayol e de quebra sobre Henry Ford.

Vivemos um gigantesco paradigma sobre produção de qualquer coisa (industria) feita pelo homem; o vini disse (se não me engano) que a culpa é nossa. SIM -> quem tem que quebrar paradigmas somos nós mesmos. NÃO -> Por ter sido inserida na industria em tamanha profundidade e por sofrer tamanha influencia do contexto no qual foi inserida torna-se dificílimo as mudanças de pensamento neste setor.

flws

saoj:

JoseIgnacio:

Não entendo essa fixação em medir produtividade. Alguém já viu um projeto de software que fracassou porque atrasou?

Um ponto interessante, mas o problema é que tempo é dinheiro, não? Um projeto que atrasa geralmente fica mais caro, as pessoas ficam mais ansiosas, a pressão aumenta, etc.

A qualidade de um projeto não é influenciada pelo tempo que ele tomou para ser desenvolvido. Mas isso não quer dizer que tempo não tem custo.

Dois projetos com a mesma qualidade: um feito em em 3 meses e outro em um ano. O que foi feito em 3 meses tem mais valor eu diria.

O problema é que quando um projeto é definido em termos de custo e prazos, sua qualidade É comprometida.

YvGa:

Mas isso talvez seja porque a abordagem não espera que seja assim. Porque tentam construir software como se fosse prédio e quando não se consegue gera essa frustração. Quando se tem o dia da estréia há um foco nas coisas que são importantes para a estréia.

Eu nunca participei de um grupo teatral, mas imagino que uma peça, assim como um software, nunca está de fato pronto no dia da estréia. Depois da estréia ele ainda vai ser melhorado muito.

Só pra ficar claro, estou feliz hoje construindo software como se fossem prédios.

A frustação era justamente por estrear algo meia-boca, ao invés de algo pronto.

Sim, se for simplesmente assim voce tem razao. Simplesmente estipular uma data para que tudo esteja pronto vai sim prejudicar a qualidade. É preciso uma mudança de cultura muito grande para que a coisa funcione com a “data de estréia”. E esta mudança cultural não é no cliente, mas em nós desenvolvedores.

E a mudança cultural começa por entendermos que não é entregar algo meia boca. Tudo que for entregue deve estar funcionando 100%. O que pode ser negociado é o escopo do que será entregue. Porém para negociar o escopo, outra mudança de cultura deve acontecer.

Iniciar sempre o desenvolvimento pelas funcionalidades mais importantes para o cliente, pois faz assim que os maiores problemas surjam já no início e sejam resolvidos já no início. E não começar pelo modelo de dados, depois especificações, depois as telas de cadastro, depois os processos um pouco mais complicado e finalmente o processo principal. Trabalhando desse jeito a “data de estréia” não funciona mesmo.

Para se deixar de fazer software como se fosse prédio, o que, com certeza - e historicamente comprovado, não faz a maioria dos clientes felizes, não basta simplesmente determinar outra forma. Há uma série de mudanças que nós mesmos temos adotar.

YvGa:

Fazer software é como produzir uma peça teatral. Você tem um texto que deve ser seguido, todos o conhecem e discutem sobre ele. Todo mundo vê o todo e vendo o todo cada um faz sua parte. Há o diretor que procura manter a “big picture” da leitura que ele quer do texto. Há os atores, talentosos, que usam da sua criatividade para dar vida aos personagens sem fugir muito da visão do diretor. Há os cenógrafos, maquiadores, figurinistas que entendem o contexto pra chegarem ao resultado final.

E o melhor de tudo, o prazo já vem dado. A estréia é no dia tal e naquele dia tudo deve estar pronto. E mesmo assim a peça irá evoluir durante a temporada, a medida que os atores forem entendendo melhor a reação do público, colocando e retirando uma palavra aqui e ali.

Acho que esse é o contexto que melhor se encaixa com desenvolvimento de software. Não que sejamos artistas, embora existam as divas entre nós, mas o processo de evolução do produto é parecido com o teatro.

1. Quanto à parte dos atores serem talentosos… pode ter sido verdade no passado, mas hoje em dia no teatro profissional a coisa tá feia!!! hehe (essa foi só pra descontrair)

2. Acredito que essa não possa ser “A” analogia que segundo o Kico precisamos para definir nossa profissão dentro do mercado, por um motivo que é o fator psicológico perante o mercado:
   Imagine-se falando para um potencial cliente (por exemplo um executivo, leigo em desenvolvimento de software) sobre seu trabalho.

• Trabalhar como uma indústria ou construção civil tem uma conotação de solidez, seriedade, trabalho duro. Com certeza os olhos dele vão brilhar quando ouvir falar nisso.
• Agora diga a ele que o seu trabalho funciona como um grupo teatral… a impressão não é tão legal. Tradicionalmente o teatro está associado a um estilo de vida desregrado, indolente, sem ambição, cheio de gente pelada.

E é só por causa desse efeito que não acho a analogia com teatro 100% perfeita (para usar como uma forma de comunicaçao com o mundo não-TI). Mas é totalmente precisa ao descrever como funciona o processo.

Mas é por essa linha mesmo, para fazer uma boa analogia temos que pensar em atividades que envolvem criatividade, não-repetição, trabalho em equipe, e ao mesmo tempo tem que lidar com prazos e custos. Mais alguns exemplos: uma redação de jornal ou revista, uma campanha de marketing.

YvGa:

JoseIgnacio:

O problema é que quando um projeto é definido em termos de custo e prazos, sua qualidade É comprometida.

Sim, se for simplesmente assim voce tem razao. Simplesmente estipular uma data para que tudo esteja pronto vai sim prejudicar a qualidade. É preciso uma mudança de cultura muito grande para que a coisa funcione com a “data de estréia”. E esta mudança cultural não é no cliente, mas em nós desenvolvedores.

E a mudança cultural começa por entendermos que não é entregar algo meia boca. Tudo que for entregue deve estar funcionando 100%. O que pode ser negociado é o escopo do que será entregue. Porém para negociar o escopo, outra mudança de cultura deve acontecer.

Negociar escopo é uma consequência do gerenciamento de prazos e custos, portanto incompatível com qualidade.

Olá,
Kicolobo, parabens pelo artigo, gostei muito.
Metáforas são sempre dificeis, porque são metáforas. A linguagem em si é uma dificuldade. Quantas palavras precisamos para expressar ate as coisas mais simples? quantas frases? Na minha opinião, seria necessário criar palavras novas para dar conta dessa nova área e dessa nova realidade que é o ofício do profissional de TI. É algo novo, e por isso merece novo vocabulário.
Acho a comparação com a indústria horrível. De vez em quando me pergunto se não estamos sendo tratados não como os operários de uma fábrica do início do século passado, mas sim como as máquinas que eles operavam. Máquinas que ligamos e desligamos quando queremos, que fazem tudo igualzinho todos os dias e que sejam desprovidos de sentimentos/problemas/razão. Ah sim, a razão servindo apenas para escrever o código que rode adequadamente. E se somos máquinas ou operários, não vejo la muita necessidade de cursos superiores na área. E nem de remunerar la muito bem, afinal, qualquer pessoa bem treinada pode fazer…(tudo isso, pode ser meio que consequência desse vocabulário… ou de toda uma mesma visão de mundo, uma determinada forma de pensar que é hegemônica no mundo contemporâneo)
Mais uma coisa sobre essas metáforas. Uma vez li, mas não me recordo onde, que o fato de usarmos um vocabulário associado a construção civil e indústria bélica afastava muitas meninas do aprendizado na área de TI. Sim, estou falando de meninas pré-adolescentes que teriam menos vontade/disposição de aprender “coisas de computador”. (Gostaria de me lembrar aonde li isso, pois era muitíssimo interessante).
Só mais uma coisa sobre vocabulário: nós usamos muitas palavras em inglês, ou aportuguesando as palavras vindas do inglês (debugar, dar um build…). Será que essa é a melhor solução? Será que isso estabelece um vocabulário comum para todos ao redor do mundo e por isso deve se manter assim?
Só mais uma coisa: adorei a discussão! E as idéias de metáforas… nada mau!
até!

Clientes não ligam para funcionalidades parcialmente implementadas.

E se ligar, e souber dizer qual funcionalidade mais importante, isso não significa que é que vai dar mais problema pra implementar. Essa é uma afirmação absurda.

JoseIgnacio:

YvGa:

Iniciar sempre o desenvolvimento pelas funcionalidades mais importantes para o cliente, pois faz assim que os maiores problemas surjam já no início e sejam resolvidos já no início. E não começar pelo modelo de dados, depois especificações, depois as telas de cadastro, depois os processos um pouco mais complicado e finalmente o processo principal. Trabalhando desse jeito a “data de estréia” não funciona mesmo.

Clientes não ligam para funcionalidades parcialmente implementadas.

E se ligar, e souber dizer qual funcionalidade mais importante, isso não significa que é que vai dar mais problema pra implementar. Essa é uma afirmação absurda.

Não é questão de ser mais complicada de implementar, clientes vão exigir prazos, é o mundo real e querer que os nossos projetos tenham tempo infinito é utopia. Sabendo disso, quando o tempo para a conclusão do projeto não for suficiente, a melhor forma de não comprometer a qualidade é reduzindo o escopo e ao reduzir o escopo, é melhor que as funcionalidades mais importantes para o cliente já estejam prontas.

Eu queria dar os parabéns pelo artigo que vai direto ao ponto. Quando comecei a ler pensei que seria relacionado ao levantamento de requisitos (onde a linguagem também é um problema), mas logo ficou claro que o ponto é a metáfora relacionada ao software. Se sua mãe perguntar o que vc faz, como vc explica ? Vc explica algo assim :" Fazer software é como … "

A metáfora industrial (o nome é muito bom) é realmente um problema. Em momento algum a sociedade de desenvolvimento quiz ou procurou esta metáfora. Quem criou esta metáfora foram as pessoas que criaram as empresas de software. O problema é que as empesas de software vieram das empresas de hardware, e nessas a metáfora industrial funciona (por razões obvias embutidas na prórpria palavra hardware - que é um sinónimo de ferramenta em inglês : hardware store). Quando o software ganhou sua própria identidade e as empresas produziam apenas software e não mais hardware, devido à tradicão e experiencias anteriores dessas pessoas e à osmose do software como vindo do hardware a mesma metáfora foi usada. mas se vc procurar nos livros, sempre, em todos eles, é explicito que o desenvolvimento de software é uma atividade ciclica, com iterações, e que portanto não cabe na metáfora industrial ( o produto final não volta a entrar na linha de produção, em software volta).

Acho que o que melhor define o software é que não ha dois iguais. Isto leva ao conceito de que o software é mais semelhante a uma oficina do que uma industria. A metáfora da oficina é interessante e serve para explicar o que acontece no nível dos desenvolvedores, mas não serve tão bem a nível gerencial. A metáfora da saúde é melhor no aspeto de relação com o cliente, mas pior para descrever o dia a dia do desenvolvedor.( em tese a medicina não é experimental, mas o software é). É preciso dizer que a metáfora da oficina é maior que o Software Craftmanship. O SC é uma especilização dessa metáfora, mas a metáfora em si é maior que o que eles advogam. O manifesto da SC é importate ( eu mesmo assinei) e eu considero mais importante que o manifesto ágil. Mas ambos não traduzem o que estamos dicutindo aqui.

A metáfora da oficinal assenta no processo empirico de control, e aqui que eu acho que está a grande diferença: no processo subjacente. Este mesmo processo pode ser usado na metáfora da industria, e industrias verdadeiras o usam para melhorar seus processos ( foi assim que começou o embriam do que hoje é o scrum e o lean). A ideia é que vc pode fazer como quiser , mas têm que ter 4 precauções : continuamente inspecionar o que faz para verificar se está como deveria. Isto inclui o fator de qualidade, mas não só. Se não estiver como deveria, vc deve adaptar o produto e/ou o processo para que assim seja. Você deve realizar estas atividades com transparencia e vc deve procurar sempre entregar o melhor produto possível. Estas 4 qualidades formam os pilares aceites hoje e resumidamente chamados de “Ágil”.
Existem muitas visões de como usar estes 4 pilares e isso leva aos vários sabores de Ágil que tem por ai, contudo estes pilares não nos dão uma metáfora especifica ou uma modelo de negócios especifico. Excepto em um detalhe : seja transparente.

Alguem deu o exemplo do cliente que pressiona por terminar antes. Isto se relaciona à falta de respeito de que os desenvolvedores gozam em relação aos clientes. Nenhum paciente manda o seu médico se apressar. E é aqui que a metáfora da saude ajuda. O desenvolvedor , autonomo ou não, a empresa de desenvolvimento, deve se colocar com respeito. Deve respeitar, mas pedir respeito. Não faz mal se o cliente for embora. Isso é apenas um sintoma que o cliente lhe iria dar problemas. É certo que vemos cliente = dinheiro, mas não é bem assim. É cliente = dinheiro + risco. Ás vezes os risco não compensa o dinheiro.

Portanto, para mim, a metáfora - sem nome- seria algo entre a metáfora da oficina e a da saude.

Olhando por outro lado, a necessidade de uma metáfora demonstra como falhamos em termos um processo próprio, especifico. Seria de esperar que alguem dissesse “mãe, isto é como fazer software” em vez de "mãe, software é como … ". Então, ao mesmo tempo que procurar uma metáfora é interessante, isso é apenas um eufemismo para o problema real que é não termos um processo próprio.

Hoje, está mais próximo de termos esse processo. muita gente considera o Ágil como a corrente que irá proporcionar isso, o problema é que o Ágil está partido em várias partes “concorrentes” e muitas delas “brandificadas” (com marcas comerciais. Outro dia ficar parvo quando vi que o nome “Planning Poker” é uma marca registrada. Isso é riduculo) .

O problema eu vejo que está no oportunismo. Ainda existe muita gente na área que realmente não está nem ai para o core daquilo que faz. muita sempre simplesmente faz código e ganha dinheiro com isso e adotam a postura “o patrão sempre tem razão” e o padrão adota a postura “o cliente sempre tem razão”. E isto é errado. Está nos livros que é errado, mas os patrões não querem saber disso , já está na sua cultura.

Então o que precisamos é, como alguem disse, impedir que quem chega no ramo adote essa cultura. A cultura alternativa da qualidade, da inspeção, das transparencia, da busca de valor, deve prevalecer. E ha uma forma simples disto acontecer. Basta que as pessoas que pensam assim se reunam e produzam empresas que obliterem as de cultura “atrasada”. O cliente irão preferir bons produtos que são baratos, mesmo que tenham que ouvir um não de vez em quando. Os clientes têm que diferenciar entre quem lhe quer chupar a carteira e quem quer maximizar o custo/beneficio. O Google, por exemplo, adota uma postura bem diferente do resto das empreas tradicionais e isso tem lhe dado frutos. E esses frutos têm se traduzido na obliteração da concorrência, mas ao mesmo tempo na expansão das ideias cada vez mais arrojadas. O Google Maps é uma ideia obvia, mas executá-la não é nada trivial. Eles quiserem fazer algo, e tentaram fazer o melhor possível.

A metáfora é importante para explicar para quem está de fora, mas para quem está por dentro é melhor focar em incutir os valores corretos.

diegosammet:

Não é questão de ser mais complicada de implementar, clientes vão exigir prazos, é o mundo real e querer que os nossos projetos tenham tempo infinito é utopia. Sabendo disso, quando o tempo para a conclusão do projeto não for suficiente, a melhor forma de não comprometer a qualidade é reduzindo o escopo e ao reduzir o escopo, é melhor que as funcionalidades mais importantes para o cliente já estejam prontas.

Não sei se esta trolando ou falando sério.

Como você pode entregar algo incompleto e achar que não comprometeu qualidade?

Reduzir escopo é sim reduzir qualidade.

JoseIgnacio:

diegosammet:

Não é questão de ser mais complicada de implementar, clientes vão exigir prazos, é o mundo real e querer que os nossos projetos tenham tempo infinito é utopia. Sabendo disso, quando o tempo para a conclusão do projeto não for suficiente, a melhor forma de não comprometer a qualidade é reduzindo o escopo e ao reduzir o escopo, é melhor que as funcionalidades mais importantes para o cliente já estejam prontas.

Não sei se esta trolando ou falando sério.

Como você pode entregar algo incompleto e achar que não comprometeu qualidade?

Reduzir escopo é sim reduzir qualidade.

Esse é o ponto, reduzir o escopo não é entregar algo incompleto é somente reduzir o numero de funcionalidades. E existe essa redução justamente para que as funcionalidades implementadas estejam completas.

diegosammet:

Esse é o ponto, reduzir o escopo não é entregar algo incompleto é somente reduzir o numero de funcionalidades. E existe essa redução justamente para que as funcionalidades implementadas estejam completas.

Hã?

Não sei aonde quer chegar. Não importa se as funcionalidades existentes estão completas. O PROJETO não está completo se todas as funcionalidades não tiverem sido implementadas.

Mas justamente esse é o ponto importante da discussão.

Isso que você disse é a mais pura verdade. Se o cliente disser que é. Se ele não aceita algo ser posto em produção enquanto outra funcionalidade não está pronta, forçando o release você diminui a qualidade.

Mas se o cliente diz que não quer/precisa esperar certas funcionalidades para que seja feito o release, não houve perda de qualidade. Veja que as funcionalidades principais estão todas lá porque foi a primeira coisa que voce fez. Então se você atrasar, coisa a que está menos propenso porque enfrentou os riscos (que estão nas funcionalidades principais) antes do que faria num processo normal. Mas mesmo assim, se atrasar, o escopo comprometido é menor e o cliente normalmente julgará aceitável. E julgará aceitável normalmente porque acompanhou todo o processo validando as funcionalidades principais e solicitando as alterações muito antes do que faria normalmente.

Mas justamente esse é o ponto importante da discussão.

Isso que você disse é a mais pura verdade. Se o cliente disser que é. Se ele não aceita algo ser posto em produção enquanto outra funcionalidade não está pronta, forçando o release você diminui a qualidade.

Mas se o cliente diz que não quer/precisa esperar certas funcionalidades para que seja feito o release, não houve perda de qualidade. Veja que as funcionalidades principais estão todas lá porque foi a primeira coisa que voce fez. Então se você atrasar, coisa a que está menos propenso porque enfrentou os riscos (que estão nas funcionalidades principais) antes do que faria num processo normal. Mas mesmo assim, se atrasar, o escopo comprometido é menor e o cliente normalmente julgará aceitável. E julgará aceitável normalmente porque acompanhou todo o processo validando as funcionalidades principais e solicitando as alterações muito antes do que faria normalmente.

Exatamente, depois dessa explicação nem preciso responder…

O meu ponto de vista não quis concordar ou discordar com o que foi dito antes.
A responsabilidade pela forma como nosso cliente nos vê é nossa? É.
Cabe a nós nos comunicarmos de outra forma? Cabe.
Aquele cliente apressadinho vai querer sentar para te ouvir e falar também, de tão disposto que vc está em falar com ele? Não vai.
Há casos e casos, ninguém está falando que todo cliente é assim.
Não se trata de querer protelar indefinidamente a entrega do software, mas sim de estabelecer um prazo adequado para que o produto saia com a qualidade mínima esperada para não dar dor de cabeça lá na frente (a diferença entre passar por uma boa fase de análise e projeto e sair codificando correndo para ver o negócio funcionando o mais rápido poossível).
Em muitos casos torna-se necessária uma atitude rigida perante o cliente, sim. Essa é a postura que adoto e, acredite, parece que faz eles me procurarem mais (devem sentir mais confiança). Eu imponho minhas condições. Esta semana mesmo me procuraram para desenvolver uma loja virtual básica. Pedi um prazo e o cliente me perguntou se não dava para fazer em uma semana porque estava com pressa. Tive que ser firme. A “linguagem” que usamos é feita mais de tom de voz e expressão corporal do que de “palavras” em si. Se o cliente acha que é possível fazer loja virtual em uma semana, ou ele não entende absolutamente nada ou porque algum moleque que fuça em computador já deve ter feito uma paginazinha “pás coxa” nesse prazo.
Explicar com palavras, blá blá blá, porque isso isso e aquilo não vai fazer muitos entenderem. Os que são agressivos e querem. Querem agora. Quando tenho para dar, eu dou e cobro o preço justo. Quando não tenho, que insista com outro.
Não tiro a razão do cliente em querer as coisas e querer resultados, tanto que sempre dou abertura para me procurarem e quero também procurá-los quando sentirem dúvidas. Talvez me interpretaram mal, porque eu não me refiro a qualquer cliente, exatamente ao tipo (extremamente comum) que quer as coisas para “já” mas não se dispõe nem a responder minhas perguntas. Eu vivo às turras com gente assim (mas guardo pra mim). Será que sou só eu?

Mark, eu não discordo de você. Sim nós devemos ser honestos com os nossos clientes sempre, mesmo que isso signifique um sonoro NÃO na orelha dele. Sim, você perde o cliente, mas acabaria perdendo dinheiro (tempo e paciência) se aceitasse algo esdrúxulo só pra ele poder lucrar nas suas costas.

Mas há algumas ressalvas no que você escreveu que eu gostaria de fazer.

Nos casos em que vi isso foi em repartições públicas onde sistemas eram impostos aos usuários por superiores, com visões bem longe daquelas que o usuário queria.

Fora isso, eu raras vezes enfrentei esse problema, talvez por isso tenha uma visão distorcida sobre esse ponto. Um cliente que não se dispõe a falar com você sobre algo que ele quer (precisa), não dispõe do tempo dele pra isso, nem pede que alguém o faça, não pode ser levado a sério. Porque é indício de que ele não está nem aí pro software. Então não há muito o que ser feito. Não é uma questão de metáforas nem de linguagens, é uma questão de prioridades dele e pronto. Muito prazer e até um dia.

Mas cá pra nós, isso beeem incomum. Normalmente quem está pedindo software gosta de acompanhar, participar, entender. Claro que nem sempre ele vai ter todo o tempo pra isso, mas mesmo assim põe alguém a disposição pra tirar as dúvidas e participar.

Não que eu discorde, mas tem um enorme porém nessa afirmação. Bem grande.

Dependendo da proporção em que as doses são aplicadas, “uma boa fase de análise e projeto”, pode significar na prática “um monte de tempo desperdiçado seguindo uma caminho que se pensa ser o certo sem que o cliente diga que é de fato certo, só pra depois descobrir que não era bem aquilo que ele queria e o ficar xingando porque mudou tudo na ultima hora.”, enquanto, por outro lado "sair codificando correndo para ver o negócio funcionando o mais rápido poossível", passa a significar “implementar o mínimo possível do que há de mais importante no sistema para que o CLIENTE veja funcionando o mais rápido possível e se baseie naquilo, e não num monte de papel com frases sem sentido, para nos dizer se estamos no caminho certo ou não.”

O erro na proporção de uso destas duas técnicas pode levar ao desastre.

Mais uma vez concordo com ressalvas. Sim, como eu já disse você está certo em ser firme, porque nesse caso ser firme é ser honesto. Primeiro com você, segundo com o cliente. Mas de novo deve se ter cuidado para não perder oportunidades. Repare que muitas vezes o cliente talvez não esteja te pressionando somente pra tirar vantagem, ele pode estar te pressionando porque realmente precisa da loja virtual, na visão dele, pra dali a uma semana.

O problema é que as vezes, ele não quer exatamente uma loja virtual em uma semana, mas de especificamente uma ou outra funcionalidade que necessariamente teria que estar pronta em uma semana e talvez esta uma ou outra funcionalidade possa de fato ser feita em uma semana. E nessa você perde um bom negócio.

Houve um caso em que o cliente, desesperado, queria um sistema de estoque em um mes. Com controle de pedidos, venda, clientes, contas a pagar, receber, etc, etc, etc. E ainda tinha que converter a base de dados do sistema antigo e abandonado pelo cara que fez. O programador então ficou curioso e perguntou "por que você precisa em um mês? o que vai acontecer daqui a um mês que faz com que você precise disso pronto? Ele precisava emitir notas fiscais, mas o sistema velho não fazia isso, nem iria fazer, já que a empresa que dava manutenção já não existia mais faz tempo.

Ou seja, ele queria um sistema de controle de estoque, emissao de NF, contas a pagar/receber, blablabla blablabla, mas o que ele precisava mesmo pra dali a um mês era só algo no qual ele pudesse emitir NFs.

Então fala pra mim em que estado do país vc mora, que eu quero me mudar para aí. Eu sempre enfrento esse problema, os caras não querem sentar para pensar. Não adianta insistir, e quanto + vc tenta puxar mais eles correm. Não são todos, claro, tem muitos que são bons de lidar e querem detalhar o máximo o funcionamento de seus sistemas. Mas esse perfil que tanto me irrita, por aqui, chega a uns 20 a 30%.

Outra questão linguística: porque quando se fala em “analisar calmamente os requisitos junto com o cliente” interpreta-se “vamos enrolar escrevendo papeis que não tem nada a ver”? Será que o Kico responde essa?

Mas justamente esse é o ponto importante da discussão.

Isso que você disse é a mais pura verdade. Se o cliente disser que é. Se ele não aceita algo ser posto em produção enquanto outra funcionalidade não está pronta, forçando o release você diminui a qualidade.

Mas se o cliente diz que não quer/precisa esperar certas funcionalidades para que seja feito o release, não houve perda de qualidade. Veja que as funcionalidades principais estão todas lá porque foi a primeira coisa que voce fez. Então se você atrasar, coisa a que está menos propenso porque enfrentou os riscos (que estão nas funcionalidades principais) antes do que faria num processo normal. Mas mesmo assim, se atrasar, o escopo comprometido é menor e o cliente normalmente julgará aceitável. E julgará aceitável normalmente porque acompanhou todo o processo validando as funcionalidades principais e solicitando as alterações muito antes do que faria normalmente.

Você é uma rara exceção que entrega a primeira versão de um software sem bugs e com uma experiência de usuário impecável.

Esse cara tá falando tanta patacada que eu já tô com desgosto desse debate kakakaka.
O que o cara do blog tá dizendo é que eles nos veem como “fábrica” justamente pela nossa linguagem, a forma como nós nos colocamos. Cito o trecho “qualidade requer tempo para entender com o que estamos lidando.” Identifiquei-me na hora.
O que o amigo acima falou é a mais pura verdade:

cliente sabe o que quer = 1o. release de boa qualidade
cliente que não sabe o que quer e não colabora = 1o. release completamente nada a ver

Ok, preciso de um sistema de missão crítica para amanhã cedo. Não tenho tempo de lhe explicar, resolva aí. E quero o troço funcionando!

JoseIgnacio:

Você é uma rara exceção que entrega a primeira versão de um software sem bugs e com uma experiência de usuário impecável.

Entregar um software cheio de bugs para o cliente com a desculpa de que é assim mesmo e depois a coisa se ajeita é coisa que já está se tornando inaceitável para os consumidores de software. Tem gente vindo aí, e cada vez mais, que consegue satisfazer o cliente sem ter que antes provar a paciência dele. Talvez eu seja exceção e não regra, mas não mais tão rara assim e cada vez menos.

Se eu disser sem bugs e com uma experiência de usuário impecável eu vou estar exagerando, mas eu posso te dizer: Normalmente eu entrego com uma quantidade de bugs bem menor, e bem menos graves, e com uma experiência de usuário bem mais próxima do ideal do que quando eu fazia baseado no modelo tradicional de fábrica que vocês, quer queiram ou não, estão defendendo.

O que talvez vocês ainda não tenham entendido, provavelmente por falha minha em não enfatizar é que quando a primeira versão de um software vai pra produção, ela não é nem perto a primeira vez que o cliente vai vê-la funcionando. A cada reunião que eu tenho com ele, eu levo algo rodando, software, rodando. Nada de planilha, nada de papel, nada de UML, nem MER, nem DER, nem nada técnico. Ele vê software funcionando, e a partir da primeira reunião, até a última, dentre as quais haverá muitas, em todas elas ele vai ver software rodando. Vai dizer se era aquilo ou não que ele esperava, se aquilo resolve ou não o problema dele.

Sabe aquelas coisas que acontecem com todos nós de você demonstrar o sistema funcionando para o cliente, realizar o fluxo a que ele se dispõe, salvar tudo bonitinho, tudo redondinho e o cliente diz: “Ok, isto está certinho, mas e quando for o caso de …blablabla blablabla…” E você sente até um frio no estômago porque estava achando que iria sair dali com os parabéns e descobre que o que você fez não atende ao que o cliente precisa.

Alguém já passou por isso?

Eu não passo mais. Porque se ele precisa de um sistema de agendamento de utilização de veículos, eu vou até ele, converso com ele, tento entender o processo, escrevo tudo que posso pra levantar as situações e vou pra casa. Depois eu vou organizar aquilo que eu levantei e vou fazer a maldita tela de agendamento de veículo. Eu não vou sentar na frente de uma ferramenta case e montar todas as tabelas do sistema, fingindo que as informações que eu tenho já me são suficientes, ou me julgando o mestre dos analistas de sistema, capaz de com não mais de meia dúzia de reuniões, entender completamente como o negócio do meu cliente funciona.

Eu vou fazer alguns HTMLs, criar os testes e a classe Agendamento, criar a tabela para ela somente com os campos que eu for usar AGORA, criar a classe veículo, com seus testes e suas tabelas. Fazer algo real, pequeno, mas real e levar ao cliente. Ele vai ver a tela, não vai imaginar, nem ler, vai ver. Vai me mostrar como ele trabalha e já na hora, vai dizer o tradicional: “mas como eu faço para…” E você não vai ter calafrios porque só se passou uma semana. Repare que você não está entregando nada, não tem release nenhum, coisa que ainda está longe. Mas já tem software rodando e que só vai ser ampliado até o dia do release.

A coisa evolui passo a passo, mas com feedback rápido, semana a semana, menos até se for possível e as discussões são feitas sobre implementações reais, mas que ainda não estão nem perto do release.

Se você seguir o modelo tradicional, este que diz que você deve perder mais tempo na fase de análise, para não perder tempo depois, você vai assumir muitas coisas e várias delas estarão erradas e o seu cliente só descobrirá isso no final do projeto, porque ele não tem no que se basear para te dar a informação certa.

MarkKnopfler:

Esse cara tá falando tanta patacada que eu já tô com desgosto desse debate kakakaka.

Se você prefere ignorá-los chamando tudo de patacada é um direito seu, mas não culpe seus clientes porque eles têm que cuidar dos negócios deles, não do seu.

Sim, requer, mas só o cliente vai poder dizer exatamente com o que estamos lidando, e só ele vai poder dizer se você está certo ou não e para descobrirmos com o que exatamente estamos lidando, precisamos de um modelo concreto para basear nossa conversa com ele. E não há modelo melhor do que um sistema rodando, para que ele diga: isto está certo, isto está errado. Sistema rodando não significa necessariamente release, por isso uma mínima parte sobre a qual possa discutir já basta.

Não, não é a mais pura verdade. O cliente normalmente sabe exatamente o que quer, só não sabe te explicar. Se você não consegue extrair isso dele, vai dizer que ele não sabe o que quer, que não colabora e vai entregar uma release nada a ver. Mas vai por a culpa nele e chamar de patacada quando alguém disser que a culpa disso tudo é tua.

MarkKnopfler:

Ok, preciso de um sistema de missão crítica para amanhã cedo. Não tenho tempo de lhe explicar, resolva aí. E quero o troço funcionando!

Pessoal, ninguém desenvolva software comigo, porque sabe o que eu vou fazer? Eu não vou nem tentar entender o que vc quer, eu vou rabiscar um punhado de papeis e não vou deixar vcs se aproximarem de mim, afinal eu sou um gênio e preciso de silêncio para trabalhar. E quando tiver pronto, se vc achar que não ficou como vc queria, vc deve entender que eu fiz assim porque eu julguei melhor para vc. Afinal eu manjo da área, não sou “fábrica de software” igual esses carinhas aí, meu trabalho é uma verdadeira obra de arte. E pode confiar em mim que eu entrego tudo no final, vc não precisa ver nada do meu trabalho funcionando.

O debate é sobre a nossa linguagem de comunicação, não sobre os méritos do desenvolvimento incremental.

O que está me deixando de certa forma cansado (mas ainda assim vou continuar retornando aqui para expor meu ponto de vista) é a forma como o que eu falo está sendo distorcido:

Mano, eu faço isso?? Desculpe, essa sim foi patacada e das fortes, foi um ataque mesmo, Onde está a moderação?

Não, ele não está. E o exemplo que eu citei bem depois não é idiota, o cliente normalmente pensa daquela forma mesmo: preciso disso pro dia X (não importa a complexidade do software e o tamanho da equipe). Quando eu posso entregar, eu entrego. O nosso amigo debatedor parece me enxergar como um sujeito que não cumpre prazos, e não sei de onde raios ele tirou isso. Só falei sobre o tempo necessário de análise, projeto e coleta de informações para embasar com a minha experiência o que o Kico falou, que a pressão por produtividade é que gera código ruim. Eu volto a bater na tecla de antes, que nós devemos ser firmes contra “abusos”. O cliente não vai entender que nós não somos fábrica “explicando” calmamente, muitas vezes teremos que nos impôr.

Oxi, é assim que eu faço?? Mesmo??

Sério mesmo que vc não vê clientes desse tipo?? Me diga onde vc mora que quero me mudar para aí. Por esse ponto de vista, eu não deveria levar a sério grande parte dos meus clientes!

Que bom que seus clientes estão sempre ali para lhe dizerem o que é o certo
O que eu estava narrando é uma situação atípica para vc, mas muito típica para mim. Cliente arredio, arisco, escorregadio, ele parece aquelas mulheres do e-book do Nessahan Alita: quanto + vc corre atrás, + ele te enrola. E depois vai cobrar o resultado! É por isso que eu bato o pé. E te digo, muitas vezes funciona. Um olhar cheio de sangue e um tom de voz firme valem + do que palavras. Software rodando foi o que eu tentei mostrar pro cara, juro pela minha própria alma!

O ponto de vista que eu defendi consiste justamente em se arriscar a perder essa oportunidade. O lado + forte é o que pode recusar o que o outro tem. Essa “oportunidade perdida” não é motivo nenhum de arrependimento para mim. Faz o seguinte, vc me passa seu e-mail e quando eu quiser recusar um chato assim, eu indico vc

Olha aí o tom acusatório de novo. O meu ponto de vista a todo momento foi o de sempre tentar puxar o cliente para junto de mim, a fim de que ele me dê mais e mais informação sobre como deve funcionar o software que é dele. Eu não queria ser arrogante, mas vou ter que ser e garantir que a qualidade dos meus softwares é impecável. O que sobra para alterar depois de cada release são detalhezinhos. Pequenos mesmo. Pronto, me idolatrem

YvGa:

Sabe aquelas coisas que acontecem com todos nós de você demonstrar o sistema funcionando para o cliente, realizar o fluxo a que ele se dispõe, salvar tudo bonitinho, tudo redondinho e o cliente diz: “Ok, isto está certinho, mas e quando for o caso de …blablabla blablabla…” E você sente até um frio no estômago porque estava achando que iria sair dali com os parabéns e descobre que o que você fez não atende ao que o cliente precisa.

Alguém já passou por isso?

Eu não passo mais.

Estou 100% de acordo contigo, camarada. Por isso eu também sempre mostro para ele algo funcionando. A diferença é que vc tem a sorte de poder ter essa experiência maravilhosa com todos os seus clientes, e muitos de nós não, porque os ditos-cujos, como vc falou, não estão preocupados com o próprio software - acho que apenas não reconhecem a importância de participar do processo.

Mas o software que eu desenvolvo para eles é negócio deles, e não meu.

Meu amigo, eu quero q vc entenda que a cada citação que faço do seu nick, não estou necessariamente “discordando”, e sim dizer que a minha realidade não é a mesma que a sua. Quantas vezes vou ter que repetir que é o meu cliente que foge de mim, e não o contrário? Essa pelo visto é uma realidade que vc desconhece.

Aqui eu discordo completamente. Estou com inveja de vc, sério. Sem ironia, amigo. Vc tem a sorte de trabalhar com pessoas de alto nível, que devem ter uma formação exemplar, alta cultura e sabem expôr brilhantemente para leigos o funcionamento de seus negócios.

Eu já tenho que trabalhar com muitos aventureiros que “metem as caras” sem nem mesmo saber algo sobre tocar um boteco. Novamente, que minha alma queime no inferno se eu estiver mentindo!

Enfim, a nossa realidade é diferente. O que funciona na sua realidade não vai funcionar na minha e vice-versa, sr. YvGa.

Mark, vc tem razão. É exactamente este o ponto da questão. Ainda é muito díficil à maioria aceitar isto. Aceitar que o cliente não tem razão. O Cliente tem necessidade, não “razão”.
Se nós podemos suprir a necessidade, otimo. Se não, adeus e até à próxima. É também uma forma de educar as pessoas.

Vc deu o exemplo tipico. O cara chegar e quer o software completo num prazo impossível (tipo uma semana). O que é ético aqui ? Informá-lo que não vai dar. Por preço nenhum.
O cara vai reclamar. Vai achá-lo um fraco. Isso até que ele ache um carinha que faça em uma semana em PHP e depois o cara se estrepe todo. Ai ele vai entender que vc não estava mentindo e provavelmente irá voltar para o procurar. Porquê ? Porque vc mostrou ética. Não o enganou.

Por outro lado, o que acho que o YvGa está tentando dizer é que neste mesmo cenário: O cara chegar e quer o software completo num prazo impossivel (tipo uma semana). O que é ético aqui ? Perguntar-lhe o que realmente ele precisa. Fazer uma lista. Falar para o cara ordenar a prioridade. Dizer-lhe que eu uma semana não dá nem para o primeiro item. Mas que talvez o primeiro item dê para fazer em X tempo. Ver o que cliente acha disso. Se o cara aceitar, vc tem trabalho, ele tem a parte do software que mais lhe interessa e nasce uma relação. Se o cara vai querer continuar e fazer o resto das features ou não é irrelevante neste ponto. Foi apenas uma ferramenta usada para chegar na necessidade do cliente. É a mesma coisa que antes, mas a versão mais longa

No fundo estão dizendo o mesmo.

oi,

Acho que eu sou muito pessimista com relação à mudança deste quadro que as pessoas estão colocando aqui…

Primeiro porque eu acho que o cliente “não quer” alterar a visão que ele tem do processo de desenvolvimento do SW.

Segundo porque as pessoas que teriam condições de quebrar este “paradigma” (gerentes/administradores/etc) a maioria das vezes não têm ou não querem alterar esta visão.

Resumindo, se as coisas funcionam assim é porque estão ganhando dinheiro com isso (clientes e empresas que desenvolvem SW).

E isso só vai alterar um dia quando alguem aprender a ganhar mais dinheiro desenvolvendo SW da forma “correta”

Não estamos dizendo a mesma coisa. Vc falou muito bem dessa ideia difundida de que “o cliente tem razão” (grande idiotice, aliás). Eu defendo a ideia de jamais se dobrar ao cliente, como se somente eu dependesse dele (e não ele de mim). Já ele defende uma visão parecida com “faça o que o cliente quer”. Já fui muito conciliador com cliente afobado, e garanto que isso não funciona. Quanto mais ele vê que sou capaz, mais abusa do peão da fábrica de software aqui. Eles são vorazes.

Pra informação do YvGa, hj mesmo eu liberei o cadastro de produtos da loja virtual que o cara queria pronta em “uma semana”. Ele já tem código rodando lá. Se tiver algum bug, ele vai me reportar.

O que me deixou profundamente irritado é que esse cara insinuou trocentas coisas sobre a minha forma de trabalhar que não tem nada a ver com o que eu prego aqui. Mas bem, deixemos isso para lá. Quem quiser software para amanhã, peça para ele que eu já estou de serviço até o pescoço

Ok, então, falha minha em não entender o que você realmente está querendo dizer. Apenas mais um exemplo de como é difícil a comunicação sem algo concreto no que se basear.

Nem eu disse que fazia, repare que há um deve se tomar cuidado, nessa frase aí. E repeti muitas vezes o cuidado com a busca da proporção entre as coisas. Em nenhum momento eu disse que você está fazendo isso certou ou errado. Repare que várias vezes eu disse claramente que concordava com você, mas com ressalvas. Estas ressalvas são mais para quem lê do que para você propriamente.

Eu já disse, eu não discordo de você quanto a ser firme com o cliente, mas do jeito que você põe as coisas a impressão que me passa é que é você contra eles. E você mesmo deve saber que não é. Sim, existem alguns metidos a sabichões que podem querer te explorar, mas um cliente quando te contrata, normalmente ele tem um problema e quer vê-lo resolvido, e vai fazer o que for preciso para que aquilo seja de fato resolvido. Essa é a experiência que eu tenho, pouquíssimas vezes trabalhei com clientes que não colaboravam. E quando trabalhei foi em situações bem específicas. Claro que eu tenho que entender quando estou lidando com um cara que é responsável por um setor com 400 pessoas. O ponto é que ao surgir uma dúvida eu não fico esperando a resposta dele para continuar meu trabalho, eu assumo algumas possibilidades, implemente e levo pra ele avaliar. Ele pode apontar uma delas como a correta, ou dizer que todas estão erradas e me explicar a certa.

Então, não, eles não estão sempre ali, mas eu não fico esperando pra seguir o caminho. Agora eu acho muito estranho alguém contratar outra pessoa, investir dinheiro e não ligar pra isso durante o processo. Eu raramente vi isso, e já se vão mais de 10 anos desenvolvendo. Ou você tem muito azar, ou eu tenho muita sorte. Ou ainda você está num nicho de mercado que favorece este tipo de coisa.

Mas sendo assim você está certo em tomar mais cuidados mesmo.

E não eu não acho que você é um não cumpridor de prazos, você acabou levando exemplos para o lado pessoal. Mas não são, eu digo você no sentido genérico, pode ser você, mas pode ser eu, ou pode ser qualquer um.

Nem eu disse que fazia, esse você está dentro de um contexto e é um exemplo de como funciona a visão tradicional de “coleta” de requisitos.

Quando eu disse perder oportunidades, eu disse oportunidades de fato, não uns trocados de um sem-vergonha que só quer te explorar pra gastar pouco dinheiro. As vezes o cliente é um cara sério, que precisa de uma emissão de NF em um mês, mas acha que precisa de um ERP em um mês. E isto sim é uma oportunidade perdida, porque onde todo mundo diz que não dá, você entrega.

Prova de que você levou a discussão pro lado pessoal, este post sequer era resposta a um seu. E não era acusatório, foi um exemplo genérico. E este comportamento aí não é exceção infelizmente. Muitas empresas utilizam-se do “software é assim mesmo”, para explicar os atrasos e bugs.

Não é que os clientes entendam e sejam todos maravilhosos, mas normalmente eles não se negam a participar (claro que voce nao ficar ligando de 15 em 15 minutos, nem marcar reuniao todo dia), mas eles normalmente são solícitos em tirar suas dúvidas.

Legal, tirou totalmente do contexto, hein?

Como eu disse sempre, eu concordo com ressalvas. E essa sua realidade é realmente algo que eu desconheço.

Não, não trabalho somente com clientes ultra top high cultos e inteligentes. Mas eu digo que normalmente eles sabem o que querem porque eles sabem o que é necessário, afinal o negócio é deles. Eles sabem o tem que ser feito para que a coisa melhores (ou pensam que sabem), e sabem exatamente onde aperta o calo. O problema é que eles não sabem explicar isso em software. E aí começa a nossa falta de entendimento com eles.

Talvez sim, talvez não.

MarkKnopfler:

Já ele defende uma visão parecida com “faça o que o cliente quer”. Já fui muito conciliador com cliente afobado, e garanto que isso não funciona. Quanto mais ele vê que sou capaz, mais abusa do peão da fábrica de software aqui. Eles são vorazes.

Mas nem de longe eu disse isso, nem de longe. O que eu disse é que não é nós x eles, que você aponta.

André Fonseca:

oi,

Acho que eu sou muito pessimista com relação à mudança deste quadro que as pessoas estão colocando aqui…

Primeiro porque eu acho que o cliente “não quer” alterar a visão que ele tem do processo de desenvolvimento do SW.

O que o cliente quer ou não quer em relação ao nosso processo de desenvolvimento é “irrelevante”. Nós não lhe dizemos como ele tem que fazer o negocio dele, ele tb não pode nos dizer como fazer o nosso.
A visão que o cliente tem pode ser igual à sua ou não. Se é , ótimo. Se a visão for errada os dois se dão mal. Se não é, vc vai tentar mudar a visão dele para ser igual à sua. Dependendo da real necesidade que o cliente tem, ele irá entrar na sua ou não.
O ponto é que , aos poucos, levando um não daqui e da li os clientes vão começar a pensar “põ, estes caras no software já não é na pressão e na gamb como antes. tenho que conversar mais com eles”.

O cliente não quer alterar a visão ? Vc altera por ele.

Ora ai que está. Eu falei disso também em algum ponto e concordo. Mas o que eu acho que se estivermos à espera desses ai, nunca mais vai acontecer. O pessoal que é autônomo pode escolher melhor e mudar de paradigma primeiro pq tem mais flexibilidade. O resto, tem que se filiar a uma empresa que siga o novo paradigma. Onde estão essas empreas ? bom ai que está o X da questão. Eu espero que a tendencia é que as novas gerações de empreendedores na área de software sejam educados no novo paradigma, e com isso eles criem empresas nesse paradigma. O novo paradigma dá mais dinheiro que o outro. Isso é certo. Não apenas porque tem menos desperdício mas porque o cliente sente mais ética e por isso volta para fazer outras coisas. A ideia de que software bom é software caro está mudando. E tem que mudar ainda mais. Software bom, é software que faz o que cliente quer, como ele quer, e não lhe custa desperdício. Independentemente do preço.

O ponto que sobra, então, é se conseguimos ou não educar as novas gerações no novo paradigma ( que como falei antes, é “O Paradigma”, e sempre foi esse, o pessoal da industria que o disvirtualizou. então é mais voltar ao paradigma certo, e menos mudar de paradigma) . Além disso existe a questão se a nova geração quer realmente ser educada no que é ético ou se quer continuar perseguindo o elefante branco do dinheiro fácil.

O trabalho de educação está em curso. As pessoas ouvem cada vez mais falar de ágil. Já estamos no estágio em que Ágil é conhecido no sentido que o pessoal sabe que ele existe. Agora partimos para o estágio de fazer entender o que Ágil realmente é e o que significa. Depois iremos para como praticá-lo corretamente e finalmente para processos “out-of-the-box” que nos colocam no caminho certo, como Scrum.

cliente prestativo e bom de lidar = sou a favor.
cliente agressivo, quer tudo pra já = não pego serviço (e ainda faço questão de pôr ele no lugar)

Em resumo: sou contra eles mesmo

Bom,
acho que o sergiotaborda resumiu bem o ponto proposto pelo YvGa.

Um outro ponto é que o própio termo “cliente” se refere a algo muito generico (apesar dissso existe um ponto em comum entre eles).
Para um cliente externo as vezes é mais fácil demonstrar o valor e o melhor retorno na adoção das interações curtas, foco no resultado e etc. Creio que ele vai aceitar naturalmente se o analista tiver a competência necessária para demonstrar o valor desta abordagem. Não é questão da equipe engolir tudo que o cliente propõe. Na verdade é exatamente o contrário.

Quando tratamos de clientes interno em uma empresa com uma estrutura de TI com uma cultura fortemente baseada na ideia das fabricas e departamentalizada, a situação se complica um pouco mais.
Mudar a cultura de um ambiente tão complexo e tão grande é algo que parece impossível. Ao mesmo tempo sabemos que os valores e a cultura ágil, que valorizo muito, não pode ser simplesmente empurrada de cima pra baixo e ao mesmo tempo parece ser também impossível de acontecer de baixo pra cima. Criticar a posição do gerente que adota o modelo tradicional de gestão é muito fácil, mas acho que se observamos mais de perto a situação pensariamos das vezes antes de falar qualquer coisa com tanta certeza.
Nesse ambiente para um entusiasta da cultura ágil sozinho não resta muita alternativa a não ser ele ir aos poucos demonstrando o valor de cada principio.
Minha opinião é que primeiro é preciso demonstrar a competência técnica antes de qualquer coisa. Após conseguir o ‘respeito’ e reconhecimento dos dos lideres ele vai ser capaz de sugerir qualquer coisa em beneficio da equipe e ter a sugestão aceita.
O segundo problema é que ele não vai ter um passo a passo pois cada empresa funciona de uma forma. Livros práticos como ‘scrum direto das trincheiras’ pode até ajudar a ter uma ideia, mas é preciso ter muito cuidado pra não cair na tentação de aplicar o que é aplicado lá e ignorar a realidade da organização.
O mais importante mesmo é descobrir como atender aos principios ageis no ambiente em que se encontra. Não tem receita de bolo pra isso.

A própria expressão “desenvolvimento Ágil” talvez seja outra metáfora que deveríamos abolir (ou nem é metáfora, é ao pé da letra mesmo??)
Se um cliente apressadinho ouve falar nisso, tá feita a m**** hahahaha
E continuo sem entender pq o YvGa fala tanto mas não fala para mim onde ele mora, visto que ele tem poucos problemas com os clientes dele. Não é ele que é sortudo, nem ele que é azarado, é simplesmente o contexto onde cada um trabalha.

MarkKnopfler:

A própria expressão “desenvolvimento Ágil” talvez seja outra metáfora que deveríamos abolir (ou nem é metáfora, é ao pé da letra mesmo??)
Se um cliente apressadinho ouve falar nisso, tá feita a m**** hahahaha
E continuo sem entender pq o YvGa fala tanto mas não fala para mim onde ele mora, visto que ele tem poucos problemas com os clientes dele. Não é ele que é sortudo, nem ele que é azarado, é simplesmente o contexto onde cada um trabalha.

É verdade que o termo “Desenvolvimento Ágil” não é dos melhores.
Mas acho que ele serve mais como uma prova que o problema nem é tanto os simbolos ou as palavras, mas sim as ideias que elas trazem.

No caso de “Desenvolvimento Ágil” a idéia de velocidade só vem à mente daquele que não faz a menor ideia do que ele realmente significa.

MarkKnopfler:

A própria expressão “desenvolvimento Ágil” talvez seja outra metáfora que deveríamos abolir (ou nem é metáfora, é ao pé da letra mesmo??)
Se um cliente apressadinho ouve falar nisso, tá feita a m**** hahahaha
E continuo sem entender pq o YvGa fala tanto mas não fala para mim onde ele mora, visto que ele tem poucos problemas com os clientes dele. Não é ele que é sortudo, nem ele que é azarado, é simplesmente o contexto onde cada um trabalha.

Moro em Curitiba-PR, mas não creio que isso faça realmente diferença.

vou te indicar um cliente de Pouso Alegre-MG, topas ou vai arregar na primeira tentativa do cara de te enrolar

(sim, isto é um alerta para todos que nunca visitem isto aqui :D)

MarkKnopfler:

vou te indicar um cliente de Pouso Alegre-MG, topas ou vai arregar na primeira tentativa do cara de te enrolar

(sim, isto é um alerta para todos que nunca visitem isto aqui :D)

Um não é problema, seriam exceções. Você conseguiria me indicar 5 desses que querem tudo pronto e não querem nada com nada?

Indico esse da loja de 1 semana, o de um sistema de integração entre skydrive e clipper (!!), e uns 5 ou 6 clientes do primeiro. Se eu te passar o primeiro, vc já ganha esses 5 ou 6 (talvez +) de lambuja. Quer?

YvGa:

MarkKnopfler:

vou te indicar um cliente de Pouso Alegre-MG, topas ou vai arregar na primeira tentativa do cara de te enrolar

(sim, isto é um alerta para todos que nunca visitem isto aqui :D)

Um não é problema, seriam exceções. Você conseguiria me indicar 5 desses que querem tudo pronto e não querem nada com nada?

Cara, realmente esse tipo de situação é excepcional, mas já vi acontecer de perto. Normalmente fica bem claro logo no inicio o interesse do cliente em derrubar o projeto.
A situação que presenciei aconteceu pois a TI teve que empurrar uma solução para uma área funcional que havia acabado de receber uma competência que eles achavam que deveria ser de outra área.

No geral a situação é mesmo de desconhecimento do cliente sobre custo e esforço de desenvolvimento e isso pode ser contornado com o desenvolvimento ágil.

Eita, onde vcs moram? Vamos trocar nossas carteiras de clientes? hehehehehe
Sério, não é tão excepcional assim não. Pelo menos aqui na minha região.
Eles são cheios de vir falar “é bem simples, é só X”, e depois q vc começa descobre que é “x ao quadrado vezes 100”.
Eu sou, sim, a favor do desenvolvimento iterativo e incremental justamente por evitar grandes retrabalhos provocados pela falta de informação sobre o negócio deles. Mas o que o Manifesto Ágil diz já tromba um pouco com a minha opinião - não que eu discorde, mas que eu veja com “ressalvas”.

1o. problema:

Vc está falando dos clientes ou dos desenvolvedores? Pq é coisa da nossa área, os clientes em 99,99999% das vezes não sabem o que significa. E algo que era para significar “sem burocracia desnecessária e processos complexos” passa a significar “velozes fazedores de milagres”.

2o. problema (tirado do Manifesto):

Colaboração com o cliente mais que negociação de contratos

Aqui estou me expondo à polêmica. Esse cara não quer colaborar com o cliente, quer só receber o $$$!!!
Bem, como dizia meu amigo Einstein, tudo é relativo. Para entender, releiam meus relatos sobre como vivo às turras com gente metida a esperta. Vcs parecem (ou pelo menos me passam isso) que não têm esse problema - não na quantidade que eu tenho. Se eu me preocupar em simplesmente “colaborar com o cliente” e dane-se se ele quer ou não pagar o preço justo da minha colaboração desapegada (noites em claro e etc.), rapidamente terei que penhorar as minhas calças.

A metodologia Ágil é bacana (só podia mudar de nome, vamos arrumar outra metáfora :D). Mas ela não vai resolver todos os problemas e é difícil aplicar todos os seus princípios no meu contexto.
Parece-me que ela também já virou um hype (indico este post do Kico - http://www.itexto.net/devkico/?p=1148 )

Cara, bem que eu gostaria de ter tempo pra isso. Gostaria mesmo, talvez menos por satisfazer seus cliente e mais para ter os meu próprios. Mas infelizmente não tenho, sou funcionário e o tempo livre não me permite que assuma prazos.

Mas se você ansia tanto assim em provar a maldade dos seus clientes porque não os convida para o debate? Ou me passe os emails de alguns deles e vejamos o que eles pensam sobre isso.

MarkKnopfler:

Vc está falando dos clientes ou dos desenvolvedores? Pq é coisa da nossa área, os clientes em 99,99999% das vezes não sabem o que significa. E algo que era para significar “sem burocracia desnecessária e processos complexos” passa a significar “velozes fazedores de milagres”.

2o. problema (tirado do Manifesto):

Colaboração com o cliente mais que negociação de contratos

Aqui estou me expondo à polêmica. Esse cara não quer colaborar com o cliente, quer só receber o $$$!!!
Bem, como dizia meu amigo Einstein, tudo é relativo. Para entender, releiam meus relatos sobre como vivo às turras com gente metida a esperta. Vcs parecem (ou pelo menos me passam isso) que não têm esse problema - não na quantidade que eu tenho. Se eu me preocupar em simplesmente “colaborar com o cliente” e dane-se se ele quer ou não pagar o preço justo da minha colaboração desapegada (noites em claro e etc.), rapidamente terei que penhorar as minhas calças.

A metodologia Ágil é bacana (só podia mudar de nome, vamos arrumar outra metáfora :D). Mas ela não vai resolver todos os problemas e é difícil aplicar todos os seus princípios no meu contexto.
Parece-me que ela também já virou um hype (indico este post do Kico - http://www.itexto.net/devkico/?p=1148 )

Cara, ninguem ta dizendo que você tem que fazer as coisas de graça ou por um preço ridículo. Você tem que cobrar caro sim, principalmente se conseguir fazer mais rápido que outros e o prazo tem que ser justo. Mas justo para os dois lados.

Eu gostaria de ouvir mais opiniões sobre essas relações com clientes. Se a maioria concordar com você, talvez realmente seja sorte, ou inocência minha. Se a maioria concordar comigo talvez o problema esteja na forma como você está se relacionando com seu clientes.

Não digo que não existam espertinhos, mas o que a maioria quer é só um software para ajudar no seu dia a dia, se funcionar bem é um diferencial.

MarkKnopfler,

Quando falei sobre o entendimento do termo falava tanto de cliente quanto de desenvolvedor, mas cabe ao desenvolvedor orientar o cliente sobre o que se trata.

No fim a proposta do desenvolvimento ágil pode se resumir em diminuição do risco do projeto e isso significa diminuir as chances de prejuizo não só para o cliente como também para o desenvolvedor. É só isso.

Uou.
Um baita texto e uma baita discussão.
Fiquei uns dias foras mas encontrei isso aqui na volta, parabéns Kico pelo texto e os demais pela discussão.

oi Sérgio,

Eu concordo que estamos passando por uma mudança na visão de como se desenvolve SW.
Só acho que quem vai ditar essa mudança é o mercado .
E acho que isso vai acontecer quando:

:arrow: fornecedores de SW conseguirem comprovar que desenvolver SW de maneira caótica não irá agregar valor ao cliente

:arrow: consumidores de SW perceberem que para conseguirem ganhos maiores terão que se organizar de forma diferente para receber o produto/serviço final adequado

Abs

PS: bom seu artigo

André Fonseca:

oi Sérgio,

Eu concordo que estamos passando por uma mudança na visão de como se desenvolve SW.
Só acho que quem vai ditar essa mudança é o mercado .
E acho que isso vai acontecer quando:

:arrow: fornecedores de SW conseguirem comprovar que desenvolver SW de maneira caótica não irá agregar valor ao cliente

:arrow: consumidores de SW perceberem que para conseguirem ganhos maiores terão que se organizar de forma diferente para receber o produto/serviço final adequado

Abs

PS: bom seu artigo

Cabe a nós comprovarmos. Esperar iniciativas do lado de lá é o caminho para o fracasso (não discordando do que o André Fonseca falou, mas só comentando em cima). Eles não vão “perceber” as coisas tão natural e facilmente.

E ainda tô achando estranho o sr. YvGa ficar duvidando da existência em massa de clientes extremamente agressivos e pressionadores. Vc é funcionário, acho que seu patrão deve saber bater o pé quando o cliente vem com missões impossíveis. Eles vão procurar outro desenvolvedor e vc acaba nem vendo a cara deles. Será que é isto?

Falando do assunto em questão e levando em consideração o que foi dito antes:

Sei exatamente que é isso, é tenso falar de prazos, pois muitas empresas, para não dizer quase todas, não enchergam o homem e sim um “cuspidor de código”, uma maquina geradora de software, onde prazos são absolutos e que tudo deve dar certo até o momento da estreia.

Prazos devem existir para gerar uma meta, porém eu nunca vi ou conheci um caso de sucesso onde o cliente comprou um sistema a ser feito do zero e no final falarem: “Entregamos o sistema no prazo E o sistemaesta funcionando perfeitamente, onde nosso cliente esta satisfeito”.

O ironico que os casos que conheci onde houve o atraso e o setor de teste do sistema atuou forte, quando chegou ao cliente, gerou satisfação, pois quase sempreo cliente aceita o atraso, o que ele não vai aceitar é receber algo ruim, problematico, inacabado.

Sistema não é um slide em Power point, apresentou acabou, mas é um objeto que sera usado e destrinchado pelo cliente, o que torna a entrega muito mais complexa.

Dar prazo curto dentro e fora do ambiente de desenvolvimento é ruim.

Tem cliente que é agressivo e tem empresas que são agressivas com seus desenvolvedores, nos dois cass isso é ruim

MarkKnopfler:

E ainda tô achando estranho o sr. YvGa ficar duvidando da existência em massa de clientes extremamente agressivos e pressionadores. Vc é funcionário, acho que seu patrão deve saber bater o pé quando o cliente vem com missões impossíveis. Eles vão procurar outro desenvolvedor e vc acaba nem vendo a cara deles. Será que é isto?

Não, não é isso, eu vejo a cara deles sim. E muitas vezes sou que tenho que negociar os prazos, baseado nos levantamentos que eu mesmo faço, sou eu que negocio a entrega, como vai ser feito, como será o desenvolvimento, como eles irão participar e etc… (Quando eu digo eu, quero dizer a equipe de desenvolvimento, sejá quem for o responsável pelo projeto, ele é sempre um analista/desenvolvedor).

Aliás, esse papel do cliente malvado que quer tudo pra ontem é muito bem executado aqui pelo pessoal do comercial. É com eles que temos que brigar para não aceitar tudo pra ontem.

Eu eu já vi muitos, de vários segmentos, de vários portes, públicos, privados, botecos, multinacionais e raras vezes encontrei situações em que eles não queriam colaborar. Muitas vezes, muitas mesmo, por opção nossa, passamos semanas desenvolvendo no próprio escritório dos clientes, devido a proximidade com os usuários.

Então, amigo, eu sem bem do que estou falando.

Você está criando uma falsa dicotomia. Um autor não senta na frente do editor de texto e escreve o romance todo de uma vez. Nem tampouco faz uma lista dos capítulos a serem entregues de acordo com um prazo imaginário.

Exatamente! A questão é que o tempo necessário de análise e projeto continua sendo fundamental. Mas é só falar em “análise e projeto” que o pessoal defensor do chamado “desenvolvimento ágil” já interpreta como “vamos gastar um tempão analisando o software todo já no início para não termos que ter trabalho depois”. Eles torcem o nariz para o termo que chamam de “tradicional” e não conseguem encaixá-lo em nenhum contexto.

Se o desenvolvimento é incremental, e eu vou entregar primeiro só a funcionalidade que mais interessa ao cliente, então eu vou precisar de um tempo para entender e fazer uma boa análise dessa funcionalidade X que vai resolver o problema mais urgente dele. Se o cliente colabora e me passa o máximo de informações que pode, eu posso projetar em cima daquilo e em poucos dias levar algo rodando para ele. Se não, a coisa complica. No meu caso, simplesmente não é possível (e eu me recuso a) fazer suposições, criar várias implementações diferentes que eu sei que depois ele vai falar “não é nada daquilo”. O meu tempo não é grátis, não. Claro que sempre vai ficar faltando alguma coisa que só se descobre depois, mas se ele me passar a base daquilo que ele quer, o que sobra pra mudar são mais questões de interface (“dá pra fazer já cair no campo tal quando eu clico Incluir?”) e poucas de negócios (“mas esse cálculo tinha que ser assim”).

Eu tento fazer o cliente entender que eu simplesmente não topo:

• sair codificando correndo só pra ver funcionando (porque vai me dar uma senhora dor de cabeça, e para ele também, quando precisar que mude algo)
• ter retrabalho devido à indecisão/falta de esclarecimento da parte dele

Ou o YvGa tem muita sorte dos clientes dele colaborarem, ou eu tenho muito azar. Porque muitos que eu tenho não colaboram mesmo, ou colaboram de uma maneira porca, sempre apressados, respondem correndo e esperam que eu adivinhe detalhes do negócio que é deles, e não meu.

Manda um currículo meu pra sua empresa que eu quero trampar aí

Ah, vc desfez minha ilusão! Isso não se faz com um jovem idealista! Eu já estava pensando que aí não tinha nenhuma pressão… Agora pare e pense um pouco: pq o comercial pressiona vcs? Só de sacanagem, ou porque é a eles que o cliente pressiona diretamente?

Pessoal, voces estão distorcendo as palavras do YvGa. Isso não leva a lugar nenhum.

O que ele está afirmando é só que é possível ver o cliente como colaborador do projeto e não como um adversário. Ou seja, é posível construir a solução junto com o cliente (e de fato é, apesar de não parecer).
Qual cliente vai querer derrubar o próprio projeto conscientemente? (Eu citei anteriormente um exemplo em que isso aconteceu, mas isso foi uma grande exceção).
Lógico que o cliente vai cobrar e vai querer a coisa funcionando e da melhor forma possível, mas a gente que é desenvolvedor sabe que nem sempre tudo que o cliente pede é de fato o que ele precisa. Todo projeto envolve trocas e escolhas de prioridade já que existe um limite tanto de custo quanto de tempo. A equipe diz o que pode fazer no projeto com essas restrições fixadas e o cliente diz as prioridades. É simplesmente isso.

Não tem isso de cliente bonzinho ou cliente malvado. Cliente é cliente e quer saber de ganhar dinheiro com o que vamos construir e só disso. Não vejo pq ele deveria pensar de outra forma.
Ele não quer saber se tu vai precisar fazer analise ou testar o sistema, ou se a tela x ou y ta dando erro. Ele que saber é do retorno daquilo que ele investiu e de preferência o mais rapido possível.

Tempo é uma restrição e desse fato não tem como correr. O gasto do tempo com planejamento e analise deve ser limitado e o limite é justamente até o ponto onde aquilo realmente compensa para o retorno daquilo que o cliente investiu. Se para desenvolver o software vai levar mais tempo do que o que minha necessidade pede, então eu não preciso do software. É simples assim.

O desenvolvimento ágil simplesmente tenta diminuir os riscos do projeto. Pra reduzir o risco uma das necessidades é que a equipe veja o cliente como um colaborador e não como um adversário a ser vencido. Ao mesmo tempo existem algumas ferramentas e tecnicas que podem ser adotadas para trazer o cliente para perto do time (ou seja, virar um colaborador). O que vai justificar essa transformação é simplesmente a vontade do cliente em ter o máximo de retorno no que ele mesmo investiu. Qual cliente que faz questão de perder dinheiro? Esse sim eu nunca vi.

immortalSoul:

Pessoal, voces estão distorcendo as palavras do YvGa. Isso não leva a lugar nenhum.

O que ele está afirmando é só que é possível ver o cliente como colaborador do projeto e não como um adversário. Ou seja, é posível construir a solução junto com o cliente (e de fato é, apesar de não parecer).

Não se preocupe que distorções acontecem aqui a todo momento, eu já nem ligo

Sério que o cliente pode colaborar com o projeto? Essa eu não sabia

Amigão, quando falo do cliente xarope que não colabora, em nenhum momento eles querem “derrubar” o projeto, como vcs dizem. Se eles quiserem me sacanear dessa forma, eu deixo, desde que me paguem todas as horas trabalhadas. O que lhes falta é a noção da importância de participar.

Só que temos um ponto de discordância o qual não adianta ficarmos discutindo:

Então tá, se ele for médico e de repente eu tiver câncer, eu quero a solução o mais rápido possível, afinal estou investindo (= pagando).
Se ele for advogado, é para ele ganhar a causa e o mais rápido possível, que eu não quero ter que ficar pagando honorários.
Se ele for …

É esse tipo de atitude que deseduca os clientes!

Agora uma coisa q vc falou eu concordo:

Se ele não quiser aceitar a condição que eu coloco, ele não é obrigado. Ele pode desistir do software se quiser, procurar outra solução, ou procurar outra empresa/desenvolvedor que tenha tempo e recursos para fazer no prazo que ele quer.

Então você é agil cara, sem ter precisado dar nome aos bois. O que eu não gosto é de não ter o que mostrar para o cliente depois de 2, 3 semanas de projeto e ainda dar um documento pro cara assinar “se responsabilizando” pelo que ele pediu, sabendo que isso vai mudar e que a percepção do cliente quando ver o software, também vai mudar.

É essa etapa que o Agil retira, não a análise e o projeto. O problema é, se você deixa pra codificar e prototipar tarde demais, seu feedback virá tarde demais e não importa quantos documentos você tenha em mãos assinados pelo cliente, Software funcionando é o que vale.

MarkKnopfler:

Ou o YvGa tem muita sorte dos clientes dele colaborarem, ou eu tenho muito azar. Porque muitos que eu tenho não colaboram mesmo, ou colaboram de uma maneira porca, sempre apressados, respondem correndo e esperam que eu adivinhe detalhes do negócio que é deles, e não meu.

Manda um currículo meu pra sua empresa que eu quero trampar aí ;)

acho que os clientes são do mesmo tipo e talvez (aqui estou supondo) a abordagem possa até estar sendo parecida… Tenho hoje os 2 tipos de clientes, os que querem burocratizar e precisam burocratizar por causa dos seus modelos “imutáveis” de negócio e os que entendem a abordagem e topam logo de cara…

Enfim.

Quanto ao tema de metáforas, é uma pena que o ser humano precise de nomenclaturas e figuras para entender um conceito… agil não deveria ter nome, deveria somente o SER.

Belo Post Kiko, precisamos de metáforas, mas eu sinceramente as odeio.

Tá vendo, immortal, como distorções acontecem a todo momento?
Sobre a etapa de análise e projeto (2o. parágrafo), eu não falei de desenvolvimento ágil, eu falei de “incremental”. Eu não pratico desenvolvimento ágil (agora que o Kico falou sobre o problema da linguagem, me dá calafrios falar um nome desse pra alguns dos meus vorazes clientes), pratico muitas vezes desenvolvimento incremental. E sim, eu faço questão de fazer análise e projeto de cada fase.
Mas como eu disse, é só falar “análise e projeto” que vcs torcem o nariz e acham que vou ficar “perdendo um tempão”. Putz, eu vivo refatorando código, cara! Não analiso e projeto tudo do jeito que ficará no resultado final (de cada etapa, tenho que ficar martelando). E qual é o crime de tirar um dia pra pensar antes de fazer as coisas?

Tem alguns problemas com essa analogia (são situações diferentes), mas o maior é que o nosso trabalho é somente o meio e não um fim.
Advogados e médicos trabalham em algo que poderiamos chamar de fim da ‘cadeia de valor’, mas esse não é o nosso caso.
No geral o cliente não ta interessado diretamente no que produzimos, mas no que ele vai poder ganhar quando aquilo que ele está investindo estiver pronto.
A preocupação principal do cliente é o risco do negócio. Ela não está preocupado só se o sistema vai ficar pronto, mas também se depois de pronto aquilo realmente vai gerar algum lucro pra ele.
A TI é só um detalhe no negócio dele (um detalhe importante, mas ainda assim um detalhe).

Uma das propostas do ágil é fazer com que a equipe de desenvolvimento pare de olhar somente para a TI de forma isolada e passe a olhar o negócio como um todo. O foco no retorno sobre investimento (ROI) é justamente isso. Um programa, funcionalidade ou caracteristica desenvolvida não significa nada a não ser que traga algum retorno para o cliente.

O ROI é o objetivo do cliente da mesma forma que a cura da doença é objetivo do doente. Se o paciente paga um médico é pq quer a cura e se um cliente paga uma equipe de desenvolvimento é pq quer o ROI.

JoseIgnacio:

YvGa:

Eu não vou sentar na frente de uma ferramenta case e montar todas as tabelas do sistema, fingindo que as informações que eu tenho já me são suficientes, ou me julgando o mestre dos analistas de sistema, capaz de com não mais de meia dúzia de reuniões, entender completamente como o negócio do meu cliente funciona.

Você está criando uma falsa dicotomia. Um autor não senta na frente do editor de texto e escreve o romance todo de uma vez. Nem tampouco faz uma lista dos capítulos a serem entregues de acordo com um prazo imaginário.

E onde eu disse que é assim que tem que ser feito? Acho que vocês estão se confundindo.

O fato de o que fazemos para eles ser um meio e não um fim, não justifica, a meu ver, essa cobrança muitas vezes descabida da parte deles. Então o que é fim deve ter seu tempo respeitado, mas o que é simplesmente “meio” não??

Claro que o foco é o retorno sobre o investimento (ROI), se eu desenvolvo é porque aquilo vai agregar valor para ele, e não para mim. Mas o que vcs chamam de “foco” muitas vezes eu chamaria de “obsessão”. Por que, cá entre nós, quando vcs vão contratar algum serviço, vcs acreditam quando o prestador promete “o que vc queria”?

Eu não.

MarkKnopfler:

Tá vendo, immortal, como distorções acontecem a todo momento?
Sobre a etapa de análise e projeto (2o. parágrafo), eu não falei de desenvolvimento ágil, eu falei de “incremental”. Eu não pratico desenvolvimento ágil (agora que o Kico falou sobre o problema da linguagem, me dá calafrios falar um nome desse pra alguns dos meus vorazes clientes), pratico muitas vezes desenvolvimento incremental. E sim, eu faço questão de fazer análise e projeto de cada fase.
Mas como eu disse, é só falar “análise e projeto” que vcs torcem o nariz e acham que vou ficar “perdendo um tempão”. Putz, eu vivo refatorando código, cara! Não analiso e projeto tudo do jeito que ficará no resultado final (de cada etapa, tenho que ficar martelando). E qual é o crime de tirar um dia pra pensar antes de fazer as coisas?
Kico, socorro! Fanboys detected ;)

Pedindo ajuda? Por que? Ninguém aqui está concordando com sua visão de que os clientes são na maioria um bando de sacanas que só querem tirar proveito dos pobres programadores desamparados?

E chama quem não concorda contigo de fanboy? Eu sou fanboy? Fanboy de clientes colaboradores? Ou voce tem a mania de atacar quem não concorda contigo? Se for assim, o fato de você se deparar somente com clientes ruins tem explicação. Talvez sejam apenas pontos de vistas diferentes, aos quais você ataca como sendo uma visão inocente, de alguém inexperiente, algum fanboy ou que só fala patacadas, ou que só quer te sacanear.

Eu me retiro dessa discussão, não posto mais nesse tópico porque esta já é a quarta vez que você posta algo ofensivo, e de todas elas eu me esquivei e procuro responder somente aos argumentos. Mas você continua me “adjetivando”. Porém, repare como boa parte dos que postam, tendem a concordar mais comigo do que com você.

Se você não entende, ou não quer adotar práticas que eu uso no meu dia a dia é um direito seu, inquestionável. Mas não me chame de fanboy por eu ter uma visão diferente da sua.

Veja, em nenhum momento eu disse que você está errado na sua forma de trabalhar, o que eu acho errado é sua visão de nós vs os clientes. E mais ainda discordo de você atacar quem discorde de você simplesmente por você não conseguir convencê-lo do contrário.

Se você quer impor suas ideias na marra, e tenta rebaixar quem discorda, num fórum onde você não conhece quase ninguém, eu imagino o quanto você se irrita quando o que está em jogo é um contrato valendo dinheiro.

De resto, encerro por aqui minha participação.

Q isso, meu amigo, não pode brincar? Vamos tomar uma cerveja

Bem, já que o YvGa não volta +, vou continuar conversando com o resto do pessoal. Ainda que a maioria esteja concordando com o outro ponto de vista, estou achando muito interessante e produtivo.

E quem falou que eu não aplico as práticas de D. Ágil? Eu aplico sim, a maioria. Só não sou um ágil “oficial”, de carteirinha. Percebem a diferença?

Estão interpretando que eu sou contra meus clientes. Não sou contra a minha fonte de renda, jamais! Só que eu explico repetidamente o porquê dos meus pensamentos e vêm sempre de novo repetir a mesma coisa, como se eu já não tivesse falado nada sobre aquilo. Estão lendo meus posts inteiros ou dá preguiça pq são longos???

Agora, que eu acho q o desenvolvimento ágil está sendo visto como um hype, “A” solução para todos os problemas, acho que está sendo visto sim. O cara fez um post sobre o problema das metáforas, aí chega um grupo dizendo “é pq vc não pratica o desenvolvimento ágil, ele é a solução”. Aí eu falo das minhas dificuldades em pôr todos esses princípios na prática, que nem sempre eles se aplicam no meu contexto… Que bom q a solução que vcs adotam é útil para vcs, da mesma forma que a solução que eu adoto é útil para mim. Não podemos ser anacrônicos (google!) e achar que a realidade do cara com ideias estranhas é a mesma que a nossa. Se ele insiste naquelas ideias, por + estranhas que pareçam, deve haver alguma razão. E vcs entenderiam essa razão depois de 1 mês lidando com esse povo fresco com que eu tenho que lidar aqui.

YvGa: vou sentir sua falta, cara (sem ironia). Debate não tem graça sem alguém que discorde da gente

MarkKnopfler:

Tá vendo, immortal, como distorções acontecem a todo momento?
Sobre a etapa de análise e projeto (2o. parágrafo), eu não falei de desenvolvimento ágil, eu falei de “incremental”. Eu não pratico desenvolvimento ágil (agora que o Kico falou sobre o problema da linguagem, me dá calafrios falar um nome desse pra alguns dos meus vorazes clientes), pratico muitas vezes desenvolvimento incremental. E sim, eu faço questão de fazer análise e projeto de cada fase.
Mas como eu disse, é só falar “análise e projeto” que vcs torcem o nariz e acham que vou ficar “perdendo um tempão”. Putz, eu vivo refatorando código, cara! Não analiso e projeto tudo do jeito que ficará no resultado final (de cada etapa, tenho que ficar martelando). E qual é o crime de tirar um dia pra pensar antes de fazer as coisas?
Kico, socorro! Fanboys detected ;)

Eu tenho uma noticia para si: chame-lhe como quiser, mas o que vc está fazendo é Ágil. Digo mais, o espirito como que vc está fazendo é ágil.
Ágil significa continuamente inspecionar o que está com defeito e modificar para ficar sem defeito. “Defeito” pode ser desde bug até uma feature que o cliente quer mudar, acrescentar, remover, qualquer coisa.
Ágil não remove a necessidade de análise, bem pelo contrário. A analise é continua.
Além das inspeção, o ágil é feito em cima de transparência, e isso já ficou claro que vc tb tem e em cima de acrescentar valor. Tlv esta ultima parte do valor vc não procure conscientemente, mas acaba procurando inconscientemente quando vc dá sugestões.

YvGa:

MarkKnopfler:

Tá vendo, immortal, como distorções acontecem a todo momento?
Sobre a etapa de análise e projeto (2o. parágrafo), eu não falei de desenvolvimento ágil, eu falei de “incremental”. Eu não pratico desenvolvimento ágil (agora que o Kico falou sobre o problema da linguagem, me dá calafrios falar um nome desse pra alguns dos meus vorazes clientes), pratico muitas vezes desenvolvimento incremental. E sim, eu faço questão de fazer análise e projeto de cada fase.
Mas como eu disse, é só falar “análise e projeto” que vcs torcem o nariz e acham que vou ficar “perdendo um tempão”. Putz, eu vivo refatorando código, cara! Não analiso e projeto tudo do jeito que ficará no resultado final (de cada etapa, tenho que ficar martelando). E qual é o crime de tirar um dia pra pensar antes de fazer as coisas?
Kico, socorro! Fanboys detected ;)

Pedindo ajuda? Por que? Ninguém aqui está concordando com sua visão de que os clientes são na maioria um bando de sacanas que só querem tirar proveito dos pobres programadores desamparados?

Não todos , mas alguns. Existem clientes de todos os tipos. Isso é natural. Mas é claro a todos que existe ainda uma parcela muito elevada de maus clientes. E maus significa muitas coisas. Desde não pagar a tempo até não querer participar.
Software é diferente de outras areas neste aspeto. Vc precisa da participação do cliente. Não existe ficar isolado do cliente. Mas muitos clientes ainda acham que eles chegam e pedem um sistema XPTO e automáticamente vc sabe o que tem que ser feito. Não é assim.

Agora, vc pode tentar educar os clientes ou não. Acho que a dicotomia é essa. Depois que vc decide educar o cliente pode reagir mal a isso. Nesse caso vc faz uma escolha, ou abandono o cliente (merecidamente) ou tenta mais uma vez educá-lo.
É fato que os clientes assumem que pode pressionar. Cabe a nós explicar que não é assim, e se impor. O uso de metodologias ágeis remove a figura do tempo e trasnfere a responsabilidade de volta ao cliente. muitos se assutam com isso, outros adoram ter o controle. Ha gostos para tudo. O ponto é, existe sim diferentes graus de cliente e existem sim os muito ruins e os muito bons. Sendo que os muito ruins são a maioria e os muitos bom a minoria.

Cada a nós todos alterar este cenário. A única ferramenta é educação.

(Eu continuo achando que vc estão dizendo o mesmo , mas por alguma razão se perderam e acham que estão em campos opostos)

Aqui está o problema. A primeira coisa a entender é que existem um conjunto de valores que são maiores que todos nós. Este valores geram principios ( receitas para acção do dia a dia).
Não é uma questão de metodologia A ou B, e uma questão do Principio X ou Y ou do Valor W ou H.

No mundo existe um principio que poderíamos traduzir como “O cliente tem sempre razão”. Este principio tem vindo a se contrapor com outro “O cliente tem uma necessidade, não uma razão”.
Um outro principio seria “O cliente pergunta o prazo e vc se responsabiliza por ele”, atualmente outro principio emergir “O tempo é um numero de ciclo, o cliente escolhe quantos ciclos quer usar, e o que fazer em cada um”.

Atualmente a palavra que mais se aproxima de referir estes novos princípios é Ágil. Eu concordo que não é um bom nome e que ele está cheio de outras cosias que poluem os principios. Então vamos esquecer o ágil um pouco e focar nestes novos principios.

Dado que vc concluem que estes principios novos são melhores que os antigos, vc tenta aplicá-los. Ai vc bate com entraves e vc conclui “nem sempre se aplicam no meu contexto”. Quando eu digo “vc” é o “vc proverbial”, é qualquer um de nós na realidade.

É ai que entra a importância se estarmos falando de principios e não de metodologias. Dizer que vc não pode aplicar o principio 100% do tempo é o mesmo que dizer que vc pode não ser honesto 100% do tempo, ou que em algum momento é aceitável matar.
Isso é verdade. Existem exceções a todos os principios e a todos os valores. mas isso não significa que podemos nos relaxar em os seguir. É aqui que está o X da questão.

O mundo do desenvolvimento está consciente dos novos valores e até os quer usar, mas as dificuldades são muitas. Uma delas, como falamos aqui é a cultura dos clientes. Cultura essa que ai está baseada nos velhos principios que alias eles ajudaram a montar.
É natura que vai doer, tanto a eles quanto a nós, mas o ponto é que a mudança é necessária.

Ai caimos nesse de “a minha solução”. São essas soluções que precisam ser compartilhadas. Com cada um lida com os entraves e bloqueios de aplicar os mesmos principios. Sem desistir de os aplicar.

Isto estabelece muitos desafios. E existe muitos blogs correndo paragrafos sobre estes entraves. Cada uma dá o seu pitaco e todos são válidos se não violam os principios. Mas temos que dar um passo além. Temos que sintetizar essas descobertas empiricas em novos princípios e valores.

Ha um valor que mudou o paradigma , antes era “me dê seu dinheiro por este monte de códiog” , agora é “Como eu posso realizar um produto que o ajude”. O primeiro é mais vil e aproveitador, o segundo é mais orientado a um mercado de serviços. Mas muita gente ainda vive no primeiro paradigma - o chamado “tradicional” - e muitos querem mudar para o novo. E chama a isso (a à mudança) se tornar Ágil. E o Ágil fica sendo essa bandeira da revolução.

o Ágil é distorcido em muitas partes porque as pessoas ainda acham que se trata de uma metedologia e que portanto pode ser adaptada. Não é isso. É um conjunto de valores. Ou vc tem, ou vc não tem.
E desconsiderando todos os problemas de nomenclatura e branding, existe algo bom no final disso tudo a que chamam ágil. Então foquemos nisso , o resto é apenas um problema de linguagem.

sergiotaborda:

YvGa:

MarkKnopfler:

Tá vendo, immortal, como distorções acontecem a todo momento?
Sobre a etapa de análise e projeto (2o. parágrafo), eu não falei de desenvolvimento ágil, eu falei de “incremental”. Eu não pratico desenvolvimento ágil (agora que o Kico falou sobre o problema da linguagem, me dá calafrios falar um nome desse pra alguns dos meus vorazes clientes), pratico muitas vezes desenvolvimento incremental. E sim, eu faço questão de fazer análise e projeto de cada fase.
Mas como eu disse, é só falar “análise e projeto” que vcs torcem o nariz e acham que vou ficar “perdendo um tempão”. Putz, eu vivo refatorando código, cara! Não analiso e projeto tudo do jeito que ficará no resultado final (de cada etapa, tenho que ficar martelando). E qual é o crime de tirar um dia pra pensar antes de fazer as coisas?
Kico, socorro! Fanboys detected ;)

Pedindo ajuda? Por que? Ninguém aqui está concordando com sua visão de que os clientes são na maioria um bando de sacanas que só querem tirar proveito dos pobres programadores desamparados?

Não todos , mas alguns. Existem clientes de todos os tipos. Isso é natural. Mas é claro a todos que existe ainda uma parcela muito elevada de maus clientes. E maus significa muitas coisas. Desde não pagar a tempo até não querer participar.
Software é diferente de outras areas neste aspeto. Vc precisa da participação do cliente. Não existe ficar isolado do cliente. Mas muitos clientes ainda acham que eles chegam e pedem um sistema XPTO e automáticamente vc sabe o que tem que ser feito. Não é assim.

Agora, vc pode tentar educar os clientes ou não. Acho que a dicotomia é essa. Depois que vc decide educar o cliente pode reagir mal a isso. Nesse caso vc faz uma escolha, ou abandono o cliente (merecidamente) ou tenta mais uma vez educá-lo.
É fato que os clientes assumem que pode pressionar. Cabe a nós explicar que não é assim, e se impor. O uso de metodologias ágeis remove a figura do tempo e trasnfere a responsabilidade de volta ao cliente. muitos se assutam com isso, outros adoram ter o controle. Ha gostos para tudo. O ponto é, existe sim diferentes graus de cliente e existem sim os muito ruins e os muito bons. Sendo que os muito ruins são a maioria e os muitos bom a minoria.

Cada a nós todos alterar este cenário. A única ferramenta é educação.

(Eu continuo achando que vc estão dizendo o mesmo , mas por alguma razão se perderam e acham que estão em campos opostos)

Não acho que a questão do cliente que não paga entraria no que está sendo discutido, mas a questão da participação do cliente sim.
E neste caso, também não acho que o desenvolvedor deva educar o cliente (acho que isso, voltando ao tema do post, pode trazer uma interpretação errada do verdadeiro papel do desenvolvedor).
Minha analogia seria(propositalmente) dessa forma: Um médico precisa saber do paciente onde está doendo antes de dizer o diagnostico e de forma semelhante o desenvolvedor tem que fazer com o cliente.
Na verdade acho que o correto é dizer que desenvolvedor deve se educar para tirar do cliente aquilo que ele precisa para fazer seu trabalho. (Claro que cabe ao cliente no final decidir se vai querer se tratado daquela forma ou não). O que torna o trabalho do ‘desenvolvedor’ ainda mais dificil é que não existe receita de bolo para tratar o cliente. É papel do desenvolvedor é também se educar e descobrir como cada cliente deve ser tratado para assim atingir os mais importantes princípios ágeis.

sergiotaborda , quanto ao que voce postou no comentário anterior, nada a declarar. É exatamente o que penso hoje em dia.

e destaco a parte mais importante:

Pegando o seu exemplo, imagine que o paciente fala assim “Doutor estou com “doença X” preciso que me dê o remédio Z”. O médico irá perguntar “Onde doi” e o paciente responde “Não importa. Me dê o medicamento Z”. O que isto é ? É um paciente tentando se sobrepor à decisão do médico, mais do que isso , impedindo que o médico realmente saiba o que está errado. Isto é real. Tem pessoas que fazem isto. Este tipo de pessoas têm que ser educadas que não é assim que funciona. Ele tem que entender que precisa responder. Quem vai fazer isso ? O interlocutor, que é o médico neste caso.
Levando para o software é a mesma coisa “Desenvolvedor, estou com “problema X” e preciso que me faça um software Z”. e vc pergunta “Porque vc tem esse problema?” “Não importa. Me dê o software”. " O que o software faz?" " - como assim o que ele faz ?! vc não sabe ?" É a mesma coisa. O cliente não colabora e tenta controlar a conversa. Ele tem que ser educado que não é assim que funciona. Ele tem que entender que precisa responder.Quem vai fazer isso ? O interlocutor, que é o desenvolvedor neste caso.

Quando se diz Desenvolvedor, diz qualquer qualquer interlocutor. Pode ser area comercial tb, pode ser qualquer um relacionado ao software. Estamos usando um cenário mais simplificado em que só tem o cliente e o desenvolvedor ( porque estamos num cenário de autonomos). Como já foi dito algures por alguem neste thread, quando vc é CLT é mais complexo influenciar e até ter contato com o cliente. E isso é um problema em si mesmo. Mas um de cada vez …

Lógico q deve! Aí que está, eu estou tentando entender como é que aí tem tantos clientes que não dão tanta dor-de-cabeça (alguma sempre dá, mas eu digo tanta que não precisem de fato ser educados). Aqui, por outro lado, eu vou dar mais detalhes sobre como é.

O cara chega para mim e fala que quer “um sisteminha de pedidos, coisa simples”. Sempre o mesmo papo, “coisa simples, o + simples q vc imaginar” (sim, já me falaram isso). Bem, o + simples que posso imaginar, digamos, um denominador comum aos pedidos de uma farmácia, sorveteria ou siderúrgica, seria um pedido com data, cliente, itens, quantidades, valor unitário, total do item e total do pedido. Talvez alguma perfumaria, como observação, um espaço pra colocar o logo da empresa ou desconto.

Mas aí eu mostro pro cliente o tal do pedido simples e o cara me diz: “mas e o cálculo do frete? Tem que ter cálculo do frete! Quando o frete é dentro da cidade tem x% de acréscimo, quando é pra outra cidade eu cobro por distância em km”. Com vcs não acontece nada assim? Eu sei que acontece, e estamos ainda na fase de desenvolvimento, mas deixem-me continuar meu raciocínio.

Tudo que eu posso fazer é olhar no olho dele e dizer: “sim, mas vc não me falou o que tinha isso, pediu um pedido simples e só, não deu detalhe de nada”. Aí ele fica sem graça, e tenta se esquivar e enfatizar que o pedido tem que ter o tal do frete. Vcs vão me falar: mas vc está validando o primeiro modelo com o cliente, ele vai ter que falar onde não se encaixa. Mas (agora é opinião pessoal e sei que muitos discordam, mas eu insisto) ele não tem esse direito. Ele sequer explicou para mim o que ele precisa, como vai ter o direito de exigir? Esse exemplo é trivial, mas às vezes (quase todas) são regras de negócios complexas. E não, se eu tentar renegociar o preço pelo trabalho não previsto, ele não vai aceitar. (Os clientes de vcs aceitam? Já falei, mandem um currículo meu pra essa empresa!!)

O que me parece é que a mente da gente desta região aqui é tão fechada, mas tão fechada, que se na empresa do camarada que faz móveis o pedido tem o frete assim, assim e assim, ele acha que o pedido da padaria da esquina é a mesma coisa. Sequer passa pela cabeça do infeliz que cada firma tem uma realidade diferente, e são infinitas formas de se tocar uma empresa (muitas bem melhores que a dele, mas ele se fecha).

Acho que o cerne das nossas diferenças de opinião resume-se ao seguinte:

Minha visão = relação de igual para igual entre cliente e desenvolvedor. Sempre uma relação de troca e respeito ao ser humano. Ele não me pede coisas absurdas ou impossíveis e eu entrego um serviço de qualidade que satisfaça todas as suas necessidades, desde que haja tempo hábil para realizar o tal serviço. Se está fora do meu alcance, eu admito com humildade, mas não aceito pressão. Não só eu que preciso dele para ter trabalho, ele precisa do meu trabalho também. O cliente tem que ser comprometido em prestar ao desenvolvedor informações detalhadas sobre o funcionamento da sua empresa que ele quer ver no sistema. E se é inseguro e não sabe o que quer, sempre vai ver defeitos onde o desenvolvedor tenta ajudar.

A outra visão = o foco é sempre o que o cliente quer, não importa se ele exige que eu faça o ERP todo em 1 semana, quer que eu adivinhe o que ele necessite, ou precisa de um milagre mesmo. O cliente tem o direito de querer o que ele quiser e o desenvolvedor competente é hábil para satisfazer todas (não importa se é autônomo, trabalhe em uma empresa grande ou pequena). Existem técnicas para lidar com clientes dessa forma, que farão todos os clientes tornarem-se colaboradores assíduos sem virarem exigidores agressivos. Se houver falha de comunicação, o responsável sempre será o desenvolvedor (isto me cheira a servidão) que não soube atrair o cliente para a causa comum que é o sucesso do projeto.

O fato é que a cultura deste lugar é tão perniciosa (podem perguntar pq não me mudo daqui) que, se notam boa vontade na minha pessoa, aí que tentam levar vantagem mesmo. Acreditem se quiser!

sergiotaborda:

Aqui está o problema. A primeira coisa a entender é que existem um conjunto de valores que são maiores que todos nós. Este valores geram principios ( receitas para acção do dia a dia).
…
É ai que entra a importância se estarmos falando de principios e não de metodologias

Sim, mas parece que o pessoal da outra visão (que vc acha q é a mesma que a minha) quis levar para o lado de discutir os méritos de uma metodologia específica, ou conjunto de princípios, como queiram - no caso, o Ágil.
E outra, quando se fala em princípios, “agregar valor” e etc., só se pensa em satisfazer ao cliente e nunca a resguardar o prestador de serviços contra abusos cometidos por este. A velha cultura do “o cliente sempre tem razão”. O Cliente é o Princípio e o Fim!

sergiotaborda:

Pegando o seu exemplo, imagine que o paciente fala assim “Doutor estou com “doença X” preciso que me dê o remédio Z”. O médico irá perguntar “Onde doi” e o paciente responde “Não importa. Me dê o medicamento Z”. O que isto é ? É um paciente tentando se sobrepor à decisão do médico, mais do que isso , impedindo que o médico realmente saiba o que está errado. Isto é real. Tem pessoas que fazem isto. Este tipo de pessoas têm que ser educadas que não é assim que funciona. Ele tem que entender que precisa responder. Quem vai fazer isso ? O interlocutor, que é o médico neste caso.
Levando para o software é a mesma coisa “Desenvolvedor, estou com “problema X” e preciso que me faça um software Z”. e vc pergunta “Porque vc tem esse problema?” “Não importa. Me dê o software”. " O que o software faz?" " - como assim o que ele faz ?! vc não sabe ?" É a mesma coisa. O cliente não colabora e tenta controlar a conversa. Ele tem que ser educado que não é assim que funciona. Ele tem que entender que precisa responder.Quem vai fazer isso ? O interlocutor, que é o desenvolvedor neste caso.

Quando se diz Desenvolvedor, diz qualquer qualquer interlocutor. Pode ser area comercial tb, pode ser qualquer um relacionado ao software. Estamos usando um cenário mais simplificado em que só tem o cliente e o desenvolvedor ( porque estamos num cenário de autonomos). Como já foi dito algures por alguem neste thread, quando vc é CLT é mais complexo influenciar e até ter contato com o cliente. E isso é um problema em si mesmo. Mas um de cada vez …

Concordo com o que disse. O que quis dizer no post anterior foi somente para tomar cuidado com as palavras utilizadas. Em minha opinião, pelo menos, dizer que o cliente precisar ser educado além de não retormar a noção principal da ideia, também não passa uma imagem muito boa (Somente resgatando o assunto principal deste tópico, mas já dentro do próprio contexto de desenvolvimento ágil).
Quando se fala em educar um cliente ou paciente, temos alguns sinônimos que não são os mais adequados. Novamente, não diria que o desenvolvedor deve educar o cliente, mas sim que o próprio desenvolvedor deve educar-se para saber como fazer o cliente colaborar. Claro que se o cliente for completamente cabeça dura, não tem jeito. Talvez por isso mesmo eu diria que o desenvolvedor deve ser mais psicologo do que professor.

Cara bom artigo.

Eu comecei a desenvolver em uma empresa pequena, onde o patrão estava encima, o dia todo. Cobrando a todo hora. Fazia reunião semanal, cobrando e cobrando.

Nem por isso, eu fiquei preguiçoso, em entender o problema.

Isso não justifica.

O que eu vejo é uma crescente em nossa área de projetos, e não estamos dando conta.

Fato de não se levantar corretamente os requisitos, fazer o estudo de caso. Não é culpa do Engenheiro, e culpa do programdor, que é alienado.

Eu sou formado em Analise e Desenvolvimento, e meu chefe sabe muito bem, que antes de iniciar o codificar o projeto, eu tenho que entender o sistema.

O problema é o programdor preguiçoso.

MarkKnopfler:

E outra, quando se fala em princípios, “agregar valor” e etc., só se pensa em satisfazer ao cliente e nunca a resguardar o prestador de serviços contra abusos cometidos por este. A velha cultura do “o cliente sempre tem razão”. O Cliente é o Princípio e o Fim!

Eu queria comentar esta ideia de que “agregar valor” significa satisfazer o cliente e isso significa não resguardar o desenvolvedor. Não.

Agregar valor apenas significa que o cliente é que decide o que ele quer e que o desenvolvedor não será preguiçoso ou displicente. A qualidade do produto do ponto vista técnico é obrigatória e não é discutível. Mas a qualidade do produto do ponto de vista de quem o uso, do ponto de vista de mercado , digamos, do ponto de vista externo, é também responsabilidade do cliente. Agregar Valor significa que na hora de decidir entre incluir a funcionalidade A ou B, o desempate é por aquela que adicionar mais valor. O que significa “valor” ? e o que significa “mais valor” ? depende do cliente. É por isso que a figura do cara que decide do ponto de vista do negocio/cliente e não do desenvolvimento é importante. É vital. Todas as metodologias ágeis de uma forma ou outra têm esta figura normalmente chamada de Product Owner (Dono do produto). É importante notar que o cara é dono do produto, não do código, ou da técnica. Em tese o PO tem informações de outras fontes (por exemplo, equipe de UX e QA, mas tb dos stakeholders) sobre o que é tem mais valor e menos. O valor é subjectivo ao cliente, mas a decisão é concreta. Identificar o PO do projeto é a coisa mais importante, e mais difícil, porque normalmente as pessoas não tem este perfil. Mas é um principio importante e temos que ser conscientes disso, e portanto tentar encontrar essa pessoa. Essa pessoa tem que ser alguém na empresa do cliente, não na sua.

Este principio cria um outra dinâmica com o cliente. É o cliente que tem a responsabilidade de pedir e decidir, não o desenvolvedor. Quando vc inverte a responsabilidade e a dá para o cliente, duas coisas podem acontecer. Ele entende que o poder é dele o usa, ou ele não entende e prefere que vc decida. No segundo caso, ha que pensar se vale a pena continuar.

Outra coisa que eu queria comentar é o modelo de negócios. Esta subentendido na sua historia que o cliente pediu A, B e C e depois ele adiciona D, E, e F e pede que o preço seja o mesmo que por A,B,C.
O problema é o seguinte vc está usando um modelo fechado, ele está usando um modelo aberto. A diretiva é , não lute contra o modelo aberto. O seu cliente sempre usará o modelo aberto. Então se protega disso, já à partida assumindo que não é apenas A, B e C que será necessário. Como fazer isto ? Bom, não ha uma resposta universal ainda. Existem vários modelos de contrato ágil para ajudar, mas não sei qual é melhor.
Aqui alguma coisas pode ser feitas. A primeira é ter o bom senso de não acreditar no cliente, no sentido que sempre que ele usar palavras como “é só isso” , “é sempre assim” , “nunca vai mudar”, e coisas finais do tipo, desconfie. Explore essas frases. Elas escondem normalmente exceções que são importantes. Leve o raciocinio do cliente a chegar no ponto onde ele admite que pode haver uma exceção ou onde ele admite que se essa execção um dia acontecer, precisará de outro software diferente. No caso do frete, pro exemplo, começa por ser nacional. Vc pergunta “mas e exportações ?” ele responde “nunca fazemos”. E vc fala “E no dia que quiserem fazer ?” e o cara responde “ai precisamos de outro software” ou pode ser assim.Vc pergunta “mas e exportações ?” ele responde “nunca fazemos”. E vc fala “nunca fizeram ?” . Ele responde ah!, já aconteceu, mas fizemos por fora do sistema". Ai vc pergunta “então isso não será uma feature ?” e ele diz , "não. Isto é errado. Foi certo até ele admitir que existiu a exceção, mas levá-lo a concluir que a feature não será necessária é errado. A feature existe, então ela será necessária. A questão é : com que prioridade ? O sugerido é que coloque a feature no backlog e lhe dê prioridade minima. Desta forma vc não se irá enganar e deixa aberta a opção para depois.

Como cobrar por isto ?

O modelo atual é cobrar por tempo. Basicamente o tempo é que gera o custo no projeto. Portanto, o primeiro passo é criar um backlog rico. Isto significa que todas as ideias , mesmo as que não serão feitas agora, estão lá. Fixe um tempo para os cliclos. Vc cota esse backlog (existem várias técnicas) vc coloca uma margem de erro. e isso lhe dá uma ideia de quantos ciclos de tempo são necessários. E isso lhe diz o custo. Do custo vc acha o preço e é isso que vc cobra. Ai vc divide em 3 fatias. 3 versões. A versão A tem como objetivo provar que o sistema funciona. Vc joga um monte de cosias básicas (tipo cadastro e tal) e uma ou duas coisas mais avançadas que tenham valor. Ou seja o cliente irá lhe dizer o que mais lhe interessa. Mas ele tem que se comprometer com isso. A versão A tem um tempo maior porque existe um trabalho de infra que tem que ser feito tb. Durante este processo as features irão aparecer e desaparecer. Vc pode postergar para a próxima versão, ou trazer da versão seguinte para agora, etc… O ponto é que vc tem um plano o cliente tem a possibilidade de brincar com as peças como ele quiser (com algumas restrições sensatas. ). O valor aqui é que o cliente sabe se ficar patinando o dinheiro tá indo embora. Ele lhe está pagado para fazer as coisas, mas as decisões de negocio são dele.

Agora vc vai dizer que o cliente não vai nessa. bom, ai é que está. Quando o cara vier lhe pedir um sistema “simples” o tamanho do backlog vai lhe mostrar a ele , que não é tão simples. Vc explica as regras com antecedência. Algumas podem até estar em contrato. E ai deixa ele decidir. Vc não está enganando a ele , nem a si. Ele deve ficar consciente que pode pedir mais coisas, mas isso irá ocupar o espaço de outra coisa que ele já pediu. Ele que tem que fazer o trade-off.

Não estamos falando que vc deve ser subserviente. Estamos dizendo que vc deve dar a escolha ao cliente. Dá-lhe a responsabilidade. Normalmente as pessoas são capazes da usar. Assim , os abusos dele irão se refletir nele mesmo, não em si.

Bacana seus comentários, mas acho que mesmo acordando tudo isto no início, muita gente não respeita e chega com a maior cara de pau pedindo coisas. Eu educadamente coloco as condições, digo, “tudo bem, esta é uma funcionalidade nova, e vai custar X”, e eles ficam mais humildes da próxima vez.

Acabei de responder um e-mail de um desses clientes ariscos. O cara pediu uma modificação que ia implicar em n coisas lá na frente, e nem se dispôs a tirar minhas dúvidas sobre como o sistema ia tratar as consequências. Eu fui obrigado a optar por um caminho e seguir, e não, claro que não, não era o que ele queria. Dei um senhor sermão mesmo, disse que era para ele refletir direitinho sobre o que ele quer ver exatamente naquela tela, e que não respondesse minhas mensagens correndo. Quando ele responder, eu conto pra vcs

immortalSoul:

O que quis dizer no post anterior foi somente para tomar cuidado com as palavras utilizadas.

…

Quando se fala em educar um cliente ou paciente, temos alguns sinônimos que não são os mais adequados.

Não, meu amigo. É educar Educar mesmo, com todas os significados que isso pode trazer. Às vezes será questão de “explicar”. Às vezes teremos que pô-los no lugar mesmo.

É essa atitude de reverência e pisar em ovos com o cliente que eu não concordo, ela nos desvaloriza muito. Eu defendo atitudes radicais mesmo porque eles não nos valorizam. Para eles, somos servos, aquele que “sempre está lá pro que der e vier”.

MarkKnopfler:

É essa atitude de reverência e pisar em ovos com o cliente que eu não concordo, ela nos desvaloriza muito. Eu defendo atitudes radicais mesmo porque eles não nos valorizam. Para eles, somos servos, aquele que “sempre está lá pro que der e vier”.

Não chamo isso de atitude de reverência nem de pisar em ovos, mas sim de profissionalismo.

Então profissionalismo para mim e para vc significa coisas diferentes. Para mim, não significa assumir responsabilidades que não são minhas (nem tem como ser). Mas o que o cliente quer é que vc apresente uma solução, resolva o problema dele! Isso não é profissionalismo, é marketing barato.

Cumprindo a minha promessa, depois do meu sermão, o meu cliente desceu ao nível de me chamar de burro e disse que não quer mais me ver tão cedo. Antes que digam que eu xinguei ele, saibam que apenas lhe disse que mais qualidade era impossível sem mais comprometimento da parte dele em me prestar informações (tudo correndo e confuso) e, mais importante, que eu já esperava que esse tipo de reação poderia ocorrer.

Eu não sou obrigado a entender tudo o que ele fala. O cara é programador (Clipper) e onde está exibindo errado, ele fala que está gravando errado (eu acho que na verdade ele quis dizer “exibindo”, não tenho certeza. Mas kd o cara pra me esclarecer?). Bem, lá vou eu conferir o arquivo e dizer que o arquivo está gravando assim, assim e assim, confere para mim se está certo. Se ele dissesse “mas é que tá aparecendo na tela o campo incorreto”, eu ia só dizer “ah, é q vc falou ‘gravar’, então entendi que era no arquivo” e mudando 4 linhas de código eu mandava mostrar o campo certo, e todos sairíamos felizes. Mas ele resolve apelar pra baixaria… Realmente ele não tem paciência para me explicar nada, e isso foi criando um círculo vicioso até o ponto em que eu não conseguia entender nada.

Por isso eu defendo a postura radical, de bater o pé: não me arrependo de perder esse cliente. Ia ser dor de cabeça para a eternidade. Kd o YvGa pra eu dar o telefone dele? Quer pegar, immortalSoul?

MarkKnopfler:

Então profissionalismo para mim e para vc significa coisas diferentes. Para mim, não significa assumir responsabilidades que não são minhas (nem tem como ser). Mas o que o cliente quer é que vc apresente uma solução, resolva o problema dele! Isso não é profissionalismo, é marketing barato.

De fato concordo com o Mark, aceitar falta de cultura, de educação, pressão psicológica e outras coisas mais, não é profissionalismo. Profissionalismo é parar essas coisas na fonte. Sem margem para duvida ou ambiguidade.
Se o cliente não gostar da sua atitude ele procurar outro. Simples assim. Não ha nenhuma obrigação do desenvolvedor se sacrificar pelo cliente. Essa relação master-slave não funciona. Isso é ainda é uma atitude derivada do principio de que o cliente tem sempre razão porque tem o dinheiro. Não. Ele não quer o dinheiro, ele quer o software. (O dinheiro só importa enquanto ha o que comprar)

uau, alguém concordou comigo aqui! estou chorando de emoção.

a saga do cliente chato - parte II

Hj cedo acordei e uma das primeiras coisas que pensei foi em mandar um e-mail para ele, perguntando se estava mais calmo e levantando as minhas conclusões sobre tudo o que ele quer que modifique no software.
Ele respondeu “Muito melhor assim, sussinto i[/i] e objetivo”. Aham. Os e-mails ele eram tão “sucintos” que o miolo do entendimento simplesmente sumiu. Para bom entendedor, meia palavra basta mesmo?

Eu respondi a ele que se não fosse eu para reler todo o material e sintetizar tudo sucinto e objetivo, ninguém + ia fazer isso. E que eu sou burro d+ e não sei como se “grava” numa tela, mas que um dia eu iria aprender rsrsrs. Será que alguém no GUJ me ajuda? Como se grava numa tela?

Aguardem o próximo capítulo

MarkKnopfler:

E não, se eu tentar renegociar o preço pelo trabalho não previsto, ele não vai aceitar. (Os clientes de vcs aceitam? Já falei, mandem um currículo meu pra essa empresa!!)

Vc está negociando errado. Não negocie o valor do projeto, negocie seu valor/h.

andre_salvati:

MarkKnopfler:

E não, se eu tentar renegociar o preço pelo trabalho não previsto, ele não vai aceitar. (Os clientes de vcs aceitam? Já falei, mandem um currículo meu pra essa empresa!!)

Vc está negociando errado. Não negocie o valor do projeto, negocie seu valor/h.

Acho difícil o cliente aceitar … Tente se colocar no lugar do cliente … Como vou saber que o cara não está “inchando” o tempo de desenvolvimento para cobrar a mais ?

andre_salvati:

MarkKnopfler:

E não, se eu tentar renegociar o preço pelo trabalho não previsto, ele não vai aceitar. (Os clientes de vcs aceitam? Já falei, mandem um currículo meu pra essa empresa!!)

Vc está negociando errado. Não negocie o valor do projeto, negocie seu valor/h.

Ou fechar um pacote e cobrar o valor do projeto. Caso existir algo além, cobrar por hora estas implementações a mais…

Desse jeito se tem margem pra fazer um preço e acaba não sendo tão injusto com o cliente. Também obriga o cliente a sentar e conversar tim tim por tim tim, pois ele sabe que se precisar de mais alguma coisa, vai ter que pagar a mais…

É que os clientes deveriam trabalhar do mesmo modo que nós. Levantando os requisitos e documentando tudo, buscando padrões de comportamento para os procedimentos.

Tenho 20 anos, já trabalhei em 3 empresas, e só uma única maledeta tinha seus processos documentados e regrados. Isso faz muita diferença, pois aí não tem aquela história de “eu faço desse jeito e fulano faz de outro”, com procedimentos regrados existe uma base que deve ser seguida, e em cima dela se fazer alguma adaptação…

O maior problema para os analistas é chegar na empresa do cliente pra levantar os requisitos e ter de encarar um mar de gente vindo explicar o que faz. O papel de saber tudo o que acontece na empresa é do gerente/dono e de mais ninguém…

Por essas e outras que o Brasil é campeão em falências e a granda maioria das novas empresas não dura nem um ano…

Realmente. Como eu desenvolvo em uma velocidade acima da média (não é para me gabar), eu vou acabar cobrando barato d+ dessa forma.

Como alguém colocou neste mesmo tópico, algumas páginas atrás, um serviço feito em menos tempo com a mesma qualidade deve ser cobrado mais caro.

sergiotaborda:

De fato concordo com o Mark, aceitar falta de cultura, de educação, pressão psicológica e outras coisas mais, não é profissionalismo. Profissionalismo é parar essas coisas na fonte. Sem margem para duvida ou ambiguidade.
Se o cliente não gostar da sua atitude ele procurar outro. Simples assim. Não ha nenhuma obrigação do desenvolvedor se sacrificar pelo cliente. Essa relação master-slave não funciona. Isso é ainda é uma atitude derivada do principio de que o cliente tem sempre razão porque tem o dinheiro. Não. Ele não quer o dinheiro, ele quer o software. (O dinheiro só importa enquanto ha o que comprar)

Não é relação mestre-escravo. Estamos em um mercado, a concorrência é livre. Pessoas precisam comprar trabalho e pessoas precisam vender trabalho e toda relação de troca é um beneficio mutuo. Simples assim.
Pessoas sem tato para lidar com outros seres humanos existe em todo canto, pode ser não só como contratante, mas também no contratado. Mas nesse caso estamos saindo de desenvolvimento de software e falando de relações sociais. Sinceramente, acho que não cabe discutir isso aqui por mais relevante que seja.

Cabe sim, o tópico é sobre a linguagem e a comunicação. Eu tive problemas com meu cliente justamente por causa da linguagem (universos) distintos.

Vamos debater. Garçom, traz 1 porção de filé!

rmendes08:

andre_salvati:

MarkKnopfler:

E não, se eu tentar renegociar o preço pelo trabalho não previsto, ele não vai aceitar. (Os clientes de vcs aceitam? Já falei, mandem um currículo meu pra essa empresa!!)

Vc está negociando errado. Não negocie o valor do projeto, negocie seu valor/h.

Acho difícil o cliente aceitar … Tente se colocar no lugar do cliente … Como vou saber que o cara não está “inchando” o tempo de desenvolvimento para cobrar a mais ?

Confiança é algo que se conquista. Como alguém já falou aí em cima: “estamos falando de relações humanas”, e é sobre isso que ser Ágil fala.

Conheço gente q está muito feliz com esse modelo, e ainda trabalhando em casa…

immortalSoul:

sergiotaborda:

De fato concordo com o Mark, aceitar falta de cultura, de educação, pressão psicológica e outras coisas mais, não é profissionalismo. Profissionalismo é parar essas coisas na fonte. Sem margem para duvida ou ambiguidade.
Se o cliente não gostar da sua atitude ele procurar outro. Simples assim. Não ha nenhuma obrigação do desenvolvedor se sacrificar pelo cliente. Essa relação master-slave não funciona. Isso é ainda é uma atitude derivada do principio de que o cliente tem sempre razão porque tem o dinheiro. Não. Ele não quer o dinheiro, ele quer o software. (O dinheiro só importa enquanto ha o que comprar)

Não é relação mestre-escravo. Estamos em um mercado, a concorrência é livre. Pessoas precisam comprar trabalho e pessoas precisam vender trabalho e toda relação de troca é um beneficio mutuo. Simples assim.
Pessoas sem tato para lidar com outros seres humanos existe em todo canto, pode ser não só como contratante, mas também no contratado. Mas nesse caso estamos saindo de desenvolvimento de software e falando de relações sociais. Sinceramente, acho que não cabe discutir isso aqui por mais relevante que seja.

Eu acho exatamente o contrario. O desenvolvimento de software é uma relação social. É exatamente isto que as pessoas têm que perceber. É por causa de não entenderem isto que estamos como estamos.
O desenvolvimento de software é a arte de entender requisitos. Implementar código é apenas uma ferramenta. às vezes durante o levantamento de requisitos vc chega à conclusão que não precisa do software para fazer aquilo, basta modificar o processo da empresa de uma outra forma.

A concorrencia é livre, mas é desleal. O gambiarreio que cobre barato a hora e incha o cronograma não se pode comprar com o cara que cobra caro, faz com qualidade e mas faz depressa. Tb não podemos compara o cara que implementa a primeira coisa que o cliente fala, com o cara que perde um tempo entendendo a necessidade do requisitor.

O benefício mútuo da tal “relação de troca” é só teórico. Na prática um lado sempre se estrepa.
Esta discussão que estamos tendo necessitaria ser levada para qualquer área, ela não é restrita do desenvolvimento de software (embora aqui o problema seja bem sério).
O profissional ser obrigado a sempre atender bem, do jeitinho que o cliente quer, é sim uma relação mestre-escravo. O cliente já chega se vendo com mais direitos que o desenvolvedor e isso é inadmissível.

sergiotaborda:

Eu acho exatamente o contrario. O desenvolvimento de software é uma relação social. É exatamente isto que as pessoas têm que perceber. É por causa de não entenderem isto que estamos como estamos.
O desenvolvimento de software é a arte de entender requisitos. Implementar código é apenas uma ferramenta. às vezes durante o levantamento de requisitos vc chega à conclusão que não precisa do software para fazer aquilo, basta modificar o processo da empresa de uma outra forma.

A concorrencia é livre, mas é desleal. O gambiarreio que cobre barato a hora e incha o cronograma não se pode comprar com o cara que cobra caro, faz com qualidade e mas faz depressa. Tb não podemos compara o cara que implementa a primeira coisa que o cliente fala, com o cara que perde um tempo entendendo a necessidade do requisitor.

Não misture as coisas, e se formos nesse caminho daqui a pouco estaremos falando sobre filosofia e arte da retorica. Não disse que relação social não é importante para desenvolvimento de software. Aliais, se eu tivesse dito isso jamais poderia ter sugerido que estamos mais pra psicologo do que professor.
Acho que não da pra ser mais claro que isso. O que disse é que a conversa estava tomando outro rumo. Deixamos de falar de cliente do software para falar sobre pessoas com problema ao lidar com outras e isso definitivamente não é problema de desenvolvimento de software. Pessoas com esse tipo de problema existe no mundo em qualquer profissão e em qualquer papel, seja cliente ou vendedor, seja médico ou paciente, aluno ou professor e etc. Definitivamente se formos discutir isso, não estaremos mais discutindo desenvolvimento de software. Ou ainda discorda deste ponto?

sobre o fato da concorrência ser desleal isso já é outra questão e uma realidade que pouco adianta chorar e rezar na tentativa de mudar. A realidade é essa e aquele que se adaptar a ela sobrevive. Não tem essa de regras bem definidas ou de como deveria ser. Tem somente a realidade crua mostrando como é. Mas volto a repetir: Pessoas precisam comprar trabalho e pessoas precisam vender trabalho e toda relação de troca é um beneficio mutuo.
Sem falar que não existe uma referência universal de como as coisas devem ser, de qual o tamanho de cronograma ideal ou de quanto é caro e quanto é barato. Na verdade, a coisa mais próxima de uma referência universal é justamente o mercado, que não é nada mais do que cada relação de troca que acontece entre os indivíduos.

Por tudo isso, só posso afirmar que se fazer de coitado e jogar a culpa no cliente é uma atitude pouco profissional, mesmo entendendo que há casos de pessoas problemáticas, com algum tipo de deficiência no relacionamento social e etc (Que como disse anteriormente, está além do que trata o desenvolvimento de software).

Tadinho de mim, meu cliente não me entende… chuif.

Condordo 100%, meu amigo. Só acho que vc está levando nossas afirmações a ferro e fogo, achando que jogamos a culpa de tudo no cliente.
O que defendemos é o cliente assumir a responsabilidade que é dele, enquanto eu assumo somente a que é minha. O foco é sempre na responsabilidade do desenvolvedor; o cliente é visto como um ser que só tem direitos e não obrigações. Claro que ele não vai aceitar as obrigações dele como eu gostaria, vc bem disse:

Por isso eu defendo a ideia de bater o pé e negar serviço para esse cliente justamente porque, como dizia minha mãe, “o que não tem remédio, remediado está”. Eu me encarrego de servir a ele um chá de realidade.

andre_salvati:

MarkKnopfler:

E não, se eu tentar renegociar o preço pelo trabalho não previsto, ele não vai aceitar. (Os clientes de vcs aceitam? Já falei, mandem um currículo meu pra essa empresa!!)

Vc está negociando errado. Não negocie o valor do projeto, negocie seu valor/h.

Exato. A partir do momento que se dispõe a fazer o que o cliente quer você passa a prestar um serviço e não mais vender um produto ou solução.

rmendes08:

andre_salvati:

MarkKnopfler:

E não, se eu tentar renegociar o preço pelo trabalho não previsto, ele não vai aceitar. (Os clientes de vcs aceitam? Já falei, mandem um currículo meu pra essa empresa!!)

Vc está negociando errado. Não negocie o valor do projeto, negocie seu valor/h.

Acho difícil o cliente aceitar … Tente se colocar no lugar do cliente … Como vou saber que o cara não está “inchando” o tempo de desenvolvimento para cobrar a mais ?

O programador ficar responsável pela negociação é suicídio. Precisa de uma boa equipe de vendas.

JoseIgnacio:

rmendes08:

andre_salvati:

MarkKnopfler:

E não, se eu tentar renegociar o preço pelo trabalho não previsto, ele não vai aceitar. (Os clientes de vcs aceitam? Já falei, mandem um currículo meu pra essa empresa!!)

Vc está negociando errado. Não negocie o valor do projeto, negocie seu valor/h.

Acho difícil o cliente aceitar … Tente se colocar no lugar do cliente … Como vou saber que o cara não está “inchando” o tempo de desenvolvimento para cobrar a mais ?

O programador ficar responsável pela negociação é suicídio. Precisa de uma boa equipe de vendas.

Ué, quem é autônomo não tem muita alternativa …

rmendes08:

Ué, quem é autônomo não tem muita alternativa …

neste caso não.

Existe um motivo pra autônomos gravitarem em torno de projeto de sistemas ERP e de “padaria”, eles são mais fáceis de serem vendidos.

JoseIgnacio:

rmendes08:

Ué, quem é autônomo não tem muita alternativa …

neste caso não.

qual caso ? eu falei de maneira genérica. Se você trabalha como autônomo o caixa não deve ser lá essas coisas, sendo assim, com que dinheiro você vai pagar equipe de vendas ? Claro que uma equipe especializada é mais eficiente, mas se pra começar um negócio eu tivesse que de antemão montar toda uma estrutura corporativa, então simplesmente não existiriam empreendedores nem autônomos.

rmendes08:

JoseIgnacio:

rmendes08:

Ué, quem é autônomo não tem muita alternativa …

neste caso não.

qual caso ? eu falei de maneira genérica. Se você trabalha como autônomo o caixa não deve ser lá essas coisas, sendo assim, com que dinheiro você vai pagar equipe de vendas ? Claro que uma equipe especializada é mais eficiente, mas se pra começar um negócio eu tivesse que de antemão montar toda uma estrutura corporativa, então simplesmente não existiriam empreendedores nem autônomos.

Se você não sabe o que construir e não quer deixar de ser autônomo a única alternativa é sistemas de padaria. Veja meu post anterior.

E qual o problema com isso ? Qualquer produto que demonstre seu valor por si mesmo é fácil de vender. Nesses casos, vendedores são até dispensáveis. Veja o sucesso do comércio eletrônico, você entra no site, busca o produto, paga e eles entregam. Quando o produto é uma porcaria ai sim você precisa de vendedores excepcionias. Veja Polishop e a câmera Tecpix. Pelo menos nas comunidades que frequento, os desenvolvedores prezam pela qualidade do produto, de forma que ela se venda por si mesmo, agora, tem gente que gosta do jeito Softwell/Maker de ser, que precisa a todo momento convencer os prospectos de que aquilo vale o preço.

Com certeza…

A cada esquina tem um mercado ou padaria que precisa de um sisteminha, e apesar da montoeira de produtos já existentes para este fim, ainda se carece de muita oferta…

rmendes08:

E qual o problema com isso ? Qualquer produto que demonstre seu valor por si mesmo é fácil de vender. Nesses casos, vendedores são até dispensáveis. Veja o sucesso do comércio eletrônico, você entra no site, busca o produto, paga e eles entregam. Quando o produto é uma porcaria ai sim você precisa de vendedores excepcionias. Veja Polishop e a câmera Tecpix. Pelo menos nas comunidades que frequento, os desenvolvedores prezam pela qualidade do produto, de forma que ela se venda por si mesmo, agora, tem gente que gosta do jeito Softwell/Maker de ser, que precisa a todo momento convencer os prospectos de que aquilo vale o preço.

Não disse que era um problema. Se alguém quer desenvolver software padronizado, ótimo pra ele!

Tb não disse que vendedores são necessários porque o produto é uma porcaria, e sim porque você não pode demonstrar o valor de algo que ainda não existe.

Seja prestando serviço, seja vendendo uma solução, o problema é quando o cliente não entende quando vc diz que aquilo é outra complexidade e o preço deve ser a parte. Muitos acham que estamos os enganando, aproveitando o momento para “meter a faca”. Até não digo que estão errados de pensar assim. No entanto, assim que é feito o primeiro acordo, eu já deixo claro que aquele valor e aquele prazo correspondem àquelas funcionalidades. Acréscimo e alteração de funcionalidades (não correção de erros) serão cobrados à parte.
Eu tô ficando bom em negociar, meu último cliente entendeu certinho
O problema não é haver quem ensine, em curso nenhum

MarkKnopfler:

Seja prestando serviço, seja vendendo uma solução, o problema é quando o cliente não entende quando vc diz que aquilo é outra complexidade e o preço deve ser a parte. Muitos acham que estamos os enganando, aproveitando o momento para “meter a faca”. Até não digo que estão errados de pensar assim. No entanto, assim que é feito o primeiro acordo, eu já deixo claro que aquele valor e aquele prazo correspondem àquelas funcionalidades. Acréscimo e alteração de funcionalidades (não correção de erros) serão cobrados à parte.
Eu tô ficando bom em negociar, meu último cliente entendeu certinho
O problema não é haver quem ensine, em curso nenhum :(

Você ilustrou o maior problema das relações humanas, fazer-se entender.

Isso é pior que inveja, ódio e raiva porque geralmente é a dificuldade em se fazer entender que gera os sentimentos que citei…

Se dá bem nessa área de TI quem consegue se entender bem com seu cliente, pois o que eu mais vejo por aí é analista de TI “se achar” por ser da área, e portanto pensar que o cliente tem que aceitar qualquer preço que for proposto. E cá pra nós, tem gente que se acha o herói da humanidade por trabalhar com TI. Já passou essa época faz tempo, diria até que a TI é menosprezada hoje em dia…

Enfim, é o valor do seu produto que determina o preço que você vai cobrar. Eu pelo menos não me importo de ter que pagar um pouco mais em um produto que tem valor e reconhecimento, do que em um mais barato mas que eu nem sabia que existia.

Dá até pra tirar uma conclusão: Você tem que se fazer entender para o cliente e vender embasado em valor, e não preço. Depois que você encanta o cliente e vê que ele já está “laçado” pelo seu produto, o preço é um mero adendo à negociação.

MarkKnopfler:

Seja prestando serviço, seja vendendo uma solução, o problema é quando o cliente não entende quando vc diz que aquilo é outra complexidade e o preço deve ser a parte. Muitos acham que estamos os enganando, aproveitando o momento para “meter a faca”. Até não digo que estão errados de pensar assim. No entanto, assim que é feito o primeiro acordo, eu já deixo claro que aquele valor e aquele prazo correspondem àquelas funcionalidades. Acréscimo e alteração de funcionalidades (não correção de erros) serão cobrados à parte.
Eu tô ficando bom em negociar, meu último cliente entendeu certinho
O problema não é haver quem ensine, em curso nenhum :(

É talvez ha que deixar claro que você está usando um conceito de “pacote de desenvolvimento” as coisas novas vão para um pacote novo. Realmente “cobrar à parte” parece significa “cobrar por fora”. Mas se vc apenas disser que será feito no próximo pacote e explicar que cada pacote tem seu preço e prazo é mais simples e transparente. Basta explicar à partida que o cliente pode pedir quantos pacotes ele quiser ( outro nome para pacote é versão, mas acho que acaba sendo muito técnico para o leigo).

a parte = outra negociação.

É assim q eu falo com meus clientes.