Por que você NÃO deve ter empatia com seu cliente – parte 2

Como desenvolver Empatia Responsável Pare! Se você está lendo este artigo sem ter lido este, recomendo fortemente que volte...

Evellyn Zagui de Almeida

View posts by Evellyn Zagui de Almeida
Formada em tecnologia da informação pela Unicamp, atua há mais de 10 anos no mercado de TI. Iniciou sua carreira como desenvolvedora de software, passou pela área de qualidade e há 8 anos atua como Product Owner na Dextra. Também é instrutora de treinamentos (qualidade, automação, metodologias ágeis), além de escrever diversos artigos relacionados à relacionamento com o cliente e gerenciamento de produto, liderança, treinamentos, entre outros.
Data de publicação: 15/03/2019

Como desenvolver Empatia Responsável

Pare! Se você está lendo este artigo sem ter lido este, recomendo fortemente que volte e leia o artigo anterior, pois este aqui é a continuação, ok?

Desenvolver empatia responsável não é uma atitude gratuitamente alcançada. Não é fácil e não é de um dia para o outro. Como responsáveis por gerenciar um produto, temos que lidar com inúmeros fatores, como prazos, limitações financeiras, e o princípio mais básico de qualquer relacionamento comercial: satisfação de ambas as partes.

Ao longo de anos como Product Owner aqui na Dextra, pude atuar em produtos dos mais diversos segmentos e aprendi algumas lições. Aqui eu listei 4 delas, fundamentais na jornada para desenvolver empatia responsável:

1. Conheça seu usuário (de verdade!)

Já sabemos que conhecer nosso usuário final é fundamental para nos ajudar a desenvolver soluções assertivas. Porém, muitas vezes, devido à n fatores (falta de tempo, orçamento ou conhecimento) não envolvemos estas pessoas em nenhuma etapa do desenvolvimento. Assumimos características para representar estas personas de acordo com nossos “achismos” ou direcionamentos do cliente. O problema é que, no atual cenário tecnológico, onde tudo é muito versátil e ágil, é um risco muito grande nos basearmos em conceitos previamente construídos e não-validados. Para exemplificar, vou te contar uma situação que eu vivi há pouco tempo:
Estávamos aplicando um Design Sprint em uma grande empresa de bebidas na região de Campinas. Um dos problemas em foco era que os funcionários faziam muitas horas extras e os gerentes não tinham uma visão muito clara para acompanhamento e controle disso, o que poderia até acarretar em processos trabalhistas para a empresa. O ideal era que as equipes conseguissem produzir as bebidas dentro do limite de horas estabelecido.

Então, nossa equipe de designers projetou uma tela com o conceito de gamification, onde mostrávamos o total de horas extras realizado até o momento e o limite. Comparávamos o total de cada funcionário x o total da equipe x o total entre várias equipes. A ideia era engajar o funcionário de maneira que ele se sentisse responsável por não atingir o limite, e mobilizasse sua equipe também. As equipes que conseguissem ficar dentro do limite receberiam alguma gratificação da empresa, como brindes da marca.

Quando apresentamos esta ideia para o cliente, ouvimos feedbacks como:

  1. A ideia até que é legal, mas nossos funcionários são chão de fábrica. Eles não sabem o que é gamification.
  1. O funcionário não está preocupado com isso, ele só quer receber mais horas extras!
  1. Não precisamos envolver os funcionários, é responsabilidade do gerente acompanhar isso.

É importante ouvir o cliente. Ele é a pessoa que mais conhece seu usuário final. Porém, todas estas frases eram hipóteses, e tínhamos que validá-las, antes de abandonar qualquer ideia. Decidimos não retirar esta parte do protótipo e aplicamos um teste de usabilidade com os funcionários. A resposta foi surpreendente! Eles não somente entenderam muito bem o conceito, como também demonstraram interesse na “competição” com outras equipes para ficarem dentro do limite de horas. Através de um conceito muito simples, mostramos para o cliente que era possível mudar até o seu processo (isso vai além do software 🙂 ), uma vez que agora a responsabilidade de acompanhar este indicador seria compartilhada também com os próprios funcionários, além dos gerentes. Isso é transformação digital.

Por mais que tenhamos uma ideia do comportamento dos nossos usuários, o melhor jeito de descobrir se uma hipótese deve virar estória de backlog ou não, é testando-a diretamente com estas pessoas.

2. Não ignore a TI

Num processo criativo de uma solução, podemos ser tentados a envolver os sponsors do projeto que estão mais relacionados ao produto, como negócios, marketing, comercial, etc. Porém, é fundamental considerar fatores como viabilidade técnica, arquitetura, infra estrutura, sustentação, etc. Muitas vezes o cliente não tem consciência de quais áreas da sua estrutura devem ser envolvidas num design sprint, por exemplo. É nosso papel alertá-lo sobre isso, e envolver todas as áreas necessárias para criar uma solução simples e viável, sem deixar de lado a usabilidade.

Ok, mas…será que só isso já é suficiente?

Recentemente, aprendi uma lição relacionada a isso: estávamos rodando um Desing Sprint para desenvolver um aplicativo para alunos de um grande grupo de faculdades do Brasil. O app deveria refletir toda a vida acadêmica do aluno, tendo funções como grade de disciplinas, avisos da faculdade, notas, frequência, boletos, etc.

