Gestão de Produto Ágil: Guia de Processos & Funções

Há muito conteúdo, guias, manuais, cursos e certificações disponíveis sobre gestão de produtos Ágil. Sinceramente, não precisa de tudo isso.

Na sua essência, a gestão de produtos Ágil assenta numa filosofia simples e orientada para as pessoas. Muitos dos processos em que o Ágil se concretiza são simples e fáceis de compreender. No entanto, a complexidade surge devido a expectativas, funções e processos mal compreendidos.

Neste guia, iremos:

• Explorar a gestão de produtos Ágil, a sua filosofia e os processos através dos quais ganha forma.
• Analisar as funções que compõem uma equipa típica de desenvolvimento de produtos Ágil, compreender em que consistem e como colaboram.

Compreender estas áreas fundamentais é importante. Isto fornecer-lhe-á as ferramentas para implementar ou melhorar a gestão de produtos Ágil na sua equipa ou organização.

O que é a gestão de produtos Ágil?

Ágil é uma filosofia sobre a forma como as equipas podem colaborar eficazmente para alcançar um objetivo. O manifesto Ágil original, publicado em 2001, exprime da melhor forma os princípios Ágeis:

• Indivíduos e interações mais do que processos e ferramentas
• Software funcional mais do que documentação abrangente
• Colaboração com o cliente mais do que negociação contratual
• Responder à mudança mais do que seguir um plano

Essa é a essência da gestão de produtos Ágil. Não há qualquer menção a pontos de história ou pistas de fluxo. Nem a reuniões diárias ou iterações.

Embora o manifesto Ágil não prescreva a utilização de processos e ferramentas, minimiza a sua importância em favor de uma colaboração adaptável e centrada nas pessoas. Ao abordar o desenvolvimento de produtos Ágil pela primeira vez (ou mesmo ao fazer uma revisão), pode ser esclarecedor começar pelos fundamentos do manifesto.

À medida que entramos nas questões práticas do Ágil, é importante continuar a ter o manifesto em mente. Processos, documentação e planeamento são excelentes. No entanto, se se encontrar numa situação em que você ou a sua equipa os estão a priorizar em detrimento da sua equipa ou de um produto funcional, deverá prestar atenção a este aspeto.

Vejamos alguns dos aspetos mais subtis da mentalidade de desenvolvimento de produtos Ágil.

Centrado nas pessoas

O desenvolvimento de software Ágil está centrado em capacitar as pessoas que compõem a sua equipa de produto. Para o praticar corretamente, deve realmente confiar nas pessoas com quem trabalha. Sem confiança, a segurança psicológica da sua equipa fica em risco e a colaboração produtiva pode ficar comprometida.

Centrado nos utilizadores

É essencial concentrar-se incansavelmente nos seus utilizadores. Afinal, não são eles a razão pela qual desenvolvemos produtos?

Uma equipa Ágil eficaz entrevista constantemente os utilizadores para obter retorno sobre os seus produtos. Envia e processa inquéritos para orientar a definição de prioridades no desenvolvimento de novas funcionalidades. Os gestores de produtos Ágeis procuram sempre formas de dividir o trabalho em pequenas parcelas que possam ser lançadas, para as validar com os utilizadores ao longo do processo, tendo o cuidado de evitar a expansão descontrolada de funcionalidades.

Sem convidar regularmente os utilizadores a participar, aquilo que planeamos hoje poderá ser inválido amanhã.

Desafiante

A gestão de produtos Ágil é incrivelmente desafiante, e não pelas razões que poderia esperar.

As equipas Ágeis eficazes têm geralmente menos processos e relatórios formais do que as suas homólogas não Ágeis. Isto deve-se ao facto de o Ágil se centrar num fluxo contínuo de trabalho e na transparência, dando prioridade à colaboração em vez de marcos isolados.

A falta de processos também traz, para muitos gestores de produto, a sensação de falta de controlo. No entanto, continuam a ter um elevado grau de responsabilidade associado à função. Equilibrar a própria atuação para não ultrapassar limites e desviar o foco da equipa é uma arte, e algo que pode variar de equipa para equipa, dependendo da dinâmica.

No entanto, quando um gestor de produto adota uma abordagem de liderança ao serviço da equipa, pode obter mais benefícios a longo prazo — e, ironicamente, mais controlo —  do que de outra forma. Isto deve-se aos ganhos que a adoção de processos Ágeis baseados na confiança pode proporcionar.

