Product Backlog: o que pode e não pode cair para Sprint Backlog?

Uma discussão que sempre gera muita negociação é o que o time pode se comprometer a fazer em uma determinada Sprint Backlog?

Obviamente que o PO tem a atribuição de definir o que deve ser priorizado, podendo aplicar diversas técnicas para tal (MOSCOW[a], KANO[b], WSJF[c], etc).

De qualquer forma cabe ao time nas cerimônias de refinamento e planning aferir se os acordos das histórias estão sendo cumpridos. Por exemplo:

Story

  1. As histórias estão DOR (Definition of Ready), com o detalhamento necessários para compreensão do time, ou seja, detalhamento de ao menos um critério de aceite, wireframe/protótipo de baixa fidelidade?
  • A história é do tipo INVEST(Independent, Negociable, Valuable, Estimable, Small e Testable). Ou seja, sua atomicidade garante um desenvolvimento desacoplado, pode ser negociada, tem valor suficiente para uma implementação para o cliente, é passível de ser estimada e suficientemente testável?
  • Existem riscos de indefinições técnicas, de negócio ou arquitetura que não serão resolvidas pré-Sprint?
  • Existem dependências com outros times que não foram negociadas as demandas para sincronização adequada de implementação?
  • A história tem uma importância e relevância para o cliente?

Está gostando deste post? Cadastre-se na nossa newsletter e receba os próximos conteúdos sobre transformação digital e mais!


Maturidade

Times com baixa maturidade e sem um suporte adequado de um agilista do processo (Scrum Master e Agile Coach por exemplo), acabam não se atentando aos pontos citados acima. Isso corrobora ao não atingimento do objetivo definido na Sprint, perda do timebox estabelecido e consequentemente frustração entre os integrantes do time.

Ainda nessa linha, é necessário verificar se a formação do time foi montada de acordo com as características técnicas necessárias do que será implementado no roadmap das sprints planejadas.

Uma vez que os itens acima sejam considerados, o time consegue não aceitar histórias incompletas e que gerem riscos para cumprimento do objetivo estabelecido na Sprint.

Naturalmente que o time deve ter autonomia e maturidade suficiente para eventuais itens considerados “incompletos” não caiam para Sprint Backlog, onde se comprometem a entregar as histórias discutidas e entendidas para serem implementadas.

No início deste processo, naturalmente o time terá muitas dificuldades em fazer cumprir as regras/acordos definidos. Neste cenário, o agilista (como citado acima), ganha uma importância fundamental para orientar, passar direcionamento, realizar mentoring e nas retrospectivas tangibilizar ao time, eventuais motivos que a sprint “capotou” e não foi possível cumprir o que foi comprometido na planning. Por exemplo, histórias incompletas que o time permitiu que fossem construídas.

Outro aspecto importante que o agilista pode contribuir é não permitir que o time se fruste com insucessos iniciais, já que estamos lidando com modelo não prescritivo e empírico.

As retrôs neste cenários são muito importantes para identificar problemas de indefinições, riscos existentes, histórias incompletas e atuar em ações assertivas para que um novo ciclo não se repita as mas características de ocorrências.

Com esse acompanhamento realizado pelo agilista, o time vai ganhando cada vez mais confiança e empoderamento, para que nas próximas sprints o processo fique cada vez mais maduro e assertivo.

[a] MOSCOW

O termo MoSCoW é um acrônimo em inglês derivado da primeira letra de cada uma das quatro categorias com os “Os” no meio para fazer a palavra ser pronunciável. Dessa forma:

  • Must Have (Tenho que fazer)
  • Should Have (Devo fazer)
  • Could Have (Poderia fazer)
  • Won’t Have (Não vou fazer)

[b] KANO

O Modelo Kano (pronuncia-se “kah-no”) é uma abordagem para priorizar recursos em um roadmap de produtos com base no grau em que eles provavelmente satisfarão os clientes. As equipes de produto podem avaliar um recurso de alta satisfação em relação aos custos de implementação, para determinar se a inclusão ou não no roadmap é uma decisão estratégica.

[c] WSJF  

Sigla com significado Weighted Shortest Job First, que realizando uma tradução objetiva seria trabalho com menor esforço e maior valor devem ser priorizados primeiro. Criando um peso de cada item do backlog para calcular qual teria mais relevância e menor esforço para ser desenvolvimento primeiro.


Artigo escrito por Sérgio Ricardo Vieira, Agile Coach da Mooven Consulting.

Gestão de Mudança Organizacional Ágil: 5 razões para a sua empresa adotar essa prática

Gestão de Mudança Organizacional Ágil: 5 razões para a sua empresa adotar essa prática

No mundo dos negócios, as mudanças e inovações são uma constante que impactam diversas esferas nas empresas. Neste contexto, o papel da Gestão de Mudança Organizacional Ágil é criar um processo de transição assertivo e que atenue os incômodos da mudança, especialmente para as pessoas envolvidas com o novo cenário.  

O que é Gestão de Mudança Organizacional? 

Como a própria expressão evidencia, a gestão de mudanças se relaciona com uma transformação, um movimento que irá modicar um status ou implementar um projeto dentro de uma empresa.  

Dado o cenário, o objetivo da gestão de mudança organizacional ágil é auxiliar as empresas em processos de transição, percorrendo o caminho da transformação. 

As ações desenvolvidas envolvem diversos pilares relacionados às pessoas impactadas pela mudança. É importante que todos entendam o que motivou a mudança e como cada um irá se relacionar com ela, ajudando as pessoas a se adaptarem ao novo ambiente que se instaurou. 

Quando bem implementada, uma das suas vantagens da gestão de mudança é a redução da taxa de falha da implementação de projetos. 


Está gostando deste post? Cadastre-se na nossa newsletter e receba os próximos conteúdos sobre transformação digital e mais!


Quais os diferenciais da Gestão de Mudança Organizacional Ágil? 

Os diferenciais da Gestão de Mudança Ágil são:

  • Entregar valor antecipado e incremental conectados à estratégia da sua empresa. 
  • Times colaborativos e integrados. 
  • Ciclos de entregas por sprint (contínua).

A Mooven trabalha com framework próprio de agilidade corporativa e digital, pronto para acelerar a transformação na sua empresa. Converse com o nosso time para saber mais! 

Por que adotar a Gestão de Mudança Organizacional Ágil? 

Se a sua empresa está passando ou vai passar por uma série de mudanças, a Gestão de Mudança Organizacional pode ser imprescindível neste momento. Confira 5 razões para adotar essa prática. 

1ª razão: Sua equipe está mostrando poucos resultados.   

Ao longo dos anos, sua equipe sempre se saiu bem, entregando resultados relevantes. Mas, ultimamente, pode não estar no mesmo ritmo de antes.  

Esta situação pode ir além da produtividade dos colaboradores e ser um reflexo da transformação digital que está acontecendo no mundo dos negócios. A adoção da GMO pode ajudar a desenvolver ações para contornar essa situação.  

2ª razão: Se sua empresa está mudando para uma nova plataforma tecnológica.  

Ao adotar uma nova plataforma de tecnologia, é preciso garantir que o produto seja funcional na ferramenta escolhida. Com a gestão de mudanças, é possível identificar as alterações que precisam ser implementadas em processos, mas também os ajustes que impactam colaboradores, fornecedores e clientes.   

3ª razão: Seus objetivos de negócios mudaram.  

Quando uma empresa cresce, os objetivos de negócios também expandem, e isso pode acontecer devido a uma variedade de fatores. Por exemplo, a empresa pode ter atingido novos mercados e, por consequência, o número de clientes aumentou.   

É por isso que é de importância crucial que a estratégia de gestão dmudançase ajuste às necessidades atuais da empresa. É preciso modificar a estratégia corporativa para corresponder às necessidades dos novos mercados atingidos.  

4ª razão: Sua liderança apresentou novas ideias e inovações que impactam diretamente os resultados.  

Mudanças em organizações podem ser muito benéficas, impactando diretamente no resultado. Ao implementá-las, as empresas podem se deparar com novas maneiras de olhar para as necessidades dos clientes, de prestar serviço ou fortalecer as interações com os clientes, e novos produtos que podem atrair novos mercados. 

5ª razão: A transformação digital força a sua empresa a mudar.  

Na medida que mais e mais empresas tiram o máximo proveito da digitalização, o papel da gestão de mudança organizacional também precisa ser aprimorado para enfrentar novos desafios. Essas questões envolvem um impacto humano mais profundo e amplo relacionado à digitalização e o uso de métodos de implementação, como experiência do usuário e design thinking.  

Quer implementar Gestão de Mudança Organizacional na sua empresa? Descubra o que a Mooven Consulting pode fazer pelo seu negócio. Entre em contato conosco!

Conheça outras especializações da Mooven Consulting.

Visão Sistêmica para Estruturação do Backlog do seu Produto

O motivo de eu escrever este artigo é o de compartilhar uma visão estruturada da formação de um backlog de produto que de fato considere vertentes de engenharia de produtos e de agilidade.

Como todos sabem, desde 2012 atuo fortemente na transformação organizacional, ágil e digital de empresas de destaque no mercado brasileiro. Nesses trabalhos, em todos os casos me deparei como uma grande dificuldade por parte dos líderes dos times de entrega em materializar um backlog de trabalho que de fato represente as necessidades relacionadas a entrega de valor esperada pela organização.

A minha ideia neste texto não é discutir ou analisar práticas e abordagem de mercado para formar um backlog, fazer inceptions ou coisas do tipo (existem artigos mais adequados para isso). Aqui desejo apresentar para vocês princípios de arquitetura corporativa, engenharia de software e gestão de requisitos que devem ser bem estabelecidos nas sinapses de cada um para que de fato possam trabalhar de forma eficiente e alinhada com algo que ao final resulte em um produto que tenha seu valor maximizado.

DEFINIÇÕES E SIGNIFICADOS

Não adianta caminharmos para um debate sem que os significados das coisas estejam claras. Destaco que aqui não busco mudar a sua “crença” sobre os termos a seguir, mas sim deixar claro o que tenho em minha visão de solução.

ARQUITETURA DE UMA EMPRESA

O maior erro que se pode cometer na formação de um backlog de trabalho é ignorar completamente a estruturação da organização. Essa estrutura em sua forma ideal, permeia a organização de ponta a ponta, criando sinergia entre aqueles que transformam esforço (processos, funcionários, sistemas, algoritmos, etc ) em versões de produtos prontos para os clientes.

Não entrarei em detalhes para todos os itens, seria tema de um outro artigo. Todavia, alguns pontos preciso mencionar:

  1. Numa organização existem 3 camadas representas por seres humanos: Acionistas, colaboradores/parceiros e clientes
  2. Clientes consomem os produtos e serviços através de um catálogo via canais ( digitais ou analógicos)
  3. Estruturas corporativas (áreas, feudos, tribos, departamentos…etc) existem para levar da melhor forma esses produtos e serviços via canais para os clientes
  4. Uma estrutura corporativa tem ligação direta com um ou mais “Componente de negócio”
  5. Para suportar um componentes de negócio são necessárias plataformas e times
  6. Uma plataforma é feita de features ( funcionalidades ) – UFA!!! se quiser esquecer todos os outros itens é um bom momento, mas guarde este por favor!

Fora os 6 itens comentados gostaria de destacar um outro ponto importante. Em nenhum momento mencionei o termo projeto. Logo, no meu ponto de vista, projetos não são entidades necessárias em uma organização.

ÉPICOS

Representa um serviço prestado por um componente de negócio (business services). É uma jornada de evolução de plataforma/arquitetura/tecnologia . Representa o atendimento a um tema estratégico.

O épico não é um projeto dito de outra forma.

O épico não é um produto.

Um épico existe, impacta e demanda a organização enquanto tiver sua relevância e uso.

Exemplos de épicos seriam: Análise de contratos(Jurídico); Avaliação de crédito (Financeira); Empacotamento (Logística);Atendimento ao cliente(Agência);Gestão de conformidade(Governança)

FEATURES

É um componente da solução de tecnologia ( plataforma ou infra) que suporta a execução de um business service <=> Épico

É o item tangível do valor esperado pelo cliente/usuário para atender suas necessidades

Pode ser tipificado em: Interface humana, campanha, pesquisa, interface sistêmica, relatório, rotina automatizada, documentação técnica, algoritmo, vídeo, documentação funcional, etc

DICA: O tipo de feature aliado com a plataforma, tecnologia, nível de automação e maturidade de equipes é um ponto de partida excepcional para previsibilidade do portfólio de demandas (tema para outro artigo de tão importante)

HISTÓRIAS

Uma História representa a forma como uma determinada persona deseja interagir como uma Feature.

Para sua construção utiliza-se um modelo mais humano que busca manter a necessidade de negócio na perspectiva do usuário. Em geral as Histórias seguem a seguinte estrutura.

“Dado que sou , <Papel do usuário> gostaria que <descrição da necessidade> de tal forma que <descrição do objetivo>.

A história tem uma definição de “ready”, definição de ”done” e critérios de aceite e pode receber diversos documentos complementares como anexo, para que viabilize o entendimento entre as partes

Uma história inclui, altera, remove ou ativa/inativa uma feature de um produto/plataforma

TASKS

A Tarefa define o trabalho necessário para completar a entrega de uma História.

Uma tarefa tem como objetivo impactar uma feature para atender uma história de usuário

Uma tarefa deve ser qualificada em planejamento, documentação, desenvolvimento, testes, implantação e suporte.

ENTREGA

Uma entrega é um conjunto de features que foram desenvolvidas através da transformação de esforço (tarefas) em features de uma solução para atender as necessidades de um clientes (história) através de um determinado canal

ROADMAP / RELEASE PLAN

Uma visão na linha do tempo das entregas

VISÃO GERAL DE RELACIONAMENTO

Os Épicos e Histórias estão relacionados ao fluxo de valor, com experiência e com a jornada

As Features e Tasks são relacionadas com a engenharia do Produto/Solução.

AJUSTANDO A ROTA

Nos itens abaixo vou compartilhar com vocês alguns pontos que devem ser atacados para ajustar a rota para ter um backlog top de verdade, que todos tenham clareza e que a gestão de ponta a ponta seja efetiva.

USE FEATURES!

Se você ainda não usa o conceito de features, pare tudo e comece a usar. Migre de um conceito “vamos listar os desejos” para uma ação orientada a features de produtos, com valor agregado e estimativas.

Para isso ser alcançado invista em um profissional com a competência. Não parta do princípio que as pessoas conseguem fazer essa mudança logo de cara. As carreiras associadas a este são são de Gerente de Produto e Product Owners!

Uma linha de estudo sensacional para esse tema é conhecer mais de #FDD – Feature driven developement.

RECICLE O MODELO DE ATENDIMENTO

Não torne o processo de formação de backlog uma maneira diferente de fazer a “tirada de pedidos” no caderninho. Utilize técnicas de #designthinking #productbacklogbuilding #leaninception #UX #customercentricity

FERRAMENTA DE SUPORTE ADEQUADA

Esse é um grande desafio pois as ferramentas que seguem o modelo de requisitos ágeis em sua grande maioria ignoram a existência de Features trabalhando apenas com Épicos, Histórias e Tasks. Fale com o seu #agilecoach ou especialista para que possa ser configurado um template com features ou que sejam utilizados TAGS ou Cores para definir o que é uma feature. Não é um absurdo ter um Kanban separado para Features e que seja feita uma gestão mais manual do processo.

Ferramentas como #TFS #JIRA são recomendadas e cobrem essa visão. Já #trello #planner darão mais dores de cabeça

TENHA PROFISSIONAIS ESPECIALISTAS

Não ignore a complexidade do tema, tenha especialistas no time! Um especialista vai custar mais, mas vai entregar 2x ou 3x mais do que uma pessoa com pouco conhecimento. Profissionais para esse tema levam 10 a 12 anos para ter a bagagem necessária para ter eloquência ao ponto de tocar o tema na dimensão corporativa.

CASO QUEIRA DETALHAR MAIS O TEMA

CONTATO PESSOAL

Me adicione no linkedin que eu respondo todo mundo.

ME ENCONTRE PELA MOOVEN

Como muitos devem saber sou um dos sócios da Mooven Consulting – uma empresa especializada em Transformação Digital e Ágil.

Confira o site da Mooven e verifique nosso catálogo de serviços, será um prazer ter um relacionamento pessoal ou profissional contigo!

#vempramooven

Visite o site da Mooven Consulting

ME ENCONTRE PELA MODO

Outra maneira de me encontrar e bater um papo é via MODO.ONLINE. A MODO é uma iniciativa nova na qual estou atuando para criar um canal diretor entre profissionais e empresas. Faça seu cadastro na plataforma que será um prazer dar um feedback para vocês que buscam ampliar o alcance de suas carreiras!

#vaidemodo

Visite o site da MODO.ONLINE

Artigo escrito originalmente no LinkedIn por Rodrigo Galdi, Co-Founder & CTO da Mooven Consulting

Como o Product Owner e os demais papéis geram valor para o produto e projeto?

Você entende qual é a importância de um Product Owner no desenvolvimento de um produto ou de um projeto? Compreende de quais formas ele pode colaborar no planejamento estratégico de sua empresa?
Criamos este artigo para comentar o tema. Durante a leitura, você encontrará informações relevantes sobre essa função e a dos outros membros presentes na gestão de produtos e projetos. Continue lendo até o fim para ficar por dentro do assunto!

Quem é o Product Owner de um projeto e o que ele faz?

O Product Owner, também conhecido como PO, é o membro de uma equipe que trabalha com Scrum ou outro método ágil de desenvolvimento de produtos ou projetos. 
Ele geralmente atua na definição das estórias de usuários que compõem o backlog do produto, mantendo o conceito que rege as novas funcionalidades ou ideias a serem desenvolvidas.
Sua atribuição mais importante é estar junto e direcionar o time ágil “no que deve ser feito primeiro” com sua respectiva ordem de execução e conforme o valor para o negócio/cliente e critérios estabelecidos, deixando claro os requisitos, regras de negócios e outras especificações envolvidas, tudo conforme a filosofia e métodos ágeis. Ele também atua na aceitação das estórias concluídas pelo time ágil ajudando a controlar a qualidade e valor final da entrega.
Além de precisar reunir um profundo conhecimento do negócio, da empresa, do mercado e do produto, o PO também deve ter uma série de competências humanas para o bom exercício de seu papel. Nesse sentido, é fundamental que tenha empatia, facilidade de síntese e se comunique com desenvoltura e clareza. Também é interessante conhecer um pouco sobre questões financeiras, como ROI e time-to-market. 
Na prática, o Product Owner é o elo que conecta os clientes, time de desenvolvimento e demais stakeholders. Portanto, é essencial que ele atue de forma próxima a todas as pontas a fim de garantir que todos os envolvidos do projeto compreendam quais recursos são necessários e como o resultado deve ficar.
Além disso, ele tem poder e autonomia para fazer priorizações, porque conhece muito bem o produto e pode fazer isso de maneira adequada. Portanto, deve estar disponível e atuando com uma equipe muito forte no dia a dia para direcioná-la corretamente. 
Por isso, pode-se dizer que suas atividades mais recorrentes são:

  • estar disponível para o time de execução;
  • deixar claro o alvo que deve ser atingido em relação ao negócio;
  • representar outros stakeholders de negócios/sponsors;
  • direcionar o que deve ser feito;
  • priorizar ações de acordo com a necessidade para o projeto/produto.

Outros membros de um projeto: conheça a importância

Embora os POs tenham papel de destaque em relação ao produto, eles não são os únicos a contribuírem para o sucesso do projeto/produto. De uma forma ou outra, eles exercem certa liderança de direcionamento de negócio sobre o time, mas isso não quer dizer que estejam sozinhos na busca pelos melhores resultados.

Analista de negócios

Como o próprio nome do cargo já adianta, esse analista é quem cuida das necessidades da organização, recomendando soluções para aprimorá-la e adequá-la ao modelo de negócio ligado ao projeto/produto em execução. 
É sua responsabilidade garantir que os objetivos do projeto/produto solucionem os problemas existentes. Também ajuda na definição do projeto/produto e na documentação de requisitos técnicos e comerciais.
Na prática, ele pode apoiar e até ser um braço do PO. Ainda assim, vale ressaltar que o Product Owner também pode exercer o papel de analista de negócio, dependendo das características e necessidades da organização. 

Patrocinador ou sponsor

É um membro da alta administração da empresa envolvido na execução. Ele legitima os objetivos da ação e integra o planejamento de projetos de alto nível. Também atua na resolução de conflitos, na aprovação de orçamento, na disponibilização de recursos e na tomada de decisões. 
Como ajuda a remover os obstáculos que ocorrem ao longo do projeto, geralmente obstáculos táticos ou estratégicos, ele abre os caminhos para que o PO o represente e direcione a execução do projeto em termos do negócio. 

Líder do time

Algumas equipes têm um líder específico, determinado previamente. Essa função é dada a alguém que possa chamar a atenção dos outros membros para o cumprimento dos objetivos associados a cada etapa do projeto.
Quem ocupa esse papel também precisa saber ouvir seus companheiros de time, negociar com os provedores de recursos e atuar diretamente na motivação dos membros para que as metas sejam alcançadas. Ele reporta diretamente ao gerente de projeto ou à um gerente funcional, além de se comunicar diretamente com o PO junto com o time, informando sobre o andamento dos trabalhos inerentes ao seu time. 

Scrum Master

O Scrum Master tenta fazer com que a equipe siga os valores e princípios de acordo com o framework Scrum. Ele também é responsável por remover os obstáculos levantados pela equipe, por exemplo, as informadas durante as reuniões diárias.
Esse papel é exercido por uma pessoa que conhece e possui experiência no Scrum. De forma resumida atua fortemente como um líder servil para o time e para o PO, é um grande facilitador para uma boa comunicação e convívio entre o time e PO, facilita cerimônias e garante que o framework Scrum está sendo executado de forma adequada.

Time de desenvolvimento

O time de desenvolvimento é composto, basicamente, pelos profissionais responsáveis pelo desenvolvimento do projeto. Eles devem ter habilidades que se relacionam ao produto em questão. Se ele for um software, por exemplo, será possível encontrar papéis de programadores, testadores, prototipadores, designers e assim por diante. Enfim, é um time multifuncional ou multidisciplinar capaz de realizar o trabalho necessário para a entrega dos incrementos do produto. É importante também os membros serem especialistas generalistas, onde um membro é especialista em algo, mas consegue realizar outras atividades/papéis.
O time é a autoridade técnica e deve possuir autonomia e empoderamento para as decisões técnicas. O PO define “o que deve ser feito”, o time decide “o como será feito”. Scrum Master e PO não devem interferir nas decisões técnicas do time. Eles podem ajudar provendo informações e facilitando cerimônias, mas a decisão técnica é do time.

Outros membros

Os membros são aqueles que trabalham ativamente em uma ou mais fases do projeto, podendo ser colaboradores internos, externos e/ou consultores. As funções variam, é claro, conforme as demandas do projeto, bem como o tempo de dedicação, que pode ser parcial ou integral.

Qual é a relação dessas funções com a gestão ágil?

Tanto o Product Owner e as demais funções têm grande influência na transformação e na gestão ágil. Como mencionado, o PO ainda atua na representação dos stakeholders de negócio, direcionando o time sobre o que precisa ser feito.
Nos métodos ágeis ou em um contexto de escala — no qual a agilidade está presente em todos os processos e etapas — o papel do PO deve ser aplicado e até escalado, tendo em vista que ele se comunica os times e níveis relacionados ao projeto/produto, e é o responsável para o direcionamento do produto que atua.
Como está relacionado a todas as áreas que têm interesse no projeto, ele centraliza diversas visões a respeito do produto. Apesar disso, mantém a integridade do conceito do produto, porque seu foco não recai na execução — função que cabe ao time de desenvolvimento.
Essa mescla de funções gera uma confiança mútua entre o PO e o time. Assim, surge a segurança de cada membro acreditar no desempenho dos outros, gerando a certeza de que há um direcionamento eficaz para todas as funções.
Enfim, o Product Owner pode atuar ajudando a área de finanças, projetos, gestão e políticas. Ele se mostra como um papel de extrema importância justamente por ser um pivô, que permeia várias áreas e pessoas. Com ele e com os outros membros, o desenvolvimento ágil gera valor para o produto e para o projeto, garantindo a excelência em todas as etapas e processos. 
Se você se interessou pelo tema e quer saber como o aplicar a gestão ágil em sua empresa, entre em contato com a gente — a Mooven pode transformar o seu negócio!
]]>

Os 3 desafios atuais da transformação lean

O Lean já está no mercado há algumas décadas. Trata-se de uma filosofia que foca em eliminar desperdícios continuamente e resolver problemas de maneira sistemática, aumentando a eficiência dos processos. Ou seja, tudo aquilo que não acrescenta valor ao que está sendo feito, focando em identificar problemas e em resolvê-los.
A Toyota, por exemplo, é uma empresa pioneira nessa questão, quando lançou o modelo de manufatura enxuta (Lean Manufacturing). Apesar de não ser uma novidade, o método continua atual e pode ser aplicado em qualquer contexto.
Outra filosofia para transformar a performance de pessoas e equipes é a filosofia ágil. São filosofias separadas mas muito aderentes. Quando estão unidas, a agilidade fica muito mais forte e aumenta ainda mais a probabilidade de oferecer muito mais valor
Pensando nisso, preparamos este artigo para que você entenda a filosofia Lean, suas definições e princípios e conheça os principais desafios atuais dessa transformação. Boa leitura!

O que é a filosofia Lean e como ela está associado à performance das empresas?

O termo Lean foi adotado para se referir ao método que a Toyota estabeleceu em sua linha de produção no final da década de 1980. Essa filosofia visa reduzir o desperdício de recursos, além de manter o foco na resolução de problemas. Dessa forma, tudo o que não agrega valor ao serviço ou produto deve ser afastado do processo.
Essa perda representa um custo que pode e deve ser evitado, principalmente de tempo, de mão de obra, de materiais e de outros recursos. O corte de custos desnecessários agiliza as entregas e aumenta a eficiência e a eficácia dos processos. Dessa forma, é possível fazer a coisa certa sem desperdícios.
Podemos resumir os fundamentos da melhoria de performance dos processos das companhias, baseado no Lean Manufacturing, em:

  • busca pela excelência no dia a dia;
  • alinhamento das atividades operacionais com o foco estratégico da organização;
  • criação de valor adequado aos processos internos;
  • valorização da motivação e da competência pessoal;
  • transformação da relação hierárquica convencional para um espírito de equipe;
  • simplificação dos processos;
  • poder de adaptação.

Quais os principais desafios da transformação Lean?

Um dos maiores desafios ao trabalhar com o Lean é conseguir aplicar os seus princípios em grandes empresas, cheias de processos, dependências e burocracias — ou seja, naquelas não ágeis e não Lean. Essa prática deve ocorrer em larga escala, de portfólios aos projetos e operações.
Confira, a seguir, outros desafios atuais da transformação Lean.

1. Falta de planejamento

Para ser possível atingir a excelência, é importante que a implementação do Lean seja tratada como um projeto, que deve estar no planejamento estratégico da organização. Além disso, os colaboradores precisam ser envolvidos de forma programada para que se alcance o comprometimento de toda a equipe dentro dos objetivos do projeto.
Outro fator importante é definir a estratégia da empresa dentro da proposta. É possível ter um plano para cada fase da implementação ou apenas um esquema tratado em correntes sucessivas. É importante deixar claro que a cada melhoria concretizada os benefícios percebidos podem ser cada vez menores — o que não invalida a ação.

2. Falta de abertura à mudança

O sucesso da transformação Lean depende de quanto a empresa está disposta a passar por uma mudança cultural. O corte de desperdícios deve ocorrer em toda a cadeia de produção, envolvendo as áreas de manufatura, marketing, comercial, recursos humanos, entre outras.
Existem muitas formas de colocar o método em prática, partindo de iniciativas internas ou de consultoria externa, por exemplo. Independentemente da origem, um grupo pode ficar responsável por mapear o fluxo de valor e iniciar a implementação em conjunto com as diversas áreas da organização.
Nesse momento, a complexidade da execução pode começar a aparecer. Ela dependerá da abertura da empresa para as mudanças. Além disso, é preciso envolver todas as pessoas — dos mais variados níveis hierárquicos e com diversos interesses relacionados ao sucesso da realização.

3. Falta de liderança

É imprescindível que os gestores estejam engajados na metodologia e na aplicação do Lean. Embora promova a autonomia, o método depende de uma transformação cultural que deve encontrar apoio nos líderes. Dessa forma, é possível gerar uma transformação na relações hierárquicas convencionais para um espírito de equipe.
Esse fator é ainda mais relevante na resiliência necessária durante o período de implementação do Lean, em que a lucratividade ou a produtividade pode diminuir temporariamente em razão da adequação dos processos. Lembre-se de que o sucesso do Lean depende da forma como a empresa enxerga a filosofia dentro do seu contexto.

Como implantar a filosofia Lean em uma empresa?

Sempre que há desperdícios em uma organização o Lean pode e deve ser aplicado. Sistemas arcaicos, paradigmas e status quo podem ser desafios para um mindset ágil dentro das empresas. Por isso, é preciso pensar em formas de transformar a rotina e aplicar o Lean de forma efetiva.
O método nasceu na área industrial, logo, está muito ligado aos processos e à eficiência dos fluxos operacionais. Seu foco está na eliminação de desperdícios e retrabalhos. Quando realizamos muitas tarefas ao mesmo tempo, estamos chaveando de uma função para outra. Esse chaveamento demanda tempo e nos faz perder o foco, colaborando para a questão geral do desperdício.
O cálculo da eficiência do fluxo deve ser feito considerando todas as etapas do processo. É preciso conhecer o tempo total de execução das tarefas e o tempo que, efetivamente, gerou valor. Às vezes, percebemos que metade do número de horas é o necessário para cumprir aquele trabalho.
Em qualquer meio que tenha processos, seja ele fabril ou não, é possível realizar as medições e indicar o desperdício para atuar neles. Dessa forma, trabalhar no que realmente agrega valor ao resultado e ao objetivo da operação é o que torna o processo verdadeiramente enxuto.
No setor da tecnologia da informação, por exemplo, os princípios da filosofia Lean fez surgir o Lean Software Development — abordagem usada também no desenvolvimento de softwares ágeis, na administração de aplicações e no suporte e prestação de outros serviços relacionados à área. O importante é eliminar as tarefas e as funcionalidades que não são úteis e potencializar o que for mais lucrativo.
Tudo que não acrescenta valor ao resultado é desperdício. Dessa forma, o Lean surge como uma forma de pensar e de agir para não atuar com os gastos desnecessários. Para isso, as empresas devem desenvolver uma visão do todo, não abrir mão da qualidade e saber aproveitar todos os seus processos de forma eficaz.
Quer eliminar os desperdícios na sua empresa e ganhar eficiência, solucionando os problemas do seu negócio? Então entre em contato conosco! Nossa equipe está pronta para atendê-lo com agilidade.
]]>

Saiba como otimizar o Product Backlog e deixá-lo saudável!

otimizar o Product Backlog e deixá-lo saudável

Gerar valor para o produto pode ser um dos grandes desafios em um projeto, concorda? Nesse contexto, muitos profissionais têm dúvidas sobre como otimizar o Product Backlog a fim de deixá-lo saudável. O que precisa ser feito? Quais processos alterar?

Para responder a essas e a outras questões, preparamos este conteúdo especial sobre o tema. Ao longo do texto, você encontrará uma série de dicas e informações relevantes para aprimorá-lo em seu negócio. Boa leitura!

Afinal, o que é Product Backlog?

De forma bastante resumida, o Product Backlog ou Backlog de Produto é uma lista que contém todas as funcionalidades desejadas para um determinado produto, cujo conteúdo é definido pelo Product Owner. Essa figura, também chamada de PO, é um dos membros das equipes que trabalham com Scrum ou outro método ágil de desenvolvimento — seja de projetos, seja de produtos. 

Em outras palavras, o Backlog é uma reunião dos requisitos, descritos em sua própria linguagem, que o cliente espera receber no final do projeto. Para muitas pessoas, sua criação é o ponto de partida do desenvolvimento ágil. 

No modelo tradicional da gestão de projetos, por exemplo, o escopo deve ser fechado antes do início da execução. No Scrum, em contrapartida, há um consenso de que o estágio inicial do projeto não é o momento ideal para isso. Isso porque, nas primeiras etapas, o projeto pode apresentar algumas indefinições. Isto é, algumas hipóteses ainda podem precisar de esclarecimento.

Geralmente, no primeiro sprint do projeto, não há um esforço que demanda muito tempo, como escrever os requisitos previsíveis ou todas as tarefas. A partir disso, o Product Backlog cresce e muda conforme se obtém conhecimento a respeito não só do produto, mas também dos stakeholders.

Qual é a sua importância para o negócio?

Em suma, ele é fundamental para capturar toda a lista de desejos dos stakeholders — o que eles esperam, como desejam, as funcionalidades primordiais e a forma como enxergam o projeto em questão.

Como são prioridades e requisitos estabelecidos por quem receberá as entregas, seu foco recai sobre os indivíduos e as interações que existem entre eles, tornando mais fácil a compreensão sobre os objetivos. Como é embasado nas finalidades do projeto e na comunicação dos envolvidos, as mudanças por ele abarcadas ditam novos direcionamentos que o desenvolvimento pode alcançar. 

Nele, o cliente pode descrever que deseja receber os feedbacks dos usuários do software por meio de uma caixa de comentários, por exemplo. Essa definição não é técnica, isto é, ela não delimita detalhes acerca de como a ação será desenvolvida pela equipe. Em vez disso, ela parte do contexto profissional de quem elegeu esse objetivo como uma prioridade do projeto, dando voz aos principais interessados no resultado. 

Vale lembrar que o Product Backlog permite mudanças. Dessa forma, é indicado partir dos requisitos óbvios e, aos poucos, definir os mais complexos. Afinal, um pouco de tempo é útil para o amadurecimento do escopo, possibilitando a captura e o controle de todas as demandas — algo indispensável para que o resultado final atinja as expectativas. 

Como otimizar o Product Backlog?

Ter um Backlog de Produto saudável requer uma lista cujas informações podem facilmente ser identificadas por todos os envolvidos no projeto. Apesar disso, vale ressaltar que a sua gestão e a sua priorização são responsabilidades atribuídas ao PO.

Dito isso, ter um Product Backlog saudável consiste em manter boas práticas ao fazer a manutenção desse componente tão importante. Sendo assim, haverá a possibilidade de aproveitar ao máximo a produtividade do time para entregar o maior valor viável em um intervalo de tempo mais curto. Veja, a seguir, algumas dicas para otimizá-lo em seus projetos!

Faça limpezas periódicas

Na maioria das vezes, POs mais adicionam do que removem itens do Backlog. A princípio, não há nada de errado nessa prática, desde que ela contemple os desejos dos usuários e/ou dos clientes.

Entretanto, é preciso ter bastante atenção à idade de cada item, visto que eles podem ficar inativos ou simplesmente perder a prioridade em relação a outras funcionalidades. De forma gradativa, alguns objetivos não têm mais motivos para constarem na lista, mas vão se acumulando e tendem a atrapalhar a compreensão sobre o projeto. Caso prefira não se livrar de alguns pontos, marque-os como “inativos” ou “sem prioridade”. 

Evite os exageros

É inegável que projetos grandiosos podem ter listas imensas. De qualquer modo, é fundamental analisar o Backlog de maneira crítica a fim de detectar eventuais desperdícios, principalmente os que estão ligados à criação de user stories que não serão utilizadas. 

Isso porque cada entrega realizada pela equipe pode mudar as percepções e, por consequência, os desejos dos stakeholders. Portanto, vários dos objetivos iniciais podem ficar pelo caminho — sem eles, a execução seria mais precisa, e a produtividade, maior.

Lembre-se de que não há um número mágico e a extensão da lista varia muito de acordo com o projeto. Ainda assim, trabalhar com até 100 itens é o indicado para boa parte dos casos. 

Mantenha a organização

Além das limpezas periódicas e da coesão, a organização é fundamental. Uma das estratégias aplicadas nesse sentido é a organização temática dos itens, pois isso permite a visualização dos impactos e como eles se relacionariam entre si. 

Com isso, o time terá clareza na visualização e poderá checar quais são os próximos desafios. Cabe ressaltar que é uma atribuição do PO manter a lista atualizada e de acordo com as necessidades dos stakeholders. Ela também deve estar disponível para que todos possam acessar e contribuir.

Como a Mooven pode ajudar nesse processo? 

Mooven foi criada em 2016 com o objetivo de auxiliar outras empresas por meio de entregas ágeis. Levando isso em conta, a Mooven pode ajudar em todo o processo de estruturação do modelo ágil, com a identificação do Product Onwer, com a geração do Product Backlog e com o processo de priorização a cada sprint.

Enfim, a otimização do Product Backlog pode ajudar o seu negócio a se aproximar do valor que os clientes esperam. Concentre seus esforços para deixá-lo saudável a fim de conquistar bons resultados.

Se você gostou do texto, entre em contato com a Mooven agora mesmo — nós podemos ajudar!

Gestão de equipes ágeis: como fazer em tempos digitais?

transformação digital é uma das principais responsáveis pelas alterações nas estruturas organizacionais das empresas ao longo dos últimos anos. A gestão de equipes e de projetos também sofreu impactos significativos nesse sentido. 

Em tempos digitais, guiar seu time para um resultado satisfatório pode ser bastante desafiador. Pensando nisso, elaboramos este artigo. Durante a leitura, você entenderá qual é o papel do líder nos dias de hoje e o que pode ser feito para aprimorar a forma de gerir uma equipe. Acompanhe até o fim para saber mais!

Entenda a importância de uma boa gestão de equipes ágeis

Por muitas décadas, guiar a produção de um time na execução de um projeto era algo embasado na relação entre comando e controle — a liderança estabelecia um plano de ação e seus subordinados deveriam segui-lo em qualquer hipótese. A criatividade e a flexibilidade não tinham nenhum espaço entre os membros. 

Aos poucos, as pessoas passaram a ser mais ouvidas, sem que ainda houvesse uma participação plena de todos os envolvidos. Porém, na virada do século 20 para o 21, os conceitos atrelados à administração e às formas de liderar um grupo profissional passaram por inúmeras modificações, o que se deve, em grande parte, ao avanço dos recursos tecnológicos. 

Nesse contexto, os processos deixaram de ser extremamente burocráticos ou rigorosos. Diante dos diversos modos de fazer, os gestores se viram na necessidade de abrir mão dos caminhos engessados e das reuniões intermináveis: era preciso ganhar tempo, reduzir erros e fazer testes o quanto antes. Afinal, desse jeito seria viável entregar soluções capazes de gerar valor para seus clientes. 

Despontava, então, o manifesto ágil, que priorizava os indivíduos, as interações e a colaboração em detrimento de processos robustos e ferramentas tradicionais. O objetivo era chegar ao desenvolvimento com mais rapidez e eficiência.

Como resultado, as pessoas que fazem parte dessas equipes ganharam mais espaço para expor suas ideias e, consequentemente, para buscar saídas distintas e encontrar inovações, atingindo metas surpreendentes. No próximo tópico, abordaremos sobre o papel do líder nesse cenário. 

Saiba qual é o papel do líder em tempos digitais

Em um ambiente de trabalho verdadeiramente colaborativo, as lideranças precisam servir seus liderados e oferecer suporte sempre que preciso. Por conta disso, a figura do gestor fechado em sua sala, pouco participativo e cobrando relatórios extensos sobre todas as atividades perdeu espaço. 

Apontar os erros deixou de ser necessário, bem como manter a verticalidade nas relações de trabalho ou ter uma alta rotatividade entre os colaboradores. Como o que mais importa nos métodos ágeis é o resultado alcançado e os valores gerados a partir dele, as lideranças passaram a entender que certos “muros” não faziam sentido — eles deveriam ser derrubados em nome da inovação. 

Para que isso aconteça, mais do que humanizar o espaço de trabalho —  o que foi convencionado em startups —, é preciso promover uma profunda mudança organizacional, para que a prática de liderar também seja humanizada. Escutar tende a ser mais relevante do que falar; em vez de destacar os problemas, o indicado é sugerir as soluções. 

Portanto, para compreender bem as pessoas ao seu redor, líderes devem olhar para si mesmos e encontrar suas próprias forças e fraquezas. Quais melhorias podem ser feitas? Quais mudanças trariam consequências benéficas para a equipe? Como determinada conduta ajuda o andamento do projeto? Como auxiliar e dar suporte para os outros profissionais?

Descubra o que é o método ágil e como aplicá-lo na gestão de equipes

Em termos bem resumidos, o método ágil nada mais é do que um jeito de agir e estruturar a gestão de um projeto ou de uma empresa como um todo. Um de seus principais diferenciais em relação aos outros métodos está associado aos impactos que ele causa na produtividade. Suas outras características marcantes são:

  • mensurar resultados para aprimorá-los;
  • antecipar entregas sem prejudicar a qualidade;
  • agilizar a comunicação;
  • evitar desperdícios de tempo, de material e de recursos;
  • simplificar os processos.

A composição da equipe, assim como o modo de conduzir sua gestão, depende muito do escopo da iniciativa. Entretanto, em projetos ágeis, há o Scrum Master (SM), o Product Owner (PO) — representante da área de negócios, que recebe as demandas e as leva para o time, estimar e quantificar o que precisa ser feito — e a equipe de projeto propriamente dita. No desenvolvimento de softwares, por exemplo, teremos desenvolvedores, testers, designer etc. 

Muitas vezes, em um projeto ágil, a presença do SM e do PO é essencial, uma vez que eles desempenham papéis centrais para a aplicação do método. Vale ressaltar que o PO não se configura exatamente como um líder, tendo em vista que seu papel é entender a necessidade dos negócios e traduzir o que é necessário para o restante dos envolvidos.

Em um método desse tipo, existem algumas fases que guiam as lideranças e a ordenação dos procedimentos. As equipes, por sua vez, são formadas por pessoas independentes — cada uma sabe qual a é sua tarefa e o que precisa ser feito. Há uma reunião diária, também chamada de daily, na qual se discute o que está em desenvolvimento. Ela é uma boa oportunidade para saber se há algum problema que o SM possa ajudar a solucionar junto ao Product Owner.

Na prática, não há uma especificidade do método ágil em relação à gestão de equipe — o essencial é garantir que ela seja autônoma. Em relação ao projeto, é imprescindível ter alguns cuidados, como mantê-lo saudável, cumprir o prazo e atender à demanda proposta pelo cliente. Sendo assim, vale a pena organizar sessões de feedbacks e melhorias contínuas para acompanhar de perto o desempenho dos colaboradores.

Veja como melhorar a gestão de equipes em métodos ágeis

Para fazer com que sua organização vivencie uma cultura de inovação e tire um bom proveito em projetos ágeis, vale a pena contar com uma consultoria especializada, capaz de auxiliar com a implementação da metodologia e indicar soluções para a gestão de equipes. Assim, seu negócio ficará alinhado ao que se pratica nesse sentido em tempos digitais.

Se você gostou do texto e quer receber conteúdos exclusivos em seu e-mail, assine a nossa newsletter gratuita!

Enfrentando e superando os desafios do desenvolvimento ágil de softwares

O desenvolvimento ágil de software é visto por muitas organizações como um método de extrema eficiência. No entanto, sua implementação pode gerar algumas dúvidas, não é mesmo? Afinal, quais seriam os principais obstáculos para aplicá-lo?

