Compartilhar via

Incepção de projeto

  • Artigo

Você organiza os recursos básicos do projeto em uma etapa inicial que é chamada de Início do projeto.

Planejando reuniões

Em uma etapa inicial no projeto, vários participantes e especialistas de assunto devem ser convocados para discutir o projeto e fazer o plano de produto. Você deve escolher os participantes com base na natureza e complexidade do projeto e entrega do produto.

Dependendo do tamanho do projeto e da complexidade, a reunião pode ter vários dias ou semanas.

Desenvolvimento iterativo

Uma técnica importante no gerenciamento de riscos está planejando seu projeto em iterações, geralmente, de quatro a seis semanas. Um plano de iteração é uma lista de recursos que a equipe de projeto desenvolverá e testará. Cada recurso especifica uma tarefa ou uma variante aprimorada de uma tarefa que o usuário poderá executar usando o produto. No final da cada iteração, são demonstrados os recursos planejados. No final de algumas iterações, o produto em parte concluído é liberado para avaliação por um conjunto limitado de usuários.

Os comentários dessas demonstrações e avaliações são usados para revisar o plano.

O plano de produto é organizado para que os cenários de usuário da entidade de segurança e os principais componentes do sistema sejam praticados em uma etapa inicial, mesmo que somente de maneira simplificada.

Um dos riscos mais significativos na maioria dos projetos são os requisitos mal-interpretados. Os requisitos podem ser mal-interpretados não apenas pela equipe de desenvolvimento, mas também pelos usuários finais e os participantes. Eles podem achar difícil imaginar como suas atividades empresariais serão afetadas pela instalação do novo sistema.

Além disso, o contexto comercial pode mudar durante o tempo de projeto, resultando em uma alteração nos requisitos do produto.

Um processo iterativo fornece garantia que qualquer ajuste nos requisitos encontrados pela demonstração do produto pode ser acomodado antes do final do projeto, sem incorrer em custos de retrabalho significativo.

Outro risco significativo é a estimativa incorreta dos custos de desenvolvimento. Pode ser difícil para os desenvolvedores que trabalham em uma nova área, e talvez em uma nova plataforma, avaliar com precisão o custo do desenvolvimento antes do projeto. Em alguns casos, pode ser difícil determinar se uma estratégia de implementação específica será executada suficientemente bem. Mas revisando o plano no final da cada iteração, a equipe pode considerar a experiência das iterações anteriores. Esse é um motivo pelo qual um bom plano de produto agenda algum trabalho em cada componente principal em uma fase inicial.

Esse é um projeto conduzido por data ou escopo?

Alguns projetos exigem que todos os requisitos funcionem antes da entrega. Esses tipos de projeto são incomuns em um contexto de software. Um exemplo do mundo real pode criar uma ponte. Um alcance meio concluído é inútil. Por outro lado, um projeto de software não concluído, mas corretamente planejado deve ser implantável e útil para um conjunto limitado de usuários. Pode ser concluído incrementalmente no decorrer de várias atualizações.

Verifique primeiro se seu projeto é realmente conduzido por um escopo. Se for, você deve aguardar para determinar uma data de término até ter estimativas detalhadas e um plano detalhado. Você paga um preço por isso. A sobrecarga de planejamento e o agendamento de buffer como uma contingência em relação à estimativa ruim atrasará a data de entrega ainda mais, aumentando os custos. Portanto, antes de decidir que terá um projeto orientado ao escopo, esteja absolutamente seguro disso. É mais provável em um ambiente complexo de engenharia de sistemas do que em uma situação pura de produto ou de serviço de software.

A maioria dos projetos de software são conduzidos por data porque podem ser entregues incrementalmente. Por exemplo, se um jogo de computador precisar ser lançado na temporada de férias nos Estados Unidos, ele deverá ficar pronto até outubro. A falha ao entregar em outubro afetará fortemente as vendas entre o Dia das Bruxas e o Natal, e, se a agenda atrasar em dois meses, a janela de oportunidade pode ser perdida completamente.

Planejar recursos do projeto

Um projeto deve ser instrumentado por pessoal de modo que possa ser entregue na data desejada. Os dados históricos de projetos anteriores devem ser usados para informar uma discussão sobre recursos suficientes.

Depois de entender os requisitos de pessoal, crie um organograma de projeto que identifique de maneira clara a estrutura da equipe de projeto, os níveis de resourcing e a distribuição geográfica, se apropriado. Salve todas as informações da equipe no portal do projeto.

Defina funções e responsabilidades

Descreve cada função do projeto e as responsabilidades, e os publica no plano de projeto. Cada pessoa que se associa ao projeto deve compreender suas função e responsabilidades no projeto.

Defina um plano de comunicação

É importante definir um plano de comunicação para o projeto. Os caminhos de comunicação ajudam a gerenciar os custos de coordenação do projeto. É importante definir quem deve assistir a reuniões, com que frequência as reuniões são realizadas, os caminhos de comunicação, e como escalar os problemas que não podem ser resolvidos por participantes normais de nenhuma reunião.

O objetivo de um bom plano de comunicação é garantir que as atividades de coordenação no projeto sejam executadas o mais perfeitamente possível e evitar desperdício de esforço por meio de comunicação inadequada.

O plano de comunicação deve ser publicado no portal do projeto e ser mantido, pois ele é necessário. Um plano de comunicação é uma ferramenta útil para qualquer pessoal, especialmente, membros novos. Ajuda-os a entender como uma equipe maior funciona e como obter o que foi feito se comunicando adequadamente de maneiras diferentes com diferentes membros da equipe, e para diferentes fins.

Identifique os participantes

Identifique todos os participantes relevantes do projeto. Além dos membros da equipe principal, a lista deve incluir os executivos e técnicos que têm interesse na implementação com êxito do projeto ou no efeito que o produto pode ter após começar a ser utilizado. Esses participantes podem ser ascendentes ou descendentes na atividade de engenharia de software.

Descreva o plano de projeto

Crie uma versão de estrutura de primeiro plano do projeto, que poderá ser revisada quando o desenvolvimento começar. A finalidade desta versão é ajudar na discussão de recursos e escalas de tempo com os patrocinadores do projeto. Deve organizar os principais recursos e as datas de entrega estimadas. Para obter mais informações, consulte Planejar um projeto (CMMI).

Revise o plano de projeto

Publique o contorno do plano de projeto no portal do projeto. Embora muito trabalho seja feito no plano, ainda é um plano de alto nível que adia muitas decisões detalhadas de agendamento. Isso é intencional. Muitos detalhes irão gerar desperdício posteriormente.

Quando os requisitos forem incertos, faça apenas um esboço deles, adiando o detalhamento até a disponibilização de mais informações. Planeje obter essas informações.

Agende uma reunião de revisão com todos os participantes. As reuniões frente a frente são sempre as melhores para esse tipo de atividade. Certifique-se de agendar tempo suficiente para ativar uma revisão completa e permitir que opiniões divergentes sejam ouvidas.

Obtenha compromissos do projeto

Agora que o plano de projeto está acordado com os participantes do projeto, incentive cada participante a se comprometer com a aprovação do plano de projeto.

Colete os compromissos e arquive os detalhes no portal do projeto.

Recursos adicionais

Para obter mais informações, consulte os seguintes recursos da Web: