Dê um Feedback Melhor aos Seus Colegas (com Ryan Schaefer, da Viget)

Leia a transcrição:

Estamos a experimentar transcrever os nossos podcasts utilizando um programa de software. Perdoe quaisquer erros de digitação, pois o bot não está correto a 100% do tempo.

Ben Aston:

Bem-vindos ao podcast DPM, onde vamos além da teoria para dar conselhos que funcionam na liderança de melhores projetos digitais. Obrigado por nos acompanhar. Sou Ben Aston, fundador do The Digital Project Manager.

Então, como lida com a tarefa de dar feedback às pessoas da sua equipa? Aceita fazê-lo porque, bem, sabe que tem razão, é gestor de projeto, ou evita fazê-lo porque receia que não o levem a sério? Talvez receba feedback e pense que ninguém compreende realmente ou sequer ouviu o que disse. Mas, enquanto gestores de projeto, somos responsáveis por alcançar o sucesso, e isso é difícil quando as nossas equipas parecem tantas vezes estar a seguir pelo caminho errado.

Descubra, no podcast de hoje, algumas formas simples de dar feedback que ajudarão as suas equipas a produzir um trabalho melhor e a manter os seus projetos no caminho certo.

Hoje estou acompanhado por Ryan Schaefer. O Ryan passou da conceção e construção de websites para a gestão do seu desenvolvimento e trabalha em Washington, D.C., numa agência chamada Viget. Olá, Ryan.

Ryan Schaefer:

Olá, Ben. Obrigado pelo convite.

Ben Aston:

Muito bem. Ryan, conte-nos um pouco sobre a sua função atual. O que me interessa realmente é saber como fez a transição do design e desenvolvimento para a gestão de projetos. É uma pergunta que nos fazem frequentemente. O que faz neste momento? Dedica-se exclusivamente à gestão de projetos ou também se envolve um pouco nos pormenores?

Ryan Schaefer:

Diria que a função se aproxima mais da gestão de projetos a tempo inteiro, mas uma das coisas que certamente tornou mais fácil a transição da execução de tarefas de design e desenvolvimento para a gestão de projetos foi compreender todos os pensamentos e processos envolvidos nessas áreas.

Isso permite-me falar com os designers e programadores extremamente talentosos que temos aqui num plano de igualdade. Não preciso de perguntar o que significam as siglas, quais são as ferramentas ou coisas desse género.

Ben Aston:

Mas como aconteceu? Qual foi o momento decisivo em que disse: “Está decidido, vou ser gestor de projetos”?

Ryan Schaefer:

Teve um pouco que ver com querer gerir as coisas a partir de uma visão abrangente, em vez de trabalhar mais isoladamente. Mas diria que a principal razão foi querer juntar-me a uma empresa onde todos fossem apaixonados pelo digital e tivessem uma visão orientada para o futuro. O digital está obviamente a mudar a forma como vivemos enquanto civilização e, certamente, enquanto país. Estar rodeado de pessoas que viam isso, valorizavam-no e eram muito competentes nas suas respetivas áreas relacionadas com o digital era algo de que queria fazer parte. Em última análise, isso iria ajudar-me a crescer profissionalmente.

Ben Aston:

Muito bem. Conte-nos um pouco sobre o que está a fazer neste momento. Na Viget, como é essa função de gestor de projetos?

Ryan Schaefer:

Antes de mais, é Viget. Ouvimos isso muitas vezes.

Ben Aston:

Vid-get? Vig-et?

Ryan Schaefer:

Viget, sim.

Ben Aston:

Sabe, até fui ao website e cliquei num gato que dizia que se pronuncia Viget.

Ryan Schaefer:

Sim, há um botão para dizer olá. É Viget.

Ben Aston:

É isso que acontece quando se tem um nome engraçado. O que significa, afinal?

Ryan Schaefer:

“Florescemos juntos”, em latim.

Ben Aston:

Ah, claro.

Ryan Schaefer:

Algo desse género.

Ben Aston:

A minha mãe teria vergonha de mim. Mãe, desculpa. É professora de latim. Devia saber coisas dessas.

Ryan Schaefer:

O latim era a minha disciplina menos preferida no secundário. Éramos obrigados a estudá-lo. Não acredito que tivéssemos de o estudar, mas enfim.

Ben Aston:

Bem, preparou-o muito bem para todas as línguas que fala agora, não foi?

