Como otimizar o seu processo com a gestão de fluxos de trabalho (com Marc Boscher, da Unito)

Leia a transcrição:

Estamos a experimentar transcrever os nossos podcasts através de um programa de software. Pedimos desculpa por quaisquer erros tipográficos, uma vez que o bot não está correto 100% das vezes.

Ben Aston:

Perde imenso tempo a tentar encontrar a informação de que precisa? Tenho a certeza de que sim. E, além disso, enquanto pessoa que gere outras pessoas, ver a sua equipa a tentar passar horas à procura de informação é incrivelmente frustrante. A realidade é que não existe um sistema de gestão de fluxos de trabalho único que sirva para todos. Embora a sua equipa de UX e estratégia possa gostar de utilizar o Trello ou o Asana, quando chega aos programadores, estes vão invariavelmente querer utilizar o JIRA. Então, como é que gere esta confusão? Como decide quem ganha? Na verdade, houve um relatório da McKinsey que observou que a maioria dos colaboradores passa cerca de oito horas por semana apenas a tentar encontrar informação.

A boa notícia é que existe uma forma de resolver este problema, e essa solução é um sistema de gestão de fluxos de trabalho. Por isso, se estiver interessado em poupar tempo para si, para a sua equipa e para o seu orçamento, continue a ouvir o podcast de hoje. Vamos falar sobre a criação e otimização de um sistema de gestão de fluxos de trabalho. Obrigado por nos acompanhar. O meu nome é Ben Aston. Sou gestor de projetos digitais e fundador do thedigitalprojectmanager.com. Estamos empenhados em ajudar os gestores de projetos digitais a entregarem melhores resultados e a ajudar as pessoas que gerem projetos no mundo digital a terem sucesso.

Se quiser entrar em contacto com a nossa comunidade, visite o site the digital project manager ponto com, onde encontrará muitos recursos para desenvolver competências, ganhar confiança e começar a entregar projetos melhores. Hoje estou acompanhado por Marc Boscher. Marc é um programador web que se tornou especialista de produto e é agora CEO e fundador da Unito. Marc, bem-vindo ao podcast.

Marc Boscher:

Obrigado pelo convite.

Ben Aston:

Conte-nos um pouco desta história. Como é que passou de programador web a gestor de projetos, depois a especialista de produto e, finalmente, a fundador da sua própria empresa? Fale-nos um pouco dessa evolução.

Marc Boscher:

Bem, demorou alguns anos, penso eu. Comecei durante a bolha das empresas dotcom e as coisas avançavam muito depressa. Fui atraído pela tecnologia e depois pelo produto. Basicamente, trabalho com produtos há 20 anos. Quando se trabalha com produto, acontece algo muito interessante: observam-se problemas constantemente e pensa-se sempre que alguém devia resolvê-los, mas nunca se chega realmente a fazê-lo. Continuei, no entanto, a manter uma lista e, basicamente, a Unito nasceu de um desses problemas que observava regularmente.

Ben Aston:

Quando diz que trabalha com produto há 20 anos, a Unito começou como um produto relativamente recente. De onde veio a inspiração para desenvolver especificamente uma solução para esse problema?

Marc Boscher:

Na gestão de produtos e, até certo ponto, também na gestão de projetos, temos de trabalhar com muitas equipas, grupos e conjuntos de competências diferentes, e raramente temos autoridade. Normalmente, essas pessoas não são nossas subordinadas. Temos de gerir através da influência. Isso significa que não somos nós que decidimos que ferramentas vão utilizar. Muitas vezes, acabamos por estar sujeitos à combinação de ferramentas utilizada por cada uma das equipas com que temos de trabalhar. Eu dava por mim constantemente a saltar entre Zendesk, Asana, JIRA, GitHub e todas essas ferramentas, pagando o preço dessa fragmentação.

Foi um daqueles momentos em que pensei: alguém devia resolver isto. Normalmente, resolve-se obrigando toda a gente a utilizar a mesma ferramenta. Mas, à medida que as API evoluíram, surgiu a ideia: será que podemos ligar estas ferramentas? Será que podemos deixar as pessoas trabalhar na ferramenta que já utilizam e evitar que os gestores de projetos percam todo este tempo a correr de um lado para o outro, a perguntar se as tarefas estão concluídas e em que ponto se encontram, ou a avisar que alguém está atrasado e que isso tem impacto noutra pessoa? A ideia cresceu de forma muito orgânica, como uma tentativa de resolver um problema próprio. Já estava nos planos criar algo, experimentar e arriscar. Quando começou a ganhar alguma adesão, decidimos avançar. E aqui estamos hoje.

Ben Aston:

E que conjunto de ferramentas integra internamente? Sei que é possível ligar ferramentas e software de gestão de projetos, como o Trello, o Asana e o JIRA. Quais são as ferramentas que prefere ligar e como funciona esse processo?

Marc Boscher:

Pessoalmente, sou um apaixonado por ferramentas, por isso utilizo praticamente todas. É muito entusiasmante descobrir uma solução que se adapta à forma como pensamos e ao nosso papel. Ganhamos muito em termos de produtividade, mas muitas vezes a verdadeira barreira é convencer as outras pessoas a mudar para essa ferramenta.

Penso que grande parte da resistência à adoção de tecnologia atualmente tem menos que ver com a parte técnica, como instalar ou implementar o software, e muito mais com conseguir que as pessoas o utilizem. Temos atualmente uma dúzia de ferramentas. Lançámos a integração com o ClickUp há algumas semanas, vamos lançar outra na próxima semana e mais uma dentro de três ou quatro semanas. Estamos a criar integrações para ferramentas utilizadas na gestão do trabalho de projetos: Asana, Wrike e Trello. Também começámos com ferramentas para programadores, como GitHub, Bitbucket, GitLab e JIRA, concentrando-nos em ligar gestores de projetos a equipas técnicas, ou utilizadores empresariais a equipas técnicas, que normalmente não falam a mesma linguagem nem utilizam as mesmas ferramentas.

Com o tempo, adicionámos o Zendesk, para sistemas de suporte, o HubSpot, para vendas e CRM, e ferramentas de marketing. A questão é perceber como podemos começar a olhar para o trabalho não apenas como algo que acontece dentro de uma equipa, mas como um processo que atravessa toda a organização. Esse é um problema muito maior e mais importante, no qual se gasta e desperdiça imenso tempo .

Ben Aston:

Como apaixonado por ferramentas, descobriu recentemente alguma ferramenta nova que o tenha entusiasmado e que considere que todos deveriam ter?

Marc Boscher:

Todas as ferramentas que integramos estão entre as melhores do mercado. No entanto, gostamos de pensar que não existe uma única ferramenta melhor para todas as pessoas. Tudo depende do que se pretende alcançar, de quem somos e da forma como trabalhamos. Essa é uma convicção central. Não recomendo uma ferramenta em detrimento de outra; depende sempre da situação. A tese central do negócio é que cada pessoa tem a sua ferramenta, aquela que a torna mais produtiva. O desafio é que essa ferramenta nunca é igual para todos. Todos os dias surgem novas ferramentas. Tendemos a escolher as mais populares, promissoras e em crescimento. Naturalmente, também precisam de ter uma camada de API para poderem ser integradas. Atualmente, a maioria das ferramentas dispõe desse componente e dessa visão de ecossistema.

Ben Aston:

O Marc escreveu um artigo que pode consultar em thedigitalprojectmanager.com, intitulado Como criar um sistema de gestão de fluxos de trabalho. Há alguns exemplos nesse artigo. Para quem ainda não o leu, pode explicar-nos melhor o que entende por gestão de fluxos de trabalho? Como gestores de projetos, compreendemos que os processos representam a forma como passamos do ponto A ao ponto B: o ponto A é o início dos projetos, o ponto B é o final e existem várias etapas pelo caminho.

Marc Boscher:

É muito semelhante ao processo a que estamos habituados. As pessoas utilizam frequentemente os termos fluxos de trabalho e processos de forma intercambiável. Gostamos de pensar nos processos como sequências relativamente lineares, passo a passo. É assim que pensamos naturalmente. Quando planeamos projetos, começamos frequentemente por dizer: primeiro é necessário fazer isto, depois aquilo e, em seguida, outra coisa. Depois, a realidade intervém.

Quando as pessoas começam a trabalhar, descobrem coisas, têm de colaborar entre equipas e alguém precisa de participar num ambiente muito dinâmico, especialmente no trabalho digital atual. Já não é tão linear nem tão específico, e torna-se muito menos previsível. Podemos ter um processo de desenvolvimento de software, um processo de gestão de campanhas de marketing, um processo de lançamento de produto ou um processo de vendas. Cada equipa tem de definir o seu processo e existem muitos modelos para o fazer.

