A medida que crescemos profissionalmente e nos aproximamos da área de gerenciamento de projetos entramos cada vez mais em um mundo o qual extrapola os limites da paciência, o desgaste físico e mental do profissional da área de tecnologia. Os prazos e orçamentos são extremamente justos, além das complexas solicitações de mudanças que aparecem normalmente no meio do projeto e que prejudicam ainda mais os prazos definidos e principalmente o custo do projeto. Isso é algo comum para nós da área de tecnologia da informação, estamos acostumados (salvo exceções) a trabalhar diante de um cenário que muda radicalmente da noite para o dia, o qual o cliente vai dormir pensando em uma definição e acorda com outra. E a pergunta para nós é “isso deveria ser algo normal?”.
Acredito fortemente que muitas empresas não estão preocupadas em todo o conhecimento de um gerente de projetos e desta forma, em muitos casos, o simples fato do profissional estar com um MS® Project instalado em sua máquina e ter as atividades controladas pelo cronograma não fazem dele um gerente de projetos. Realizando uma análise macro sobre empresas que ainda atuam com esta forma de gestão em seus projetos, o resultado é sempre muito semelhante: hora extra para a maioria dos envolvidos, discussões com seus fornecedores na tentativa de identificar o culpado pelos problemas, discussões entre os participantes, e por fim, uma margem de lucro tendendo a zero. Porém, existem empresas que levam esta tarefa a sério, colocam uma prioridade muito grande para a gestão, e nela incluem um planejamento minucioso das fases que vão garantir um custo menor, um prazo plausível e um escopo mais próximo do real. Sob o ponto de vista do cliente, sua empresa está encaixada neste perfil?
Um exemplo que mostra a ineficiência de muitos clientes em relação à gestão:
O cliente busca em sua equipe uma pessoa com grande conhecimento no negócio e elenca esta como um líder ou gerente de projeto. Essa pessoa, que tem todo potencial em se tornar um gerente de projetos, é bem organizada e trabalha com um cronograma bem definido, aceita o desafio. Porém ela não tem experiência, força para negociações e feeling da produtividade da equipe (em relação ao tempo de desenvolvimento). O cronograma é definido pelo cliente com um curto prazo em relação ao número de atividades a serem desenvolvidas. O fornecedor por sua vez, não quer perder o projeto e então aceita o cronograma sabendo que sua equipe está alocada em outros projetos. Começa a corrida contra o tempo. As poucas horas de atraso acabam transformando-se em dias até a entrega da documentação final do cliente para o fornecedor, com qualidade das especificações ficando abaixo da esperada. O gerente de projetos tenta tirar os impeditivos, porém, sabe que o cronograma é curto e com isso vai precisar pressionar o fornecedor a manter a data, mesmo ele entregando a documentação com alguns dias de atraso.
O fornecedor recebe as documentações e aceita o prazo, além de estar com a equipe trabalhando em hora extra, possuir uma série de dúvidas relacionadas a uma documentação de baixa qualidade e obter respostas às suas perguntas com atraso pelo cliente. No final, o fornecedor garante a entrega na data, mas logo em seguida começa a perceber problemas relacionados a entrega: os bugs começam a aparecer, as discussões sobre a qualidade de entrega x qualidade das documentações gera um desgaste entre as equipe e a rentabilidade do projeto começa a diminuir. O colapso inicia-se muitas vezes em uma negociação interna sobre prazos, em que um profissional que está iniciando o processo de gestão não tem o apoio necessário e experiência para visualizar os problemas ao longo prazo que o projeto pode acarretar. Isso não acontece só com profissionais que estão iniciando em gestão de projetos, mas também com pessoas experientes, porém, que não tiveram uma bagagem teórica aplicada. Por fim, os problemas são escalados, discussões entre fornecedores e clientes ficam mais acirradas, equipes são deslocadas para sala de guerra, pois o projeto já extrapolou em mais de um mês a entrega. Ao final chega-se à conclusão de que o fornecedor precisava de mais um mês para a entrega do projeto a fim de satisfazer o cliente com qualidade.
Isso é possível de ser evitado?
Em resumo, podemos dizer que muitas empresas apenas se enganam controlando cronogramas, realizando entregas comprometidas e ao final, exigindo um lucro acima de algo que foi se perdendo durante o período de construção, na forma que os clientes são abordados, na maneira em que as atividades são conduzidas e acima de tudo, não se adequando a evolução da TI. SIM!!! A TI evolui e os processos melhoram a medida que os anos passam. Uma prática difundida ultimamente é chamada de “Lean Startup”, que pode ser vinculada a gestão de projetos como uma saída para evitar os principais conflitos, e que projetos virem um fracasso. Imagine que o cliente final tenha chances de dar um feedback antes do início do desenvolvimento, algo como estar participando mais efetivamente das reuniões com fornecedores e entendendo melhor o que deseja. Este processo pode ser considerado complicado, com possíveis alterações de escopo, porém as negociações são mais participativas e o projeto final será conforme o solicitado pelo cliente. O exemplo anterior mostra uma falha de planejamento, que pode ser possivelmente vinculada ao não entendimento do cliente por parte da complexidade do projeto como um todo. Atualmente empresas estão adotando diferentes formas de trabalho, como entregas parciais de projeto (que evitam problemas como o exemplo em questão), outras adotam um pool de gerente de projetos (que ficam normalmente unidos para atender projetos de diversas áreas com grande troca de conhecimento nos trabalhos, ajudando os novos profissionais a adquirirem experiência e também insights para contornar os problemas do dia a dia).