terça-feira, 5 de novembro de 2013

Software de Qualidade mais que Software Funcionando

Em 2011, quando Fortaleza sediou o Agile Brazil, os participantes do evento tiveram a oportunidade de assistir a um Keynote entitulado: "Liderança adaptável: acelerando a agilidade organizacional".  Durante os dias do evento, pude conhecer um pouco mais sobre Jim Highsmith, o preletor desta palestra e um dos autores do Manifesto Ágil. Em uma das conversas com ele, uma frase ficou gravada na minha mente: "Qualidade é Pessoal."

Na verdade, eu já havia escutado esta frase várias vezes, mas nunca da boca de Jim Highsmith.  Ele falara de forma tão precisa e profunda, que acreditei haver algum material de sua autoria na internet falando do assunto.  Encontrei um artigo dele chamado When Quality is Personal.  Também encontrei um outro artigo entitulado Quality is Personal, escrito por Israel Gat. Indico a leitura dos dois.

Comecei a ver o conceito Qualidade de forma diferente. Anteriormente, software funcionando mais que documentação abrangente, já me dizia tudo. O tempo e a experiência me fizeram perceber que não há como definir qualidade de software, tendo em mãos, "apenas" um Software Funcionando.   Segundo o dicionário,  "Qualidade é um atributo, condição natural, propriedade pela qual algo ou alguém se individualiza, distinguindo-se dos demais; maneira de ser, essência, natureza..." 

Entretanto, no desenvolvimento de software, conseguimos encontrar um outro conceito para a palavra qualidade: 

"Experiência agradável (ou desagradável) pela qual passa um usuário ao utilizar um programa de computador"

Atualmente, há uma tendência em valorizar empresas que investem grandes volumes de recursos financeiros em qualidade de processos, desenvolvimento de pessoas e melhoria no ambiente de trabalho. Mas "apenas isso" não é suficiente para criar um produto de qualidade.  

Por exemplo:
O Brasil é, hoje, um dos maiores produtores e consumidores de café do planeta. Em uma recente pesquisa feita pela ABIC (Associação Brasileira da Indústria de Café), foi constatado que um brasileiro chega a consumir 83 litros de café por ano. É muito café! Acredito que eu tenha uma parcela de contribuição nesta estatística.

O resultado dessa pesquisa não é surpresa. Durante anos, os produtores de café fizeram grandes investimentos na lavoura, na industrialização do café e na logística de entrega. Grandes quantias em dinheiro são gastas, anualmente, para alcançar elevados níveis de qualidade nos processos de fabricação.

Mas o que isso nos interessa?  Simples.  Eu gosto de café, mas detesto café forte. Não adianta o melhor processo de produção, guiado pelos mais conceituados profissionais do planeja... se eles me entregarem uma xícara de café forte... vou fazer careta! 

"A boa qualidade de um produto não depende do processo de fabricação ou da competência técnica dos profissionais envolvidos, mas da experiência agradável vivenciada pelo consumidor. "

Equipes de desenvolvimento de software que realmente buscam a qualidade, estão preocupadas com a Experiência do Usuário com o produto. O processo de "industrialização" do software é secundário.

Essa é a razão pela qual muitos dos nossos colegas falam em User eXperience (UX). Um trecho de uma entrevista feita a Steve Jobs, em um artigo de 2003 entitulado "The Guts of a New Machine" ("As entranhas de uma nova máquina") publicado no The New York Times por Rob Walker, já resumia o que hoje chamamos de UX :

...
 ''Most people make the mistake of thinking design is what it looks like,'' says Steve Jobs, Apple's C.E.O. ''People think it's this veneer -- that the designers are handed this box and told, 'Make it look good!' That's not what we think design is. It's not just what it looks like and feels like. Design is how it works.''
...


O foco deste post não é falar sobre UX.  Irei escrever um outro artigo sobre isso futuramente.  No entanto, para quem interessar, sugiro o material WHAT IS UX DESIGN? por Ross Popoff-Walker.

Finalizo este post com a simples conclusão de que não adianta falar de qualidade sem proporcionar aos usuários/clientes a experiência de usar nosso software. 




sexta-feira, 1 de novembro de 2013

Como dizer ao cliente que ele é importante?

Nos últimos anos, tive a oportunidade de lidar com diferentes clientes e empresas.  Algumas das pessoas com as quais conversei, absorveram a importância delas (clientes) em participar dos projetos. Não somente validando resultados, mas direcionando o desenvolvimento.  Entretanto, grande parte dos clientes não se interessa pela execução do projeto. Uma das razões pra isso é que nós, pessoas que constroem o software, não sabemos como dizer a eles, pessoas que usam o software, a importância da sua participação. Este post não tem a pretensão de ensinar como fazer isso, mas tentar mostrar como uma analogia pode mudar todo o entendimento. Então, como deixar claro que a participação dos nossos clientes/usuários é decisiva? 

Leia a analogia abaixo:



Imagine uma Ferrari Enzo.  Agora, se conseguir, imagine um fusca. Ambos são carros e têm um objetivo em comum: transportar pessoas (sem piadas com o fusquinha, por favor).  No entanto, existe uma "pequena" diferença na potência desses carros. Uma Enzo pode chegar a 800 cavalos enquanto um fusca chega a 200.  E daí?  Calma! 

Pergunta: Qual dos dois carros o leitor gostaria de ganhar de presente?  A maioria esmagadora das respostas seria óbvia, a Ferrari.  Mesmo os apaixonados por Fusca ainda escolheriam a Ferrari.  A venda dela daria para comprar vários Fuscas. 
Mas a questão não é essa. 

Vamos dar vida a essa história. 
Suponha que você ganha na loteria.  Algumas dezenas de milhões de reais.  Mas o prêmio será entregue em outra cidade à 2000km de distância.  Você tem duas opções de transporte: a Ferrari Enzo ou o Fusca (vamos levar em consideração que você não está no Brasil, uma vez que não temos rodovias decentes pra suportar uma Ferrari). Cada um dos carros com um motorista.  Qual dos dois veículos você escolheria?  Parece fácil, mas tem um detalhe... um dos motoristas não sabe o caminho, além de ser um bêbado estressado (isto é só um exemplo. Se beber, não dirija!), enquanto o outro é um GPS humano e nunca colocou uma gota de álcool na boca.  Qual dos carros seria escolhido?

A resposta é: Depende em qual dos carros está o motorista bêbado e estressado. Nesse caso, a decisão não depende do carro, mas da pessoa que irá guia-lo. É bem mais seguro gastar uma semana para percorrer 2000km em um Fusca, com um motorista sóbrio, do que entrar em uma Ferrari com a certeza absoluta de que o bêbado estressado vai levar você, e talvez ele (o "motorista" quase sempre escapa), para o túmulo.



No mundo corporativo, é fácil encontrar equipes tão potentes quanto uma Ferrari sendo guiadas por pessoas estressadas que não sabem aonde ir. Já vi times de desenvolvimento de software de alto nível fazerem entregas pífias, bem como Sprint Reviews de times inexperientes que resultaram em pedaços de software verdadeiramente úteis.

É importante, pra não dizer essencial, que o cliente entenda que ele não é "somente" um Product Owner (dono do produto) no sentido literal da palavra.  Ele é a parte mais importante deste conjunto multi-disciplinar de elementos que envolve um projeto de software. Ele é "O Guia" do projeto.