Script
Olá pessoal, Fabio Akita
HOJE quero tocar no assunto sobre projetos. Em particular sobre a importância de entender o que significa priorizar as coisas e o processo de gerenciar um projeto Não tem nada tão complexo que requer uma pós-graduação no assunto. Qualquer um pode entender os conceitos básicos e como um conceito naturalmente leva ao próximo.
Em outros episódios vou entrar em mais detalhes sobre cada um desse conceitos, mas hoje quero só mostrar a linha de raciocínio geral que você podem levar para qualquer projeto, pequeno ou grande, basta expandir as premissas que vou mostrar hoje.
...
Um dos problemas mais frequentes que eu vejo é a surpreendente capacidade das pessoas de fugir da priorização. Parece medo de priorizar. E não é difícil de entender porque.
O modo mais normal das pessoas é: "vou fazendo, uma hora dá certo". Ou pior: "eu não escolho o que fazer, alguém escolhe por mim, e eu só vou fazendo".
A molecada é muito ligeira pra postar no Twitter como a gerência do projeto ou da empresa é ruim. Mas eu pergunto: quantos desses já assumiram de fato o bastão da responsabilidade pra criticar com tanta confiança? É muito fácil se esconder na anonimidade da internet. Difícil é executar e mostrar resultado. Nunca ouça ninguém que não tem resultados mensuráveis pra mostrar.
Você não precisa ser um MBA ou um "Certified Scrum Master" ... pra entender esses conceitos, porque eles são meio triviais na verdade.
Primeiro entenda uma verdade absoluta: você não tem tempo infinito. Sua vida não é infinita, uma coisa que temos em comum é que um dia vamos morrer. Se fôssemos imortais, priorizar seria irrelevante já que poderíamos realmente fazer o que quiser, quando quiser.
No mundo real, tudo é finito. Tempo é a primeira coisa finita. Segundo são recursos, dinheiro, pessoas, materiais. É finito, é restrito e normalmente é pouco. Sua expectativa é investir 1 unidade de recurso pra no futuro conseguir recuperar 2 ou 3. Sim, retorno. Senão você estaria simplesmente jogando recursos fora. Por exemplo, eu costumo dizer que o objetivo de qualquer Product Owner é a responsabilidade sobre o retorno do investimento. Na verdade, eu diria que o objetivo de qualquer profissional é o retorno de investimento sobre seu trabalho, senão pra que você trabalha?
Sendo tempo e dinheiro coisas finitas, você precisa Escolher o que fazer. A primeira coisa a precisa fazer é planejar, enxergar o começo e o fim. Essa é a definição de um projeto. Você tem uma lista de coisas pra fazer, mas provavelmente não dá pra fazer tudo.
Quem me conhece sabe que eu tenho um certo desdém por material de auto-ajuda. Porém sou obrigado a aceitar que analogias e metáforas ajudam a visualizar um conceito abstrato.
Eu vi um vídeo anos atrás, acho que foi de Stephen Covey, autor do famoso Os 7 Hábitos das pessoas altamente eficazes. Ele ensinava o conceito e a importância de priorizar. Eu nunca mais achei esse vídeo online, então quero recriar minha própria versão aqui.
Priorizar funciona assim: você costuma ter tarefas pequenas e tarefas grandes. Tarefas mais fáceis e tarefas mais complicadas. Se você não tem experiência, o normal é a inércia tomar conta e você começar a fazer as tarefas menores ou mais fáceis.
Só quando já é tarde demais se lembra que tinha as tarefas mais importantes que ficaram pra trás. Você percebe que desperdiçou seu tempo fazendo o que não era importante e agora não tem mais tempo. É assim que projetos atrasam: um dia de cada vez, deixando a priorização pra amanhã.
O que o povo aprende a fazer com o tempo? A olhar o big picture: quais são TODAS as tarefas? Quais são as MAIS importantes? Vamos fazer as mais importantes PRIMEIRO e ir encaixando as menos importantes no meio.
Iteração, iteração. E no final, a mesma quantidade de tarefas pode até mesmo CABER no mesmo TEMPO que antes não caberia.
Priorizar é avaliar. É tomar uma decisão e se comprometer. É errar, assumir o erro, reajustar e seguir em frente. É colaborar com os colegas, criar relacionamentos de confiança. Nosso povo sabe que pode confiar um no outro, sabe quem pode procurar pra qual tipo de problema, não existe perda de tempo e desperdício onde a gerência cria silos de influência e um grupo começa a sabotar outro grupo. Nosso povo funciona tão bem que eu posso quase que aleatoriamente ir formando equipes entre eles e eles sabem o que fazer.
Eu aprendi que todo projeto funciona como um gás: ele vai ocupar todo o espaço que você der pra ele. Se você der um ano, o projeto vai durar um ano e mais um pouco. O mesmo projeto se você der 6 meses, vai durar 6 meses e um pouco. A coisa mais importante em um projeto é delimitar os tetos: o custo e o tempo.
E como você sabe que vai durar isso? Você NÃO sabe. Não é uma previsão. Já notou que existem 2 palavras: estimar e prever? Pára de tentar prever. Estime. E estimar não é exato, pela definição da palavra. Estimar é chutar uma ordem de grandeza. Ordens de grandeza não é dizer que vai durar 743 horas e 54 minutos. É saber dizer a ordem de grandeza que estamos falando é uma semana, ou um mês, um semestre, um ano.
O que você faz quando precisa ir pra um lugar longe e não tem um Waze pra te guiar? Você pega um mapa. Mas não tem como ir vendo o mapa o tempo todo e dirigindo ao mesmo tempo. Então você dirige um trecho até onde acha que ainda sabe o caminho. Daí você pára, olha o mapa e vê se continua no caminho certo. Daí prossegue. Pára de novo. De repente você nota que entrou numa curva errada, então você volta até a última bifurcação e corrige. E vai assim até o fim. Por isso a temos sprints ou iterações, senão você ia até o fim do caminho pela estrada errada e quando perceber que tinha feito uma curva errada, já é muito tarde pra voltar. Se for reavaliando em trechos menores, mesmo que precise voltar um pouco ainda dá tempo de corrigir. Faz sentido?
Essa é a essência de gerir um projeto: não é acertar todos os passos, mas garantir que se você errar - e vai por mim, você vai errar - dá tempo de voltar um pouco atrás e corrigir o percurso. Gerir não é evitar 100% dos erros, é garantir que o 1% que errar Não vai comprometer os 99%. Tente ir às cegas: você cai do barranco.
E como você sabe de quanto em quanto tempo parar? Na dúvida pára no menor período possível. Por isso quando me falam de sprints de 3 semanas eu dou muita risada. Significa que se você errar, você vai levar no mínimo 3 semanas pra corrigir e isso pode gerar um efeito cascata de erros que vai prejudicar pelo menos 1 mês e meio de trabalho. Agora começa a escalar isso, é assim que um projeto atrasa 1 ano.
E como você estima as coisas? Tanto faz. Esqueça fórmulas complicadas, diferença de story points, ou qualquer tipo de points. Usa uma escala assimétrica. O menos granular possível. Por exemplo: fácil, médio ou difícil. 1, 2, 5, 8. Por que assimétrico assim? Porque numa ordem de grandeza você quer saber só se a tarefa leva meio dia, um dia inteiro, dois dias ou 1 semana. Mais que isso tanto faz, 5 ou 4 ou 6 dias não faz diferença. Basta 1 story de 8 pontos pra quebrar suas pernas, daí as outras stories de 1 ou 2 pontos não fazem diferença porque essa de 8 é que vai definir seu andamento. É como a demonstração da esfera maior ou das bolinhas menores. Ordem de grandeza. Você só precisa saber quais são as histórias que representam o maior risco, e lidar com o risco. Talvez quebrar em história menores se possível.
Finalmente, você vai ter sua velocidade: quantas dessas histórias são possíveis de serem feitas dentro de um período ou sprint. Com uma ordem de grandeza de velocidade, agora você olha pro projeto como um todo e diz: com essa velocidade atual, dá pra chegar ao fim?
Normalmente não dá. Então você precisa começar a cortar o que é menor prioritário e está no fim da lista. E avisar o quanto antes todo mundo: NÃO VAI DAR TEMPO DE TUDO. É simples assim. Das duas uma: ou simplifica o que precisa fazer ou CORTA o excesso, corta. E não tenta como primeira opção aumentar o custo ou aumentar o tempo. Faz caber! E nem adianta tentar aumentar a velocidade à força. É como no exemplo da viagem de carro sem Waze. Tenta acelerar sem ter certeza, você só vai errar mais bifurcações mais vezes e ter que voltar atrás mais vezes. Não compensa só pisar no acelerador.
Mas e se não for aceitável simplificar ou cortar? Então cancela o projeto, pára agora. Se a premissa inicial tava subestimada, é melhor aceitar um prejuízo pequeno do que tentar acelerar e no final gastar mais e o prejuízo aumentar. É o problema do custo perdido. Sempre é melhor perder o que já gastou no curto prazo do que insistir no erro e no final gastar mais. Deixa eu parar pra explicar custo perdido um pouco.
Digamos que você comprou um ingresso de cinema mas só depois vai ver as críticas e descobre que o filme é uma droga por unaminidade. Assumindo que você não tem nenhum conhecido idiota que compraria seu ingresso, você tem duas opções:
- Já que você já pagou pelo ingresso, vai assistir pra não desperdiçar
- Jogar o ingresso fora
A falácia do custo perdido é não perceber que em qualquer das duas opções, você já pagou pelo ingresso e não vai ter reembolso e portanto o custo perdido não é relevante pra tomar uma decisão racional.
Opção 1: Você sofre o custo do ingresso + Você sofre pelo resto do filme Opção 2: Você sofre só o custo do ingresso e não desperdiça também o seu tempo
Racionalmente a opção 2 é melhor.
E pra chegar nessa conclusão, primeiro você teve que fazer os passos anteriores que falei: enxergar os limites do projeto que são o tempo e o custo, enxergar o que é o objetivo do projeto, organizar o que é essencial e importante e o que é opcional e pode ser deixado pro fim ou até mesmo cortado, começar a fazer, parar e ver se não errou o caminho, e uma vez determinada a velocidade normal, ver o objetivo é alcançável ou não. E, se não for, parar imediatamente antes de gastar mais do que precisaria pra não chegar em lugar nenhum de qualquer jeito.
E isso, senhoras e senhores, é a essência de gerência de projetos. Avançar num objetivo inalcançavel, continuar remando num navio que vai afundar, não é gerenciar, é simplesmente dirigir às cegas sem um mapa. E tudo começa com priorização.
Como eu disse no começo, o objetivo desse vídeo não é transformar ninguém em um ultra gerente de projetos. É só introduzir os primeiros conceitos do que todo mundo, gerente ou não gerente, deveria saber. Em outros vídeos eu quero explorar alguns desses conceitos em mais detalhes, algum em especial que você tenha interesse? Não deixe de mandar nos comentários quais aspectos de projetos mais deixam você inquieto. E se gostou deste vídeo mande um joinha, assine o canal e não deixe de clicar no sininho pra não perder os próximos episódios. A gente se vê até a próxima !