Times de produto e métodos ágeis: como construir produtos de sucesso

Mundo Vuca

Vivemos em um mundo globalizado e amplamente volátil, e estamos vivendo um momento de transformação digital, onde tudo se volta para a agilidade. Com esta mudança, os ambientes empresariais também estão mudando e deixando o modelo tradicional de trabalhar de lado e buscando novas formas de realizar esse trabalho com facilidade, transparência, qualidade e visando a satisfação dos seus usuários finais, focando cada vez mais no ágil e na experiência de usuário.

Assim, os times dessas empresas precisam se adaptar às mudanças e seguir esse novo jeito de trabalhar, se transformando nos chamados times ágeis, squads ou scrum team – nomenclaturas que vão variar muito de acordo com a metodologia aplicada. Caso seja do seu interesse saber mais sobre inovação tecnológica e o chamado “Mundo Vuca”, indico esse artigo: Inovação Tecnológica: diferencial ou sobrevivência?

Dentro dos contextos das maiorias das empresas atuais é preciso entender que trabalhar de forma ágil não é fácil nem possível de uma hora para outra, sendo uma verdadeira mudança de mindset e cultura que deve ser trabalhada diariamente entre todos: o time de desenvolvimento, o cliente e os stakeholders. Principalmente nas empresas tradicionais, às vezes existe uma certa dificuldade e resistência em virar essa chave e passar a pensar de forma ágil, e realmente não podemos cobrá-los de imediato, é necessário realmente um trabalho de evangelização e construção de cultura.

Para que essa evangelização seja possível é preciso que os times transpirem agilidade em tudo o que fazem, soando de forma natural e motivada.

Nesse texto, vou falar um pouco mais sobre a formação desses times, trazendo uma visão mais direcionada a construção de produtos e as implicações dentro desse contexto.

O que torna um time ágil?

Antes de entrar no contexto da formação dos times vamos discutir dentro do cenário de desenvolvimento, quais as características de um time que o torna ágil perante as outras formas de desenvolvimento e gestão de projetos. Posso destacar alguns pontos chaves, que devem ser verdadeiras estrelas guias para o seu time, caso você esteja atuando dentro de um cenário ágil ou assim deseja trabalhar de agora em diante:

• Entregas pequenas e frequentes, sempre com a intenção de validar uma hipótese – pensar sempre na entrega de valor ao seu usuário com pequenas iterações no seu produto;
• Encorajar criatividade e proatividade, sendo tolerante a falhas –  todos os integrantes do time devem fazer parte das definições de solução, não cabe somente ao product manager ou product design esta atribuição.
• Simplificar conceitos e soluções (pensando sempre na construção de um MVP) – sempre ter em mente a construção de soluções mínimas viavéis do seu produto para que sejam validadas pelos seus usuários evitando construções desnecessárias e/ou que não façam sentido ou não sejam utilizadas.
• Feedback concreto dos usuários – sempre que possível colher feedbacks com seus usuários sobre suas entregas como modo de validação e geração de idéias para construções futuras. Seja sempre centrado no usuário.
• Processo de discovery contínuo – a descoberta do seu produto não é somente no início do projeto quando se mapeia a dor e solução propostas, o processo de descoberta ocorre durante todo o ciclo de vida do seu produto, devendo sempre revisitar e atualizar seu backlog de features.

Como são formados os times de produto?

Imagine que você queira construir uma casa e para isso já comprou o terreno, os materiais necessários para construção e definiu orçamento para mão de obra, porém não contratou nenhum engenheiro e arquiteto para desenho da planta, ou mesmo pedreiros para levantar as paredes. Dentro deste cenário acredita que irá conseguir ter sucesso na construção dessa casa? A sua resposta a pergunta com certeza é: ‘Não!’. Como é possível que esta casa seja construída se eu não tenho mão de obra para isso?!

Trazendo para o contexto de produto, podemos considerar a casa como sendo o produto, os materiais como os recursos e os engenheiros, arquitetos e pedreiros nosso time de desenvolvimento; assim da mesma forma, sem um time de produto não conseguiremos construir nosso produto e muito menos entregar valor para o nosso usuário final, simples assim!

A definição deste time vai variar muito de contexto para contexto, de empresa para empresa, e quando digo isso me refiro a multidisciplinaridade do time. Para a construção de qualquer produto é necessário um time que vá realmente por a mão na massa para resolver o problema encontrado, e é na definição dessa equipe que se encontra o diferencial e muitas vezes a garantia de sucesso ou fracasso de um produto. A escolha das pessoas que vão trabalhar em um time de produto tem de ser bem pensada e estruturada de acordo com a necessidade de cada produto. Como cita John Doerr, investidor do Vale do Silício, ‘’nós precisamos de equipes de missionários não de equipes de mercenários.’’, onde os mercenários simplesmente fazem o que são mandados fazer, já os missionários se preocupam realmente em resolver a necessidade do usuário.

Uma equipe ou time de produto normalmente é composto por um gerente de produto, um design e até dez ou doze engenheiros, mas isso não é regra, pode e vai variar de acordo com o produto em que se esteja trabalhando. Pode acontecer de não ser necessário um design, se seu produto não tiver interface com o usuário, ou pode ser necessário um número menor de engenheiros, mas como uma equipe mínima, seria ideal um gerente de produto, um design e dois engenheiros.

É importante dizer que em uma equipe de produto não existe uma hierarquia, ninguém trabalha para ninguém, não existe cargo de chefia. É uma organização totalmente horizontal, onde cada um tem o seu papel definido e o trabalho de todos em conjunto fazem o produto acontecer. Cada área de desenvolvimento deve se reportar ao seu gerente funcional para a resolução ou tratativa de alguma situação que não seja possível tratar entre o time, não existindo assim centralização. Ressalto que o gerente de produto não é chefe de ninguém, todo o time age de forma colaborativa- produto, design e engenharia – para construir e entregar sempre o melhor produto.

Um ponto interessante é que as equipes de produto devem ter o mínimo de dependência entre elas, por isso possuem autonomia para resolução das situações referentes ao produto que surgir, Marty Cagan fundador do Silicon Valley Product Group, fala que as equipes de projeto devem ser capazes de tentar resolver os problemas aos quais são designadas da forma que julgarem mais conveniente.

Agora que já conhecemos um pouco da formação e estrutura de um time de produto, vamos falar um pouco de cada um desses papéis, entender suas hard e soft skills, além de suas responsabilidades na construção de um produto!

O papel do Product Manager

O gerente de produto ou product manager é aquela pessoa que cuida da vida de um produto. Ele deve ter uma visão holística e ao mesmo tempo detalhada do produto, estando constantemente preocupado com o que está sendo construído mas também com o que será construído em seguida.

Costumo dizer que o product manager precisa ter uma incerteza real do que vai ser construído no futuro; posso parecer incoerente com essa afirmativa quando logo antes neste artigo eu disse que ele deveria ter uma visão do que virá em seguida, mas nas linhas seguintes eu me explico!

Quando eu digo incerteza, estou me referindo ao fato dele estar constantemente avaliando e realizando um processo de discovery contínuo sobre o produto. Não se pode ter certeza do que será construído a um médio ou longo prazo, trabalhar com produto está muito relacionado ao contato com seu usuário e a construir de acordo com o que sentimos e observamos de retorno dele. Não estou dizendo que não devemos ter um roadmap estratégico do produto com apontamentos a curto, médio e longo prazo (now, next and later), muito pelo contrário, isso é muito importante para ter uma visão – mesmo que suscetível a mudança – sobre o que está sendo pensado para o produto alinhado a estratégia do negócio. O que digo é que não devemos nos ater a esse roadmap como uma verdade absoluta, pois como apontei acima, com produtos trabalhamos de acordo com as percepções dos nossos usuários, então devemos ter consciência de que planos de médio ou longo prazo podem mudar e com certeza em algum momento isso vai acontecer.

Um ponto importante sobre o gerente de produto é que ele deve estar em constante comunicação com o time  de engenharia e design, repassando a eles como está a saúde do produto de uma forma geral, alinhando o time e colocando-os na mesma página, direcionando os próximos passos, mas sempre com muito cuidado para não impor as soluções dos problemas encontrados que precisam ser resolvidos, essa decisão é do time como um todo.

Não é papel ou função do gerente de produto apontar solução para os problemas, seu papel é envolver o time e contextualizar sobre as necessidades e juntos chegarem em uma solução viável. Claro que ele já pode de acordo com suas percepções e conhecimento do negócio, ter um caminho pensado que poderia ser encarado como uma solução viável, mas ele nunca deve impor, pelo contrário, ele deve trazer para discussão e em comum acordo do time encontrar o melhor caminho.

Para definir uma solução de um problema é importante todos do time estarem envolvidos, pois todos podem e devem contribuir: o gerente de produto com sua visão de negócio e estratégia, o design com suas percepções de experiência de usuário e os engenheiros com as ponderações técnicas e possibilidades na construção. Como Marty Cagan cita em seu livro Inspired, ‘gerentes de produto são responsáveis por contribuir com seu time’.

Existem algumas áreas de conhecimento que são importantes para o product manager ter dominância e entendimento para construção de um produto, são elas:

• Clientes – deve entender o seu público alvo, quais suas necessidades, principais dores, o que pensam e o que esperam do seu produto;
• Dados – deve procurar analisar os dados encontrados sejam por pesquisa, observação de uso ou outros e transformá-los em informações que possam ser usadas na tomada de decisão;
• Negócio – deve entender realmente o negócio como um todo, os stakeholders e suas necessidades, absorvendo também questões das outras áreas como marketing, comercial e vendas;
• Mercado – deve identificar seus concorrentes, qual sua posição no mercado, como gerar impacto de forma positiva e definir qual o diferencial de mercado do seu produto.

Um profissional de produto deve permear entre todas as áreas de construção do produto, ele não pode apenas se ater a gerar backlog de funcionalidades a serem construídas, seu papel é muito além disso, ele deve ser apaixonado pelo seu produto e alimentar essa paixão no seu time. A persistência, a resiliência e a empatia são virtudes características imprescindíveis para a pessoa que assume esse papel de gestão de produto.

Tirando uma dúvida comum: PM ou PO?

Afinal, qual a diferença entre um Product Manager (PM) e um Product Owner (PO)? De uma forma geral podemos conceituar o Product Owner ou PO, como sendo a pessoa responsável por maximizar o valor do produto, refinando as estórias de usuário, levantando os requisitos junto aos stakeholders e gerenciando o backlog. O seu papel é mais no âmbito operacional. Já o Product Manager ou PM tem um papel mais gerencial, voltado a estratégia do negócio, sua visão está mais direcionada ao futuro do ciclo de vida do produto pensando em escalabilidade e estratégia de mercado.

Mas na prática, a definição desses papéis vai ser muito distinta de acordo com a empresa em que você atua, pois em algumas empresas maiores esses papéis podem estar bem definidos e escalonados, em outras pode existir apenas o Product Manager fazendo os dois papéis, ou ainda outras que exista apenas o Product Owner que realiza também o papel de PM. O que é certo, é que não tem como existir apenas um papel, caso assim seja, a pessoa responsável estará executando as duas funções durante o seu dia a dia de trabalho com o time de produto.

O papel do Product Design

Podemos afirmar que o trabalho do design dentro de uma equipe de produto é imprescindível na construção do produto e na geração de valor para os usuários. Na antiga e comum gestão de produtos o papel do product design era muito voltado para o design visual, onde a construção era direcionada apenas pelos requisitos passados pelo gerente de produto. No cenário atual este papel mudou significativamente, onde o design passa a trabalhar lado a lado com o gerente de produto auxiliando principalmente na descoberta do produto. Seu papel dentro do time além do design de interação e visual está atrelado a descoberta do produto, experiência de usuário, prototipagem, testes de usabilidade e de usuário.

Podemos dizer que a sua preocupação com o produto, se torna similar à do gerente de produto, trazendo claro também suas percepções de usuário. Por essa similaridade ao papel do gerente de produto, há muitos questionamentos sobre essa divisão de funções, até onde vai o papel do gerente de produto e até onde vai o papel do design? Não acredito que exista uma resposta certa, ou um limiar assertivo neste ponto, defendo muito o equilíbrio entre esses dois papéis. Muito vai da dinâmica em si, e das suas percepções como time. A sinergia entre esses dois papéis tem de ser alta, pois depende deles a construção do produto certo, e essa troca de conhecimento e experiências pode e deve auxiliar e muito para isso.

O design tem seu foco todo direcionado ao produto e conhece as ferramentas necessárias para que seja possível captar, entender e trazer valor para a construção do produto a partir do ponto de vista do usuário, e essa percepção de user experience é o diferencial principal atribuído a este papel, já o gerente de produto tem uma visão mais estratégica e holística sobre o produto.

