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.
[/quote]
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.
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.
[quote=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.[/quote]
É 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.
[quote=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.[/quote]
Moro em Curitiba-PR, mas não creio que isso faça realmente diferença.
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?
[quote=YvGa][quote=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)[/quote]
Um não é problema, seriam exceções. Você conseguiria me indicar 5 desses que querem tudo pronto e não querem nada com nada? [/quote]
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.
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 )[/quote]
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.
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.
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
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[/quote]
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
[quote=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?[/quote]
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.
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.
