Como acompanhar o ROI?

Depois de falar um pouco sobre Métricas e Retorno sobre o Investimento, vamos falar um pouquinho mais sobre como acompanhar o ROI de um produto ou serviço. Pra isso, vou trazer aqui pro palco, ninguém menos do que Dave McClure pra trazer as Métricas do Pirata.

Então, o que são as Métricas do Pirata? São elas que medem o comportamento do seu cliente durante o Ciclo de Vida dele em contato com seu produto. Como assim?

Continue lendo “Como acompanhar o ROI?”

Problemas e Oportunidades

No dia-a-dia de quem trabalha com produto, é frequente a pergunta: “Mas qual problema você está resolvendo?” e essa simples pergunta pode confundir o transeunte que acaba de chegar no meio.

O problema que você está resolvendo tem muito a ver com a hipótese que você está trabalhando.

MAS PRI DO CÉU SÓ COMPLICA! ISSO QUE EU TÔ TRABALHANDO NÃO É HIPÓTESE, É UMA DEMANDA REAL!!!!!111

Disse o PO transeunte…

Sobre hipóteses:

Toda iniciativa começa com uma hipótese. E a premissa de toda iniciativa é:

Este produto pode/deve ser construído? Qual o resultado de valor esperado desta iniciativa?

Quantas vezes você já viu um produto no mercado que não fazia muito sentido? Quantas vezes você viu uma demanda sendo atendida para um “total de zero pessoas”?

Uma hipótese abraça o conceito de que toda demanda merece um olhar atento e precisa resolver um problema. Portanto, toda iniciativa carrega em si o fato de que são apenas apostas, suposições de que algo vai dar certo.

MAS DAÍ PRI, ENTÃO A GENTE PODE SAIR TESTANDO?

Nossa missão aqui é reduzir o risco dessa hipótese. Mas como?

Sabendo qual problema estamos resolvendo.

A iniciativa é composta de três conceitos:

Output > Outcome > Impact

Onde output é a saída do seu produto, outcome são as métricas operacionais do seu produto, e impact são os resultados para o negócio.

Por exemplo

Output: Entreguei uma nova área de ofertas

Outcome: Rendeu 10000 visualizações e 1000 cliques no primeiro mês de vida

Impact: Ajudou a monetizar 1000 clientes no primeiro mês, trazendo R$ 5000,00 de incremento de faturamento.

Declarando em palavras esta hipótese, vou deixar aqui a colinha:

Nós acreditamos que será alcançado este

[outcome de negócio]

se [este usuário]

conseguir com sucesso [seu outcome de usuário]

com [esta funcionalidade].


Saberemos que isto é verdade se observarmos este feedback:

1) qualitativo e/ou

2) quantitativo e/ou

3) alteração em algum indicador/KPI.

Então, independente se um problema (dor já existente) ou oportunidade (resolvendo um problema futuro para obter algum resultado), as hipóteses nivelam esse conceito para que possamos acompanhá-las da mesma forma.

Porque ter colaboradores motivados deveria ser prioridade na sua empresa

Mas pera, Motivação tem a ver com Análise de Negócios? Tem sim senhor! Tudo o que tem a ver com a estratégia da empresa e formas de aumentar o ROI tem a ver com Análise de Negócio e são assuntos que devem ser tratados com prioridade na empresa.

Primeiro, eu queria que você visitasse o link aqui: Motivação pode aumentar produtividade do funcionário em até 50%

Uma empresa com colaboradores motivados tem aumento de produtividade,  reduz  a rotatividade, e tudo isso pode representar redução de custos para a empresa, e claro, associados a outras estratégias no negócio, podem levar a um aumento do ROI.

Mas eu, gestor, sou responsável pela motivação das pessoas? A resposta é: Não. Mas você pode tomar ações que podem incentivar que as pessoas se motivem. Por exemplo, temos o Jogo de Moving Motivators, criado pelo Junger Appelo, da Management 3.0.

O jogo normalmente é aplicado presencialmente, mas montei essa apresentação para que possa ser feito à distância:

Se você quiser imprimir as cartas, elas podem ser encontradas aqui:

Moving Motivators Download

Mais informações sobre Moving Motivators? Você encontra aqui:

Prática- Moving Motivators

Organize. (3)

 

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)

Comunicação Não-Violenta: Uma ferramenta poderosa na negociação

 

Você já ouviu falar sobre Comunicação Não-Violenta? Eu ouvi esse termo, há mais ou menos um ano atrás, quando conheci o Su. Na ocasião o Su, que é entusiasta da CNV, me explicou sobre como utilizar Comunicação Não-Violenta no dia-a-dia, e eu acabei por considerar a CNV uma ferramenta excelente para negociações de prioridades e reuniões com os mais diferentes stakeholders.

Para introduzir o assunto a vocês, eu entrevistei o Su Kei-Wei, entusiasta da comunicação não-violenta e palestrante no assunto.