Pode acontecer de em algumas situações ser necessário o PM desempenhar esse papel de design, caso em seu time não exista um design dedicado ou a empresa não entenda a necessidade de um, porém isso pode acarretar em várias implicações da construção do produto, onde muita da carga de design vai ficar a cargo dos engenheiros, que vão ter de compreender sozinhos o design, o que de toda forma afetará diretamente a entrega de valor do produto.

Um gerente de produto ter experiência ou conhecimento em UX/UI traz um valor muito grande para o papel, pois pode despertar uma visão diferente sobre o produto e as soluções a serem propostas e mesmo trazer discussões proveitosas entre o time de design e o PM, agora ter este conhecimento não implica na substituição do papel do design, ambos tem suas funções e responsabilidades dentro de um time de produto, o ponto aqui é a facilidade de comunicação entre eles, que também caso não se tenha este conhecimento prévio por parte do PM na área de design, o mesmo pode e será desenvolvido entre eles.

Para sintetizar essa relação entre gerente de produto e design, vou trazer um texto  onde Marty Cagan nos apresenta cinco pontos-chave para um relacionamento saudável e bem sucedido com o seu design:

1. Faça o que precisar fazer para que seu design sente ao seu lado.
2. Inclua seu design desde o início de cada ideia.
3. Inclua o design em todas as interações de usuário e consumidores possíveis. Aprendam sobre os usuários e clientes juntos.
4. Lute contra a sua tentação de fornecer ao seu design suas próprias ideias de design. […].
5. Encoraje seu designer a iterar cedo e frequentemente. […].

O papel do design vai muito além do ‘desenhar telinhas bonitinhas’, está muito mais direcionado à descoberta do produto e do que construir.

O papel dos Engenheiros

Outro papel importante dentro da equipe de produto é o dos engenheiros, ou desenvolvedores como são comumente chamados. Este papel está mais relacionado à construção do produto em si, consumindo os insumos gerados pelo gerente de produto e designers.

É de grande importância para o gerente de produto ter um bom relacionamento com os engenheiros de seu time, pois ele precisa estar em contato constante com eles, seja para passar a visão do produto em si, discutir um problema ou direcionar uma implementação.

O PM precisa saber programar?

Neste ponto vem uma pergunta muito comum de se fazer: é necessário que o gerente de produto tenha conhecimento em programação (desenvolvimento)? Respondo esta pergunta com tranquilidade em dizer que não é um requisito para a função de gerente de produto, porém caso o PM tenha conhecimento em programação, em qualquer linguagem que seja, vai sim lhe ajudar na comunicação com seu time de engenheiros. Será muito mais fácil você discutir uma solução para um problema ou uma ideia de construção se entender sobre o desenvolvimento e todas as suas implicações, isso lhe dará argumentos na discussão. Claro que não é necessário que você saiba codificar ou seja expert em uma linguagem específica, você entendendo da lógica e um pouco sobre o processo de desenvolvimento já é suficiente!

Gosto muito de dizer que se você tem um time eficiente você está munido das ferramentas que precisa, basta saber ter ao seu lado as pessoas certas para lhe ajudar e direcionar, mas claro, para isso é preciso humildade em saber o que você não sabe e mostrar isso ao seu time, é muito mais válido você assumir que não tem conhecimento de algo do que tentar provar ou deduzir algo que você não tem certeza! Use a estrutura do seu time, vocês estão juntos nessa. Não tenha vergonha de não saber e nem de perguntar, o crescimento de um é o crescimento de todos do time!

Muito importante dizer que mesmo que você entenda sobre desenvolvimento (talvez tenha migrado desta área), nunca imponha uma solução ou diga como eles devem fazer algo. Como já falado anteriormente no tópico do papel do design, as decisões são tomadas pelo time e a forma de construção de um produto, aqui me refiro ao aspecto técnico, deve ficar a encargo do seu time de engenharia que deve possuir total autonomia para definir a melhor tecnologia a ser utilizada, claro que orientado pelo seu head de engenharia ou líder técnico.

O gerente de produto tem um papel muito voltado a passagem das informações do produto, quais os problemas que precisam ser resolvidos, quais as percepções de usuário e estratégias, cabe a ele trazer essa visão holística aos engenheiros, para que eles construam alinhados ao produto e sabendo o que e para atender à qual dor do usuário final estão construindo aquela solução.

Um pouco mais sobre o time de produto

