Elaboração de um Product Backlog Efetivo

Scrum é um framework para gerenciamento de produtos, baseado em desenvolvimento iterativo e incremental. O seu ciclo inicia com uma lista de funcionalidades desejadas para o produto, priorizada pelo cliente, então o time escolhe as funcionalidades que se compromete em desenvolver, geralmente  com iterações de 1 a 4 semanas.

Podemos notar que esse ciclo é bem definido, tendo como ponto de partida o Product Backlog, mas o Scrum não tem nenhuma definição de como construir um Backlog. Sempre nos deparamos com as perguntas:

  1. Como chegar ao Backlog?
  2. Como construir algo que tenha valor?
  3. Como encontrar a real necessidade do cliente?
  4. Como definir o que é prioridade para o cliente no primeiro momento?

Tentando responder essas perguntas, depois de diversas experiências em vários clientes, nasceu o “PBB – Product Backlog Building”. O PBB tem como principal objetivo ajudar na construção de um Backlog de uma forma compartilhada, construindo um entendimento compartilhado, levando todos os envolvidos ao entendimento colaborativo do domínio do negócio, ou seja, todos compreenderem o contexto do negócio.

Tem como objetivo vivenciar na prática a construção de um Backlog através do Product Backlog Building (PBB) um processo de construção do Product Backlog que utiliza o Backlog Canvas como ferramenta. Essa dinâmica leva todos envolvidos do negócio a uma experiência prática de elaboração e definição de um Product Backlog Efetivo totalmente consistente e alinhado com os valores de negócio do cliente.

Principais objetivos:

  1. Ajudar na construção de um BACKLOG de um forma efetiva e colaborativa.
  2. Construir um entendimento compartilhado do negócio do cliente, facilitando a descoberta e compreensão do produto.
  3. Buscar uma maneira de descrever a experiência do usuário com o produto.
  4. Facilitar a descoberta e escrita de User Stories.
  5. Priorizar por alinhamento de expectativas e metas.
  6. Ter como resultado um Product Backlog totalmente alinhado com o valor de negócio do cliente.

PBB é representado por um canvas (Backlog Canvas) que tem um fluxo bem simples e de fácil compreensão, principalmente para facilitar o entendimento do cliente, pois sua participação é de suma importância nesse processo de construção.

O fluxo de uma forma linear ajuda a organizar a visão geral do negócio e alinhar o valor de negócio, a compreenção e o que o projeto irá agregar ao final, junto com a ferramenta “Backlog Canvas” que ainda deixa todo o levantamento de requisitos organizado de forma visual.

Nenhum comentário »

Categorias deste post

Agile, Gestão de Produtos, Portfólio, Requisitos, Scrum

Um exemplo prático de SCRUM em uma Campanha de Marketing (Parte II)

Leia a Parte I aqui

Planeje, fracasse, itere…

Enfim, chegamos na Sprint1 e como já sabemos, o SCRUM permite que a equipe tenha um nível de interação muito alto, principalmente pela característica de autogerenciamento e é exatamente por isso que certas regras quando combinadas entre todos de forma antecipada, tornam o ambiente mais amigável e estimulam a disciplina e organização.

Para a campanha foram necessárias algumas definições importantes previamente combinadas com o time na reunião Sprint Planning.

Sprint Planning

Definition of Ready

Aqui descrevemos o que é importante estar pronto em relação aos itens do Product Backlog para que a Sprint seja iniciada:

Definições de pronto para iniciar: à construção da Landing Page finalizada; o e-mail que será enviado devidamente finalizado com as configurações prévias do software de disparo prontas; os anúncios do Google Adwords validados; assim como os Banners finalizados e toda a configuração do Google Adwords feita e pronta para inicio da Sprint.

Definition of Done

Aqui descrevemos o que é importante estar pronto após a execução da Sprint em relação aos itens do Product Backlog:

Definição de pronto após finalizada a Sprint: as Estatísticas de acesso do Google Adwords; do Google Analitycs; dos e-mails enviados; das ligações realizadas; das oportunidades abertas; dos registros de visitas e dos faturamentos. Ainda consta desta lista, a relação de e-mails sensibilizados que foram encaminhados para a pessoa de Telemarketing para ações de Follow-up.

Meta

A meta definida para a Sprint 1 foi baseada na quantidade de Contatos mapeados considerados efetivos (quando há um contato com chances reais de virar uma oportunidade), que no caso foi de 25 Contatos efetivos, no índice de CTR 1 do Google ADwords superior a 1% e no índice de e-mails clicados superior a 15% do total dos e-mails lidos.

1  O CTR é o número de cliques recebidos pelo anúncio dividido pelo número de vezes que ele é exibido.

Conforme o SCRUM há alguns cerimoniais que são utilizados como reuniões de feedback e que suportam o conceito de Inspeção e Adaptação, no caso:  Daily Meetings, Reviews e Retrospectives.

 Sprint 1

