Transcrição do episódio A transcrição é gerada automaticamente por Podscribe, Sonix, Otter e outros serviços de transcrição eletrônica.
Olá pessoal! Bem vindos a mais um Five Minutes Podcast! Hoje eu queria falar sobre essa nossa insistência, muitas vezes, de encontrar uma solução que resolve a todos os problemas o tempo inteiro. Ou seja, é esse sonho daquela solução mágica que a gente tem para os nossos projetos. E eu queria ressaltar que não existe o “one size fits all” não existe uma metodologia ou uma abordagem que é universalmente perfeita para todos os cenários. Bem, o que a gente tenta na maior parte das vezes, quando, por exemplo, uma instituição ou uma empresa desenvolve um método para gerenciar os seus projetos. Essa empresa está tentando o que ela está tentando simplificar o seu processo tenta dar uma uniformidade, um parâmetro mínimo, um padrão mínimo para que as pessoas, por exemplo, consigam comparar diferentes projetos e avaliar esses projetos, segundo determinados critérios, cada organização cria agora. Uma das coisas que a gente tem que estar muito atento e que, por exemplo, se você pegar uma empresa grande, uma empresa da indústria automobilística ou uma grande empresa de software, e você falar que um método, uma abordagem resolve todos os tipos de projetos a todo o tempo. Bem, isso não existe. Isso não existe em lugar nenhum, porque a natureza do projeto torna ele único. Ou seja, a nossa própria definição do que é um projeto pressupõe algo único. Então a gente tem que tomar muito cuidado com isso. E por que eu estou falando isso? Porque não adianta a gente querer desenvolver uma metodologia infalível para qualquer caso, em qualquer cenário, porque se a gente tentar fazer isso, a gente vai falhar. O que a gente precisa? O que a gente precisa é que a gente tem visto hoje. A gente viu isso no agile manifesto ou manifesto ágil.
A gente viu isso agora no PMBOK sétima edição, a gente viu isso no PRINCE2. Que é o quê? Você cria um conjunto de princípios, como eu já falei inúmeras vezes anteriormente. E esses princípios eles não são fixos, eles não são prescritivo. Eles não são uma receita de bolo. Eles são coisas que guiam o seu comportamento diante de alguma coisa. Por exemplo, quando lá no manifesto ágil, você fala assim o código funcionando, a documentação significa o que significa que uma pessoa desenvolvendo um software, ela deve estar mais focada em ter um código que funciona do que em documentar, seja isso está dando ali um direcionamento segundo o manifesto ágil. Agora, o que você precisa então? Você precisa ter uma caixa de ferramentas, por exemplo. Toda vez que eu estou estudando projetos, eu tento estudar coisas diferentes, estudar aspectos diferentes, estudar técnicas diferentes. Porque quanto mais técnicas diferentes eu tenho, como por exemplo você estudar sobre Round Robin ou você estudar sobre Slip de Crawford, ou você estudar, por exemplo, Safe ou você estudar Scrum que isso vai te ajudar diante de técnicas de brainstorming até métodos. Isso vai fazer com que a sua caixa de ferramentas para resolver os problemas dentro da sua organização se torne mais versátil, com diferentes ferramentas para que você consiga isso. É o que eu falo sempre. Se você quer cortar alguma coisa, você pode usar uma tesoura ou uma faca, concordam comigo? Ambos são objetos cortantes, mas existem casos em que um objeto é melhor do que o outro.
Por exemplo, se você vai cortar papel, você pode usar uma faca. Claro que você pode. Talvez não seja a melhor ferramenta. Agora, se você vai cortar, por exemplo, um cabo, uma corda, é muito mais interessante usar uma faca do que uma tesoura. Tesoura talvez não tenha a capacidade de cortar uma corda. Isso é o conceito da ferramenta. Então a gente precisa sair um pouco fora dessa, nossa predisposição a tentar achar soluções fáceis para cenários complexos. Bem, isso seria uma pedra fundamental se a gente conseguisse fazer. Mas a realidade não é assim. Muitas vezes, problemas complexos eles vão exigir um conjunto amplo de ferramentas onde você vai pegar. E é o que eu faço o tempo todo. Eu vou customizar uma abordagem de comunicação pegando coisas de Scrum. Por exemplo, eu faço o chamado Daily Scrum em projetos que não usam scrum, em projetos com um planejamento mais detalhado, um projeto seguindo waterfall etc. Aí isso vai falar mas como é que você faz um daily? O daily scrum que eu tiro é o conceito da agilidade do pensamento. O conceito do grupo está reunido para discutir, mesmo tendo ali um escopo claro dentro daquele projeto. Então, é esse tipo de abordagem que a gente precisa entender. E é isso que hoje é uma das coisas que mais diferencia um gestor de projetos scrum master é a capacidade que esse profissional tem de conseguir adaptar aquele conjunto de ferramentas que ele ou ela desenvolverem aprenderam para cada um dos diferentes cenários.
Pensem nisso e até semana que vem, com mais um Five Minutes Podcast.
