Posts Tagged ‘produto’

Por uma web melhor: evite manter estado

7 de setembro de 2010

Todo dia centenas de aplicações são lançadas ou atualizadas na internet e fazem uso do protocolo http, que influencia diretamente o retorno do nossos produtos. Por exemplo, adotar web services via ftphoje em dia não parece tão viável quanto era anos atrás.

Mas mesmo com um protocolo ubíquo como o http, muitas vezes deixamos de lado conhece-lo a fundo e perdemos um grande número de potenciais clientes.

Um caso comum que pode ser melhorado é a utilização indiscriminada de estado de cliente para responder uma requisição.

Nesse cenário, já na primeira requisição o servidor marca o cliente com um cookie de tempo determinado de expiração, por exemplo 15 minutos, e esse cookie é essencial para todas as requisições futuras. Assim que o cookie expira, o usuário é obrigado a voltar para a pagina inicial.

Por exemplo, no site da Tam, inicie uma busca e aguarde sua sessão expirar. Tente executar um refresh: o site o redireciona para a página inicial de escolha de língua, uma página que você não passou anteriormente.

Tam e a escolhe de país

Site com escolha de país. Opção para lembrar, mas será esquecida junto com o cookie.

Ao escolher um país note que devido a utilizar cookies (ou url-rewriting), o sistema não consegue realmente lembrar após o tempo passar, apesar de marcarmos o checkbox.

Além do usuário se assustar com uma tela que não existia antes, ele não retorna para onde estava, mas sim para a página inicial, perdendo o trabalho executado até então.

Se o usuário encontrou uma viagem interessante e tenta compartilhar o mesmo para Se enviar o link para um colega para que veja o preco da passagem, ele nao sera capaz de acessa-lo. Como o http pode nos ajudar? Trabalhando com a busca como um recurso (de REST), URIs amigáveis, verbo GET e sem manter o estado teríamos uma URI que resolveria quase todos os problemas acima mencionados:

http://site.com.br/viagem/cgu/seo/20110101/201101012

Podemos medir o número de clientes potenciais que podemos perder diariamente por mantermos sessão em momentos desnessários colocando um contador na página de perda de sessão.

Analise em seu site quantas pessoas entram nessa página diariamente e tem seu fluxo de pensamento quebrado devido a essa abordagem.

Na abordagem da URI baseada em recursos existe somente um ponto que não foi abordado: como saber o país do cliente? Existe uma solução padrão do http para isso: utilize o header Accept-language.

Seria possível reescrever as URIs com a língua o que apresenta desvantagem somente para o caso de compartilhar a URI com amigos que não entendem a lingua atual.

Timeout

Quando uma sessão se faz necessária e o tempo é curto, mantenha um contador indicando o mesmo para seu usuário, como no site do Banco do Brasil. Perder o fluxo de trabalho atual é sempre uma experiência negativa portanto dê a chance de seu usuário executar um refresh para continuar trabalhando.

Solução do BB: mostrar o tempo até expiração.

Caso o usuário esteja preenchendo um formulário e não queira executar um refresh, mostre um alert do javascript confirmando se o usuário deseja se manter logado, executando uma requisição ajax para prolongar o tempo, como alguns sistemas de submissão de palestra online costumam fazer.

Recentement Subbu Allamaraju comentou sobre a questão de sessão não fazer parte de HTTP e quão vital isso é para a web escalar.

Entender o cookie e o valor da sessão significa algo além do que está na URI: conhecimento fora do padrão HTTP, chamado out-of-band knowledge. Sites que se baseiam nesse tipo de trabalho, implicam em pior SEO, além de dificuldades de acesso no dia a dia por seus usuários. Por uma web melhor, não dependa de estado do seu cliente.

Um produto por semana

30 de março de 2010

Para atender a demanda de um cliente decidimos aplicar uma técnica de criação rápida de um produto. Ele precisava de uma ferramenta de otimização de feeds e widgets, permitindo encontrar novos parceiros – indo um passo a mais de distância que o Urchin ou Analytics.

Duas semanas depois, o Probe estava no ar atendendo as requisições internas e gerando estatísticas importantes sobre parceiros de qualquer empresa. Mas o que permitiu entregar um produto tão rápido?

Fugindo do brainstorm

A idéia do produto já havia sido discutida internamente na Caelum entre diversas pessoas, o que amadurece a mesma, permitindo cortar idéias não triviais que seriam danosas a uma primeira entrega. Esse período não foi um brainstorm onde determinadas pessoas sentam numa mesa e discutem ao máximo determinado assunto, tentando chegar na visão ótima do que seria seu produto. Pelo contrário, isso não seria nada ágil.

Não existe e consequentemente é impossível alcançar algo perfeito, adaptamos o que temos para chegar o mais próximo do idealizado.

Discutir no dia a dia a idéia com diversas mentes que entendem um pouco ou muito do assunto amadurece aos poucos a visão que temos do produto.

