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

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í :wink:

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…:frowning: 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.

[quote=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). [/quote]

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

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

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.

[quote=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í ;)[/quote]

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.

[quote=JoseIgnacio][quote=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.
[/quote]

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.
[/quote]

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.

[quote=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 ;)[/quote]

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 :wink:

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??? :frowning:

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 :wink:

[quote=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 ;)[/quote]

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.

[quote=YvGa][quote=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 ;)[/quote]

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?
[/quote]

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.

[quote=sergiotaborda][quote=YvGa][quote=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 ;)[/quote]

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?
[/quote]

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)[/quote]

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!

[quote=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[/quote]

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!

[quote=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 … [/quote]

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.