Arquivo da tag: product owner

1

Variação interessante do Product/Market Fit Canvas

|

Que tal um Canvas como base para uma dinâmica de mapeamento de produto e seu mercado? De um lado temos características, desafios, canais e experiência do usuário, enquanto do outro analisamos as outras alternativas, funcionalidades-chave, valor para seu canal e métricas-chave.

O objetivo inicial tem muito a ver com empatia com determinada(s) persona(s) que estejam em seu foco ou hipótese de negócio para então discutir a modelagem de parâmetros que o ajudem a construir seu entendimento e argumentos de venda ou contribuir para a definição de hipóteses para validação.

Imagine um evento onde grupos multi-disciplinares de profissionais debatam em um world-café diferentes produtos, seus mercados e valor, para isso eu ajustei os campos do canvas a nossa necessidade, a esquerda empatia com o cliente, a direita percepções sobre o produto.

O objetivo final é relacionar o melhor texto e argumentos de valor do produto, por isso uma proposta de mercado (cliente) e objetivamente a caracterização essencial do produto e informações que possam estabelecer qualidades e benefícios.

Vale a pena seu uso em diferentes situações, o canvas adaptado, o original ou outras variações podem ajudar como um warm-up, na forma de um jogo de aquecimento antes de uma dinâmica de modelagem de produtos, de retrospectiva de um projeto, de vendas ou mesmo de estratégia.

O original foi proposto como uma técnica específica para modelar o entendimento do acoplamento entre mercado e produto, mas eu o tenho usado mais para aquece, para ampliar o domínio sobre algo, quer seja um produto ou serviço em diferentes situações.

A seguir uma foto simbólica com a apresentação do product/market fit canvas e do objetivo final a ser atingido …

40877319_2082728815113391_6041530551670669312_o

 

0

Benchmark

|

É mais que analisar a concorrência, é tirar o máximo de proveito dos dados, informações e conhecimentos disponíveis sobre qualquer fonte, física ou virtual, primária ou secundária. No Design Thinking é a Pesquisa Desk, o Gartner oferece uma ideia de quadrante mágico, um eixo de inovação e execução, mas com frequência usamos planilhas comparativas de features, pontos fortes e fracos, valores e recursos necessários.

Ludicamente, é como um arquiteto ou estilistas que busca inspiração nas artes, nas ruas, revistas, hoje em dia a web é ponto de partida para tudo, mas com o cuidado de não se limitar, porque o mundo real desperta outros sentidos e percepções … eles chamam de repertorizar. Benchmark é evitar tentar reinventar a roda.

Se você teve uma ideia, o primeiro passo é pesquisar e ver quem mais a teve, a quanto tempo, quantos produtos semelhantes já estão no mercado, quais seus pontos fortes e fracos, características e estratégia adotada por suas empresas, matriz de funcionalidades, comercialização, …

Significado: “Benchmarking é um processo de comparação de produtos, serviços e práticas empresariais, e é um importante instrumento de gestão das empresas. O benchmarking é realizado através de pesquisas para comparar as ações de cada empresa. Tem o objetivo de melhorar as funções e processos de uma determinada empresa, importante aliado para vencer a concorrência, uma vez que analisa as estratégias e possibilita criar e ter ideias novas em cima do que já é realizado.”

Sempre que já existem opções, como sistema atual, alternativas, concorrentes, é preciso conhecê-los e compará-los, quer seja para não cometer erros conhecidos, como para inspirar-se naquilo que o mercado já confirmou ou rejeitou. Abaixo algumas matrizes comparativas para efeito de ilustração, entretanto benchmark pode vir na forma de um relatório ou fichas descritivas:

0

Prototipação

|

O uso de protótipos pode ser feito de diferentes formas, por meio de simulações, wireframes, modelos em escala, prototipação de hardware, usando controladoras genéricas como arduino, desenho, colagem, simulações com produtos similares, etc.

