GPS - Gestão de projeto de software Professor Emiliano S. Monteiro
Gerenciamento de Mudança Nível operacional Itil cobit Togaf RFC Request for change
Gerenciamento de Mudança System Center: Microsoft Configurarion Manager Operation Manager Service manager Hyper server v
Gerenciamento de Mudança O.S.
Gerenciamento de Mudança
Gerenciamento de requisitos Requisitos Avaliação de requisitos Avaliação de custos Priorização Obter aprovação Controlar os requisitos Avaliação de cronograma Formulário para submeter requisitos, alimentar um banco de dados (ou vai para email)
Gerenciamento de requisitos Formulário para submeter requisitos Fila para análise de solicitações Processo de avaliação Requisitos novos entrar na fila de produção Análise de risco
Gerenciamento de Requisitos
Gerenciamento de Requisitos
Gerenciamento de Requisitos
Sobre gerenciamento de mudança x requisitos Ao reparar os fluxos anteriores podemos perceber que são bastante similares de abstrairmos que um requisito novo pode ser implantando em um sistema que já esta em produção e que solicitações de mudanças do parque tecnológico podem ocorrer em projetos de software que nem começaram ainda (tanto em projetos de hardware, redes ou software). Geralmente tem-se em mente que o gerenciamento de requisitos é utilizado apenas nos processos de desenvolvimento de sistema e que o gerenciamento de mudanças é utilizado apenas nas modificações da infra estrutura; quando na verdade podemos inclusive trocar etapas entre eles ou até criar um fluxo personalizado.
Alguns conceitos comuns nos desenhos apresentados 1. Existe sempre um personagem que inicia a solicitação de mudança ou de requisitos pois isto atende sua necessidade ou ele percebe que algo pode dar errado (antecipa-se ao problema) (stakeholde ou nível operacional). 2. Um personagem deve decidir se aceita a solicitação ou não, ou até se ele a prioridade da solicitação e a submete a um conselho (ou grupo de analista seniors) para uma aprovação superior (alguns pedidos não necessitam de aprovação). 3. As solicitações devem se registradas, categorizadas, priorizadas, analisadas, estuadas, colocadas em um cronograma para posterior implementação, e por último o novo ambiente ou software modificado deve ser documentado. 4. Os fluxos (workflow) sempre tem mais de um ponto de decisão e podem retornar ao começo em algum ponto, pois uma solicitação que foi rejeitada hoje pode ser aceita amanhã.
Exemplo de change log
Road map
Alguns fatos sobre projetos... 1. São as pessoas trabalhando que fazem os projetos andarem e entregarem resultados, não os processos ou sistemas. 2. A vontade dos empregados e gerentes em aceitar mudanças vinda dos projetos é tão importante quanto qualquer outro assunto relacionado à projetos. 3. Um projeto pode ser visto como uma organização temporária, estabelecida pela empresa para levar a cabo atribuições que são do interesse da mesma. 4. O refinamento de técnicas de gestão de projetos, fornecem um grau de controle adequado que possa permitir o sucesso do projeto.
Passado futuro Presente
http://st.merig.eu/index.php?id=204&l=5
Pirâmide das necessidades de Maslow
Perguntas para cada fase do projeto Início e planejamento Implementação Monitoração/Controle Revisão e finalização 1. Por que este projeto existe? 2. Quem são os possíveis parceiros neste projeto? 3. Quais são os principais objetivos e os resultados desejados? 4. Qual é o escopo do projeto (incluindo limites)? 5. Quais recursos organizacionais são necessários? 1. Quais são as principais atividades? 2. Quais capacidades organizacionais estão disponíveis? 3. Como engajar stakeholders internos e externos? 1. Como será assegurada a implementação das atividades? 2. Quais são os critérios, métodos e indicadores em monitoramento, avaliação e garantia de qualidade? 1. Conseguimos os resultados desejados? Por quê? Por que não? 2. Quais foram as principais lições identificadas? 3. Como podemos garantir aprendizado das lições? 4. Compartilhamos nossas descobertas? Como?
WBS (Work Breakdown Structure) EAP (estrutura analítica do projeto) A estrutura analítica do projeto (WBS) é uma entrega chave do projeto que organiza o trabalho da equipe em seções gerenciáveis. (quebra o projeto em partes!) O PMBOK define a estrutura analítica do projeto como uma "decomposição hierárquica orientada para entrega do trabalho a ser executado pela equipe do projeto". A estrutura analítica do projeto define visualmente o escopo em partes gerenciáveis que uma equipe de projeto pode entender, pois cada nível da estrutura analítica do projeto fornece mais detalhes e definição. É uma lista de todas as tarefas que a equipe precisa concluir no projeto. Depois que o gerente de projeto lista todas as tarefas, ele as vincula a tarefas predecessoras que controlam a sequência das tarefas. Em seguida, o gerente de projeto atribui recursos a cada tarefa na EAP. Os recursos podem ser pessoas, contratados ou materiais. Em seguida, o gerente de projeto calcula a duração de cada tarefa na EAP. Isso completa o cronograma do projeto.
https://sites.google.com/site/r10ce4107/work-breakdown-structure-wbs
https://www.researchgate.net/figure/example-work-breakdown-structure-wbs_fig2_224829566
Pert PERT é uma ferramenta de planejamento de gerenciamento de projetos usada para calcular a quantidade de tempo que levará para concluir um projeto. PERT significa (Program Evaluation Review Technique) técnica de revisão de avaliação de programas. Gráficos PERT são ferramentas usadas para planejar tarefas dentro de um projeto. Foram criados na década de 1950 para ajudar a gerenciar a criação de armas e projetos de defesa para a Marinha dos EUA. É um método similar ao chamado Caminho Crítico. O PERT é semelhante ao caminho crítico, pois ambos são usados para visualizar a linha do tempo e o trabalho que deve ser feito para um projeto. O PERT é calculado para trás a partir de uma data final fixa, uma vez que os prazos do contratante normalmente não podem ser movidos.
https://cdn.ttgtmedia.com/whatis/images/pert_chart.jpg
Normas ISO 1. ISO 10006:2003 Linhas gerais para gestão da qualidade em projetos. 2. ISO 21500:2012 Guia para gestão de projetos. 3. ISO 31000:2009 Princípios e linhas gerais para a implementação da gestão de risco 4. ISO 31010:2009 Técnicas de levantamento de risco 5. ISO 19600:2014 Guia para gestão de sistemas de conformidade.
Algumas habilidades de relacionamento relacionadas ao PMBOK para o gerente de projetos 1. Liderança 2. Construção do espírito de equipe 3. Motivação 4. Comunicação 5. Influência 6. Tomada de decisão 7. Consciência política e cultural (cultura organizacional) 8. Negociação 9. Gestão de conflitos
Equipe do projeto x Equipe de gerenciamento do projeto Equipe de projeto = equipe executora Equipe de gerenciamento do projeto = administração do projeto e suas atividades correlatas como: cronograma, orçamento, relatórios de status, etc.
Estrutura organizacional Tradicional Organização por projeto Projeto
Processo básico Monitora Planejamento Iniciação Execução Encerramento Controla
Processo básico dentro de um ciclo maior Estágio 1 / fases 1 Estágio 2/Fase 2 Estágio 3/Fase 3
Custo x Pessoal Custo x Pessoal Monitora Maior quantidade de pessoal Planejamento Iniciação Execução Encerramento Poucas pessoas Controla Poucas pessoas Tempo Em verde = andamento do projeto
Gold plating Banhar a ouro algo que não necessitava. Ocorre em situações como "Já que isso será feito, aproveitem para resolver este outro caso também"! Este comportamento acarreta riscos ao projeto pois agregou um item não planejado.
Principais problemas no gerenciamento de projetos 1. Não cumprimento dos prazos estabelecidos 2. Mudanças de escopo constantes 3. Problemas de comunicação 4. Recursos humanos insuficientes capacitada 5. Riscos não avaliados corretamente 6. Mudanças de prioridade constantes 7. Escopo de projeto com nível de detalhe insuficiente 8. Não cumprimento do orçamento estabelecido 9. Disputas por recursos entre as gerências funcionais e o gerente de projetos 10. Problemas na administração do trabalho/contratos de terceiros 11. Problemas políticos 12. Produtos mal especificados 13. Problemas culturais 14. Expectativa do cliente (interno ou externo) desalinhada com a realidade do projeto 15. Falta de autoridade do gerente do projetos 16. Recursos humanos sem as competências necessárias 17. Recursos financeiros insuficientes 18. Falta de apoio da alta administração
Cronograma GANTT EAP PERT