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”

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)

Roube como um Analista de Negócios (Como assim?)

Outro dia, finalizei o microbook “Roube como um Artista“, e achei genial a forma com que o processo criativo se forma.

download

No livro, Austin Kleon demonstra o processo criativo como uma coleção de experiências e referências passadas, bem como um pouco de confiança em si mesmo para explorar e tentar o novo.

Mas daí você pode me perguntar. Priscila, o que isso tem a ver com Análise de Negócios?

Gosto de pensar que a Análise de Negócios em si é um processo criativo, onde compartilhamos nossa experiência e nossos projetos passados, na esperança de melhorar empresas e promover transformação.

E como “Roubar como um artista” na Análise de Negócios?

  1. Conheça as técnicas de levantamento de requisitos, de mapeamento de processos e de conhecimento de negócio;
  2. Tente trabalhar em projetos diferentes em termos de negócio. Entenda de como os negócios se formam, não seja um especialista de uma única indústria, por exemplo: Analista de Negócios especialista em Bancos.
  3. Saia da sua zona de conforto e conheça analistas que fizeram coisas diferentes, pessoas que trabalham em áreas diferentes. Entenda como elas trabalham e se interesse genuinamente pelos processos e pelos motivadores das pessoas.
  4. Colecione estas experiências, mas também viaje, faça exercícios e compartilhe sua visão com as pessoas.

Tenha em mente que, quanto mais você experimentar, mais vivências você terá e mais formas de ajudar seus clientes você terá.

Organize. (3)

Você quer uma documentação que atenda o usuário e o desenvolvedor?

Muito do que já ouvi em projetos de software é que a documentação precisa ser abrangente, precisa atender tanto ao usuário como ao desenvolvedor. Alguém mais já passou por isso?

Frequentemente é delegado ao Analista (de Negócios, Requisitos ou Processos) que execute esta função de forma que o documento agrade a todos.

Continue lendo “Você quer uma documentação que atenda o usuário e o desenvolvedor?”

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”

Caí de paraquedas num projeto e sou responsável por requisitos, e agora?

Publicado originalmente em 23 de março de 2017, no Linkedin

Outro dia estava eu ali num fórum, quando uma pessoa entrou e perguntou: A partir de amanhã serei analista de requisitos, não sei por onde começo!

Parece incomum mas acontece com frequência: Quantas vezes a gente já se deparou com um desafio que não sabe nem como começar? Que tipo de ajuda você espera quando isso acontece? No fórum vi muita gente recomendando leituras. Bom, leituras são imprescindíveis para o bom conhecimento de qualquer profissional. Mas e quando você está na fogueira? Como faz? Aqui está um passo-a-passo simples de como sair do outro lado num mar de problemas. Continue lendo “Caí de paraquedas num projeto e sou responsável por requisitos, e agora?”

Análise de Problemas à distância: É possível?

  • Publicado originalmente em 2 de fevereiro de 2017, no Linkedin

Um dos maiores problemas que temos atualmente é a comunicação. Volta-e-meia, acontece que alguém diz aquela frase: “Mas não era exatamente isso que eu estava imaginando!”. Se você exerce análise de negócios em algum âmbito, certamente já se deparou com isso.

E é incrível, que dia após dia, apesar de nos depararmos com este tipo de problema de comunicação, algumas empresas pensarem que o levantamento de requisitos – seja por brainstorm, entrevistas, mapeamento de processos, ou o detalhamento do problema, possa ser feito por telefone ou por telepresença.

O diagrama abaixo, de Alistair Cockburn, um autor também muito recomendado, detalha a riqueza da comunicação por cada via:

O gráfico indica que face a face, num quadro branco (desenhando!), é a melhor forma de ter entendimento de todas as partes. Isso responde nossa pergunta?

Utilizar telefone para levantamento de requisitos, além de inefetivo, pode causar sérios prejuízos ao seu projeto. É claro que em projetos onde a distância fisica impera, pode não haver outra solução. Neste caso, o melhor a ser feito é utilizar o maior número de recursos visuais possível, o que pode onerar a quantidade de documentação.

E você, o que acha? É possível fazer análise por telefone?

Elicitação de Requisitos: De quem é a responsabilidade?

*Originalmente publicado em  1 de setembro de 2016 no Linkedin.

As atividades de elicitação são definidas, pelo BABOK, como: trazer à tona, descobrir requerimentos ou recebê-los diretamente dos stakeholders ou de outras fontes, e é a principal atividade de um analista de negócios no que tange a descoberta de necessidades dos stakeholders e formas de desenhar um software ou projeto.

As atividades de elicitação são definidas pelos seguintes processos:

  • Preparar;
  • Conduzir;
  • Validar (confirmar);
  • Comunicar;
  • Gerenciar colaboração.

E a linha fica tênue entre as responsabilidades do gerente de projeto e do analista de negócios, pois em muitos projetos o planejamento, a abordagem, a agenda e o tempo necessário para a elicitação e escrita dos requerimentos fica a cargo do gerente de projetos. Mas o que diz o BABOK?

O BABOK diz que as atividades de preparação da elicitação envolvem a abordagem a ser utilizada pelo analista, o levantamento dos stakeholders,  e cada perfil, incluindo também o nível de engajamento no projeto, localização, logística, etc. Também define quais serão os entregáveis e delimita expectativas entre stakeholders e o analista (ou time de analistas).

A condução das atividades também fica a cargo do analista. Aqui, a técnica pode ser variada e pode envolver os stakeholders ou não. Por exemplo, as principais técnicas de elicitação utilizadas são: Entrevistas e Brainstorming. O analista pode utilizar de experiências, pesquisas ou Provas de Conceito (POC) para elicitar uma necessidade sem a participação direta dos stakeholders, mas validada por eles. Afinal, todas as atividades devem ser validadas por todos os stakeholders.

O plano de comunicação dos requisitos também deve ser responsabilidade do analista, definindo por exemplo qual será o modelo de comunicação, e quando ou como esta informação deve ser apresentada.

Como podemos ver, o BABOK e o BACCM (Business Analysis Core Concept Model) dá autonomia ainda maior ao analista de negócio na condução de atividades de análise de negócio, ficando a cargo do analista todo o planejamento e execução das atividades.

Neste cenário, o gerente de projeto atua como par do BA e facilitador, garantindo que todos os recursos estão disponíveis de acordo com o planejamento e abordagem do analista.