2.0 Fases de Implantação de Projetos (Parte 1)

Iniciação #

O início do projeto é referido como a fase de início. Nesta fase, a ideia do projeto é explorada e desenvolvida. O objetivo desta fase é ver se o projeto pode realmente ser concluído. São feitas escolhas sobre quem vai liderar o esforço, qual a organização que vai participar, e se o negócio receberá apoio suficiente dos envolvidos.

Este passo exige que o atual ou futuro líder do projeto prepare uma proposta que esponte os pontos acima mencionados. Os planos de negócios e as candidaturas de subvenções são exemplos deste tipo de proposta de projeto. Os potenciais patrocinadores do projeto avaliam a candidatura e dão o financiamento necessário se for aprovado. O projeto começa formalmente após aprovação. Devem ser abordadas na fase inicial:

  • Por que este projeto?
  • É fisicamente possível?
  • Quais são os resultados desejados?
  • Quais são os limites do projeto (o que está incluído no âmbito do projeto)?

A capacidade de dizer “não” é uma característica crítica de um líder de projeto. Uma vez que os indivíduos ficam entusiasmados com um projeto, ele tende a crescer no âmbito. Já que estamos a fazer isso, podemos muito bem… é a ideia subjacente. Os projetos a que se somam os objetivos adicionais e os projetos que continuam a crescer estão quase garantidos a esgotar-se e dificilmente cumprirão os seus objetivos iniciais.

O primeiro passo é estabelecer uma ligação entre todas as partes interessadas do projeto. Expectativas irrealistas em relação ao resultado do projeto podem ser evitadas se o âmbito for bem compreendido. Para começar, estabelecer uma ligação entre as várias pessoas envolvidas. É essencial ter uma compreensão firme do seu âmbito de aplicação.

O método escolhido para um tipo específico de projeto tem um impacto significativo no seu resultado. Por exemplo, um esforço de investigação e desenvolvimento pode fornecer um relatório que avalie a viabilidade técnica de uma aplicação. Um projeto que resulta no desenvolvimento de um protótipo inclui todas as funções de uma aplicação. Ainda assim, não são obrigados a ser adequados para a utilização num ambiente específico (por exemplo, por centenas de utilizadores). Um projeto que produza um produto funcional deve também abordar questões de manutenção, documentação e administração de aplicações.

Numerosos mal-entendidos e litígios ocorrem devido às pessoas envolvidas na gestão de projetos serem pouco claras sobre estes pontos. Os clientes podem antecipar um produto funcional, enquanto os membros da equipa do projeto acreditam que estão a criar um protótipo. Embora um patrocinador possa pensar que o projeto resultaria numa peça útil de software, os membros da equipa devem primeiro determinar se o conceito é tecnicamente viável.

Definição #

Após o plano de início de sessão aceite, o projeto iniciou a segunda fase: a fase de definição. Esta fase especifica tão precisamente quanto possível os requisitos ligados ao resultado de um projeto. Esta fase implica determinar as expectativas de todas as partes envolvidas no desenvolvimento do projeto. Quantos ficheiros são necessários para arquivar? Os metadados devem estar no formato De Documentação de Dados (DDO) ou o Núcleo de Dublin (DC) seria suficiente? Os ficheiros são permitidos no seu formato original ou apenas aqueles que aderem às “Normas Preferenciais”? É dever do depositante garantir que um conjunto de dados seja devidamente processado no arquivo, ou é da responsabilidade do arquivista? Que garantias serão dadas sobre o resultado do projeto? A lista de inquéritos pode continuar indefinidamente.

É fundamental estabelecer necessidades tão cedo quanto possível no processo.

Wijnen (2004) estabelece os seguintes tipos de necessidades do projeto como um auxílio à memória:

  • Pré-requisitos
  • Requisitos para a funcionalidade
  • Requisitos para a funcionalidade
  • Restrições de design

As condições prévias fornecem o enquadramento em que o projeto deve ter lugar.

A legislação, as regras que regem as condições de trabalho e os procedimentos de aprovação são todos exemplos. Estes critérios são imutáveis dentro do projeto.

É importante lembrar que as especificações dos requisitos são aquelas que têm a ver com a qualidade da saída final — especificações técnicas relacionadas com a forma como os resultados do projeto serão usados. Por exemplo, o número de erros deve ser reduzido em 90% após o fim de um projeto de software. As restrições de design, por outro lado, são requisitos específicos do projeto. Os produtos químicos perigosos e os parceiros estrangeiros com normas laborais questionáveis não podem ser incluídos no projeto, como exemplo.

Durante a fase de definição de um projeto que incluía a construção de uma aplicação web para um consórcio de grandes organizações, não foram tomadas decisões sobre o navegador que o programa apoiaria. O consórcio pensou que seria o Microsoft Explorer, uma vez que era “o navegador de todos.”

Os desenvolvedores construíram a aplicação no Firefox porque já estavam familiarizados com o navegador e tinham várias funcionalidades especialmente úteis ao longo do desenvolvimento. Como a maioria dos sites projetados para o Firefox também aparecem ótimos no Explorer, a mudança foi primeiro impercetível. No entanto, para a conclusão do projeto, o cliente começou a protestar que o site “não estava bonito”. Os programadores, que estavam a aceder ao site através do Firefox, ficaram perplexos com a denúncia.