Ryan Schaefer:

Sim, exatamente.

O meu papel na Viget, enquanto gestor de projetos, engloba muitas coisas diferentes. Há, naturalmente, as responsabilidades fundamentais de um gestor de projetos, como cronogramas, orçamento, planeamento, formação das equipas e alocação de recursos. Também fazemos coisas mais específicas da gestão de produto. Não temos gestores de produto específicos, por isso os gestores de projeto são responsáveis por muitos percursos dos utilizadores, pela definição de funcionalidades, pelos testes de garantia de qualidade e por compreender profundamente as empresas com que trabalhamos e os produtos que estamos a construir.

Ben Aston:

Portanto, é gestão de projetos e gestão de produto?

Ryan Schaefer:

Sim, é uma mistura das duas coisas. Estão relacionadas e é vantajoso fazê-las em conjunto, mas também são suficientemente diferentes para ser uma boa mudança de ritmo quando se passa de trabalhar no projeto para gerir o projeto.

Ben Aston:

Pode contar-nos um pouco sobre algum dos projetos em que está a trabalhar neste momento?

Ryan Schaefer:

Passei recentemente a trabalhar a tempo inteiro num único projeto, algo que nunca me tinha acontecido. Estamos a trabalhar num grande website de marketing e num portal para diferentes grupos de público, que podem iniciar sessão e receber dados diferentes consoante o grupo a que pertencem.

Estamos essencialmente a refazer o ecossistema, a atualizar o design de todos os materiais digitais voltados para o público e a preparar um roteiro para produtos futuros, talvez uma aplicação ou algo semelhante. É um projeto muito envolvente e estou entusiasmado por me dedicar a um único projeto, conhecê-lo realmente bem e aprender mais sobre ele.

Ben Aston:

Falando da criação de uma aplicação nativa, sei que vai apresentar uma palestra no DPM Summit com dicas para gerir a criação de uma aplicação nativa. Pode dar-nos a versão resumida da sua apresentação? O que está a descobrir sobre a criação de aplicações nativas?

Ryan Schaefer:

A minha apresentação baseia-se no que aprendi durante o maior projeto em que participei aqui: um projeto de design e desenvolvimento de uma aplicação Android.

Vou falar sobre as diferenças entre gerir a criação de uma aplicação nativa e uma criação web mais comum, sobre as melhores práticas e sobre os requisitos técnicos específicos que um gestor de projetos precisa de conhecer.

Por exemplo, o custo de uma falha é muito elevado numa aplicação, porque esta pode bloquear. Num website, se ocorrer um erro, normalmente basta recarregar a página. Além disso, as linguagens utilizadas para escrever aplicações nativas não funcionam como o JavaScript utilizado nas aplicações web. É necessário resolver uma parte muito maior do problema. Existem também controlos do sistema e outras restrições, como as restrições de funcionamento offline. É preciso saber como a aplicação funciona sem ligação, como os botões de menu do telefone interagem com ela e para onde conduzem o utilizador.

Ben Aston:

Já trabalhou em aplicações web e, obviamente, em aplicações nativas. A tendência que eu vinha a observar era a de toda a gente criar aplicações web porque são mais fáceis e rápidas de desenvolver. Qual é a sua opinião sobre a evolução das aplicações web em comparação com as nativas?

Ryan Schaefer:

Uma das coisas interessantes que estamos a observar é o crescimento de ferramentas como Squarespace, Beams no WordPress e Weebly. São serviços muito utilitários que permitem a pessoas com conhecimentos técnicos limitados criar rapidamente websites com bom aspeto.

Por causa do baixo custo e da acessibilidade, é mais difícil encontrar projetos tradicionais de criação de websites de marketing. O desenvolvimento nativo ainda não se abriu verdadeiramente a esse tipo de solução, por isso vemos muito potencial nessa área. E também é divertido poder dizer que temos uma aplicação.

Ben Aston:

Então, Ryan, com todos os projetos em que está a trabalhar, quais são as ferramentas que fazem parte do seu conjunto de ferramentas de gestão de projetos?

Ryan Schaefer:

É importante começar bem. Gosto de facilitar reuniões de arranque de projetos com clientes. Uma reunião de visão é muito útil para falar sobre o que a organização faz atualmente, o que o produto faz e não faz e onde pretende chegar. Também gosto de realizar workshops sobre problemas, objetivos e metas, além de entrevistas com as partes interessadas.