P: O que é Comunicação Não-Violenta?

Continue lendo “Comunicação Não-Violenta: Uma ferramenta poderosa na negociação”

E o RUP?

O que é RUP? A sigla RUP quer dizer “Rational Unified Process”, ou, em português, “Processo Unificado Rational”. Mas isso não significa que o RUP seja realmente um processo, mas sim, um framework de boas práticas. Digo isso porque o RUP apenas sugere algumas boas práticas para o desenvolvimento de software, e não implica que nenhum software será entregue caso as práticas do RUP não sejam seguidas.

Cheguei a ler o RUP 5.0 inteiro, no que compete a papéis do analista, e pude observar que o RUP possui todas as orientações para o desenvolvimento de um software.

O que as pessoas querem saber quando te perguntam: Você sabe RUP?

O RUP, além de ser um framework de boas práticas, possui uma série de templates de artefatos a serem entregues nas diversas fases do desenvolvimento de software. Quando alguém te pergunta se você conhece RUP, está se referindo ao seu conhecimento quanto ao uso destes artefatos em cada fase do projeto.

Mas não são artefatos demais?

Sim, são. Porém, existem alguns artefatos que são “padrão” de uso e exigidos na maioria dos processos de desenvolvimento de software, e outros que são apenas complementos, ficando o usuário do RUP livre para decidir quais artefatos serão necessários.

Como o RUP, que é um “manual”, consegue saber da necessidade diária do meu projeto?

Aí é que está a mágica: ele não sabe. Mas possui uma série de técnicas que são comuns à maior parte dos projetos, e pode ser adaptado conforme a necessidade.

RUP é o Waterfall, ou Processo Sequencial Clássico?

Essa é uma das maiores confusões em relação ao RUP. O rup possui as quatro fases de desenvolvimento do software, a seguir:

  • Iniciação
    • A meta dominante da fase de iniciação é atingir o consenso entre todos os envolvidos sobre os objetivos do ciclo de vida do projeto. A fase de iniciação tem muita importância principalmente para os esforços dos desenvolvimentos novos, nos quais há muitos riscos de negócios e de requisitos que precisam ser tratados para que o projeto possa prosseguir. Para projetos que visam melhorias em um sistema existente, a fase de iniciação é mais rápida, mas ainda se concentra em assegurar que o projeto seja compensatório e que seja possível fazê-lo.
  • Elaboração
    • A meta da fase de elaboração é criar a baseline para a arquitetura do sistema a fim de fornecer uma base estável para o esforço da fase de construção. A arquitetura se desenvolve a partir de um exame dos requisitos mais significativos (aqueles que têm grande impacto na arquitetura do sistema) e de uma avaliação de risco. A estabilidade da arquitetura é avaliada através de um ou mais protótipos de arquitetura.
  • Construção
    • A meta da fase de construção é esclarecer os requisitos restantes e concluir o desenvolvimento do sistema com base na arquitetura da baseline. A fase de construção é de certa forma um processo de manufatura, em que a ênfase está no gerenciamento de recursos e controle de operações para otimizar custos, programações e qualidade. Nesse sentido, a mentalidade do gerenciamento passa por uma transição do desenvolvimento da propriedade intelectual durante a iniciação e elaboração, para o desenvolvimento dos produtos que podem ser implantados durante a construção e transição.
  • Transição
    • O foco da Fase de Transição é assegurar que o software esteja disponível para seus usuários finais. A Fase de Transição pode atravessar várias iterações e inclui testar o produto em preparação para release e ajustes pequenos com base no feedback do usuário. Nesse momento do ciclo de vida, o feedback do usuário deve priorizar o ajuste fino do produto, a configuração, a instalação e os problemas de usabilidade; todos os problemas estruturais mais graves devem ter sido trabalhado muito antes no ciclo de vida do projeto. No fim do ciclo de vida da Fase de Transição, os objetivos devem ter sido atendidos e o projeto deve estar em uma posição para fechamento. Em alguns casos, o fim do ciclo de vida atual pode coincidir com o início de outro ciclo de vida no mesmo produto, conduzindo à nova geração ou versão do produto. Para outros projetos, o fim da Transição pode coincidir com uma liberação total dos artefatos a terceiros que poderão ser responsáveis pela operação, manutenção e melhorias no sistema liberado.

Mas isso não significa que cada fase só executará uma vez, ou que elas tenham dependência para início. O gráfico das baleias mostra exatamente como deve ser o ciclo de vida do projeto:

Como é possível verificar, a modelagem de negócios acontece durante todo o projeto, por exemplo. A parte de requisitos é forte durante as fases de Iniciação e Elaboração, mas continua durante todo o projeto, assim como as demais disciplinas. Isso diferencia o RUP do Waterfall, que possui uma única iteração ao longo do projeto, com interdependências entre fases.