Significado: “Na Engenharia de Software, protótipo é um sistema/modelo de um software sem funcionalidades inteligentes como acesso a banco de dados, podendo conter apenas funcionalidades gráficas. Utilizado para fins de ilustração e melhor entendimento, geralmente em reuniões de validação com o contratante.”

Uma técnica que permite a materialização ou visualização simulada de um produto, de forma a permitir maior entendimento pela equipe de projeto, pelo cliente, patrocinadores ou investidores. Frente a metodologias ágeis, uma forma de validação de baixo custo, comparada ao tempo e recursos para o desenvolvimento real e escalável do produto final.

Em relação a busca pelo senso de pertença e imersão de equipes de trabalho no produto ou serviço que estão projetando ou desenvolvendo, protótipos permitem máximo entendimento do objetivo e trabalho necessário para executá-lo.

O custo para sua confecção depende do grau de acuracidade e realismo em seus detalhes e características funcionais. Esta decisão deve levar em consideração não só o custo em dinheiro, mas em tempo e valor agregado, associado à construção e aproveitamento.

0

Shadowing para levantamento de mais informações

|

É análogo ao conceito de sombra do Design Thinking, é sentar ao lado de alguém, no dia-a-dia de uma equipe e registrar fatos e percepções. Fotografe, grave, filme, peça depoimentos, abstraia roteiros, registre pensamentos, insights, cenários principais e alternativos.

Há uma possibilidade em que terceirizamos esse trabalho, quer por motivos geográficos, volume, velocidade, então um diário pode ser confeccionado e entregue a quem fará o registro, sugerindo as mais diferentes técnicas, para ser preenchido e mantido pela própria pessoa estudada (*) ou por um observador próximo.

(*) Há uma técnica chamada diário, em que pedimos que a própria pessoa registre e mantenha tudo o que acontece durante um certo período de horas ou dia, pois ao ter que registrar provavelmente ele próprio perceberá fatos que lhe passam desapercebido em meio a rotina.

Um super-artigo sobre shadowing em pesquisa é https://www.interaction-design.org/literature/article/shadowing-in-user-research-do-you-see-what-they-see

0

Opportunity Canvas – modelando algo conhecido

|

O Opportunity Canvas pode ser útil para facilitar a discussão sobre diferentes recursos para nosso produto ou serviço. Ao contrário do Business Model Canvas ou Lean Canvas que foca em inovação, aqui Jeff Patton assume que já temos um produto e queremos mapear e entender o negócio por trás dele.

Muito inspirado no Business Model, alterado por conveniência para discutir e modelar algo conhecido que pode ser melhorado. Assim, devemos considerar os problemas específicos dos usuários, aqueles que estamos tentando resolver e como achamos que eles usarão esta solução para resolvê-los.

oportunity canvas

Por não se tratar apenas sobre os usuários, é preciso incentivar a discussão sobre como estes usuários prejudicam seu próprio negócio e como ajudá-los a ajudar seu negócio e como mediremos o seu sucesso. O próprio autor tem um post bem acanhado sobre o post, mas o compartilha em uma versão PDF que vale a pena baixar – https://jpattonassociates.com/opportunity-canvas/

0

Um quadro estratégico e tático inter-equipes

|

Em uma consultoria recente os PO’s e analistas me pediram ajuda para organizar um product backlog compartilhado entre 6 equipes especialistas em suites de uma solução digital corporativa – financeiro, contábil, backoffice, etc.

Me baseei em um quadro de features por equipes do framework SAFe, onde temos cada equipe com suas features para o Train, garantindo uma visão tática por equipe x feature que dá suporte para algumas reuniões táticas e escaladas.

A necessidade era baseada em um backlog sendo priorizado por diferentes clientes e pela própria empresa para evolução e manutenção do produto. Queriamos um artefato que os ajudasse a ter uma visão clara transversal estratégica e tática para distribuição e acompanhamento.

Eu já havia ajudado a introduzir há alguns meses Scrum e Scrum of Scrums, que vinham trazendo bons resultados, mas agora os PO’s e analistas precisavam algo mais visual para o backlog nos próximos meses.