É também ideal ter uma cultura de trabalho que apoie a metodologia ágil. É possível começar numa organização sem apoio à metodologia ágil, mas isso será mais desafiante e dar-se-á por si a trabalhar contra a corrente. Uma organização que apoia a metodologia ágil sentir-se-á confortável com planos intencionalmente vagos, pois compreende que os planos se tornarão mais claros à medida que o tempo avança.

Gestão enxuta

Aplicar uma abordagem enxuta na prática é crucial. Um foco absoluto nos resultados mantém as equipas ágeis a avançar em direção ao objetivo, com poucas distrações. Concentrar-se na menor quantidade de trabalho que pode ser realizada para alcançar o objetivo ajuda a equipa a continuar a avançar e a alcançar o sucesso no mercado o mais rapidamente possível.

Fluxo ágil

Antes de analisarmos alguns dos processos específicos que pode utilizar para adotar a gestão de produtos ágil, falemos sobre o fluxo geral do processo e sobre as etapas da metodologia ágil que a maioria dos processos seguirá. 

Leitura relacionada: Como implementar os princípios da gestão ágil do portefólio de produtos

Estratégia

Um excelente desenvolvimento ágil começa com uma boa estratégia e alinhamento. Reunir toda a equipa numa sala (ou numa reunião do Zoom) pode contribuir muito para estabelecer uma visão e uma direção unificadas para o produto. Considere utilizar software de colaboração visual envolvente para garantir que as pessoas não perdem a atenção.

Esta pode ser uma oportunidade para a equipa se alinhar quanto ao plano de negócios, à direção visual, aos utilizadores-alvo, entre outros aspetos. Serve como um ponto de partida comum fundamental para a equipa se concentrar.

É importante notar que os planos e a documentação criados durante este período são tratados como pressupostos. Estão prontos para serem revistos e iterados regularmente à medida que o tempo avança.

Experimentação

Tudo é uma experiência. Logo desde o início, o primeiro bloco de trabalho focado que realizar deve ter uma duração definida e ser depois testado com os utilizadores. Este trabalho pode ser extremamente rudimentar, podendo consistir simplesmente em esboços grosseiros que apresenta a alguém.

O objetivo é abordar o seu trabalho com a mentalidade do método científico. Somos trabalhadores do conhecimento e, como tal, o nosso foco não está exclusivamente na execução. Está também na criação e na descoberta de conhecimento.

Testes

Cada experiência deve ser testada qualitativa e quantitativamente. Através de uma análise regular dos resultados, terá as ferramentas necessárias para confirmar que aquilo que a sua equipa está a criar tem valor e será aceite pelo mercado.

Validação

Depois de lançar uma nova funcionalidade, acompanhe-a de perto. Está a ser utilizada? As pessoas conseguem encontrá-la? Outras áreas do seu produto foram afetadas positiva ou negativamente pela introdução desta funcionalidade?

Rever e verificar regularmente aquilo que lança depois de estar "concluído" fornecerá mais ferramentas e orientações para tomar decisões ainda melhores.

Repetição

Este é o passo mais importante. Continue a percorrer novamente o fluxo do processo ágil, como um motor. Este fluxo é intencionalmente cíclico, e não linear, para incentivar a aprendizagem. Aprenda com ele. Adapte-se com base nele. Celebre-o. Aceite o fluxo da mudança.

2 abordagens ágeis comuns

A metodologia ágil é uma filosofia capacitadora que reúne as equipas em torno de um objetivo comum, através de formas colaborativas que não são possíveis com processos e relatórios excessivamente estruturados.

No entanto, alguns processos são úteis. Quando corretamente implementados e utilizados tendo em consideração a cultura específica de uma equipa, os processos podem servir como limites orientadores que mantêm a equipa concentrada na concretização dos seus objetivos, apoiando simultaneamente a liberdade criativa.

Vamos analisar alguns dos processos mais populares que põem a filosofia ágil em prática.

Scrum

O Scrum é talvez o processo ágil mais popular, e por uma boa razão: divide os compromissos e a aprendizagem em períodos de trabalho dedicados, denominados "sprints". Isto incentiva uma quantidade saudável de aprendizagem e mais oportunidades para adaptação com base nessa aprendizagem.

O elemento central destes sprints é a própria equipa Scrum. No Scrum, não existem títulos: todos os produtores da equipa desempenham o papel de "programador". Isto incentiva uma forte concentração da equipa na colaboração e na concretização do objetivo de cada sprint. 

Na prática, isto significa que, se um engenheiro de testes estiver à espera de uma funcionalidade para testar, pode dedicar esse tempo a programar uma nova funcionalidade. Esta mentalidade multifuncional é incrível quando funciona, porque permite que uma equipa produza resultados fantásticos.

O Scrum procura minimizar as reuniões para promover períodos de desenvolvimento concentrado. Para tal, existe um conjunto de reuniões recorrentes, ou cerimónias:

• Planeamento do sprint: Utilizado para planear o trabalho que a equipa pretende comprometer-se a realizar no sprint.
• Revisão do sprint (demonstração): Um momento para demonstrar o progresso alcançado uns aos outros e às partes interessadas, bem como para abordar quaisquer aprendizagens.
• Retrospectiva do sprint: Um momento de reflexão franca para a equipa analisar o sprint anterior e discutir o que correu bem, o que não correu e onde poderão existir oportunidades de crescimento.
• Refinamento e estimativa do backlog: Este é um período recorrente para analisar e priorizar o backlog do produto, em constante mudança, com base nas aprendizagens empresariais e técnicas. Assim que existe alinhamento relativamente aos itens do backlog, estes são estimados para efeitos de planeamento.
• Reuniões diárias: Um momento regular todos os dias para a equipa partilhar o que concluiu ontem, em que está a trabalhar hoje e se está bloqueada por algum motivo.

Para ligar o trabalho centrado no sprint à visão global, o Scrum incentiva a utilização de "pontos de história" para fazer estimativas através de sessões estruturadas de planeamento do sprint. Estes representam um nível arbitrário de esforço que a equipa atribui a cada item do backlog.

O que é incrivelmente poderoso nisto é o facto de permitir acompanhar a velocidade. Ou seja, o número médio de pontos de história que a equipa conclui em cada sprint. Após alguns sprints iniciais, este número deverá estar calibrado e poderá ser utilizado para previsões e planeamento direcionados de lançamentos.

Se estas ferramentas forem utilizadas diligentemente com a equipa e orientadas por um Scrum Master experiente, o Scrum pode ser um processo poderoso que apoia o desenvolvimento Ágil focado e proporciona amplas oportunidades para uma iteração eficaz.

Kanban

Inspirando-se bastante no Scrum, o Kanban inclui muitos elementos familiares, como o refinamento do backlog, um quadro semelhante a um quadro de sprint, entre outros.

No entanto, enquanto o Scrum se concentra numa pequena quantidade de trabalho, o Kanban dá ênfase a um fluxo contínuo de trabalho.

O elemento central deste processo é o quadro Kanban. Os itens são continuamente priorizados à esquerda e avançam pelo processo personalizado da equipa até à direita, terminando em "concluído". Muitas vezes, para equilibrar a carga de trabalho, cada coluna pode ter um limite de trabalho em curso (WIP) que define quantas tarefas podem ser trabalhadas em simultâneo.

O Kanban é excelente para trabalho de suporte ou para equipas que têm uma disponibilidade irregular para assumir compromissos.

SAFe, XP e outros

Existem muitas outras variantes de processos Ágeis, cada uma adequada a necessidades organizacionais e normas culturais específicas.

O SAFe é um sistema Ágil abrangente para implementar o desenvolvimento Ágil em escala numa organização, normalmente numa grande empresa. É composto por vários "comboios de lançamento Ágil", que são essencialmente equipas individuais de Scrum. Estão envolvidos vários papéis e cerimónias para garantir que todas as equipas trabalham no sentido de objetivos organizacionais e planos de lançamento partilhados.

A programação extrema (XP), o DevOps, o Ágil moderno e outras metodologias existem para abordar casos de utilização do desenvolvimento Ágil específicos de determinados papéis ou culturas.

Experimentar diferentes práticas Ágeis é saudável. Pode conduzir a uma compreensão eficaz do que funciona para a sua organização específica.

Certificações de gestão de produtos Ágeis

Provavelmente já viu as inúmeras certificações que pode obter para qualquer processo Ágil específico. São promovidas de forma a fazê-lo sentir que o respetivo processo é a única forma e que, sem obter uma certificação dispendiosa, não conseguirá realmente praticar o processo.

Ignore isso.

Idealmente, este guia proporcionar-lhe-á impulso suficiente para iniciar um percurso de aprendizagem próprio. As metodologias Ágeis são um conjunto de ferramentas para quem as aplica, não algo sobre o qual será avaliado. É útil familiarizar-se com o processo, as cerimónias e a documentação próprias de cada processo; no entanto, regressando ao manifesto, é mais importante envolver a sua equipa na implementação do processo Ágil que escolher. Existem organizações dedicadas à criação e manutenção de certificações; é naturalmente do seu interesse promover o processo em detrimento das pessoas.

Isso é realmente Ágil?

Tudo isto para dizer que esta é simplesmente uma história de advertência à medida que faz o seu próprio percurso de aprendizagem Ágil. As certificações podem ser valiosas. Se frequentar uma sessão prática, pode ser uma forma orientada de aprender rapidamente todos os pormenores de um processo específico. Algumas organizações valorizam o facto de ser certificado como forma de criar confiança rapidamente.

Se obter uma certificação o ajudar a alcançar o resultado pretendido e exigir um esforço reduzido, avance. No entanto, se não precisar de uma certificação, a experimentação e a aprendizagem contínua sobre a implementação do Ágil são o caminho mais eficaz no seu percurso Ágil.

Relacionado: 4 melhores certificações online de gestão Ágil de produtos

Quais são as funções no desenvolvimento Ágil de produtos?

Ao abordarmos os processos Ágeis, começámos a identificar um conjunto de funções essenciais que constituem uma equipa de desenvolvimento Ágil de produtos. Estas funções incluem:

• Gestor de Produto
• Responsável pelo Produto
• Programador
• Designer
• Engenheiro de testes / QA

Geralmente, cada organização tem a sua própria abordagem às funções que estas pessoas desempenham. Por exemplo, o conjunto de responsabilidades de um gestor de produto numa empresa pode estar mais alinhado com os compromissos de um responsável pelo produto noutra. No entanto, tendo em mente esta flexibilidade, vejamos algumas das definições mais abrangentes que ilustram as funções numa equipa de produto.

É frequente existir alguma sobreposição entre responsáveis pelo produto, gestores de produto e gestores de projetos, e as equipas podem ter um, dois ou todos os três. Os gestores de produto ou responsáveis pelo produto assumem frequentemente responsabilidades de gestão de projetos quando não existe um gestor de projetos na equipa.

Gestor de Produto

Então, o que faz um gestor de produto? O gestor de produto é responsável por, bem, gerir o produto.  A principal responsabilidade da função de gestão de produto é garantir que tudo está alinhado para alcançar os principais resultados com base nos testes com utilizadores, nos contributos da equipa e no planeamento estratégico.

No entanto, uma gestão de produto eficaz consiste em capacitar a equipa de produto. Por isso, o gestor de produto desempenha uma função generalista. Ou seja, precisa de ter competências abrangentes para ser eficaz, mas não tem necessariamente de ser um programador ou designer especializado (embora seja comum as funções de produção evoluírem para a gestão de produto).

Um conjunto de competências generalista permite ao gestor de produto ser um líder servidor empático para a sua equipa. Munido de uma compreensão apenas suficiente do que o desenvolvimento implica, o gestor de produto pode ajudar a orientar a equipa na definição e no planeamento eficazes do produto, sem simultaneamente interferir com as competências da equipa.

Leitura relacionada: Porque é importante a gestão de produto

Responsabilidades do Gestor de Produto

• Resultados do produto
• Gestão da lista de trabalho pendente
• Gestão das partes interessadas
• Testes com utilizadores
• Redação de histórias de utilizador
• Facilitação de equipas multifuncionais
• Gestão do roteiro do produto
• Análise do produto

Responsável pelo Produto

Enquanto o gestor de produto assume a responsabilidade pelo sucesso tático do produto, o responsável Ágil pelo produto é responsável pelo sucesso empresarial e de mercado.

Geralmente, o responsável pelo produto desempenha uma função empresarial central que, por vezes, pode ser uma parte interessada central para a equipa de produto. O seu conhecimento do mercado e a sua perspetiva de 50 000 pés sobre o negócio fazem dele um recurso essencial e conhecedor para ajudar a otimizar a equipa de produto tendo em vista o sucesso. 