Basicamente o conceito de iniciar a Sprint da campanha foi:

– Disparar o Mail Marketing
– Ativar as Campanhas no Google Adwords (Pesquisa Orgânica e Rede de Display)
– Iniciar o trabalho de “cold call”

Há quem pergunte sobre o Sprint Backlog da campanha e a resposta é: “Os itens do Product Backlog estavam tão bem definidos que não tivemos problemas em utilizá-los na integra sem precisar decompô-los, até porque, essa seria uma tarefa bem difícil no nosso caso”.

Daily Meeting e Review

Uma vez que os dados foram gerados diariamente ao longo da Sprint, qualquer pessoa do time podia acompanhar o desempenho dos resultados, e encaramos isso como a nossa Daily Meeting, onde cada membro opinou sobre o andamento da campanha e sugeriu mudanças no decorrer do dia que foram implementadas ao longo da Sprint.

A partir da Daily Meeting muitas mudanças e ajustes foram realizados no Google ADwords.

Veja algumas importantes mudanças que ocorreram durante a Sprint 1:

– Rapidamente identificamos a necessidade de incrementar o valor unitário de cliques para algumas palavras chaves do Google ADwords com maior probabilidade de sucesso e revisão de outras com menos impressões entre outros ajustes em anúncios;

– Foram sugeridas novas possibilidades de mensagens do Mail Marketing e outras estratégias devido a baixa taxa de abertura;

– Foram apresentadas algumas dúvidas levantadas por clientes sobre produtos e soluções que acabaram por demandar um treinamento para a Analista de Telemarketing ministrado junto a nossa Parceira Oracle;

– E por último foi discutido possíveis ajustes no script de Prospecção para melhorar o discurso e a qualidade dos contatos efetivos.

Já a Review tratamos como o encontro realizado ao final da Sprint com o objetivo de apresentar os resultados, então foi apresentado um quadro resumo (com gráficos) com todos os números de desempenho e estatísticas de acesso e cliques realizados ao longo da Sprint.

Retrospective

As retrospectivas são as reuniões destinadas a entendimentos e esclarecimentos a respeito do processo de trabalho de uma Sprint, tendo como base o aprendizado necessário para a promoção das possíveis adaptações para as próximas Sprints.

Em nossa 1ª retrospectiva foram levantados alguns pontos de melhoria descritos baixo:

– Entendimento sobre o conceito de Oportunidade entre Prospecção e Vendas;

– Melhora no formato de apresentação do relatório de oportunidades e do quadro resumo;

– Detalhamento do fluxo de suporte da Oracle com relação às dúvidas técnicas levantadas nas atividades de prospecção;

– Solicitação de suporte do Google para aperfeiçoar algumas configurações do Google Adwords e esclarecer algumas dúvidas;

E tudo isso depois de apenas uma semana de campanha!

As metas foram parcialmente alcançadas:

Contatos Efetivos: 25 realizados
CTR: 0,08
E-mails clicados: 14,29%

Demais Sprints e Campanhas

As demais Sprints seguiram por mais três semanas e contribuíram positivamente para a melhora dos indicadores da campanha, forneceu subsídios valiosos sobre o comportamento dos clientes e reforçou a experiência e confiança do time em busca de resultados mais concretos.

Após duas Campanhas (Logística e Indústria), de acordo com os resultados gerados, conseguimos um aumento de 85% de incremento de novas Oportunidades e demos um importante passo no reforço da nossa marca junto ao mercado, especificamente para os dois segmentos abordados.

E depois…

Atualmente estamos trabalhando em nossa terceira campanha e o que eu posso registrar até o momento é que o SCRUM realmente nos trouxe uma perspectiva diferente de trabalho, totalmente baseada em um maior engajamento e colaboração do time, em prol de resultados mais satisfatórios para todos e para a empresa.

Também não posso deixar de considerar o aprendizado que todos nós tivemos em conjunto, embora não tenha trabalhado em todas as frentes, posso garantir que aprendi muito sobre várias atividades que se delegadas individualmente e gerenciadas de forma centralizada, não estariam tão expostas e suscetíveis as contribuições do grupo.

O efeito alcançado de melhoria contínua também foi notável, principalmente pelos erros e desencontros gerados pelas escolhas mal sucedidas, ou seja, quanto mais cedo você errar, mais perto de acertar nas próximas tentativas você estará, e com essa prática os resultados apareceram em questão de tempo.

Enfim, é preciso separar bem o Método ou Modelo de Trabalho de resultados positivos, é certo que o SCRUM não resolve tudo e nem é garantia de sucesso, porém através desse exercício empírico, se é que eu posso chamar assim, para minha empresa e para o meu grupo de trabalho ele funcionou adequadamente e trouxe resultados satisfatórios.