Diagramaticamente, reorganizamos os postits utilizados por eles em uma reunião recente de priorização com clientes, quando usaram um quadro de valor x esforço, com cores para 5 diferentes naturezas de ítens.

Simbolizei na imagem a principal diferenciação destacada, pois para cada time temos duas trilhas, uma para projetos (azul) e outra para sustentação (reserva técnica). O quadro visual é apenas para priorização e abstração em uma escala de tempo mensal.

O quadro ficará em um desses cavaletes com rodinhas, a granularidade dos tickets será por conveniência, coisas muito pequenas não serão representadas individualmente e o formato privilegiará selos com marcos, riscos e lembretes.

Cada postits azul representando projetos, no momento apropriado, terão sua própria inception e seu quadro de Release Plan junto ao(s) time(s) envolvidos, ficando aqui registrado apenas seus MVP’s e Releases.

O número de meses/sprints representados no quadro será um ponto de equilíbrio com foco em que o quadro facilite reuniões de estratégia com as equipes, diretoria e clientes. Também será um facilitador na mudança em curso para Agile no que diz respeito a gestão visual transversal, no plano estratégico e tático, compartilhada entre todos os envolvidos e interessados, inclusive stakeholders.

Relato GVDASA

Uma empresa de atuação nacional que vem fazendo sua transformação digital, com total apoio da alta direção, da gestão e equipes ágeis praticando Scrum, Kanban e realizando reuniões transversais seguindo Scrum of Scrums.

A mais de ano, cada equipe, desde a adoção, contando com profissionais que vem se empenhando em serem ágeis, agregar valor, evoluindo a cada ciclo, melhorando suas práticas ágeis através de experimentação x resultados.

“Já queria te dar um primeiro feedback. Recebemos um pedido de priorização de outra área, o item estava em 7º lugar no backlog, marquei um momento para discussão com os envolvidos e direção e utilizamos a técnica de comparação, ou seja o item a ser priorizado é mais importante que o 1º, 2º, 3º e assim sucessivamente. O resultado foi que todos concordaram que a priorização estava correta e deram um feedback positivo a respeito da clareza e transparência das prioridades que estão sendo trabalhadas.”

Vinicius Iager – coordenado de desenvolvimento GVDASA – Gestão educacional integrada, solução completa para a otimização dos processos acadêmicos e administrativos da sua instituição – http://gvdasa.com.br/

logotipo GVDasa

Conclusão

Não só as equipes envolvidas, mas a participação de clientes, líderes e executivos sempre é muito positivo ao se depararem com um quadro de portfólio, programa, ciclo ou Release Plan. Eles veem ali materializado seus objetivos, desejos, sonhos e expectativas.

Muito da alta pressão, “natural” em projetos de TI, é existir diferentes percepções e entendimentos relativos a prioridades e possibilidades. Ao estabelecer um quadro estratégico ou tático, toda a discussão sobre priorização (e mudanças) geram um único entendimento.

Não há regras pétrias de ticketagem (postits) ao iniciar o uso, tanto granularidade quanto diferenciação irão adaptar-se a realidade do tipo de portfólio, programa, ciclo, tecnologia, complexidade, volumes, equipes, pessoas, etc … Dê o primeiro passo, explicite e deixe que as retrospectivas se encarregarão de melhora-lo cada vez mais.

0

Agile Bi-Modal e o planejamento de projetos

|

O agilista que mais admiro e sigo é o Paulo Caroli, guru da Thoughtworks, referência ágil mundial desde o planejamento até a retrospectiva.

Em 2011 participei de um evento em que ele facilitou uma técnica de Inception para um site de CoP – elevator, objetivos, personas, jornadas, histórias, US mapping com valor x cronologia – sprints e releases.

Anos depois ele lançou a Inception Enxuta, sua técnica Direto ao Ponto surpreende pela habilidade em planejar em nível zero – elevator, objetivos, personas, features, MVPs em ondas (sequenciamento) e canvas.

