Pessoa triste diante do notebook

O desastre de uma revisão mal feita

Quando eu trabalhava como gerente de projetos na empresa Menes LearnInsight, da querida Marta Enes (a qual me ensinou muito na minha trajetória), usávamos uma ferramenta de acompanhamento de projetos que controlava toda a produção a partir de uma ferramenta baseada na Extranet. Essa ferramenta era tão completa que eles chegaram a receber propostas para vender a própria ferramenta no mercado.

O que fazia essa ferramenta tão eficiente era justamente o processo de revisão do curso produzido, que era o mais automatizado possível. Ela funcionava da seguinte maneira, após a revisão do storyboard do curso, este era efetivamente produzido e liberado em link para revisão do cliente dentro da Extranet. O diferencial era justamente estar na Extranet, pois em cada tela do curso no link tinha um box posicionado no canto superior do monitor, com um campo de preenchimento e um botão ENVIAR. Ali, o cliente ia pontuando e enviando suas considerações durante toda sua revisão, tela por tela. Quando a revisão do cliente era concluída, automaticamente chegava um e-mail para o gerente na Menes, que acessava a Extranet numa visão GERENTE e abria ali uma página com todas as observações feitas pelo cliente identificadas por tela. Na visão do gerente, essa interface tinha um ComboBox com três opções, onde ele direcionava cada ajuste: design, programação ou conteúdo. Ao final da sua análise, ele clicava em ENVIAR e os itens eram direcionados para cada etapa da produção. A partir daí, cada etapa visualizava pela Extranet apenas os ajustes atribuídos a ela, mas com um botão de OK para cada ajuste. A medida que iam ajustando os itens da revisão, clicavam no OK e o item corrigido saía da relação. Sua revisão estava concluída quando a lista estava zerada. Após todas as etapas estarem concluídas na revisão, o gerente voltava à Extranet e, novamente, tinha uma nova visão do relatório. Agora com todos os itens da revisão corrigidos para sua revisão final. Nessa segunda visão, ao lado de cada item existiam dois novos botões: APROVADO ou REPROVADO/COMENTE. Novamente, os ajustes aprovados iam sumindo da lista e só ficavam os reprovados, que voltavam para cada etapa. A partir daquele momento, novamente, cada etapa tinha uma nova lista com os comentários do gerente para os ajustes que não foram feitos (ou foram feitos, mas não corretamente). A revisão só estaria fechada após todos os itens estarem zerados na visão do gerente e da equipe. Essa ferramenta possibilitava o erro ZERO no processo de revisão e garantia que tudo o que foi pedido pelo cliente na sua revisão estivesse feito! A segunda revisão do cliente era apenas para bater os ajustes pedidos por ele e nada novo era considerado. De lá, ia direto para o SCORM.

Depois que saí da Menes, eu não vi nenhuma ferramenta semelhante nas outras empresas que trabalhei.

Maaaaaaaaas, mesmo não tendo esse tipo de ferramenta na sua empresa, é possível sim também garantir erro ZERO nas suas revisões (ou quase ZERO). Primeiro, devemos respeitar as etapas! O processo de revisão ao longo da produção de cursos on-line é um dos pontos mais sensíveis no seu desenvolvimento como um todo. Na grande maioria dos casos, uma revisão mal feita é responsável por cronogramas estourados ou até prejuízos para empresa que produziu os cursos, por conta dos custos das idas e voltas de ajustes, até que o curso esteja finalizado corretamente.

Em seguida, o storyboard (ou roteiro, visual storyline…). Independentemente do nome dessa etapa, essa é (na minha visão) a mais importante no processo de produção. O storyboard apresentará a proposta de toda a nova organização pedagógica para o curso ser produzido (em tempo, não estou tirando a importância do projeto gráfico ou da programação no processo como um todo, mas não adianta nada desenvolvermos um curso lindo, interativo e de fácil navegabilidade, se o conceito apresentado está errado ou não está claro para o aluno). Não necessariamente o conteúdo base será reescrito do zero no momento do storyboard, mas ele será reorganizado a partir de uma nova linguagem e estrutura, considerando que o aluno não estará no presencial, e garantindo que os conceitos ali apresentados sejam entendidos da melhor maneira possível, sem a necessidade da presença de um professor para explicar novamente aqueles conceitos.

