Análise de Negócios aplicada ao desenvolvimento de produto

1.013 visualizações

Publicada em

Palestra apresentada no BA Brazil 2013, em São Paulo.

Qual a diferença entre gerenciar projetos e desenvolver produtos? Ambos precisam de análise de negócios? Precisam. Mas projeto é relacionamento de curto prazo. Algo que você conhece, se aprofunda, muitas vezes até se apaixona, mas que você sabe que está fadado ao fim. Projetos você entrega. E parte para outra. Produto não. Produto é compromisso de longo prazo, é aliança no dedo. É dormir e acordar pensando na mesma coisa. É conhecer cada detalhe com profundidade, escovar, polir, melhorar continuamente. Produto também tem fim. Tem até troca. Mas o relacionamento com ele é eterno, pelo menos enquanto dura. Apresentação de um case real sobre como a análise de negócios ágil transformou a área de desenvolvimento de produtos digitais de uma grande empresa de comunicação a partir da ótica de uma ex gerente de projetos que se transformou em uma product owner apaixonada.

Publicada em: Negócios
0 comentários
5 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
1.013
No SlideShare
0
A partir de incorporações
0
Número de incorporações
11
Ações
Compartilhamentos
0
Downloads
0
Comentários
0
Gostaram
5
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide
  • Quem aqui trabalha com desenvolvimento de produto. É PO? É gestor de produto? É gerente de produto? Há 3 anos atrás eu não sabia muito sobre o que era isto.
  • Como iniciei, contar a história dos 900 pila. Detalhar os projetos.
  • A palavra aqui é mudança. Como parzianello fala, ou muda ou dança.
  • A palavra aqui é mudança. Como parzianello fala, ou muda ou dança.
  • Em 2010
  • Eu gostava de gerenciar projetos, juro. Contar que o time queria estar mais perto do seu cliente redação.
  • Consultoria, óbvio
  • No Review, não faz sentido apresentar para o PO que está dentro do time. Contar a história das entrevistas.
  • Backlog de Produto, sprints de duas semanas, dailys, entrega cont[inua.
  • Análise de Negócios aplicada ao desenvolvimento de produto

    1. 1. + Análise de Negócios aplicada ao desenvolvimento de produtos. BA Brazil 2013
    2. 2. + Diana Corrêa  Formada em Publicidade e Propaganda pela PUCRS.  Cursa MBA em Liderança, Estratégia e Inovação pela ESPM.  Atua há 11 anos em tecnologia.  Trabalha desde 2010 no Grupo RBS: Gerente de Projetos / Analista de Negócios / Product Owner  hagah  Projeto de Eleições 2012  Produtos Mobile  Esportes br.linkedin.com/in/dianacorrea/ @llldianalll
    3. 3. + Objetivo A palavra é mudança  Apresentar um case real de mudança organizacional – Grupo RBS.   Mudança do papel do analista de negócios  Mudança na forma de fazer gestão de produtos   Mudança do modelo de desenvolvimento: do cascata ao ágil Minha mudança pessoal: como virei P.O. e o que tive que aprender. Ainda estamos mudando, o processo é iterativo incremental.
    4. 4. + Grupo RBS  Hoje, a RBS é líder na área de comunicação no Rio Grande do Sul e em Santa Catarina, produzindo conteúdo e entretenimento em rádio, televisão, jornal e plataformas digitais.  E-Bricks:    Wine.com.br Grupo PontoMobi Meu desafio: Melhor entrega de conteúdo digital no negócio de Jornais.
    5. 5. + Já estava assim quando eu cheguei… “Nossa, parece quando a gente estava no segundo andar”.
    6. 6. + Cliente Demanda Redação Demanda Comercial Estrutura e Processo Como era no segundo andar?  Determinava o que devia ser feito, como, e, algumas vezes, quando.    Aprovava os entregáveis (Wireframes, Design, Produto Final).  Tirava o pedido e apresentava possíveis soluções. Especificava o que deveria ser feito. Gerenciava o projeto como um todo (custo, prazo, escopo).  Prestadores de serviço.  Desenvolviam em cascata.  Pessoas eram recursos: pulapula de projetos.
    7. 7. + Como era no segundo andar Pouco poder de decisão:  Tudo passava pela aprovação de um diretor ou área parceira  Não gerava demandas, era demandado  Papel do Analista de Negócios  Distribuição de tempo:  15% tirava pedidos  25% realmente fazia análise de negócios  60% do tempo gerenciava projetos
    8. 8. + Qual era o problema?  Pessoas desmotivadas e sem engajamento  Entregas de baixa qualidade Processo burocrático e lento Aplicação de lógica de projetos em uma área de produto.    Riscos:  Não há evolução contínua  Pouca competitividade/agilidade frente à novos entrantes e concorrentes existentes NÃO TRATE SEUS PRODUTOS COMO PROJETOS
    9. 9. + Decidimos ser ágeis Rumo ao Tecnopuc
    10. 10. + Conceito de Startups PRODUTO TI Business Owner Nova estrutura Como é no Tecnopuc? TIME = PRODUTO + TI Cliente??
    11. 11. +  Não é cliente do time. É membro do time.  Não é gestor, embora seja uma liderança.  Não gerencia projetos, faz gestão de produto.  Envolve o time nas decisões e busca engajamento.  Co-Criação > Entendimento  Compartilha conhecimento e adquire conhecimento.  Tem autonomia e toma decisões, just in time.  Escreve User Stories.  Participa da Daily, do Planning, do Review, da Retrospectiva. E promove Discoveries. Qual o papel do P.O. no time? Lá na RBS.
    12. 12. + Cultivando o backlog User Story Mapping Todos do time são envolvidos no Discovery e priorização. Pessoas chave de outras áreas são envolvidas. How You Slice It Jeff Patton
    13. 13. + Processo de trabalho  O product backlog gera Releases de produto, que geram Sprints de 2 semanas.  Cada time trabalha com o processo/ferramenta que considera melhor.
    14. 14. + Agora Product Owner Todo poder de decisão:  Tem a gestão do produto em suas mãos.  Papel do Analista de Negócios  Distribuição de tempo:  80% fazendo análise de negócios / gestão de produto  10% do tempo gerenciando projetos  10% do tempo pensando em marketing digital GP PO
    15. 15. + Resultados  Pessoas motivadas e engajadas  Aumento na qualidade de entrega  Time-to-market melhorou  Iniciamos um processo de real gestão de produto
    16. 16. +  Ainda tínhamos times por tecnologia.  Mais uma vez, lógica de projetos.  Mais uma vez, falta de agilidade/foco em termos de gestão de produto. Mudança iterativa incremental Scrum não é bala de prata, lembra? NÃO TRATE SEUS PRODUTOS COMO PROJETOS
    17. 17. + Sou uma Product Owner e agora? O que eu tive que entender…
    18. 18. + Quem é meu cliente?  Antes era fácil. Meu cliente era um diretor. Ou era a redação. Ou era o comercial.
    19. 19. + Meus clientes: Milhões de usuários. E agora?  Como eu coleto requisitos desta gente que eu nem sei o nome?  Como eu entendo o problema destas pessoas?  O que elas querem? O que gostam? O que pensam? O que sentem? O diretor não é o cliente, eu não sou o cliente, o time não é o cliente. Meu objetivo: Entender meu usuário.
    20. 20. + Só sei que nada sei… Mas vou ter que descobrir.
    21. 21. + Entendendo meu usuário Usando Empathy Map…  Entrevistas com usuários.  Entendimento do problema, necessidades e ganhos e não da solução.  O que esta pessoa sente, vê, pensa, escuta, precisa, ganha?
    22. 22. + Entendendo meu usuário …para formar personas.  Identificação de padrões  Montagem de personas  Qual o problema do meu usuário?
    23. 23. + O usuário não sabe o que quer. Será?
    24. 24. + Qual afinal é o negócio?  Devo focar no anunciante ou na audiência?  Qual a minha principal proposta de valor?  Business Model Generation Quem pode me ajudar nesta jornada? “Por mais que me doa dizer isto, o foco deve ser a audiência”. (Gerente Comercial)
    25. 25. + Lean Canvas
    26. 26. + Mas tudo isto são hipóteses “A gente não é o Brasil˜.
    27. 27. + Canvas de hipóteses e de testes
    28. 28. + Ainda sobre hipóteses… Entendendo o real valor do MVP Eu trabalho com mínimo produto viável para:  Entregar valor mais rápido?  Ter um time-to-market melhor que o do meu concorrente?  Fazer todo mundo mais feliz porque está vendo o fruto do seu trabalho mais rápido no mercado? Sim, é tudo isto. Mas, mais ainda, é isto: Conhecer o usuário o mais rápido quanto for possível. Testar meu modelo de negócios na “vida real”. COMO???
    29. 29. + Medindo tudo! (Feedback sempre)  Tudo tem que ser trackeável.  Defina as métricas de acompanhamento.  Olhe estas métricas com frequencia.  Decida em cima de métricas.  Uma nova feature vai ser lançada? Defina em quais métricas você vai mexer. Volte para ver o resultado.  Investigue com profundidade:   Tempo de navegação pode significar que seu usuário ama seu conteúdo. Ou que o seu UX é tenebroso. Não se apegue à métricas de vaidade: Downloads, por si só, nem sempre significa sucesso.
    30. 30. + Não se apegue  Uma estratégia não deu certo? Mude.  Corte os excessos: features que ninguém usa só atrapalham o usuário.  Volte para olhar seu modelo de negócio de novo e de novo.
    31. 31. + Trabalhar com produto para mim é… É diferente de gerir projetos. Não tem começo, meio e fim, é fluxo contínuo. É compromisso de longo prazo.  Exige dedicação: dormir e acordar pensando nisto.  Muitas vezes o cliente está mais longe, é mais difícil de “coletar requisitos”.  E é preciso criar os meios para isto. O usuário não sabe o que quer, mas sabe um monte de coisas. É como um relacionamento: ou conheço meu cliente um pouco mais a cada dia, ou levo um grande pé na bunda.
    32. 32. + Mudança pessoal A partir de uma mudança organizacional eu aprendi que:  Não quero deixar de trabalhar com ágil  Quero fazer análise de negócios voltada para produto  Achei finalmente a minha verdadeira paixão
    33. 33. Papel do Product Owner: + “Ajudar o time (e a empresa) a entregar o produto certo para o usuário certo”. Gerando ROI!
    34. 34. + Obrigado! Perguntas?

    ×