Um guia prático para montar um sistema de gestão de projetos em torno de como a sua equipe realmente entrega o trabalho: por que as ferramentas genéricas de PM são ignoradas, como modelar suas etapas e passagens reais, o que a versão um precisa ter e como enxergar o trabalho em andamento sem reuniões de status.
Agências, times criativos, prestadores de serviço, times de produto e empresas de serviço cuja entrega não cabe em ferramentas de projeto prontas.
- Um modelo de projeto construído sobre as suas etapas de entrega e passagens reais
- Uma visão do trabalho em andamento que substitui a reunião de status
- Um sistema que você pode remodelar conforme o seu processo de entrega muda
A maioria das equipes já tentou uma ferramenta de gestão de projetos e acabou voltando para planilhas e chat. O problema não era a ferramenta; era o encaixe. Ferramentas genéricas de projeto impõem um formato, tarefas em colunas, e a sua entrega tem um formato próprio: suas etapas, suas aprovações, suas passagens. Quando a ferramenta não combina com a forma como você realmente entrega, atualizá-la vira trabalho burocrático e ela morre em silêncio. Este guia trata de montar uma que combine, para que ela pegue.
Porque elas impõem um formato genérico, em geral tarefas passando por colunas, e a sua entrega tem etapas, aprovações e passagens específicas que não se encaixam nele. Então as pessoas mantêm a ferramenta só por causa da gestão enquanto a coordenação de verdade acontece no chat, a ferramenta fica desatualizada e vira um segundo lugar para atualizar em vez do lugar para consultar. Um sistema de projeto só pega quando suas etapas são as suas etapas, nas suas palavras.
O sinal é conhecido: a ferramenta diz que um projeto está "em andamento" enquanto todo mundo sabe que na verdade ele está "esperando os arquivos do cliente", um estado que a ferramenta não tem nome para descrever. Cada estado que falta é uma pequena mentira, e um quadro cheio de pequenas mentiras é um quadro em que ninguém confia, então ninguém o mantém atualizado. A solução não é mais disciplina; é um sistema cujas etapas correspondem às reais, incluindo aqueles estados incômodos de espera onde o trabalho de fato empaca.
Por isso descrever a sua entrega e construir o sistema em torno dela supera configurar o modelo de outra pessoa. As etapas, os pontos de aprovação e as passagens são o produto, e são específicos de como você trabalha.
Antes de qualquer quadro, reconstitua como alguns projetos recentes de fato foram do início ao fim, incluindo onde travaram. Você está extraindo o formato da sua entrega.
Um estúdio de design vivia perdendo projetos no vão entre "enviado ao cliente" e "cliente respondeu", onde as coisas ficavam paradas por dias sem dono e sem relógio visível. Modelado com honestidade, o fluxo tinha oito etapas, três delas estados de espera, e o recurso decisivo foi simplesmente tornar os estados de espera visíveis com um relógio, de modo que um projeto travado em "aguardando retorno do cliente" por uma semana aparecesse em vermelho em vez de se esconder numa coluna genérica de "em andamento". Nada mais mudou, e a entrega no prazo disparou.
Ferramentas de projeto incham mais rápido do que quase qualquer outro tipo: controle de horas, faturamento, planejamento de recursos, portais de cliente, dependências. A versão um é a menor coisa que torna o trabalho visível e em movimento.
A reunião de status recorrente existe porque o status não está visível em lugar nenhum; as pessoas se reúnem para dizer em voz alta o que um bom sistema mostraria. O objetivo de um sistema de projeto é tornar essa reunião desnecessária, e não adicionar uma ferramenta sobre a qual você fala nela.
Você chega lá quando qualquer pessoa pode abrir uma visão e ver todos os projetos, sua etapa, seu dono e há quanto tempo estão parados. Etapas de espera com um relógio transformam travas silenciosas em travas visíveis; um projeto que está em "revisão do cliente" há oito dias aparece sozinho, e a conversa vira uma decisão em vez de uma descoberta. Quando o quadro é confiável e atual, a reunião encolhe para as poucas coisas que realmente precisam de discussão, e muitas vezes desaparece.
Manter o sistema confiável depende de duas coisas que vêm de ser dono dele: o quadro corresponde à realidade porque suas etapas são as reais, e ele continua correspondendo porque você mesmo pode mudar as etapas quando a sua entrega evolui. Um sistema de projeto construído em torno do seu fluxo de trabalho, que você pode remodelar sem um chamado de engenharia, é um sistema que a sua equipe mantém atualizado, porque ele finalmente está dizendo a verdade sobre o trabalho.
Porque a ferramenta impõe um formato genérico, em geral tarefas em colunas, que não combina com as suas etapas de entrega, aprovações e passagens reais. As pessoas a mantêm por causa da gestão enquanto a coordenação de verdade fica no chat, então ela fica desatualizada. Um sistema pega quando suas etapas são as reais, incluindo os estados de espera onde o trabalho de fato empaca.
Reconstitua como alguns projetos recentes de fato andaram, incluindo onde travaram, e dê nome às etapas reais nas suas palavras: briefado, em design, revisão do cliente, ajustes, aprovado e assim por diante. O mais importante é incluir os estados de espera como "aguardando retorno do cliente", porque é aí que o trabalho se esconde nas ferramentas genéricas.
Projetos ocupando uma etapa real e clara, um dono para cada projeto e etapa, uma única visão de todo o trabalho em andamento por etapa e passagens explícitas para que o próximo dono saiba sem uma mensagem no chat. Controle de horas, faturamento e dependências podem esperar pela versão dois.
Em grande parte, sim. A reunião existe porque o status não está visível em lugar nenhum. Quando uma visão confiável mostra todos os projetos, sua etapa, seu dono e há quanto tempo estão parados, com um relógio nas etapas de espera, a parte de descoberta da reunião desaparece e sobram apenas as decisões reais. O quadro precisa estar atual e verdadeiro, o que vem de você mesmo ser dono e dar forma a ele.