Data Science - Tipos de Análise de Dados
Introdução
Todas as análises depende da pergunta de quem precisa dessa análise, da interpretação dessa necessidade e esclarecimentos da pergunta e noção ou descoberta de bloqueios. E só após isso é que se percebe qual o tipo de análise de dados vai ser necessária fazer e se é possível fazer na sua integridade ou não.
O QUÊ?
Análise Descritiva – Dados para tomar uma decisão, entender uma ação realizada ou antecipar um comportamento.
Esta análise tem como principal objetivo descrever o que aconteceu ou o que está a acontecer num determinado momento. Deve estar sempre limitada ao âmbito do projeto, utilizando técnicas estatísticas para resumir os dados brutos.
Principais características:
- Medidas de Tendência Central: média, moda, mediana
- Medidas de Dispersão: variância, desvio padrão, quartis
- Visualizações: gráficos de colunas, barras, linhas, dispersão, correlação
- Identificação de tendências e padrões nos dados
- Exploração inicial dos dados, permitindo detectar problemas e entender a distribuição
Exemplo:
Vendas do produto X nos últimos 3 anos.
Objetivo: entender o estado da métrica e o comportamento dos atores que influenciam essa métrica.
A análise pode ser encerrada aqui, ou pode seguir para uma análise mais aprofundada – análise de diagnóstico.
PORQUÊ
Análise Diagnóstica – Dados para entender as causas por trás do que foi identificado na análise descritiva.
Esta análise tenta responder ao “porquê” de um fenómeno acontecer, identificando relações e padrões que ajudam a explicar as variações observadas.
Principais características:
- Investigativa por natureza
- Baseada em hipóteses, priorizando aquelas que devem ser testadas primeiro
- Utiliza dados históricos para compreender comportamentos
- Multivariada, já que normalmente não há uma única causa para um fenómeno
- Requer interpretação cuidadosa e um conhecimento mais avançado de estatística
- Evolui naturalmente a partir da Análise Descritiva
- Técnicas utilizadas: regressão, correlação, análise de clusters (clusterização), entre outras
Exemplo:
O número de conversões diminuiu no último mês.
Objetivo: identificar as causas possíveis para essa diminuição, como mudanças no comportamento do consumidor, campanhas de marketing ou fatores externos.
A análise pode ser encerrada aqui, ou seguir para prever o que poderá acontecer no futuro.
QUANDO?
Análise Preditiva – Esta análise procura antecipar eventos futuros com base em dados históricos e técnicas de modelagem estatística.
Principais características:
- Criação de modelos para prever comportamentos futuros
- Baseada em dados históricos, com ajustes e simulações
- Utiliza análises multivariadas
- Insere-se no campo da Ciência de Dados
- Emprega Machine Learning e modelos estatísticos
- Reduz a dependência de suposições baseadas apenas em experiência
- Fornece orientações às equipas de negócio sobre o que pode vir a acontecer
Exemplo:
Com base nos dados dos últimos 3 anos, é possível prever as vendas do produto X para o próximo trimestre, considerando fatores como sazonalidade, comportamento de clientes e campanhas previstas.
A análise pode ser encerrada aqui, ou pode avançar para uma análise prescritiva, indicando o que deve ser feito com base nas previsões.
COMO?
Análise Preescritiva – Dados para recomendar ações futuras.
É o nível mais avançado de análise, oferecendo recomendações específicas sobre o que fazer após as análises anteriores.
Principais características:
- Suporte à tomada de decisão baseada em dados (data-driven)
- Redução de riscos nas decisões
- Baseia-se em simulação de múltiplos cenários
- Considera diferentes variáveis e restrições
- Pode utilizar técnicas de otimização, modelagem matemática e sistemas de apoio à decisão
Exemplo:
Com base na previsão de queda nas vendas do produto X, a análise preescritiva pode recomendar o melhor mix de canais de marketing, distribuição de orçamento e ações promocionais para mitigar essa tendência.
Conclusão
As diferentes análises – Descritiva, Diagnóstica, Preditiva e Preescritiva – formam um ciclo contínuo de melhoria e aprendizado a partir dos dados.
Cada uma tem seu momento e valor dentro de uma estratégia de análise mais ampla e, quando combinadas, ajudam as organizações a compreender melhor o presente, explicar o passado e moldar o futuro com decisões mais informadas.
Data Science for Business Strategy
Introdução
O objetivo deste artigo e dos possíveis artigos seguintes é o de acompanhar os estudos que estou a fazer na Pós-Graduação em Data Science for Business Strategy da Universidade Nova – Faculdade de Ciência e Tecnologia.
É também uma forma de estudar a tentar assimilar melhor os conteúdos ministrados.
O que é Data Science
Data Science, em português, é a Ciência de Dados. OK. Mas o que significa Ciência de Dados? Se formos traduzir DataScience é a Ciência de trabalhar os dados.
Vamos analisar uma definição mais conceptual de Data Science.
Data Science é uma área interdisciplinar que utiliza métodos científicos, processos, sistemas, ferramentas e algoritmos para extrair insights e inteligência dos dados, com o objetivo de descobrir padrões, gerar novos insights para informar o processo de decisão.
Conceitos importantes a reter:
- Interdisciplinaridade – É uma disciplina que envolve 3 disciplinas: estatística, ciências da computação, conhecimento de negócio
- Método Científicos, Processos, Algoritmos e Sistemas – Métodos científicos porque um projeto de Data Science envolve a constatação de um problema, uma declaração de hipóteses e a execução de testes para não rejeitar ou rejeitar a hipótese inicial.
- Processos – Envolve seguir um procedimento, ou seja e por exemplo…não se deve começar a trabalhar os dados sem antes termos feito: 1) o entendimento dos dados, 2) o tratamento dos dados e 3) a análise exploratória dos mesmos.
- Algoritmos – Os algoritmos nada mais são do que um conjunto de procedimentos que levam à criação de um processo. Quando, por exemplo somamos 1 + 1 isso é o algoritmo da soma. Ou quando o fazemos tendo a expressão 1 + 1 * 3.
- Ferramentas – As ferramentas, nomeadamente as tecnológicas auxiliam-nos na execução das disciplinas que compõe a disciplina maior de Data Science: Matemática e Estatística, Ciências da Computação e (Conhecimento do Negócio.
Depois desta definição mais teórica, a minha definição de Data Science é simples: Em termos de conteúdo eu diria que Data Science é o estudo dos dados de modo a conseguir responder a perguntas sobre um ou mais problemas que têm o seu enquadramento no contexto atual e que, concumitantemente ou não, nos permite também descobrir e aturar no naquilo que poderá ser o contexto futuro. Relativamente à forma eu diria, que todo o conteúdo da definição pode e deve ser feito através de pergunta críticas e curiosidade, análises quantitativas e qualitativas, visualizações de dados e comunicação.
As Disciplinas que Compõe Data Science
Então, Data Science envolve três disciplinas: Matemática/Estatística, Ciências da Computação e Conhecimento de Negócios. E estas 3 disciplinas embora possam sejam áreas distintas e devem sê-lo também a nível empresarial e de constituição de equipas e departamentos de Data Science, elas intersectam-se.
Os Papéis em Data Science
A disciplina de Data Science é colaborativa, como tantas outras disciplinas técnicas (e Data Science não é só parte técnica) como Digital Marketing, Product Management, UX-Research. E por serem colaboravas as Empresas devem ter papéis e responsabilidades bem definidas para o efeito…mas sobre este tema talvez faça um publicação só sobre isso – “A Falta de Conhecimento Real sobre o que as Empresas necessitam”. Normalmente o que as Empresas Portuguesas querem para todas as áreas são “Full-Stack Unicorns”.
Portanto, num mundo real e ideal, ou seja, no mundo onde as Empresas querem a serio criar e desenvolver equipas dentro da áreas de Dados e Data Science motivada, interdisciplinar e que cresça, terá na sua génese as funções e responsabilidades seguintes:
NÃO EXAUSTIVO
- Data Engineers (Database Administradores de Bases de Dados e Desenvolvedores de Software) – Têm o seu foco no back-end: desenho e concepção das estrutura dos servidores, desenho, arquitetura e administração das bases de dados, desenvolvimento particular de software específico, servidores e nas bases de dados. É quem fornece a base para que todo o restante trabalho possa ser desenvolvido.
- Big Data Specialists (Machine Learning Engineers, Computer Science Engineers) – Têm o seu foco no desenvolvimento de algoritmos de Machine Learning por forma a que se consiga processar e analisar grandes quantidades de dados, e responsáveis também, se necessário, pela criação de “Produtos de Dados”. Um produto de Dados pode ser um dashboard, mas a este nível estamos a falar mais de produtos de dados que ajudam as pessoas por exemplo qual o melhor produto que ela pode comprar se já comprou os produtos a, b,c,d.
- Database Administradores de Bases de Dados e Desenvolvedores de Software) – Têm o seu foco no back-end: desenho e concepção das estrutura dos servidores, desenho, arquitetura e administração das bases de dados, desenvolvimento particular de software específico, servidores e nas bases de dados.
- Data Analysts – Têm o seu foco no dia a dia do negócio e na análise dos respectivos dados. Podem ser por exemplo análises de dados web, análises de dados de produto, análises de dados de RH e por ai fora. Importante ter conhecimento de SQL, consoante o volume de dados
- Business Analysts – Têm o seu foco nas perguntas importantes para o negócio (tal como os Data Analysts) e gerem ou podem gerir projetos relacionados com dados.
Este artigo pode vir a ser adaptado e complementado ao longo de 2025
Como Fazer e Interpretar uma Análise de Cohort: Exemplo Prático
O exemplo de construção e análise de Cohort apresentado no artigo faz parte do portfólio de trabalhos que fiz durante a formação em Análise de Dados da Comunidade DS.
O que é a Análise Cohort
A Análise de Cohort é uma técnica de analítica cujo objetivo é caracterizar pessoas ou eventos que tenham em comum uma determinada característica durante um determinado período de tempo, e com isso observar o seu comportamento ao longo desse período temporal.
Dando um exemplo simples do nosso quotidiano e depois passando para o ambiente online de desenvolvimento de produtos digitais.
Exemplo offline: Imaginando que vais almoçar fora com os teus pais, mais com os teus 2 irmãos e com os teus avós ao restaurante “Almoça Aqui”. E imagina que esse almoço foi o almoço do primeiro dia do ano – 1 Janeiro de 2025.
Ou seja, e considerando apenas a tua família, o restaurante “Almoça Aqui” recebeu no dia 1 Janeiro de 2025, 7 pessoas, nesse dia, mês e ano. E tu e a tua família, partilham uma característica em comum: foram almoçar a esse restaurante simultaneamente nesse dia.
Soubeste que os teus pais foram jantar ao restaurante no dia seguinte com mais um casal de amigos e o seu filho de 7 anos (considera novamente apenas os teus pais e o casal de amigos como únicos clientes nesse restaurante ao jantar).
E tu foste no dia 3 de janeiro, com a tua namorada e fechaste o restaurante só para vocês e fizeste-lhe uma surpresa :).
Soubeste mais tarde pelos teus pais que o casal de amigos dos teus pais foi ao restaurante no mesmo dia que foste com a tua namorada, mas almoçar.
Ou seja e em termos de Análise de Cohort, teríamos que se representa na tabela abaixo:
|
Primeira visita / Atividade |
Dia 1.1.25 |
Dia 2.1.25 |
Dia 3.1.25 |
|
Dia 1.1.25 |
7 |
2 |
1 |
|
Dia 2.1.25 |
– |
3 |
2 |
|
Dia 3.1.25 |
– |
– |
1 |
Exemplo de E-commerce: O exemplo de e-commerce segue exatamente, mesma lógica, sendo que desta vez estamos a analisar meses.
|
First-purchase / Atividade |
Jan 25 |
Fev 25 |
Mar 25 |
|
Jan 2025 |
1000 |
700 |
300 |
|
Fev 2025 |
– |
600 |
400 |
|
Mar 2025 |
– |
– |
500 |
Notas Importantes
- A característica comum às pessoas, não precisa de ser obrigatoriamente a primeira visita, ou a primeira compra. Pode ser, por exemplo e para o caso do restaurante o “prato” escolhido. E para o caso de e-commerce a categoria de produto comprado “sapatos”. A característica escolhida para a análise depende da própria análise que se pretende fazer.
- Mais à frente veremos melhor a interpretação dos dados da tabela de Análise de Cohort. Aqui quero apenas deixar a nota que, por exemplo para o dia 2 de Janeiro de 2025 (que será a data de cohort) a célula 1 de Janeiro de 2025, porque esse cohort/safra não existia (logicamente) nesse dia. O mesmo raciocínio aplica-se para os meses na loja online
Para que serve a Análise Cohort
O objetivo principal de uma Análise Cohort é para medir o comportamento das pessoas na utilização de um determinado produto ou serviço. Agora esse comportamento traduz-se nalguma métrica que pode variar, consoante as características dos grupo que foi selecionada:
- Retenção
- Life-Time Value
- Melhores Produtos
Que Dimensões e Métricas Precisamos para fazer uma Análise Cohort
As dimensões estarão relacionadas com o tempo ou inteligência de tempo. No exemplo do Restaurante estaríamos a falar da dimensão de tempo em dias. Já no caso do E-commerce a dimensão de inteligência de tempo seria o mês.
Outra dimensão que vamos precisar e que, de certa forma está relacionada com o tempo é, no exemplo do restaurante da data da “primeira visita”. E no caso do E-commerca da data da “primeira compra”.
As métricas que vamos precisar seria o Nº de primeiras visita ao restaurante e para o E-commerce, o Nº primeiras Compras.
No exemplo prático, temos de pensar no binómio “Facto-Dimensão”.
Exemplo de uma Análise Cohort feita em Excel
Enquadramento rápido:
Um Grupo de Beleza com várias lojas físicas espalhadas por Portugal, com o objetivo fazer acreditar no poder transformador da beleza e comercializar diferentes categorias de produtos de beleza.
Recentemente, foi identificado um desafio crescente: a retenção de clientes. A empresa percebeu que, embora as vendas continuem ocorrendo, a frequência de compras de clientes recorrentes tem diminuído.
O objetivo é criar indicadores que mostrem como os clientes interagem com o Grupo de Beleza ao longo de um determinado período de tempo.
Procedimento
Para não tornar o artigo longo e exaustivo, admite que todos os dados que seriam precisos estão na base de dados em Excel denominada de Customers. E nela temos as seguintes dimensões: Customer_Id, Order_Id, Order_Date.
1 – Que dimensões, métricas e factos vamos precisar
Facto:
-
- Customer_ID
Dimensões:
-
- Order_Date (Recorrência de compras) e precisamos de fazer a análise mensal
Dimensões de tempo derivadas da Order_Date:
-
- Order_Date (da primeira compra) e precisamos de fazer a análise mensal
|
Customer_ID |
Order_Date (first-purchase) |
Order_date (Recorrência) |
|
AA123 |
1.1.23 |
1.1.23 |
|
BB321 |
1.2.23 |
1.2.23 |
|
AA123 |
1.1.23 |
2.3.23 |
|
BB321 |
1.2.23 |
1.2.24 |
|
AC123 |
2.2.23 |
2.2.23 |
|
AC123 |
2.2.23 |
5.5.23 |
|
CA321 |
4.8.23 |
4.4.24 |
|
CD123 |
4.6.24 |
4.6.24 |
|
CD123 |
4.6.24 |
1.3.25 |
|
EF123 |
8.7.24 |
8.8.24 |
2 – Como vamos construir a Análise Cohort em Excel
2.1 Criar uma tabela com 3 colunas:
Coluna 1 – Customer_ID
-
- Não precisamos de fazer nenhum cálculo
Coluna 2 – Order_Date (data da primeira compra, em mês)
-
- Utilizando duas fórmulas:
- Formatar os valores de “Date” da coluna Order_Date (first_purchase) em formato custom do tipo “MM-YYYY”
- Utilizar a fórmula: =MINIFS[min_range;criteria_range1;criteria]
- Utilizando duas fórmulas:
Coluna 3 – Order_Date (recorrência de compras)
-
- Utilizando três fórmulas:
- Formatar os valores de “Date” da coluna Order_Date (Recorrência) em formato custom do tipo “MM-YYYY”
- Utilizar, por exemplo a fórmula =DATEDIF[initial_date;final_date;format], neste caso meses
- Utilizando três fórmulas:
Ou seja, vamos ter uma tabela similar a esta:
|
Customer_ID |
Order_Date (first-purchase) |
Order_date (Recorrência) |
Recorrência calculada (meses) |
|
AA123 |
1.23 |
1.23 |
0 |
|
BB321 |
2.23 |
2.23 |
0 |
|
AA123 |
1.23 |
3.23 |
2 |
|
BB321 |
2.23 |
2.24 |
12 |
|
AC123 |
2.23 |
2.23 |
0 |
|
AC123 |
2.23 |
5.23 |
3 |
|
CA321 |
8.23 |
4.24 |
8 |
|
CD123 |
6.24 |
6.24 |
0 |
|
CD123 |
6.24 |
3.25 |
9 |
|
EF123 |
7.24 |
8.24 |
1 |
4 – A Tabela de Cohort no Excel – Exemplificativa
A tabela de cohort resulta de uma pivot table em que utilizamos os facto-dimensões trabalhadas anteriormente. Ou seja, o facto será o “customer_Id” colocado em valores. E as dimensões serão em colunas e linhas respetivamente,“order_date” e “first_purchase”. Para termos os valores em %, temos de dividir o número de clientes em cada um dos meses pelo total de clientes no mês em que aconteceu a Order_Date – first_purchase.
5 – Interpretação dos Resultados
Em linha:
Conseguimos analisar a retenção dos clientes ao longo dos meses que estamos a analisar. Por exemplo, analisando a primeira linha, percebemos que dos clientes que fizeram a primeira compra no mês 0, só cerca de 10% voltaram a comprar no mês seguinte e nenhum comprou no 3º mês.
Podes analisar a média de cohorts, tendo em atenção o período de maturação do cohort. Por exemplo, considerando um mês
Em coluna:
Conseguimos analisar a retenção de novos clientes, e em relação aos níveis de retenção do mesmo mês. Considerando o exemplo de cima, verificamos que na 2ª linha e no mês 1, ao invés dos 9,9% de retenção, foi conseguida uma retenção de cerca de 17% e no mês seguinte de 8%.
O melhor cohort foi o mês de Novembro, analisando a retenção para um mês, e teve cerca de 24% de retenção de clientes.
Este tipo de análise, certamente que poderá ser feito recorrendo a outras ferramentas, como SQL, Python ou até mesmo em ferramentas já “prontas” como o GA4 que nos proporciona uma análise de cohort para o número de visitas. Tudo depende do conhecimento do problema e do conhecimento e da disponibilidade das ferramentas disponíveis.
Os Diferentes tipos de Valores do Produto associados aos seus Riscos de Desenvolvimento
Acredito que os quatro tipos de valor do produto – valor financeiro, valor social, valor psicológico e valor funcional – podem ser associados aos cinco riscos no desenvolvimento de produtos, definidos por Marty Cagan no seu livro Inspired e que estou a ler.
Ora vejamos:
1. Risco de Usabilidade e Valor Psicológico
Valor Psicológico – Este valor está relacionado mais ao campo interno e subjetivo da satisfação e do significado que o produto nos pode proporcionar. Produtos que oferecem valor psicológico vão além do seu valor funcional, do valor financeiro.
Na minha opinião este Valor está relacionado com o Risco de Valor de Negócio e/ou com o Risco Financeiro.
Quando se define uma estratégia financeira para o preço deve-se ter o valor psicológico em conta e o mesmo deve ser comunicado em ações de product marketing e/ou product growth.
#MVP #UXResearch #ProductManagement
2. Risco de Exequibilidade Técnica e Valor Funcional
Valor Funcional – Este valor do produto deve questionar ou melhor, responder à questão: “O produto satisfaz uma necessidade específica ou resolve um problema particular?”.
É o valor mais tangível do produto, fundamentado na utilidade e no pragmatismo. Compreender este valor do produto é compreender o seu propósito — o resultado concreto e prático que o produto oferece aos utilizadores.
O Valor Funcional, na minha opinião, é afetado diretamente pelo Risco de Viabilidade Técnica (Execução) já que se não houver capacidade interna para desenvolver o produto ou partes do produto, tal vai comprometer as expectativas já possivelmente cridas.
O risco de viabilidade técnica surge, ou melhor analisa-se e mitiga-se trabalhando em conjunto com as equipas de engenheiros e desenvolvimento. Ou seja, vamos avaliar se a solução proposta é exequível.
#POC #UXResearch #SolutionArchitects #DevelopmentEngineers #ProductManagement
3. Risco de Viabilidade de Negócio e Valor Financeiro
Valor Financeiro – É o valor que equilibra o custo e o benefício (valor psicológico), do produto. É o preço de venda com que o produto sai para o mercado e deve refletir não apenas os recursos materiais investidos, mas também o valor intrínseco que o produto possui. É uma medida de justiça, de quanto pedimos em troca do que entregamos e se essa troca parece justa e razoável.
O Risco de Viabilidade do Negócio está relacionado com o Valor Financeiro do Produto, porque o produto tem de ser rentável e só o é se for “saudavelmente financeiro” para a Empresa. Se o valor financeiro (ou melhor, o valor monetário) percebido pelos utilizadores não se traduzir num Modelo de Negócio viável, este risco vai aumentar.
4. Risco de Valor que se relaciona com todos os Tipos de Valor do Produto
Valor Financeiro – Se o produto não oferece benefícios financeiros claros para as pessoas e, simultaneamente, se não estiver assente no Modelo de Negócio e de pricing correto, os utilizadores poderão não comprá-lo, aumentando o risco de valor.
Valor Psicológico – Sem benefícios emocionais ou mentais (como tranquilidade ou satisfação), o produto pode não ser percebido como valioso em termos psicológicos.
Valor Funcional – Se o produto não resolve um problema importante ou não cumpre a sua função, o risco de valor funcional aumenta significativamente.
E o Risco Legal…
Por último, existe um risco que o Marty Cagan não fala, mas eu vou falar que é o risco legal. Um produto que não cumpra as requisitos legais, mesmo que tal seja difícil de compreender, de implementar ou até mesmo interfira na forma como as equipas trabalham, é um produto que mais tarde ou mais cedo vai estar condenado.
Tudo (ou quase tudo) sobre Product Market Fit
Introdução
Começo por citar Paul Graham: “O erro mais comum de startups e das empresas em geral é resolver um problema que ninguém tem.”
E porquê? Por várias razões, todas elas relacionadas com falta de estratégia e entendimento das necessidade, motivações, frustrações dos clientes.
Product Market Fit
O Product Market Fit é o estágio em que o produto já colmata as necessidades reais (ou latentes) dos clientes, atraindo aqueles com disposição para fornecer algum tipo de valor, essencialmente monetário. Os clientes demonstram isso de forma consistente, o que sinaliza o potencial efeito de escala do produto. De forma simples, o estágio de Product Market Fit significa perceber se o Produto tem/terá mercado ou não.
Portanto, o Product Market Fit é uma interseção entre o Valor para a Empresa/Clientes, Necessidades dos Clientes e Exequibilidade Técnica.
Economic Market Fit
Já o Economic Market Fit é diferente. Significa perceber se o Produto retorna valor económico para a Empresa no decorrer do tempo. E existem 2 estratégias para o atingir, manter o Economic Market Fit.
-
- Estratégias de Preço – As estratégias de preço são, essencialmente, duas:
- Penetração – Em que a Empresa assume um preço baixo para o produto para penetrar no mercado
- Desnatação – Em que a Empresa assume um preço alto para o seu produto ir “desnatando” à medida que tenciona ou vai entrando em novos mercados.
- Estratégias de Diferenciação – Em que a Empresa se foca em tornar o produto único em comparação com o dos seus concorrentes, de forma que os consumidores estejam dispostos a pagar um preço premium por ele.
- Estratégias de Preço – As estratégias de preço são, essencialmente, duas:
Independentemente da estratégia escolhida para o produto, é preciso conseguir responder às perguntas seguintes:
- As operações funcionam de forma eficiente e eficaz e são capazes de geram os proveitos suficientes para cobrir os custos que existem atualmente?
- E vamos conseguir manter este nível de performance nas operações se o volume de clientes aumentar em 20%, 40%, 60%…?
- A Empresa vai conseguir manter o preço do seu produto competitivo de forma consistente – no caso da estratégia escolhida for a de preço – no caso da concorrência aumentar?
Ou seja, Pode haver Market Fit e não haver, seja no curto no médio ou no longo prazo, Economic Fit
Matematicamente, o Economic Fit ocorre quando o CAC < LTV do cliente. Se CAC=LTV podemos dizer que a Empresa está a atingir o break-even-point com esse Produto.
Problem Solution Fit
O Problem Solution Fit é o estágio em que o produto se encontra fornecendo uma solução que resolve um problema específico do cliente ou de um segmento de clientes.
Ou seja, as Empresas cujos Produtos atingem o estágio de Product Market Fit, atingirão também o estágio de Problem Solution Fit. Mas o inverso não é verdadeiro, até porque a Solution Fit pode não ser 100% viável tecnicamente ou financeiramente.
Business Model Canvas Fit e Proposta de Valor
O Business Model Canvas é uma ferramenta estratégica que nos auxilia a mapear todos os intervenientes de um Negócio/Produto.
O Business Model Canvas, tal como por exemplo o Service Blueprint, mas para outros efeitos, é composto por duas partes: a Área que está mais visível para os clientes e a Área que está mais visível para a Empresa.
Área Mais Visível para os clientes é composta por:
-
- Segmentos de Utilizadores/Personas – Diferentes grupos de pessoas ou organizações que as Empresas têm como alvo.
- Canais – Detalha como a Empresa comunica com os seus potenciais clientes a sua proposta de valor.
- Relacionamento com os Clientes – Especifica o tipo de relacionamento que a Empresa estabelece com cada segmento de cliente, que pode ser pessoal, automatizado, entre outros. Este relacionamento visa a aquisição e retenção de clientes.
Área Mais Visível para a Empresa é composta por:
-
- Parceiros Chave – Inclui fornecedores, parceiros estratégicos e outras entidades com as quais as Empresas colaboram ou colaborarão para otimizar o modelo de negócio e reduzir riscos.
- Recursos Necessários para o Negócio – Define os ativos mais importantes que a Empresa precisa para operacionalizar o negócio, como recursos físicos, humanos, intelectuais (como patentes) e financeiros.
- Atividades Necessárias para o Negócio – Engloba as atividades essenciais que as Empresas precisam realizar para fornecer a sua proposta de valor, alcançar mercados, manter os relacionamentos com os clientes e gerar receita. Isso pode incluir produção, desenvolvimento, marketing e distribuição.
- Fluxo de Receitas – Descreve as fontes de receita das Empresas. Pode incluir vendas per si, subscrições, licenças, entre outros.
- Estrutura de Custos – Detalha os custos necessários para operacionalizar o modelo de negócio. Deve incluir os custos fixos e variáveis, como despesas com recursos humanos, custos com produção.
A “cola” que une estas duas áreas é a Proposta de Valor.
Proposta de Valor
A Proposta de Valor reflete a promessa de benefício que um Produto oferece aos seus clientes, destacando as razões pelas quais o mesmo se diferencia (parcial ou totalmente) dos produtos existentes. De forma simples, é o motivo pelo qual os clientes escolhem ou devem escolher um determinando produto em detrimento de outro(s) concorrente(s).
A proposta de valor responde claramente às perguntas:
-
- Qual problema específico o produto resolve? – Problem Solution Fit
- Quais os benefícios e/ou resultados os utilizadores obtêm ao utilizá-lo? – Product Market Fit
- O que diferencia o produto de outros concorrentes? – Product Market Fit
Componentes de uma Proposta de Valor:
- Problema a ser resolvido – Define o problema ou necessidade que o produto resolve. Deve ter em consideração uma dor ou necessidade clara dos clientes.
Exemplo: “Facilitamos a comunicação rápida e eficiente entre equipas remotas.”
- Benefícios Principais – Destaca os resultados positivos que o cliente obterá. Isso pode incluir economias de tempo, melhorias na eficiência, redução de custos ou aumento de conveniência.
Exemplo: “O nosso software reduz o tempo gasto em tarefas manuais em 50%.”
- Diferenciação – Explica por que o produto é único ou melhor em relação à concorrência. Pode estar relacionado com a inovação, com a qualidade, com a facilidade de utilização, ou com uma combinação desses fatores.
Exemplo: “Somos a única plataforma que integra todas as ferramentas de produtividade num único interface simples de utilizar.”
Como Definir uma Boa Proposta de Valor
- Uma boa proposta de valor está alinhada com um modelo de negócio sustentável, garantindo que o produto ou serviço oferece uma solução que não só atende às necessidades dos clientes, mas também gera receita suficiente para sustentar o crescimento e o negócio em termos operacionais. Os Product Managers, em conjunto com o CEO, devem garantir que a proposta de valor não só resolve um problema real, mas também que está inserida numa estrutura financeira viável.
Exemplo: O modelo de assinaturas do Spotify oferece valor para o cliente final (acesso ilimitado a música) e para o Spotify (uma receita contínua obtida através de uma subscrição para serviço premium).
- Em mercados competitivos, a proposta de valor deve se concentrar no que realmente importa para os clientes. Deve resolver os problemas mais prementes ou ajudando-o a alcançar os seus objetivos. Foco relevância significa entender o que os clientes valorizam e o que os motiva/frustra, em vez de tentar resolver todos os problemas. A proposta deve ser percebida de forma clara, transparente para o cliente.
Exemplo: O Slack foca-se na eficiência da comunicação para as diferentes equipas empresariais, tornando-se a plataforma ideal para aumentar a produtividade em ambientes de trabalho remoto ou híbrido.
- Uma proposta de valor eficaz seleciona apenas algumas tarefas essenciais ou dores dos clientes, focando nas que eles estão dispostos a pagar para resolver. Isso ajuda a manter o produto simples, mas poderoso, focando nas áreas que terão o maior impacto para os clientes.
Exemplo: A Dropbox oferece espaço de armazenagem na Cloud com sincronização automática e backup de arquivos, resolvendo o problema específico de armazenagem e segurança dos dados – algo que os clientes valorizam e que estão dispostos a pagar.
- Para criar uma proposta de valor que realmente se identifique com os clientes. Mais uma vez, é fundamental compreender as motivações, frustrações e expectativas deles em relação ao produto. Isso permite que os product managers consigam criar uma oferta de produto/serviços que vá ao encontro dos desejos/necessidades emocionais e práticas dos clientes.
Exemplo: O Airbnb identificou que os viajantes procuravam experiências mais autênticas e acessíveis, frustrados com hotéis caros e impessoais. A sua proposta de valor foca-se em fornecer estadias únicas e personalizadas, respondendo a essas expectativas.
- É importante entender como os clientes definem sucesso ao usar um produto. Isso pode ser medido em termos de economia de tempo, simplificação de tarefas, ou melhoria na performance. A proposta de valor deve refletir essa perceção de sucesso para criar uma ligação mais forte e autêntica com os clientes.
Exemplo: O sucesso para os clientes do Trello é medido pela organização e produtividade alcançadas pelos seus projetos.
- Uma proposta de valor sólida deve destacar a diferenciação do produto, ou seja, aquilo que o torna único ou superior em relação às empresas concorrentes. Essa diferenciação competitiva é o que convencerá os clientes de que o produto tem mais valor ou resolve (melhor) o problema e de forma mais eficaz do que os outros existentes no mercado.
Exemplo: A Tesla diferencia-se no mercado de automóveis não só por fabricar veículos elétricos, mas também pela inovação em tecnologia de baterias e condução autónoma e por todos os produtos, tal como a Apple, fazerem parte de um ecossistema elétrico.
- Uma proposta de valor ideal é aquela que é difícil de ser copiada a 100% pelos concorrentes. Seja por meio de tecnologias patenteadas, design exclusivo, ou um forte brand awareness. A dificuldade em replicar o produto, garante que o mesmo mantenha a vantagem competitiva ao longo do tempo ou por mais tempo.
Exemplo: A Apple tem uma proposta de valor difícil difícil de replicar, pois a mesma combina tecnologia high-tech, design icónico e centrado nas pessoas e um ecossistema integrado de hardware e software.
Podem saberes mais sobre Produtos Digitais e Gestão dos mesmos, podes consultar os artigos seguintes::
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
OKRs na Vida Real - Aplicação no Mundo Empresarial
Introdução
Os OKRs estão na moda. Mas tal não significa que devamos seguir essa moda se não estamos preparados para ela. Isto porque, implementar a metodologia de OKRs incorretamente vai custar mais à empresa e aos colaboradores do que se continuasse com a metodologia antiga e/ou sem metodologia. É por isso, que é uma best practice iniciar a implementação dos OKRs numa equipa considerada piloto. E, por norma, essa equipa será ou terá uma melhor performance dos que as restantes equipas e, por esse motivo, estará melhor preparada para retornar um resultado mais fidedigno daquilo da futura implementação dos OKRs.
OKRs na Vida Real
Nada melhor do que pensar naquilo que é o nosso quotidiano para perceber como funcionam os OKRs, na prática. Não obstante de podermos ler artigos e livros sobre o tema. Por exemplo, eu li o livro Measure What Mattters by John Doerr que retrata o tema dos OKRs de forma muito minuciosa.
Antes de passarmos aos exemplos, devo referir que são exemplos ilustrativos para se perceber como se devem definir OKRs. Não dei muita importância às regras para se atingir algo, porque não sou especialista nem em futebol, nem em gastronomia.
Vamos então aos exemplos e desmistificar os OKRs de forma simples, ainda que a sua implementação seja complexa e demorada.
Exemplo 1 – Clube de Futebol Profissional
No meu caso é o Sporting Clube de Portugal.
Imaginemos que após várias conversas top-down e bottom-up se definiu o seguinte objetivo (Big Hairy Audacious Goal) para o ano de 2024-2025: Ganhar a Champions League.
Definido o Objetivo, temos de pensar como vamos definir os Key results para cada uma das “sub-equipas” que compõem a equipa de futebol profissional do Sporting. Mas antes de definir esses Key Results, temos de garantir que todos que direta ou indiretamente compõem a equipa de futebol profissional do SCP estão cientes do Big Hairy Audacious Goal. É por isso que há inúmeras conversas top-down e bottom up até se atingir a definição final do Objetivo e respetivos KRs.
E podemos definir, por exemplo, como Key Results para o Objetivo de ganhar a Champions League no ano de 2024/2025 os 3 seguintes:
Objective – Ganhar a Champions League. AS MEASURED BY
Key Result 1 – Ganhar os 3 jogos em casa contra os 3 diferentes adversários do grupo
Key Result 2 – Ganhar, pelo menos 1 jogo fora, contra a equipa favorito do grupo
Key Result 3 – Ter um saldo positivo de golos marcados Ganhar à principal equipa adversário do grupo em casa e fora
Se analisarmos bem os KR, vamos reparar que os mesmos estão muito mais relacionados com a equipa que joga, os jogadores e não tanto com as restantes “sub-equipas” que compõe a “equipa global” de futebol profissional do SCP. Por exemplo, a equipa de preparação física dos jogadores do SCP, consegue perceber o Objetivo e os KR, mas por não jogarem (não são jogadores), não conseguem perceber qual será o seu Objetivo bem como os seus KR, para que a equipa profissional do SCP atinja o principal objetivo que é ganhar a Liga Europa.
Significa então que o trabalho não está terminado. Temos que definir os KR para as restantes equipas. Mas como? Simples teoricamente, porque na prática exige pensar o tema e exige tempo!
Podemos e devemos replicar (cascade) estes KR para as “sub-equipas” que constituem a equipa global de futebol profissional do SCP. Replicando os KR teríamos, por exemplo para o 1º Objetivo da equipa de futebol profissional do SCP; jogadores e treinadores, a seguinte “cascade” para a equipa de preparadores físicos.
Objective – Ganhar os 3 jogos em casa contra os 3 diferentes adversários do grupo AS MEASURED BY
Key Result 1 – Ter disponível e em forma (dentro do peso e do índice IMC) pelo menos 1 ponta de lança para cada um dos jogos em casa do Sporting na Champions
Key Result 2 – Garantir que todos os jogadores não têm uma variação da massa gorda entre jogos da Liga Europa superior a 5%
E esta “cascade” replica-se pelas restantes equipas.
Ou seja, fazendo a “cascade” dos Key Results – que não é obrigatório, mas facilita o trabalho – todos ficam a conhecer o Objetivo, todos têm KR específicos para a sua equipa e todos sabem o que devem fazer etêm as condições para fazê-lo de forma independente.
Se tivéssemos definido apenas os KR para a equipa de futebol, a equipa de preparadores físicos não sabia ao certo como atingir os KR, porque não são eles que estão dentro do campo a jogar contra as equipas. Os KR definidos não fazem sentido para a equipa de preparadores físicos.
Mas não havia problema algum se se quisesse criar só OKRs para a equipa de futebol profissional do SCP, jogadores. Não há nada que diga que todas as equipas têmque ter Objetivos e Key Results Definidos – aliás, se bem implementados, uma das fases de implementação dos OKRs é implementá-los primeiro numa equipa piloto – mas concordarão que ficará mais difícil para a equipa de futebol profissional do SCP atingir o objetivo de ganhar a Champions, se as equipas mais influentes e que trabalham mais de perto com a equipa de futebol (mas não dependem dela, têm as suas funções e responsabilidades, são multi-disciplinares e são autónomas) não tiverem os seus Objetivos e Key Results definidos.
Exemplo 2 – Cozinha de um restaurante
Para mim os restaurantes são bons, se cumprirem um determinado conjunto de critérios. Por exemplo, se o restaurante não me servir comida que não seja fresca nem saborosa, para mim são 2 razões suficientes para não voltar ao restaurante. Mas vou colocar a fasquia mais alta. Afinal é isso que é o que os OKRs se propõem.
Mais uma vez, vamos imaginar que após várias conversas top-down e bottom-up se definiu o seguinte objetivo para o triénio de 2023-2026: Ganhar a primeira Estrela Michelin para o restaurante.
O Chef do restaurante, a sua brigada, o chefe de sala e o seu staff, e o diretor do restaurante e demais membros da equipa, terão de estar alinhados enquanto equipa neste Objetivo e, com isso, definir os seus Key Results. Para esse objetivo, vamos definir então 2 Key Results.
Objective – Ganhar a primeira Estrela Michelin para o Restaurante dentro de 3 anos
MEASURED BY
Key Result 1 – Aperfeiçoar, pelo menos 2 pratos de autor, nos próximos 3 anos
Key Result 2 – Garantir que nesses 3 anos não existe nenhum reclamação grave dos clientes, seja ao nível da refeição, do serviço ou das instalações
Mais uma vez, os KR estão muito direcionados para a equipa do Chef e da sua Brigada. Será que o chef de Sala consegue cumprir o KR de aperfeiçoar pelo menos 2 pratos de autor? Não me parece.
Portanto, é preciso fazer o “cascade” dos Key Results dessa equipa, transformá-los em Objetivos de uma outra equipa e traçar novos KR.
Exemplo de um Objetivo e KR para o Chef de Sala e a sua equipa:
Objective – Garantir que nesses 3 anos não existe nenhum reclamação grave dos clientes, seja ao nível da refeição, do serviço ou das instalações
AS MEASURED BY
Key Result 1 – Promover a formação profissional da sua equipa em gestão de clientes e de sala de restaurantes
Key Result 2 – Auditar de 15 em 15 dias o comportamento e desempenho da sua equipa enquanto atende o cliente e serve os pratos.
(Muito exemplificativo)
Conclusão
- Os OKRs não são de todo uma metodologia fácil de implementar. É uma metodologia complexa que demora tempo a perceber, interiorizar, espalhar pela Organização, a implementar e a controlar. É por isso que muitas vezes opta-se, no início da sua implementação, de fazer um teste piloto junto de uma equipa que já performance bem.
- Os OKRs não se definem ao nível das pessoas, mas sim ao nível das equipas. E as equipas têm de ser 100% autónomas, responsáveis para puderem atingir o seu Objetivo medido através dos KR. E neste ponto permitam-me um exemplo muito rápido. Imaginem que o Manuel resolveu estabelecer como Objective perder 20 quilos em 1 semana. E definiu 1 KR como: percorrer 20 Km / dia de bicicleta e mais 2 KR. Só que o Manuel não têm bicicleta, mas o seu vizinho (outra equipa) tem. Ele precisa da bicicleta do seu vizinho para cumprir o seu objetivo atingindo o KR de percorrer 20 Km /dia de bicicleta. É muito pouco provável que o consiga atingir aquele KR, porque não tem autonomia e responsabilidade total sobre o KR que definiu, está 100% dependente de outra equipa.
- Os OKRs ajudam os membros de cada equipa a criarem laços mais fortes. Mas se as equipas ou algum membro da equipa não se identificar com esses OKRs, pelas razões acima descritas ou outras, o feitiço vira-se contra o feiticeiro. O que me leva ao ponto 4 da conclusão, descrito no livro de John Doerr…
- A implementação dos OKRs, tem de se ser acompanhada de CFR – Conversations, Feedback e Recognition. Com o objetivo de rever KR, adaptá-los se for o caso, e perceber as razões para a equipa não estar a conseguir atingir o Objetivo com base nesses KR.
- A réplica “cascade” dos OKR de uma equipa para outra não é obrigatória, mas pode ser uma metodologia que facilita a distribuição de OKRs pelas diferentes equipas. Mas nada impede que se crie OKRs específicos para cada equipa sem nenhuma metodologia associada. Esses OKRs têm é de ser coerentes para cada uma das equipas.
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