É tudo muito 'lindo' mas e onde tá o negócio?

Assuntos Gerais
#21

Eu já vi mudarem o sistema de um grande grupo de empresas no RJ porque o antigo, que atendia totalmente, era “feio” e “ultrapassado”. O novo foi comprado com o toda a pompa, todo o glamour e, até onde sei, até hoje (5 anos de uso) só da dor de cabeça e atende porcamente.

Resumindo: a não ser que os clientes sejam engenheiros, caprichem no visual. É 99% da venda.

UMA HISTORINHA IMPORTANTE:

Um comerciante vendeu para outro um punhado de feijão estragado e ganhou 10 reais. O segundo vendeu para um terceiro e ganhou 12 reais. Este último foi cozinhar o feijão e descobriu que estava estragado. Foi então reclamar com o vendedor que respondeu: “esse feijão é para vender e não para cozinhar”.

E assim caminha o mundo dos negócios. Quer vocês gostem ou não. Software é para VENDER e não para FUNCIONAR. Se não concordam, abram uma ONG ou sejam atropelados pela concorrência. É triste, mas é a REALIDADE.

#22

O que mais importa para o cliente é usabilidade…

#23

[quote=guariba]Eu já vi mudarem o sistema de um grande grupo de empresas no RJ porque o antigo, que atendia totalmente, era “feio” e “ultrapassado”. O novo foi comprado com o toda a pompa, todo o glamour e, até onde sei, até hoje (5 anos de uso) só da dor de cabeça e atende porcamente.

Resumindo: a não ser que os clientes sejam engenheiros, caprichem no visual. É 99% da venda.

UMA HISTORINHA IMPORTANTE:

Um comerciante vendeu para outro um punhado de feijão estragado e ganhou 10 reais. O segundo vendeu para um terceiro e ganhou 12 reais. Este último foi cozinhar o feijão e descobriu que estava estragado. Foi então reclamar com o vendedor que respondeu: “esse feijão é para vender e não para cozinhar”.

E assim caminha o mundo dos negócios. Quer vocês gostem ou não. Software é para VENDER e não para FUNCIONAR. Se não concordam, abram uma ONG ou sejam atropelados pela concorrência. É triste, mas é a REALIDADE.[/quote]

Eu sei, o povo só se interessa pela beleza no software.

As vezes um samppo vende mais que o outro porque tem um rotulo melhor, mais um conteudo infinitivamente inferior.

É a realidade, as pessoas preferem interfaces com aberturas, bonitas e bem desenhadas do que um rapido, eficiente e que gere lucro para ela.

Se o cliente quer um software inútil, eu farei um inútil desde que me pague(obivio) mesmo que seja contra meus principios e meus sentimentos, afinal sou mais racional que emocional.

Lógico que há clientes que querem usabilidade, então eu darei a eles usabilidade.

Eu não trabalho para mim, trabalho para meu cliente.

Mais não intendo o porque das pessoas(no geral) se interessarem por “maquiagens” que não passam de “peso extra” e só atrapalham na hora de usar, desenvolver e fazer a manutenção.

#24

[quote=labavel]Ja houvio falar que o cliente diz se o seu sistema e bom ou ruim pela vizão que ele tem e não pelo codigo bem elaborado.

[/quote]

Concordo em partes.

Obviamente o cliente vai criticar ou elogiar o que ele alcança com os olhos… que é a interface gráfica.
Mas algoritmos mal escritos podem tornar um sistema lento, mesmo com uma interface gráfica impecável, e isso também servirá de crítica para o sistema.

#25

Bem-vindo ao mundo cumpadi!

Quando for comprar meu próximo carro lembrarei deste tópico e optarei por um Buggy de fibra e motor de fuquinha…

#26

[quote=giulianocosta]Bem-vindo ao mundo cumpadi!

Quando for comprar meu próximo carro lembrarei deste tópico e optarei por um Buggy de fibra e motor de fuquinha…[/quote]

Pois é, tem gente esquecendo que também é usuário.