Agora só resta você testar também e lembre-se que para começar é preciso não se esquecer de Planejar, Fracassar e Iterar!

Boa sorte!

1 Comentário »

Categorias deste post

Agile, Gestão de Produtos, Mudança organizacional, Scrum

Um exemplo prático de SCRUM em uma Campanha de Marketing (Parte I)

Planeje, fracasse, itere…

Desde 2002 atuo na área de negócios com foco em vendas de soluções e serviços para tecnologia e agora nos últimos anos comecei a desbravar a área de marketing, foi então que resolvi colocar em prática algumas experiências adquiridas com o tempo.

Métodos Ágeis tem revolucionado a área de tecnologia, sobretudo área de desenvolvimento de software e mais recentemente a área de gestão.

E é exatamente com o foco mais em gestão do que em tecnologia que escrevo este artigo com o objetivo de apresentar de forma prática e direta o uso de uma Metodologia Ágil aplicada a Área de Marketing, onde a intenção aqui não é explicar o que é o SCRUM e sim demonstrar o seu uso no dia a dia de uma campanha de marketing recentemente lançada pela empresa.

A ideia partiu da necessidade de trabalharmos uma campanha para a venda de licenças Oracle que servisse de modelo para as demais campanhas de marketing da Unidade de Negócios responsável pela venda de produtos e soluções.

O desafio foi imenso, pois não sabíamos por onde começar, então tomamos por base iniciar pelo caminho mais lógico e óbvio, a Visão:

Vision – É melhor começar por aqui!

Antes de tudo, é muito importante sabermos para onde queremos ir ou onde queremos chegar.  Por isso, antes de iniciarmos os trabalhos efetivamente, conversamos com todo o grupo envolvido a respeito dos objetivos da campanha e o resultado dessa conversa foi a descrição abaixo sobre a Visão:

“Reforçar a presença da Unidade de Negócios junto ao mercado e clientes da empresa como fornecedores de soluções Oracle através de quatro campanhas para segmentos diferentes com duração de aproximadamente 1 mês cada uma e consequentemente incrementar em 80% o Pipeline de Oportunidades do time de vendas. “

Pre-game – Antes de iniciar o jogo.

Trabalhar com Métodos Ágeis exige muita disciplina e planejamento ao contrário do que se prega por aí, a diferença é que o planejamento realizado é pragmático e o feedback das ações e acontecimentos são rápidos, diferente da dinâmica utilizada em métodos tradicionais.  Sendo assim, foram definidos previamente a título de Pre-Game algumas premissas importantes e vitais para a campanha:

– Principais Canais a serem utilizados:
– Google Adwords;
– Mail Marketing disparado através de uma ferramenta específica;
– Ligações (Telemarketing Ativo) realizadas por um membro da equipe com experiência neste tipo de abordagem;
– Visitas e atendimento comercial realizado por um Vendedor especializado;

– Os papéis:
– Eu como Scrum Master;
– O Gerente de operações da Unidade de Negócios como o  Product Owner ;
– O time de execução: Vendedor,  Analista de Telemarketing e Analista de Marketing .

– Definição de uma meta por campanha expressa em quantidade de licenças por tipo de produto. Essa meta não é a mesma meta da Sprint sugerida pelo SCRUM que será comentada mais adiante, é apenas uma diretriz e definição de “norte” para a equipe de vendas;

– Como medição dos resultados, decidimos utilizar os Relatórios Gerenciais das ferramentas utilizadas (Google Adwords, Google Analitycs, e-Goi e Sistema de CRM);

– Embora a literatura do SCRUM sugira um tempo de Sprint entre 2 a 4 semanas como ideal, o tempo de duração utilizado nas Sprints foi de 1 semana, pois de acordo com o negócio em questão, foi considerado um tempo suficiente para a percepção das mudanças e geração de resultados.

Product Backlog – É hora de exercitar sua criatividade!

Após a etapa de Pre-game, montamos uma lista de itens com todas as informações que tínhamos disponíveis e que de alguma forma poderiam ajudar a formar a nossa lista final do Product Backlog:

– Informações bem detalhadas sobre os Produtos e Soluções ofertadas
– Cases de Sucesso sobre os segmentos que estávamos abordando
– Uma pesquisa simples sobre os segmentos desejados considerando alguns números de mercado e os principais desafios para Área de Tecnologia para o próximo ano para cada um deles
– Política de descontos dos nossos Distribuidores
– Base de e-mails exportada a partir do CRM

A partir dessas informações “idealizamos” o nosso próprio Product Backlog conforme os seguintes itens:

– Landing Page da campanha
– Banners publicitários
– Anúncios
– Script para Prospecção (Telemarketing Ativo)
– E-mail

A escolha de cada item acima foi decidida com base em “peças” que poderiam ser trabalhadas quanto à forma, estética e conteúdo e que também poderiam ser facilmente estressados ao longo das Sprints, considerando testes e medições. Em outras palavras, o conceito de Inspeção e Adaptação foi levado ao extremo, pois os resultados das medições ficaram disponíveis em tempo real o tempo todo e as alterações e mudanças foram realizadas ora balizadas pelos resultados até então atingidos, ora como testes que se provaram ou foram abandonados nas Sprints futuras.

Na Parte II deste texto você verá o que aconteceu na Sprint 1, não deixe de ler aqui!

2 Comentários »

Categorias deste post

Agile, Gestão de Produtos, Mudança organizacional, Scrum

Requisitos Ágeis “à moda da casa” !

Gravamos um vídeo sobre a nossa compilação de aprendizados na disciplina de requisitos!

Esclarecemos, em um quadrante – Why, What, Where e How – , quais técnicas, de levantamento de requisitos e funcionalidades, podemos utilizar em processos ágeis. Conectar essas técnicas e direcionar os profissionais envolvidos; através da prática de dinâmicas baseadas em “canvas”; a alcançar um alto nível de conhecimento sobre as características técnicas e de negócio deste produto, em tempo otimizado, é o objetivo do treinamento de Requistos Ágeis – que estruturamos a partir deste nosso aprendizado!

Este treinamento será ministrado, com super descontos, e com três instrutores no do Agile Trends 2014!

Assistam o vídeo e venham participar!

Videocast Adaptworks #4 – Requisitos Ágeis

Nenhum comentário »

Categorias deste post

Agile, Eventos, Gestão de Produtos, Product Owner, Requisitos, Videocasts

TeamStart – Vídeo do webinar sobre Estimativas Ágeis

Nesse webinar promovido pela Rally Software,  faço uma dobradinha com Andreano Lanusse para dar uma visão prática de como funcionam as estimativas ágeis num projeto de software. O vídeo,  com duração de 01:36h,  mostra uma série de dicas para escopo, classificação de tamanho, tratamento da incerteza, da complexidade, orçamentação, preparação e refinamento do backlog. Bons estudos!

Nenhum comentário »

Categorias deste post

Agile, Gestão de Produtos, Product Owner, Requisitos, Videocasts

Grooming Canvas – Todas as user stories estão no inferno!

Dentro do paradigma ágil, quando estamos num processo de desenvolvimento de um produto,  buscamos iniciar todos os nossos esforços de entendimento e até mesmo de desenvolvimento por aquilo que acreditamos que será o maior valor do produto.

O  próprio Scrum estimula que um Product Owner (vulgo PO) comece a “povoar“ seu Product Backlog aplicando um forte senso de priorização baseada em valor. E de maneira geral, muitas organizações tem uma enorme dificuldade em definir  ou consensualizar o que é valor. Mas isso é assunto para outro texto.

Contudo, ao longo do tempo, comecei a notar uma tendência forte entre os POs e times de produtos. Podemos nomear essa tendência com a famosa frase de “no final, tudo é importante!”

Isso acontece pois seria uma ingenuidade achar que conseguiríamos, de imediato, já iniciar o nosso pensamento sobre o produto pelo mais importante e excluir as funcionalidades que não agregam valor. Na verdade isso é bastante perigoso. O perigo se dá pois, na tentativa de começar um Product Backlog pelo seu topo de prioridade, ordem e valor, acabamos gerando o mesmo problema de excesso de funcionalidades nos produtos desenvolvidos. Na prática, muitos Product Backlogs tem um topo muito extenso.  E é aí que mora o perigo.

Ao meu ver, isso acontece pois muitos praticantes de agile se distanciaram de um item muito importante do manifesto ágil. Na verdade, o item em questão é um dos doze princípios ágeis (pois é, eles existem! Usa Agile e não sabia disso? Shame on you!). Mas especificamente,  estou me referenciando ao décimo princípio.

O Décimo princípio do Manifesto Ágil diz:  Simplicidade – A arte de maximizar a quantidade de trabalho não realizado – é essencial.  Esse princípio, na minha opinião, é matador!  Na prática ele  toca na ferida ou na maior dificuldade na adoção do pensamento ágil na criação de produtos. Essa dificuldade se dá pelo fato de que Agile preconiza o desapego de (muitas) partes desejadas para um determinado produto.   Quando se contrasta “coisas que tem valor” versos “coisas que não tem tanto valor”,  o exercício  de priorizar e descartar fica fácil. Mas quando se contrasta “coisas que tem valor” versos “coisas que também tem valor”, aí o desafio começa.

Meu amigo Rodrigo de Toledo menciona:  “Nos tempos atuais, o trabalho do profissional de informática deveria passar a se concentrar na SÍNTESE de sistemas. Devemos remover funcionalidades ao invés de gerar mais.” Sendo assim, um dos maiores desafios econômicos e culturais do desenvolvimento de software é criar e efetivar uma inteligência saudável de descartar o máximo possível de trabalho não feito, para poder focar na menor parte de maior valor do produto.

