Não tem que ser difícil
9 de agosto de 2009Ao dar os primeiros passos na plataforma .NET Framework eu percebi de imediato a diferença e o grande potencial que eu tinha em minhas mãos com esse novo modelo de desenvolvimento. Com o .NET muitos paradigmas existentes precisaram ser quebrados para se incorporar em uma nova realizadade que estava surgindo.
Eu tive uma relação muito positiva logo no primeiro contato e rapidamente já estava dando aulas de .NET nas empresas. Durante um desses treinamentos que surgiu a frase “Não tem que ser difícil” e a proposta foi justamente representar com poucas palavras a quebra de todos os conceitos que pregavam no passado.
Eu tinha amigos que se achavam os caras, pois gastavam um enorme tempo fazendo as coisas das formas mais difíceis sem a minima preocupação com a entrega do projeto. Era mais importante complicar e dizer que tinha gastado muito mais tempo em uma determinada implementação.
O Visual Basic que era uma das plataformas mais utilizadas no mundo (se ainda não é). Não prestava, pois era mais cool dizer que programava em C++ ou quem sabe até em assembly pela dificuldade.
E a cada dia vejo que o grande diferencial das empresas que atuam na era da Web 2.0 é a simplicidade. Você pode olhar exemplos rápidos como o Google; Twitter e Apple que entregam seus conteúdos de forma simples e integrada e devem ser analisados, pois de forma simples conquistaram seu grande espaço.
Ontem encontrei uma ilustração do Eric Burke que representa muito bem a força da simplicidade.
Eu costumo repetir além da frase “Não tem que ser difícil” para os amigos que o mais difícil é justamente fazer de forma simples. A proposta é você propagar em seus projetos e nos negócios que para ser cool não precisa fazer da forma mais complicada e sim resolver as necessidades atendendo a satisfação do consumidor.
Quando eu conheci o “Kano model” alguns anos eu iniciei outro processo de quebra de paradigma. Que era identificar o nivel de percepção de qualidade por parte do usuário. Segundo o professor Kano a qualidade de um produto tem ser medida baseada no nível de percepção de qualidade por parte do cliente. Esse modelo deu origem ao famoso processo conhecido como “Kano Analysis”.
A proposta é identificar os fatores que realmente vão fazer com que o seu usuário considere o seu produto um sucesso e trabalhar em cima deles numa escala evolutiva para conquistar a satisfação do usuário/consumidor com o seu produto.
– Fatores Básicos
Mínimo para não ter insatisfação. Os clientes vêem como “pré-requisitos” ou pontos iniciais.
– Fatores de Excitação
Trazem grande satisfação mas não são obrigatórios. É diferencial para os concorrentes.
– Fatores Performance
Presença causa satisfação e sua ausência causa insatisfação.
– Atributos indiferentes
O cliente não se importa com essa característica.
– Atributos questionáveis
Não se tem certeza se o cliente espera essa característica.
Atributos invertidos
O contrário do que foi solicitado pelo cliente.
Imagina agora você construindo um botão dinâmico que movimenta-se em toda a tela e o seu cliente recebendo esse recurso como um “Atributo indiferente”. Todo o seu trabalho não dará resultado.
Para saber mais:
Simplicity
Diagrama de Kano
Continue sua participação nos comentários discutindo o tema “Não tem que ser difícil”.
[],
Ramon Durães
Especialista em desenvolvimento de software
Ramon é autor da frase “Não tem que ser difícil”