Carlos Brando

Nome do Jogo

Personalizar ou não personalizar?

1219450501_628b20dc79.jpg

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).

Comments