Para ajudar a resolver esse problema (veja bem, ajudar, não resolver, ok?) há algum tempo sugiro para os POs o seguinte exercício:  Vamos adotar a premissa de que “Todas as user stories têm baixo valor até que se prove o contrário!”. A ideia é transformar esse pensamento numa espécie de mantra ou numa regra que deve ser seguida a risca a cada item desejado para o Product Backlog.

Ao seguir essa regra, O PO precisa fazer um difícil exercício. Esse exercício é difícil pois como todos os itens já nascem com baixa prioridade, o PO, tem se esforçar em fazer aquele item merecer ir para o topo do Product Backlog.

É  importante alertar que o elemento que mostrarei em seguida, não oferece uma maneira explícita para identificar a priorização.  Cabe a cada PO identificar uma forma ou técnica para fazer essa priorização. O importante que essa priorização aconteça por critérios transparentes e passíveis de discussão dentro da organização.

Para apoiar esse exercício, criei uma espécie de canvas (ver figura abaixo) para guiar, de maneira visual, esse raciocínio.  A esse canvas chamo carinhosamente de Grooming Canvas, pois  sua aplicação serve exatamente para ajudarmos o processo de grooming (refinamento e organização) dos itens de um Product Backlog.  Essa prática de grooming, no fundo, tem um caráter contínuo no desafio em tornar os itens mais prioritários em estágio de DOR (Definition Of Ready).

GroomingCanvas-ManoelPimentel

Nesse canvas,  temos 2 eixos. No eixo vertical, temos a dimensão de valor seguindo a premissa de priorização que explicamos acima. E no eixo horizontal, temos a dimensão de tamanho. A dimensão de tamanho segue o mantra de “Todas as user stories são um ÉPICO/TEMA até que se prove o contrário!”. O tamanho é outro ingrediente importante nessa conversa.  Pois se algum item tem pouco valor de negócio, não precisamos investir (ou gastar) tempo em detalha-lo. A ideia do Épico ou Tema é uma forma de identificarmos e mostrarmos o quanto um item ainda está muito grande, ou há muita incerteza, ou ainda não está num tamanho suficiente pequeno para entrar em uma Sprint.  Dessa forma, por ser um TEMA/ÉPICO isso significa que aquele item precisa ser quebrado/desmembrado em itens menores e factíveis de entendimento, por exemplo.

Juntando as regras de que todas as user stories são grandes e também têm baixo valor, notamos que por padrão, os itens do backlog já nascem no final do mesmo (representado pelo canto inferior direito do canvas). E cada vez que vamos refinando e entendo mais sobre o seu contexto de negócio, o  item vai subindo ao topo do backlog (que no canvas é representado pelo canto superior esquerdo).

Uma maneira de compreender a dinâmica e os fenômenos que ocorrerão no canvas, é usando a metáfora Dantesca para classificar as coisas. Nessa visão (ver figura abaixo), é possível resumir que todo e qualquer item, já nasce no inferno (cruel, não?) e ele precisa ser trabalhado em termos de prioridade e redução de tamanho para poder merecer entrar no céu.

GroomingCanvas-DivinaComedia-ManoelPimentel

Esse canvas acaba sintetizando uma forma um pouco contra-intuitiva para priorizar e refinar itens de um Product Owner.  Pelo fato de ser contra-intuitivo, demanda um esforço maior por parte de um PO. Lembro-me que na primeira vez que usei essa abordagem era possível ouvir (metaforicamente) os estalos das sinapses na cabeça do pobre PO.

Infelizmente apliquei e acompanhei esse canvas em poucos projetos reais. Mas mostro-a de maneira frequente aos alunos do curso de Requisitos Ágeis aqui na Adaptworks.  E durante ou após o treinamento, sempre recebemos feedbacks muito positivos quanto à mesma. Dessa forma, o objetivo desse texto foi socializar essa simples abordagem.  Desejo que outras pessoas sintam-se estimuladas a experimentarem e nos falarem dos resultados/dificuldades encontradas em sua aplicação. Maiores dúvidas ou sugestões, sintam-se convidados a me contatar em manoel@adaptworks.com.br ou pelo meu twitter: http://twitter.com/manoelp .  Até lá!

4 Comentários »

Categorias deste post

Gestão de Produtos, Product Owner, Requisitos

Usabilidade ou User Experience – é questão de escolha?

Acertar na interface exposta para os usuários e no modo de interação deles com nosso produto é sempre difícil. Afinal, existem grandes barreiras conceituais para atravessar: nós não sofremos do exato problema que eles sofrem e, nenhum deles passou o tempo implementando a solução conosco.

