Os projetos mais bem sucedidos são aqueles que atendem ou superam as expectativas de seus stakeholders, além claro de resolver as dores reais de seus usuários. Porém a adesão dos principais interessados é parte importante nesse processo, visto que a forma que eles entendem as suas ideias vão fazer com que eles sigam em frente ou barrem o sucesso desse possível produto. Por isso precisamos falar sobre o buy-in com dados.
Conseguir a adesão dos stakeholders é uma arte mágica por si só, pois existem várias formas de conseguir isso. Aqui neste artigo vou trazer alguns exemplos, principalmente de como usar dados a seu favor nesse momento – ainda mais que esse desafio aumentou muito no contexto do trabalho remoto.
É de suma importância identificar todas as partes interessadas no projeto nesse momento para conseguir gerenciar suas expectativas com sucesso ao longo dessa construção, pois obter o buy-in para suas ideias é uma tarefa difícil. No entanto, é algo que você precisará conquistar em todos os níveis da empresa – independentemente de ser um gerente, um colaborador individual ou até mesmo o CEO da organização.
Quanto maior a empresa na qual você trabalha, mais complexo fica esse trabalho. Quanto mais projetos você tem sob sua responsabilidade, mais importante é obter essa adesão.
A boa notícia é que existem maneiras de conseguir executar esse trabalho para conseguir obter a adesão de suas ideias, alinhar partes interessadas e se tornar um comunicador melhor, principalmente utilizando Product Analytics.
Vamos entender melhor? Ao longo do texto, vamos entender melhor os seguintes tópicos:
- Importância de obter o buy-in dos stakeholders
- Mapeando as necessidades e definindo a hierarquia do stakeholders
- Definindo e entendendo a hierarquia do stakeholders
- Atendendo às necessidades e criando consenso das partes
- Apresentando a ideia
- Técnicas para validar a ideia
- Expondo os dados coletados
- Criando o modelo de negócio
- Como obter buy-in com dados para reduzir as dívidas técnicas
- Minha experiência nesse contexto
- Avaliando o impacto de um problema técnico
- Comunicando o impacto com clareza
Vem comigo!
Importância de obter o buy-in dos stakeholders
Porque obter o buy-in dos stakeholders é uma atividade complexa e difícil dependendo do contexto?
Simples, você está pedindo às pessoas que coloquem fé em você de várias maneiras, pedindo que elas assumam um risco cego com a promessa de uma recompensa no futuro. Esse pedido é para que eles tomem uma decisão sob as condições desse risco, considerando que podem acontecer coisas significativas durante o processo de andamento das ideias propostas.
Quando você está lidando com gerentes e liderança executiva, o quanto eles “compram” (ou seja, o nível de apoio que eles dão a você) determina praticamente todos os aspectos de sua vida como Product Manager diariamente a partir desse ponto. Quanto dinheiro eles dão a você, nível de apoio de outros departamentos que você tem, quão bravos eles ficarão se você cometer um erro ou passo em falso – tudo é ditado pelo quanto eles “compram” sua ideia em troca do que você promete a eles sobre o futuro.
Embora a aposta inicial da liderança sênior seja importante, você precisa essencialmente mantê-los engajados continuamente. Isso requer uma compreensão mais profunda dos líderes com quem você está trabalhando e do tipo de benefícios que eles exigem para considerar que o risco inicial vale a pena. Vale se questionar, por exemplo:
- O que você está propondo é bom para o cliente final?
- É bom para um gerente?
- É bom para a liderança sênior?
- Beneficia quais setores da empresa?
- Se encaixa nos planos de longo prazo da empresa?
- Quais resultados possíveis estão sendo esperados de início?
- Qual é a meta determinante a ser alcançada?
Ao projetar seu pitch para responder o maior número possível dessas perguntas, é muito provável que você obtenha o buy-in inicial de que precisa.
Mas lembre-se: se há uma coisa que a alta administração gosta é de resultados, números, benefícios, esforço para ter isso num curto prazo, etc… Ou seja, informações mais aprofundadas. Elaborar seu pitch nessa direção vai ajudar bastante a desbloquear os resultados que você procura em primeiro lugar.
Lançar uma ideia requer mais do que apenas fazer com que todos em uma sala concordem que vale a pena. É um ato de equilíbrio de persuadir seus stakeholders de que suas necessidades de negócios serão atendidas, ao mesmo tempo em que defende as necessidades de alguém que não está na sala: o usuário.
Mapeando as necessidades e a hierarquia do stakeholders
Como mencionei anteriormente, é de suma importância identificar todas as partes interessadas no projeto antecipadamente, para poder gerenciar suas expectativas com sucesso ao longo do projeto.
Uma atividade que acho essencial nesse momento é criar um mapa de stakeholders, dessa forma você vai ter mais controle e visibilidade das pessoas que você precisa manter informadas, com quem você tem que trabalhar em conjunto, e para quem você compartilha decisões.
A forma que eu mais gosto de fazer esse mapeamento é usando ferramentas como Miro, Mural, Jamboard e MindMup. Existem várias ferramentas para te apoiar, sempre escolha a que você se sente mais confortável e que atenda melhor suas necessidades do momento.
Outro framework muito bom para entender como você pode organizar essas comunicações é a própria Matriz RACI ou a planilha do Bruno Coutinho.
Entendendo e gerenciando os tipos de stakeholders envolvidos
Pode ser que os exemplos que eu trago aqui não façam sentido para seu momento atual, ou sejam um pouco diferentes em algumas empresas. Mas ter conhecimento pode te ajudar a realmente entender como sua organização pode estar estruturada e quem pode te apoiar nessa fase.
- Alta administração – Os planos do projeto e os principais marcos geralmente devem ser aprovados pela alta administração durante as fases de planejamento e desenho do projeto. Eles devem ser mantidos sempre bem informados sobre o status e sobre os riscos e impactos potenciais. Seja sempre bem objetivo com essas informações, o pessoal da alta administração é bem ocupado e precisa saber das coisas direto ao ponto.
- Membros da equipe do projeto – Sempre que possível envolva os membros da equipe no planejamento do produto, na co-criação, mas também dê direção e apoio.
- Gerente direto – Quando não tiver certeza sobre as direções, peça esclarecimentos e comunique-se com frequência. Faça reuniões semanais para manter o alinhamento e garantir que tudo está sendo esclarecido.
- Pares – Peça explicitamente apoio total para a construção da ideia do produto. Organizar reuniões de revisão frequentes, lembre-se que você não trabalha sozinho, trazer todas as pessoas para perto fará ter mais chances com o sucesso no final.
- Parceiros estratégicos – Busque parceiros que possam apoiar com a cultura e os negócios das organizações, comunique-se com frequência, façam planos de melhorias constantes com base nos aprendizados.
- Clientes externos, contratados e fornecedores – São indivíduos ou grupos fora do negócio. Entregar informações sustentáveis e essenciais para este grupo é extremamente importante, geralmente os dados que vamos coletando ao longo do tempo ajudam nessa comunicação.
Sempre haverá mais de uma parte interessada, e quanto mais partes interessadas, mais interesses conflitantes. Sendo assim, é importante entender esses conflitos e tentar resolvê-los. As expectativas das partes interessadas devem ser claramente explicitadas e seu papel será sempre gerenciar isso da melhor forma possível.
Para fazer isso, você precisa:
Determinar onde está o poder/influência
Meça o grau em que as partes interessadas podem influenciar. Quanto mais influente for um stakeholder, mais o projeto precisará de seu apoio. Saber o que cada stakeholder precisa ou deseja permitirá avaliar seu nível de apoio.
Identificar metas
Identifique as características e os interesses das partes interessadas. Ter uma compreensão clara do que os motiva, bem como o que os provoca. Determinar se há conflitos de interesse entre o grupo de partes interessadas.
Identificar a cultura do stakeholder
Ao operar em grande escala, as partes interessadas do projeto podem não compartilhar uma cultura comum. Deve haver adaptações para lidar e trabalhar com as diferenças culturais. Os três principais aspectos da diferença cultural que podem afetar um projeto são:
- Comunicação: a mentalidade, a linguagem, os sinais e os símbolos das partes interessadas são diferentes entre as culturas;
- Negociações: cada cultura tem uma visão de mundo diferente e, portanto, uma grande variação no estilo de negociação;
- Tomada de decisão: as diferenças interculturais têm uma grande contribuição na tomada de decisão das partes interessadas.
Entender suas expectativas
Esclareça quando necessário e tenha certeza absoluta de que suas expectativas são compreendidas e atendidas. Valide sempre.
Definir o que é sucesso
Cada parte interessada tem uma ideia diferente de como é o sucesso do projeto/produto. Reúna as definições antecipadamente e inclua-as nos objetivos para ajudar a garantir que todas as partes interessadas apoiem os resultados finais e faça com que revisem constantemente.
Manter as partes interessadas envolvidas e informadas
Não reporte apenas às partes interessadas, peça a opinião delas também. Meça a capacidade de participação de cada parte interessada e respeite as restrições de tempo de cada um.
Nesse sentido, você deve também enviar atualizações de status regulares, mas dentro de frequência acordada. Muitos emails e informações podem fazer com que eles nem se interessem em ler o que você compartilhou.
Atendendo às necessidades e criando consenso entre as partes
Poderíamos dizer que uma maneira de construir consenso é atender as necessidades das diferentes partes interessadas. Porém, é difícil construir um consenso em torno de uma iniciativa se atendermos apenas às necessidades de uma parte interessada. Quanto mais stakeholders se beneficiarem de suas ideias, mais fácil será para você construir um consenso.
Quanto menor for o nível do stakeholder, a necessidade geralmente tem um foco mais no tático. Já para as partes interessadas de nível mais alto, as necessidades costumam ser mais estratégicas.
E aqui o desafio pode ser grande pois as partes interessadas do seu cliente também terão necessidades conflitantes. O que um grupo de pessoas dentro de uma empresa pode precisar pode causar problemas para outro grupo na mesma empresa. Aposto que você já deve ter passado por algo assim na sua carreira. Vai ser a sua capacidade de entender e mitigar essas necessidades conflitantes que vai te ajudar a construir um consenso.
Aqui vão algumas dicas de como fazer isso:
Não ignore nenhum stakeholder
A razão pela qual nenhum consenso é construído é muitas vezes porque as partes interessadas que seriam necessárias para um consenso são ignoradas.
Se você não investir tempo em se reunir com todas as pessoas que podem ser diretamente afetadas por uma decisão e aprender sobre suas necessidades, sua ideia – por melhor que seja – não vai adiante.
Seja bom ouvinte
Primeiro crie relacionamento, mostre interesse genuíno por ouvir o que eles têm a dizer, reunindo-se com as partes interessadas individuais e colete suas necessidades. Você ficará surpreso com o quanto aprenderá e o quanto isso significa para eles.
Depois disso, agende reuniões em grupos com seu cliente para discutir quaisquer problemas que você possa ter que mitigar e trabalhar. Esse é quase um momento de co-criação, porém vocês estarão discutindo o alinhamento de interesses.
Apresente alternativas
Com base no que você entendeu de todas as necessidades, traga os prós e contras das opções que norteiam os melhores direcionamentos e ajude-os a ver o que é possível e quais podem ser as compensações.
É importante que você continue fazendo reuniões privadas para entender quaisquer obstáculos e trabalhar com seus colegas para encontrar maneiras de resolvê-los da melhor forma.
Conecte a proposta a um problema
E por último, se o que você está fazendo é de alguma forma interessante, você pode vincular todo o contexto a um problema maior e atraente, explorando cada vez mais novas possibilidades. De alguma forma, estará relacionado ao aumento de lucros, aumento de receitas ou redução de custos.
Apresentando a ideia
Agora que você já entendeu como e quão importante é realizar esse mapeamento inicial, vamos à parte na qual trazemos a ideia para a mesa e nos aprofundamos nas formas de fazer isso.
Lembrando que as formas que eu trago aqui não se limitam, você pode encontrar muitas outras maneiras de fazer isso, sempre use sua criatividade a seu favor com o que você tem nas mãos.
Mapeando a ideia
O primeiro passo é fazer o mapeamento dessa ideia trazendo algumas perguntas que podem direcionar esse primeiro entendimento. Faça perguntas como:
- Você tem algum problema a ser resolvido?
- Isso é algo que as clientes querem?
- Alguém pagaria por essa ideia?
- É algo que pode ser resolvido?
Já para o entendimento do mercado, você pode fazer perguntas como:
- As pessoas querem o que você está propondo construir?
- Você sabe como adquirir novos clientes?
- Sabe como reter clientes?
- Você vai ser pago pelos clientes?
Conseguir responder o máximo de perguntas vai te ajudar a mostrar para seus stakeholders que ter mercado (Product-Market Fit) e potenciais usuários (Problem Solution fit) é o que mais importa nesse momento.
Assim você garante que, além de gerar valor para todas as partes envolvidas, também poderá superar os resultados esperados pelas partes interessadas.
Validando a ideia
Para realizar essa análise e conseguir essas respostas, existem várias técnicas que podem te apoiar. Você precisa entender qual o melhor meio de aprendizado, quais são suas restrições, o que é mais viável no momento e que pode te gerar resultados rápidos, pensando sempre em um bom MVP.
Técnicas para validar e gerar dados:
- Através de landing pages: criando uma página simples falando sobre esse produto/ideia e analisando quantas pessoas clicam nessa página demonstrando interesse;
- Pre-order – disponibilizando a venda de seu serviço ou produto sem ter ele pronto ainda, deixando as pessoas cientes sobre isso e analisando quantas pessoas estão apostando e investindo na sua ideia;
- Vídeos explicativos: temos o famoso exemplo do Dropbox, que através do vídeo explicando o produto sem ao menos ter pronto conquistou muitas pessoas interessadas;
- Piecemeal MVP: basicamente uma demonstração do seu produto utilizando ferramentas já disponíveis no mercado, observando o engajamento para adaptar seu produto;
- SaaS e PaaS: você utiliza algum serviço ou plataforma disponível no mercado e inclui ao seu MVP para ganhar tempo – se fizer sentido e no futuro aumentar o número de clientes, você avalia a possibilidade de criar a própria plataforma ou serviço;
- Wizard of Oz: é uma forma simples de se validar um produto ou serviço sem necessariamente ter tudo pronto. Podemos citar algumas empresas que usaram esse formato, como a Zappos (o idealizador ia às lojas locais, tirava fotos dos sapatos e postava no site, comprando e enviando o produto apenas quando alguém o adquiria online) e a Groupon (eles tinham um blog bem simples em WordPress, que gerava cupons em PDF que eram enviados manualmente para os interessados;
- Entrevistas, demos, protótipos: esses são os mais comuns, onde você cria formulários de perguntas, agenda entrevistas, desenha alguns protótipos mais simples, agenda reuniões online ou presenciais e toma nota desses usuários.
Expondo os dados coletados
Após ter utilizado algumas dessas técnicas e coletar os dados necessários, você precisa conseguir responder mais algumas perguntas que vão fortalecer as conversas com os stakeholders.
- Você consegue de alguma forma provar que seus usuários e/ou clientes não vivem sem o seu produto?
- Você consegue ter pedidos que validem seu roadmap de vendas?
- O modelo financeiro proposto faz sentido? Você tem um negócio viável?
Cuidado com as métricas de vaidade que nos fazem se iludir rapidamente acreditando que a ideia vai ser um sucesso de cara. Números ou estatísticas parecem lindas no papel, mas se elas não significam nada de importante na prática, é bem perigoso cair numa cilada.
Números de downloads isolados, por exemplo, não nos dizem nada. Muitos usuários podem ter feito o download e nem estar usando o produto. O mesmo serve para o número de visitantes, pois sem a interação não temos muita coisa.
Existem algumas formas de coletar essas métricas de forma que sejam relevantes e úteis para o negócio:
Métricas Piratas (AARRR)
Aqui você desenha um funil AARRR com as etapas de Aquisição, Ativação, Retenção, Indicação e Receita.
Com esse framework, você vai conseguir responder à algumas perguntas, como:
- Quais os meios que os usuários te encontram?
- Como é a primeira experiência desses usuários?
- Os usuários voltam a interagir com o produto?
- Os usuários contam sobre o produto para outras pessoas, amigos, familiares?
- Como você faz dinheiro com esse produto?
Net Promoter Score (NPS)
Com base no resultado do NPS você vai poder ter uma ideia de como esses usuários se sentem usando o produto. A proposta nada mais é do que aplicar uma pesquisa que visa entender o nível de satisfação do usuário, assim como a probabilidade de indicação do produto para um amigo.
Criando o modelo de negócio
Até aqui você já tem:
- O mapeamento completo das pessoas interessadas;
- Quais suas maiores necessidades com o negócio;
- Suas metas e objetivos no curto, médio e longo prazo;
- Dados coletados sobre mercado e usuários.
Agora é importante criar o modelo de negócio para dar andamento na ideia proposta.
Nesse momento podemos considerar que os stakeholders compraram a ideia, porém isso ainda vai ser um trabalho contínuo de validação – tanto do trabalho que vai ser executado, como em continuar acreditando que isso está dando certo.
O legal de construir um Business Model Canvas para tangibilizar o modelo de negócio é que você consegue ter cada vez mais visibilidade de como, o que, para quem e por que você está construindo essa ideia de produto.
Aqui vale destacar alguns pontos importantes para aproveitar o melhor dessa poderosa ferramenta:
- Valide sempre: cada um dos blocos tem diferentes formas de impactar no produto final, ter esse olhar das partes que complementam o todo trará muitos insumos de onde você deve dar mais atenção;
- Capture valor no mercado: se você não observar essa parte no momento em que coleta dados, provavelmente você vai deixar passar algumas coisas que afetam significativamente o seu modelo de negócios.
“É importante compreender os padrões de modelos de negócio e adaptá-los ao seu mercado. – Business Model Navigator”
- Garanta a consistência (interna e externamente): essa documentação é viva e deve ser atualizada sempre que for descoberto coisas novas ao longo do caminho.
Como obter buy-in com dados para reduzir as dívidas técnicas
Como uma produteira técnica que sou, não poderia deixar de fora esse assunto – que é muito importante.
É bem comum que partes interessadas e outros líderes executivos se afastem da equipe quando o assunto começa a ir para um lado mais técnico.
Geralmente o foco está tanto no negócio – em entregar os recursos o quanto antes para o ajuste de mercado – que não priorizam de forma adequada a qualidade de como está sendo feito. Ou seja, os assuntos sempre estão girando em torno de atingir metas de negócio com entregas rápidas, na maior produtividade possível.
Porém a comunicação sobre o impacto que isso também gera no negócio é crucial, principalmente quando se trata de gerenciar a redução de dívidas técnicas que vão se acumulando ao longo do caminho (quando o foco não está na qualidade).
A maioria dos engenheiros pode refatorar o código (processo de alterar um software de uma maneira que não mude o seu comportamento externo e ainda melhore a sua estrutura interna) à medida que se deparam com as inconsistências. Isso acontece principalmente times mais sênior, que têm essas habilidades evidentes no dia a dia, fazendo essas alterações sem precisar haver uma conversa explícita sobre isso.
Porém, à medida que o produto (MVP) vai evoluindo, você vai precisar de mais recursos e pessoas nos bastidores, garantindo que tudo continuará funcionando de forma eficaz. Por isso, é importante haver uma comunicação clara e bem estruturada, trazendo informações relevantes que contribuam com esse diálogo.
Minha experiência nesse contexto
Recentemente passei por uma situação bem parecida no meu time. Entregamos o MVP de um produto que foi um sucesso – pasmem: em menos de 5 meses conseguimos mais de 1 milhão de usuários se registrando e usando o produto.
O cliente não poderia estar mais feliz, pois entregamos o produto que tinha fit de mercado e que resolvia o problema de usuário. Ganhamos uma profunda confiança da cliente, que passou a nos solicitar o desenvolvimento de novos produtos.
Qual foi o problema aqui?
As dívidas técnicas começaram a se acumular e a prioridade eram os novos produtos a serem desenvolvidos. O cenário que se seguiu foi quase algo como: “Tudo bem se estivermos sangrando um pouquinho, vamos colocar um band-ainds por enquanto, avisem quando estiver jorrando sangue”.
E o resultado?
Nossa aplicação não estava resiliente o suficiente ou mesmo robusta para suportar a quantidade de requisições que estavam acontecendo.
Outro ponto também é que, por termos muitas dependências com outros sistemas externos, quando um deles um problema gigante de comunicação (DNS), nosso produto foi ao fundo do poço, literalmente. Tivemos que tirar o produto do ar quando perdemos o controle da situação.
Como identificamos esse problema?
Através de alertas e métricas de monitoramento internas que foram implementadas para nos avisar quando algo errado estivesse acontecendo.
Mais uma vez, fizemos um ótimo trabalho em mapear os riscos e problemas que poderiam acontecer no fluxo de comunicação entre as APIs e outras plataformas. Além disso, criamos os alertas e organizamos as métricas que poderiam ser de maior impacto em dashboards de visualização, para estarmos preparados quando qualquer inconsistência começasse a aparecer com mais frequência.
Obviamente alguns problemas foram reportados imediatamente para a cliente, já outros viraram histórias de débitos técnicos e melhorias – que nunca eram priorizados como deveriam.
O que podemos concluir desse exemplo?
- O problema foi o negócio? Definitivamente não, validamos com sucesso essa parte do modelo de negócio;
- Deixamos de mapear nossa arquitetura e possíveis melhorias do MVP? Não, tivemos um backlog cheio de dívidas se acumulando, e muitas documentações de como era o modelo de arquitetura;
- Deixamos de mapear os riscos? Também não, fizemos sessões com o time para mapear os riscos e pontos que deveriam ser monitorados através de métricas e alertas a fim de ter uma resposta rápida se algo acontecesse.
- O que faltou então? Eu diria que comunicar de forma intencional para as partes interessadas o quão importante é dar a devida atenção à parte técnica e aos dados que estávamos monitorando, considerando o impacto que tudo isso poderia gerar ao produto e usuário final.
Sendo assim, para obter o buy-in com dados em caso de dívidas técnicas, eu sugiro focar em 2 ações principais: 1) avaliar o impacto e 2) trabalhar a comunicação desse impacto antes que a situação se agrave.
1. Avaliando o impacto de um problema técnico
Antes de tudo precisamos ter certeza de que o que estamos fazendo é realmente impactante e pode ser justificado junto com outras prioridades da equipe. Fazer isso às vezes requer um nível de muita discussão na hora da modelagem da arquitetura mapeando os principais pontos de risco.
Ter a disciplina de dar um passo atrás, avaliar o impacto de um projeto e depois decidir se vale a pena priorizar é difícil. Mas vai ajudar o resto de sua equipe a pensar criticamente sobre prioridades e foco.
Algumas perguntas que podem direcionar melhor o entendimento desses possíveis impactos a serem justificados na priorização:
- Que tipo de mudanças esperamos fazer nos próximos meses?
- Quais são as principais prioridades para a equipe de engenharia agora? E a empresa?
- Qual é a principal métrica de sucesso deste projeto e qual seria o impacto na equipe de engenharia?
- Qual é o impacto na produtividade do desenvolvedor, nas revisões de código etc?
- O que é esperado que aconteça com o crescimento do produto? Existe algum mapeamento de escalabilidade?
- Vai ser preciso mudar alguma lógica de negócios?
2. Comunicando o impacto com clareza
Se após responder essas perguntas e fazer um mapeamento de riscos técnicos, o time percebeu que a preocupação é válida e importante, você precisa comunicar as pessoas envolvidas e as partes interessadas. Quanto mais distante o nosso público estiver da mecânica e dos objetivos do nosso trabalho, mais importante se torna a comunicação sobre o impacto.
Por exemplo, digamos que o time queira priorizar algumas refatorações no código relacionado a algumas partes do serviço de usuário, você pode fazer de forma simples, uma tabela ou usando a ferramenta que achar melhor e preencher junto com o time de engenharia.
Dessa forma você também conseguirá entender o que o time está fazendo e traduzir isso em linguagem de negócio posteriormente aos interessados.
Eu geralmente faço uma planilha de Excel para ir mapeando as tarefas técnicas, colocando uma coluna com o nome do card (história/demanda), uma outra coluna para explicar brevemente qual é o cenário atual. Em uma próxima coluna, explico brevemente a solução desenvolvida e o porque foi feito. Por último, qual resultado se espera após a mudança – que pode ser explicativo mesmo, ou utilizando dados e métricas para garantir um reforço ainda maior.
Vou trazer um exemplo bem simples de como é essa planilha para ajudar a ir transformando essas informações técnicas em informações que você consiga dialogar com os stakeholders. Esse formato é só uma ideia, dependendo do seu contexto ou necessidade tente melhorar e adaptar para fazer mais sentido com o que você precisa.
Digamos que o time irá fazer determinado card para que a performance de resposta ao usuário aumente a rapidez em 40% – e, consequentemente, isso também irá impactar positivamente em outros aspectos do produto e satisfação do usuário. Essa planilha pode te ajudar a tangibilizar melhor os “porquês” e os “comos” do time de Engenharia para atingir essa métrica.
Quanto mais claramente você puder articular seu impacto técnico, mais bem-sucedido será em obter adesão das pessoas interessadas.
Conclusão
Nada disso será uma tarefa fácil, no entanto é totalmente possível desde que você tenha um senso de observação aguçado e esteja preparado para as possibilidades e desafios que irão surgir ao longo do caminho.
O buy-in dita tudo o que se seguirá de cima para baixo quando falamos de stakeholders, de quanto apoio de colegas você desfrutará, até quanto espaço de manobra você terá com erros e riscos.
Todo esse esforço feito desde o início irá indicar a quantidade certa de trabalho para chegar o mais perto possível do que você e todos os envolvidos desejam alcançar. É sobre usar o melhor das ferramentas para mostrar as partes interessadas que o tempo investido agora economiza potencialmente dinheiro e dor de cabeça mais tarde.
Mapeie as partes interessadas em todos os níveis, escute-os, leve-os para cocriação de ideias e gere consenso entre as partes, criando também espaços para seu time e cliente exporem ideias. Invista em ferramentas de data visualization e transmita clareza sobre o que é preciso e quais os impactos das decisões. Isso vai te fornecer uma base sólida de monitoramento e controle enquanto tenta o apoio necessário para o projeto.
Fazer essas coisas não garante o sucesso final, pois ainda iremos aprender muito ao longo do caminho. Mas com certeza isso vai te ajudar a construir uma equipe de alta performance, que questiona e analisa criticamente as decisões, assim como vai ganhar a confiança e apoio de quem você precisa para continuar investindo no valor que você está ajudando a gerar.
Leia também:
