[quote=JoseIgnacio][quote=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.
[/quote]
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.
[/quote]
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.
[quote=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.[/quote]
Não sei se esta trolando ou falando sério.
Como você pode entregar algo incompleto e achar que não comprometeu qualidade?
[quote=JoseIgnacio][quote=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.[/quote]
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.
[/quote]
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.
[quote=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.[/quote]
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.[/quote]
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.[/quote]
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!
[quote=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.[/quote]
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.
[quote=MarkKnopfler]Esse cara tá falando tanta patacada que eu já tô com desgosto desse debate kakakaka.
[/quote]
Cara, essa patacada é fortemente embasada pela literatura técnica da nossa área. Antes de dizer isso você deveria ler coisas como Getting Real, Lean Software Devolopment, Planning Extreme Programming, Applying UML and Patterns entre muitas outras coisas do gênero. Muito do que você escreve são erros tradicionais, comuns e catalogados por desenvolvedores experientes, para os quais há soluções conhecidas.
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.
[quote=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![/quote]
Péssimo exemplo, você foi ao extremo e contra isso não há discussão. Mas afrouxe um pouco o tempo e faça com que o cliente não seja tão idiota assim e talvez você encontre uma solução que o satisfaça.
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
[quote=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.[/quote]
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
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.
[quote=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.
[/quote]
Mas nem de longe eu disse isso, nem de longe. O que eu disse é que não é nós x eles, que você aponta.