O curso só poderá ser produzido a partir do momento em que o storyboard estiver 100% validado pelo cliente (com o projeto gráfico). Mesmo que tenha tido várias idas e voltas na revisão, ele precisa estar totalmente validado para que siga na produção. Isso porque, geralmente, ele é feito em um arquivo power point (ou qualquer outro semelhante), que é muito mais fácil de ser alterado do que nas telas já produzidas no formato final.

Caso real, certa vez participei de um projeto que deu tudo errado por conta justamente da forma em que as revisões foram feitas. Foram dois momentos em que deram errado. Primeiro, foi quando enviamos o storyboard para revisão do cliente e, em menos de um dia, o ponto focal já mandou arquivo validado sem nenhum pedido de ajuste (quando isso acontece, muito provavelmente o cliente não entendeu a importância dessa etapa. Fato! É exatamente nesse momento em que erros precisam ser identificados). Voltamos ao cliente, informamos da importância do storyboard e perguntamos se ele queria revisar novamente o arquivo. “Não precisa!’, disse ele! “Está tudo ótimo e validado!”. Explicamos novamente o processo, mas mesmo assim ele insistiu que estava validado.

Bom, já que o cliente aprovou o storyboard, confirmando a validação por e-mail e tudo, seguimos com a produção.

Produção pronta, revisões internas feitas, ajustes necessários implementados… Link liberado para o cliente!

O mesmo ponto focal que validou o storyboard anteriormente, ligou informando que gostaria de passar os ajustes num conference call com a equipe. Bom, call feita, equipe anotou todos os pedidos de ajustes, o que representava uma “refação” de 40% do curso. QUARENTA PORCENTO!!! Isso porque nosso amigo validou o storyboard sem nenhuma consideração.

Naquele momento, já havíamos sinalizado para o dono da conta do cliente sobre o ocorrido e já sinalizamos que teríamos retrabalhos nessa produção.

Bom, naquele momento era importante registrar num e-mail tudo o que foi pedido e enviar para validação do cliente. Enviamos num tom mais de entendimento do que para nos resguardar: “Você poderia, por favor, verificar os pontos listados no e-mail e confirmar se entendemos corretamente tudo o que você pediu?”. A partir do OK para nosso e-mail, fizemos exatamente tudo o que foi pedido na revisão e, após o ponto focal validar o curso produzido, publicamos na plataforma e concluímos o projeto.

De repente, chega um e-mail da diretoria… O curso estava totalmente diferente do que eles esperavam para esse conteúdo. Detestaram o resultado final! Como tínhamos tudo registrado, todos os pedidos do ponto focal e, principalmente, a validação das mudanças pedidas, conseguimos reverter a situação… Um novo cronograma foi feito e nos foi autorizado emitir mais uma nota fiscal cobrando pelos 40% do conteúdo que seria refeito!

Várias lições foram aprendidas nessa confusão!

Primeiro, que nem sempre o cliente percebe a importância do storyboard. É essencial que isso seja esclarecido e que esse material seja efetivamente revisado por ele (quantas vezes forem necessárias).

Em outros momentos, esse cliente não consegue nem visualizar as propostas apresentadas no storyboard a partir um arquivo power point. Nesses casos, é importante elaborar um protótipo a partir das primeiras telas do curso, para que ele possa entender como será a navegabilidade e as interações do curso.

E depois, por mais burocrático que pareça, tenha tudo registrado. Qualquer vírgula que o cliente tenha pedido para mudar de lugar, precisa ter uma confirmação formal (mas sempre tratando com o cliente num tom positivo, nunca deixando claro que é para nos resguardar).

Enfim, mais uma vez a presença do gerente de projetos é de extrema importância para que problemas ao longo da produção sejam evitados e a relação com o cliente permaneça a mais saudável possível.

Compartilhar
foto do autor

Alexandre Collart

Atuou em projetos para clientes como White Martins, SulAmerica, Autotrac, TV Globo, Petrobras BR, Bob’s, Mongeral Aegon, Módulo Security, Universidade Candido Mendes, Telelistas, Brasil Brokers, Prudential, Wilson’s Sons, Souza Cruz, Honda Motos, Icatu Seguros, Furnas, TIM, Laboratórios Abbott, Sebrae/RJ, Fiocruz, Claro, entre outras. Aprendendo a cada projeto entregue, a cada metodologia utilizada e a cada acompanhamento com os clientes, resultando nos textos para este Blog.

SAIBA MAIS

Deixe um comentário

O seu endereço de email não será publicado. Campos obrigatórios marcados com *

whatsapp