Concordo com o rogelgarcia, UX é o que é buscado. E às vezes só com interface rica e bonita pra se conseguir. Outras vezes, firula só atrapalha, que o digam os usuários do Windows Media Player. Pra muita coisa eu prefiro muito mais um notepad++ do que qualquer outro editor de texto.

Ah, pessoal, sei que aqui não é forum de português, e nem sou perfeito, mas vamos manerar aí. Não precisa agredir a coitada da nossa língua tb.

#27

[quote=renamed][quote=labavel]Ja houvio falar que o cliente diz se o seu sistema e bom ou ruim pela vizão que ele tem e não pelo codigo bem elaborado.

[/quote]

Concordo em partes.

Obviamente o cliente vai criticar ou elogiar o que ele alcança com os olhos… que é a interface gráfica.
Mas algoritmos mal escritos podem tornar um sistema lento, mesmo com uma interface gráfica impecável, e isso também servirá de crítica para o sistema.[/quote]

Bom, eu tenho a oportunidade de conhecer algumas das usuárias finais do sistema no qual eu trabalho, e são pessoas para as quais o que menos interessa é a interface, isso eu posso garantir. E nenhuma delas é especialista em informática. Mas para pessoas que tem que realizar dezenas de lançamentos por dia em um sistema, trabalhar em um sistema lento ou cheio de erros causa stress além de ser anti-produtivo. E sistema lento e cheio de erros é sinônimo de código porco. Assim, a relação:

código bem-escrito == software funcionando == cliente satisfeito == $$$$

para mim é mais do que verdadeira. O problema é que para algumas pessoas código bem-escrito é entupí-lo de classes e padrões de projeto, e aí colocam a culpa nas metodologias, quando na verdade a culpa é de quem não sabe usar.

#28

Não li omiolo do topico, mais eu acho que um bom design é fundamental para um sistema… afinal vc n compra um carro levando em consideração apenas se ele anda ou não bem… e uma coisa é falar do design e outra e falar que o sistem n presta… então seria impossivel fazer um sistema bonito e que funcione ? Acho que as vezes as pessoas errão muito na metodologia que implementão em um sistema, muitas vezes por não conhecer o projeto em si… acho que isto é o desafio da nossa profissão encontrar meios de fazer a coisa ir para frente da melhor forma possivel… incluindo um design e uma alta qualidade de projeto(código)…

Minha opnião!!

#29

Uma coisa é fato. Se nossos clientes são ignorantes, a culpa é nossa, não dos nossos clientes. Ele não tem obrigação nenhuma de estudar TI ou de compreender a dimensão do que estão pedindo. Eles tem o papel de pedir, seja qual for a idéia mirabolante que eles tenham.

A falha é nossa. Somos nós que não sabemos diferenciar entre os próprios cargos da nossa função. Nós é que não sabemos dizer ao cliente prazos mais precisos, ou informa-los dos custos de seus desejos.

#30

[quote=ViniGodoy]Uma coisa é fato. Se nossos clientes são ignorantes, a culpa é nossa, não dos nossos clientes. Ele não tem obrigação nenhuma de estudar TI ou de compreender a dimensão do que estão pedindo. Eles tem o papel de pedir, seja qual for a idéia mirabolante que eles tenham.
[/quote]

Eu diria mais, eu diria que é falta de alguns clientes serem chamados de embecis. Se vc for num marceneiro e pedir um armário sem portas ele manda vc à … então porque quando um “cliente” pede uma funcionalidade idiota os gerentes aceitam ?

Uma razão muito simples : eles são gerentes só de nome.

Num ambiente sério de desenvolvimento de software existem pessoas olhando os custos e os lucros. Pessoas que pederão seu empregos se esses custos e lucros não se equilibrarem. Não é, obviamente , o ambiente da maioria das empresas de desenvolvimento no mundo.

Infelizmente a maioria dos desenvolvedores e “gerentes” ainda acha que os requisitos funcionais são os mais importantes. Não são!
Os requisitos mais importantes são aqueles ditados pela produtora. O cliente fica satisfeito com qualquer forma que atenda a sua necessidade. O problema é que ele confunde necessidades. muitos usuários acham muito importante ter teclas de atalho para fazer cadeia de comandos rápidamente, mas esquecem que muitas dessas cadeias poderiam ser feitas apenas com um comando.

