Nome do Jogo

Tradução do artigo de Ryan Carson do blog Carsonified:

Ao construir software para a internet, uma das decisões mais importantes que você deverá tomar é sobre quem vai realizar o design do seu aplicativo. Seu software está fadado ao fracasso se o design e a usabilidade forem ruim.

Para nosso novo projeto nós escolhemos Jason Santa Maria e não poderíamos estar mais felizes. Pensei que seria útil compartilhar como tomamos esta decisão.

Estes são os passos que tomamos: 

1. Criamos uma lista com três designers que consideramos talentosos.

2. Enviamos um email perguntado se eles estavam disponíveis e se tinham interesse em trabalhar conosco.

3. Os três responderam que gostariam de trabalhar com a gente e que tinham tempo em suas agendas (isto que é sorte).

4. Respondemos o três emails com uma pequena prévia do projeto e pedimos uma cotação. Pedimos para que enviassem um valor considerando um mês de trabalho (baseado em nossa experiência com nosso primeiro projeto).

5. Recebemos de volta cotações entre $5,000 e $14,000.

Tomando a decisão difícil

Então, nós tínhamos três orçamentos de três designers talentosos e capazes. Como escolher com qual vamos trabalhar?

Em primeiro lugar, vamos deixar claro o que não vamos levar em conta. Não fizemos nossa escolha baseada em preço (Jason estava com um valor intermediário). Não levamos em conta a localização (Jason mora do outro lado do oceano Atlântico). Então, em que se baseou nossa decisão? Nós escolhemos Jason por quatro motivos:

1. Entusiasmo: Ele deixou muito claro para nós que iria trabalhar arduamente no projeto.

2. Experiência: Ele tem uma boa compreensão de usabilidade e simplicidade.

3. Flexibilidade: Ele tem um estilo bem amplo (veja a diferença entre o seu site pessoal e um outro site desenhado por ele).

4. Velocidade: Ele já entende bem de padrões web e acessibilidade.

5. Confiança: Ele é bem amigável e parece ser fácil trabalhar com ele. Nós também sentimos que podíamos confiar nele.

O fator decisivo

O fato de sentirmos que podíamos confiar em Jason foi o fator decisivo. Ele fez o esforço de gastar um tempo conosco, e assim conseguimos conhecê-lo. Ele nos falou que estava muito interessado em trabalhar no projeto e que daria tudo de si nele. Devido a isso, sabíamos que não seria arriscado escolhe-lo como nosso designer. Sabíamos o que esperar dele.

Então, qual é a lição para os designers? Conheça seus potenciais clientes pessoalmente e tome conhecimento de qual será o fator decisivo para que você consiga o trabalho. Fazer estas conexões é fundamental, e se você fizer isso, nunca ficará sem trabalho.

Hoje em dia tem muita gente usando a palavra customizar, mas eu não gosto muito deste neologismo em especial, então vou usar personalizar mesmo.

Durante muito tempo me ensinaram que um software realmente poderoso deve ser totalmente personalizável. Pois assim, caso o cliente desejasse ajustar alguma coisa ele simplesmente deveria ir até a tela de configurações e mudar alguns parâmetros. Isto era ainda mais importante caso o software fosse vendido para mais de um cliente, porque cada um poderia deixar o software do seu jeito. Ao gosto do cliente.

O engraçado é que isto nunca funcionava, você tinha um trabalhão para criar uma tela de configurações que o cliente acabava usando apenas uma vez, isto quando usava. E na maioria dos casos, quando o cliente resolvia mudar alguma coisa, era justamente aquela opção que você não deixou personalizável.

Mais de uma vez vi colegas criando soluções mirabolantes para deixar o software mais flexível. Tabelas de domínio, configuração ninjas em arquivos XML e mais um monte de soluções fantásticas que ninguém usava.

Mas veja o que o Getting Real fala sobre isto:

Evite Preferências

Decida sobre os pequenos detalhes para que seus clientes não precisem

Nos deparamos com uma decisão difícil: quantas mensagens incluímos em cada página? A primeira inclinação pode ser em dizer, "Vamos apenas tornar isso uma preferência onde as pessoas possam escolher 25, 50 ou 100". Entretanto, essa é a forma mais simples. Apenas tome a decisão.

Preferências são uma maneira de evitar tomar decisões difíceis

