Dilema de gestão de projeto (RUP x PMI)
O pessoal da administração, que muitas vezes não tem acesso ou contato com
processos de desenvolvimento de software, desconhecem completamente RUP e
desprezam isso quando montam uma proposta técnica para poder conquistar um
projeto em um cliente. Concebem a 'inception', 'design', 'testing' e
'implementation' porém não tem processos bem dimensionados com os papéis bem
definidos como no RUP. Têm a mania de refazerem a roda dos projetos.
Nos deparamos com anti-patterns organizacional decorrente disso pois, quando
vão fazer os cálculos de tempo / recursos / valrores, se deparam com as
discrepâncias dos processos que querem criar versus os processos realmente
necessários para as montagens das builds já previstos na RUP.
E nisso vemos um conflito comum entre área de projetos, que não leva em conta o
RUP e sim o PMI, e a equipe de desenvolvimento. Esta precisa da participação,
conforme o enfoque RUP, do Gestor de Projeto e, se possível, um Gestor de
Mudanças também. A dissociação dos papéis é útil pois, enquanto um reporta o
projeto como um todo aos players (investidores do projeto) o gestor de mudanças
intermedia a liberação entre as builds. Frequentemente vemos faltar um participante
como gestor de mudanças, que efetua o represamento de requisitos não viáveis
para a build corrente e, por outro lado, como o gestor de projeto responde pelo
projeto como um todo, quer tudo 'à toque de caixa', a famosa 'pizzaria'.
Sabemos como isso é complicado quando o gerente de projeto não está acostumado
com o desenvolvimento RUP, como sempre vemos: querem fazer um filho em um mês
com 9 mulheres, ou seja, é a preconização do impossível. E nisso há todo um
stress em relação às expectativas do projeto tornando uma experiência dolorosa
e inesquecivelmente traumática.
Já um gestor proveniente da área de sistemas tem sempre sucesso principalmente
com seus pares da área de desenvolvimento que se vê harmoniosa e atendendo as
demandas sem o stress comum em projetos.
Muitos questionam porquê os projetos têm essas características. Muitas vezes,
além dos prazos apertados, até o gestor faz as vezes de analista de sistemas
(!) absurdamente, para 'economizar'. Nisto ele aparece com o perfil de alguém
que está 'dando retorno (ROI)' do projeto. A que custo? Questiono qual o real
papel de tal gestor...
O pior cenário é justamente do gestor, como formação PMI administrativa, querer
dar 'pitaco' na área de desenvolvimento a ponto de negligenciar o papel fundamental
do Arquiteto de Sistemas que é seu braço direito técnico. Isso é o mais
lamentável pois o Arquiteto comumente tem a visão mais longe a ponto de
determinar os padrões, expansões e limites técnicos do projeto, área
frequentemente obscura para quem trabalha somente com prazo, tempo e recursos
humanos e financeiros.
Anibal Marques é Arquiteto de
Sistemas, Tecnólogo em Sistemas de Informação, iniciou sua carreira na área de
Informática em 1986, formando duas turmas de profissionais COBOL após o término
do próprio curso. Autodidata, está acostumado em atuar em empresas de grande
porte como Bancos, Financeiras, Seguradoras e Segmento de Transporte e exerce
os papéis de Arquiteto de Sistemas / Integração EAI, Analista de Requisitos,
Designer / Desenvolvedor e Líder de Projetos bem como elabora propostas
técnicas como suporte ao comercial de empresas de consultorias. Atualmente
pós-graduando em Ensino Superior.