Concordo com o rmendes08 , a qualidade do código sim é o ponto mais fundamental do desenvolvimento é isso que traz lucro ou prejuizo à empresa produtora do software e é nisso que temos que pensar, não se o cliente vai ou não gostar. O que adianta o cara achar lindo e maravilhoso se manter o sistema está nos dando prejuizo ?

Se o cliente quer um sistema bonito : pague por ele! caso contrário leva o feio mesmo. É isto que a apple descobriu faz tempo. Que ha pessoas que pagam mais se apenas adicionarmos beleza.

Nas empresas produtoras de software de hoje escasseiam os testers quanto mais os designer e nem pensar em especialistas em ergonomia… afinal, os desenvolvedores , infelizmente, não sabem seguir padrões…então do que adianta essas pessoas os criarem ?

duas palavras : desenvolvimento sustentável. Isso significa “faça hoje sem ferrar o (seu) amanhã”.

quando eu afirmo que o cliente nem sempre tem razão vem um orde de gente dizer que é preciso abrir as pernas para comer. Nesta mentalidade clientes e empresas se merecem, e as empresas merecem falir. é preciso saber dizer não quando é não, e saber negociar quando é talvez. Dizer que sim a tudo, é, simplesmente infantil. Não é por acaso que “saber dizer não” é uma das bandeiras ageis.

#31

[quote=ViniGodoy]Uma coisa é fato. Se nossos clientes são ignorantes, a culpa é nossa, não dos nossos clientes. Ele não tem obrigação nenhuma de estudar TI ou de compreender a dimensão do que estão pedindo. Eles tem o papel de pedir, seja qual for a idéia mirabolante que eles tenham.

A falha é nossa. Somos nós que não sabemos diferenciar entre os próprios cargos da nossa função. Nós é que não sabemos dizer ao cliente prazos mais precisos, ou informa-los dos custos de seus desejos.
[/quote]

Discordo totalmente Vinão, em uma faculdade de TI se aprende noções de economia , administração, estatística, direito, pq raios o pessoal das outras áreas não tem que ter algum conhecimento básico de TI? E não me refiro a Excel.

Estamos em 2010 e hoje no mercado competitivo (leia-se, onde estão os contratantes, analistas de negócio, etc…) quem não sabe um pouco a mais de TI mesmo na condição de usuário não tem, ou melhor, não deveria ter espaço no mercado.

O que se vê são pessoas totalmente ignorantes, com responsabilidade de tocar um projeto de um sistema importante para a empresa, sem conhecimento e experiência no assunto, pessoas que não acessam um internet banking, que não conhecem as tendências atuais para web, pedindo telas que 15 anos atrás já eram feias, hoje então…

Obviamente que um gerente de projeto tem que ter o tato de sugerir e aconselhar as melhores coisas, como disseram acima, saber dizer não, mas também não dá para exagerar nos princípios, hoje para qualquer projetinho de merda o patrocinador cota 3, 4 empresas, no fim das contas o que vai contar é o custo, mas se desde a fase de proposta começar com as limitações, a coisa complica cada vez mais, sem contar que infelizmente estamos nas mãos do maldito pessoal do comercial, é ai que começa toda a merda, pois esses também são totais ignorantes em TI.

#32

Eles tem isso mesmo, aprendem noções de TI. Por noção de TI não entende-se que ele deva saber administrar um projeto de TI, ou ter noções de custo ou do processo de desenvolvimento de um software. Assim como você ganha noções de administração, mas fica muito longe de saber administrar uma empresa.

De qualquer forma, ainda é culpa nossa que as disciplinas de TI ministradas em faculdade sejam ruins. Se estamos vivenciando esse problema na área, tinhamos nós que pressionar o MEC a fornecer ementas mais coerentes para o que seria o mínimo que alguém deveria aprender em TI hoje. Ou seja, a falha continua sendo nossa.

[quote=Daniel_MV]Estamos em 2010 e hoje no mercado competitivo (leia-se, onde estão os contratantes, analistas de negócio, etc…) quem não sabe um pouco a mais de TI mesmo na condição de usuário não tem, ou melhor, não deveria ter espaço no mercado.

O que se vê são pessoas totalmente ignorantes, com responsabilidade de tocar um projeto de um sistema importante para a empresa, sem conhecimento e experiência no assunto, pessoas que não acessam um internet banking, que não conhecem as tendências atuais para web, pedindo telas que 15 anos atrás já eram feias, hoje então…[/quote]

A diferença também é que estamos numa das únicas áreas onde 5 ou 6 anos é considerado muito tempo. Você estuda nas suas noções de administração na escola o Fordismo, Taylorismo, Fayol e outras escolas administrativas, que existem a vários anos. E muitos desses conceitos ainda são válidos. É claro que houve a introdução de técnicas mais modernas, como o Kaisen, Just-in-time ou o Scrum, mas eles não invalidaram o que havia no passado.

Por isso, temos que estar realmente preparados para um cliente que não seja tão antenado em TI quanto nós mesmos.

Você tocou num ponto ainda mais sensível. Se nem o departamento comercial das empresas de TI está sabendo dimensionar os projetos que ele mesmo vende, o que dizer então do cliente? É aí que entro novamente em dizer que se o cliente é ignorante, a culpa é nossa. É o nosso comercial que orça errado, não o do cliente. Somos nós que deixamos transparecer que em software tudo é possível, sem custo e que nós “damos um jeitinho”. Se nosso comercial baixa a cabeça e promete o mundo, a culpa é nossa, não do cliente. Se as faculdades dos outros cursos não estão acertando nas ementas de TI, e isso nos afeta, e não fazemos nada a respeito, a culpa é nossa também.

Só não podemos é ficar jogando no cliente a responsabilidade dos nossos erros.

#33

Eu concordo com o ViniGodoy… se vc é engenheiro civil e vem um cliente pedir um predio no formato de piramide, só que de ponta cabeça e vc fala que da para fazer… e no final das contas o predio cai… a culpa é do cliente que só pediu e confiou em vc ?

#34

Eles tem isso mesmo, aprendem noções de TI. Por noção de TI não entende-se que ele deva saber administrar um projeto de TI, ou ter noções de custo ou do processo de desenvolvimento de um software. Assim como você ganha noções de administração, mas fica muito longe de saber administrar uma empresa.

De qualquer forma, ainda é culpa nossa que as disciplinas de TI ministradas em faculdade sejam ruins. Se estamos vivenciando esse problema na área, tinhamos nós que pressionar o MEC a fornecer ementas mais coerentes para o que seria o mínimo que alguém deveria aprender em TI hoje. Ou seja, a falha continua sendo nossa.

[quote=Daniel_MV]Estamos em 2010 e hoje no mercado competitivo (leia-se, onde estão os contratantes, analistas de negócio, etc…) quem não sabe um pouco a mais de TI mesmo na condição de usuário não tem, ou melhor, não deveria ter espaço no mercado.

O que se vê são pessoas totalmente ignorantes, com responsabilidade de tocar um projeto de um sistema importante para a empresa, sem conhecimento e experiência no assunto, pessoas que não acessam um internet banking, que não conhecem as tendências atuais para web, pedindo telas que 15 anos atrás já eram feias, hoje então…[/quote]

A diferença também é que estamos numa das únicas áreas onde 5 ou 6 anos é considerado muito tempo. Você estuda nas suas noções de administração na escola o Fordismo, Taylorismo, Fayol e outras escolas administrativas, que existem a vários anos. E muitos desses conceitos ainda são válidos. É claro que houve a introdução de técnicas mais modernas, como o Kaisen, Just-in-time ou o Scrum, mas eles não invalidaram o que havia no passado.

Por isso, temos que estar realmente preparados para um cliente que não seja tão antenado em TI quanto nós mesmos.