Acredito que tenha conseguido trazer nos tópicos anteriores a importância de todos os papéis e da relação entre eles como time e principalmente do product manager nesse cenário. Agora voltando um pouco lá no início, vimos que a equipe de produto deve ser multidisciplinar, e isso quer dizer que vamos ter pessoas das mais variadas áreas trabalhando juntas e trocando experiências. Existirão experts em cada área e essa estrutura de time lhe permite usar dos conhecimentos de todos os integrantes do time na resolução das necessidades que aparecer, e é essa troca que engrandece a construção de um produto.

Enxergo a multidisciplinaridade dos times como uma grande oportunidade de crescimento para o time, onde todos podem desenvolver tanto as hard skills, como e principalmente as soft skills. E como gosto de dizer sempre, um produto não é construído por uma pessoa, mas por um time, focado e dedicado em seu maior impulsionador: o usuário!

Os ritos dentro de um time ágil

Dentro de um contexto ágil são vários os ritos de alinhamento e definição do que será construído, e considero esses ritos essenciais para o bom andamento de um time e a construção de produtos de sucesso, trazendo-os sempre alinhados à estratégia do negócio. Abaixo vou listar os principais ritos realizado dentro de um squad:

●     Grooming de Produto

Neste rito é o momento onde os itens do backlog são refinados em relação ao negócio. O product owner apresenta as estórias priorizadas para a sprint futura para o time e diante da necessidade ou problema, são discutidas as soluções possíveis. Este rito é onde todas as estórias serão entendidas dentro do aspecto do negócio e necessidade de usuário.

É importante que participe o negócio, o designer e pelo menos um engenheiro. Considero a participação da equipe técnica muito importante para o esclarecimento e pontualmente para definição sobre os aspectos possíveis de construção, norteando as soluções. A equipe de design UI/UX também é muito importante pois traz a discussão para uma visão mais voltada ao usuário e sua experiência com o produto.

●     Grooming Técnico

Neste rito o product owner traz as estórias refinadas no grooming de produto para um refinamento agora em caráter mais técnico. Aqui é o momento para discussão sobre a forma de implementação dessas estórias de uma maneira mais detalhada, trazendo os principais pontos técnicos, até mesmo como uma forma de direcionamento e alinhamento entre o time de engenheiros sobre a melhor forma de construção. Aqui todo o time participa.

Este é um rito que considero um dos mais importantes justamente por já trazer todos os engenheiros para a mesma página das estórias que serão levadas para planning, assim otimizando o tempo da planning e gerando mais insumos para uma estimativa mais assertiva para o planejamento da sprint.

●     Planning

O rito de planning é uma reunião onde o product owner irá apresentar as estórias que estão previstas, de acordo com a priorização do backlog, para entrarem para a próxima sprint ou ciclo de desenvolvimento. Aqui as estórias já passaram previamente pelo refinamento realizado pelo PO e o time nos ritos de grooming.

O momento não é destinado a definição do que vai ser feito ou qual a melhor solução, estas questões já devem estar definidas antes, este rito é para repassar de forma macro pelas estórias (a fim de relembrar o time sobre elas) e realizar a estimativa junto ao time. As estimativas podem ser feitas através de ferramentas online como o Azure DevOps ou utilizando o Poker Planning, por exemplo. Após estas estimativas serão definidos os work itens que entrarão realmente para o próximo ciclo de desenvolvimento de acordo com a capacidade do time disponível.

●     Daily Scrum

Este rito tem como objetivo disseminar conhecimento sobre o que foi feito no dia anterior, identificar impedimentos e priorizar o trabalho a ser realizado no dia seguinte, sendo uma forma de acompanhamento diário do time de produtos.

As dailys normalmente são realizadas no mesmo lugar, na mesma hora do dia, em pé e com duração de no máximo 15 minutos, sendo importante a participação de todos integrantes do time. Existem algumas perguntas nortes que devem ser respondidas:

1. O que você fez ontem?
2. O que você fará hoje?
3. Há algum impedimento no seu caminho?

Aqui é o momento onde o time terá uma visão geral sobre o andamento da sprint e como forma de acompanhamento visual pode ser utilizado algumas ferramentas como o board de tarefas (quadro kanban) e o gráfico de burndown – estas ferramentas podem ser disponibilizadas por frameworks de acompanhamento de projeto como o Azure DevOps. Planos de ação podem ser traçados a partir desse rito, caso se identifique uma situação que precise ser mitigada pelo time.

●     Review

