Gestão de Stakeholders para Lideranças de Engenharia

Transcript

1. GESTÃO DE STAKEHOLDERS para engineering leaders
2. Eduardo Matos Pai da Duda e do João Líder em Tech há +8 anos Desenvolvedor há +18 JWT | R7.com | Creditas | GetNinjas | Nubank | Will Bank | iFood
3. Agenda • De fi nições de Stakeholders; • Histórias e experiências; • Sobre Expectativas; • Capital Político; • Ferramentas, Rituais e Práticas; • Exercício de Mapeamento de Stakeholders; • Criação dos grupos e Passo 1 - Identi fi car; • Passo 2 - Classi fi car por interesse/in fl uência; • Passo 3 - De fi nir Abordagem; • Trazer para o grupo todo; • Perguntas e consideração fi nal.
4. pra eu conhecer um pouco de vocês rapidamente, digitem no chat: Nome, time/área, cidade
5. Nas últimas décadas do século XX, a palavra “stakeholder” tornou-se mais comumente usada para signi fi car uma pessoa ou organização que tem um interesse legítimo em um projeto ou entidade. De fi nições de Stakeholder
6. No contexto de engenharia Stakeholders mais comuns em engenharia são: • Product Managers, GPMs, Heads de Produto, CPOs; • Data Leads, Data Managers, CDOs; • Product Design Lead, Design Managers; • Product Marketing Manager; Stakeholders que são impactados indiretamente pelos times de engenharia podem ser diversos, desde Customer Experience, até Riscos e Compliance, Segurança, Public Relations, etc.
7. Tipos e níveis de stakeholders Internos
 São os que comentei anteriormente, que estão dentro da empresa Externos
 Investidores, órgãos reguladores, fornecedores. Nesse workshop, vamos focar apenas em internos.
