Code for the users, not for the spec

Eu não sei exatamente quando foi que comecei a me ressentir com pessoas para quem eu estava escrevendo código, mas foi um sinal claro de que eu estava me sentindo esgotado. Durante dez anos, trabalhei como um desenvolvedor em agências de design e marketing, em seguida, no Yahoo!, e, finalmente, dentro da minha própria empresa de serviços ao cliente. Em algum ponto ao longo do caminho, eu tinha perdido contato com as pessoas que utilizam o software que eu estava criando. E isso foi um saco!

Uma das grandes alegrias de criar software é resolver problemas. Não apenas resolver problemas academicamente, mas realmente consertar as coisas para as pessoas. Tornar a vida de outras pessoas melhores, permitindo-lhes realizar mais com menos. A satisfação obtida por ter outro ser humano satisfeito usando o que você criou é o que faz tudo valer a pena. Se esse ciclo de feedback é quebrado, você acaba liberando código para o vazio como uma máquina produzindo funcionalidade para a especificação.

Uma coisa que você encontra rapidamente quando você reduz seu papel para simplesmente uma das codificações para a especificação é que a sua posição padrão para qualquer pedido é “não”. Para manter o projeto no prazo, no orçamento, e para evitar que a equipe boie, você tem que se manter firme contra o que poderia ser visto como mudanças desnecessárias e pedidos estúpidos de usuários que realmente não sabem o que estão falando. É cansativo dizer “não”, e acaba acumulando rapidamente ressentimento para com aqueles que fazem as perguntas.

Antes que você perceba, o trabalho não é divertido como ele costumava ser.

A solução é fácil. Pare de codar para especificação, e comece a programar novamente para os usuários.

Funcionalidade não é o bastante

Acho que todos nós, provavelmente, estivemos em uma situação na qual os usuários pedem algo que já existe. Com o nosso pequeno CMS, Perch, os usuários muitas vezes pediram a capacidade de reordenar itens de conteúdo.

É claro, já era perfeitamente possível reordenar os itens – havia opções para definir o conteúdo para ordenar em qualquer campo, e em qualquer direção. Se o usuário precisava de uma ordem arbitrária, eles poderiam adicionar um novo campo, adicionar um número aos seus itens, e ordenar com isso. No papel, era um sistema bastante poderoso e flexível.

No entanto, os usuários ainda estavam pedindo uma maneira de ordenar o conteúdo. A funcionalidade estava lá, mas os usuários não estavam encontrando, entendendo, ou ambos. A especificação foi atingida, mas a funcionalidade estava fracassando com os usuários.

Lembre-se, a especificação é um requisito mínimo. Para realmente fazer um bom trabalho, às vezes é necessário ir além do que a especificação diz e fazer algo que realmente funciona para as pessoas que têm de usá-la.

Aceite quando os usuários estão tendo problemas

Uma grande parte disso é aprender a aceitar quando o código em que está trabalhando está quebrado. Às vezes os problemas internos são os mais difíceis de resolver e, como com todos eles, o primeiro passo para resolvê-los é admitir que você tem um problema. Como um desenvolvedor, é uma lição muito difícil aprender que, uma característica que funciona perfeitamente, livre de erros, está quebrada se os usuários não a entendem.

O que você desenvolveu pode atender aos requisitos da especificação o suficiente para obter o aval, mas não estamos trabalhando para a especificação mais. Como é que vamos começar utilizar e aval?

Às vezes, o problema pode ser resolvido com uma melhor mensagem de usuário, ou por repensar a interface, mas outras vezes você só tem que aceitar que os usuários estão tendo problemas, e que você precisa voltar à prancheta – e que isso é ok. Se o que está aí não funciona para os usuários, então não funciona.

Minha primeira recomendação nessa situação é simplesmente ouvir seus usuários. Pergunte a eles o que estão tentando conseguir. Muito parecido com a debatida citação “cavalos mais rápidos” de Henry Ford, seus usuários podem aparecer com as soluções erradas, mas o seu requisito fundamental pode muitas vezes ser destilado a partir dessas soluções. Então, pergunte a eles, e depois ouça atentamente a resposta.

Os verdadeiros grandes desenvolvedores resolvem problemas

Voltei para a prancheta com a minha ordenação de conteúdo e implementei uma interface JavaScript de reordenação usando drag e drop. O core que meus usuários estavam pedindo era uma forma rápida de definir uma ordem arbitrária de conteúdo. Eu não sou de lançar enormes quantidade de JavaScript em todos os problemas, mas, nesse caso, parecia que drag and drop era uma boa maneira de atingir esse objetivo.

Agora os usuários podem pegar um pouco de conteúdo e largá-lo facilmente onde quiserem. O resultado final é diferente da funcionalidade que fornecemos antes? Não, mas o processo de chegar lá é mais alinhado com a maneira como os usuários querem utilizar o software.

Isso não só significa que eles não estão me incomodando com pedidos de recursos que existem, mas também que são capazes de conseguir mais com o software.

FAQs são erros que você não corrigiu ainda

Temos uma política de não ter FAQs. Se os usuários estão perguntando sobre algo com regularidade, então isso significa que não estamos explicando as coisas claramente, ou que o produto pode ser melhorado.

Com o Perch, os usuários precisam adicionar o domínio do seu site e a chave de licença correspondente antes de poderem logar em uma nova instalação. Se eles perderam todas as instruções e não conseguiram fazer isso, então foram presenteados com a seguinte mensagem:

“Desculpe, sua chave de licença não é válida para este domínio.”

Apesar de precisa, essa mensagem muito raramente resultou em o usuário tomar o rumo correto de ação para resolver o problema. O que elas realmente fazem é pedir ajuda dizendo que eles não conseguiram logar.

Uma maneira de resolver isso seria adicionar FAQ ao nosso site que explica o que fazer quando se deparar com a mensagem. Isso seria um curativo na ferida – seria estancar a hemorragia, mas não aliviar a dor. A solução real era muito mais simples. Nós modificamos a mensagem de erro:

“Desculpe, sua chave de licença não é válida para este domínio. Log em sua conta Perch e adicione o seguinte como o seu domínio de produção ou de teste: example.com”

Com example.com sendo o domínio onde a instalação está sendo executada. Após essa alteração simples, ninguém nos faz essa pergunta mais. Tenho certeza de que muita gente ainda sente falta das instruções de instalação e vê o erro, mas não é mais um problema para eles – eles só precisam fazer a alteração e continuam sem incidente.

A pior coisa que você pode fazer com FAQs é uma lista delas em seu site. FAQs são bugs, e a única resposta satisfatória para eles é corrigir o problema; assim, as perguntas não serão feitas novamente.

Ser um desenvolvedor não é fornecer ferramentas, é resolver problemas. Se queremos curtir o que fazemos, fazer coisas impressionantes, e não nos sentirmos esgotados, então precisamos encontrar maneiras de resolver problemas que funcionam muito bem para os usuários. Se você fizer um grande software, os usuários apreciarão seu trabalho e você vai se sentir orgulhoso com o que você conseguiu. Pra mim, isso soa como uma boa receita para ser feliz no seu trabalho.

***

Texto original disponível em http://phpadvent.org/2011/code-for-the-users-not-for-the-spec-by-drew-mclellan