Existem diversas técnicas criadas para ajudar a resolver esse quebra-cabeça e possibilitar uma interface satisfatória que mantenha a integridade da solução provida. Em uma procura na web, livraria ou conferências, as duas buzz-words mais populares são “Usabilidade” e “UX” (User Experience). Qual a diferença? Qual conjunto de técnicas escolher entre os dois?

Como qualquer discussão técnica sobre definições e termos, bem, não existe uma única resposta correta para a diferença. Neste artigo vou tentar esclarecer minha própria visão dos dois, o modo como penso sobre cada termo quando aplico ou leciono suas técnicas – use se for compatível com seu parecer e aproveite a área de comentários para discutir se não for!

Não sou um fanático de definições, assim antes de começar, temos que deixar claro que… Desde que mantenhamos a abordagem correta, não faz diferença alguma!

A nomenclatura do termo que usamos na hora da implementação é um problema dentro do domínio de implementação, a escolha é uma solução que resolve um problema que nós temos, mas nosso usuário não. O problema que o usuário tem é que ele quer ser feliz e eficiente ao usar o produto, independente da forma como sua criação foi organizada, de modo que a terminologia correta é qualquer terminologia que facilite uma abordagem de desenvolvimento focada e centrada no usuário (solucionando o primeiro problema) e dessa forma atinge o objetivo de satisfazer o usuário (a solução do problema 2)!

Usabilidade

De volta ao contraste dos dois termos, até tempos atrás Usabilidade era o nome utilizado para resolver qualquer problema ou questão pertinente à qualidade da interação com o Usuário: Não basta ser útil, um software tem que ser usável também! Temos varias funções no nosso produto, mas será que o usuário encontra e opera essas funções intuitivamente e com baixo custo operacional?

Com o tempo, para administrar a usabilidade, sentiu-se a necessidade de defini-la e procurar medi-la. Os Standards voltados à usabilidade foram um bom empurrão nesse sentido e, com o tempo fizeram-se disponíveis métodos, definições e listas pelas quais organizar nosso trabalho de Usabilidade nos nossos projetos. Por exemplo, Jacob Nielsen (um das autoridades nas pesquisas de usabilidade) descreve o termo como a medida da coleção de Aprendibilidade, Eficiência, Memorabilidade, Erros e Satisfação.

UX

A própria popularidade do termo tornou-se seu maior obstáculo. Ao tentar definir o termo de forma exata, acabamos com uma lista do que o termo é… E subentendes-se o que o termo não é.

Preenchendo esses espaços que as definições de usabilidade não cobrem, User Experience é uma extensão da definição de Usabilidade: Não basta ser útil, não basta ser usável, um software tem que proporcionar uma experiência positiva e intensa! O usuário encontra e opera as funções com facilidade, mas será que ele está feliz ao fazê-lo?

Se quiséssemos comparar com Usabilidade, Peter Morville (outro guru) define UX como uma coleção de atributos que inclui Usabilidade — e outras características mais como Desejabilidade, Credibilidade, e Valor.

Segundo o visto acima, UX é um termo que inclui o conceito de Usabilidade, então de modo seco pode também ser considerado um termo mais seguro.

Porém não se pode atingir um grau elevado de experiência de usuário (UX) sem atingir um grau elevado de Usabilidade. O foco da equipe de desenvolvimento deve ser nos dois simultaneamente e, nas duas áreas existem técnicas (às vezes distintas, às vezes as mesmas) que nos ajudam a trabalhar cada um dos dois em separados e em conjunto, técnicas que centram nossas decisões no bem do usuário final.

Até a próxima vez, boa sorte… E tome conta do seu User!

Sobre o autor:

Shmuel Gershon

É líder técnico na Intel Corporation em Israel, onde testa software e firmware com seu time de super-heróis. Seu dia a dia inclui diversas atividades, como criar e adaptar estratégias de testes, testar tecnologia em diversas camadas, treinar testers, ajudar amigos e fazer tudo de novo no próximo produto. Já trabalhou em empresas de diversos portes da América do Sul ao Oriente Médio, e apesar de começar sua carreira programando, descobriu que testar é o dobro da diversão. Shmuel é palestrante frequente em conferencias internacionais sobre testes (StartEast, EuroStar, SIGiST…) e sobre programação (Oredev, Goto, SWPC…), trazendo uma visão única sobre software: a convicção de que o fator mais importante na nossa busca por qualidade são as pessoas e não as tecnologias. Para conhecer mais, leia seus artigos na BetterSoftware Magazine ou no blog, onde você também encontra Rapid Reporter, aplicativo freeware que facilita relatórios e anotações durante testes exploratórios. Homepage: http://gershon.info.

Nenhum comentário »

Categorias deste post

Gestão de Produtos

Definition of Ready : Qualidade na entrada das Sprints

