AULA 7 GESTÃO DE PROJETOS TECNOLÓGICOS COMPLEMENTO 1

Prévia do material em texto

1 
Na tramitação de uma mudança, pode ser solicitado para as partes interessadas 
que se use um formulário padronizado contendo as informações necessárias e 
assim facilitando o entendimento. Este controle integrado de mudanças é 
importante ser definido já no planejamento do projeto, ou seja, antes do seu 
início, consequentemente, todos terão ciência como as mudanças serão tratadas 
durante o andamento. 
 
Faremos agora um comentário da vida real: Na verdade, havendo 
obrigatoriedade em preencher um formulário padronizado, as pessoas que 
eventualmente iriam solicitar bobagens pensarão duas vezes. Isto pode eliminar 
a perda de tempo desnecessária, pois uma mudança solicitada deve ser bem 
fundamentada, deve dar um pouco de trabalho para as pessoas que 
eventualmente só queiram “aparecer” não façam. 
 
Assim, todas as mudanças precisam ter os impactos decorrentes analisados, 
como prazo, custo, qualidade, riscos e se estão relacionadas à satisfação do 
cliente. É também muito importante verificar se a mudança está vinculada com 
os objetivos do projeto, ou seja, se é um fator crítico de sucesso para o produto 
pretendido. 
 
Para que se façam estas avaliações, pode ser montado um comitê, sendo 
composto pelo gerente de projetos, membros da equipe e outras partes 
interessadas que forem cabíveis na avaliação em curso. As mudanças, 
normalmente, devem ser negociadas com o cliente, em alguns casos, a 
aprovação terá até que ser levada ao patrocinador, pois pode envolver o 
aumento no orçamento. Lembre que é o gerente de projetos quem negocia estas 
mudanças e nem todas poderão ser aceitas. 
 
Uma vez que a mudança foi aprovada deve ser documentada e incorporada ao 
cronograma, ao escopo e ao orçamento do projeto. A agenda do projeto, no 
Project, deverá ser alterada. Assim como pode ser necessário atualizar o plano 
do projeto. 
 
 
 
 2 
 
É uma boa prática manter as versões dos documentos que utilizamos no projeto, 
isto é importante, temos que ter controle sobre os documentos alterados, pois 
mais tarde, poderemos precisar avaliar o histórico de evolução do projeto, 
assim, podemos obter várias linhas de referências para fazermos comparações. 
Para isso, recomenda-se estabelecer um sistema de gerenciamento de 
configuração que se refere aos documentos criados durante o projeto. Este 
sistema não necessariamente precisa ser um software, pode ser uma pasta no 
servidor onde todos os documentos sejam guardados com um controle de versão 
nos nomes dos arquivos. 
 
É importante que cada documento do projeto tenha um campo chamado versão, 
isto evita que alguém use um plano desatualizado. Existem softwares de 
gerenciamento de projetos que possuem este controle de documentos, ou 
gerenciamento de configuração, já embutidos no próprio software. 
 
 
Modelo de solicitação de mudança em projeto: 
 
Este é um exemplo de formulário modelo para que as partes interessadas 
formalizem as suas solicitações de mudança. É importante ter estes registros, 
 
 
 
 3 
pois, mais tarde, se o projeto atrasar e custar mais do que foi previsto, e isto 
acontecer devido às mudanças solicitadas, o gerente terá estes registros como 
uma ferramenta para justificar ou explicar os atrasos no cronograma e o estouro 
de orçamento. 
 
O formulário exemplo foi obtido em: 
http://www.trainning.com.br/download/planodeprojeto.pdf 
Se procurarmos no Google encontraremos vários modelos para gerenciar projetos. 
Existem também alguns softwares que já possuem este formulário de solicitação de 
mudanças (CR´s) no formato eletrônico como uma funcionalidade do sistema, 
assim, os usuários podem fazer as solicitações de mudanças através da intranet. 
 
 
 
 4 
