BT

Disseminando conhecimento e inovação em desenvolvimento de software corporativo.

Contribuir

Tópicos

Escolha a região

Início Notícias Construindo o roadmap para o Portfolio no Jira

Construindo o roadmap para o Portfolio no Jira

Favoritos

Quando o backlog do seu produto é uma lista priorizada de problemas ao invés de funcionalidades, fica mais fácil responder às mudanças; não é preciso se comprometer com antecedência para entregar funcionalidades e pode-se usar novas tecnologias quando estiverem disponíveis. Visualizar seu roadmap e regularmente incluir novas informações para reavaliar seu plano ajuda a mantê-lo Ágil.

Jonno Katahanas, gerente de produto da Atlassian, explorou como a equipe por trás da funcionalidade Portfolio para o Jira montou seu roadmap no Atlassian Summit 2018. O InfoQ está cobrindo este evento com resumos e artigos de perguntas e respostas.

O InfoQ entrevistou Katahanas para saber mais sobre a construção de roadmaps de curto e longo prazo, manter os roteiros Ágeis para responder às mudanças e dicas para a gestão de roadmaps de produtos.

InfoQ: Quem foram os envolvidos no roadmap do Portfolio para o Jira?

Jonno Katahanas: Muitas pessoas! Quando estamos definindo o plano de alto nível dos produtos para os próximos três anos, envolvemos um número bastante grande de pessoas. Este não é um roadmap típico no qual listamos várias coisas para trabalhar, é mais uma articulação clara do que o Portfolio pretende ser e como seria nossa visão de sucesso.

Internamente, trabalhamos próximos ao designer, ao gerente de engenharia e a alguém de marketing do produto para elaborar nosso plano inicial de três anos. Em grande parte, esse plano se baseia em coisas que já conhecemos e em outras pesquisas suplementares que fazemos como uma equipe central. Externamente, passamos muito tempo conversando com os clientes para entender suas necessidades e pontos problemáticos. Também pesquisamos em outros canais para fortalecer a compreensão sobre nossos clientes. Esses canais incluem feedbacks vindos da equipe de suporte e de pesquisas no aplicativo.

Quando olhamos o plano de curto prazo para o ano à nossa frente, de uma perspectiva externa, voltamos a ponderar muito as interações e os comentários que recebemos dos clientes. De uma perspectiva interna, a equipe principal inclui a gestão de produto, o designer, o gerente de engenharia e alguém do marketing.

No fim do dia, geralmente é o gerente de produto que dá a última palavra sobre o quê permanece e o que fica no plano. Mas essa decisão é tomada com muita participação e discussão dos outros membros presentes. Quando necessário, também trazemos pessoas de outras equipes que são relevantes para qualquer item específico no plano. Se houver algo que achamos ser dependente de outra equipe, tentamos envolvê-los o mais cedo possível. Isso nos dá mais tempo para trabalhar com quaisquer possíveis bloqueadores.

InfoQ: Como é garantido que o roteiro seja Ágil o suficiente para responder as mudanças?

Katahanas: Responderei a essa pergunta focando em como abordamos a criação do plano de curto prazo (de um ano). Enquanto construímos o plano, queremos ter uma lista de problemas a serem resolvidos durante aquele ano, e não as funcionalidades a serem construídas. Isso é contrário a um padrão comum no qual as equipes de produto criam um plano que é uma lista de funcionalidades que irão entregar. Não é anormal falar com uma equipe informa qual funcionalidade será entregue em nove meses.

A razão pela qual concentramos em ter um plano que é uma lista priorizada de problemas, e não de funcionalidades, é dupla. Em primeiro lugar, gostemos ou não, assim que adicionamos uma funcionalidade a um plano com uma data ao lado dela, os stakeholders tomam isso como compromisso - um compromisso de que a funcionalidade será entregue naquele momento. O desafio disso é que não sabemos com certeza se o que nossos clientes querem ou precisam agora será o mesmo em 6, 9 ou 12 meses.

Como podemos saber a funcionalidade exata, que melhor atenderá às suas necessidades, quando chegarmos a realmente trabalhar no problema? Muitas equipes afirmam que são ágeis e estão constantemente interagindo para responder às necessidades dos clientes. Mas, como isso pode realmente acontecer se já se comprometeram a entregar uma funcionalidade há muitos meses atrás? Esse compromisso inconsciente é todo impulsionado pelo simples ato de colocar uma funcionalidade e uma data em um plano, com bastante antecedência.