Há muitas coisas que não é possível descobrir durante o processo comercial, por mais detalhado que este seja. Depois de compreender realmente tudo isso, entra-se no projeto com conhecimentos que permitem começar mais depressa, trabalhar de forma mais eficiente e, em última análise, entregar um produto final melhor.

Utilizamos ferramentas como Airtable, GitHub Projects, ZenHub e Trello, dependendo das preferências dos clientes e das nossas próprias recomendações.

Ben Aston:

Existem algumas ferramentas de gestão de projetos que tenha descoberto recentemente e que estejam a tornar a sua vida muito melhor?

Ryan Schaefer:

Passo algum tempo a aprender os atalhos do computador, porque são muitos e poupam segundos centenas de vezes por dia.

Ben Aston:

Qual foi o seu atalho preferido recentemente?

Ryan Schaefer:

Comando-Shift-T, que abre o separador fechado mais recentemente.

Ben Aston:

Boa.

Ryan Schaefer:

A nova ferramenta que estou a utilizar e que abriu muitas possibilidades é o Notion. É uma aplicação de espaço de trabalho que pode ser utilizada para notas e colaboração. Tem funcionalidades offline, uma interface limpa, permite incorporar conteúdos, criar menus expansíveis e organizar páginas dentro de subpáginas. Tem também aplicações web e móveis, por isso pode ser utilizada em qualquer lugar e é muito personalizável.

Ben Aston:

O que considera mais difícil no seu trabalho diário?

Ryan Schaefer:

Uma das maiores dificuldades é não ter tempo suficiente. Outra é mudar constantemente de contexto. Normalmente, um gestor de projetos trabalha em vários projetos e tem muitas reuniões no calendário. É preciso passar de uma reunião para outra e recuperar rapidamente todo o contexto do projeto seguinte. Para lidar com isso, tomo notas muito cuidadosas, preparo agendas para todas as reuniões e reservo algum tempo no início do dia para refletir sobre o estado de cada projeto.

Outra dificuldade é facilitar a colaboração entre designers e programadores. Muitas vezes, o designer cria uma composição visual excelente, mas é necessário que o programador analise o trabalho e ajude a documentar todas as funcionalidades e o funcionamento da área de administração. Estamos a explorar formas de utilizar o Airtable para estruturar o conteúdo e relacionar cada elemento dos desenhos, criando uma fonte de informação central para toda a equipa.

Ben Aston:

Vamos falar sobre o seu artigo, que aborda a forma de dar feedback de modo a beneficiar o projeto e entregar um produto ou projeto melhor.

Ryan Schaefer:

Acho que existem algumas razões para nos retrairmos. A primeira é humana: não queremos ofender os colegas nem desvalorizar o trabalho que fizeram. A outra é não nos sentirmos suficientemente confiantes para dar a nossa opinião a especialistas, como designers e programadores.

São preocupações razoáveis, mas, como gestor de projetos, está próximo do cliente e tem um olhar mais fresco do que alguém que esteve profundamente envolvido no trabalho. Pode simular melhor a perspetiva do utilizador final e oferecer uma perspetiva diferente sobre o trabalho.

Deve sentir-se confortável com esse tipo de conhecimento. Pode perguntar se o trabalho comunica claramente o que a organização faz, se é adequado ao público e se determinadas funcionalidades são evidentes. Esse tipo de reação ajuda a equipa a relacionar as decisões com o comportamento esperado dos utilizadores e com os objetivos do negócio.

Ben Aston:

No artigo, apresenta dez recomendações para dar um bom feedback. A primeira é preparar-se e obter informação suficiente a partir da perspetiva do sucesso do negócio. Como sabe quando está devidamente informado?

Ryan Schaefer:

Nunca se sabe verdadeiramente se se tem toda a informação, e isso é aceitável. As reuniões de visão são um bom ponto de partida, porque permitem compreender como a empresa se vê e onde quer chegar. Conversar com as partes interessadas executivas ajuda a perceber como tencionam concretizar essa visão. Depois, uma reunião de arranque com as pessoas diretamente envolvidas mostra como o projeto se relaciona com os objetivos empresariais mais amplos.

É um processo evolutivo que exige bastante investimento no início. Temos apostado muito nestas fases de descoberta, que ajudam a responder a estas perguntas, simplificam o processo e resultam num produto final melhor.

