Convença a todos com seu roteiro

Folha de consulta: as dez principais dicas para obter aceitação da equipe técnica

Martin Suntinger Martin Suntinger

A apresentação de um roteiro pode ser complicada para desenvolvedores e gerentes de produto. Uma das partes trabalhou muito para chegar a uma visão enquanto a outra parte aguarda para ver algo desconhecido que afetará seu trabalho.

Senti essa tensão quando trabalhei como desenvolvedor e me encontrava, com frequência, insatisfeito com os roteiros que o gerenciamento de produtos reunia. Eu não concordava totalmente com as decisões e, com frequência, saia de reuniões de planejamento com o sentimento de "bem, isso não faz sentido para mim, mas se eles pensam assim...", ou, até pior, um "teremos que descobrir nós mesmos e fazer parecer que nos adequamos a esse roteiro".

Você pode argumentar que o problema provavelmente era eu sofrendo de NIH (síndrome não inventada aqui) e você pode estar certo. Como um desenvolvedor, eu tinha uma opinião muito forte sobre o que era o certo a fazer. Mas, agora como gerente de produto, vejo o que causou esta desconexão e quais aprendizados gerais os gerentes de produtos podem obter disso para terem êxito na próxima apresentação de roteiro. Afinal, se a equipe técnica concorda e compreende a visão global, as decisões de implementação e de design cotidiano serão feitas com o contexto certo e você terá o produto que imaginou.

1. Escolha conteúdo e não chavões

Chavões como "análise de big data", "aprendizagem de máquina" ou "uma iniciativa de Internet das Coisas (IoT)" podem soar, para os parceiros de negócios, como pontos de ancoragem de alto nível, que não são itens úteis e acionáveis para as equipes técnicas. A engenharia precisa saber exatamente o que estão criando, como isso se relaciona com os produtos atuais, como deve ser entregue e qual é o público-alvo e qual é a finalidade.

Definir temas de alto nível é ótimo para estruturar o roteiro e o contexto, mas se certifique de não parar por ai e tenha ótimas respostas para o que está por trás de cada item de alto nível. Por exemplo, se você chama um tema de "serviços inteligentes", certifique-se de detalhar isso em epics e iniciativas principais que são necessários para fornecer esse tema.

2. Defina o contexto certo

As equipes técnicas precisam saber por que você está criando algo de acordo com um roteiro. Nenhuma equipe técnica dirá: "Diga-me o que quer e farei para você". Pelo contrário, os engenheiros precisam de evidências que mostrem por que você precisa de um recurso. Deixe os dados falarem, mas conte também uma ótima história do ponto de vista de seus usuários. Use personagens e fale sobre algumas alternativas que você já excluiu e o motivo. Para ajudar toda a equipe entender o roteiro, o motivo importa tanto quanto a necessidade.

3. Considere os compromissos cuidadosamente

Se um recurso não parecer bem pensado ou realista, mas estiver no roteiro, ele deverá ser analisado com cuidado. Você não quer que a equipe técnica tenha a impressão de que devem criar itens só porque você prometeu isso a alguém. Isso pode ser um compromisso com um cliente ou apenas porque "a gerência quer". Então, pense bem antes de fazer compromissos. Mesmo que alguém com um cargo mais alto deseje uma determinada alteração, certifique-se de entender e passar a base racional para a equipe e continue dando suporte.

4. Faça planos realistas

Uma ideia pode ser boa, mas será ainda melhor se todo mundo tiver confiança de que ela poderá ser alcançada. O plano não necessita ser preciso, mas se a primeira coisa que seu gerente de desenvolvimento vir ao olhar para um roteiro for um grande obstáculo – por exemplo, se o roteiro parecer complicado e centralizado em front-end, mas a equipe tem apenas um designer e está enfrentando problemas com tópicos de frontend nos últimos meses – então o gerente terá dificuldades com o roteiro durante toda sua apresentação.

Certifique-se de fazer uma verificação da realidade antecipadamente com a equipe e testar cenários hipotéticos. Você precisa ter respostas, um plano de ação e uma consideração concisa sobre "como isso pode ser feito" antes de pedir o comprometimento de todos. 