Você tocou num ponto ainda mais sensível. Se nem o departamento comercial das empresas de TI está sabendo dimensionar os projetos que ele mesmo vende, o que dizer então do cliente? É aí que entro novamente em dizer que se o cliente é ignorante, a culpa é nossa. É o nosso comercial que orça errado, não o do cliente. Somos nós que deixamos transparecer que em software tudo é possível, sem custo e que nós “damos um jeitinho”. Se nosso comercial baixa a cabeça e promete o mundo, a culpa é nossa, não do cliente. Se as faculdades dos outros cursos não estão acertando nas ementas de TI, e isso nos afeta, e não fazemos nada a respeito, a culpa é nossa também.

Só não podemos é ficar jogando no cliente a responsabilidade dos nossos erros. [/quote]

Vini eu concordo com vc na questão de uma mea culpa mas não podemos nos ajoelhar no milho e se sentir culpados de tudo também.

Gestão de Projetos pelo PMBOK que é o conceito difundido no mercado e amplamente utilizado hoje em dia, não é a Gestão de Projetos de TI, é Gestão de Projetos, qualquer projeto.

O Líder de projeto do lado do contratante , é sempre um gerente, é sempre um cara bem remunerado, o que se cobra é o mínimo, o cara não precisa realmente dominar análise de pontos de função, mas saber entender um requisito e um caso de uso não é nada demais também.

#35

O fracasso das “soluções”, tem várias origens.

Muitos e muitos sistemas são desenvolvidos sem nenhum planejamento, já vi empresa de “processamento de dados”, que possuia equipe de TI, desenvolveram todas “soluções” em ferramentas diferentes:
Módulos em Clipper - processamento de folha pagamento, contas a receber, etc
Módulo em PHP - cadastrar novos funcionarios na base MySQL
Módulo em Delphi - monitorar a base MySQL, chamar programa em Clipper para atualizar os demais sistemas em Clipper
Módulos em VB - contas a pagar, etc
etc

Alguns sistemas começam bem modestos, alguns em clipper, cerca de 10, 15, 20 anos, linguagem mais fácil do mundo, afinal, tem poucos recursos e sem regras, DBF ( que é o mesmo que TXT ), estes sistemas foram crescendo desordenadamente, há grandes empresas nesta situação, há anos estão investindo em SAP, DataSul, até tirar de vez tais sistemas.

O usuário/cliente tem todo direito de pedir o que parecer absurdo, cabe a cada desenvolvedor traduzir, analisar com coerencia a melhor forma de atendê-lo, pois há solicitações se fossem desenvolvidas a risca, tornariam o processo de uso burocratico, manual.

Todas as ferramentas (linguagens) de desenvolvimento deveriam ser gratuitas, existem várias formas de se ganhar.
As ferramentas evoluem (será ?), mas a que custo ? (não o financeiro diretamente, requisitos de Hardware, sofware, incompatibilidades, binários de terceiros, etc) Delphi 7, Delphi 8, Delphi 2005, Delphi 2006, Delphi 2009, Delphi 2010, mas o que é isso ?! moda de confecção, automóvel ? não chamo isso de evolução, por ser comercial e fechado, causam incovenientes.

Usar ferramentas de produtividade (Maker, etc) é ótimo, para empresas de consultorias, para os profissionais programadores, desenvolvedores ficariam sem opções no mercado.

Todas as ferramentas possuem os pontos fortes e fracos, não acredito que exista a melhor, dependerá da necessidade, habilidade, criatividade de cada um para extrair o melhor.

e por ai vai…

[quote=Sparcx86]Em muitos lugares a area de TI é uma das mais caras e das mais criticadas porque? Simples, gerentes abrem as pernas pra funcionalidades ridiculas, telas imensamente complexas que ninguem irá usar e o requisito de negócio qusae sempre é posto de lado em troca de framewokrs e design patterns… não que isso não seja importante mas o que devia ser o centro da TI é o negócio e não uma tela bonita que um webdesigner que não entende nada de desenvolvimento web inventou.

Existem ferramentas muito produtivas que atendem praticamente a qualquer requisito de negócio que voce pensar e porque não sao tão utilizadas? simplesmente porque sempre há um imbecil que quer uma tela complexa demais que a ferramenta não se adequa.