Solicitamos a participação de diversas áreas, incluindo a TI. No primeiro dia estava todo mundo lá e ficamos muito animados pois o cliente estava super engajado em montar a solução “à 4 mãos” com a gente. Mas ao longo dos dias, percebemos que a participação do grupo técnico foi se enfraquecendo. Eles ficavam na sala, mas quase não acompanhavam as dinâmicas e, por diversas vezes, saíam e demoravam pra voltar. Fizemos também uma dinâmica de Service Blueprint – que é de extrema importância para mapear as informações do app e quais suas fontes – integrações, APIs, serviços, etc, e também não sentimos o grupo técnico engajado como gostaríamos. Isso nos trouxe dor de cabeça, pois conceitos já validados com os usuários foram inviabilizados por questões técnicas em etapas posteriores.

Por que isso acontece? Talvez, por estarmos ainda no início do projeto, onde há muita indefinição. Ou ainda, por se tratar de uma fase de criação que tem “cara de design de interface” apenas, a TI não vê valor na sua participação.

Faz parte da empatia responsável mostrar para o cliente (seja qual for a área) o quão importante é o envolvimento de todos. Afinal não adianta nada desenharmos um aplicativo lindo que exibe informações valiosas aos usuários, mas que dependem de serviços que não existem e nem serão construídos.

3. Não abandone o produto após a entrega

Como você determina o sucesso ou não de um produto?

O Software Quality Consulting define como um projeto de sucesso aquele que  que foi entregue no prazo, custo e com as funcionalidades requeridas*. Será que é só isso? Você pode entregar uma funcionalidade no prazo, custo e qualidade requeridos, mas se ninguém usá-la, do que adianta?

O trabalho de um Product owner/manager não termina quando o produto foi entregue, pelo contrário! Meça! Compare, faça reajustes e meça novamente! Após disponibilizar um software ou aplicativo em produção, você deve ser capaz de responder perguntas como: quais as funcionalidades mais utilizadas? Quanto tempo o usuário leva para concluir principal função do sistema? Quantos desistem no meio do caminho? Qual a opinião dos meus usuários quanto ao sistema? Quantos voltam? Quantos indicam para outros? Dependendo ainda do tipo de software você ainda pode precisar saber índices como taxa de retenção, renovação, frequência de acesso, etc.

Ter empatia responsável também é cuidar para que sucesso de um produto perdure além do seu desenvolvimento, durante toda a sua vida útil.

*Fonte: http://www.swqual.com/verification_validation.html

4) Não limite as ideias, mas não queira começar pelo topo

“MVP” – este deve ser o termo mais citado nas negociações entre Product Owners x Clientes (risos)!  Quando o cliente quer investir em “ideias mirabolantes” e planos que vão “dominar o mundo”, tratamos logo de colocar os pés no chão com a velha frase: “vamos focar no MVP”. Não quero aqui questionar este conceito, acredito  muito nisso, na verdade. Porém, é um erro limar as ideias para sempre buscar o MVP, ou ainda, usar o backlog como um grande cemitério de ideias que nunca serão sequer priorizadas. Por outro lado, também é um erro começar de cara pela solução completa, antes de testá-la numa versão simplificada.

Também tenho um exemplo para isso 😉

Estávamos desenvolvendo um sistema de importação para uma startup. Uma parte deste sistema consistia num módulo de cotações de fretes internacionais. Imaginamos uma mega solução. O usuário importador forneceria todas as informações referentes a sua carga. Esta requisição apareceria num painel onde várias empresas de frete internacional poderiam acessar e responder com os valores da cotação daquele frete. O usuário então receberia estes valores e escolheria a empresa para realizar seu frete. Tudo isso e mais várias funcionalidades, como notificações, gamification, dashboards, indicadores, fluxo de estados, etc. Investimos tempo e esforço para desenvolver a primeira parte desta solução e decidimos validar com os clientes (ainda bem!).

O resultado não foi como esperado. A forma como havíamos enxergando não era como o mercado atuava. Apesar da nossa ideia ter sido muito legal, os usuários não queriam trabalhar desta forma. Eles preferiam comprar sempre com o mesmo fornecedor, porque era um risco enorme trocar devido a criticidade da carga se extraviar, mesmo tendo que pagar um valor maior no frete. Um dos nossos principais erros neste cenário foi querer desenvolver uma solução muito maior que um MVP, sem antes validá-la (mesmo tendo realizado a validação, já tínhamos feito um bom pedaço da solução).

Empatia responsável é também ajudar o cliente a encontrar um equilíbrio entre o mínimo e o máximo, entre o imprescindível e desejável.

Evellyn Zagui de Almeida

View posts by Evellyn Zagui de Almeida
Formada em tecnologia da informação pela Unicamp, atua há mais de 10 anos no mercado de TI. Iniciou sua carreira como desenvolvedora de software, passou pela área de qualidade e há 8 anos atua como Product Owner na Dextra. Também é instrutora de treinamentos (qualidade, automação, metodologias ágeis), além de escrever diversos artigos relacionados à relacionamento com o cliente e gerenciamento de produto, liderança, treinamentos, entre outros.

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

1 × um =

Posts relacionados

  1. Sobre a Dextra

    Somos especialistas em desenvolvimento de software sob medida para negócios digitais. Pioneiros na adoção de metodologias de gestão ágil, combinamos processos de design, UX, novas tecnologias e visão de negócio, desenvolvendo soluções que criam oportunidades para nossos clientes.

  2. Categorias

Scroll to top