8. Histórias, nossas histórias Meu time está voando Era minha primeira experiência como pessoa gestora. Meu time estava voando. Nós fazíamos entregas semanais, rodávamos experimentos, validávamos hipóteses rápidas, e estávamos atingindo os nossos objetivos. Numa reunião trimestral, onde apresentávamos os resultados do trimestre e os objetivos do próximo, mostramos o que atingimos e estávamos con fi antes de que o nosso trabalho era um sucesso. No primeiro slide quando falamos o primeiro resultado uma das lideranças levantou a mão e perguntou: vocês estão considerando como vão comunicar os clientes sobre essas novas funcionalidades? Silêncio absoluto, nós nem tínhamos pensado nisso. Logo após, outra liderança levantou a mão: e se a funcionalidade causar problemas ou dúvidas, qual vai ser a estratégia de comunicação no atendimento aos clientes? E essa foi a minha primeira experiência de lidar com stakeholders. Até então, eu estava pensando apenas na e fi ciência de entrega do meu time, desconsiderando as interdependências com as áreas. Falando assim dessa forma, hoje eu sinto que foi falta de experiência ou até uma certa inocência da minha parte, mas grande parte dos desencontros, quando lidamos com entrega contínua de software, acontece por falta de gestão de expectativas com stakeholders. Quantos de vocês já passaram por esse tipo de situação?
9. Histórias, nossas histórias O Blocker Eu fazia a gestão da área de segurança da informação de uma empresa. Nós tínhamos construído um Framework, baseado no NIST, que é um framework de segurança conhecido no mercado, mas que continha elementos que, ou estavam ultrapassados, ou não batiam com a nossa realidade. Depois de construir o framework, nós começamos a aplicar dentro da empresa e promover melhorias, principalmente no ecossistema de desenvolvimento de software. Numa reunião quinzenal com toda a diretoria eu apresentei o projeto e as iniciativas relacionadas aos itens de segurança do framework. Mas o Diretor de Compliance levantou vários questionamentos do porquê não utilizar um framework conhecido como o NIST. Ele tinha vários pontos que faziam sentido, mas estava irredutível com relação a adaptação que fi zemos para o nosso contexto. Ele pediu para bloquearmos as iniciativas enquanto ele não fi zesse suas considerações e avaliasse se as adaptações que nós fi zemos seriam aceitas por órgãos regulatórios. Ele bloqueou o projeto praticamente. Fizemos um 1:1, e ele trouxe várias considerações que não tínhamos levado em conta quando iniciamos o projeto. Ao mesmo tempo, percebi que ele se sentia ignorado, e que a sua área não era considerada nas discussões de produto.
10. Sobre Expectativas Essas histórias são mais comuns do que parecem. Grande parte das dores está relacionada a quebra de expectativas e a inde fi nição de responsabilidades sobre decisões ou sobre resultados. Por exemplo, você sabe qual expectativa existe sobre os projetos que você está tocando, pelos times de Atendimento, Segurança, Compliance, Jurídico? As lideranças dessas áreas estão à par das iniciativas que o seu time está planejando ou que vai entregar em breve? elas fi zeram parte do processo de validação ou de viabilidade ou tiveram espaço para levantar pontos de atenção? Normalmente andamos no automático, e queremos focar na velocidade das entregas, sem perceber que gerir as interdependências são parte do desa fi o de gestão. Gerir as dependências também inclui construir relacionamentos com stakeholders.
11. Expectativas comuns nessa relação
12. Visibilidade Visibilidade gera Con fi ança. Se você não consegue demonstrar quais iniciativas seu time está trabalhando, em que fase de desenvolvimento está, e se há algum problema que precisa de ajuda, nunca você irá gerar con fi ança. Além disso, visibilidade traz segurança para as pessoas que dependem ou esperam algo do que vocês estão trabalhando.
13. Envolvimento Alguns stakeholders querem ser envolvidos nas discussões ou até mesmo na decisão fi nal de um objetivo, um projeto, ou até em uma re- estruturação organizacional. É importante saber qual o nível de interesse e se de fato essas pessoas podem contribuir para a decisão, seja com idéias ou " fi nanciando" elas (ex: budget, como aliados). Stakeholders que não contribuem, mas querem decidir, podem ser um problema de se gerenciar. Nesses casos, é importante explicitar o envolvimento: é consultivo? é apenas pra ser informado? quer tomar a decisão em conjunto?
14. Nível de detalhe (operacional, tático, estratégico) Uma dica é entender o nível de detalhe que a pessoa quer ser envolvida, ou informada. No nível operacional, é onde o time decide o "como". Normalmente, stakeholders não deveriam se envolver aqui, mas nos casos onde isso aconteça, é importante de fi nir o papel - ter interferência no dia-a-dia do time é algo que você precisa lutar contra. Não é o papel de um stakeholder dizer COMO um time deve trabalhar, a não ser que não haja con fi ança no time, ou o time é formado por pessoas com pouca experiência. Infelizmente isso é sempre usado como argumento para haver esse envolvimento. É importante deixar claro o quanto isso pode afetar a segurança do time no próprio trabalho. No nível tático é onde uma parte dos stakeholders pode contribuir muito. Entender se as iniciativas podem contribuir para suas áreas de interesse é algo que sempre vai ser buscado nessa relação, por isso é importante ter a participação deles, em algum momento da de fi nição de hipóteses ou apostas dos times. No nível estratégico é onde stakeholders mais deveriam atuar. Nesse caso, entender como os objetivos das áreas que stakeholders pertecem podem gerar mais resultado de negócio e como seu time pode contribuir com isso, é essencial para conectar esses objetivos em comum.
15. Capital político No segundo exemplo, do Blocker, a Head de Segurança decidiu se aproximar mais do diretor de Compliance, e conhecer mais quem ele era, quais as crenças e valores, frustrações, e entender como se relacionar mais com a áre de Riscos. Ela descobriu, por exemplo, que falar com ele presencialmente era mais efetivo, e ele era menos ansioso ou mais calmo do que de forma remota. Ela começou a convida-lo para validar roadmap e objetivos de segurança, e até conseguiu o buy-in dele nas reuniões de diretoria. Capital político é algo que sempre evitamos de falar, mas quando começamos a enxergar a perspectiva das outras pessoas, nos conectar de verdade com elas, percebemos que existem anseios e expectativas que geralmente não são explicitadas, e elas são as que causam mais con fl itos e impedimentos para que as coisas aconteçam.
16. Aproximação Pegando o exemplo de Segurança, que comentei anteriormente, a estratégia de aproximação foi: • Saber quem era a pessoa (conhecer de onde a pessoa era, quebrar o gelo, história pro fi ssional, etc.); • Entender o motivo do blocker - sem o viés de uma reunião formal de diretoria (o que de fato era impeditivo e poderia ser problema para os órgãos regulatórios); • Entender as frustrações (entender porquê o sentimento de distância com relação a produto); • Combinar ações de colaboração (convidar para de fi nição de objetivos);
17. Aproximação Esse é um formato que não necessariamente precisa ser sempre dessa forma, mas esses passos podem fazer parte de um método de aproximação que você pode replicar no seu dia-a-dia. 1) conhecer 2) empatizar 3) alinhar expectativas 4) combinar o trabalho em conjunto
18. Consultando e Informando Precisamos entender que alguns stakeholders gostariam de ser consultados em decisões estratégicas do seu time. Outras pessoas gostariam apenas de serem informadas. Criar ferramentas pra lidar com esses desa fi os de envolvimento dessas pessoas é algo essencial para tornar a relação mais con fi ável - e consequentemente aumentar seu capital político.
19. Ganhando Aliados Alguns projetos podem impactar positivamente áreas diferentes. Nesses casos, quanto mais você se aproximar dessas lideranças e convida- las a participar das decisões, ou informá-las sobre o andamento desses projetos, mais você cria um laço de con fi ança e de entendimento da importância do seu trabalho e do seu time. As decisões fi cam mais fáceis dessa forma, e em momentos de questionamentos sobre os projetos, você pode ter stakeholders como aliados.
21. Empatia e escuta ativa Outro cenário que eu sempre vivenciei foi de pessoas não-técnicas questionarem as entregas, prazos ou a forma como trabalhamos em tecnologia. Imagine que muitas dessas pessoas vieram de contextos, épocas ou períodos diferentes, e acima de tudo, de outras realidades. Quando falamos que é quase impossível cravar datas numa entrega de tecnologia, essas pessoas vão questionar, por não entender como a construção de um software é feita - por ser uma área do conhecimento, mesmo sendo de exatas ao mesmo tempo. Se aproximar das pessoas, explicar como trabalhamos, e além disso, entender, escutar, empatizar com um olhar de mundo diferente do nosso, faz parte de construir um capital político, e de facilitar o nosso trabalho, como pessoas de tecnologia.
22. Dinâmica do poder Não dá pra não falar sobre a dinâmica do poder/ autoridade nesse caso. Infelizmente, ela existe, e temos que lidar com isso de alguma forma. O pior cenário é termos essa dinâmica oculta, não explicitada, portanto difícil de gerir ou atender expectativas. Deixar claro qual o nível de envolvimento a pessoa quer ter e em quais tipos de decisões é super importante pra manter sua sanidade e tranquilidade - e a do seu time também.
23. Ferramentas, rituais e práticas pra gestão de stakeholders Práticas síncronas • Reuniões de pré-release; • Business Review (resultados e objetivos); • Update de iniciativas (apresentação); • De fi nição de responsabilidades e nível de participação; • Conversas individuais; • Delegation Board; • Comitês de liderança; Práticas assíncronas • Updates via Slack/Teams; • Canais de mensagem com stakeholders; • Documentos (RFCs); • Board com iniciativas;
24. Mapeando Stakeholders Vamos praticar?
25. Perguntas e Discussão 🙋🙋
26. Obrigado