Personas: Chegando ao cerne do negócio com um mapa de empatia

TIPS FROMSUCCESSFULPEOPLE.

Em contextos voltados ao sucesso do cliente, uma das abordagens mais populares para mapear requisitos de cliente é o Mapa de Empatia, para mapear as personas.

Mas o que é isso?

Personas são personagens fictícios criados para representar os diferentes tipos de usuário dentro de um alvo demográfico, atitude e/ou comportamento definido que poderia utilizar um site, uma marca ou produto de um modo similar. Personas são uma ferramenta ou método de segmentação de mercado. O termo persona é usado amplamente em aplicações online e tecnológicas, bem como em publicidade, onde outros termos como retratos de pena também podem ser usados. (Wikipédia)

Tá, entendi. Então vamos criar personagens fictícios para representar usuários? Sim!!! E por que se faz isso?

Continue lendo “Personas: Chegando ao cerne do negócio com um mapa de empatia”

Sobre o PMBOK Ágil (Por Jorge Audy)

Fiz vários posts nas redes desde que as primeiras resenhas sobre o PMBOK 6ª edição começaram a sair, mas não aqui no blog para registro. Não é um passo a frente, é apenas o resgate de um gap de 30 anos, desde o mítico artigo de Takeushi e Nonaka em 1986 com “The New New […]

via PMI Agile Practice Guide – boas práticas ágeis há 30 anos — Jorge Horácio “Kotick” Audy

Utilizando Canvas para entender melhor seu produto

Dando uma pausa..pngJá é uma prática de mercado utilizar canvas para obtenção de dados para o que quer que seja, já vi scrum team canvas, machine learning canvas… Tem Canvas para todos os gostos. O canvas acabou caindo no gosto dos analistas, product owners e demais profissionais do mercado porque facilita o entendimento de todas as partes e direciona um brainstorm, por exemplo.

Uma das estratégias comuns para entendimento do produto (e da visão da empresa), são os Business Model Canvas e o Product Vision Board.  Vou focar, hoje, nestes dois canvas.

Continue lendo “Utilizando Canvas para entender melhor seu produto”

PO Proxy – PO Linha

 

BusinessAnalystAsProxyProductOwner

“O Product Owner é aquele que determina as metas e conduz o time na entrega constante de valor” (Cohn, 2009, Succeeding with Agile)

Recentemente assumi um projeto (iniciado a 3 meses por um fornecedor em metodologia tradicional), e projeto apresentava a cada status report a dependência/premissa de ter declarado o PRODUCT OWNER, mas neste caso leia-se dono do projeto, a pessoa que aprova ou não as entregas.

Para o fornecedor essa pessoa deveria ser alguém da área de negócios, e por isto foi apontado um gerente de uma área de negocio, que além de todas as suas atividades diárias ele deveria também tocar as atividades deste projeto (o profissional atribuído a este papel deveria estudar o produto, testar conceitos e construir o produto).

Scrum Guide , uma das referências do assunto, descreve o PO como:

“É o responsável por maximizar o valor do produto e do trabalho da equipe de Desenvolvimento. Como isso é feito pode variar amplamente através das organizações, Times Scrum e indivíduos. O Product Owner é a única pessoa responsável por gerenciar o Backlog do Produto. (…)

Sendo o “Product Owner uma pessoa e não um comitê. O Product Owner pode representar o desejo de um comitê no Backlog do Produto, mas aqueles que quiserem uma alteração nas prioridades dos itens de Backlog devem convencer o Product Owner.”

Cerejinha do bolo, este projeto possui duas áreas de negócios envolvidas (Limão e Laranja e por este motivo não será possível UM Product Owner.

Qual a probabilidade destes DOIS gerentes quererem assumir mais uma função, com uma parte da atividade que eles desconhecem, de um projeto já iniciado e que ele não tinha conhecimento do escopo que foi fechado?

O PO neste cenário é o que chamamos de “cliente”, ele tem noção do que o produto precisa solucionar, mas não tem conhecimentos técnicos para realizar testes, cuidar da evolução do produto e dar diretrizes para o time (pensando na questão técnica), principalmente, sendo dois clientes com objetivos distintos dentro do produto.

Quando me coloquei a par do projeto sugeri trazer uma “nova” função/papel para o projeto, um PO LINHA (tem quem conheça essa função como PO Proxy), essa pessoa tem o perfil de um analista de negócios/requisitos que prepara todo o material (escreve user stories (traduz as necessidades do cliente – E ELE É TIME!), deixa as estórias em critério de ready para inicio da Sprint, declara os critérios de aceite das histórias, faz a ponte com o time) tudo isto em conjunto com os Product Owners do projeto, neste caso os gerentes das áreas de negócio.

Esse caso que estou contanto é recente e tem 10 dias que se iniciaram as atividades e venho contar aqui as evoluções de 2 semanas:

                – O Product Owner consegue tocar todas as suas atividades diárias e o projeto não é considerado um peso (declaração do próprio PO)

                – O PO linha já apresentou as regras de negócio para a primeira Sprint para que o Product Owner valide e dê o seu de acordo (DOR/DOD) e já estamos trabalhando nas histórias de 2 Sprints a frente.

Organize. (3)

4 Livros sobre AN e Scrum que vão revolucionar seu dia-a-dia

Volta e meia venho aqui e posto a capinha de um livro. Hoje resolvi compilar uma série de títulos que acho relevantes para a área de negócios, requisitos e cultura ágil.

Vamos ao primeiro deles:

Apesar de Casos de Uso estarem fora de moda, Alistair Cockburn explora neste livro vários níveis de abstração em requisitos. Se você trabalha com requisitos, seja em times ágeis ou times tradicionais, este livro com certeza é uma boa pedida.

Jeff Sutherland, um dos criadores do Scrum, ensina como usar Scrum pra fazer qualquer coisa. Ele até me inspirou a escrever este artigo.

No livro Gamestorming, existem diversas dinâmicas para reuniões, que podem transformá-las em verdadeiros Games. Com objetivo definido e tempo restrito, a produtividade cresce! Vale a pena ter como livro de referências.

E por último, mas não menos importante:

O BABOK contém importantes referências sobre o mundo da análise de negócios e também requisitos. Vale a leitura completa e depois ter como livro de referência.

E você, tem algum livro pra acrescentar nessa lista? Vamos dividir!

 

curte-compartilha

Uma forma eficiente de escrever user stories

Em outro artigo, escrevi sobre o framework para requisitos ágeis. De fato, ele não existe. Existem boas práticas, como o INVEST e também sempre consultar o time a respeito da abordagem da documentação.

Aliás, a abordagem do analista de negócios é uma boa prática segundo o BABOK.

Tá vendo? Ali, 3.1: Plan Business Analysis Approach. É a forma como você vai conduzir as atividades de análise de negócio. Fechar com seu time o que ele precisa para desenvolver o produto passa pelo planejamento da abordagem do PO ou Analista, e também é refinado através de groomings, o que significa que a abordagem pode mudar de acordo com novos aprendizados.

Uma forma de ser assertivo na escrita de uma User Story é respeitar as 7 dimensões do produto: Continue lendo “Uma forma eficiente de escrever user stories”