Muito mais do que ser a ponte entre cliente e o time de desenvolvimento, o papel de Product Owner (PO) aqui na Just Digital vai além, sempre pensando nos preceitos da Cultura Ágil. Batemos um papo com 3 de nossos P.O.’s: Luciano Oliveira, Joel Gouveia e Jonas Barreto. Confira abaixo o melhor desta conversa, do dia a dia com o time até a parceria com o Scrum Master (SM).
1. Qual o papel do P.O. na Just Digital?
Luciano Oliveira – Minha principal função é alinhar as necessidades do cliente com o time de desenvolvimento. Mantendo o cliente e time na visão do projeto planejado e respeitando o roadmap.
Joel Gouveia – Dentro do time SCRUM, o P.O. é responsável pelo Produto, disseminando a visão e priorizando os itens com maior valor para a equipe de desenvolvimento e mantendo alinhamento constante com o cliente.
Jonas Barreto – Aqui na Just Digital, o P.O. deve conhecer bem sobre as tecnologias que usamos. Esse conhecimento não precisa ser tão profundo, pois nós P.O.’s devemos focar no valor de negócio. No início de um projeto, o P.O. deve criar a visão do produto juntamente com o cliente através de várias reuniões e dinâmicas. Chegar num acordo do que será o MVP para depois entregar funcionalidades de forma incremental, separando em releases. Depois, o refinamento e ordenação do backlog de acordo com o que está combinado para cada release, tentando ter o quanto antes o máximo possível de histórias detalhadas. Na fase de desenvolvimento, o P.O. deve se mostrar disponível para o Scrum Team para sanar dúvidas e levantar pré-requisitos técnicos de forma bem antecipada e alinhar com o cliente. Assim evitam-se impedimentos por conta de pré-requisitos não atendidos.
2. Qual foi a sua trajetória profissional para se tornar um P.O. de qualidade?
Luciano – Comecei como analista de suporte técnico, quando tive que lidar com pessoas. Antes disso, eu era muito tímido, tinha vergonha até de atender telefone. Depois fui trabalhar com sistemas e não gostei da vida de desenvolvedor, pois ficava o dia inteiro sem falar com outros. Pesquisei e conheci a área de negócios, especificamente Análise de Negócios, e comecei fazendo cursos simples, me especializando na área. Trabalhei muito com processos empresariais e fui trabalhar numa empresa que estava implantando o Ágil. Foi onde fiz o curso de P.O. e me dediquei ao Método Ágil.
Joel – Acredito que minha experiência generalista (Designer > Desenvolvedor > Scrum Master > P.O.) possa somar neste papel, balanceando a expectativa do cliente com as necessidades técnicas do projeto, entendendo quando algo é complexo e antecipando as necessidades que os desenvolvedores terão. Agora é reorganizar os favoritos e a lista de leitura para ter uma participação efetiva no papel.
Jonas – Algumas habilidades que fui ganhando a cada empresa que trabalhei, ajudaram a garantir alguns pré-requisitos para ser P.O. Dei aulas de informática e web design por cerca de 5 anos, estagiei numa software factory como tester e analista de testes de software. Depois tornei-me analista desenvolvedor web, porque programar me dava mais realização do que elaborar roteiro de testes. Esses 3 cargos me deram uma boa base para ser P.O., mas no ambiente da Just Digital foi onde pude experimentar o Ágil, seja com Scrum ou métodos híbridos que dão agilidade ao desenvolvimento. Ao ver de perto o trabalho dos P.O.’s da Just Digital tive certeza que essa era uma trilha que eu poderia seguir, obtendo ainda realização profissional. É notável que ainda tenho muito pra ver e aprender, pois essa função exige muitas outras habilidades que ainda tenho por desenvolver, conhecimento a obter e cases de sucesso e insucesso a observar.
3. Qual é o melhor caminho: alguém externo que foi contratado para ser P.O. ou alguém interno que foi “promovido” à P.O.?
Luciano – Indiferente. Contratado externo traz hábitos e processos que talvez a empresa não tenha, por outro lado pode ter problema de entrosamento com o time e com a empresa, visto que a Just Digital é muito diferente das empresas do mercado, e isso pode trazer risco de adaptação. O profissional que foi promovido já não corre o risco de adaptação, mas não conhece o mundo e as práticas externas. Também tem o problema da falta de prática com a nova função, podendo levar um tempo para aprender os macetes e técnicas.
Joel – Ambos tem vantagens e desvantagens. Um P.O. externo, como qualquer outra pessoa que entre em uma empresa, pode não se adequar à cultura ou maturidade na qual ela se encontra. Por outro lado, pode trazer novos valores, metodologias e processos que, se disseminados, auxiliam no crescimento do produto e da empresa como um todo. Alguém interno que adquire esse papel, já conhece a cultura da empresa, já é conhecido por todos de modo que a integração acontece naturalmente. A desvantagem é o risco de se cair em vícios da própria organização caso não haja proatividade em buscar a melhora contínua.
Jonas – Vejo pontos positivos nos dois caminhos. E um pode ser mais adequado que outro dependendo do momento da empresa. O primeiro caso pode ser de grande vantagem quando existe a necessidade de ter um P.O. com experiência no menor tempo possível. Já no segundo caso, ajuda quando a empresa esteja em busca de um novo P.O. e ao mesmo tempo tenha algum desenvolvedor que deseja tornar-se P.O. Mas é claro que essas duas condições apenas não podem determinar a mudança de papel. Outros critérios relacionados ao perfil devem ser levados em consideração, como habilidade de negociação, saber analisar requisitos e ter uma boa comunicação no geral. Se a pessoa que almeja tornar-se P.O. não tiver essas habilidades num nível razoável e ainda não gostar muito de falar com o cliente, sejam por conferência e principalmente reuniões, dificilmente terá êxito na função. Gosto muito do segundo cenário, porque a empresa mostra sua capacidade de formar profissionais qualificados. É justamente esse o meu caso aqui na Just Digital.
4. Um P.O. se divide entre as necessidades/expectativas do cliente e a realização disto pelo time de desenvolvedores. Como você trabalha entre estes dois polos?
Luciano – O importante é a transparência com o cliente e criar uma parceria com ele. Sempre deixar o backlog priorizado com o cliente e estar do lado dele para guiá-lo a atender as necessidades da visão do projeto e respeitando o roadmap traçado com ele. Também é importante deixar claro para o time os prazos e a importância do projeto.
Joel – O segredo está na priorização do que será desenvolvido. Para o cliente, o que é mais importante deve ser feito antes e para os desenvolvedores a importância do que estão fazendo deve ser clara. Se ambas as partes entendem que o valor daquela priorização está certa, o fluxo tende a ser melhor.
Jonas – Nesse ponto eu atuo como interface entre o negócio e o desenvolvimento. E a mesma linguagem não pode ser empregada para os dois lados. Meu background técnico me ajuda muito ao lidar com os desenvolvedores. Na verdade, por vezes tento me policiar para não interferir nas decisões técnicas deles. Por outro lado, tenho que aprender a falar sobre as funcionalidades num nível mais alto, sem tantas minúcias técnicas.
5. O papel mais difícil do P.O. é dizer “Não” ao cliente para que a fila de tarefas não sobrecarregue o time de desenvolvedores. Como você age em situações em que é preciso dizer “Não” ao cliente?
Luciano – Realmente o “Não” para o cliente é o mais complicado para um P.O. Primeiro, quando eu vejo que ele quer algo que não agrega valor ao negócio dele, tento entender o porquê daquilo e deixar ele entender que aquilo não é necessário. Se isso não dá certo, até crio a demanda dele, mas deixo no backlog, bem embaixo das priorizações que realmente valem a pena. Geralmente, se aquilo não é importante, o cliente esquece e aquilo morre.
Joel – Mais importante do que dizer “Não”, é demonstrar que talvez aquela ideia não resolva o problema do cliente e que há outras coisas prioritárias. Deve-se evitar que o cliente crie sua lista de desejos sem reconhecer qual problema os itens resolverão. Por isso, a “Visão” do produto deve ser clara para direcionar escolhas e um constante alinhamento com o cliente para entender suas reais necessidades.
Jonas – Simplesmente negar algo para o cliente não é fácil e também não deve ser feito. Muitos clientes se apegam mais a requisitos e escopo em vez de valor. Isso pode fazer com que o produto acrescente números naquela estatística tão conhecida de bilhões gastos anualmente com funcionalidades que não são usadas. Diante dessa realidade é importante explicar o porquê. E se ainda o cliente bater o pé a respeito de uma funcionalidade que não acrescenta valor, anoto-a, deixo-a no backlog lá no finalzinho. Ele terá um tempo pra repensar sobre esse item. E conseguirei ter mais formas de convence-lo de que ele não precisa dela. Sinceramente, ainda tenho que praticar melhor as técnicas de dizer “não”. Isso está bem ligado à habilidade de negociação.
6. Quais os critérios para definir as histórias que trarão mais valor ao cliente e que, portanto, vão entrar na frente da fila de tarefas que os desenvolvedores irão realizar primeiro?
Luciano – Meus critérios são:
- Atende DOR do time;
- Tem valor de negócio;
- Está na meta para release;
- As histórias não podem ter dependência entre si;
- O conjunto de histórias vai trazer algo entregável no final do sprint.
Joel – Deve existir um alinhamento sobre o que pode ser entregue de forma utilizável sobre o que será percebido a longo prazo. Entendendo a “Visão” do produto e o significado de “Valor” e que estes conceitos estejam disseminados por toda a equipe a priorização ocorrerá de modo mais natural.
Jonas – Por mais que o valor seja subjetivo, ao criar a visão do produto de forma consistente, o valor torna-se mais concreto e palpável. Se o P.O. e o cliente estiverem bem alinhados quanto aos objetivos do produto isso ocorre quase que naturalmente nas reuniões de refinamento de backlog com o cliente. Para a priorização das histórias, elas devem estar de acordo com o conjunto de funcionalidades esperado para cada release. Essa é a primeira fase de priorização. Dentro dos sprints, temos as histórias eleitas de acordo com o critério maior que é entregar valor o mais cedo possível. Por exemplo, temos 15 histórias para o próximo sprint e 8 delas são essenciais para sua meta. Sim, o sprint deve ter uma meta de negócio. Essas 8 ficarão no topo do backlog do sprint porque se algo não der muito certo e caso o time não consiga entregar tudo, pelo menos a meta não foi comprometida.
7. Como equilibrar tarefas de curto prazo (apagar incêndios) com tarefas de longo prazo que irão melhor beneficiar os usuários?
Luciano – Tentamos não fazer faíscas para não gerar incêndios, mas quando alguém joga uma bituca de cigarro na mata tentamos resolver logo o problema. Eu tento mapear qual o problema e trazê-lo o mais mastigado possível para o time. Se for algo que pode esperar, encaixamos na próxima sprint, se não, negociamos com o time para priorizar o problema e depois continuar a sprint como planejada, mas já sabendo que ela não será completa.
Joel – Se o “apagar incêndios” se refere à quebra de valor já entregue em um produto em produção, este deve ser priorizado. Se isso for constante e contaminar o desenvolvimento, deve-se notar que as “tarefas de longo prazo” não estão sendo realizadas da melhor forma possível e ações de melhorias precisam ser tomadas, como grupo de estudos, refação ou até trocar membros da equipe.
Jonas – Elas podem coexistir no mesmo sprint. Sendo que o “incêndio” estará priorizado no topo do backlog e dependendo do workflow adotado, pode ir para deploy o quanto antes.
8. Como funciona a parceria com o Scrum Master do time?
Luciano – Tentamos sempre em primeiro lugar fazer a evolução do time e cumprir as metas e prazos. Diferente do que se vê em outras empresas que usam SCRUM, aqui na Just Digital, não existe confronto entre os Desenvolvedores, o Agile Coach e o Product Owner. Sempre existem conversas de alinhamento para melhorar o trabalhos de todos e evoluir o produto da melhor forma possível.
Joel – Aqui na Just Digital o Scrum Master funciona como um Agile Coach que preza que os valores do Ágil não sejam quebrados por qualquer motivo que seja, independentemente da pressão e urgência que ocorra. É o papel de quem busca manter o processo funcionando.
Jonas – O P.O. e o S.M. devem ter um trabalho entrosado, pois o S.M. é um agente de mudança cultural e evolução técnica do Scrum Team. Todas as ações de inspeção e adaptação provenientes do S.M. fazem o time evoluir em práticas ágeis de desenvolvimento, e ainda proporcionam maior sinergia e entrosamento. A comunicação próxima e constante é a maior ferramenta para essa parceria ser bem sucedida. Não será uma vez ou duas que o P.O. encontrará impedimentos em histórias dentro do sprint ativo, e essa comunicação bem afinada entre os dois papéis ajuda a fazer o trabalho fluir mais rápido e a resolver impedimentos sem comprometer a meta do sprint.