Mas, quando começamos a colaborar para além dessas fronteiras, há muito menos estrutura. Passa a haver mais reuniões, chamadas Zoom e conversas por chat, e menos utilização das ferramentas que nos permitem gerir o trabalho e acompanhar a execução e a entrega. Quando falamos de gestão de fluxos de trabalho, referimo-nos a uma camada que liga tudo entre si, atravessando todos esses processos e garantindo que tudo é acompanhado corretamente.

Ben Aston:

Se dissermos que um sistema de gestão de fluxos de trabalho tem em conta cenários do tipo “se isto acontecer, então faça aquilo”, a realidade é que o percurso de A a B num projeto nunca é uma linha reta. É normalmente uma série de ciclos e desvios. Precisamos de uma forma de gerir essas situações. Sabemos que, quando apresentamos a experiência do utilizador ao cliente, também podemos estar a desenvolver os elementos visuais. O que acontece quando a experiência do utilizador é aprovada, mas esses elementos não são? Como mantemos o projeto em movimento e garantimos que as pessoas certas estão ligadas e atualizadas, para que o desenvolvimento possa começar? Uma compreensão mais complexa e detalhada pode ajudar-nos a ser mais eficientes na entrega de projetos, porque deixamos de pensar neles como processos lineares e passamos a vê-los como uma série de pequenos ciclos integrados.

Marc Boscher:

Exatamente. Estamos a aplicar muitos dos princípios ágeis: não tentar controlar tudo, dar mais liberdade às pessoas para colaborarem, remover obstáculos à colaboração e trabalhar em ciclos curtos. Atualmente, as ferramentas podem dificultar tudo isto porque cada pessoa utiliza uma ferramenta e um processo diferentes. O primeiro passo da gestão de fluxos de trabalho é ir até ao local onde o trabalho acontece — aceitar que as pessoas trabalham em locais diferentes e ir até lá.

O primeiro passo é integrar as ferramentas onde o trabalho acontece. O segundo é mapear o fluxo de trabalho entre essas ferramentas e definir as regras e orientações. Por exemplo, perceber como o marketing trabalha com o desenvolvimento, ou quando uma funcionalidade precisa de envolver os designers, os gestores de produto e os programadores. Não se trata necessariamente de limitar as pessoas, mas de abrir caminhos para que possam colaborar a partir das suas próprias ferramentas sem terem de as abandonar.

Um exemplo simples seria ter o plano do projeto num gráfico de Gantt, numa ferramenta como o Wrike ou o Asana, e uma atividade que tenha de ser realizada pelos programadores. Essa atividade transforma-se automaticamente num problema no JIRA, mantendo-se sincronizada com esse problema. Quando alguém é atribuído à tarefa, o trabalho começa, é incluído num sprint e avança pelo ciclo de desenvolvimento. O gestor de projetos fica a saber, em tempo real, o que está a acontecer no seu próprio sistema.

Marc Boscher:

Também consegue ver as dependências com outros departamentos, equipas ou atividades sem ter de saltar entre ferramentas. O primeiro passo é reconhecer onde o trabalho acontece. Depois, ligamos tudo e definimos as regras: sempre que algo acontece neste projeto, quero vê-lo no meu plano do projeto. Quando isso é feito, as pessoas não precisam de abandonar as suas ferramentas. Toda a informação fica acessível onde quer que estejam. De repente, a colaboração torna-se mais rica e tem menos fricção. É aí que podemos começar a otimizar e a melhorar.

Ben Aston:

Cada equipa vai querer trabalhar com ferramentas diferentes. É provável que a sua equipa de design e UX não queira trabalhar no JIRA, porque pode ser muito complexo. A vantagem de uma ferramenta como a Unito é permitir que cada pessoa trabalhe na ferramenta que melhor se adapta às suas necessidades. É um desafio constante encontrar uma única ferramenta que faça tudo da forma pretendida.

Cada ferramenta tem uma filosofia própria sobre a gestão de projetos. Dependendo dessa filosofia, torna-se mais fácil ou mais difícil para diferentes equipas dentro da organização colaborarem e trabalharem em conjunto. Já tentei fazer com que equipas de design trabalhassem no JIRA e foi imediatamente rejeitado, especialmente quando se cria um fluxo de trabalho complexo.

Como se extrai então esse processo e decide o grau de complexidade do sistema de fluxos de trabalho? Pode explicar-nos o processo de conceção de fluxos de trabalho? Como se introduzem verificações, equilíbrios e automatizações sem tornar o sistema demasiado complexo?