A interface

Por mais que alguns projetos com os quais os usuários interagem possam ser tocados sem wireframe, para evitar dúvidas pontuais de CSS, usabilidade etc, utilizamos um design pronto (simples, intuitivo e direto), economizando tempo de pesquisa e encaixe pois as lógicas já eram criadas no design final.

Fazer o mínimo possível

Com o design em mãos e uma visão razoável do que queremos, escolhemos as funcionalidades mínimas para ter um produto que entregue algo que os produtos similares (Feedburner, Analytics etc) ainda não fazem. Essas funcionalidades, um subconjunto de histórias, foi definido como o objetivo ideal de entrega: o que deixaria o produto um passo a frente dos concorrentes.

Além disso, o PO possuia uma data de entrega, quando o sistema deveria estar no ar, que só ele conhecia. E aí entra a questão: se a data e o escopo estão fixos, perderemos qualidade.

Excluindo funcionalidades

Para fugir da perda de qualidade, o escopo era ideal, mas não fixo. Se fosse possível entregar tudo o que o PO desejava, ótimo, se não, ele deve estar pronto para lidar com o que foi entregue. Durante essa fase, o PO é capaz de rejulgar o escopo.

Após poucos dias, algumas funcionalidades foram cortadas, pois ficou claro que a ferramenta já entregaria valor suficiente com menos do que originalmente pensado para o primeiro release.

Excluindo funcionalidades

Mais alguns dias e novamente outras funcionalidades se apresentaram desnecessárias, junto com a maior importância na data de entrega do que no escopo a ser entregue. Com isso, menos funcionalidades (menos valor) seriam feitas, mas teríamos um produto que retorna valor em breve.

Priorizando o backlog

Priorizar o backlog adequadamente foi outra ação fundamental para entregar o máximo de valor possível no produto desenvolvido.

Excluindo funcionalidades

A equipe não possui um comprometimento com um escopo em uma data específica, portanto é responsabilidade do PO escolher o que é melhor ser entregue nesse período, isto é, priorizar corretamente.

Foram mais de duas vezes durante o período de desenvolvimento que cortamos funcionalidades. Em todas elas ganhamos tempo pois entregaríamos algo usável antes do planejado.

Equipe mínima

Em um início de produto tão rápido, é necessário manter uma equipe pequena pois qualquer burocratização do dia a dia de desenvolvimento levaria tempo demasiado para encaixar-se nas poucas horas. No nosso caso, existiam dois desenvolvedores e sentimos que em um grupo de até três, talvez quatro, seria possível fazer um trabalho similar.

Qualidade

Apesar de usar as práticas mais educadas possíveis, houve uma queda na qualidade, algo que o PO teve que pesar: após as 64 horas de desenvolvimento (2 pessoas, 4 dias úteis), tivemos mais 60 horas para investir somente em testes e refatorações.

A partir daqui, o desenvolvimento deve ser feito seguindo todas as práticas que acreditamos, sem margem para entregas rápidas como essa primeira pois a complexidade desse trabalho aumenta muito.

Pareamento e isolamento

A equipe se manteve razoavelmente distante de outras equipes de desenvolvimento e combinou pareamento com programação não pareada. Houve um equilíbrio de forças, misturando a propriedade coletiva do código com a produtividade que foi necessária. Novamente, após essa primeira entrega, abrir mão do pareamento se torna inviável.

Cliente ao lado

A qualquer instante os desenvolvedores tinham acesso ao PO e o cliente, tomando alguns cuidados. Esse é um ponto a ser defendido a todo custo se a entrega de uma versão inicial seguirá esse padrão. A qualquer instante o cliente poderá remover histórias desnecessárias ou solucionar problemas.

Na continuidade do projeto, isso já se torna diferente, uma vez que não esperamos re-priorizações dentro de sprint ou um cliente 100% liberado para os desenvolvedores.

Outros

Existem daily meetings, feedback rápido etc, como as práticas ágeis defendem.

A entrega

Após ter entrado em produção notamos que o tempo todo de desenvolvimento, o foco estava voltando na entrega de algo utilizável, algo com valor para o cliente, que no dia seguinte já poderia colocar em produção.

Deixamos um front end aberto da aplicação para quem desejar visualizá-lo, apesar do back end envolver funcionalidades ligadas com REST, feeds, widgets etc que não estão visíveis no mesmo.

Resumindo

O primeiro release de um produto pode ser feito com práticas ágeis que fujam um pouco da qualidade máxima que tentamos atingir, viabilizando uma entrega rápida – mas não necessariamente ágil a todo instante – e valiosa.

Mas nada disso serve como desculpa para manter o desenvolvimento do produto dessa maneira posteriormente: a preocupação com a qualidade deve voltar ao máximo e a partir desse instante um método de desenvolvimento mais formal (como Scrum, Lean etc) deve ser seguido.

Post criado junto com o Thiago Ferreira da Caelum.