Como desenvolver projetos com eficiência, atingindo os resultados esperados?
Gestão de Projetos
Como desenvolver projetos com eficiência, atingindo os resultados esperados? Bem, esta pergunta pode ser respondida de algumas maneiras. Duas abordagens principais cobrem este tema de forma diferenciada. A primeira delas está associada ao Gerenciamento de Projetos Tradicional ou Waterfall. A segunda está relacionada diretamente com o modelo ágil de se construir e acompanhar os projetos da organização.
Partindo do ponto de vista do Gerenciamento Tradicional, esta metodologia coloca foco nos processos e em áreas do conhecimento como Integração, Escopo, Cronograma, Custos, Qualidade, Recursos, Comunicações, Riscos, Aquisições e Stakeholders.
Ao se desenvolver um projeto, independente da sua magnitude, neste primeiro formato temos a fase de Inicialização, que se concentra em gerar as primeiras informações para o gerente de projeto. O principal foco desta fase é a análise de viabilidade, levando a um contexto onde temos os dados referentes ao retorno do investimento e desejos iniciais como metas macro.
A fase seguinte se concentra no planejamento. Normalmente feita de forma superficial, ela deveria contemplar o que se espera dentro de cada área mencionada anteriormente. A saída principal desta fase é gerar os planos. Aqui é o momento adequado para se decompor as partes do projeto, definir o cronograma, o orçamento com base nos recursos e estipular quais os riscos que estão em pauta, mesmo antes do projeto. Todo este trabalho resultará em um mínimo de reservas a serem contempladas, tanto em termos de tempo quanto em termos de custos.
A próxima fase é a execução, que direciona a energia dos integrantes do projeto para a realização dos planos. Com ela o Monitoramento e o Controle também acontecem. As principais referências de controle para a execução são as linhas de base do projeto. As mesmas são estabelecidas no início, após a análise de viabilidade. Ao buscarmos os objetivos do projeto, é evidente que teremos mudanças e assim o escopo, o cronograma e os custos precisam ser medidos e comparados com aquilo que estava previsto.
Normalmente faremos as seguintes perguntas: o custo está de acordo com este momento e a quantidade de trabalho considerada? E o cronograma versus as entregas previstas estão de acordo com o esperado? Se as mudanças foram solicitadas e aprovadas, qual foi o impacto? Lembrando que todo o processo de mudanças deve ser acompanhado por um comitê e o trabalho de avaliar os impactos precisa ocorrer previamente à análise das linhas de base. Caso contrário, o gerente de projetos irá apenas contornar situações ou “apagar incêndios”.
A última etapa do projeto é o Encerramento. Com uma baixa frequência de aplicação nas empresas, ela consolida que o projeto entregou o que deveria dentro do esperado, registrando as lições aprendidas. Para isso, normalmente são considerados dois critérios específicos. O primeiro compreende que os entregáveis foram aceitos dentro do que estava solicitado. O segundo formaliza o encerramento em virtude do tempo ter sido totalmente consumido, reduzindo o número de ações ou entregas em virtude da indisponibilidade de recursos, que precisariam ser liberados para outras iniciativas. Nesta segunda hipótese, o patrocinador e os stakeholders aceitariam o desfecho do projeto com entregas possivelmente não concluídas, estabelecendo que o restante do escopo deveria ser contemplado em um momento futuro.
Agora numa abordagem Agile, como isso funciona? Os ciclos passam a ser reduzidos, quando comparados ao Waterfall. Em linhas gerais, ao invés de termos 6 meses a 5 anos de duração, o formato seria replicado em ciclos com 2 a 8 semanas, por exemplo. Isso significa que a revalidação das entregas seria feita com mais frequência e mudanças de prioridade poderiam ser estudadas em períodos mais curtos. Esta é uma forma vencedora nos projetos voltados para a Tecnologia da Informação e vem sendo replicada para muitas outras áreas. Os pacotes, que anteriormente apresentavam interdependências passam a ser independentes com as suas especificações dentro dos próprios ciclos num modelo muito mais autônomo quando nos referenciamos à equipe responsável. Assim o projeto pode agregar o mesmo valor de um formato Waterfall, fazendo verificações mais constantes junto ao cliente. As validações e melhorias também acontecem ciclo a ciclo e a evolução do trabalho vai sendo concretizada de uma forma que o cliente não espera tanto pelo benefício. Isso se ajusta muito bem à realidade dos aplicativos. Quando você instala diferentes versões, ao mesmo tempo, você recebe novos ícones ou melhorias de funções associadas a uma consulta ou à uma entrega de valor.
As verificações no modo Agile são mais frequentes e são conduzidas com um time que revisa o que deve ser feito, criando um status baseado nas atividades do dia anterior, por exemplo. Numa perspectiva similar ao Waterfall, temos os integrantes principais de projeto voltados para funções específicas. O líder dentro da iniciativa será o Scrum Master, os membros de time serão os responsáveis pelas atividades juntamente com o líder, que executa atividades dentro do próprio time. Por fim, o Product Owner faz a ponte com o cliente, garantindo uma entrada assertiva dos requisitos ciclo a ciclo. A cada fim de sprint a equipe se reúne para validar e encerrar os ciclos com as entregas determinadas baseadas nos backlogs, que comportam todo o trabalho a ser desenvolvido.
O processo de gerenciamento e a metodologia a serem utilizados variam de acordo com cada organização. Devemos ter atenção ao analisar cada formato, principalmente por conta de fatores culturais ou adaptações necessárias. O nível de maturidade, tanto do sistema utilizado quanto dos profissionais inseridos nesta dinâmica precisam ser avaliados para se definir os próximos passos para uma evolução constante, desde uma aplicação híbrida, indo além dos contextos apresentados, até uma estruturação de um escritório de projetos (PMO - Project Management Office).
O mais importante é termos um modelo de trabalho com ferramentas e templates dentro do ambiente. Afinal, padronização, assim como em outros processos, também faz parte do gerenciamento de projetos.
