Hoje em
dia, existem muitas metodologias de gerenciamento de projetos. Umas mais reconhecidas, outras
mais práticas; algumas tradicionais, outras ágeis.
Metodologias tradicionais
foram criadas para atender a vários tipos de projetos, tanto de desenvolvimento
de software quanto de construção civil, fabricação de equipamentos, entre
outros. Por isso, muitas vezes elas não são tão eficientes quando as utilizamos
no desenvolvimento de novos produtos ou serviços de tecnologia, principalmente
no que diz respeito a inovação, pois atualmente este mercado necessita uma
agilidade muito maior que os demais. Se um produto demora para ser lançado, até
lá já estará obsoleto ou a empresa terá perdido o time to market para seu
concorrente...
Acredito muito na utilização de metodologias na implantação
de projetos, mas elas devem ser aplicadas para nos apoiar, e não para burocratizar o processo. Caso
contrário, sua utilização irá gerar um esforço adicional que não agrega nenhum
valor.
Na minha
opinião, tanto as metodologias tradicionais quanto as ágeis possuem pontos
positivos e negativos. O ideal é conseguir aproveitar as melhores práticas de
cada metodologia e utilizá-las independentemente da cultura organizacional ou
dos processos da sua empresa.
A
principal diferença que vejo entre estas metodologias é na definição do escopo.
Na metodologia tradicional ou em cascata, o escopo do projeto é fixo e deve ser
detalhado no início do projeto. A partir desta premissa, serão definidos o
custo e o prazo de entrega. Já na metodologia ágil, são definidas apenas as
funcionalidades básicas antes de iniciar o desenvolvimento, e a partir da
entrega de cada versão, serão detalhadas as próximas funcionalidades a serem
desenvolvidas, caracterizando um escopo variável.
Desta
forma, a metodologia ágil aceita as mudanças de forma mais natural, enquanto na
metodologia tradicional é necessário redefinir o escopo, prazo e custos a cada mudança
solicitada pelo cliente. E, como todos sabemos, mudanças são inevitáveis em
qualquer tipo ou tamanho de projeto...
Com um
menor detalhamento no início do projeto, o objetivo da metodologia ágil é evitar
o desperdício no desenvolvimento de funcionalidades que não serão utilizadas. Isso
porque muitos clientes ainda não possuem uma visão clara do que realmente
querem antes de receberem o produto final, o que resulta na necessidade de mudanças e
também de retrabalho. Ou ainda, querem um sistema que tenha exatamente as mesmas
funcionalidades e processos que o sistema que utilizam atualmente, sem ao menos
pensar em novas alternativas, simplesmente porque eles já estão acostumados a
operar daquela forma.
Por
isso, o ideal neste caso é que, mesmo que trabalhe com uma metodologia
tradicional na sua empresa, você foque no negócio do cliente e entenda por que
ele precisa daquela funcionalidade. Coloque-se no lugar dele e ganhe confiança
para poder discutir a real importância de cada funcionalidade e ajudá-lo a
priorizar as mais importantes. E, se possível, faça entregas parciais ao seu
cliente, mesmo que ele não lance o produto final para o consumidor, assim ele
já poderá te dar um feedback sobre o que já foi desenvolvido.
Outro
ponto que deve ser utilizado em qualquer metodologia é a visão colaborativa e
não competitiva durante o projeto, tanto com o cliente quanto com as equipes
internas. Toda a equipe do projeto deve ser tratada com respeito e se sentir
confortável para dar sugestões de melhoria, de resolução de problemas ou de
novas soluções.
O responsável
pelo projeto deve focar nos prazos e acordos feitos anteriormente com a equipe,
mas ao mesmo tempo entender os motivos pelos quais algo não aconteceu conforme
o previsto. A equipe deve confiar nele o suficiente para que ele seja a
primeira a ser contatada caso um risco ou issue seja encontrado. Se ele adotar
uma abordagem agressiva ou autoritária, a equipe começará a esconder os
problemas dele... e o resultado final será pior para todos os stakeholders.
Uma das
formas de engajar a equipe para a execução do projeto é fazer com que todos entendam
os objetivos de negócio, independentemente do seu nível hierárquico. Quando um
analista júnior ou um desenvolvedor acreditam no projeto e entendem sua
importância da mesma forma que seu gerente ou diretor, ele também se sentirá
responsável pelo sucesso do projeto. Esta visão de negócios sempre deve ser
reforçada a toda a equipe pelo gerente do projeto ou pelo seu sponsor no início
do projeto.
Por
último, a principal habilidade que o gerente de projetos, scrum master ou
product owner deve assumir, é a comunicação efetiva. Seja no detalhamento das
funcionalidades, para que todos os analistas e desenvolvedores entendam
realmente o que devem criar, seja nos reports executivos elaborados
periodicamente com o status do projeto, ou ainda na identificação e comunicação
dos riscos, inclusive para o sponsor do projeto, antes que seja tarde demais...
A comunicação é a chave da gestão de projetos, e um gerente de projetos que não
sabe se comunicar nunca será um bom gestor.
Uma
prática que adoto bastante nos core teams ou na tomada de decisões sobre o
projeto é primeiramente alinhar verbalmente com o público alvo (através de uma reunião
presencial ou virtual e, de preferência, utilizando recursos visuais tais como
uma apresentação breve com o que deve ser abordado), e posteriormente enviar
por e-mail o que foi discutido. Desta forma, todos podem reforçar o seu
entendimento, e aquela decisão ficará registrada para futuras consultas sobre o
seu resultado.
Além
disso, o owner do projeto deve garantir que sua audiência (seja o analista, o
sponsor ou o cliente) entenda o que ele está comunicando, utilizando a
linguagem adequada para cada um desses níveis. Às vezes a comunicação pode até ser redundante, mas no caso de detalhamento de requerimentos, ou na comunicação de riscos, por
exemplo, ainda é melhor reforçar os pontos principais que correr o risco de alguém não ter entendido sua mensagem.
E ao final da reunião, sempre fazer um resumo do que foi discutido e das decisões e próximos passos acordados, garantindo que todos os participantes entenderam da mesma forma e estão de acordo com as suas responsabilidades.
Espero que vocês possam aplicar algumas dessas práticas para se tornarem excelentes gerentes de projetos!
Comments
Post a Comment