Colocar aquela facilidade a mais para "melhorar" o software

Olá

Nós programadores temos a mania de adicionar "facilidades" imaginando que software que faz mais coisas só pode ser melhor. Uma coisinha aqui, outra ali e já temos um monte de desculpas para não cumprir os prazos.

Mas será que estes badulaques serão bons para o cliente? Já pensaram que colocando mais coisas o cliente demorará mais para aprender a usar nosso maravilhoso software?

Pois é, sobre este modo pouco ágil de desenvolver vale a pena ler o pequeno texto Foco no cliente do Peter Abilla onde aparece o seguinte gráfico feito pela nossa amiga Katty Sierra:

[]s
Luca

No Rio Java Summit 2006 o Scott Ambler falou que cerca de 60% das features dum software em média não são utilizadas pelo cliente. Incrível mesmo!

Legal

yeap, mas a grande pergunta é: quais são as features utilizadas?
como saber quais serão utilizadas antes de desenvolve-las e disponibiliza-las para o cliente?

urubatan wrote:yeap, mas a grande pergunta é: quais são as features utilizadas?
como saber quais serão utilizadas antes de desenvolve-las e disponibiliza-las para o cliente?

Diga não a todas features, repita não mais 10x para cada feature. Depois disso sobram realmente as que são necessárias.

louds wrote:

urubatan wrote:yeap, mas a grande pergunta é: quais são as features utilizadas?
como saber quais serão utilizadas antes de desenvolve-las e disponibiliza-las para o cliente?

Diga não a todas features, repita não mais 10x para cada feature. Depois disso sobram realmente as que são necessárias.