Genial as duas, extremamente simples, racionais e objetivas ao que se propõem, pessoalmente acabei optando por deixar as duas na minha toolbox, as vezes uso uma, outras vezes a outra.

Fazer certo a coisa certa

Mais importante que a inception, é o trabalho prévio para enquadramento, direcionando ou não business cases, concepção estratégica, bases para que uma inception se beneficie de tudo o que já sabemos – mapas, jornadas, processos, benchmark, mapa de funcionalidades, etc.

Quando iniciamos um projeto do modo 1 como se fosse modo 2, este é o primeiro e maior desperdício, ele se propagará por meses, desconsiderando tudo o que já se sabe apenas para tentar enquadrá-lo como modo 2.

Modo #1 – Projetos com escopo de negócio claros

Participo de dezenas de projetos a cada ano, para os grandes clientes da DBserver, novos produtos tanto quanto evolutivas e pacotes de corretivas. A maioria deles temos um escopo de negócio claro, há variadas alterações durante seu curso, mas um Release Plan claro em sprints e histórias permitem amplitude de conhecimento, registro permanente de mudanças e aprendizado intenso, como por exemplo:

Um sistema de acompanhamento jurídico, com cadastro de escritórios, advogados, causas pró e contra, agenda de datas legais e de trabalho, integração com o TJ e etc. Um projeto executado em alguns meses com uma equipe enxuta, com alterações muito a nível de DoR, pois o briefing e brainstorming durante a Inception, somado ao budget e schedule, proporcionaram um projeto focado e estável em alto nível.

Um sistema de qualidade relacionado a exportação, focado na comunicação de ocorrências por clientes de outros países, gerando registro em uma base de dados, negociação, desde a abertura até o encerramento de cada caso, contando com fotos, relatos e laudos. O briefing, maturidade da equipe, budget e schedule deste também proporcionou um projeto focado e estável em alto nível.

Também soluções corporativas como de serviços adicionais, seguros ou franquias, é claro que há mudanças, mas termos uma ou duas dezenas de sprints desenhadas só trazem senso de pertença, apropriação de conceitos de negócio, principalmente nos dá visão clara de mudanças, impactos, compromisso com entrega, em contextos que valoriza-se o negócio tanto quanto há conhecimento abrangente sobre ele.

Modo #2 – Projetos com escopo de negócio variável

São em bem menor número, na maioria dos casos envolvem eventos prévios de concepção ou mesmo sprint designs, não há uma clara visão da melhor solução ou da melhor forma para executá-las, na maior parte das vezes há um objetivo de entender o primeiro passo, o mínimo produto viável, contando com algumas prints para durante esta trajetória escolher o próximo passo, fruto de construção e validações.

O case mais vivo na minha memória foi em uma solução de atendimento ao cliente com acompanhamento jurídico, de início planejamos alguns sprints, houveram muitas mudanças e aos poucos estabeleceu-se um planejamento de altíssimo nível sem sequer usar de estimativas, apenas conversávamos e a equipe estabelecia com o PO e stakeholders por onde ir e a medida que seguíamos em frente ajustava-se o backlog.

Outro case foi uma solução de apoio a gerentes de contas ou de negócios, onde de início estabeleceu-se a percepção de que não sabíamos para onde seguir e durante algumas semanas foram trabalhadas reuniões de concepção junto a diferentes personas, validando-as em mocks até que a melhor solução ficou estabelecida, completamente diferente da proposta inicial.

Fui Agile Coach por vários meses em uma aceleradora, a cada sexta-feira planejávamos os próximos passos para algumas semanas, sendo que na sexta seguinte tudo poderia mudar. Lean Startup na veia, permanentemente checando ideias, pressupostos, validando, programando algo, validando, tudo de novo, validando, … Várias startups, com nenhuma tínhamos planos maiores que algumas semanas em Kanban.

A seguir minha reinterpretação sobre a TI Bi-Modal do Gartner, ambos os modos ágeis: