Fundamentos de Product Management - Aspetos relativos ao Product Manager
Introdução
Este artigo é a parte 2 do artigo publicado em Agosto Fundamentos de Product Management – Aspetos Relacionados com o Produto | João Carlos Matos (joaomatosdigital.pt)
O que é ou o que envolve a função de Product Management
O Product Management – PM – é o enabler/connector entre a estratégia da Empresa e os problemas e necessidades dos clientes. Ou seja, deve perceber na Visão do Produto como o mesmo vai ou pode impactar positivamente a vida das pessoas e, simultaneamente, os objetivos estratégicos da empresa. Ou seja, a função de Product Management envolve equilibrar e entregar valor e viabilidade ao longo de todo o ciclo de vida do produto.
Gestão de Projetos e Gestão de Produtos
Se um projeto é diferente de um produto, obrigatoriamente, a gestão de projetos é diferente da gestão de produtos. E a este respeito aconselho a leitura do artigo que publiquei sobre este tema: “Produtos e Projetos – Product Management e Project Management”.
Product Management vs Product Owner – PO
Pois é, ao contrário daquilo que muitas Empresas pensam, a julgar pelos anúncios publicados para a “função” de PO, um PO não é um PM. Indo direto ao ponto, um PO não é uma função. É uma papel desenvolvido pelos responsáveis pela criação do Scrum Guide. O papel do PO é focado na criação da meta da sprint, priorização do backlog e na garantia dos deliveries dentro dos prazos acordados. Ou seja, é um papel muito mais tático, enquanto o papel do Product Management é uma função e muito mais estratégica.
Cultura de Produto
Uma empresa não tem uma cultura de produto por inerência à sua constituição. A cultura de produto, tal como a cultura de um país ou de uma pessoa, constrói-se e vai-se desenvolvendo.
Alguns princípios para uma cultura de produto ser desenvolvida podem traduzir-se em:
- Aprendizagem acima de Culpa – O indivíduo, as equipas, as pessoas e o produto só se desenvolvem se se cometerem erros. Sejam eles calculados ou não. Na psicologia há um princípio que é o “Condicionamento Operante”. Muito utilizado no treino canino. Mas cães, ao contrário daquilo que as pessoas possam pensar, não aprendem através de punição, mas sim através do reforço positivo. E com as pessoas e as suas funções dentro da empresa este princípio deve ser aplicado. Mesmo que a cultura não seja de produto. Acredito que este é um princípio universal empresarial
- Colaboração acima do Individualismo – A É sempre melhor trabalharmos em equipa do que individualmente. “Nenhum Homem é uma Ilha”. E o desenvolvimento carece de várias disciplinas empresariais para o seu desenvolvimento. E ainda, trabalhando em equipa quando há vontade, motivação, conhecimento, multidisciplineriedade e não reconhecimento de culpa, a probabilidade de acontecerem erros forçados é menor.
- Propósito de negócio acima de Receita – O propósito de um negócio não pode ser a receita. NA receita é algo que está subjacente a um negócio que não tem fins lucrativos. A Receita deve ser vista como uma métrica Q.B., mas como uma métrica. E mesmo sendo vista como uma métrica, não deve ser vista como a North Star. Daí ter dito que é uma métrica Q.B.
- Transparência e Contexto acima de Opacidade – Sem contexto não há aprendizagem. Sem contexto não há trabalho individual e muito menos em equipa. Sem contexto o negócio não tem um propósito, porque não conhece as suas circunstâncias internas e externas.
- Inovação acima de Estagnação – Se as empresas não evoluírem, as pessoas não evoluem, o produto não evoluem e a empresa mais cedo ou mais tarde, ou pelo menos o produto entra em declínio.
Liderança de Produto
- Contexto – Um dos Princípios da Cultura de Empresa é o Contexto acima da Opacidade. E além daquilo que escrevi sobre este Princípio, o Contexto significa que todas as pessoas conhecem qual é a Visão, a Missão e os Valores da Empresa (e se os clientes também souberem melhor).
- O Propósito deve responder à pergunta: Por que?
- A Visão responde à pergunta: O quê?
- A Missão: Como?
- Remover Impedimentos – Mais uma vez: a liderança deve estar presente, mas sem microgerir as equipas. A liderança deve deixar claro para todos qual a Visão de Futuro, e gerir excessos de trabalho, gerir expectativas e ansiedades, e ter a responsabilidade e independência total para que possa auxiliar a equipa a sentir-se parte integrante de “uma gestão” de produto.
- Desenvolver as Pessoas – Numa cultura de produto, o desenvolvimento deve ser feito tendo em conta o seguinte:
- As Pessoas são a prioridade número 1 da Empresa, só assim conseguimos que elas consigam estar focadas no seu trabalho. E por isto, é importante que a liderança saiba, entre outros temas, balancear pressão, ainda que não exista ttrabalho sem pressão.
- A aprendizagem, tal como visto no parágrafo sobre a Cultura de Produto é uma constante e deve ser fornecida a todas as pessoas e todas as pessoas são vasos e veículos de aprendizagem, inclusivamente o Product Manager
- Avaliações e Feedbacks – As avaliações são um “número” ou um “tier” em que a pessoa fica após ser avaliada. O feedback dá o contexto e responde aos possíveis porquês que os avaliados possam ter. Fazer uma avaliação sem dar contexto (até mesmo sem contexto prévio de quais serão os fatores a serem avaliados) é algo de uma Empresa sem cultura não só de produto, mas sem cultura de Pessoas.
- Promoções e Aumentos – Duas ideias sobre este tema:
- 1 – As promoções e os aumentos não devem estar atreladas ao ciclo de avaliação. A própria metodologia de OKR – Objectives & Key Results transpira este princípio.
- 2 – As promoções podem ser feitas de duas formas: Assumir atividades relacionadas com essa função ainda não ter atingido a mesma – push promotion e assumir as funções apenas quando se chega à função – push promotion.
Carreira de Produto
A carreira de produto pode ser biforcada. Num dos caminhos temos uma carreira mais vocacionada para a Liderança de Pessoas e no outro caminho temos uma carreira mais de especialista.
- Ramo comum – As funções comuns à carreira de Product Manager, antes de “se optar” por um dos caminhos da bifurcação são: Associate Product Manager, Product Manager e Sénior Product Manager
- Se se optar pelo caminho de Gestão de Pessoas temos as seguintes funções – Group Product Manager, Head of Product e VP of Product
- Se se optar pela carreira de Especialista temos como funções – Product Specialist e Principal Product Manager
Conclusão
Acredito que este segundo artigo sobre Fundamentos de Produto possa ajudar muitos aspirantes a Product Managers a entender melhor este mundo e a fazer escolhas acertadas quando optarem por ir para uma Empresa. Porque tal como disse no primeiro artigo, há muito falta de cultura de produto dentro das Empresa, infelizmente. E isto não é necessariamente mau, a partir do momento que as empresas o reconhecem e fazem tudo para que essa cultura seja implementada. Vai ser fácil? Não. É o CEO que a implementa? Não. Temos de ter autonomia total e responsabilidade enquanto PM? Sim.
E puxando a brasa, dentro do possível à minha sardinha e mais uma vez: não tenho o título de Product Management, mas tenho mais de 11 anos de experiência a trabalhar em produtos digitais dentro de várias culturas empresariais e interagindo com diversas equipas e adoraria assumir uma função dentro desta área associada ou não aos dados.
Fundamentos de Product Management - Aspetos relativos ao Produto
Introdução
Este artigo é um resumo daquilo que foi a minha aprendizagem do Módulo 1 do curso de Product Management, mas direcionado ao tema do Produto. No próximo artigo escreverei sobre os “Aspetos relativos à Função de Product Management”.
O que são Produtos Digitais e que Tipos de Produtos Digitais Existem
Neste artigo podem obter informação sobre O que são Produtos Digitais? | João Carlos Matos (joaomatosdigital.pt). Escrevi este artigos antes de iniciar este curso, o que comprova que todo o investimento feito em formação e experiência profissional adquirida me permitem atuar como um Product Manager.
Mas vamos fazer então um breve resumo sobre este tópico. Um produto digital é qualquer tipo de software e/ou tecnologia que tenha utilizadores.
Os tipos de produtos digitais que existem são:
- Produto Digital (software propriamente dito) – É um produto comprado ou subscrito online pelos utilizadores. Por exemplo, uma assinatura do serviço da Google (SaaS). Ou a utilização de uma app de Homebanking.
- Marketplaces (de troca) – São plataformas que reunem num único lugar fornecedores, vendedores e clientes. Por exemplo, Airbnb.
Visão e Estratégia de Produto
A Visão de Produto é aquilo que queremos que ele seja no futuro. A Visão de Produto é das maiores responsabilidades do Product Management, pois é a “estrela guia” de tudo o resto. Mas atenção, não é o Product Management que estabelece a Visão do Produto sozinho. Assim como não é o CEO que a estabelece essa visão sozinho. Ambos estabelecem essa Visão e com base em vários elementos e artefactos que veremos de seguida.
Elementos da Visão
Os eleitos da visão serão os Objetivos Estratégicos da Empresa e os Problemas e as Necessidades das Pessoas.
Artefactos da Visão dos Objetivos Estratégicos da Empresa
- Análise SWOT – A Matriz SWOT vai permitir-nos identificar as Forças (Strengths) do negócio, as Fraquezas do negócio (Weakness) as Oportunidades do Mercado (Opportunities) e as Ameaças do Mercado (Threats).
- Análise de Mercado – Os vários tipos de análise de mercado vai permitir-nos identificar: Concorrentes, Potencial de crescimento nesse mercado, possíveis disrupções…Este tipo de análise advém não só da SWOT, mas também, por exemplo, de Benchmarks.
Artefactos da Visão Problemas e as Necessidades das Pessoas
- Jornada do Cliente – Representação visual, mas com base na realidade, dos passos, interações, motivações e frustrações dos clientes com uma Empresa/Produto ao longo de toda a sua experiência.
- Personas – Perfis fictícios baseados em dados reais que representam os diferentes tipos de clientes de um produto ou serviço.
- Mapa de Empatia – Ferramenta que ajuda a entender melhor as emoções, desejos, preocupações e comportamentos de um cliente, colocando-se no lugar dele.
- Quais são as Etapas do Ciclo de Vida do Produto
Este tema ainda o estudei na universidade, ainda nada se falava sobre Product Management, falava-se em Gestão de Produto (mais físico). Mas em metodologias de trabalho agile nada, mesmo nada se falava. Vejam bem!!!
O Ciclo de Vida do Produto tem 4 fases:
- Entrada/Inovação – A primeira fase chamo-a de entrada para aquelas produtos que não trazem nada de inovador ao mercado e, portanto em princípio não vão trazer grande valor para as pessoas (a não ser provavelmente o preço mais baixo), e consequentemente para o negócio. E se o benefício for o preço, entra-se numa luta para o fundo. Para aqueles produtos que são inovadores, os benefícios deverão ser valorosos para as pessoas e para o negócio. Partindo do princípio que o Produto foi pensado tendo em conta essas premissas, mas também, as metodologias de desenvolvimento.
- Crescimento – Nesta fase é onde percebemos para os produtos que não trazem nada de valor ao mercado se o preço é suficientemente algo que gera valor para as pessoas e para o negócio ou se pelo contrário, o produto entrará em declínio. No caso dos produtos inovadores esta é a fase em que o Produto tem de encontrar o seu “Product Market Fit”.
- Maturidade – Nesta fase os produtos começam a gerar receita para o negócio – Product Economic Fit.
- Declínio/Relançamento – Fase em que o Produto chegará ou não ao Product Market Fit, mas por nunca encontrar um bom Economic Fit, é descontinuado e7ou tem de ser repensado.
Estas 4 fases em a sua correspondência na Matriz BCG, que é um dos artefactos de um Product Management e/ou negócio:
- Quadrante da Matriz BCG dos Pontos de Interrogação – Corresponde à fase de Entrada do CVP
- Quadrante da Matriz BCG Vacas Leiteiras – Corresponde à fase de Maturidade do CVP
- Quadrante das Estrelas da Matriz BCG – Corresponde à fase de Crescimento do CVP
- Quadrante dos Abacaxis da Matriz BCG – Corresponde à fase de Declínio do CVP
Quais são as Fases de Desenvolvimento de um Produto
O desenvolvimento de um produto digital faz-se, ou deve-se fazer, de forma iterativa. Porque os produtos digitais são complexos e em que o problema das pessoas (utilizadores) vai sendo descoberto à medida em que o produto se vai desenvolvendo. A este respeito podem ler também o artigo sobre a Metodologia Agile vs Waterfall na criação de produtos digitais | João Carlos Matos (joaomatosdigital.pt)
Então, existem, essencialmente 3 fases no desenvolvimento de um produto:
- Problem Discovery – Fase em que se está a tentar identificar da melhor forma e detalhe possível o problema que as pessoas estão a enfrentar e que podem gerar valor para o negócio, de acordo com aquilo que é a visão da Empresa. Esse problema pode ser uma necessidade real ou uma necessidade latente. Nesta fase, existe uma maior participação da gestão de produtos e UX (80%-90%), mas a participação das equipas de desenvolvimento e engenharia também é bem vinda, se possível e viável (20%-10%).
- Solution Discovery – Fase em que se está a desenvolver uma possível solução (teste) para o problema descoberto. Ou seja, além de se descobrir as (possíveis) melhores oportunidades, é importante criar e validar essas hipóteses de solução.
Nesta fase, todas as pessoas da equipa devem participar. - Delivery – Fase em que se desenvolve a solução, mas e novamente testando-a de forma rápida e analisando resultados/métricas para se voltar a iterar.
- Nesta fase, existe uma maior participação da equipa de desenvolvimento e engenharia (80%-90%) e uma participação mais residual das equipas de gestão de produtos e UX (20%-10%).
Mas vamos fazer então um breve resumo sobre este tópico. Um produto digital é qualquer tipo de software e/ou tecnologia que tenha utilizadores.
Conclusão
Este curso, comprova, por mais uma vez, a minha forma de estar comigo, enquanto profissional responsável e que se interessa bastante pela área digital/Martech onde trabalho e a minha forma de olhar para o trabalho.
Como se costuma dizer, “no papel” não sou um Product Management, nem Product Owner – e tenho também a Certificação CSPO da Scrum Alliance. Mas tenho mais de 11 anos de experiência a trabalhar em produtos digitais interagindo com diversas equipas e em várias empresas; agência full service, agência de web intelligence, clientes B2C, clientes B2B, consultoras.
Produtos e Projetos - Product Management e Project Management
Introdução
Já escrevi três artigos a falar sobre Produtos Digitais e que podes lê-los nos links abaixo.
O que são Produtos Digitais? | João Carlos Matos (joaomatosdigital.pt)
Hoje o artigo foca-se mais naquilo que são projetos e como geri-los. Tenho duas ideias fortes sobre o tema:
1 – A gestão de produto e a gestão de projetos, ainda que diferentes, sobrepõe-se.
2 – A gestão de projetos torna-se mais fácil para quem tem conhecimentos e/ou prática na gestão de produtos, nomeadamente produtos digitais. Isto porque, é mais difícil gerir algo com menos informação do que com toda a informação. Além disso, Além disso, os Project Managers utilizam combinações de metodologias ágeis e tradicionais, para garantir que os projetos são concluídos conforme o plano estabelecido inicialmente.
Projetos e Produtos, nomeadamente digitais, são conceitos diferentes.
As principais características de um projeto são:
- Foco, essencialmente, no cumprimento do prazo de entrega e na própria entrega
- Tanto o cenário como o contexto é conhecido na sua plenitude e por isso…
- Âmbito negociado inicialmente e fechado
- Timing de início e de finalização previsto
- Budget definido inicialmente e sem necessidade de revisão (previsivelmente)
- Terminado o projeto, o trabalho do Project Manager nesse projeto, geralmente termina
As principias características de um produto são:
- Foco, essencialmente, na entrega de resultados e valor para pessoas e empresas
- Os cenários e os contextos não são totalmente conhecidos à partida, por serem voláteis às necessidades das pessoas
- O âmbito não é fechado e vai-se negociando durante o desenvolvimento do produto
- Timing de início definido, mas sem um timing de finalização uma vez que o produto está (ou deve estar) em constante adaptação
- Budget definido, mas com necessidade de revisões periódicas e com base nas várias conclusões emergentes dos ciclos de iteração
- Em princípio um produto está em constante desenvolvimento (a não ser que seja descontinuado) e, portanto enquanto o produto estiver a evoluir o trabalho do Product Manager não termina
Se são conceitos e realidades diferentes, será que a gestão de projetos e de produto é também ela diferente? Diria que obrigatoriamente terá de ser. Podes ver o artigo sobre esta temática intitulado:
Será Diferente Criar um Produto Digital em Ambiente Agile ou Waterfall? | João Carlos Matos (joaomatosdigital.pt)
Aliás, quem está no meio sabe que existem certificações em Gestão de Projetos. Por exemplo a certificação em Project Management Professional do Project Management Institute – PMI. Mas também existem certificações em Product Owner. Por exemplo a certificação CSPO da Scrum Alliance ou a certificação PSPO da Scrum.org. Eu tenho a primeira.
Então, o que é assim tão diferente entre a gestão de produto (Product Management) e a gestão de projetos (Project Management).
Gestão de Projetos
A gestão de projetos foca-se na realização de algo específico e com objetivos, âmbito, prazos e alocação de recursos bem definidos. Isto porque um projeto tem uma data de início e de fim e o Project Manager tem a responsabilidade de garantir que todo o Ciclo PDCA – Planeamento, Desenvolvimento, Controlar e Atuar é executado dentro dos timings, budget e âmbito estabelecidos inicialmente.
A gestão de projetos tem uma componente de risco associada e que deve ser também gerida pelo Project Manager. Essa componente é inerente ao facto das características de um projeto, onde tudo fica definido inicialmente (âmbito, budget, prazos, requisitos, recursos, ferramentas…).
Existe também a necessidade de gestão de das pessoas, comunicações e stakeholders ao longo do mesmo, mas que é algo semelhante ao que acontece com a gestão do produto (digital).
Gestão de Produtos
A gestão de produto (Product Management) e a gestão de projetos (Project Management) são disciplinas distintas que, embora possam se sobrepor em algumas áreas, têm objetivos, responsabilidades e focos diferentes. A gestão de produto concentra-se no ciclo de vida completo de um produto, desde a concepção até a descontinuação, garantindo que o produto atenda às necessidades do mercado e dos clientes. O gestor de produto (Product Manager) é responsável por definir a visão do produto, planejar a estratégia de desenvolvimento, priorizar funcionalidades e trabalhar em estreita colaboração com equipes de desenvolvimento, marketing e vendas para garantir o sucesso contínuo do produto.
Conclusão
Ou seja, enquanto a gestão de produto é uma função estratégica e contínua, a gestão de projetos é uma função tática e finita, cada uma essencial para o sucesso organizacional nas suas respectivas áreas.
Scrum - Eficiência vs Eficácia
Para melhor leitura e compreensão deste post, aconselho a leitura do último post publicado no blog intitulado Scrum para “Dummies”: Papéis e Eventos – Comparação com o Futebol
Há muitos anos, antes da popularização da framework Scrum e das metodologias ágeis, aprendi (com muita ajuda do meu avô) sobre a importância da melhoria contínua com base nas Normas ISO, destacando a diferença entre eficácia e eficiência. A distinção é simples: eficácia significa fazer as coisas certas, enquanto eficiência envolve fazer as coisas bem.
Comparando isso ao futebol, a eficácia seria a equipa marcar golos, enquanto a eficiência seria jogar bem. Assim como no futebol, a beleza artística das equipas a jogar não garante vitórias, mas certamente que poderá aumentar a probabilidade que a eficácia – golos – aconteça.
No contexto do Scrum, essa distinção também se aplica. Podemos ser eficientes sabendo trabalhar muito bem com ferramentas de gestão de backlog, organizar o sprint backlog, ou agendar todas as cerimónias regularmente no mesmo local e horário, demonstrando eficiência.
No entanto, é crucial questionar se somos eficazes. Estamos a fazer as coisas certas? Estamos a cumprir com as metas da sprint? Estamos a entregar outcomes em vez de features? Estamos a entregar valor?
Uma nota de rodapé e recordando minha experiência na implementação de Sistemas de Gestão da Qualidade, lembro-me do Ciclo PDCA – Planear, Executar, Controlar e Agir. Ao observar de perto, percebo que o Scrum segue um padrão semelhante. Temos o Sprint Planning, a execução dos trabalhos durante a sprint, o controlo (no Scrum chama-se de inspeção) nas cerimónias e a ação, evidenciada na Retrospective e na Review.
Scrum para “Dummies”: Papéis e Eventos - Comparação com o Futebol
Introdução
Escrevi este artigo para consolidar conhecimentos na framework Scrum e preparar-me para o exame de certificação de Professional Scrum Master.
A comparação com o futebol visa tornar mais claro o que é e como funciona esta framework. Muitas pessoas de diversos setores desconhecem esta metodologia ágil. Para aqueles que a conhecem, mas não a aplicam corretamente, espero que esta comparação seja esclarecedora e produza os efeitos desejados.
Naturalmente, esta é uma comparação “bruta” e superficial e por isso deve ser interpretada com um “grain of salt”.
Vamos então…
Os Papéis
Scrum Master
O Scrum Master é a pessoa na equipa Scrum que deve compreender melhor a framework Scrum e uma das suas responsabilidades é disseminar esse conhecimento pela organização e, por conseguinte, pela equipa Scrum.
Assim, pode-se dizer que os árbitros, por compreenderem melhor as regras do futebol, desempenham no futebol o papel equivalente ao do do Scrum Master.
Product Owner
Considerando que o Dono do Produto tem como função principal gerar retorno do investimento do produto para a empresa, o papel semelhante no futebol poderá ser o treinador principal.
O equivalente a uma equipa de futebol pode ser o treinador principal. Contudo, é importante notar que enquanto o treinador principal de uma equipa de futebol é o líder desta equipa, o Product Owner não lidera ninguém na Equipa Scrum.
Developers
Os developers são as pessoas responsáveis por gerir/auto-gerir os trabalhos da sprint para que, no final desta, se atinja a meta e se produza um incremento com a qualidade e valor esperados.
No futebol, os developers são os jogadores de futebol.
Os Eventos de uma Sprint
Sprint Planning
O Sprint Planning é o evento que dá origem à sprint. Neste evento, o Product Owner, em conjunto com a equipa de developers, define a meta da sprint. Após definida a meta, é necessário determinar quais os itens do product backlog que serão incluídos no sprint backlog (assumindo que todos estão prontos). Por último, os developers “quebrarão” essas histórias em atividades a desenvolver ao longo da sprint.
No futebol, o treinador, juntamente com os membros da equipa, define o plano de jogo para o próximo encontro. Decide quais jogadores irão participar e como deverão jogar para cumprir o plano. Pode haver substituições durante o jogo e, da mesma forma, ao longo da sprint, através da inspeção e adaptação, podem ocorrer ajustes, sempre em concordância com o Product Owner.
Daily
A Daily é um evento do Scrum com uma timebox de 15 minutos, destinado aos developers realizarem a inspeção e adaptação. Não é necessário que o Scrum Master ou o Product Owner estejam presentes, a menos que estejam a trabalhar num item.
Para o futebol, com as devidas exceções de timebox, a Daily é o treino diário físico. Dado que a equipa já conhece as atividades físicas a realizar e, mesmo no treino tático, o treinador principal não intervém muito. Pelo menos, quando se trata de uma equipa experiente com automatismos para diferentes tipos e planos de jogo. A inspeção nas cerimónias ocorre, evidenciada na Retrospective e na Review.
Quem nunca reparou nos treinos (dailies) da Seleção Portuguesa de Futebol o selecionador a andar de um lado para o outro do campo, com as mãos atrás das costas, cabeça baixa e pensativa?
Sprint Review
O evento Sprint Review é o momento em que os stakeholders e a Equipa Scrum inspecionam e adaptam o que foi feito, para perceber se a equipa está a cumprir a meta do produto.
Considero que o evento da Sprint Review é o próprio jogo de futebol. Aqui, os jogadores apresentam (jogam) perante os sócios e outras pessoas (stakeholders) o que estiveram a trabalhar ao longo da sprint (uma semana entre jogos para o campeonato nacional), onde ocorreram as diferentes “dailies”.
A inspeção do plano de treino (meta da sprint) e das atividades em desenvolvimento (itens do backlog) está a ser realizada e adaptada. Inclusive, no futebol, esta inspeção e adaptação ocorrem frequentemente ao intervalo.
Sprint Retrospective
O evento Sprint Retrospective é o momento em que se planeia a qualidade e a eficácia.
No futebol, é o momento em que se analisa o que correu bem e mal, avalia a performance dos jogadores (não aplicável no Scrum), verifica-se o estado físico e psicológico dos jogadores, e vice-versa. Com toda essa informação, devem surgir melhorias para o próximo jogo.
A Meta da Sprint
Não é nem um papel, nem um evento, mas acredito que faça sentido mencioná-la. E falo da Meta da Sprint. É aquilo que queremos entregar como incremento e com valor. Ou seja, a Meta da Sprint deve responder à questão: Porque esta sprint é valiosa.
Na linguagem do futebol, a Meta da Sprint seria o Plano de Jogo da equipa para enfrentar a equipa adversária na próxima jornada. E esse plano de jogo tem subentendido o porquê daquela sprint (semana do campeonato) ser importante para a equipa.
Espero que tenham gostado do artigo. A área de dados, nomeadamente a área de MarTech é uma área na qual me estou a debruçar devagarinho.
Want to read this article in English? Please click here
Será Diferente Criar um Produto Digital em Ambiente Agile ou Waterfall?
Introdução
Já vimos na PARTE 1 – O que são Produtos Digitais. E na PARTE 2 – O que Envolve Criar Produtos Digitais? E como o Tema está Relacionado com o Scrum.
Vamos agora ver na PARTE 3 – se Será Diferente Criar um Produto Digital em Ambiente Agile ou Waterfall?
Ambiente Waterfall
Em ambiente waterfall significa, de forma não exaustiva, o seguinte:
- O tipo de projeto não envolve incertezas. Ou seja já se sabe o que se vai desenvolver/construir. Por exemplo, uma casa ou uma piscina.
- As as atividades desse projeto, por estar inserido num ambiente de certeza e não de incerteza, são desenvolvidas sequencialmente. Ou seja, após o términos de uma atividade, começa-se a segunda.
- Não existe um envolvimento direto do cliente e, por conseguinte, não é costume haver iterações à medida que as atividades vão sendo desenvolvidas
- Havendo possibilidade e vontade em fazer testes, estes são feitos em grande escala no final de todas as atividades estarem concluídas
Ambiente Agile
O ambiente agile significa, o contrário do ambiente waterfall. Ou seja, e de forma não exaustiva:
- Os projetos mais adequados para serem desenvolvidos neste tipo de ambiente são projetos complexos e que envolvem algum grau de incerteza. Por exemplo, o desenvolvimento de um produto digital, enquadra-se neste tipo de projetos.
- Todas as atividades que se consideram necessárias para produzir um incremento, são realizadas no sprint correspondente. E, portanto, daqui surgem duas grandes diferenças de projetos em ambiente waterfall e ambiente agile:
- As equipas devem ser multi-disiplinares e autónomas
- Os testes, devem ser considerados uma atividade que produz um incremento e, portanto, são realizados em cada sprint e não no final do projeto. Até porque, e passamos para o ponto 3…
- Tem de existir um envolvimento direto do cliente. Isto porque não sabemos a 100% como vai ser o produto final. E o cliente também não sabe. E, portanto o cliente tem de estar envolvido no desenrolar do projeto. Por exemplo, criando atividades de UX Research na fase em que Visão do Produto está a ser desenvolvida. E com isso, valorizamos e muito o início do projeto, porque a Visão do Produto incorpora findings e insights daquilo que são as necessidades, frustrações e motivações dos cliente.
- Outra altura onde o cliente pode estar presente será nas cerimónias de review para recolha direta de feedback. e, por conseguinte, não é costume haver iterações à medida que as atividades vão sendo desenvolvidas. Ou seja, e vamos para o ponto 4…
- Há iterações entre as equipas, clientes e stakeholders. Iterações essas que nos vão permitindo afinar o produto final. Como? Redefinindo e refinando o backlog prioridades de produto e, posteriormente, o backlog da sprint.
Conclusão
Poder-se-ia dizer que se as metodologias, ou melhor, se os ambientes ou frameworks são diferentes, então, obrigatoriamente, será diferente criar um produto digital em ambiente agile do ambiente waterfall. E dizer isto não está errado. Afinal é uma verdade de La Palice.
O problema é que não basta dizer que estamos ou adotamos uma metodologia agiela e o desenvolvimento do produto digital, per si, será diferente.
Quem faz os ambientes serem waterfall ou agile ou de outro tipo são as pessoas. E, portanto, se não houver vontade, motivação, aprendizagem e um step-up, sem medos e com compreensão 100% da hierarquia de quais são os papéis de cada um e o que isso implica, para mudar a cultura da Empresa e assim efetivamente implementar o ambiente agile, o que vai acontecer é que estaremos a desenvolver um produto digital em ambiente “pseudo-agile”; ou seja na realidade o ambiente é waterfall.
Há várias de formas de perceber isso, elenco apenas quatro:
- O cliente não é envolvido de início e ao longo do desenvolvimento
- As equipas não são multi-disciplinares nem autónomas
- A priorização das atividades ou a re-priorização das mesmas ou de algumas delas, não é feita pelo PO, mas está dependente do cargo da pessoa que faz um pedido.
- Os testes são feitos “em barda” dias antes do lançamento do produto para o mercado
Espero que tenham gostado e aprendido alguma coisa neste conjunto de 3 artigos sobre produtos digitais.
O que Envolve Criar Produtos Digitais? E como o Tema está Relacionado com o Scrum
Introdução
Já vimos na PARTE 1 – O que são Produtos Digitais. Vamos agora ver o que envolve, em termos de negócio e de equipas, criar um produto digital.
A PARTE 3 – Será Diferente Criar um Produto Digital em Ambiente Agile ou Waterfall? Será publicada no final do mês de Agosto.
O que Envolve Criar um Produto Digital?
Criar um produto digital não é pensar o design e depois bater código. Desenvolver um produto digital envolve muito mais do que design e desenvolvimento. Tal como a construção de uma casa não envolve apenas um desenho do arquiteto. Ainda que a construção de uma casa seja um projeto fechado e um projeto que decorre em ambiente certo.
Existem diferentes temas que são essenciais para descobrir, posicionar, desenvolver, monitorar, comunicar e impulsionar a adoção deste tipo de produtos.
Visão do Produto – Envolve identificar os diferenciais do produto, definir a proposta de valor única e criar mensagens de marketing que comuniquem esses aspectos de maneira convincente.
User Experience Research – Antes de se criar um produto digital, é crucial realizar perceber quais as necessidades, motivações, frustrações, expectativas e emoções dos clientes ou potenciais clientes.
O trabalho de desenvolvimento de um produto digital deve ser feito com base em Outcomes e não em Outputs.
As atividades de UX Research fornecem uma base sólida para as decisões de design, permitindo que as equipas validem hipóteses, identifiquem problemas de usabilidade e iterem rapidamente com base no feedback dos utilizadores. Além disso, o foco contínuo nas atividades de UX Research possibilita a adaptação às mudanças ao longo do projeto, tornando o Scrum ainda mais eficiente e eficaz na entrega de soluções inovadoras e centradas no usuário.
User Interface Design – Aspeto fundamental do processo de desenvolvimento de produtos, dedicado a criar interfaces visualmente atraentes e user friendly que melhoram a experiência geral dos utilizadores. Estas atividades de desenho do user interface concentram-se em temas que permitam desenvolver interações entre os utilizadores e esses produtos digitais, garantindo que cada interação seja fluida e intuitiva
O User Interface Design não é só algo estético; deve haver um esforço para se encontrar o equilíbrio entre forma e função. Um interface bem pensado (UX Research) guiará os utilizadores ao longo do produto de forma suave e sem atritos, ajudando-os a realizar as suas atividades de forma eficiente e com o mínimo de frustração.
Podem saber mais sobre o tema Como Definir os Princípios de Design.
UX Writing ou Marketing de Conteúdo – A criação de conteúdo relevante e valioso é fundamental para a atração e retenção de potenciais utilizadores dos nossos produtos. O UX Writing não se restringe só à escrita de textos para blogues. Todo o conteúdo de um website ou loja online ou de outro produto digital deve ter uma estratégia de UX Writing. Além dos de vídeos, animações, white papers ……
E é preciso saber como escrevê-los; onde colocá-los no nosso produto e quando colocá-los.
SEO – A otimização para os motores de pesquisa é fundamental para garantir que o produto digital seja encontrado online, quando os utilizadores pesquisarem por keywords relevantes. Isso envolve a criação pensada e estruturada da arquitetura de Informação desse produto digital, a inserção/utilização adequada de keywords de forma a otimizar o conteúdo e a criação de backlinks.
O UX Writing ou Marketing de Conteúdo e o SEO são disciplinas que têm muita interligação entre si.
Acessibilidade – A acessibilidade no contexto do design, dentro de uma equipa que utiliza o Scrum, refere-se às atividades e práticas implementadas para garantir que o produto desenvolvido seja inclusivo e facilmente utilizado por todas as pessoas, independentemente de suas capacidades e/ou necessidades específicas. Este tema, tal como os anteriores e os a seguir devem ser considerados pelas equipas desde o início das atividades do projeto, incorporando-a em todas as etapas do ciclo Scrum.
Este tema, deverá ser também tido em conta aquando das atividades de UX Research. Podem ler mais sobre Empathy as a Service.
Analytics — Desempenha um papel fundamental no desenvolvimento de produtos dentro de um ambiente ágil. Ao aproveitar o poder dos dados e os insights que se obtêm a partir deles, as equipas podem tomar decisões informadas em cada etapa do processo de desenvolvimento.
Análises qualitativas — A incorporação de análises qualitativas capacita as equipas a adaptar estratégias com base no feedback dos clientes e em tempo real, garantindo que as suas necessidades, motivações, frustrações são tidas em conta no desenvolvimento do produto.
Análises quantitativas — Essas análises permitem compreensão profunda dos comportamentos, preferências e pontos problemáticos dos usuários, o que influencia significativamente o aperfeiçoamento e a otimização de produtos digitais. Podemos utilizar ferramentas de web analytics e/ou de user behaviour analytics.
Desenvolvimento – As atividades de desenvolvimento é tudo aquilo que engloba colocar em prática todo o trabalho desenvolvido nas atividades anteriormente descritas. O trabalho de desenvolvimento não é só olhar para o “design” e começar a programar. Algumas atividades que devem ser tidas em conta antes do desenvolvimento front-end e back-end apresentam-se abaixo.
-
- Arquitetura funcional
- Arquitetura técnica
- From-end development
- Back-end development e Gestão de Base de Dados
- Integração de sistemas e desenvolvimento de infra-estruturas
Testes – Em ambiente agile todas as user stories devem ser testadas pelo membro da squad para o efeito. Desenganem-se aqueles que acreditam que os testes são feitos pelas pessoas das organizações ou que se podem fazer depois testes de usabilidade com os clientes. Deixarmos a realização dos testes, com as funcionalidades já em produção, para outras pessoas e/ou para os clientes fazerem é meio caminho andado para que a dívida técnica/UX aumente. Além de que não cumpre com aquilo que a framework do scrum apregoa.
-
- Testes de Carga do Servidor
- Testes das Funcionalidades
- Produção de quick reports com as respetivas conclusões/correções a fazer
Depois numa fase já mais estabilizada do produto, podemos desenvolver então os testes com os utilizadores.
Gestão da Release – A gestão da release no contexto do Scrum refere-se ao processo de planeamento, coordenação e entrega dos outputs, sempre baseados em outcomes (o que defendo) desenvolvidas ao longo das várias sprints pronto para ser disponibilizado aos utilizadores.
Muito importante na gestão da release, nomeadamente se for uma gestão da release já com o produto “fechado” (se bem que o produto nunca estará fechado) é a definição da estratégia de lançamento.
Estratégia de Lançamento – A estratégia de lançamento engloba as atividades que têm como objetivo informar os utilizadores sobre as diversas vertentes do produto. A estratégia de lançamento focam-se, na sua maioria, em temas de comunicação como:
- Campanhas offline (TV, rádio, jornais, revistas, outro tipo de publicações)
- Organização de Eventos
- Campanhas online (e-mail, ppc, social media, afiliados, ….)
- Redes Sociais
- Influenciadores
Conclusão
É fundamental ter em atenção a todos estes temas quando se desenvolve um produto digital, seja em ambiente agile ou ambiente waterfall. Nomeadamente, é imperativo considerar estes temas em cada uma das fases dos ambientes agile:
- visão do negócio/produto
- Desenvolvimento do backlog do produto
- Desenvolvimento do backlog da sprint (Priorização de acordo com aquilo que é a visão do negocio)
- Cerimónias de Planeamento
- Cerimónias de Review
- Cerimónias de Retrospective
Além disso, fica bem patente, tal como o Scrum advoga, que um desenvolvimento de um produto digital não é só desenhar e programar o desenhado.
Sabe mais sobre Scrum neste artigo – Scrum for Dummies”: Papéis e Eventos – Comparação com o Futebol
O que são Produtos Digitais?
Introdução
Quando pensei escrever este artigo tinha imaginado um título do género “Como gerir projetos digitais (ou não) que são transversais à Empresa e/a determinado produto digital em ambiente agile”. Mas dediquei algum do meu tempo a pensar no assunto e percebi que o título não faz sentido algum.
E para não tornar o artigo demasiado longo dividi-o em 3 partes:
PARTE 1 – O que são Produtos Digitais
PARTE 2 – O que Envolve Criar um Produto Digital
PARTE 3 – Será Diferente Criar um Produto Digital em Ambiente Agile ou Waterfall?
O que são Produtos Digitais?
Um produto digital é todo o produto que pode ser utilizado e/ou comercializado online. Ou seja, podemos ter como produtos digitais aqueles que são passíveis de download e aqueles que não são passíveis de download:
Produtos Digitais Passíveis de Download
- Produtos que os utilizadores podem fazer o seu download e começam a utilizá-lo. Por exemplo uma App para afinar a guitarra como o Guitar Tuner.
Produtos Digitais Não Passíveis de Download – SAAS / Cloud Software
- Produtos em que os utilizadores não necessitam de fazer download dos mesmos e ainda assim utilizá-los na modalidade de free, paga ou freemium. Todos os Softwares As a Service são este tipo de produtos. Por exemplo, a Google Cloud Platform funciona como SAS.
Produtos Digitais como Extensão da Experiência de Cliente – Canal Online
Depois ainda existe uma categoria de produtos digitais que são um misto entre as duas categorias acima. E que eu caracterizo não como produtos digitais, mas sim como táticas ou canais de comunicação com os utilizadores. Por exemplo:
ebooks – livros; Webinars – Conferências; PodCasts – Entrevistas; Cursos online – aulas presenciais; Websites/Lojas Online – sede ou loja física
Conclusão
A criação de produtos digitais, não é desenhar e desenvolver o front-end desse desenho. Nem é desenvolver o back-end desse front-end.
Pensar em desenvolvimento de produtos digitais com foco apenas em design, front-end e back-end vai dar origem a:
1 – Potenciais MVPs mal definidos
2- Desenvolvimento de produtos com base em features (outputs) e não outcomes (mudança que queremos ver no mundo ou nas pessoas para que a vida delas se torne melhor)
3 – Dívida Técnica com uma enormidade de bugs e issues para corrigir
4 – Custos escondidos – de desenvolvimento ou de redesenvolvimento; horas-extra da equipa; possíveis custos no suporte ao cliente, entre outros
Será isto fácil de implementar nas empresas? Certamente que não o é! Mas é meio caminho se as pessoas envolvidas tiverem esta visão e a colocar em prática, mesmo que devagar este princípio.
O próximo artigo PARTE 2 – O que Envolve Criar um Produto Digital