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.
[quote=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.[/quote]
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!
[quote=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![/quote]
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.
[/quote]
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
[quote=saoj][quote=JoseIgnacio]
Não entendo essa fixação em medir produtividade. Alguém já viu um projeto de software que fracassou porque atrasou?
[/quote]
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.
[/quote]
O problema é que quando um projeto é definido em termos de custo e prazos, sua qualidade É comprometida.
[quote=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.[/quote]
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.
[quote=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.[/quote]
Essa analogia é ótima, queria fazer umas observações:
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)
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.
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.
[quote=YvGa][quote=JoseIgnacio]
O problema é que quando um projeto é definido em termos de custo e prazos, sua qualidade É comprometida.
[/quote]
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.
[/quote]
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.