Embed Size (px)
Citation preview
O Porquê?
Como surgiu: Não sei você, mas eu preciso dar visibilidade dos meus
projetos aos meus gestores e clientes, independente se utilizar ágil ou não.
E depois de muita pesquisa e várias tentativas, consegui consolidar e
montar este mapa para apresentação e acompanhamento do projeto ágil.
Mas e o porquê mesmo?
Eu sempre tento antes de te passar qualquer material é falar um pouco do
benefício que este material ou ferramenta vai te dar.
1
Você deve estar imaginando, que esta é só mais uma ferramenta que eu
não vou utilizar pra nada.
Ai se você vai utilizar ou não, isto só vai depender de você.
Mas eu garanto que este mapa vai dar a visibilidade ideal para o seu
projeto.
Este mapa é uma ferramenta de planejamento e gestão da execução de
projetos ágeis com SCRUM.
Mas também pode ser utilizado para outros Frameworks.
Ele vai lhe proporcionar uma gestão a vista de todo o projeto
Aumentando o engajamento de todo o time no desenvolvimento do projeto.
2
O Mapa
Calma que eu vou explicar cada “caixinha” acima.
E no final tem um presente para você.
(pode ficar tranquilo que não é desconto em nada, não estou vendendo nada...rsrsr)
3
PERSONA
O que você ganha tendo conhecimento de suas personas?
● Você será mais assertivo na comunicação:
Cada pessoa gosta de receber a informação de uma maneira.
Sabendo você qual o perfil do seu público, você poderá adaptar sua
linguagem e até o seus textos.
Por exemplo, temos pessoas que são objetivas e direta ao ponto e
temos pessoas detalhistas.
4
● Cria empatia com a pessoa:
Você passa a entender melhor porque a pessoa é do jeito que é.
● Você consegue gerar valor de forma mais rápido à sua persona:
Todo contato com sua persona é uma oportunidade para gerar valor a
ela.
Mesmo que seja apenas na fase de planejamento de um projeto, você
já consegue gerar valor a sua persona.
A partir do momento que você identifica suas dores e o que ela
considera como útil ou valioso.
Você consegue identificar suas principais dores.
Com isso, você consegue atender o que mais “dói”, ou sua principal
necessidade, logo no início do projeto.
● Desenvolve confiança em você:
Acredito que este seja um dos principais benefícios que você terá.
Pois se você consegue desenvolver uma confiança mútua entre você
e o seu cliente ou a sua persona, se torna muito mais simples a
comunicação.
Caso você precise negociar prazos com a sua persona, isto será mais
simples, pois a sua persona confia em você.
5
Definição de persona
A 1º coisa que você vai fazer é
definir a sua persona.
Aqui vou te dar uma breve
explicação do que é persona,
caso você não conheça.
“Caso você queira saber mais detalhes das informações de precisa ter
na criação de uma persona, no final terá alguns links de artigos”
A persona nada mais é do que a representação do seu cliente ideal.
Ou a pessoa para qual você está desenvolvendo o projeto.
Porém, as personas de um projeto não são apenas o seu cliente que está
pagando por ele.
Mas também as pessoas que você se relaciona durante a vida deste
projeto.
6
Pois estas pessoas também farão parte do sucesso ou fracasso do projeto.
Em uma boa persona, você precisa encontrar:
● Características comportamentais;
● Dados pessoais, o que ela gosta ou deixa de gostar;
● Suas motivações;
● Desafios;
● Preocupações;
● Suas dores;
● O que motiva esta pessoa;
● A rotina diária da pessoa.
Pode ter certeza que estas informações irão te ajudar a encontrar soluções
que as pessoas realmente irão se apaixonar.
7
Como encontrar suas personas?
Em todo tipo de projeto nós temos
várias personas envolvidas, porém
vou focar na minha especialidade
que são projetos de software.
Em um projeto de software, você
poderá ter as seguintes personas:
1. Usuário final da solução (sua principal persona).
2. O gestor ou gerente do usuário final (sua segunda principal persona).
3. O proprietário do estabelecimento (quando a solução é para alguma
empresa).
4. A pessoa que é o TI do seu cliente.
5. O patrocinador do projeto (quem está pagando pelo desenvolvimento)
(sua terceira principal persona).
6. Seu coordenador ou gerente, caso você trabalhe em uma empresa de
software.
7. O desenvolvedor que vai atuar no projeto.
8. O analista de teste que vai testar o projeto.
8
9. A pessoa que vai implantar o software (caso necessite de
implantação).
10.Quem vai dar o suporte.
11. A pessoa que vai vender.
12. Quem vai fazer o marketing do sistema.
Ufa, se fosse só para falar das características destas pessoas, já daria um
livro.
“Mas como não é o foco deste ebook, depois faço para você um
artigo com as características de cada persona.”
São muitas pessoas envolvidas em um projeto de software.
No mapa das histórias, você não precisa colocar todas as personas de
forma detalhada.
Mas é interessante que você conheça todas elas.
Mas no mapa precisa estar contido pelo menos as 3 principais:
● O usuário final.
● O gestor do usuário final.
● O patrocinador do projeto.
Com isto, espero ter deixado claro para você o quão importante é conhecer
bem as pessoas que interagimos durante toda a vida útil de um projeto.
9
NECESSIDADES DA PERSONA
Muito cuidado aqui.
A necessidade, não é a descrição
da funcionalidade que a pessoa
está pedindo.
Mas sim, o porquê de sua
necessidade, o que o motivou a te
procurar.
Vamos a alguns exemplos, para te ajudar a entender melhor:
Exemplo:
- A pessoa ou a empresa te procura e pede para você criar um site para
ela anunciar seus serviços ou produtos.
- Logo você pensa em formas de criar este site e quanto vai cobrar por
ele, certo.
- Errado, você precisa pensar o porque a pessoa está pedindo a
criação de um site?
10
- Provavelmente será porque ela quer aumentar as suas vendas, quer
novos clientes.
- E apenas a criação do site vai garantir que isto aconteça?
- Acredito que não.
- Então se você apenas criar o site para o seu cliente e entregar o
projeto, ele vai ficar satisfeito? Ele vai aumentar suas vendas?
- Provavelmente não. E ele não te procuraria mais.
- Então, se você se preocupar com o porquê da necessidade dele?
- Você deixará o cliente mais satisfeito.
- Então, voltando ao nosso exemplo, se você entender que o que ele
precisa é aumentar as suas vendas.
- Você pode propor a criação de páginas em redes sociais e
investimento em marketing digital, o que pode dar um retorno mais
rápido ao seu cliente.
- Ou se ele vender produtos, você pode propor a integração com
grandes marketplaces, pois eles já fazem o trabalho de marketing e
possuem um grande tráfego.
A descrição da necessidade precisa conter os seguintes elementos:
● O porquê de sua necessidade.
● O que o motivou a te procurar para desenvolver uma solução para
ele.
11
● Qual problema ele está tendo atualmente.
● Qual o problema ele pretende resolver.
De forma objetiva a descrição da necessidade precisa trazer os elementos
que justificam o investimento no projeto.
Ela precisa ser objetiva, de tal forma que qualquer pessoa que leia consiga
identificar o porquê da existência do projeto.
Está vendo que captar a necessidade do usuário não é uma tarefa simples.
Requer paciência, cautela e principalmente senso crítico, pois você vai
precisar questionar muito o seu cliente, mas sem ofender.
Então para te ajudar a identificar a causa raiz dos problemas dos seus
clientes, temos duas ferramentas:
● A técnica dos 5 porquês.
● Diagrama de Ishikawa.
Abaixo eu mostro como utilizá-las, em seus projetos de software de forma
ágil.
12
Técnica dos 5 porquês
Esta técnica foi criada dentro do
modelo Toyota de qualidade
total, pelo arquiteto Taiichi Ohno
em 1950.
E serve para quase tudo na vida,
mas vou trazer uma abordagem
para dentro do contexto de
desenvolvimento de software.
Mas porque utilizar 5 porquês?
Para te ajudar a identificar a causa de um determinado problema.
É natural da raça humana, sempre que tem um problema, buscar um
culpado ao invés de discutir o problema e procurar a causa raiz.
Os 5 porquês podem virar 6, 7 ou até 2 ou 3. Não existe regra dizendo que
tem que ser 5, mas conforme estudo realizado pela Toyota, identificou-se
que 5 é uma média para se chegar a causa raiz.
Pois normalmente se diz:
13
● No 1º porquê, você vai encontrar o sintoma do problema de sua
persona.
● No 2º porquê, você vai conseguir extrair uma desculpa.
● No 3º porquê, a pessoa vai procurar um culpado para o problema.
● No 4º porque, é onde vai começar a falar da causa.
● E no 5º porquê, geralmente é onde você vai conseguir extrair a causa
raiz.
Isto não obrigatoriamente seguirá este script padrão.
Mas o importante desta técnica, é quando você estiver conversando com
alguma persona que está lhe pedindo algo.
Você tentar identificar se o que ela está falando é realmente a causa raiz ou
uma desculpa ou já está tentando te falar a solução do que você tem que
fazer para resolver um problema dela.
Mas cuidado ao utilizar esta técnica, para não parecer aquela pessoa chata
que nem “criança”.
Procure formular suas perguntas de forma que você não fique apenas
perguntando, “mas porquê….”, “mas porquê…”.
Esta é uma técnica muito útil, que você consegue colocar em prática a
qualquer momento.
14
Sugiro que você comece o quanto antes, e quanto mais você treina, melhor
você vai ficar.
Esta técnica te ajuda a encontrar o real problema do seu usuário, com isso
você consegue de destacar da maioria.
Pois a maioria faz apenas o que o usuário está pedindo, e nem sempre o
que ele pede vai resolver a causa raiz de seu problema.
Diagrama de Ishikawa
15
Esta ferramenta é indicada para identificar as possíveis causas de um
determinado problema.
Ela é similar a técnica dos 5 porquês, no entanto este diagrama é mais
estruturado e bem formatado.
Você pode utilizar esta técnica para apresentar para o seu cliente ou seus
gestores, o como você conseguiu chegar na causa raiz de um problema.
Este diagrama também é conhecido como:
- Espinha de peixe;
- Diagrama dos 6M;
- Diagrama de causa e efeito.
Independente do nome, o importante é você saber adaptá-lo à sua
realidade.
Como construir um diagrama de Ishikawa?
1º. Defina claramente o problema que você quer resolver. Aqui é a dor de
seu cliente, ou também conhecido como o sintoma.
2º. Faça um levantamento de todas as possíveis causas, aqui você pode até
utilizar a técnica dos 5 porquês.
3º. Agora procure as causas com base em 6 perspectivas diferentes,
conforme abaixo:
16
1. Método.
2. Máquina.
3. Medida.
4. Meio ambiente.
5. Material.
6. Mão de obra.
● Método:
As causas relacionadas ao método, estão diretamente relacionadas à forma
como a atividade está sendo realizada.
● Máquina e equipamentos:
Procure identificar como as máquinas ou equipamentos que são utilizados
no processo interferem ou influência no problema.
● Medida:
Aqui você vai identificar as métricas que são utilizadas para medir o
desempenho das pessoas envolvidas, e quais delas podem influenciar no
problema.
17
Tente encontrar também as métricas de vaidade, que são aquelas que não
são cobradas pelo gestor, mas que muitas das vezes o colaborador adota
para obter um benefício próprio.
● Meio ambiente:
Procure identificar como o meio em que a atividade está sendo
desenvolvida influência sobre o problema.
● Material:
Quais os materiais utilizados e como eles podem influenciar sobre o
problema.
Cuidado para não confundir materiais com equipamento.
Materiais estão geralmente ligados a matéria prima utilizada na produção de
um determinado produto.
● Mão de obra ou pessoas:
Nesta seção você vai identificar as pessoas que estão diretamente ou
indiretamente envolvidas no problema e o seu respectivo papel.
Bom, estas foram duas técnicas, que eu gosto, que irão te ajudar a
encontrar a real necessidade do usuário.
18
INICIATIVA / PROJETO
Aqui você vai colocar uma breve descrição dos recursos e funcionalidades
que pretende entregar para atender a necessidades de sua persona.
Ou seja, de forma objetiva, é descrever o que o projeto irá entregar.
Aqui você não precisa chegar no detalhe das funcionalidades, nem as
opções de tela.
Aqui a sua persona precisa identificar se o problema dela será realmente
resolvido.
19
Para que ele possa saber no detalhe como seu problema será resolvido,
nós teremos os épicos e as histórias para isto.
Então vamos a alguns exemplos
1. O cliente está com problema de baixa lucratividade e já fez a devida
análise e descobriu que precisa aumentar suas vendas, mas não tem
condições de contratar vendedores.
Iniciativa: Desenvolver solução de integração para que os produtos
possam ser vendidos através de marketplaces.
De forma bem objetiva, você consegue saber exatamente o que será
feito para resolver o problema do cliente.
É muito importante esta definição da iniciativa para que o seu time técnico,
quando estiver pensando nas funcionalidades e recursos do sistema, saiba
exatamente qual a expectativa do cliente.
O envolvimento do time técnico na criação da iniciativa, também é muito
importante, para que o time se sinta engajado com a solução que será
desenvolvida.
O engajamento do time, faz toda a diferença em um projeto.
20
ÉPICOS
Os Épicos nada mais são do que histórias de usuário que ainda não foram
refinadas, geralmente são grandes demais para serem consideradas uma
história.
Ou seja, a história é a menor unidade a ser desenvolvida em um projeto
SCRUM.
O Épico pode duas ou mais histórias.
O SCRUM não determina quantas histórias podem conter em um épico.
21
No entanto ele deixa claro que um Épico precisa representar um item
grande que ainda precisa ser refinado e quebrado em duas ou mais
histórias.
Exemplo:
1. Utilizando aquele nosso exemplo anterior para venda de produtos no
marketplace.
Os Épicos podem ser:
1. Ferramenta para enviar os produtos que serão vendidos
no marketplace da Amazon.
2. Ferramenta para definir quais produtos serão vendidos no
marketplace.
3. Ferramenta para processamento dos pedidos realizados
no marketplace.
Bom, estes foram alguns exemplos hipotéticos.
Em um épico precisa conter pelo menos dois elementos:
● Nome.
● Descrição.
No Épico você já pode colocar elementos um pouco mais detalhados do o
que será desenvolvido para atender a sua persona.
Não existe segredo para criação de Épicos, é simples assim mesmo.
22
HISTÓRIAS DE USUÁRIO
Também muito conhecidas
pelo termo em Inglês User
Story.
As histórias de Usuário são
geralmente escritas pelo
Dono do Produto.
São projetadas para assegurar que os requisitos do cliente sejam
claramente descritos.
E possam ser totalmente compreendidos por todos os stakeholders,
principalmente pelo time técnico.
É na criação das histórias que você vai colocar aquele famoso jargão “dividir
para conquistar” em prática.
Uma história de usuário deve estar claro os 3 elementos abaixo:
1. Quem.
O “Quem” da história, você vai colocar os dados do seu usuário final,
que irá utilizar o produto.
23
Isto servirá para criar uma conexão entre o problema que a história se
propõe a resolver e o seu time de desenvolvimento.
Você vai citar informações básicas do usuário pertinentes ao assunto,
tais como: o nome dele, sua função dentro da empresa.
2. O que.
Você vai colocar as funcionalidades e recursos desejados por este
usuário, que esta história se propõe a desenvolver
3. Porquê.
É a alma da história.
É o problema de sua persona que você se propõe a resolver.
É o que vai vender a sua estória para o time e para os stakeholders.
Então, o porque precisa estar muito claro.
Nele é bom você colocar o problema que o usuário está tendo hoje e
o seu benefício com esta ferramenta ou produto.
Exemplo:
1. (Quem) Eu, Max, gerente de vendas da empresa X, (O que)
preciso poder escolher os produtos que podem ser enviados
24
para venda no marketplace, (Porque) pois precisamos aumentar
as vendas de nossa empresa e não temos condições de
aumentar a equipe de vendas.
Critérios de aceitação
Uma história de usuário precisa conter os critérios de aceitação.
Os critérios de aceitação, é onde o dono de produto vai colocar o que deve
ser feito, ou o que ele espera do produto para considerar esta estória como
pronta.
Fique atento, pois “o que” é diferente do “como”, o como o produto será
criado ou será desenvolvido, é de responsabilidade do time central.
Aqui o dono de produto vai colocar as regras de negócio que esta história
precisa atender.
Para que ele considere a história como pronta.
O dono de produto só define os detalhes técnicos que são pertinentes para
atender ao negócio.
Por exemplo:
1. Critérios de aceitação:
● Deve ser apresentada uma lista para que o gerente
escolha qual produto quer enviar para o marketplace.
● Deve ter opção para informar o valor do produto para
venda.
25
● A integração deve ser feita via webservice. (aqui nós
temos um requisito técnico, pois neste exemplo, a
comunicação só funciona desta forma, então não adianta
o time técnico querer fazer algo em .TXT ou API, que não
vai atender).
Espero que o exemplo tenha ajudado.
Você viu que detalhes técnicos, são apenas os que são realmente
imprescindíveis para o funcionamento do negócio.
Na ferramenta, você irá colocar apenas as informações:
● Título da história
● Uma breve descrição do “o que” da história, para que qualquer
pessoa possa ver o mapa e identificar as etapas do projeto.
● E também o sprint previsto, se você quiser.
● Você também pode colocar a data prevista de entrega, que deve ser
a data da conclusão da sprint.
26
CONCLUSÃO Espero, de verdade mesmo, que tenha lhe atendido as expectativas e lhe
agregado algum valor com este conteúdo.
Pois todos meus conteúdos são criados pensando em você, para que de
alguma forma possa estar te agregando alguma qualificação.
Este material você pode colocar em prática hoje mesmo.
Não espere amanhã para colocar em prática, comece hoje, não perca
tempo.
27
E O PRESENTE? Achou que eu tinha esquecido?
Segue o link para download do arquivo em .PDF em formato A1.
E o link para download em formato A4.
Sugiro que você trabalhe a criação deste mapa juntamente com outras
pessoas do seu time.
Caso o arquivo não esteja mais disponível para download, me envie um
email que eu te mando o arquivo.
Muito obrigado!
Celso Mendes
28
