Autonomia vs. Missão

No meu último artigo, escrevi sobre os compromissos entre os diferentes objetivos da autonomia e da determinação externa nas equipas. Recebi algumas mensagens a dizer que este é um grande tema nas empresas e algumas pessoas queriam saber mais sobre o assunto – mas mais numa perspetiva de produto e design do que de desenvolvimento. O tema é muito diversificado e por isso achei que valia a pena aprofundá-lo.

Aqui estão algumas questões que quero abordar:

• E se uma equipa vir uma oportunidade ainda melhor e decidir concentrar-se num tipo de cliente diferente?
• E se uma equipa não quiser executar o trabalho que deveria apoiar uma grande iniciativa empresarial (por exemplo, internacionalização do produto)?
• E se uma equipa estiver convencida de que precisa de mudar o rumo para aproveitar as oportunidades no mercado móvel, mesmo sendo responsável apenas por uma parte do todo?
• E se uma equipa estiver convencida de que precisa de mudar para um design de experiência do utilizador diferente, mesmo que isso a diferencie das outras equipas?

Em cada um destes casos, a equipa e a gestão provavelmente têm perspetivas muito diferentes. Muitas equipas afirmam que – se realmente puderem trabalhar com autonomia – podem tomar essas decisões.

O problema

Em equipas e organizações saudáveis, normalmente chega-se a um compromisso entre estas duas visões, dando à liderança o controlo sobre dois pontos importantes no processo de decisão. O primeiro é a visão geral do produto e o segundo são os objetivos empresariais específicos que são definidos para cada equipa.

No entanto, podem surgir problemas quando a gestão não formula estes dois pontos importantes com clareza suficiente, pois então surge uma zona cinzenta e já não é claro o que a equipa pode decidir por si própria e o que não pode.

A visão do produto descreve o panorama geral dos clientes-alvo e os serviços que se quer oferecer a cada tipo de cliente. Esta visão do produto deve apoiar a estratégia empresarial. Se tiver, por exemplo, uma estratégia empresarial baseada num modelo de vendas low-touch (pouco contacto pessoal com o cliente), isso promove um tipo muito específico de visão do produto. Se uma equipa quiser desenvolver um produto que se desvie da visão e deste modelo, será bastante difícil comercializar o produto.

Os objetivos empresariais específicos são apresentados às equipas sob a forma de KPI (Key Performance Indicators – indicadores-chave de desempenho) priorizados – também chamados Product Scorecards – ou sob a forma de OKR (Objectives and Key Results), que também resultam em vários KPI. Se o objetivo empresarial for, por exemplo, reduzir significativamente a taxa de abandono dos clientes, essa é a missão da equipa.

As equipas recebem a visão do produto e os KPI da liderança, mas não lhes é dito como os devem realizar. É aqui que a equipa pode trabalhar de forma autónoma e flexível. Gosto de descrever equipas de produto fortes como comunidades de trabalho para resolver problemas difíceis. Reduzir a taxa de abandono pode definitivamente ser um grande desafio e provavelmente há inúmeras formas de alcançar este objetivo. O mesmo se aplica ao aumento do "Customer Lifetime Value" (valor que um cliente tem para a empresa durante toda a sua relação comercial) ou à redução dos custos de aquisição de clientes, etc.

Quando a visão do produto e os KPI são definidos, a diferença entre equipas autónomas e todas as outras é se existe ou não um roadmap para a empresa. Se a gestão ou os stakeholders apresentarem à equipa uma lista de funcionalidades obrigatórias, com as quais os clientes e stakeholders já contam firmemente, a equipa tem pouca margem para encontrar a melhor solução para as questões empresariais subjacentes (para não falar de temas realmente fundamentais).

E é exatamente por isso que estou tão contente com o ressurgimento dos OKR. Quando são aplicados corretamente, ajudam a reorientar esta situação do output (funcionalidades nos roadmaps) para o outcome (resultados de negócio).

2 Casos especiais

Há dois casos especiais que vale a pena mencionar porque causam stress muito frequentemente nas empresas.

O primeiro caso especial tem a ver com design. Não há dúvida de que é um grande ganho para uma equipa e para os clientes ter um designer em cada equipa (que assume funcionalidades orientadas para o cliente). Estes designers criam uma ligação muito próxima com o seu produto e os programadores e são membros de equipa de primeira classe. Além disso, não tentam trabalhar segundo um modelo que se assemelhe a uma agência de design interna. Mas como garantir que os designers querem melhorar a experiência para todos os utilizadores e não apenas para os objetivos da sua própria equipa? Aos utilizadores não interessa a sua estrutura de equipas. Mas como promover a autonomia e ao mesmo tempo garantir uniformidade?

Existem vários métodos para isso – desde nomear um "Design Manager" (ou Senior Designer) que revê e aprova o trabalho de todos os designers, até à maior automatização possível com "Pattern Libraries", "Style Guides" e "Stylesheets".

No que diz respeito à autonomia e rapidez, prefiro a automatização, porque assim a equipa consegue fazer o design (Interaction e Visual) de forma relativamente simples e boa. Claro que ocasionalmente também há "Design Debt", ou seja, descobrimos que o design precisa de ser revisto, e isso faz-se assim que o problema é identificado. Gosto desta abordagem porque o Design Manager continua a reunir um grupo de bons designers, mas já não precisa de estar presente em cada revisão de cada pequena coisa (isso atrasa tudo e mina a autonomia).

O segundo caso especial são as iniciativas empresariais. Estes são os projetos que envolvem sempre várias equipas. Um caso bastante comum é a internacionalização. Outro é o chamado "Responsive Design". Outro ainda é levar o mercado móvel a sério. Acho que percebe o que quero dizer. Na melhor das hipóteses, estas iniciativas encaixam bem nos KPI priorizados de cada equipa e muitas vezes há um objetivo OKR concreto para esta iniciativa. No entanto, devemos estar conscientes de que uma iniciativa importante nem sempre é um ganho claro para cada equipa individual. Ainda assim, cada equipa tem de cumprir a sua tarefa, porque senão a iniciativa falha. Costumo dizer às equipas que às vezes simplesmente temos de cumprir a nossa tarefa como parte do todo. O bom é que estas iniciativas são realmente fantásticas para o produto e para o cliente, por isso pelo menos podemos ficar satisfeitos com isso.

Conclusão sobre autonomia vs. missão

Portanto, se as suas equipas não sentem que têm autonomia suficiente, então precisa de dar a cada equipa uma visão de produto clara e objetivos de negócio inequívocos e priorizados. O contexto contido nisso é a missão da equipa. Garanta que as equipas compreendem esta missão e dê-lhes a maior margem de manobra possível para poderem cumprir a sua missão.

Este texto é do Blog de Marty Cagan e foi traduzido por nós para alemão.

Criar Visão do Produto

=> Product Vision Canvas - O guia para a visão do produto.

Scrum Master Training

=> Torna-te Scrum Master certificado na Agile Academy!

Utilizar métricas ágeis corretamente

=> Quais indicadores você deve conhecer como Scrum Master?