http://www.guj.com.br/posts/list/2.java JForum - http://www.jforum.net
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 [url=http://www.shmula.com/158/focus-on-the-customer]Foco no cliente[/url] do Peter Abilla onde aparece o seguinte gráfico feito pela nossa amiga Katty Sierra:
[img]http://static.flickr.com/70/196889323_56424491cd_o.jpg[/img]

[]s
Luca]]> http://www.guj.com.br/posts/preList/39019/208165.java http://www.guj.com.br/posts/preList/39019/208165.java GMT http://www.guj.com.br/posts/preList/39019/208191.java http://www.guj.com.br/posts/preList/39019/208191.java GMT http://www.guj.com.br/posts/preList/39019/208243.java http://www.guj.com.br/posts/preList/39019/208243.java GMT como saber quais serão utilizadas antes de desenvolve-las e disponibiliza-las para o cliente?]]> http://www.guj.com.br/posts/preList/39019/208454.java http://www.guj.com.br/posts/preList/39019/208454.java GMT como saber quais serão utilizadas antes de desenvolve-las e disponibiliza-las para o cliente?[/quote]

Diga não a todas features, repita não mais 10x para cada feature. Depois disso sobram realmente as que são necessárias.]]> http://www.guj.com.br/posts/preList/39019/208456.java http://www.guj.com.br/posts/preList/39019/208456.java GMT como saber quais serão utilizadas antes de desenvolve-las e disponibiliza-las para o cliente?[/quote]

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

Se eu dizer nao para todas nao vai sobrar nada.

]['s]]> http://www.guj.com.br/posts/preList/39019/208472.java http://www.guj.com.br/posts/preList/39019/208472.java GMT ]]> http://www.guj.com.br/posts/preList/39019/208515.java http://www.guj.com.br/posts/preList/39019/208515.java GMT
[quote=fabgp2001] Se eu dizer nao para todas nao vai sobrar nada.[/quote]

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

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

[b]Nunca fazer TUDO o que o cliente pediu ou sonhou[/b]

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]]> http://www.guj.com.br/posts/preList/39019/208520.java http://www.guj.com.br/posts/preList/39019/208520.java GMT
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.

]]> http://www.guj.com.br/posts/preList/39019/208539.java http://www.guj.com.br/posts/preList/39019/208539.java GMT
[b]Nunca fazer TUDO o que o cliente pediu ou sonhou[/b][/quote]

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.

]]> http://www.guj.com.br/posts/preList/39019/208562.java http://www.guj.com.br/posts/preList/39019/208562.java GMT 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. ]]> http://www.guj.com.br/posts/preList/39019/208606.java http://www.guj.com.br/posts/preList/39019/208606.java GMT
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 [url=http://en.wikipedia.org/wiki/Expertise]"expertise"[/url].

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]]> http://www.guj.com.br/posts/preList/39019/208625.java http://www.guj.com.br/posts/preList/39019/208625.java GMT 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...". [/quote]

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! ]]> http://www.guj.com.br/posts/preList/39019/208637.java http://www.guj.com.br/posts/preList/39019/208637.java GMT
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, [b]ninguém[/b] usou.]]> http://www.guj.com.br/posts/preList/39019/208642.java http://www.guj.com.br/posts/preList/39019/208642.java GMT ]]> http://www.guj.com.br/posts/preList/39019/208685.java http://www.guj.com.br/posts/preList/39019/208685.java GMT ]]> http://www.guj.com.br/posts/preList/39019/208755.java http://www.guj.com.br/posts/preList/39019/208755.java GMT Minha hora é X, as tarefas que você esta solicitando são essas que levam Z de tempo, caso ele venha a pedir mais alguma coisas, blz! mais vai passar mais Y de tempo.

]]> http://www.guj.com.br/posts/preList/39019/213630.java http://www.guj.com.br/posts/preList/39019/213630.java GMT