O rito de review é o momento onde o time apresenta as entregas realizadas na sprint finalizada, normalmente conta com a participação de todo o time de produto e stakeholders. Neste momento é onde o negócio (cliente) irá avaliar as entregas do time e validar de acordo com o que havia sido definido inicialmente em relação aos objetivos do Sprint, determinados durante a Planning, mas o importante mesmo é que a equipe tenha alcançado o objetivo geral do Sprint.

Gosto de pontuar que a review não deve tratar apenas das entregas de funcionalidades ou features, é importante que se traga uma visão de forma macro sobre todo o produto e o andamento das questões que o envolvem, é importante usar esta reunião para alinhamento do time ao produto que está sendo desenvolvido.

●     Retrospectiva

O rito de retrospectiva é sempre realizado ao final de cada sprint e deve ser um momento para que o time reflita sobre os  pontos positivos, que devem ser mantidos para os próximos ciclos e os pontos negativos, que devem ser melhorados a partir de planos de ação definidos.

É um rito muito importante pois garante a saúde do time, sendo um momento totalmente livre onde todos têm a oportunidade de falar abertamente sobre os pontos que podem estar incomodando ou mesmo apresentar sugestões de melhorias para o time como um todo.

O que são as metodologias ágeis

As metodologias ágeis surgiram a partir do Manifesto Ágil criado em fevereiro de 2001, por 17 profissionais que se reuniram em Utah, nos EUA para discutir novas formas de abordagem para o desenvolvimento de software que minimizassem os problemas encontrados nos modelos tradicionais de desenvolvimento, como escopo fechado, prazos exorbitantes, entregas atrasadas e pouco valor entregue ao usuário final. O manifesto foi criado com o intuito de trazer transparência, comunicação e pensamento centrado no usuário, sendo composto por doze princípios e quatro valores.

●     Princípios do Manifesto Ágil

1. Nossa maior prioridade é satisfazer o cliente através da entrega contínua e adiantada de software com valor agregado.
2. Mudanças nos requisitos são bem-vindas, mesmo em uma etapa mais tardia do desenvolvimento. Processos ágeis tiram vantagem das mudanças visando vantagem competitiva para o cliente.
3. Trabalhar com ciclos de produção curtos, entregando softwares funcionais simples para testar hipóteses e colher aprendizados.
4. Desenvolvedores e demais profissionais devem trabalhar diariamente em conjunto por todo o projeto.
5. Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e o suporte necessário e confie neles para fazer o trabalho.
6. O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de desenvolvimento é através de conversa face a face.
7. Software funcionando é a medida primária de progresso.
8. Os processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante por tempo indeterminado.
9. Atenção contínua à excelência técnica e bom design aumentam a agilidade.
10. Simplicidade — a arte de maximizar a quantidade de trabalho não realizado — é essencial.
11. As melhores arquiteturas, requisitos e designs emergem de equipes auto-organizáveis.
12. Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e então ajusta seu comportamento de acordo com o que foi definido.

●     Valores do Manifesto Ágil

1. Indivíduos e interações acima de processos e ferramentas
2. Software em funcionamento acima de documentação abrangente
3. Colaboração com o cliente acima de negociação de contratos
4. Responder a mudanças acima de seguir fielmente um plano

Ou seja, mesmo havendo valor nos itens à direita, os itens à esquerda são os mais priorizados.

Abordagem das metodologias ágeis

A partir do manifesto ágil várias metodologias de desenvolvimento foram criadas seguindo esses princípios e valores, abrangendo muito mais que somente projetos na área de tecnologia, mas também em outras áreas do mercado. Uma dessas metodologias que é bastante usada e disseminada nas empresas é o Scrum.

O que é o Scrum?

O Scrum como já mencionei, é uma metodologia ágil que garante entregas dentro do prazo e com qualidade, permitindo ao time uma visibilidade e transparência do que está sendo construído.

No Scrum existem alguns papéis importantes que devem ser mencionados, que são o Product Owner – responsável pela gestão e manutenção do backlog, o Scrum Master – que atua como um facilitador e resolvedor de impedimentos que possam levar ao atraso das entregas, e o time de desenvolvimento – que são os responsáveis pela construção do produto.

O ciclo de desenvolvimento do Scrum

Existe product backlog onde estão ‘estocados’ todos os itens mapeados para construção do produto,  que é mantido sempre atualizado pelo Product Owner; estes itens então passam por um processo de priorização e formam assim o Sprint Backlog. Com o Sprint Backlog formado esses itens entram para o ciclo de desenvolvimento que no Scrum chamamos de Sprints, que duram em média de 2 a 4 semanas. Durante este ciclo são realizadas reuniões diárias (daily) que são executadas durante toda a sprint. Ao final de cada ciclo de sprint se tem um produto ou funcionalidade pronta para ser entregue.