Marc Boscher:

Desde o primeiro dia, o nosso objetivo foi permitir que os utilizadores empresariais configurassem tudo por si próprios. Isto é essencial, porque, se quiser ligar duas equipas, não pode exigir conhecimentos técnicos nem esperar que um programador configure a integração. Trata-se de criar visualmente as regras e especificar, em linguagem natural, que quando algo acontece deve aparecer na equipa de engenharia.

Também é importante mapear processos com diferentes níveis de detalhe. No desenvolvimento de software, pode haver etapas como testes de qualidade, revisão pelos pares e passagem para ambiente de teste. No marketing, talvez apenas interesse saber se uma funcionalidade está pronta para ser lançada. Não é necessário acompanhar todos os detalhes do processo de engenharia.

O sistema deve permitir dizer: este é o meu processo de marketing; como é que as suas etapas correspondem às etapas da engenharia? Não têm de corresponder uma a uma. Dez etapas detalhadas de engenharia podem simplesmente aparecer como “em desenvolvimento” para a equipa de marketing.

Começa-se por uma conversa sobre a forma como cada equipa trabalha e sobre como juntar esses processos. Depois, os utilizadores empresariais podem configurar essa relação e melhorá-la gradualmente. Não é necessário definir tudo de uma só vez. Pode começar com regras simples: sempre que atribuo algo ao Ben, deve aparecer na ferramenta dele; sempre que encaminho um pedido para a engenharia a partir do sistema de suporte, deve aparecer neste projeto do JIRA. Depois de observar o fluxo de informação, pode avançar para um nível maior de sofisticação e poupança de tempo.

Ben Aston:

Para facilitar essa conversa entre equipas diferentes, que trabalham em ferramentas diferentes e precisam de compreender quem necessita de quê, quando e em que formato, recomenda começar por desenhar tudo num quadro ou diretamente na ferramenta?

Marc Boscher:

Vimos clientes a desenhar os processos e a utilizar quadros brancos. Por isso, criámos uma função diretamente na ferramenta que permite mapear visualmente onde o trabalho acontece e orientar o fluxo de trabalho. A conversa que descreveu é essencial. Os clientes conhecem muito bem os processos das suas equipas. No entanto, quando falamos de colaboração entre equipas, muitas vezes não sabem como as outras pessoas trabalham. Os gestores de projetos conhecem bem esta realidade, porque vivem constantemente nessas fronteiras.

Em vez de os gestores de projetos passarem o tempo a traduzir, copiar, colar e repetir informação, as ferramentas poderiam deixar de ser um obstáculo. A comunicação poderia fluir diretamente e os gestores de projetos poderiam concentrar-se no que fazem melhor: alinhar pessoas, acompanhar riscos, reduzir riscos e definir prioridades, sem o trabalho burocrático de manter todos informados.

Ben Aston:

Muito do tempo e do orçamento de gestão é gasto a garantir que as pessoas sabem aquilo que deveriam saber e que leram o pedido que chegou à sua caixa ou viram que algo foi atualizado no Trello. É importante reconhecer que cada pessoa trabalha de forma diferente e acomodar essa realidade: se alguém quer trabalhar no Trello, a informação deve estar no Trello; se quer receber um problema no JIRA, devemos tornar isso possível.

Mas falemos sobre quando o sistema falha. Quais são os desafios? Podemos começar a acreditar que o fluxo de trabalho é a solução para todos os problemas, mas, quando há muitas coisas a acontecer em vários locais, continuam a existir falhas entre as partes. Que desafios encontrou na utilização de um sistema de gestão de fluxos de trabalho?

Marc Boscher:

A comunicação é sempre fundamental, tenha ou não um sistema que ajude a integrar duas equipas. Quando tornamos a comunicação mais fácil, as pessoas podem utilizar as ferramentas que já usam diariamente para trabalhar, comunicar e colaborar com pessoas que não estão na mesma ferramenta. O requisito de comunicação continua a existir, mas torna-se mais simples.

Pense numa orquestra. Existem vários músicos e cada um tem o seu instrumento ou ferramenta. Os violinos estão no Trello e o piano está no JIRA. Há alguém, normalmente o gestor de projetos, que tenta mantê-los sincronizados e coordenados. Não vai obrigá-los a trocar todos para violinos, porque a força está precisamente no facto de cada um ter o seu próprio instrumento.

