Fazendo as Coisas Acontecerem

 

Outro dia, me encontrei perguntando: - Desde quando o gerenciamento de projetos é uma coisa fácil? Depois de algum tempo acabei me deparando com o livro Making Things Happen: Mastering Project Management de Scott Berkun, publicado em março de 2008, com muita coisa interessante.

Sobre o autor, vale citar outros de seus livros como Mitos da Inovação, de 2007, Confissões de um Orador Público, de 2010, e o recente How Design Makes the World, de 2020.

Eu acho que ainda não encontrei uma resposta que preenchesse todas as indagações da minha enorme curiosidade, mas, e daí? Talvez isso nunca aconteça. Daqui pra frente nesse post estou abrindo enormes aspas para o Sr. Berkun.

              ********   *********   ********

“Em muitas organizações, a pessoa que lidera um projeto ... não tem o cargo de gerente de projeto . Isso está okay.    Todos gerenciam projetos em seu trabalho diário, sejam sozinhos ou liderando uma equipe. Por enquanto, essas distinções não são importantes.  Minha intenção é capturar o que torna os  projetos  bem-sucedidos  e  como  as  pessoas que lideram os projetos o fazem.  Essas  estratégias  não  requerem  hierarquias,  cargos  ou métodos específicos.  Portanto,  se  você  trabalha  em um projeto e tem pelo menos alguma  responsabilidade  por  seu  resultado,  o que se segue se aplica a você.  E  se  acontecer  de seu cartão de visita dizer  gerente de projeto, tanto melhor.

O primeiro capítulo do livro Making Things Happen: Mastering Project Management traz um breve histórico de projetos e por que devemos aprender com o que outros fizeram. O gerenciamento de projetos, como uma ideia, vem de um longo caminho. Se você pensar em todas as coisas que foram construídas na história da civilização, temos milhares de anos de experiência em projetos para aprender. Uma linha pontilhada pode ser traçada para ligar os desenvolvedores de software de hoje até os construtores das pirâmides egípcias ou os arquitetos dos aquedutos romanos. Em suas respectivas épocas, os gerentes de projeto desempenharam funções semelhantes, aplicando tecnologia aos problemas relevantes da época. Ainda hoje, quando a maioria das pessoas tenta melhorar a forma como seus projetos de desenvolvimento de software são gerenciados, é raro que prestem atenção às lições aprendidas no passado. A linha do tempo que usamos como escopo para o conhecimento útil está muito mais próxima dos dias atuais do que deveria estar.

A história dos projetos de engenharia revela que a maioria dos projetos tem fortes semelhanças. Eles têm requisitos, designs e restrições. Eles dependem de comunicação, tomada de decisão e combinações de pensamento criativo e lógico. Os projetos geralmente envolvem um cronograma, um orçamento e um cliente. Mais importante ainda, a tarefa central dos projetos é combinar as obras de diferentes pessoas em um todo único e coerente que seja útil para pessoas ou para clientes. Quer um projeto seja construído em HTML, C ++ ou cimento e aço, há um conjunto de conceitos básicos inegáveis que a maioria dos projetos compartilha.

Meu interesse em conhecer as melhores maneiras de liderar os esforços de desenvolvimento de software, me levou a estudar outros campos para ver como eles resolviam os desafios centrais de seus projetos. Eu me perguntei como projetos como o Telescópio Espacial Hubble e o Boeing 777 foram projetados e construídos. Eu poderia reutilizar algo de suas especificações complexas e processos de planejamento? Ou quando o edifício Chrysler Building foi construído na cidade de Nova York e o Partenon em Atenas, os líderes do projeto planejaram e estimaram sua construção da mesma forma que meus programadores? Quais foram as diferenças interessantes e o que pode ser ganho examinando essas diferenças?

Mas não é só isso. E quanto à produção de filmes? O lançamento da Apollo 13? Examinando essas questões, pude ver como conduzir equipes de projeto de uma nova maneira.

No entanto, essas perguntas nem sempre fornecem respostas óbvias. Não posso prometer que você fará o lançamento mais cedo ou fará um planejamento melhor, especificamente porque os conselhos do livro foram influenciados por essas fontes. Mas sei que, quando voltei ao mundo do software depois de procurar outro lugar, meus próprios processos e ferramentas pareciam diferentes para mim. Encontrei maneiras de mudá-los que não havia considerado antes. No geral, percebi que muitas das abordagens e comparações úteis que encontrei nunca foram mencionadas durante meus estudos de ciência da computação na faculdade. Eles nunca foram discutidos em conferências do setor de tecnologia ou escritos em revistas especializadas.

As principais lições de minhas investigações no passado estão resumidas nos três pontos a seguir:

O gerenciamento de projetos e o desenvolvimento de software não são artes sagradas - Qualquer trabalho de engenharia moderna é uma nova entrada na longa história de fazer coisas. As tecnologias e habilidades podem mudar, mas muitos dos principais desafios que tornam a engenharia difícil permanecem. Todas as coisas, sejam linguagens de programação ou metodologias de desenvolvimento, são únicas em alguns aspectos, mas derivadas em outros. Mas se quisermos reutilizar o máximo de conhecimento que pudermos do passado, precisamos nos certificar de que estamos abertos para examinar os dois aspectos - o único e o derivado - em comparação com o que veio antes.

Quanto mais simples for sua visão do que você faz, mais poder e foco você terá ao fazê-lo. Se mantivermos uma visão simples de nosso trabalho, podemos encontrar comparações úteis com outras maneiras de fazer as coisas que existem ao nosso redor. Haverá mais exemplos e lições da história e das indústrias modernas que podem ser extraídas, comparadas e contrastadas. Isso é semelhante ao conceito definido pela palavra japonesa shoshin - que significa mente de iniciante, ou mente aberta - uma parte essencial de muitas disciplinas de artes marciais. Ficar curioso e aberto é o que torna o crescimento possível, e é preciso prática para manter essa mentalidade. Para continuar aprendendo, temos que evitar a tentação de cair em visões estreitas e seguras do que fazemos.

Simples não significa fácil. Os melhores atletas, escritores, programadores e gerentes tendem a ser aqueles que sempre vêem o que fazem como algo simples por natureza, mas ao mesmo tempo difícil. Lembre-se de que simples não é a mesma coisa que fácil. Por exemplo, é uma coisa simples correr uma maratona. Você começa a correr e não para até atingir 26,2 milhas. O que poderia ser mais simples? O fato de ser difícil não nega sua simplicidade. Liderança e gerenciamento também são difíceis, mas sua natureza - fazer as coisas de uma maneira específica em direção a uma meta específica - é simples".

Bem, vamos ficar por aqui. No próximo post, ainda com grandes aspas para Scott Berkun, vamos continuar explorando o truque de aprender o máximo possível com as falhas de outras pessoas. Até a próxima!