Quando se percebeu que os dois navegadores eram incompatíveis, os programadores responderam defensivamente: ‘Não podem instalar o Firefox? Afinal, é um elogio.” Por outro lado, as organizações obrigaram administradores de sistemas governamentais que, por qualquer razão, se recusaram a instalar o Firefox ao lado do Explorer.

Mesmo que quisessem instalá-lo, o procedimento teria sido longo, e teria havido despesas adicionais associadas ao tempo gasto pelos administradores do sistema no trabalho. Finalmente, determinou que a aplicação teria de se adaptar ao Explorer. Isto exigiu um esforço significativo, o que levou a que o projeto ficasse mais atrasado do que já estava, exigindo a negociação dos custos adicionais. Uma investigação posterior revelou que as várias organizações estavam a usar versões díspares do Microsoft Explorer.

É fundamental que todas as partes interessadas envolvidas no projeto, especialmente os utilizadores finais que utilizarão o resultado do projeto, participem ao longo da fase de definição. Como os clientes finais muitas vezes não são os que encomendam o projeto, são frequentemente negligenciados. Durante a fase de definição, o cliente, que paga o projeto, é convidado a contribuir para os requisitos. No entanto, a iniciativa ganha ao convidar futuros utilizadores. Como ponto de partida, é benéfico estabelecer reuniões com todas as partes interessadas ao longo da fase de definição do projeto.

Mais tarde, os utilizadores (jovens) envolveram-se no desenvolvimento de um videojogo educativo. Quando o jogo estava quase pronto, decidiu testá-lo com um grupo de jovens. As suas primeiras avaliações pareciam moderadas e amigáveis. No entanto, quando pressionados, reconheceram que tinham achado o jogo “muito aborrecido” e que “não o jogariam por si próprios. Se estes jovens se envolvessem no início do projeto, o jogo teria sido, sem dúvida, um sucesso. Atualmente, o jogo está quase sem colocação num site da Internet.

A fase de definição produz uma lista de necessidades de todas as partes interessadas envolvidas no projeto. Cada condição, é claro, tem um inverso.

Quanto mais complicado for o trabalho, mais tempo e dinheiro serão necessários. Além disso, alguns critérios podem colidir uns com os outros. Novas máquinas de cópia destinadas a serem mais amigas do ambiente; devem igualmente satisfazer as normas de segurança contra incêndios. Os regulamentos que regem a segurança contra incêndios obrigam à utilização de materiais retardadores de chama, menos ecológicos. Como mostrado nesta imagem, deve ser abordado.

Finalmente, é criada e submetida aos decisores do projeto uma lista de critérios definidos. Após a aprovação da lista, o processo de conceção pode iniciar-se – a maioria dos acordos entre o cliente e a equipa de projeto alcançada até ao final da fase de definição.

A lista de requisitos estabelece os parâmetros dentro dos quais o projeto deve funcionar.

Esta lista é usada para avaliar a equipa do projeto. Como resultado, o cliente não pode adicionar necessidades adicionais após a fase de definição.

Uma instalação informática criada como parte de um projeto inclui uma nova exposição num museu. Devido à ausência de uma fase decisiva no projeto, não foram alcançadas negociações concretas entre o museu e os responsáveis pela construção da instalação. Quando o computador da instalação falhou a meio, o museu acreditava que a garantia do projeto iria cobri-la. A equipa do projeto tomou uma posição contrária — exigiu que as negociações entre os diretores chegassem a um acordo.

Design #

O conjunto de requisitos da fase de definição pode ser utilizado para orientar as decisões de conceção. Durante a fase de conceção, são criados um ou mais desenhos que parecem cumprir o objetivo do projeto. A fase de design pode produzir dioramas, desenhos, gráficos de fluxo, árvores do local, desenhos de ecrã HTML, protótipos, impressões de imagem e esquemas UML, dependendo do tópico do projeto. Os líderes do projeto usam estes desenhos para escolher o design final para o projeto. Segue-se a fase de desenvolvimento. Uma vez selecionado um design, não pode alterar ao longo das fases seguintes do projeto como com a frase que define.

A expressão «departamento de design» não era adequada neste caso; em vez disso, referia-se a um grupo de designers que colaboraram. Além disso, todos estavam muito ocupados, incluindo o chefe do departamento.

Um projeto exigiu a criação de uma gama de projetos que foram fundamentais para o sucesso do projeto. Os desenhos desenvolvidos por um jovem designer na equipa do projeto. Embora o chefe da equipa de design tenha sido, em última análise, responsável pelos projetos, ele nunca esteve presente em reuniões de equipa de projeto durante as quais revê os projetos. O chefe da projeção sempre o convidou e enviou-lhe e-mails com desenhos do seu jovem colega, mas os e-mails foram ignorados. O líder do projeto e o jovem designer acreditavam incorretamente que o chefe do departamento tinha aceitado os projetos. A fase de implementação começou. Quando o projeto estava quase concluído, entregou o resultado ao chefe do departamento, que ficou furioso e ordenou que tudo pudesse ser refeito.