Presenting product roadmaps | Atlassian agile coach

5. Pense grande, comece pequeno

Você precisa estar ciente sobre como são o produto e as habilidades da equipe em relação a o que você deseja. É ótimo avançar em novos campos, o que podem exigir novas habilidades na equipe ou o afastamento de uma tecnologia existente, mas não estabeleça apenas sonhos sobre o que deseja obter em um ano. Em vez disso, pense em como obter o que deseja realisticamente. Aquisição de talentos e adoção de novas tecnologias levam tempo, e abandonar os produtos existentes requer compromissos claros e um plano de transição.

6. Crie um caso de negócios

Caso de negócios? Sim. Equipes técnicas se preocupam com casos de negócios. Talvez não na mesma medida que a gerência sênior, mas toda a equipe de desenvolvimento se preocupa com o motivo pelo qual algo é relevante para o negócio, se produz resultados reais e como será mensurado. Explore o conhecimento de negócios de sua equipe técnica. Todo mundo tem grande interesse no sucesso de negócios, e isso pode ser uma grande fonte de feedbacks ou ideias adicionais.

Além disso, clareza total sobre o impacto nos negócios e ver tudo acontecer pode ser um grande motivador. Ter resultados é melhor do que apenas criar e fornecer um recurso.

7. Equilibre a monotonia com a motivação

Os engenheiros querem criar produtos exclusivos e inovadores dos quais possam se orgulhar. Se for algo que já foi feito antes, eles podem ficar desmotivados. Certifique-se de pesquisar para confirmar se sua história é tão inovadora quanto você pensa. Além de desenvolvedores desmotivados, o impacto nos negócios da falta de inovação é ainda pior.

Dito isto, até os roteiros serão sempre um ato de equilíbrio entre novos recursos incríveis e outros, tecnicamente, não muito interessantes que devem ser feitos. Tente certificar-se de que até mesmo o monótono seja motivador no seu roteiro. 

8. Pense além de MVP e v1

Criar um produto mínimo viável e, em seguida, uma versão 1 é uma coisa, mas também há tudo o que acontece após a liberação: operações, manutenção, solicitação de recursos pelos usuários, melhorias contínuas e novas versões de outros produtos e/ou plataformas que são integrados. Pensar rapidamente nos desafios e obstáculos que podem surgir após a liberação mostrará esses pontos sem muito esforço, e os engenheiros serão gratos por você não ter ignorado estas realidades. Estimativas aproximadas sugerem que o esforço inicial da criação de um novo recurso é muitas vezes apenas de um terço à metade do esforço total gasto em relação a todo o ciclo de vida do recurso. Ou seja: a pós-liberação é mais custosa que a criação inicial e algumas "coisas pequenas e rápidas" tornam-se muito caras a longo prazo.

9. Lide com os obstáculos

Estimativas são algo bom de se fazer. Elas dão orientação e são criadas de acordo com o melhor do conhecimento do gerente de produtos de acordo com as circunstâncias. No entanto, muitas suposições feitas de acordo com estimativas podem se mostrar incorretas após a implementação ou a melhoria de um design. Certifique-se de preparar e apresentar o roteiro para que ele seja flexível às mudanças.

10. Seja aberto e honesto

Um roteiro existe para fornecer orientação. Não é um plano detalhado para execução e todos em uma equipe de software sabem disso. Não há necessidade de vendê-lo como algo diferente do que é. Então, se você ainda não tem todos os detalhes sobre um tema, seja honesto sobre isso. Compartilhe o que tem, qual é a intenção, quais são as questões em aberto e os riscos mais altos que ainda precisam ser abordados. Destaque áreas que requerem testes e mais pesquisa para entender o cenário. Lembre-se de executar o teste de acordo com o planejamento.

O resultado final?

Sua equipe merece um roteiro que claramente mostre todo o cenário, mas não negligencie as realidades. Sua equipe também merece um roteiro motivador, emocionante e que tenha detalhes suficientes para que toda a equipe de software saiba o que fazer nos próximos 1-2 sprints com um sentimento de confiança de que obterão grandes resultados com impacto material para o negócio.

Up Next
Requisitos