Uma reclamação frequente de times de desenvolvimento (Dev Team) em Scrum é que, com o discurso de agilidade, requisitos chegam nas Sprints com baixa qualidade. Não é difícil encontrar Product Owners que mantém no topo do Product Backlog itens com granularidade ruim, pouco (ou nenhum) detalhamento e  – pior – baixo entendimento do próprio Product Owner sobre o que está sendo pedido. Isso, na maioria das vezes, transforma a Sprint Planning Meeting em uma reunião arrastada e com muitas perguntas não respondidas. Consequentemente, times fazem um planejamento de baixa qualidade e são surpreendidos ao longo das Sprints com impactantes descobertas do Product Owner sobre aquele item, o que resulta em mudanças no objetivo e desenvolvimento. Resultado: Time desmotivado. Sprint não consegue atingir meta. Product Owner insatisfeito com o time. Sistema em colapso.

Requisitos Ready se transformam em entregáveis Done

Uma prática que tem ajudado bastante nestes casos é a adição ao Scrum do conceito de “Definition of Ready”. Este conceito age de forma bem parecida com a conhecida “Definition of Done”, mas enquanto “Done” garante qualidade na saída da Sprint, “Ready” garante qualidade na entrada da Sprint.

Enquanto o Dev Team tem o compromisso de entregar ao Product Owner apenas funcionalidades Done, este por sua vez assume o compromisso em manter apenas itens Ready no topo do Product Backlog.

Um exemplo de Definition of Ready

Uma “Definition of Ready” precisa ser capaz de expressar o mesmo significado para todos que a lêem, principalmente Dev Team e Product Owner. Um exemplo:

Um Product Backlog Item está Ready quando:

– Está escrito como uma User Story INVEST;
– Possui um Teste de Aceitação automatizável;
– Possui um Wireframe de baixa fidelidade;

Caso você trabalhe com itens de diferentes tipos no seu Product Backlog, como por exemplo: itens de negócio, itens técnicos, spikes, bugs, etc., você pode optar por ter uma Definition of Ready diferente para cada um deles; afinal de contas pode não fazer sentido gerar um Wireframe para um Spike entitulado “Escolha de solução para Pagamento de Cartão de Crédito”, certo?

Quem tem a responsabilidade de tornar um item Ready?

A responsabilidade é do Product Owner, mesmo que para isso precise envolver outras pessoas. Enquanto o Dev Team trabalha, por exemplo, na Sprint 3, o Product Owner tem que garantir que os itens do topo do Product Backlog estejam Ready para quando da Planning Meeting da Sprint 4. Caso ele precise envolver o Dev Team neste trabalho,  seria interessante “oficializar” reunião(ões) de “Grooming” que já fossem previstas no TimeBox da Sprint.

O uso de “Definition of Ready” não está limitado ao Scrum, e pode ser muito útil também quando trabalhando com Kanban e outros métodos.

Treinamentos da AdaptWorks relacionados ao tema

Certified Scrum Product Owner
Requisitos Ágeis

6 Comentários »

Categorias deste post

Gestão de Produtos, Product Owner, Scrum, Time de desenvolvimento

Treinamento sobre Innovation Games

Na semana passada tive a oportunidade de participar do treinamento de Innovation Games, promovido pela Adaptworks, com Michael Gaines.

Os “jogos de inovação” são alguns jogos elaborados por uma consultoria do Vale do Silício, The Innovation Games Company ®, criada pelo canadense Luke Hohmann, que cria jogos que estimulam o engajamento de clientes, colegas e parceiros no desenvolvimento de produtos/projetos.

Por sua informalidade, a técnica de jogos permite que pessoas de diferentes níveis hierárquicos, com diferentes papéis na empresa no ou na equipe de desenvolvimento de produto/projeto, sintam-se a vontade para expor suas visões sobre o que está sendo feito.

No treinamento nos fizemos alguns dos jogos, que nos ajudaram a aplicar diferentes técnicas para priorizar atividades no desenvolvimento de um projeto/produto, a entender melhor aspectos que estimulam ou atrasam o ciclo de desenvolvimento e a relacionar recursos existens a fim de se chegar a novas idéias através da associação destes recursos.

Aqui vai uma breve descrição dos jogos que praticamos:

Speed Boat – ajuda a entender o que seus clientes gostam ou não gostam em seu produto ou serviço, quais são os aspectos que estão ajudando a acelerar ou a desacelerar seu projeto ou ainda a entender quais são os fatores de motivação e desmotivação que sua equipe percebe no projeto. A técnica garante que reuniões de retrospectiva / avaliação fiquem sob controle e não se transformem numa avalanche de reclamações em que só aparecem os aspectos negativos do projeto, sem se pensar em como resolvê-los e avançar. A técnica é bem simples, você precisa apenas desenhar um barco num quadro branco ou folha de papel pendurada na parede, e as pessoas devem marcar, com post-its, as coisas que “ancoram” o barco, e as coisas que o fazem andar com maior velocidade. Os itens podem ter peso (marcado nos post-its), ou simplesmente estar em posições diferentes no quadro (as coisas que mais atrapalham ficam mais fundas, como se fossem as âncoras mais pesadas).