Se eu dizer nao para todas nao vai sobrar nada.

]['s

E são nessas que o usuário não usa que nós gastamos mais tempo desenvolvendo.

Olá

fabgp2001 wrote: Se eu dizer nao para todas nao vai sobrar nada.

Ou melhor, sobrará somente o que o cliente acha mais importante.

Há uma regra para desenvolver sistemas cumprindo prazos e ainda sobrar uns trocos:

Nunca fazer TUDO o que o cliente pediu ou sonhou

Geralmente o cliente não sabe exatamente o que quer e aproveita a ocasião para pedir um monte de coisas que ele viu não sei aonde e que acharia bom ter também. É preciso filtrar bem e separar o que é realmente essencial. O ideal é que a gente vá soltando o software e nas próximas reuniões explique ao cliente porque tal e tal firula não acrescenta nada ao software.

Mesmo sendo bem rigoroso no que vai para a lista de facilidades do software, é dificl lucrar muito com desenvolvimento de software. Geralmente a gente chuta um prazo curto e um preço baixo para poder ganhar o serviço. Precisa ser muito objetivo para não perder dinheiro.

[]s
Luca

O usuário tende a criar um fluxo de trabalho dentro do sistema (ou módulo) usando as funções principais do sistema. Se vc quiser adicionar mais features ao sistema tente primeiro entender onde isso vai se encaixar nesse fluxo...

O usuário nunca irá se desviar desse fluxo e dessa rotina, então nem adianta colocar uma feature num item de menu ou que tenha que desvia-lo da rotina de uso.

Outro porém interessante é que muitos desenvolvedores desenvolvem para massagear o seu ego. Ou seja, para ele não importa que ele pode fazer, resolver e nunca mais ter problemas fazendo um sisteminha em VB. Ele vai querer enfiar goela baixo do usuário a ultima tecnologia. Então esse desenvolvedor tende a valorizar mais a feature que vai usar as tecnologias X, Y e Z e não aquela que o usuário mais vai utilizar.

Tem também aquela questão do desenvolvedor que desenvolve para ficar mais fácil de desenvolver, mais simples de manter sem ao menos analisar o que isso vai impactar na usabilidade do sistema. Ao invés de criar um sistema mais "fluido" ele cria uma caralhada de CRUDs meio desconexos.

Luca wrote:Há uma regra para desenvolver sistemas cumprindo prazos e ainda sobrar uns trocos:

Nunca fazer TUDO o que o cliente pediu ou sonhou

O engraçado dessa regra é que ela vai meio "contra" o gráfico, porque o "pico de felicidade" do usuário é justamente menos da metade de tudo que ele pediu.

E tem outra regrinha que diz que o primeiro prazo que você não deve dizer é exatamente o prazo que você está acha que vai fazer.

dreamspeaker wrote:O engraçado dessa regra é que ela vai meio "contra" o gráfico, porque o "pico de felicidade" do usuário é justamente menos da metade de tudo que ele pediu.

Acho que houve um problema de interpretação aqui.

A mensagem do gráfico é que o pico é na metade, e o Luca disse pra "nunca fazer TUDO...". Pelo meu entendimento, o Luca não tá dizendo que não é pra fazer nenhuma, mas sim pra não fazer todas. E não fazer todas se encaixa com fazer somente a metade.

Olá

Vou explicar mais a tal da regra. A gente se reune com o cliente e ele pede um software que faça "alguma coisa". Mas geralmente quer esta "alguma coisa" com mais um monte de "exigências".

No tempo em que eu aprendi a desenvolver sistemas, havia uma outra regra de todo software PRECISA ser descrito com uma única frase. Então, nas primeiras reuniões com o cliente a gente precisa entender bem quais as principais funções do software e começar a elaborar a tal frase. Esta frase precisa ser bem entendida tanto por nós como pelo cliente pois o que está nela nosso software TEM que fazer.

Esta frase começa a documentação do software e com mudanças cosméticas trocando linguagem técnica por marketing ou linguagem humana, esta mesma frase vai para nosso site, folders promocionais e até mesmo contrato entre as partes.

O resto das facilidades a gente deve filtrar e só incluir se for um desejo MUITO forte do cliente manifestado em diversas reuniões, principalmente se ele pagar para fazer. Neste item que chamo de resto incluo relatórios. A gente deve vender relatório por unidade para o cliente sentir no bolso que não deve pedir aqueles relatórios que nunca ninguém lerá.

Requisitos de desempenho precisam ser encarados com cuidado pois às vezes são irreais. Já participei de um projeto onde se pedia throughput de 200 transações por segundo. Mesmo com mais facilidade de máquina que existe hoje, isto é muito difícil quando a transação precisa atravessar por vários servidores e vários firewalls. Provavelmente o cara que escreveu a especificação não tinha a menor idéia disto. Nosso projeto tinha largura de banda de 8 giga, load balancing com 2 + 2 servidores RISC cada um com 12 processadores e 16 Gb de memória + Oracle paralelo em rede gigabit e mesmo assim foi preciso gamb para atender.

PORËM, há algumas facilidades administrativas que a gente deve incluir em TODOS os softwares e que para o cliente não agrega valor a menos em caso de desastre. São coisas como logs, facilidades de localizar erros, facilidades para modificar configurações remotamente sem recompilar, etc. Isto a gente inclui no nosso marketing para provar ao cliente que nosso software vale mais do que o concorrente. Na verdade a gente precisa ter isto pronto como se fosse o framework da nossa empresa. Faz parta da nossa "expertise".

Escrevi paca mas acho que agora ficou mais claro. Geralmente o cliente não sabe exatamente o que é essencial e pede tudo. Nossa função, com ajuda de alguém que conheça bem o business, é filtrar para fazer um sistema que sirva para a tal "alguma coisa".

[]s
Luca

ZehOliveira wrote:

dreamspeaker wrote:O engraçado dessa regra é que ela vai meio "contra" o gráfico, porque o "pico de felicidade" do usuário é justamente menos da metade de tudo que ele pediu.

Acho que houve um problema de interpretação aqui.

A mensagem do gráfico é que o pico é na metade, e o Luca disse pra "nunca fazer TUDO...".

Se é metade, um pouco menos que a metade, é uma questão geométrica!

O que eu quis dizer foi que, para o cliente se sentir feliz, ele precisa de só metade daquilo que ele achava que ele precisaria pra ser feliz!

Vixe, confuso... também, quase 2 da manhã...

Gostei da tática da frase, Luca!

Pootz. Essa de cliente pedir 3487 tipos de relatórios diferentes, quando vai lê apenas 5 é de deixar qualquer programador/analista p da vida.

Chato é quando a gente gasta aquele tempão fazendo uma feature, coloca o software em produção e depois de um tempo percebe que aquela feature não tava funcionando, não deu erro e ninguém reclamou de nada. Em outras palavras, ninguém usou.

ZehOliveira wrote:Essa de cliente pedir 3487 tipos de relatórios diferentes, quando vai lê apenas 5 é de deixar qualquer programador/analista p da vida.

É verdade, mas o problema é que às vezes o programador aceita isso só pra agradar o cliente (mais ou menos como o Flávio falou acima). Eu mesmo passei por uma situação dessa alguns meses atrás. Eu assumi um projeto que já estava iniciando a fase de implementação, e o cara que tinha feito todo o planejamento, reuniões com cliente, tinha saído fora da empresa. Ele tinha prometido mundos e fundos pra cliente, que já era chata por natureza, e não se importou em saber se era possível ou não, se seria muito trabalhoso ou não... enfim. Durante o andamento e as entregas ela ficava cobrando tudo o que havia sido prometido antes. E pra explicar que determinada funcionalidade não agregaria nada? E pra explicar que outra funcionalidade demandaria muito tempo pra ser feita? "Ahhh não!! Vocês prometeram isso antes!!!". Era assim mesmo. O próprio contato do cliente, que era meio que um intermediador, falava que ela era chata pra caramba.

Notícias, artigos e o maior fórum brasileiro sobre Java