A segunda razão é baseada na taxa de mudança tecnológica. A tecnologia está mudando tão rapidamente que aquilo que não é possível agora, poderia muito facilmente ser possível em menos de um ano. Isso significa que, quando chegarmos a resolver um problema em nosso plano, poderemos entregar uma funcionalidade que não era possível quando planejamos inicialmente. Por exemplo, estamos no processo de melhorar a usabilidade de uma tabela que o usuário utiliza em nosso produto para gerenciar grandes conjuntos de dados.

Recentemente, também fizemos melhorias internas em nossa pilha de tecnologia. Algumas das soluções que procuramos entregar agora não eram tão viáveis no ano passado quando criamos nosso plano de um ano.

InfoQ: E quais são as lições aprendidas?

Katahanas: Provavelmente, meu maior aprendizado foi que o processo de criar um roadmap não é puramente o ato de escrever uma lista de coisas para fazer com algumas datas anexadas. Agora é estranho fazer isso, mas foi genuinamente a impressão que tive antes de me tornar um gerente de produto. Há tantas atividades relacionadas a planos que acontecem antes mesmo de começarmos a elaborar o que a maioria pensaria como um planejamento típico: uma lista ordenada de quando vamos trabalhar nas coisas e por quanto tempo achamos que cada item de trabalho será necessário.

Muitos usam o processo de criar um roadmap para simplesmente "dar um sentido" ao ato de escrever uma lista de trabalho a ser feito, mas não consideram efetivamente todas as atividades básicas que vêm antes que a lista física de trabalho priorizado comece a ser criada. Essas atividades básicas incluem coisas como deixar claro os planos de longo prazo do seu produto.

É crucial que as equipes tenham uma visão de 3 a 5 anos e definam o que o produto deseja ser, como o produto vence no mercado e como é sua visão de sucesso. Isso ajuda a fornecer foco quando a equipe de produto está decidindo o que adicionar ao seu plano de curto prazo para o próximo ano.

InfoQ: Quais são as dicas para as equipes quando estão trabalhando em seu roadmap de produto?

Katahanas: Tenho duas dicas importantes que realmente ajudaram nosso processo de criação do roadmap.

A primeira é que as equipes de produto tenham um mecanismo para criar um entendimento compartilhado da direção de longo prazo de seu produto. Todas as equipes de produto da Atlassian adotaram recentemente uma estrutura chamada "VSO" para ajudar com isso. "VSO" [em inglês] significa visão, estratégia e objetivos. É uma única página que usamos para definir claramente para onde nosso produto está indo nos próximos três anos. Uma vez criada, compartilhamos essa página com qualquer pessoa dentro e fora da equipe de produto para colocar todos na mesma página. Tem sido muito útil ao nos fornecer orientação e segurança ao construir nosso plano de curto prazo de um ano e decidir em que trabalhar.

A segunda dica é super importante. Certifique-se de que está usando regularmente novas informações, usando para reavaliar seu plano. As equipes precisam reavaliar constantemente se seu plano é realista. Isso ocorre porque há níveis variados de informações ao longo do tempo que precisam ser considerados.

Pessoas saem, outras se juntam a equipe, e a equipe percebe que um problema é super complexo para resolver e levará algum tempo para entregar algo de valor; a lista continua. À medida que novas informações surgirem, será preciso levar isso ao seu plano e conversar com sua equipe sobre possíveis decisões de negociação que deverão ser tomadas.

Essas decisões geralmente se resumem a compensações baseadas no escopo, nas pessoas alocadas e no tempo disponível para concluir o trabalho. Por exemplo, se alguém sair, haverá menos pessoas para fazer o trabalho. Então será preciso decidir se passará mais tempo fazendo a mesma quantidade de trabalho com menos pessoas ou se reduzirá o escopo. Não caia na armadilha de prometer o mundo e de entregar por não ter gasto algum tempo para considerar novas informações.

Avalie esse artigo

Relevância
Estilo/Redação

Conteúdo educacional

BT