Devemos pensar nisso e começar a pensar mais top down, o que importa é o negocio e TI deve começar a mudar pra este lado![/quote]

#36

[quote=Daniel_MV]Vini eu concordo com vc na questão de uma mea culpa mas não podemos nos ajoelhar no milho e se sentir culpados de tudo também.

Gestão de Projetos pelo PMBOK que é o conceito difundido no mercado e amplamente utilizado hoje em dia, não é a Gestão de Projetos de TI, é Gestão de Projetos, qualquer projeto.

O Líder de projeto do lado do contratante , é sempre um gerente, é sempre um cara bem remunerado, o que se cobra é o mínimo, o cara não precisa realmente dominar análise de pontos de função, mas saber entender um requisito e um caso de uso não é nada demais também.[/quote]

Ainda não concordo com você. O papel desse líder vai ser gerir o projeto, no sentido de acompanhar o seu desenvolvimento, estimar a sua conclusão, verificar se sua equipe está ou não cumprindo as metas estabelecidas, e facilitar seu acesso aos recursos que você necessite na empresa dele.

Mas quem tem a função de estimar prazos, definir a viabilidade técnica e definir os custos de cada caso de uso somos nós. O cliente não fala em caso de uso, ele fala em requisito.

O problema ainda é nosso. Muitas empresas de TI tem um departamento comercial que, na pressa de vender, prometem tudo. Não temos uma figura presente junto ao líder de projetos do cliente, dando a ele uma visão de que um projeto de TI não é um projeto simples, é cheio de riscos, e que ele terá que fazer escolhas, em muitos pontos.

Acho que esse é um dos grandes valores das técnicas ágeis. Elas forçam a equipe técnica a se aproximar o seu cliente, a fazer com que ele entenda como o projeto está indo e deixa para claro para ele as escolhas que faz, do que está abrindo mão, que tipo de limitações ele terá e os custos de cada etapa do projeto. E claro, uma comunicação aberta e franca, sem que um dos lados prometa o que não pode cumprir.

#37

Errado. Projetos de Software não são administrados do mesmo jeito que os outros. Este é o erro , o enorme erro, que existe na cabeça das pessoas desde dos anos 60. Projetos de Software lidam com requisitos dinâmicos, nenhum outro projeto é assim. Nenhum outro tipo de projeto funciona nessas condições.

Errado. O gerente normalmente não é lider de coisas nenhuma e por isso que os projetos falham.
Gerente é uma aberração. Em empresas que não de software vc tem gerentes de projeto e gerentes de produto. Não existem gerentes de equipe. E não existem pessoas que acumulam essas 3 atividades. Isso é uma falcatrua perpétuada pelo bando de sem noção que são os gerentes de software tradicionais que ganham muito,falam mais ainda, mas não fazem nada e nunca são responsabilizados.

#38

Fordismo , Taylorismo ,etc… são aplicáveis em modelos de linha de produção. Estes modelos simplesmente não são aplicáveis a produção de software.
Ao tentar fazer isso criam-se aberrações como o waterfall e os processos atuais na maioria das empresas.
Existem vários autores alertando para o que é realmente um bom modelo para construir software… antes de agil e antes de scrum. Mas ninguem ouviu.
Foi preciso vir o agil - que é uma metodologia baseada em puxar o saco do gerente de produto - e XP que é radical e começa com um grande “vcs estão todos errados” - para que certas práticas recomendadas ha anos vissem a luz.

Mesmo hoje, ainda existem duvidas se agil é o certo. Não é certo, mas é bem mais certo do que metodologias irracionais, tayloristicas, pseudo-funcionais, que consomem rios de dinheiro às empresas e elas gostam… esse que é o problema. Software é o único produto que quanto mais caro melhor… é por isso que o movimento free é visto com maus olhos. O que as empresas ainda não perceberam é que o sistema onde têm 20% de lucro poderiam ser sistemas com 80% de lucro. E elas não perceberam exatamente porque são compostas por pessoas sem nenhuma formação em desenvolvimento de software - seja académica ou outra.

#39

Contextualizem: http://nerdson.com/blog/renice

#40

Perfeito.