Planejamento de releases de sistemas interativos com story mapping
•
16 gefällt mir•1,001 views
Apresentação da técnica chamada story mapping, utilizada para priorização de funcionalidades e planejamento de releases de produtos interativos (no contexto de desenvolvimento ágil), e aplicação testes de usabilidade simplificados dentro desses releases.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Ähnlich wie Planejamento de releases de sistemas interativos com story mapping
Ähnlich wie Planejamento de releases de sistemas interativos com story mapping (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (9)
Planejamento de releases de sistemas interativos com story mapping
- 1. Planejamento de releases e usabilidade de sistemas interativos Fabrício Marchezini e Leandro Alves
- 2. Quem somos • Sócios da Latitude14 ‣ latitude14.com.br e @latitude14 • Mentores da Aceleradora @aceleradora • Representantes da IxDA BH @ixdabh • Coordenadores do Dia Mundial da Usabilidade em Belo Horizonte ‣ diamundialdausabilidade.com.br
- 6. Story mapping Técnica colaborativa que auxilia na priorização de funcionalidades para planejamento de releases
- 7. Quem deve participar? Negócios Marketing Designers Desenvolvedores Cliente Usuários fonte: http://www.selfishprogramming.com/2008/10/
- 8. Etapas 1. Listar funcionalidades 2. Escrever em cartões 3. Ordenar em fluxo de tarefas 4. Ajustar posição quanto à criticidade 5. Agrupar por atividades macros 6. Marcar o primeiro release
- 9. Passo 1 Brainstorming: faça uma lista de possíveis features do seu sistema • Mantenha o ponto de vista de quem vai usar o sistema • Cada item deve começar com um verbo • Esqueça detalhes de implementação
- 10. Passo 1 • Ex.: software de controle de vendas ‣ Fazer pedido ao fornecedor ‣ Receber pedido do fornecedor ‣ Gerar etiquetas para itens recebidos ‣ Vender produtos ‣ Devolver e reembolsar produtos ‣ Analisar vendas
- 11. Passo 1 • Escreva cada item em um cartão diferente • “Eu, como usuário x, preciso .... no sistema” • Deixe espaço para outros detalhes Fazer pedido ao fornecedor
- 12. Passo 2 • Adicione detalhes importantes: ‣ Usuários (profissão, cargo, papel desempenhado) ‣ Frequência de uso (muito, pouco, raro ou diariamente, semanalmente etc.) ‣ Valor (valor para o negócio. ROI) Fazer pedido ao fornecedor (comprador) Frequência: semanalmente Valor: médio
- 13. Passo 3 • Ordene as cartas em uma sequência lógica de tarefas ‣ O objetivo é contar uma história de como o sistema funciona ‣ Sobreponha os cartões que aconteçam no mesmo tempo
- 14. Fazer pedido ao Receber pedido do Gerar etiqueta para os fornecedor Vender produto Analisar vendas vendedor produtos recebidos (comprador) (consultor de vendas) (analista de vendas) (controlador de estoque) (controlador de estoque) Frequência: Frequência: diário Frequência: mensal Frequência: diário Frequência: diário semanalmente Valor: alto Valor: alto Valor: alto Valor: médio Valor: médio Devolver e reembolsar (consultor de vendas) Frequência: diário Valor: médio sequência de uso
- 15. Passo 4 • Ajustar conforme criticidade (verticalmente) ‣ Coloque acima as cartas mais críticas e mais frequentemente usadas pelos usuários. ‣ Discuta com a equipe o quão crítica cada funcionalidade é para o negócio
- 16. muito usado Necessidade Receber pedido do Vender produto vendedor (consultor de vendas) (controlador de estoque) Frequência: diário Frequência: diário Valor: alto Valor: alto Fazer pedido ao Gerar etiqueta para os fornecedor Devolver e reembolsar Analisar vendas produtos recebidos (comprador) (consultor de vendas) (analista de vendas) (controlador de estoque) Frequência: Frequência: diário Frequência: mensal Frequência: diário semanalmente Valor: médio Valor: alto Valor: médio Valor: médio raramente usado sequência de uso
- 17. Passo 5 • Marque as quebras no fluxo ‣ Discuta onde há quebras no modelo ‣ Pode ser uma mudança de usuário, regras de negócio ou processo ‣ Divida verticalmente as quebras e dê um nome ‣ Cada grupo representa as atividades que as pessoas realizam no sistema
- 18. muito usado compra recebimento Venda Análise Necessidade Receber pedido do Vender produto vendedor (consultor de vendas) (controlador de estoque) Frequência: diário Frequência: diário Valor: alto Valor: alto Fazer pedido ao Gerar etiqueta para os fornecedor Devolver e reembolsar Analisar vendas produtos recebidos (comprador) (consultor de vendas) (analista de vendas) (controlador de estoque) Frequência: Frequência: diário Frequência: mensal Frequência: diário semanalmente Valor: médio Valor: alto Valor: médio Valor: médio raramente usado sequência de uso
- 19. Passo 6 • Marcar primeiro release ‣ Deve ser o menor número de funcionalidades úteis para os usuários e o contexto do negócio ‣ É o primeiro release mas não necessariamente o primeiro a ser público
- 20. muito usado compra recebimento Venda Análise Necessidade Receber pedido do Vender produto vendedor (consultor de vendas) (controlador de estoque) Frequência: diário Frequência: diário Valor: alto Valor: alto Fazer pedido ao Gerar etiqueta para os fornecedor produtos recebidos Devolver e reembolsar Analisar vendas (comprador) (controlador de estoque) (consultor de vendas) (analista de vendas) Frequência: Frequência: diário Frequência: diário Frequência: mensal semanalmente Valor: médio Valor: médio Valor: alto Valor: médio raramente usado sequência de uso
- 21. Passo 7 • Estime o tempo de desenvolvimento ‣ Peça a equipe de desenvolvimento que estime o tempo para cada cartão (em dias, horas, semanas etc.)
- 22. Passo 8 • Reparta o bolo: programe outros releases ‣ No final você poderá ver quantos releases serão necessários e quais funcionalidades conterá em cada um
- 24. Release 1 Release 2 Release 3 Release 4
- 25. Vantagens do story map • A primeira versão tem somente o que é mais útil e tem maior valor de negócio • Facilita ver as relações de dependência entre as funcionalidades • Ajuda a formar a “visão do todo” • Facilita a comunicação interna • Gera rápido retorno • Reduz risco
- 26. E onde entra a usabilidade nessa história?
- 29. Porque testar? • Se você quer um produto realmente bom, teste! • Insights para tomada de decisão • Conhecer melhor quem usa(rá) o sistema
- 30. “Anyone can cook” Chef Gusteau
- 31. Mesmo que seja um miojo...
- 32. Ingredientes • Computador • Usuário • Tarefas • Condutor e observador • Bloco de notas
- 33. Modo de preparo • Planejamento • Recrutamento • Realização • Análise de resultados
- 34. Planejamento • Quem vou recrutar? • O que quero descobrir/confirmar? ‣ Quais tarefas testar, para responder esta pergunta? • Onde e quando será o teste? • Como guiar o teste?
- 35. Realização • Não diga o que o usuário deve fazer • Observe reações verbais e gestuais • Deixe o participante confortável • Peça para ele “pensar alto” • Grave a interação e o áudio para análise futura • Um teste deve durar no máximo uma hora • 3 x 5 > 1 x 15
- 36. Referências • Jeff Patton – http://agileproductdesign • Livro Não me faça pensar – Steve Krug
- 37. latitude14.com.br @latitude14
Hinweis der Redaktion
- Boa tarde! Eu sou Fabrício Marchezini, ele é Leandro Alves. Vamos mostrar pra vocês hoje é uma técnica chamada story mapping, que é utilizada para priorização de funcionalidades e planejamento de releases de sistemas, usada principalmente no contexto de desenvolvimento ágil. Depois disso, vamos falar um pouco sobre testes de usabilidade e como vocês podem aplicá-los de forma simplificada durante o desenvolvimento dos produtos de vocês. São duas coisas que não tem relação direta uma com a outra, mas as duas impactam muito na qualidade do produto final do ponto de vista da experiência do usuário.
- Não esquecer de falar quem somos, de onde viemos porque estamos aqui e porque somos fodas.
- Não esquecer de falar quem somos, de onde viemos porque estamos aqui e porque somos fodas.
- Não esquecer de falar quem somos, de onde viemos porque estamos aqui e porque somos fodas.
- Não esquecer de falar quem somos, de onde viemos porque estamos aqui e porque somos fodas.
- Todo mundo conhece essa figura aqui? Quem aqui trabalha ou trabalhou com métodos ágeis? Quem só leu ou ouviu falar? Quem não tem a menor idéia? Ela representa o fluxo de desenvolvimento do SCRUM, que é um método de desenvolvimento de progetos ágil. No Scrum, o desenvolvimento é feito em forma de Sprints, que são ciclos de desenvolvimento com tempo fixo (normalmente, duram de 2 a 4 semanas). Esta figura mostra um sprint completo do Scrum. No Scrum (e em outros métodos ágeis), temos um backlog do produto, que é uma lista de todas as funcionalidades planejadas para entrar no sistema. Cada funcionalidade é representada por um “user story”. Um user storie é uma caracteristica ou funcionalidade do sistema, descrita do ponto de vista do usuário (para quem não conhece um user story, vamos mostrar depois como ele é). Esse backlog é ordenado de acordo com o valor que cada funcionalidade agrega ao produto, de forma que as user stories mais importantes serão desenvolvidas primeiro. Desse backlog, são retiradas as funcionalidades a ser desenvolvidas no próximo sprint. No final desse sprint, temos uma parte do produto funcional, potencialmente pronta. Então, começa-se outro sprint. Costuma-se dizer que o processo de desenvolvimento ágil é iterativo. Realmente, é um ciclo que se repete várias vezes, mas o valor agregado ao produto se dá de forma incremental.
- Todo mundo conhece essa figura aqui? Quem aqui trabalha ou trabalhou com métodos ágeis? Quem só leu ou ouviu falar? Quem não tem a menor idéia? Ela representa o fluxo de desenvolvimento do SCRUM, que é um método de desenvolvimento de progetos ágil. No Scrum, o desenvolvimento é feito em forma de Sprints, que são ciclos de desenvolvimento com tempo fixo (normalmente, duram de 2 a 4 semanas). Esta figura mostra um sprint completo do Scrum. No Scrum (e em outros métodos ágeis), temos um backlog do produto, que é uma lista de todas as funcionalidades planejadas para entrar no sistema. Cada funcionalidade é representada por um “user story”. Um user storie é uma caracteristica ou funcionalidade do sistema, descrita do ponto de vista do usuário (para quem não conhece um user story, vamos mostrar depois como ele é). Esse backlog é ordenado de acordo com o valor que cada funcionalidade agrega ao produto, de forma que as user stories mais importantes serão desenvolvidas primeiro. Desse backlog, são retiradas as funcionalidades a ser desenvolvidas no próximo sprint. No final desse sprint, temos uma parte do produto funcional, potencialmente pronta. Então, começa-se outro sprint. Costuma-se dizer que o processo de desenvolvimento ágil é iterativo. Realmente, é um ciclo que se repete várias vezes, mas o valor agregado ao produto se dá de forma incremental.
- Fazendo um paralelo com a criação de uma obra de arte, a abordagem mostrada é mais semelhante com essa figura. Nela, o artista tem uma visão completa do resultado final e pinta bloquinho por bloquinho da tela. O problema de desenvolvermos produtos assim é que, o risco de se criar um “frankenstein” é muito grande. É o que chamamos de “efeito puxadinho”, em que a cada nova funcionalidade agregada, é necessária uma adaptação na interface. O resultado final não é legal.
- O que a gente sugere é fazer uma pequena adaptação na forma de lidar com o backlog do produto (a lista de funcionalidades que ele terá), de forma a tornar o processo mais próximo à forma que um artista produz uma obra na realidade. No início do processo se tem uma idéia vaga do que se pretende construir, então criamos um esboço, que vai evoluindo em nível de detalhes durante o tempo. Essa abordagem permite que se tenha uma visão geral do produto final e que se faça “correções no percurso” de forma mais fácil.
- O story mapping é uma técnica colaborativa que ajuda a identificar as funcionalidades de maior valor e ordená-las de forma a criar uma estrutura lógica que vai permitir entregar um sistema que seja o mais útil possível, desde o primeiro release, mas mantendo a abordagem iterativa e incremental do desenvolvimento ágil. Essa técnica, criada por um cara chamado Jeff Patton, que vem estudando as formas de aproximar as metodologias ágeis do processo de design centrado no usuário.
- A equipe inteira deve participar. A idéia é que cada membro contribua com o conhecimento e a visão que tem do produto e se chegue num consenso. Cada um entende um aspecto diferente do produto. Designer=interface, usuários. Marketing=necessidades dos usuários. Negócio=retorno de investimento. Desenvolvedor=possibilidades, restrições técnicas, etc...
- Somente citar, iremos explicar detalhadamente quando começar o workshop
- E vocês o que acharam?
- E vocês o que acharam?
- E vocês o que acharam?
- E vocês o que acharam?
- E vocês o que acharam?
- E vocês o que acharam?
- Explicar que o story mapping ajuda a demarcar pontos para testes mais completos com usuários
- Pra quem não conhece o teste de usabilidade É... e acontece assim assim assado
- Tem, também, o teste menos formal
- E vocês o que acharam?
- E vocês o que acharam?
- E vocês o que acharam?
- O legal é que, da mesma forma que qualquer um pode cozinhar, qualquer um pode realizar testes de usabilidade com um pouco de prática. Mas, mesmo sabendo cozinhar, eventualmente você vai a um restaurante. E isso acontece por uma série de motivos. Da mesma forma, em alguns casos, ainda é recomendado que um especialista externo realize avaliação e pesquisa no seu produto.
- Ninguém morre de fome se tem um miojo por perto Qualquer teste é melhor que nenhum teste Teste o máximo possível e teste após modificar o produto Que começa a cozinhar, inicia fazendo “comida ruim”
- Alguém do público-alvo é Aproveitar o contato com o usuário para buscar mais informações sobre comportamento
- Alguém do público-alvo é Aproveitar o contato com o usuário para buscar mais informações sobre comportamento
- Alguém do público-alvo é Aproveitar o contato com o usuário para buscar mais informações sobre comportamento
- Alguém do público-alvo é Aproveitar o contato com o usuário para buscar mais informações sobre comportamento
- Alguém do público-alvo é ideal, mas não é obrigatório. Perfil similar viabiliza mais o projeto Aproveitar o contato com o usuário para buscar mais informações sobre comportamento
- Alguém do público-alvo é ideal, mas não é obrigatório. Perfil similar viabiliza mais o projeto Aproveitar o contato com o usuário para buscar mais informações sobre comportamento
- Alguém do público-alvo é ideal, mas não é obrigatório. Perfil similar viabiliza mais o projeto Aproveitar o contato com o usuário para buscar mais informações sobre comportamento
- Alguém do público-alvo é ideal, mas não é obrigatório. Perfil similar viabiliza mais o projeto Aproveitar o contato com o usuário para buscar mais informações sobre comportamento
- Alguém do público-alvo é ideal, mas não é obrigatório. Perfil similar viabiliza mais o projeto Aproveitar o contato com o usuário para buscar mais informações sobre comportamento
- Alguém do público-alvo é ideal, mas não é obrigatório. Perfil similar viabiliza mais o projeto Aproveitar o contato com o usuário para buscar mais informações sobre comportamento
- Alguém do público-alvo é ideal, mas não é obrigatório. Perfil similar viabiliza mais o projeto Aproveitar o contato com o usuário para buscar mais informações sobre comportamento
- Alguém do público-alvo é ideal, mas não é obrigatório. Perfil similar viabiliza mais o projeto Aproveitar o contato com o usuário para buscar mais informações sobre comportamento
- Alguém do público-alvo é ideal, mas não é obrigatório. Perfil similar viabiliza mais o projeto Aproveitar o contato com o usuário para buscar mais informações sobre comportamento
- Alguém do público-alvo é ideal, mas não é obrigatório. Perfil similar viabiliza mais o projeto Aproveitar o contato com o usuário para buscar mais informações sobre comportamento
- Alguém do público-alvo é ideal, mas não é obrigatório. Perfil similar viabiliza mais o projeto Aproveitar o contato com o usuário para buscar mais informações sobre comportamento
- Alguém do público-alvo é ideal, mas não é obrigatório. Perfil similar viabiliza mais o projeto Aproveitar o contato com o usuário para buscar mais informações sobre comportamento
- No nosso site vocês vão encontrar nossos dados de contato. Nosso twitter é @latitude14. Se quiserem conversar mais conosco sobre esses assuntos ou qualquer outro relacionado a experiência do usuário e design de aplicações e produtos interativos, estamos aqui na Campus Party até hoje à noite.