O gestor de projetos tem ferramentas limitadas e tenta orientar o grupo através do processo. Cada pessoa é independente, tem a sua forma de tocar e precisa de contribuir em conjunto. A gestão de projetos digitais moderna é muito semelhante. O gestor de projetos conduz e orienta um grupo autónomo. O objetivo é reuni-los e mantê-los em harmonia.

O primeiro requisito é garantir que todos conseguem ver o maestro e que conseguem ver-se uns aos outros. Atualmente, cada pessoa está na sua própria caixa e, no trabalho remoto, isso é ainda mais difícil. A orquestra está espalhada pelo mundo, existem atrasos e diferenças horárias, e manter a harmonia torna-se muito mais difícil. Uma solução de gestão de fluxos de trabalho funciona como a coordenação dessas pessoas, sem obrigá-las a mudar a forma como trabalham ou as ferramentas que utilizam.

Ben Aston:

Como vê a evolução do futuro do trabalho, dos projetos e da sua ferramenta? E como vê a evolução do papel do gestor de projetos?

Marc Boscher:

Esperemos que os gestores de projetos passem menos tempo em tarefas burocráticas e mais tempo a conduzir. A tendência para utilizar cada vez mais ferramentas vai continuar, porque é barato criar software, é fácil distribuí-lo e é simples para as pessoas adotá-lo. Temos de ir até onde as pessoas trabalham e aceitar essa realidade em vez de lutar contra ela.

Mesmo quando permitimos que as equipas se organizem de forma autónoma, continuamos a ter de as alinhar e manter sincronizadas. Uma camada de gestão de fluxos de trabalho que ligue tudo funciona como uma espécie de cola. De repente, temos muito mais visibilidade sobre o que está a acontecer.

Não acreditamos num futuro em que alguém tenha de perder e mudar para outra ferramenta. Acreditamos num futuro em que as ferramentas funcionam juntas de forma integrada. Esperamos ser essa plataforma, ou contribuir para que a gestão de fluxos de trabalho seja a plataforma que torna isso possível.

Ben Aston:

Se alguém está a começar a pensar em processos e gestão de fluxos de trabalho, especialmente numa agência ou estúdio com cinco a dez pessoas, por onde deve começar a conceção do processo e a otimização do fluxo de trabalho?

Marc Boscher:

Existem sempre oportunidades fáceis de aproveitar. A barreira de entrada é muito mais baixa do que pensamos. Cada cliente tem a sua própria forma de se organizar e, frequentemente, uma agência mais pequena tem de se adaptar às ferramentas utilizadas pelo cliente. Isso significa perder muito tempo a reaprender ferramentas e adaptar-se aos processos dos clientes.

Comece por um projeto. Descubra que ferramenta o cliente utiliza e qual seria a sua ferramenta ideal. Se conseguir utilizar essa mesma ferramenta, pode começar a repetir o processo. Se conseguir manter uma única ferramenta interna para entregar os projetos da agência, da próxima vez que surgir um cliente com outra ferramenta, experimente ligar as duas no fluxo de trabalho.

Não é necessário substituir tudo nem realizar muito trabalho inicial. Pode experimentar com uma equipa pequena, um projeto ou um único fluxo de trabalho. Pode começar por uma situação específica: como fazer com que o marketing envie um pedido de alteração à equipa de engenharia do site? Ou como fazer com que o suporte encaminhe um pedido para a engenharia? Comece pelo ponto onde está a gastar mais tempo e avance a partir daí.

Ben Aston:

Um pensamento mais ágil permite criar testes e aprender. Não acertamos à primeira. Encontrar oportunidades para criar processos onde eles não existem é um excelente ponto de partida. Podemos analisar as lições aprendidas do último projeto: onde correu mal, onde as coisas se desmoronaram e porquê? Porque é que o design começou duas semanas mais tarde? Porque é que o desenvolvimento começou demasiado cedo?

A partir dessas lições, podemos começar a conceber processos. Criamos o processo, mapeamo-lo, testamo-lo e aprendemos o que funciona e o que não funciona. Esta pode ser uma excelente primeira etapa para conceber e otimizar o nosso processo. Marc, muito obrigado por se juntar a nós hoje. Foi um prazer tê-lo connosco.

Marc Boscher:

Obrigado, Ben.

Ben Aston:

Se quiser saber mais e avançar na conceção dos seus processos de gestão de projetos, visite thedigitalprojectmanager.com. Encontrará muitos recursos úteis, incluindo a nossa formação online para membros. Até à próxima. Obrigado por ouvir.