Foi pensando nisso que criamos este texto. Ao longo da leitura, você entenderá quais são os principais desafios dessa forma de desenvolver e o que pode ser feito para enfrentá-los. Aproveite o conteúdo!

Como funciona o desenvolvimento ágil?

Abertos às mudanças em qualquer fase do projeto, os modelos ágeis de desenvolvimento — Scrum, XP, ASD Crystal etc. — ganharam inúmeros adeptos durante o século 21.

Atualmente, são empregados por organizações que se destacam no mercado em relação a práticas inovadoras, como Google, Intel, Yahoo e Microsoft. A independência da equipe e foco na satisfação dos clientes são exemplificações nítidas dos benefícios que eles proporcionam. 

Quando aplicados à produção de softwares e soluções digitais em geral, eles viabilizam a elaboração de adaptações contínuas e incrementais para os projetos.

A visão ágil também contribui muito por definir prioridades específicas de acordo com o andamento dos processos. Assim, ocorrem entregas parciais, que possibilitam perspectivas prévias e a realização de testes para corrigir erros e alcançar os resultados esperados. 

Em poucas palavras, eles são mais recomendadas para desenvolvimentos que exigem mudanças com frequência ou cujos requisitos envolvidos são passíveis de alterações.

Também tendem a ser mais bem aproveitados em equipes pequenas, que têm até 10 integrantes — o que não quer dizer que eles não sejam aplicáveis em times numerosos. 

Quais os principais desafios do desenvolvimento ágil de softwares?

O desafio mais característico enfrentado pelas empresas que utilizam esses modelos é conseguir atingir por completo as expectativas de seus clientes.

Na maioria das vezes, isso acontece por uma questão de cultura organizacional, tendo em vista que muitos empreendimentos não se prepararam adequadamente para enxergar valor em entregas parciais.

Outro fator que ajuda a explicar esse impasse é o fato de a transformação digital ainda ser recente em muitas corporações. Assim, há certa dificuldade em conseguir demonstrar a eficiência que os métodos ágeis podem ter. 

Em algumas situações, o cliente pode querer ver algo pronto ou concretizado no projeto que está sendo desenvolvido. Contudo, grande parte das metodologias utilizadas (Scrum e afins), funciona a partir de entregas parciais e prioritárias, com o objetivo de chegar com agilidade ao MVP (Produto Viável Mínimo), que consiste no demonstrativo de funcionamento mínimo do software. 
 
Imagine um app com 10 funcionalidades, por exemplo. Nesse caso, há como priorizar e entregar as 3 principais e depois analisar quais serão entregues ao longo das etapas.

Depois disso, são feitas as entregas incrementais, que vão compondo o aplicativo até alcançar a versão final. Ao conhecer uma funcionalidade por vez, pode-se ter respostas e reações rápidas.

Sendo assim, é importante mostrar ao cliente que ele ganha tempo e pode chegar a um resultado bem mais satisfatório. Em contrapartida, a entrega não acontece de uma vez — o desenvolvimento evolui com o tempo e possibilita alternativas como a prototipação para reduzir erros e alinhar expectativas.

Lembre-se que essa noção pressupõe uma quebra de paradigma e é por isso que os benefícios devem ser ressaltados constantemente.

Como lidar com os prazos?

Para andar em dia com os prazos do projeto, é necessário definir o escopo e as prioridades. Com base nessas informações, há como fazer estimativas para saber quanto tempo leva cada estágio e assim definir sprints que vão de 1 a 4 semanas.

Com base na extensão do sprint e no tamanho do time alocado no projeto, a capacidade é definida. Isso é importante para contextualizar os clientes e deixá-los um pouco mais por dentro do desenvolvimento. 

Como montar uma equipe?

A montagem do time depende da necessidade e da natureza do projeto. Normalmente há o Scrum Master, alguém responsável pelo controle de qualidade e, caso seja necessário organizar a infraestrutura, um arquiteto de dados.

Eventualmente, podem aparecer outras necessidades, como desenvolvimento mobile web, mas tudo depende da demanda da cliente.

Quais são as vantagens do desenvolvimento ágil?

De acordo com um estudo publicado pelo Laboratório de Engenharia de Software do Departamento de Ciência da Computação UFMG, que desenvolveu alguns pilotos a partir de métodos ágeis, muitos benefícios foram observados.

Poder visualizar a situação e o progresso do projeto é extremamente vantajoso para a equipe responsável e para os stakeholders. Consequentemente, também cresce a capacidade de tomar decisões para contornar eventuais problemas.

Os pesquisadores também apontaram que, durante a execução dos pilotos, os desenvolvedores e outros membros do time se engajaram gradativamente, conforme percebiam os progressos alcançados.

Constatou-se, ainda, que o produto final teve maior valor, porque exigiu-se menos esforço para lidar com funcionalidades pouco relevantes. Sendo assim, a atenção adicional para os requisitos-chave foi recompensada. 

Ao concluir a pesquisa, os especialistas destacam que, apesar das dificuldades iniciais, as vantagens se mostraram muito significativas, levando o laboratório a priorizar a aplicação de metodologias ágeis em seus projetos. 

Por que sua empresa deve ser ágil? 

Para além de desenvolver apps com UX e UI impecáveis, é válido considerar o desenvolvimento ágil de softwares em sua empresa como uma rotina. Afinal de contas, como demonstramos ao longo do texto, são muitos os benefícios que ele proporciona, embora tenha, é claro, seus próprios desafios. 

Evidentemente, mudar uma cultura tradicional devidamente estabelecida não é algo simples de se fazer, bem como montar equipes totalmente adaptadas ao ágil. 

A integração entre pessoas e departamentos também deve ser considerada, porque promove a descentralização das autoridades. Desse modo, cada membro da equipe terá independência em sua área de atuação e, ao mesmo tempo, precisará se manter alinhado às demandas gerais do projeto. 

Para contar com todo o suporte necessário para essa implementação, uma consultoria de tecnologia é extremamente bem-vinda, porque pode ajudar na montagem da equipe e coordenar toda a execução. Dê preferência a uma empresa que seja 100% ágil, com uma maioria de profissionais formados em agilidade.

Enfim, o desenvolvimento ágil de software requer inovação e, por isso, também carrega consigo alguns obstáculos a serem superados. Ainda assim, ele pode fazer muita diferença em sua organização. 

Se você precisa de auxílio com métodos ágeis, tecnologias e inovações, entre em contato conosco — nós podemos ajudar!