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. 

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. 

Agilidade vai falhar na minha empresa porque...

Em agosto deste ano, tive a oportunidade de participar do Agile 2013, um grande evento de agilidade organizado pela Agile Alliance nos EUA.

Como não poderia ser diferente em um evento como esse, conheci pessoas.  Dentre elas: Jeff Patton, Linda Rising, Jeff Sutherland, Ron Jeffries, Mike Cohn e muitos outros.  Quem estuda um pouco de agilidade, já deve ter lido algum livro ou ouvido falar algum desses nomes.  Participei de apresentações que mais pareciam verdadeiros TED Talks.  Muitos Workshops mão-na-massa e espaços para troca de ideias. Um evento diferenciado. E o hotel era um show à parte.

No entanto, o que mais chamou minha atenção no evento não foram as pessoas, apresentações ou o hotel (que repito... era espetacular), mas um painel onde os participantes escreveram frases que diziam porque agilidade iria falhar em suas empresas.

AGILE WILL #FAIL AT MY COMPANY BECAUSE... 

"Because the CEO manages with fear and Intimidation"

"Only focused on changes on development teams; Not looking at whole value Stream... "

"Because of our culture"

"No buy-in from the business"

"Because the company wears 'Agile' as a label and does nothing to remove the bureaucracy and obstacles teams face daily while trying to implement agile."

"We are different"

"Our egos are bigger and more important then the company goals"

"Insufficient support from leadership"

"Different parts of the biz use different types of agile"

"My leadership no longer believes in it..."

"It's counterintuitive and hard to practice"

"We have not explained the 'why'"

Cada uma destas frases já daria um post, mas aqui está meu ponto: Agilidade é um sentimento universal e nós não estamos sozinhos.  

O fato é que... falar, escrever e ensinar agilidade não é difícil.  Vou além, é muito fácil falar de agilidade.  Até porque (eu, por exemplo), quando discurso sobre o assunto, vejo olhos brilhando e ouvidos atentos. Agilidade é o discurso que todos gostam de ouvir, mesmo os "chefes".  O problema é que transformar todo esse BLÁ BLÁ BLÁ em prática AINDA É UM GRANDE DESAFIO, mesmo para os nossos colegas norte-americanos, onde a cultura é... digamos... mais avançada.

Quando vejo um ianque escrevendo que agilidade vai falhar na empresa dele por conta da burocracia, meu primeiro pensamento é mudar de área e ir pra medicina (se bem que a concorrência com os cubanos e a falta de estrutura pra trabalhar me fariam pesar essa decisão).

Por fim, cada vez que toco no assunto Agilidade/Cultura, tenho a seguinte certeza: 

"Ou a cultura acabará com a agilidade... ou a agilidade mudará a cultura do mundo."

Como ter uma ideia

O programa Globo Ciência do dia 12 de outubro de 2013 teve, como uma de suas matérias, o tratamento de esgoto.  Neste dia, várias ideias para tratamento foram apresentadas. Todas elas tinham um processo bem desenhado e passos bem definidos para transformar esgoto em água potável.  

Entretanto, um destes processos chamou minha atenção. A ideia do criador foi construir um dispositivo com 4 orifícios. O primeiro orifício tinha a função de receber a água do esgoto, que saía filtrada e limpa pelo segundo orifício.  Até aí, nenhuma surpresa. O que chamou minha atenção foi a função do terceiro e quarto orifícios (figura abaixo).

  

De acordo com o pesquisador, nem toda água que entrava no orifício 1 conseguia ser filtrada.  A função do orifício 3 era fazer com que a água não filtrada fizesse outro ciclo de tratamento. Em outras palavras, ela saía pelo orifício 3 e entrava no orifício 4. 

Fazendo uma análise bem crítica, nada há de extraordinário nesta ideia. Mas, pra mim, sim!  Enquanto assistia a reportagem, comecei a pensar no processo Kanban de desenvolvimento e imaginei um "dispositivo" que pudesse ser utilizado em um processo ágil para reciclagem de requisitos. A ideia seria assumir que nem todo requisito que é empurrado para nosso processo esteja "pronto para consumo". Em outras palavras, que tal ter um processo de tratamento de requisitos?  Coisa de maluco...  

Mas meu raciocínio não parou por aí. O Insight que me levou a escrever este blog teve seu ápice quando comecei a pensar sobre como eu cheguei à conclusão da criação de um dispositivo para transformar requisitos "podres" em "potáveis".  Como uma ideia leva à outra? Na verdade, a mágica (se é que existe) está na quantidade e qualidade de conhecimentos gerais adquiridos por nós, seres humanos. De fato, ter uma ideia não é algo tão difícil. Todo ser humano as têm.  O mais difícil, entretanto, é realiza-las. A realização fica mais fácil quando lemos ou conhecemos diversos assuntos.

Neste mesmo programa, um pesquisador (que era músico e matemático) apresentou um programa de computador que amplia a expressão de quem está tocando um instrumento musical.  A ideia básica do seu software era apresentar imagens ou videos no computador que representassem o som tocado pelo instrumento usado. Coisas desse tipo nos trazem à mente o seguinte pensamento: "Por que não pensei nisto antes?  É tão simples!"

Não pensei porque as ideias mais simples do mundo são resultado da combinação de vários conhecimentos. Ter uma ideia depende do quanto você ler e conhece de assuntos gerais. Qualquer pessoa pode ter ideias, mas uma pessoa que conhece música e matemática tem maior probabilidade.  Uma pessoa que conhece Kanban e aprende um pouco sobre tratamento de esgoto em uma reportagem de televisão, também. 

Em suma, se você nunca teve uma ideia simples que pudesse ser executada, ENTÃO LEIA. Estude assuntos que você nunca pensou em estudar e faça atividades que você nunca imaginou fazer! 

Depois da prática, a teoria

A última vez que publiquei um post neste blog foi em Abril de 2010.  Na época, estava falando sobre estimativas ágeis.  Passaram-se 3 anos e a experiência adquirida neste período foi consideravelmente esclarecedora.  Percebi que gastar tempo em criar estimativas perfeitas é tão útil quanto mascar chiclete; Por mais que você mastigue, jamais vai ter coragem de engolir.

Entretanto, minhas experiências foram além de apenas buscar boas estimativas.  Durante muitos meses, tive a oportunidade conhecer diversos clientes, das mais diferentes empresas.  E, apesar de querer valorizar muito os desenvolvedores e os famigerados Scrum Masters,  tive que reconhecer que os clientes são as peças mais importantes dessa engrenagem chamada projeto de software.

Como se não bastasse, também comecei a abrir os olhos para o que chamamos de requisitos de software.  E, mais uma vez, aprendi que tudo é perfeito nos livros, nas palestras, nos eventos... Mas no campo de batalha, no espaço de desenvolvimento, na sala do cliente... os fatos são bem mais complexos e nebulosos do que nossos colegas agilistas pregam.

Enfim, descobri que a agilidade teórica é tão distante da agilidade prática quanto o caos é da verdadeira auto-organização e auto-gerenciamento.  Por isso, dedico esse blog, a partir de hoje, a falar de como realmente a agilidade acontece na prática e o que aprendi com ela nos últimos anos.  E como ela realmente tem a ver com a felicidade e satisfação no trabalho e a melhoria contínua; Não de processos, mas da qualidade de vida.  E por falar em qualidade de vida, dedico este blog a alguém que, de forma extremamente ágil, melhorou consideravelmente minha qualidade de vida. Um grande beijo, minha Princesa Linda.

Que venham as postagens.  Muita coisa boa vem por aí.