Buy a Feature – ajuda a fazer com que seu cliente (ou CEO, ou Diretor, ou Gerente de Produtos, etc) consiga priorizar melhor o desenvolvimento de features que realmente irão agregar mais valor ao negócio. Geralmente o cliente quer o projeto todo pronto, para ontem. Mas nem todas as features serão usadas, nem todas são críticas para o lançamento e nem todas precisam de fato ser feitas (isso vai acabar sendo descoberto com o uso do produto). O jogo consiste em ter uma lista de features, e a dar um preço para cada uma delas (na vida real, o preço pode ser a estimativa e o custo de desenvolvimento, por exemplo). Cada cliente receberá um certo valor para poder comprar as features, mas, obviamente, não terá dinheiro suficiente para todas. Portanto, para algumas features, ele terá que negociar com outros clientes para que os dois juntos tenham recursos suficientes para comprá-las, e terá que abrir mão de outras. O resultado deste jogo é que o conjunto de clientes de seu produto terá priorizado o que realmente lhes traz valor.

Remember the Future – o que você precisa fazer em seu produto para que daqui a 1 ano ele tenha trazido determinado benefício ao seu cliente? Partindo do benefício, a idéia deste jogo é pensar de traz para frente o que é necessário fazer com o produto para que ele traga tal benefício, e o que precisou ser feito imediatamente antes para que ele chegasse até este ponto. Dado o prazo para o produto atingir o objetivo, este jogo faz com que as pessoas pensem no que é realmente necessário para partir do ponto em que se está hoje, para se chegar ao ponto em que o produto trará o benefício esperado.

Prune the Product Tree – todas as features são importantes e precisam ser entregues ao mesmo tempo? Isso não é verdade, e com este jogo você e sua equipe poderão montar o roadmap de seu produto pensando nos diversos aspectos do produto. A metodologia consiste em desenhar uma árvore, e ir colocando, com post-its, para dar o formato desejado à copa da árvore. Assim, os galhos da árvore representam os tipos de funcionalidade, as funcionalidades em si são as folhas, as features fundamentais são o tronco, e a base da aplicação são as raízes. Assim, as pessoas vão colando as folhas nos devidos galhos, sendo que as funcionalidades já prontas ou mais desejáveis ficam mais perto do tronco do que as menos importantes. A metologia deixa vísivel quando, por exemplo, algum aspecto de seu produto está ficando de lado (ex: muitas folhas no ramo que diz respeito ao front-end de sua plataforma de comércio eletrônico e poucas no raml que diz respeito ao back-end), para que você possa avaliar se está é mesmo a melhor opção.

Product Box – Desenhando a caixa que venderia seu produto ou serviço num supermercado, os jogadores terão que identificar quais os aspectos mais importantes do produto, como comunicá-los melhor e quais problemas de fato seu produto resolve. As limitações de espaço exigirão que o grupo pense no que realmente são as principais características do produto, e tenha criatividade para comunicar da melhor forma.

Spider Web – Este jogo, que funciona através do desenho de uma rede que relacione todos os produtos, serviços ou usos que podem ser feitos com seu produto na forma de uma teia de aranha. Com isso, percebe-se novos usos que podem ser feitos do produto através das conexões que aparecerão.

Start Your Day – Descreva como seu cliente usa ou se relaciona com seu produto ao longo do tempo (pode ser um dia, uma semana, um mês ou qualque período, depende do seu produto). Pense em todas as situações em que seu produto é necessário para o cliente, e como seu produto pode ajudá-lo em cada caso. Com isso você entenderá melhor como seu produto é usado, para quais aspectos você tem que dar mais importância, e obviamente, ajudará a pensar na experiência do usuário, sob todos os aspectos.

Sempre que possível envolva também o cliente, afinal, é importante ele estar engajado com o projeto e totalmente alinhado com sua equipe.

Estes e outros jogos criados pela The Innovation Games Company (R) estão disponíveis no livro Innovation Games: Creating Breakthrough Products Through Collaborative Play, que todos os participantes do treinamento receberam como cortesia.

Para vários dos jogos há versões onlines, para que times remotos possam participar, mas obviamente o ideal é a equipe estar toda reunida, uma vez que a colaboração e o debate são fundamentais para que os resultados esperados sejam alcançados.

Se você já aplicou alguma destas técnicas em alguma empresa ou cliente, aproveite o espaço de comentários do blog para contar sua experiência!

Se não aplicou, lembre-se, a técnica de jogos é simples, mas exige uma preparação prévia da sala e dos materiais a serem utilizados para que funcione bem e envolva a equipe de jogadores!

Nenhum comentário »

Categorias deste post

Gestão de Produtos, Innovation Games, Mudança organizacional