Ben Aston:

Também fala sobre se familiarizar com outras disciplinas. Como faz isso quando não domina completamente áreas como garantia de qualidade ou experiência do utilizador?

Ryan Schaefer:

É importante falar com o maior número possível de pessoas da equipa e reconhecer as lacunas no próprio conhecimento. Se alguém vem do desenvolvimento, não deve ter medo de acompanhar um especialista de experiência do utilizador e observar o seu trabalho.

Também é preciso praticar. Existem muitos recursos para começar a programar ou a desenhar. Pode inspirar-se em projetos da própria equipa, identificar tendências, ler artigos e dedicar algumas horas por semana a experimentar. Quanto mais tempo se trabalha no digital e se participa em reuniões, mais conhecimento se absorve naturalmente.

Ben Aston:

Como lida com situações em que as pessoas não levam a sua opinião a sério por ser apenas o gestor de projetos?

Ryan Schaefer:

Isso ainda não me aconteceu, felizmente. Parte deve-se às excelentes pessoas com quem trabalho, mas outra parte é abordar a questão a partir da perspetiva do cliente. A equipa respeita essa perspetiva, sobretudo quando se relaciona as decisões tomadas com os objetivos definidos e acordados no início.

Em vez de dizer “não gosto daquela cor”, é melhor perguntar se determinada cor está de acordo com as diretrizes da marca e se poderá afastar o público. O designer provavelmente já pensou nisso e terá uma justificação. Se a explicação fizer sentido para si, também fará sentido para o cliente. Se ainda não tiver pensado nisso, o feedback dá-lhe a oportunidade de rever a decisão ou fazer os ajustes necessários.

Ben Aston:

Como equilibra o chamado amor duro com um feedback construtivo, sem diluir a mensagem?

Ryan Schaefer:

Não é uma ciência e não existe uma fórmula com três passos. Enquanto gestor de projetos, provavelmente tem algum grau de inteligência emocional que lhe permite perceber e reagir à forma como as pessoas recebem o feedback.

O mais importante é ser específico. Não deve defender preferências subjetivas, mas decisões objetivas relacionadas com os objetivos do projeto. Deve também transmitir subtilmente que confia na capacidade da pessoa para concretizar o trabalho. Isso é encorajador, independentemente da forma como recebe a crítica construtiva.

Ben Aston:

Se alguém sente que a sua voz não conta, qual seria o primeiro passo que recomendaria?

Ryan Schaefer:

Quando vir algo que parece errado, seja um protótipo, um design ou outra coisa qualquer, não precisa de dar imediatamente a sua opinião. Reserve algum tempo, volte à sua secretária, analise o trabalho e tome notas. Identifique onde acha que o trabalho não corresponde ao objetivo e, sobretudo, apresente sugestões de melhoria.

Isso dá-lhe tempo para compreender o processo que a outra pessoa seguiu e permite-lhe preparar melhor os seus argumentos. Quanto mais cuidadoso e completo for, mais respeito obterá da equipa e mais abertura haverá para incorporar o feedback na próxima iteração.

Ben Aston:

Excelente conselho. Reservar tempo para avaliar por que motivo algo não parece correto e apresentar uma justificação é muito melhor do que dizer simplesmente “não gosto disso”. Podemos fazer perguntas, compreender o raciocínio de quem produziu o trabalho e propor soluções. Fazer esboços num quadro branco também pode ajudar, porque mostra que está a contribuir com ideias e não a tentar assumir o controlo do design.

Ryan, muito obrigado por se juntar a nós. Foi ótimo tê-lo connosco.

Ryan Schaefer:

Muito obrigado. Agradeço imenso.

Ben Aston:

Gostaria de saber o que pensa. Já tentou dar feedback? Como foi recebido? A equipa ficou aborrecida ou agradeceu ter chamado a atenção para algo em que ainda não tinha pensado?

Diga-nos o que pensa. Comente o artigo e visite thedigitalprojectmanager.com para juntar-se à nossa equipa no Slack. Encontrará todo o tipo de conversas interessantes sobre a entrega de projetos.

Se gostou do que ouviu hoje, subscreva o podcast e reserve alguns minutos para deixar uma avaliação honesta do podcast DPM na Apple Podcasts. Valorizamos muito as suas avaliações e comentários.

Até à próxima. Obrigado por nos ouvir.