Responsabilidades do Responsável pelo Produto

• Sucesso do produto 
• Pesquisa e conhecimento do mercado
• Desenvolvimento de negócio
• Financiamento
• Desempate

Um desafio comum é a sobreposição e as diferenças entre o papel de proprietário do produto e o de gestor de produto. Por vezes, este papel faz parte do papel do gestor de produto e vice-versa. Quando os dois papéis são distintos, existe frequentemente uma sobreposição de funções. Algumas organizações chegam mesmo a trocar as responsabilidades dos papéis de gestor de produto e de proprietário do produto.

No entanto, isto é aceitável!

Apesar dos desafios que possam surgir, quando estes papéis trabalham em conjunto para encontrar um equilíbrio saudável de colaboração complementar, podem surgir resultados extraordinários. Por exemplo, uma das funções pode estar constantemente focada no produto, enquanto a outra se concentra no negócio. Uma pode estar focada nos pormenores técnicos do produto, enquanto a outra se concentra no posicionamento do mercado a um nível estratégico.

Assim, quando estas duas funções colaboram em conjunto, podem surgir, de forma inesperada, perspetivas estratégicas transformadoras que têm um impacto positivo no sucesso do produto e da equipa. Afinal, duas cabeças pensam melhor do que uma!

Programador

Numa equipa de produto eficaz, o papel do programador não consiste apenas em escrever código: este colabora com todas as funções no planeamento estratégico e técnico, bem como na apresentação de recomendações.

Munidos de um sólido conhecimento das ferramentas de desenvolvimento de produtos, das necessidades dos utilizadores e dos objetivos do produto e do mercado, os programadores conseguirão criar um plano técnico que se adapta perfeitamente ao produto. Dotar os membros da equipa de desenvolvimento deste conhecimento e da capacidade de tomar decisões técnicas importantes pode fazer a diferença entre um prazo de desenvolvimento de um mês e um prazo várias vezes superior, devido às contrapartidas técnicas associadas a essas decisões.

Quando os seus programadores estão integrados na vertente de produto da sua equipa de desenvolvimento, podem multiplicar o sucesso da equipa.

Responsabilidades do programador

• Desenvolvimento do produto
• Planeamento e investigação técnica
• Consultoria sobre a pilha tecnológica
• Prototipagem funcional
• Testes unitários
• DevOps (por vezes, uma função separada)
  • Criação e gestão do processo de implementação

Profissional de design

Tal como os programadores não devem limitar-se a escrever código, o alcance dos profissionais de design numa equipa de produto deve estender-se para além da criação de uma solução visual. Na verdade, algumas das melhores colaborações numa equipa de produto acontecem entre esta função e a função de gestor de produto.

Os profissionais de design das equipas de produto começam por analisar estrategicamente a estratégia do produto e o negócio. São frequentemente os maiores defensores do utilizador na equipa. Estas perspetivas permitem-lhes depois criar a solução visual, ainda que com um foco direcionado.

Permitir ganhos de eficiência no desenvolvimento e na aprendizagem é uma área de foco fundamental para as funções de design. A criação de sistemas de design permite aos programadores desenvolver rapidamente novas funcionalidades através de fluxos de trabalho de integração contínua. A criação de protótipos interativos e visuais permite testar com utilizadores antes de escrever uma única linha de código, validando assim um investimento adicional.

Responsabilidades do profissional de design

• Conceção do produto
• Maquetas
• Prototipagem
• Criação de um guia de estilos
• Criação e suporte de sistemas de design
• Testes com utilizadores, em colaboração com o gestor de produto
• Investigação contínua com utilizadores

Engenheiro de testes / QA

Um engenheiro de testes (por vezes designado por garantia da qualidade, ou QA) pode ser uma das funções com maior impacto numa equipa de produto. Embora o seu foco principal seja testar as funcionalidades do produto antes de este chegar aos utilizadores, o seu olhar atento pode ajudar a otimizar o foco da equipa antes de criar uma nova funcionalidade.

Os engenheiros de testes devem estar envolvidos desde as primeiras fases do desenvolvimento do produto. Isto permite-lhes definir critérios de aceitação para as histórias de utilizador do produto, que são utilizados para orientar o resto da equipa na conclusão do trabalho.

