Desde quando você pode obter mais final do que o final? A resposta é você não deveria ser capaz de ir além do “final”. Mas de alguma forma, nós parecemos querer desafiar essas regras e, ao fazê-lo, criamos uma espécie estranha de frustração para nós mesmos. É o arquivo que diz “final” o que devo usar? Ou será que existe, de alguma forma, uma versão mais recente que nós não sabemos?

Em vez de ser capaz de confiar em nossas convenções de nomenclatura, temos que perguntar por aí para ter certeza de que estamos usando a mais recente versão do arquivo. Ou, assumimos que estamos e descobrimos mais tarde que aparentemente estávamos enganados. Muitas vezes gostamos de culpar nossos stakeholders por essa frustração??, afinal, é culpa deles por pedir-nos para mudar as coisas depois que já fizemos 17 iterações, certo? Talvez eles sejam parte do problema. Mas talvez seja hora de fazer uma pausa para considerar se essa frustração particular existe em virtude de um problema maior – um que se estende muito além de uma compreensão inadequada do verdadeiro significado da palavra “final” ou stakeholders/clientes que podem ou não pode quererem nos sabotar.

O verdadeiro problema

Sempre que você ouvir a pergunta: “Este é o final-definitivo?“, talvez o que você devesse ouvir fosse: “Precisamos de ajuda com os nossos processos de aprovação“. Se revisões e aprovações estão funcionando bem em seu departamento, você nunca vai ter que verificar se algo é “final-final” antes de avançar com um trabalho. Se você tiver, então seus processos de aprovação estão, provavelmente, causando adiamento de datas, fazendo o projeto demorar mais tempo que o esperado, e gerando uma quantidade frustrante de retrabalho, o que pode acabar desperdiçando de 25 a 40 por cento dos seus gastos para o projeto.

“Final” não deve ser um jogo de “Escolha uma versão”

Ninguém se beneficia em um ambiente onde “final” não significa que o que deveria. Eis algumas dicas rápidas sobre como corrigir os processos de aprovação e manter as coisas dentro do cronograma:

– Identifique os “aprovadores” desde o início – Certifique-se de cada aprovador e / ou stakeholder esteja ciente do seu papel no fluxo de trabalho, do rascunho inicial até a entrega final. Todos devem saber os passos corretos que precisam ser dados e quem notificar em cada momento.

2 – Gerencie as expectativas dos stakeholders – Retrabalho, por vezes, tem pouco a ver com a qualidade do trabalho e muito a ver com o trabalho que não satisfaz as expectativas dos stakeholders. E as expectativas às vezes podem ser difíceis de gerenciar, porque a) elas estão sujeitos a alterações a qualquer momento, e, b) nem sempre são comunicadas corretamente. Para combater isso, sempre apresente rascunhos, até mesmo para os seus pequenos projetos. Mantenha estes rascunhos breves, mas certifique-se de fazer as perguntas certas para pedir aos clientes / stakeholders para validarem o caminho que você está adotando e para partilhar as suas expectativas. Você também pode precisar marcar uma reunião de 15 minutos com eles no início do projeto para saber o que, exatamente, eles estão procurando em seu produto final. Quanto mais você entender à frente, menos você vai ficar fazendo revisões.

3 - Defina “final” com antecedência – o que  ”final” deve significar para sua equipe? Será que isso significa que um trabalho foi aprovado por todos os stakeholders? Isso significa que um trabalho foi aprovado pelo cliente ou solicitante e eles têm a palavra final? Conseguir uma definição nítida e implementar nomes de arquivos padrão e locais dedicados para versões finais ajudará a eliminar ter 10 ou mais versões “finais” de um ativo de marketing. Ninguém deve nomear um arquivo de “final”, até que eles saibam que foi aprovado por todas as partes relevantes.

Autora: Raechel Duplain