Relington. Sobre seu comentário: "*Apresentei uma monografia no qual eu procurava uma interseção entre o ITIL e o PMBoK. Não deu muito certo, pois GP se aplicaria mais ao CMDB ou projetos que visassem correções de falhas e etc. *" Vejo as seguintes formas de complementar ITIL e técnicas de Gestão de Projeto (PMBoK).
1) Tratar a adoção de ITIL por uma organização como um projeto. Voltando ao nosso post anterior: as técnicas do PMBoK seriam o Eixo Gestão de Projetos e as técnicas/métodos para redesenhar os processos, definir KPIs, mapear papéis e responsabilidades seriam o Eixo "Metodologia " (Ciclo de Vida do Projeto. 2) Uma vez adotados processos conforme o modelo ITIL (desde que o Processo Gerenciamento de Mudanças e de Liberações esteja concluído) e com os processos "rodando", a implementação de uma Mudança no ambiente de TI, quando justificado, poderia ser feita utilizando-se as práticas do PMBoK. Ou seja, o próprio processo de Gerenciamento de Mudanças e de Liberações poderia estar "impregnado" com práticas do PMBoK (pelo menos aquelas de tamanho e custos justificáveis). 2.1) Forçando a barra, até o processo de Gerenciamento de Problemas poderia ter alguma coisinha de PMBoK... mas aí acho que vão me bater!!! 3) Numa organização aderente aos processos do ITIL v3, todo o ciclo de Estratégia de Serviços, Design de Serviço e Transição do Serviço, poderia ser executado de forma projettizada, sob as técnicas do PMBoK. Estes processos do ITIL poderiam ser as fases do ciclo de vida de um projeto. 4) Como você mesmo falou, a implantação de um CMDB pode ser tratado como um projeto. Só insisti no assunto, por que gosto dessa discussão e acho que temos que sempre ver as relações entre esses frameworks como complementares. Abraços. Marcel Fleming 2009/8/14 Relington <[email protected]> > > > Marcel, > > Perfeito!!! Teu texto ficou grande, e na metade, quando eu já pensava em > falar sobre o RUP que menciona a participação do Gestor ou Gerente de > Projetos em varias etapas, voce pediu calma. > > Apresentei uma monografia no qual eu procurava uma interseção entre o ITIL > e o PMBoK. Não deu muito certo, pois GP se aplicaria mais ao CMDB ou > projetos que visassem correções de falhas e etc. Tambem verificamos que o > CMMI tem buscado incorporar algumas coisas do ITIL, e já possuia disciplinas > de GP. > > O RUP e o CMMI, com ou sem apoio do PMBoK, realmente são aplicaveis a > situações em que temos equipe para preencher tanta papelada. Voce tambem > disse certo. Não é que inexista a documentação no SCRUM, porem lembretes, > fotos, entre outros, servem. > > O Ricardo Vargas, um dos membros do PMI-MG, presente no conselho diretor > mundial, mencionou a poucos meses sobre este metodo, e tambem as alterações > no PMBoK 4 ED. Ele tem uma serie de podcasts, são curtinhos, e outros > downloads. Se alguem se interessar e quiser baixar, o site dele: << > http://www.ricardo-vargas.com/>> > > Abraço. > > > *On Qui 13/08/09 17:30 , Marcel Fleming [email protected] sent: > * > > > > > > Anderson, Relington.... legal essa discussão. > > > > Vou tentar botar mais lenha na fogueira, no bom sentido. > > > > Se lembram que no meu primeiro post eu mencionei que há dois eixos ou > dimensões na gestão de um projeto? Então. Se vocês tiverem acesso ao > PMBoK, sugiro darem uma olhada no Cap. 2, Project Life Cycle and > Organization. > > > > Mas vamos partir de uma situação utópica... > > > > O Bill é o dono de uma software-house que pensou em um produto inovador, > tem recursos disponíveis de sobra, não precisa dar resultado para a empresa, > nem dar satisfação pra ninguém, não tem ninguém para dar palpite no produto > ou exigir que ele esteja pronto num dado momento (os tais chamados > stakeholders). > > > > Ele monta a equipe e define um processo de desenvolvimento, por exemplo, > baseado em RUP, uma equipe de trabalho. Suponha que ele vai dizer como o > sistema deve funcionar. Então ele pega uma parte da equipe, os analistas de > negócio ou de requisitos, e eles começam a escrever Casos de Uso mais > importantes ou críticos para o sistema. Esses Casos de Uso serão passados > para um arquiteto, na chamada fase de Concepção, o arquiteto, com base > nesses Casos de Uso, irá definir alguns padrões arquiteturais da aplicação, > e definir que, na fase seguinte, a chamada Elaboração, alguns desses Casos > de Uso serão desenvolvidos para mitigar ou eliminar alguns riscos que ele > viu no conjunto de Casos de Uso. > > Na fase de Elaboração, estes Casos de Uso (documentos) serão passados para > os programadores ou arquitetos para serem codificados e testados, de forma a > validar as definições arquiteturais. Em paralelo, os analistas de negócio > continuam a escrever os Casos de Uso restantes, menos complexos ou críticos, > que serão passados para os desenvolvedores na fase de Construção e por aí > vai. > > > > De um modo geral, o que descrevi acima, muito sucintamente, é uma > metodologia de desenvolvimento baseado em RUP. Ela fala em papéis (analista > de negócios, arquitetos), artefatos (casos de uso), fases (Concepção, > Elaboração...). Seria o Eixo de Processo de Desenvolvimento. > > > > Na visão do PMBoK, este processo acima descreve o chamado Ciclo de Vida do > Projeto, que está muito associado com o tipo de projeto: para construção de > uma casa, o ciclo é outro; para a realização de um evento, seria um outro > ciclo de vida; para os preparativos de um casamento e lua de mel, ainda um > terceiro ciclo de vida. > > > > Tirando alguns pontos, as atividades neste ciclo são voltadas para a > entrega do produto final - o software ou sistema sendo desenvolvido. Como o > Bill não tá nem aí para prazo, custo, riscos.. o processo acima *quase *não > tem nada de Gestão de Projetos. Muita calma nessa hora, conhecedores de > RUP!!!! -> estou deliberadamente aqui deixando de lado o workflow de > gerência de projeto que o RUP prevê. > > > > Só que, de repente, o Bill teve que fazer uma parceria com uma empresa que > achou a ideia do software interessante. Só que essa empresa passou a se > preocupar com os custos do projeto, o prazo de entrega, a qualidade do > produto a ser entregue etc... Então essa empresa trouxe para a empresa de > Bill toda uma parafernália de processos, indicadores e melhores práticas de > gestão de projetos, de forma que: > > · o escopo seja controlado – o Bill não poderá mais fazer as > mudanças que quiser a seu belprazer, nem achar que nunca haverá mudanças. > Todas as mudanças passam então a ser avaliadas com relação à importância > para o projeto, e impacto no custo e prazo, se trará riscos ou não e, se > aprovadas, o cronograma, o orçamento do projeto terá que ser revisto. > > · o custo e o prazo sejam monitorados e controlados: mecanismos > que permitem identificar eventuais desvios de custo, suas causas e agir, > proativamente, na solução desses problemas. > > · os stakeholders (agora eles são vários, antes era só o Bill) > sejam constantemente e corretamente informados do andamento do projetos, de > seus problemas e das estimativas para seu término (quanto, de fato, o > projeto IRÁ custar ao seu final?), das mudança de escopo, prazo e custo... > > Estas ferramentas e práticas que a gestão de projetos traz é que são > propostas pelo PMBoK – é o eixo Gestão de Projetos. > > > > È claro que os dois eixos, Processos (Metodologia) de Desenvolvimento e o > Gestão de Projetos se sobrepõe aqui e ali. Como eu mesmo brinquei acima, o > RUP prevê uma disciplina de gestão de projetos, menos completo que o PMBoK, > mas que pode perfeitamente ser o modelo dependendo das circunstâncias. Não > estou dizendo que as metodologias de desenvolvimento não se preocupassem com > prazo, escopo etc... mas apenas entendo que a separação desses dois eixos > nos dá uma visão mais clara dos papéis e da organização de um projeto. > > > > Quanto ao SCRUM, nesta visão ele é uma opção ao RUP. O Scrum é uma das > metodologias ágeis, como o XP, que surgiu do chamado Manifesto Ágil, que > propõe, entre outras coisas, que se faça somente o essencial em termos de > documentação, e uma aproximação mais do cliente ou usuário, daquele que dirá > o que deve ser feito. Um dos principais motivadores é o reconhecimento de > que nos métodos tradicionais gasta-se muito esforço na produção de > documentos que muitas vezes não transmitem direito os requisitos e depois > nunca são utilizados. E pior, ao não transmitirem os requisitos de forma > não ambígua e completa, corre-se o risco de entregar , no final, algo que > não era o que o usuário queria. > > > > Ao contrário do que possa parecer, há bastante planejamento e disciplina > nos métodos ágeis. O Scrum pode e deve, assim como o RUP, ser usado em > conjunto com as práticas de gestão de projetos. O número de sprints é > definido no início, e no começo de cada sprint tem-se um planejamento > daquilo que caberá no sprint. > > > > Por fim, se estivermos falando de uma implantação de um pacote pronto (um > ERP por exemplo), a gente pode ter uma outra metodologia, no lugar da > metodologia de desenvolvimento, com fases diferentes, artefatos e papéis > diferentes. Mas ainda assim haverá o eixo de Gestão de Projetos. > > > > E mais, as práticas do eixo de Gestão, propostas pelo PMBoK, podem ser > usadas de maneiras análogas num projeto de adoção de ITIL em uma organização > de TI. > > > > Sobre o Prince2, não o conheço bem, mas imagino que seja um “substituto” > para as práticas do eixo de Gestão de Projetos que o PMBoK propõe. > > > > > > Abraços. > > > > > > > > 2009/8/12 Terra - Anderson M. Pereira <[email protected]> > >> >> >> Scrum é um processo de gerenciamento de projetos ágeis, adaptado para a >> área de desenvolvimento de SW. >> >> >> >> Dentre as técnicas de utilização do Scrum, há a entrega de produtos em >> períodos de tempo pré-estabelecidos, nunca inferiores a uma semana ou >> superiores a trinta dias. >> >> >> >> Para estimular o contato entre empresa e cliente, os projetos são >> interrompidos em períodos regulares de tempo. A essas ações dá-se o nome de >> Sprint. Ao término de cada Sprint, o cliente recebe um conjunto de >> funcionalidades desenvolvidas e prontas para serem utilizadas. >> >> >> >> Importante a participação ativa do cliente no processo de desenvolvimento. >> >> >> >> >> >> >> att >> >> >> >> Anderson Marcelino Pereira >> >> Cel.: + 55 ( 11) 8317-5537 >> >> >> >> *De:* [email protected] [mailto:[email protected]] *Em nome >> de *Cleyton Santana de Sousa >> *Enviada em:* terça-feira, 11 de agosto de 2009 19:50 >> *Para:* [email protected] >> *Assunto:* Re: [itsm_br] Implementação ERP >> >> >> >> >> >> scrum é para desenvolvimento de software, certo? >> Pelo que sei, são metodologias ágeis para gerencia de SW. >> >> sds, >> >> Cleyton Santana de Sousa >> >> COBIT Certified >> ITIL Foundation Certified >> Microsoft Certified Professional >> >> http://csantanaes.blogspot.com >> Gestão de TI e Gerenciamento de Projetos >> >> "A mente que se abre a uma nova idéia jamais voltará ao seu tamanho >> original" >> (Albert Einstein) >> >> 2009/8/10 Relington <[email protected]> >> >> >> >> Gislaine, >> >> >> >> Se a tua equipe for até 10 pessoas ou projetos curtos, concordo com o >> Marcel. Gerenciar projetos em TI pode ser bom dar uma olhada no Scrum. >> >> >> >> abs, >> >> >> >> Relington >> >> >> >> >> >> ----- Original Message ----- >> >> *From:* Marcel Fleming >> >> *To:* [email protected] >> >> *Sent:* Friday, August 07, 2009 3:37 PM >> >> *Subject:* Re: [itsm_br] Implementação ERP >> >> >> >> >> >> Anderson. >> >> >> >> Na minha opinião, o PMBOK para quem tá começando e precisando decidir como >> gerenciar, em um tempo rápido, não é a referência ideal. Ele diz tudo que >> deve ser feito, mas não é muito prático em mapear circunstâncias, tipos de >> projetos versus grau de formalismos do processo. >> >> >> >> Neste sentido, algumas leituras que eu recomendaria: >> >> * Gestão de Projetos - Harold Kerzner >> >> * Visualizing Project Management - Kevin Forsberg et alii >> >> * The One Page Project Manager - Clark Campbell >> >> >> >> Algum livro que fale sobre PMO pode ser útil, mas não me ocorre nenhum >> agora. >> >> >> >> >> >> Mas talvez alguns cursos possam ser mais efetivos e rápidos. Algumas das >> entidades que dão curso preparatório também fornecem cursos com uma visão >> mais prática de gestão. >> >> >> >> Abraços. >> >> >> Marcel. >> >> 2009/8/5 Terra - Anderson M. Pereira <[email protected]> >> >> >> >> Bom dia Gislaine >> >> >> >> Parabéns e sucesso em seu novo desafio! >> >> Você já leu o PMBOK? >> >> Eu acredito que seria um ponto de partida legal para ter a visão geral de >> Gerenciamento de Projetos com base nas melhores práticas e daí então você >> dentro do seu projeto e do seu cenário ter visão de quais templates serão >> importantes ou não para o Gerenciamento do seu Projeto. Atual e os que virão >> pela frente. >> >> >> >> Sucesso >> >> >> >> Anderson Marcelino Pereira >> >> >> >> >> >> *De:* [email protected] [mailto:[email protected]] *Em nome >> de *Gislaine Bueno >> *Enviada em:* segunda-feira, 3 de agosto de 2009 21:01 >> *Para:* [email protected]; [email protected]; >> [email protected]; [email protected]; >> [email protected] >> *Assunto:* [itsm_br] Implementação ERP >> >> >> >> Boa Noite, Amigos.. >> >> >> >> Estou iniciando um trabalho novo na Area de Projetos, antes trabalhava com >> Infra-Estrutura e agora vou para a area de desenvolvimento/sistemas e >> implementação de ERP´s. >> >> >> >> Gostaria da ajuda de vcs para entender quais os docs de Projetos que se >> aplicam para ambas as áreas. >> >> >> >> PIP (plano de integração projeto) >> >> PGM (plano mudança), PGR(plano risco), etc.. >> >> >> >> Um Abração! >> >> >> >> Gislaine >> >> >> ------------------------------ >> >> Veja quais são os assuntos do momento no Yahoo! + Buscados: Top >> 10<http://br.rd.yahoo.com/mail/taglines/mail/*http:/br.maisbuscados.yahoo.com/>- >> Celebridades<http://br.rd.yahoo.com/mail/taglines/mail/*http:/br.maisbuscados.yahoo.com/celebridades/>- >> Música<http://br.rd.yahoo.com/mail/taglines/mail/*http:/br.maisbuscados.yahoo.com/m%C3%BAsica/>- >> Esportes<http://br.rd.yahoo.com/mail/taglines/mail/*http:/br.maisbuscados.yahoo.com/esportes/> >> >> Nenhum vírus encontrado nessa mensagem recebida. >> Verificado por AVG - www.avgbrasil.com.br >> Versão: 8.5.392 / Banco de dados de vírus: 270.13.44/2282 - Data de >> Lançamento: 08/04/09 18:01:00 >> >> >> >> >> >> Nenhum vírus encontrado nessa mensagem recebida. >> Verificado por AVG - www.avgbrasil.com.br >> Versão: 8.5.392 / Banco de dados de vírus: 270.13.50/2296 - Data de >> Lançamento: 08/12/09 06:09:00 >> >> > > >
