Em meados de 2005 para 2006, eu entrei num desses cursos preparatórios de formação para PMI e foi também quando tive a oportunidade de acompanhar um projeto que estava se preparando para a certificação CMMi.
Na visão tradicional de carreira em cascata, depois de muitos anos trabalhando na área de desenvolvimento de software, acaba sendo o primeiro caminho natural para se buscar uma evolução para deixar de desenvolver e partir para uma posição de gerente.
Escolhendo caminhos
Eu já trabalhava como arquiteto de software nessa época e já liderava alguns projetos, então resolvi seguir adiante para entender mais essas questões gerenciais de que tanto se falava na época.
No decorrer do curso para certificação PMI e acompanhando o trabalho de outras pessoas que já atuavam na posição de gerente, eu tomei a decisão mais importante que era justamente a que eu não queria ser gerente.
Acho o Project uma ferramenta fantástica, mas ficar sentado planejando um cronograma infinito (como esses que você observa colado na parede) definitivamente não era o futuro que estava sonhando para mim.
Foi um momento difícil porque em paralelo eu acompanhava toda a burocracia para se chegar a um projeto baseado em CMMi e felizmente fazia isso de fora, na melhor posição que era justamente como um observador e com liberdade de conversar com todos os interlocutores envolvidos em cada passo.
Traçando objetivos
Eu já vinha de mais de cinco anos trabalhando em projetos extremamente envolventes e ágeis, nos quais todos faziam literalmente tudo como um verdadeiro time multidisciplinar de planejar, executar e negociar com o cliente cada entrega. De repente, me vi no risco de enfiar cada um dos pés numa bola de ferro igual à dos filmes nas prisões americanas, gerando um pré-estresse muito grande em minha cabeça, uma vez que eu não via resultado real para tanta burocracia.
Conversava com as pessoas, e elas simplesmente diziam que faziam porque tinham fazer. Elas mesmas criavam um processo em que não acreditavam e tudo aquilo me deixava muito sufocado. Passei então a questionar o real papel do grupo SEPG (Software Engineering Process Group) no projeto e a função do gerente tradicional que não resolvia nada.
Na prática, o gerente ajustava o cronograma de forma que ficasse bonito para o sponsor. Dentro da gordura de processos existentes, ele preenchia mais uns 10 documentos para justificar, copiando e colando cada atraso de entrega, sendo que o importante era seguir o processo mantendo o cronograma atualizado sem se preocupar realmente com o empregável.
Eu sou muito prático em minhas ações e até meio simplista, mas trabalhar criando vento realmente nunca foi o meu objetivo. Literalmente é algo que ainda vejo hoje em dia e acabei em função desses gargalos que vocês já conhecem, optando por rasgar todo e qualquer plano e focar na entrega de valor para o cliente conquistando a sua satisfação e de todo o time envolvido.
Definindo funções na prática
Toda vez que escutava a palavra “recurso”, era como enfiar um prego no meu ouvido. Já a palavra replanejar era tão semanal com tão boas justificativas que o pessoal já estava acostumado. Acho que já tinha um formulário com as principais justificativas de replanejamento. Os colaboradores que executavam se confortavam em ficar parados aguardando os comandos gerenciais para entrar em ação. É um ciclo vicioso terrível que precisa ser interrompido da face da terra.
É importante deixar claro que o problema não é o profissional de projetos, e sim determinadas atitudes gerenciais que ainda remontam aos tempos medievais interrompendo qualquer relação de confiança distante dos principais conceitos de liderança e relacionamento com as pessoas no projeto.
O profissional de projetos moderno precisa se reciclar complemente para que possa criar uma cultura envolvente no projeto, que mesmo com crises possa contar com o apoio das pessoas. Acaba sendo um conjunto de fatores que somados transformam o grupo de trabalho em um verdadeiro time para enfrentar qualquer dificuldade com colaboração e principalmente atitude, direcionando sempre para a solução e não para o problema.
Conclusão
Avaliando atualmente a decisão que tomei seis anos atrás, não me arrependo em nada de ter me tornado cada vez mais especializado em desenvolvimento de software, unindo as pessoas sem me preocupar em mandar, e sim em resolver e em conquistar a felicidade nos projetos.
Com a popularização dos projetos ágeis e a cultura chegando às organizações, estamos conseguindo quebrar essa visão que para crescer na empresa você precisa necessariamente estar com um porrete nas mãos. O líder não precisa de armas, e sim de simpatia para harmonizar com maestria as dificuldades que aparecem no dia-a-dia e unir o time em torno da solução.
Não se preocupe em rasgar o seu plano de carreira sempre que for necessário, pois não adianta você montar uma visão plastificada distante do seu verdadeiro sonho de realização. Mudar de visão e se adaptar faz parte do ser humano.
Invista na melhoria continua das suas habilidades, sempre buscando a linha de trabalho que lhe deixa mais feliz. Quando tiver a oportunidade de lidar com pessoas, entenda o sentimento de cada uma e procure incentivar as habilidades delas, escutando e abrindo espaço para colaboração e, assim, os resultados vão se multiplicar.
46 Comentários
Qual a sua opinião?