Entrevista com stakeholder: o que perguntar antes do projeto

Entrevista com stakeholder é a conversa com quem tem interesse ou poder sobre o projeto, feita antes de desenhar. Serve para descobrir a história, a meta de negócio, as restrições e o que já foi tentado. Pergunte sobre quatro temas: como o sucesso vai ser medido, o que é prioridade, o que a pessoa sabe pela função dela e como ela quer acompanhar o trabalho. O que sair dali é hipótese sobre o usuário, e precisa ser conferido com quem usa o produto.

O que a conversa traz para o projeto

O guia de entrevista com stakeholder do Nielsen Norman Group (em inglês) define stakeholder como qualquer pessoa com interesse no projeto ou com quem você precisa trabalhar para concluí-lo. A entrevista com essa pessoa tem o mesmo formato de uma entrevista com usuário, mas o assunto muda. Você não pergunta como ela usa o sistema. Pergunta o que o projeto precisa atingir e o que pode travar o caminho.

O artigo lista quatro ganhos:

Contexto e histórico. Todo projeto chega com origem, limite conhecido e solução que já falhou. Em empresa grande, quase sempre chega com política junto.
Meta de negócio. O designer olha para o usuário, e quem decide olha para o negócio. A conversa mostra qual número vai provar que o projeto deu certo.
Visão alinhada. Você descobre onde a visão da pessoa difere da sua antes de a diferença virar retrabalho.
Apoio. Quem foi ouvido no começo tende a defender o resultado no fim.

O melhor momento é o começo. O NN/g diz que nunca é tarde, mas a entrevista rende mais quando abre o projeto, quando alguém novo entra ou quando algo deu errado e o time precisa recomeçar.

Antes de marcar: quem pesa no projeto

A lista de quem ouvir costuma ficar longa. O artigo de análise de stakeholder do NN/g (em inglês) propõe ordenar essa lista numa matriz de poder e interesse. Cada pessoa cai num de quatro quadrantes, e cada quadrante pede um cuidado diferente:

Muito poder e muito interesse: acompanhar de perto, porque essa pessoa pode parar o projeto ou virar a maior defensora dele.
Muito poder e pouco interesse: manter satisfeita, porque ela pode entrar no projeto quando perceber que ele afeta o trabalho dela.
Pouco poder e muito interesse: manter informada, com convite para sessão de pesquisa e para crítica de design.
Pouco poder e pouco interesse: observar de tempos em tempos, porque a posição muda.

O mesmo artigo acrescenta uma terceira coluna que a matriz não tem: a atitude da pessoa diante do projeto. Uma pessoa de muito poder e atitude negativa é onde vale gastar mais energia. A matriz também envelhece. Troca de liderança move gente de quadrante, então o mapa precisa ser revisto durante o projeto.

O roteiro: quatro temas e perguntas abertas

A entrevista costuma ser semiestruturada. Em vez de um script fixo, você leva um roteiro que dá direção e pode ser abandonado quando a conversa rende. O NN/g sugere organizar as perguntas em quatro temas:

Métrica de sucesso. O que a pessoa quer atingir, por que isso importa para a empresa e que número ela acompanha.
Prioridade. Qual problema está no topo da lista dela e do time dela agora.
Histórico e conhecimento. Que restrição você precisa conhecer e que solução já foi tentada, com o motivo de ter dado certo ou não.
Processo. Quanto ela quer participar e por qual canal prefere ser avisada.

Durante a conversa, fique neutro e escute mais do que fala. Peça um exemplo concreto, pergunte sobre a última vez que algo aconteceu e pergunte por que aquilo importa. No fim, pergunte com quem mais você deveria conversar. A resposta revela quem a pessoa considera importante e às vezes rende uma apresentação a outra pessoa importante.

Se a pessoa não tem agenda, mande por email só as quatro ou cinco perguntas mais úteis, e não o roteiro inteiro. A meta que sair do primeiro tema é o ponto de partida do relatório de impacto, e medir a linha de base antes do projeto depende dela.

A resposta interna vira hipótese, não achado

O processo de mapa de jornada em cinco etapas do NN/g (em inglês) mostra onde a entrevista entra numa pesquisa maior. Primeiro o time reúne o que a empresa já sabe: pesquisa de mercado, registro de atendimento, comentário de cliente. Depois entrevista quem decide, usando esse material para guiar as perguntas. Com isso, o time monta um mapa de hipótese da jornada.

O passo seguinte é o que separa a entrevista de pesquisa com usuário. O mapa de hipótese precisa ser validado, ou derrubado, com gente de fora, por entrevista, observação direta ou estudo de diário. O artigo sugere que de seis a oito participantes bastam para começar quando o prazo é curto.

O guia básico de mapa de jornada do NN/g (em inglês) dá a razão de fundo. O ator do mapa precisa ter as ações apoiadas em dado, e o pensamento de cada etapa idealmente vem de frase dita pelo próprio cliente na pesquisa. Opinião interna sobre o usuário não ocupa esse lugar.

Como foi no redesign do C6 Bank

No redesenho do aplicativo de computador do C6 Bank, segui essa ordem. O aplicativo é onde ficam as operações mais complexas do banco, e a complexidade acumulada só aparecia observando alguém usar de verdade. O projeto começou pelo mapeamento de jornadas e pelas entrevistas com as partes interessadas internas do banco.

O mapa e as entrevistas serviram para identificar os pontos de dor, mas não bastaram para decidir. As decisões de design passaram por protótipos iterativos e testes de usabilidade com usuários reais antes de qualquer implementação. O redesenho chegou ao desenvolvimento já testado. Para o tamanho de um teste assim, o critério está no texto sobre teste de usabilidade com cinco participantes.

Onde as fontes divergem

Conversa individual ou em grupo. O guia de entrevista pede conversa de um para um. O processo de mapa de jornada aceita grupo focal de três ou quatro pessoas da mesma função quando falta tempo.
Por onde começar. O guia de entrevista parte de uma meta definida para a conversa. O processo de jornada parte do dado interno que já existe e só depois chama as pessoas.
Quanto analisar. O guia de entrevista aceita um documento simples com os temas quando são poucas entrevistas, por volta de cinco. Acima disso, recomenda análise temática, com código em cada observação. O artigo de análise de stakeholder trata a entrevista como ferramenta para descobrir a atitude da pessoa, e não como dado a codificar.

O erro comum

O erro clássico é tratar a entrevista interna como pesquisa com usuário. A pessoa de vendas descreve o que o cliente reclama, a de suporte descreve o que chega no chamado, e as duas descrições soam como achado. Elas são pistas. Anote cada uma como hipótese, diga qual pesquisa vai conferir e mostre o resultado para quem foi entrevistado. Assim ninguém se surpreende quando o mapa muda.