De acordo com http://wthreex.com/rup/process/artifact/ar_crqst.htm#Top, os 
seguintes atributos são úteis para tomar uma decisão sobre qualquer formulário 
enviado: 
Tamanho 
 Que volume de trabalho existente precisará ser alterado? 
 Que volume de trabalho extra precisará ser adicionado? 
Alternativas 
 Existe alguma? 
Complexidade 
 A mudança proposta é fácil de ser efetuada? 
 Quais são as possíveis ramificações provenientes dessa mudança? 
Gravidade 
 Qual é o impacto da não implementação desta solicitação? 
o Há alguma perda de trabalho ou de dados envolvida? 
o Esta é uma solicitação de melhoria? 
o É um problema secundário? 
Cronograma 
 Quando a mudança é necessária? 
 Ela é viável? 
Impacto 
 Quais as consequências em efetuar a mudança? 
 Quais as consequências por não efetuar a mudança? 
Custo 
 Qual é a economia proveniente desta mudança? 
Relacionamento com outras mudanças 
 Outras mudanças substituirão ou invalidarão esta ou isso depende de mais 
alterações? 
Teste 
 Há algum requisito especial de teste? 
 
 
 
 5 
Exemplo de Formulário de Solicitação de Mudança: 
1. Identificação 
 Projeto; 
 Número da solicitação de mudança; 
 Tipo de solicitação de mudança: (Problema ou Melhoria); 
 Cargo; 
 Data de envio; 
 Originador; 
 Prioridade da solicitação de mudança. 
2. Problema Atual 
 Descrição do problema atual; 
 Falha crítica; 
 Dano; 
 Melhoria; 
 Novo requisito; 
 Condições sob as quais o problema foi observado; 
 Ambiente atual: Hardware; 
 Sistema operacional; 
 Compilador; 
 Origem do problema atual; 
 Impacto do problema atual no custo ou na economia. 
3. Mudança Proposta (Originador) 
 Descrição da mudança proposta; 
 Custo estimado para implementar a mudança proposta. 
4. Mudança Proposta (Equipe de Revisão de Mudanças) 
 Ação; 
 Aprovada; 
 Desaprovada; 
 Adiada; 
 Descrição da mudança proposta; 
 Itens de configuração afetados; 
 Categoria; 
 Correção de erros; 
 Melhoria; 
 Novo recurso; 
 Outros. 
5. Resolução: 
 
 
 
 6 
 Custo estimado para implementar a mudança proposta; 
 Implementador; 
 Tempo real para implementar a mudança; 
 Análise; 
 Implementação; 
 Teste; 
 Documentação; 
 Número de linhas de código afetadas. 
6. Avaliação 
 Métodos de teste; 
 Inspeção; 
 Análise; 
 Demonstração; 
 Teste; 
 Plataformas de teste; 
 Casos de teste. 
 
7. Disposição da Equipe de Revisão de Mudanças 
 Mudanças Aprovadas e Aceitas: 
- Ocorrência: As práticas de Gerenciamento de Mudanças, normalmente, são 
institucionalizadas ou estabelecidas no início do ciclo de vida do projeto. Desse 
modo, as CR’s, que integram o processo de mudança, podem surgir a qualquer 
momento, durante o curso do projeto. 
A principal origem de defeitos consiste nos resultados da execução dos testes — 
integração, sistema e desempenho. Contudo, os defeitos podem aparecer em 
qualquer ponto do ciclo de vida de desenvolvimento do software e abranger a 
identificação de documentação, casos de teste ou de uso ausentes ou incompletos. 
- Responsabilidade: Qualquer pessoa da equipe de projeto deve ser capaz de 
efetuar uma CR. No entanto, a CR (mudança) precisa ser revisada e aprovada pelo 
supervisor da pessoa que a efetuou. A arbitragem final, sobre uma Solicitação de 
Mudança, é realizada por uma Equipe de Revisão ou por um Comitê de Controle de 
Mudança (CCB). 
- Adaptação: Os campos e os dados reais necessários para identificar, descrever e 
controlar defeitos com precisão são variados e dependem do sistema de controle 
de mudanças, das diretrizes e dos padrões implementados.