Em vez de usar nossa experiência para escolher o melhor caminho, deixamos nas mãos dos clientes. Pode parecer que estamos fazendo um favor a eles mas apenas estamos lhes dando mais trabalho (e provavelmente eles já são ocupados o suficiente). Para os clientes, telas de preferência com uma quantidade infinita de opções são uma dor de cabeça, não uma bênção. Clientes não deveriam ter que pensar sobre cada ínfimo detalhezinho - não coloque esse peso sobre eles quando deveria ser sua responsabilidade.

Preferências também são más porque criam mais software. Mais opções requerem mais código. E também ainda tem todo o teste extra e design que precisamos fazer. E ainda vamos acabar com permutações de preferências e telas que nunca usaremos. Isso significa bugs que não sabemos a respeito: layouts quebrados, tabelas explodindo, problemas estranhos de paginação, etc.

Tome a decisão

Tome as decisões simples no lugar dos clientes. É o que fizemos no Basecamp. O número de mensagens por página é 25. Na página de resumo, as últimas 25 são mostradas. Mensagens são ordenadas em ordem cronológica reversa. Os cinco projetos mais recentes são mostrados no painel. Não existem opções. É o jeito que tem que ser.

Sim, podemos tomar uma decisão ruim. Mas e daí? Se fizermos isso, as pessoas vão reclamar e nos dizer sobre isso. Como sempre, podemos ajustar. Cair na Real é justamente sobre ser capaz de mudar em tempo real.

Ao contrário do que se pensa, esta abordagem não está tirando a flexibilidade de seus clientes, mas ao invés disto você está tomando decisões para que eles não precisem se preocupar em configurar ou ajustar algo para usar o seu software. Eles podem usar o seu produto tranqüilamente sabendo que você já se preocupou com a melhor forma de usar, ver ou fazer as coisas.

É claro que não somos fanáticos religiosos e sabemos que nem sempre poderemos criar um produto totalmente livre de parametrização, mas devemos tentar evitá-las ao máximo. Muitas das vezes acabamos criando telas de configuração por pura preguiça de pensar em qual seria a melhor opção para o cliente.

É claro que adotar esta postura pode deixar um ou outro descontente, mas este é um preço muito baixo a se pagar, pois você sabe que a maioria das pessoas poderão fazer o que realmente interessa sem se preocuparem com parametrizações e configurações.

Outro ponto citado no Getting Real que me chama à atenção é o fato de que criar telas de configuração e personalização também significa criar mais software, e nós queremos “menos software“. E não se engane achando que é apenas mais uma telinha boboca, porque para cada tela nova de parametrização que você cria você leva de brinde todo o código de teste e design da página.

E ainda existe um ponto de risco nas parametrizações. Dependendo do tipo, elas tornam algumas funcionalidades do seu sistema complexas demais, o que vai dificultar os seus testes. Será que você se lembrou de testar aquela funcionalidade com as opções 1 e 2 habilitadas e com a opção 3 desligada?

Toda a parametrização que você cria tem um custo. É claro que algumas são cruciais para o sucesso do projeto, mas algumas pessoas não entendem isso e acham que quanto mais opções forem dadas ao cliente, mais satisfeito ele ficará. Nosso foco deve ser criar software que funciona e não adicionar funcionalidades que apenas engordam nosso produto e o submetem a mais falhas.

Clique aqui para conhecer o Getting Real (em português).

David acabou de avisar sobre o lançamento do segundo Release Candidate do Rails 2.0. Mas a melhor noticia mesmo é que DHH confirmou que a versão oficial pode sair em uma ou duas semanas dependendo do feedback recebido.

Para não chover no molhado, veja o post do Akita que falou primeiro do assunto.

Para variar o Leopard ainda não chegou, e como na semana que vem estarei fora de São Paulo, liguei mais uma vez (desta vez via Skype) para saber se ainda vou receber esta semana. Falei com a Camila Carina da Cargraphics (e fui bem atendido) e ela me garantiu que eles estão enviando hoje todos as 180 cópias recebidas, e que a minha está no meio.

Como vou viajar no sábado, preciso receber até no máximo sexta-feira, então a Camila pegou meu email e prometeu me enviar o código de rastreamento do sedex ainda hoje.

