12. Termo de encerramento do projeto
O Relatório de Conclusão de Projeto serve como uma ferramenta de avaliação crucial para patrocinadores, comitê dirigente e gerentes. Este relatório não apenas oferece uma análise detalhada do sucesso do projeto, mas também é fundamental para identificar estratégias e abordagens eficientes que podem ser aplicadas em futuros empreendimentos. Além disso, desempenha um papel chave na resolução de quaisquer questões remanescentes e na formalização do encerramento do projeto, garantindo assim uma transição suave para as próximas iniciativas.
O objetivo central do Relatório de Conclusão de Projeto é multifacetado e abrange uma série de metas estratégicas essenciais para o fechamento eficaz e a análise do projeto. Estas metas incluem:
- Liberação de Recursos: Uma das primeiras tarefas é garantir a liberação adequada de todos os recursos remanescentes, incluindo financeiros, materiais e humanos, que foram alocados ao projeto.
- Validação das Metas e Sucesso do Projeto: Avaliar detalhadamente se os objetivos estabelecidos no início do projeto foram atingidos e analisar o grau de sucesso alcançado.
- Gestão de Questões Pendentes: Identificar e abordar quaisquer questões, riscos ou recomendações que permaneçam em aberto.
- Mapeamento para Encerramento Formal: Documentar e executar as tarefas e atividades necessárias para o encerramento formal do projeto.
- Destaque de Elementos Notáveis e Práticas Exemplares: Identificar e documentar os elementos mais notáveis e as práticas exemplares observadas durante o projeto.
Ao atingir estas metas, o Relatório de Conclusão de Projeto não só marca o fim de um ciclo, mas também lança as bases para o sucesso contínuo em empreendimentos futuros, garantindo que lições aprendidas sejam aplicadas e melhorias contínuas sejam realizadas.
Esta seção é dedicada à verificação e análise do cumprimento dos requisitos iniciais estabelecidos no Termo de Abertura do Projeto. O propósito aqui é assegurar que todas as especificações e condições delineadas para o encerramento bem-sucedido do projeto foram devidamente atendidas.
No Termo de Abertura, dentro da seção Critérios de Aceitação e Término do Projeto, são detalhados os requisitos específicos que devem ser cumpridos para que o projeto possa ser considerado efetivamente concluído. Estes critérios formam a base sobre a qual o sucesso e a finalização do projeto são medidos e avaliados.
O projeto será considerado finalizado quando a aplicação desenvolvida compreender todas as funcionalidades propostas, cobrindo principalmente, o fluxo principal de negócio, quando a aplicação for capaz de passar em todos os testes e quando estiver validada com os stakeholders.
Uma análise do estado atual do software permite observar que o software permite ao usuário:
- Criar um usuário
- Visualizar Jogadores
- Visualizar Times
- Visualizar Campeonatos
No entanto, devido a falta de comunicação, planejamento e organização funcionalidades essências como o CRUD das principais entidades ficou faltando. Além disso até o dia do ultimo status report o banco de dados estava extremamente atrasado e incompleto.
Em resumo, o saldo da conclusão do projeto é negativo; contudo, torna-se essencial avaliar a inadequação do software em relação ao propósito originalmente definido na fase inicial. Esta análise crítica é vital para entender onde o projeto não atendeu às expectativas e para identificar as áreas que precisam de melhorias ou ajustes.
Durante o projeto foi recorrente atrasos no cronograma que impactaram significativamente o andamento do projeto e das funcionalidades. Essa situação aconteceu muito por falta de conhecimento das tecnologias requeridas para o desenvolvimento, além da falta de planejamento e divisão de tarefas igualmente entre os membro de PSW durante o projeto. Infelizmente devido o extremo atraso não foi possível concluir como um todo, deixando funcionalidades essenciais atrasadas.
| Área de gerenciamento | Lições bem-sucedidas | Lições mal-sucedidas |
|---|---|---|
| Escopo | Com relação ao que diz respeito ao CRUD das entidades só compreende-se a leitura dados | O foco colocado na implementação da API no começo do projeto atrapalhou o progresso regular do desenvolvimento do CRUD |
| Partes interessadas | Durante o começo do desenvolvimento todas as partes interessadas mantiveram-se engajadas | Após a fase do frontend, infelizmente houve uma diminuição do ritmo por parte da equipe de PSW, o que impactou no desenvolvimento do software |
| Integração | Documentação relevante, como o documento de início do projeto, atualizações de status semanais que fornecem insights sobre custos, riscos, comunicação e envolvimento das partes interessadas, e o relatório conclusivo, foram preparados para esse fim. | N/A |
| Cronograma | N/A | Infelizmente o cronograma estipulado foi completamente desrespeitado, causando um enorme atraso na entrega das partes cruciais do projeto |
| Custos | Os custos do projeto foram dimensionados corretamente, levando-se em consideração o tempo de desenvolvimento necessário de cada funcionalidade e entregável. | O orçamento não estourou, porém isso só não ocorreu pois a projeto ficou um longo período estagnado. Na tabela de controle foi constatado que nas tarefas realizadas o orçamento extrapolou o esperado |
| Comunicações | A comunicação entre as equipes foi eficiente, com a troca de informações pelo Discord. Essa interação assegurou que todos os envolvidos estivessem atualizados sobre o progresso do projeto e permitiu realizar alterações oportunas no planejamento sempre que necessário. | A comunicação entre a própria equipe de PSW deixou a desejar, infelizmente por conta da falta de comunicação entre eles, não foi possível elaborar um plano para desenvolver o projeto de forma eficiente |
| Qualidade | Equipe de GPTI realizou testes de qualidade no software, que exibiram diversas falhas nas funcionalidades | Devido ao volume significativo de funcionalidades incompletas e em atraso, a qualidade acabou gravemente depreciada. Uma abordagem mais estratégica, como a divisão e alocação adequada de tarefas dentro da equipe PSW, teria potencialmente levado a uma resolução mais eficaz dessa questão. |
| Recursos | Os recursos providenciados para o projeto mostraram-se adequados, atendendo às demandas requeridas pelas atividades de gestão e de desenvolvimento. | N/A |
| Riscos | Desde o início, o projeto incluiu uma avaliação detalhada de riscos e custos relacionados, com uma reserva de contingência para imprevistos. As análises de risco semanais ajudaram a manter o controle e impedir que o projeto degradasse a saúde da empresa, mesmo com a ocorrência dos problemas imprevistos. | N/A |
Infelizmente o projeto não conseguiu se desenvolver como o esperado e no prazo estipulado. Devido a problemas de comunicação, falta de conhecimentos práticos, organização, entre outros, o software ficou estagnado no frontend e foi cancelado.