Dando continuidade no assunto,temos mais uma vez o argumento “o cliente não quer saber em que foi feito, se é OO ou não, ele quer que atenda as suas expectativas.
Perfeito, só que o cliente também não quer saber que por sua decisão arquitetural e de design ser ineficientevocê vai ter que mexer em 300 arquivos e testar todo o sistema para implementar uma funcionalidadezinha boba. Minha mãe não tem o menor interesse em saber como a Microsoft implementa o Windows, mas após ter que me chamar centenas de vezespara reinstalar o sistema dela após problemas ela está procurando alternativas. O que ela quer é um sistema que faça exatamente a mesma coisa mas que não seja tão inflexível, tão custoso.
Em 2007 não existem CRUDs em abundância. toda aplicação tem o potencial de ser integrada em uma rede de aplicações e eu mesmo já fiz vários trabalhos de consultoria para empresas queprojetaram ” aplicaçõezinhas simples de cadastro” que de repente tiveram que crescer. Ainda que existisse esta abundância com certeza elas seriam muito mais eficientes se implementadas emoturas plataformas que não java ou C#, que não foram criadas com este tipo de coisa em mente. Tudo deve ser pesado e um arquiteto profissional deve saber tirar estas medidas e escolher a solução mais adequada.
O que não dá é repetir sempre o mesmo “as necessidades reais tem que ser atendidas e pro cliente não importa como”. Claro que importa! O profissional de software tem que estar pronto para oferecer um leque de soluções, considerando a eficiência e eficácia de cada uma no cenário específico.
Seja OO, projeto estruturado, funcional, RAD… não importa. O importante é dar um mínimo de qualidade ao projeto.
Discordo do “em 2007 não existem CRUDs em abundancia”. Existem sim. Talvez eles não apareçam pra você.
Quando um arquiteto faz uma escolha, ele deve saber que essa escolha tem consequencias. Se ele tem alguma vantagem (competitiva talvez) por fazer sistemas rapidamente com manutenção mais complicada, ele o faz. Talvez ele não seja contratado pra dar manutenção.
É claro que é importante dar um mínimo de qualidade ao projeto. A questão é é possivel fazer bons projetos sem usar OO, sem usar Java etc..
quote:
O que não dá é repetir sempre o mesmo “as necessidades reais tem que ser atendidas e pro cliente não importa como”. Claro que importa! O profissional de software tem que estar pronto para oferecer um leque de soluções, considerando a eficiência e eficácia de cada uma no cenário específico.
Tem clientes que não se importam e que não estão nem ai pro seu leque de opções.
Existem clientes e clientes
Engraçado como esse assunto é recorrente. Acho bom que nossos engenheiros e analistas questionem como desenvolvemos software hoje em dia. Mas parece que os questionamentos estão apontando para o lugar errado.
E bom, o cliente pode realmente não querer saber como as coisas foram feitas, mas vc sim! Falei sobre isso em um antigo post no meu (falecido) blog: Qualidade importa.
valeuz…
@Felipe
Por favor me d exemplos e me diga porque deveríamos usar uma linguagem como Java para implementarmos.
Se você leu o texto deve ter lido:
Então não entendi seu ponto.
O cliente pode nãoe star ligando para o leque, mas ele vai estar ligando, e muito, para a qualidade da escolha. O quanto de qualidade ele precisa em detrimento à preço, prazo e produtividade depende, e muito, ams geralmente adotar uma postura ‘o cliente não se importa’ é suicídio.
A menos, é claro, que você trabalhe para uma consultoria que faz dinheiro com este tipo de coisa, que nãio liga para a qualidade final apenas entrega código pseudo-funcionando.
É o caso de muitos, mas aí entramos em ética profissional, uma coisa rara em nosso meio de consultorias.
Comentário rejeitado por erro meu:
New comment on your post #349 “”Necessidades Reais”"
Author : felipe cruz
E-mail : xxx@gmail.com
URI : http://blog.loogica.net
Comment:
Ai que tá o X.
O Dono de padaria que quer um sistema basico de estoque e tem um orçamento modesto tem uma mentalidade diferente do cliente da empresa que e eu trabalho.
Eu atendo os 2 se possivel mas no caso do sistema da padaria eu não foco tanto em qualidade e realmente esse sistema não precisa do nivel de qualidade do projeto que eu atendo como funcionario de uma empresa.
Você ta excluindo do mercado os pequenos clientes e os sitemas triviais. Eles existem… Esses clientes querem as coisas funcionando… Esses projetos não tem muita chance de crescer muito etc.. etc.. Talvez o cliente nem veja no sistema um potencial maior do que apenas um mero sistema
É claro que qualidade importa e em momento nenhum eu não disse que nao importa.. só estou mostrando que existe um outro tipo de cliente e que projetos triviais existem aos montes e eu não tenho nenhuma vergonha de fazer um projeto trivial.
Não estou excluindo ni ninguém, Felipe. o ponto está na pergunta que você não respondeu: por que eu vou usar uma paltaforma como java para atender a este cara? Esse sistema pode ser feito em Access, VB.Net, Delphi, PHP-GTK ou qualquer paltaforma onde a produtividade seja palavra de ordem.
Geralmente nestas plataformas se reescreve ao invés de adaptar, e apra sistemas simples isso vai muito bem. Como eu já disse algumas muitas vezes neste post qualidade é relativo, a qualidade que importa é aquela pela qual o cliente pagou.
E isso não tem nada a ver com ‘o cliente não quer saber como é feito’, muito pelo contrário. O cliente realmente não quer saber como é feito mas ele vai se importar ,strong>e muito se você fez este programa simples em Java ou C# sem nenhum critério de qualidade e vai ter que mudar 5.033 classes quando ele aumentar o preço do pão.
Neste caso é papel do profissional de software optar por uma solução simples que atenda ao cliente dentro de critérios de qualidade mínimos. Não adianta culpar a ferramenta (OO, no caso) por uma escolha ruim do arquiteto.
Bom…
Como eu trabalho com Java, quando eu vou fazer um “freela” trivial eu uso a linguagem que me sinto mais confortavel. Não é uma escolha técnica. Se eu tivesse uma empresa onde existissem pessoas qualificadas em java, RoR, php, ai sim a escolha da plataforma seria mais justificavel.
Sobre mudar 5000 classes: concordo que o cliente não está nem ai mas se para fazer uma mudança simples, é necessário modificar 5 mil classes, vamos concordar que esse sistema não tem qualidade alguma.
E pra finalizar..a minha indagação inicial, que pode nao ter ficado muito clara, é sobre o exagero na “busca de qualidade” (entre aspas mesmo) levando muita gente a perder o foco na necessidade real do cliente e isso eu já vi aos montes (por inexperiencia ou incompetencia)
Jamais questionei ou culpei a utilidade de uma ferramenta.
No final quis dizer: jamais culpei ou questionei a utilidade de alguma ferramenta
Estes sistemas são frutos do que venho criticando no post, exatamente a visão “o cliente não quer saber”. Esta é uma visão amadora, no meu ponto de vista. Como mencionei acima: “Tudo deve ser pesado e um arquiteto profissional deve saber tirar estas medidas e escolher a solução mais adequada.“, seja ela OO, procedural, glue code ou o que for.
Seria amador se o cliente nao se importasse e eu também. Eu sempre me importo, mas eu graduo essa importancia de acordo com o projeto.
Um minimo de qualidade é algo mandatorio em qualquer projeto de software.
Quem faz um software como voce descreveu porque só sabe fazer assim, nao tem qualidade. Mas existem casos em que fazer software “de baixa qualidade” é uma escolha.
Aew Phillip,
“o cliente não quer saber em que foi feito, se é OO ou não, ele quer que atenda as suas expectativas.”
A principio, acho que a frase acima esta correta em grande parte dos casos, mas existem alguns casos, que o cliente exige saber como é feito as coisas dentro da empresa, e as vezes a linguagem é decisiva para a aceitação de um projeto. Claro, isso acontece em projetos grandes, e em empresas grandes.
Um exemplo seria:
O Banco do Brasil abre uma licitação para desenvolvimento de um sistema para controle de contas, neste caso será certo que o cliente vai te exigir que o projeto seja em uma X tecnologia, querendo o saber o tempo exato de desenvolvimento de cada modulo do sistema, ira cobrar os casos de uso e mais aquele monte de coisa que agente já sabe…
para mim cada projeto deve ser tratado diferente, e cada cliente deve ser tratado de acordo as suas necessidades.
gostei do seu post.
Concordo com o artigo, pois habilidade para suportar a evolução/mudança do negócio rapidamente é a vantagem competitiva esperada.
Dentre os ativos de uma empresa, destacam-se os processos de negócio, que são refletidos em rotinas e estruturas de dados as quais se organizam em sub-rotinas, objetos, componentes e, mais recentemente, em serviços.
Com isso, defender esses ativos, com uma boa arquitetura, é estratégico para qualquer empresa. O arquiteto pode escolher fazer parte do problema ou da solução.
Lembrando que o software tem um ciclo de vida, a frase:
“o cliente não quer saber em que foi feito, se é OO ou não, ele quer que atenda as suas expectativas”
Só faria sentido estrito se estivessemos falando somente da concepção do sistema, do desenvolvimento em si, mas a manutenção (correção e evolução) ele vai querer saber porque demora tanto, aí ele mesmo sem saber os detalhes da implementação, sentirá que algo não foi feito com qualidade…