Mas será que para um time ágil funcionar bem é preciso todos esses papéis citados acima? O cenário ideal é que sim, exista as pessoas atuantes em cada um desses papéis, pois a soma de todos eles fazem a engrenagem rodar e as coisas funcionarem corretamente, porém sabemos que em muitas empresas isso não é a realidade e às vezes um time ágil precisa trabalhar de forma reduzida onde alguns dos papéis do Scrum são omitidos.

Mas e nessas situações como fazer? Mesmo nesse cenário descrito anteriormente, essas equipes são capazes sim de realizar suas atividades sem deixar a peteca cair, mas é preciso uma maturidade muito grande de todos os integrantes do time, para que as funções de cada papel sejam executadas, pois o papel deixa de existir (dentro do time) mas as funções ainda precisam ser realizadas, e em um time que tenha uma maturidade e sinergia, essas funções acabam sendo absorvidas por todos, que mesmo com menos pessoas garante que às engrenagem ainda rodem e as entregas sejam realizadas dentro do prazo e com a qualidade esperada pelo negócio.

Times de produtos direcionados

Para que um produto obtenha sucesso é necessário que o time envolvido na construção desse produto também seja um time de sucesso e realize suas funções com excelência e qualidade. Mas para que isso ocorra é necessário que este time esteja totalmente alinhado entre si e principalmente alinhado à estratégia do negócio. Mas como podemos garantir isso?

Uma forma utilizada para o alinhamento dos times é a definição de metas, que funcionam como objetivos que devem ser alcançados pelo time para que a empresa alcance sucesso. Uma metodologia que vem crescendo muito entre as empresas são os OKR – Objetivos e Resultados-Chave.

O que são OKRs?

Os Objetivos e Resultados-Chave, do inglês Objectives and Key Results, são uma metodologia implementada por John Doerr inicialmente no Google, que tem como base a representação e definição de objetivos estratégicos que são acompanhados por resultados chaves. Estes objetivos devem ser claros e transparentes para toda a organização, de forma que todos possam acompanhar o seu andamento e atingimento da meta principal.

Normalmente são definidos os objetivos principais da empresa de uma forma global e repassados aos times que devem traçar seus objetivos individuais de forma que auxiliem a empresa a alcançar este objetivo principal. Funciona como uma espécie de escalonamento onde a conclusão e atingimento de cada resultado chave referente ao objetivo é um passo ao alcance do objetivo principal que gerará valor ao produto e a empresa.

Trazendo esta metodologia para um cenário mais próximo referente a um squad, a definição dos OKRs devem estar alinhadas ao negócio e estratégia de seu cliente principal, como forma de auxiliá-lo a alcançar este objetivo, mas sempre trazendo os marcos dos resultados chaves esperados para o seu produto. Normalmente cada OKR tem uma duração de três meses para alcance e devem ser constantemente revisitados e acompanhados durante o ciclo de vida do produto.

Construção de produtos de sucesso

A construção de um produto está muito mais relacionada ao entendimento inicial da dor do seu usuário e ao trabalho de descoberta do que ele realmente precisa para que essa dor seja sanada. Existe todo um trabalho de descoberta (discovery) em cima desse processo que é iniciado no start do projeto e permanece por todo o ciclo de vida do produto.

Para que esse processo funcione bem é necessário um time dedicado e comprometido com seu papel e que entenda a sua importância de forma individual e como time para o sucesso desse produto a ser construído. Cada integrante tem seu valor representado pelas suas habilidades técnicas e pessoais em um time totalmente multidisciplinar que tem como desafio a gestão de suas habilidades como forma de geração de aprendizado constante a ele próprio e ao time como um todo.

As metodologias que existem e que auxiliam nesse processo de construção funcionam como ferramentas que vão direcionar e calçar o time, mas cabe a eles fazerem o uso correto dos recursos disponíveis para que o produto cresça e se torne referência como forma de garantia de experiência positiva aos usuários finais. A excelência de um produto está diretamente relacionada a forma que ele foi pensado e construído, e esta por sua vez está totalmente relacionada ao time que está por trás disso tudo, no dia a dia e em cada passo realizado.