Com uma mentalidade centrada no utilizador, os engenheiros de testes podem antecipar quaisquer consequências potenciais de um próximo lançamento. Quando esta função consegue aconselhar estrategicamente o proprietário do produto, pode ter um impacto concreto no sucesso ou insucesso comercial de um novo lançamento para os utilizadores.

Responsabilidades do engenheiro de testes/QA

• Testes funcionais
• Testes de regressão
• Testes exploratórios
• Definição dos critérios de aceitação
• Avaliações e análises contínuas dos riscos

Outros papéis

Embora os papéis mencionados anteriormente constituam uma equipa de produto, existem muitos papéis fora da equipa que apoiam o foco da equipa nos resultados.

Estes papéis incluem marketing, vendas, apoio ao cliente, entre outros. Normalmente, estes papéis são integrados na organização para apoiar o produto à medida que se alcança o sucesso no mercado. Regra geral, não fazem parte da equipa de produto. No entanto, uma relação forte e colaborativa com estes papéis contribui ainda mais para impulsionar o sucesso do negócio.

Colaboração

Embora cada papel tenha a sua própria área de especialização numa equipa de produto, parte-se do princípio de que todos colaboram entre si. Quando cada papel traz uma mentalidade em forma de T para a equipa, isso permite que todos contribuam com a sua especialidade, adotando simultaneamente um foco no produto como parte da definição do papel de cada um. Todos se aprofundam na sua própria área de especialização, ao mesmo tempo que alargam os conhecimentos a todos os outros conjuntos de competências, para alcançarem o sucesso em conjunto enquanto unidade.

A colaboração numa equipa de produto significa existir um foco constante nos resultados do produto e na experiência do utilizador. Todos estão envolvidos na concretização desta visão e avançam em conjunto, como uma equipa coesa.

Conclusão

Principais conclusões

• A gestão ágil de produtos é uma filosofia centrada nas pessoas e nos utilizadores para fornecer o resultado certo mais cedo.
• Embora o Agile seja simples na sua essência, a complexidade e os desafios são introduzidos por processos, cultura organizacional, entre outros fatores.
• Os processos e papéis Agile podem ser orientados por processos como scrum, kanban, SAFe, entre outros.
• Os papéis que constituem uma equipa de produto Agile incluem programadores, designers, engenheiros de testes, um gestor de produto e um proprietário do produto.

A gestão ágil de produtos é incrivelmente simples e intencionalmente simples. É uma filosofia poderosa que pode multiplicar o valor que a sua equipa consegue criar. No entanto, quanto mais se aprofunda nos processos e papéis que a apoiam, mais complexa ela corre o risco de se tornar.

Nessa complexidade escondem-se oportunidades para dar mais capacidade à sua equipa de produto e à sua organização. Utilizar estas táticas com a sua equipa é um exercício de equilíbrio, garantindo simultaneamente que não criam entraves organizacionais involuntários ao longo da colaboração normal.

No entanto, quando implementado corretamente e com uma atitude de experimentação, o Agile pode orientar o futuro do sucesso da sua equipa de produto.

Já viu o Agile ser implementado ou tem experiência com ele? Foi semelhante ou diferente do que é explicado neste guia? Diga-nos nos comentários! Não se esqueça de subscrever a nossa newsletter para gestores de produto para obter mais informações e guias.

Ou continue a aprender consultando este podcast, que pode ler/ver/ouvir de forma tão conveniente: Alinhamento através de roteiros de produto (com Brandon Blackman, da Crema)

Leituras relacionadas:

• O que é um épico Agile? Melhores práticas, modelo e exemplo
• Como criar um roteiro Agile
• Ciclo de vida da versão de software (SRLC): compreenda as 6 principais fases

Também vale a pena consultar:

• Como utilizar o monday.com na gestão de produtos
• Como criar uma descrição eficaz para a função de gestor de produto ágil (+exemplo)
• Os 15 melhores modelos de priorização de funcionalidades de produtos: qual é o melhor?
• 8 boas práticas de sinalizadores de funcionalidades que deve conhecer
• Modelos gratuitos de roteiro de produto para impressionar as partes interessadas
• Como escrever notas de versão de software eficazes que encantem os utilizadores
• Ferramentas de relatórios visuais para dados de produtos
• Ferramentas Kanban para gestão de produtos