PT: Gerir as expectativas do cliente e promover confiança

 
Managing clients' expectations.jpeg
 

Como gestores de produto, o nosso trabalho é definido de forma mais sucinta como o papel de facilitador: gentilmente desbloqueamos o fluxo de informações em diferentes direcções e apoiamos o trabalho de todos para entregar resultados de que nos orgulhamos.

Com tanta informação a fluir através de nós — dos nossos clientes para a nossa equipa, dos nossos utilizadores para o roadmap, da própria equipa de volta para os clientes — a confiança torna-se uma pedra basilar da nossa função.

Um gestor de produto confiável é alguém com quem a cliente e a equipa sentem que podem contar: para prazos prometidos, para sensatez, para tomada de decisão autónoma diariamente. E o nosso feedback tem muito peso, desde a próxima release até ao roadmap a longo prazo, desde budgets anuais até campanhas de marketing de milhares.

Espera-se que sejamos certeiros e claros. Mas o desenvolvimento de software é difuso:

É difícil prever o prazo para trabalho com que a equipa não está familiarizada; é mais difícil ainda prever se dependências externas vão entregar o prometido a tempo ou falhar por completo; mesmo para prazos imediatos, é difícil prever uma data para trabalho ainda em preparação (a ser desenvolvido ou até já em testes, mas nunca sabemos quando os testes vão detectar algo incontornável).

Portanto, quando o cliente pede um prazo, como podemos dar-lhes o que eles querem, mantendo-nos realistas e transparentes?

Recolher os factos, tornar o desconhecido em conhecido tanto quanto possível

Ninguém sabe o que precisa de ser feito como os teus colegas de equipa: afinal de contas são eles mesmos que estão a construir o que a equipa entrega. Pergunta-lhes abertamente o que precisas de saber: estás à procura de um prazo, ou de uma lista de dependências, ou de uma resposta clara de Sim/Não. Todos apreciamos ser informados dos detalhes de um problema para ajudarmos a resolvê-lo.

Se o trabalho tem dependências externas, relembra o responsável do scope das vossas necessidades e pede-lhes um prazo (de preferência faz isto por escrito: isto dá ao teu interlocutor uma checklist para o trabalho deles e serve de compromisso escrito para a entrega).

Nunca evites um “Não sei”

Tendemos a evitar esta resposta porque nos faz soar como se não tivéssemos controlo da situação, mas não só isso não é necessariamente verdade, como se for, pode ser contornado.

Se a questão é sobre algo que não sabes de cor, ou não sabes a resposta mas sabes como descobrir, podes pedir para revisitar o assunto mais tarde, dando um novo prazo. Basta algo como “Não sei de momento, mas tenho isto por escrito / mas discutimos isto por email, posso falar contigo daqui a uma hora?”. Isto compensa a ausência de resposta e define uma nova expectativa que podes cumprir. Só não te esqueças de cumprir o novo prazo 😜

Em contraste, se o assunto for o assunto da responsabilidade de outra pessoa (developers, testers, designers), podes dizer “não sei, este tópico está sob a alçada do X, mas posso arranjar-te uma resposta dentro de uma hora”. Este formato estabelece que: 1) há uma boa razão para não ser suposto saberes a resposta; 2) podes ser parte da solução mesmo não sendo parte do problema; 3) podes adiar o assunto para um momento em que o teu interlocutor vai receber a resposta.

Nunca prometas o imprevisível

Se um bloco de trabalho tem uma dependência externa, e o cliente pergunta quanto o trabalho pode ser entregue, evita falar em datas fixas se nem tu tens datas em que possas confiar. Menciona essa dependência e o prazo associado. Torna-se mais compreensível que não possas tranquilizar alguém com informações concretas se lhes explicares porquê.

Se te pressionarem para uma resposta, escolhe sempre o pior cenário possível

Se não tens os recursos para prever um prazo realista mas estão a pedir um ao teu cliente (ex.: um superior dele), podes jogar à defensiva e imaginar que todas as variáveis do teu fluxo de trabalho correm mal: a estimativa que a equipa providenciou é multiplicada por 1.5x, metade da equipa está indisponível, vão ter de re-escrever os testes, as dependências externas estão atrasadas pelo menos uma sprint, etc. Formula isto de forma clara: “Não consigo prever, mas no pior cenário o prazo seria X”. O cliente pode não gostar da resposta que lhes deste, mas é melhor prometer a menos e entregar a mais do que o contrário.

Ser pragmático e transparente ajuda a construir e manter confiança com os teus clientes e colegas de equipa, especialmente em situações difíceis.


Se quiseres falar mais sobre este post, manda-me um email ☺️