Será que esta semana esta novela acaba? O pior é que se não chegar até sexta-feira, só daqui 10 dias, isto se o correio não resolver devolver o pacote.

Sou fã do blog Signal vs. Noise de uma longa data. E já faz um tempo que eles estão fazendo uma série de posts chamada “Ask 37signals”, onde Jason Fried e outros respondem à perguntas enviadas pelos leitores. Estes são sem sombra de dúvidas os melhores post (na minha opinião) do blog. Eu vou tentar então sempre que sair um destes, traduzir e colocar alguns comentários meus.

A pergunta foi:

… Imagino que não há muito deste negócio de hierarquia na 37signals. Mas, e quando vocês chegam a um impasse, e uma decisão deve ser tomada, quem é que manda? Refiro-me mais a decisões de design e não à decisões comerciais.

Uma coisa que chama à atenção é que a 37signals tem apenas 10 funcionários, sendo que Jeffrey Hardy entrou ontem para o time. Mas isto não a torna uma pequena empresa, pelo contrário, é uma grande empresa com poucos funcionários. E o mote “menos é mais” é o que torna a 37signals tão interessante.

Vamos a resposta de Jason Fried:

Raramente, para não dizer nunca, nos envolvemos em impasses quanto a decisões de design. Um impasse só acontece quando alguém tem de pedir autorização para fazer alguma coisa e o outro lado diz não. Uma discussão só acontece quando nenhum dos lados está disposto a ceder.

Caindo na Real acaba com os impasses

Nós não nos envolvemos neste tipo de discussão. Se alguém sente que deve mudar algo, ele simplesmente 1. muda, ou 2. cria um protótipo para ver como fica. Assim que temos algo real, então podemos tomar uma decisão melhor, já que possuímos mais informações sobre o assunto. Neste ponto é muito difícil termos um impasse. Impasses são mais freqüentes quando se tem um produto abstrato ou ilusões equivocadas. A metodologia Caindo na Real acaba com os impasses antes mesmo de eles acontecerem.

Assumindo a responsabilidade para resolver conflitos

No entanto, quando temos dois pontos de vista diferentes ao tomar uma decisão de design, nós normalmente acabamos com a tensão nomeando a pessoa com a idéia revolucionária como responsável por qualquer questão relacionada com a sua decisão.

Por exemplo, se Ryan quer fazer algo de uma maneira, e eu quero que seja de outra forma, eu digo: "Ok, Ryan, vamos com a sua solução, mas você é o responsável por todo o suporte por email, confusão, ou questões que estiverem diretamente relacionados com a sua implementação." Ryan pode aceitar essa responsabilidade e ir em frente, ou ele pode dizer: "Isto não vale a pena agora, vamos adotar a sua sugestão." Ou talvez, entramos em um acordo de não fazer nada naquele momento. Esta também é uma decisão razoável.

Decisões são temporárias

Quando se tem em mente que decisões são temporárias, nós estamos abertos a rever, reparar ou mudar uma decisão se isto for melhor para o projeto. Ninguém na 37signals perde tempo em uma decisão ruim. Se é uma má decisão, nós fazemos o máximo para melhorá-la. Em vez de jogar dinheiro fora, nos livramos do lixo e tentamos algo diferente. Normalmente, percebemos se algo não vai dar certo bem rápido. Nós não podemos fingir que está tudo bem o tempo todo.

Portanto, se você estiver em um impasse, escolha uma equipe para tocar a implementação, dar suporte e pegar o feedback do cliente. Eles sentirão se vale a pena avançar. Ou podem ter uma segunda opinião. De qualquer forma, esta é a melhor maneira acabar com um impasse.

Infelizmente se você trabalha e uma “grande” empresa, dificilmente você conseguirá este tipo de poder de decisão, já que as pessoas estão muito mais preocupadas com sua superioridade (quem toma as decisões é o chefe e ponto) do que com o projeto ou com a empresa. Mas em empresas menores isto é possível, pois a árvore hierárquica é muito menor, quando existe.

A Surgeworks tem um gostinho de 37signals. Não me lembro de nenhum impasse. Toda vez que apareci com alguma sugestão fui ouvido e algumas vezes seguimos em frente com ela, em outros casos escolhemos seguir outro caminho, mas nunca ficamos parados muito tempo discutindo algo.

E aí, como vocês resolvem os impasses na sua empresa?