Gesto de Tecnologia da Informao

Material terico
Governana e Projetos em TI

Responsvel pelo Contedo: Prof. Ms. Artur Marques Reviso Textual: Profa. Ms. Magnlia Gonalves Mangolini

Governana e Projetos em TI

Nessa unidade falaremos, de forma introdutria, da importncia do gerenciamento de projetos na rea de TI, focada no framework, proposto pelo PMBOK, no concentrado em desenvolvimento de sistemas. Para isso, podemos utilizar mtodos geis e alguns outros associados a CMMI e ao prprio PMBOK, estamos nos referindo especificamente em infraestrutura e outros tipos de projetos que ocorrem em Gesto de Tecnologia de Informao. Tambm abordaremos o framework ITIL, muito utilizado em TI para realizar a gesto de servios visando prestao de um servio melhor ao usurio e atendimento das reas da empresa que precisam de suporte. Atuam tambm em incidentes e problemas. Trata-se, atualmente, do framework mais utilizado para este fim, no Brasil e no mundo. Veremos introdutoriamente os livros que cuidam de gesto de suporte e servios. Enfatizo a leitura do material deste mdulo de forma atenta e, aps isso, voc precisa realizar os exerccios propostos.

Ateno
Para um bom aproveitamento do curso, leia o material terico atentamente antes de realizar as atividades. importante tambm respeitar os prazos estabelecidos no cronograma.

Contextualizao
Silva Filho (2006) versa que, at certo ponto, natural queles que desenvolvem novos sistemas iniciarem suas atividades de desenvolvimento antes mesmo que eles entendam o que tem de ser feito, ou seja, antes mesmo que saiba qual o problema a ser solucionado. O resultado desse tipo de atitude e tem sido o insucesso de projetos. Para trabalharmos e gerirmos um projeto, devemos trabalhar longamente no entendimento do trabalho a ser feito e nas entregas esperadas, caso contrrio, no saberemos onde temos que chegar e isso o grande causador de fracassos e problemas com clientes internos e externos a organizao e tambm a causa mais comum da insero de erros logo cedo no desenvolvimento que custaro muito caro quando forem descobertos. Isso acontece infelizmente porque h pouca preocupao do profissional de tecnologia da informao com a Gesto, principalmente dos insumos humanos e materiais necessrios para o correto aproveitamento e cumprimento dos objetivos do projeto. Problemas culturais e baixa capacitao dos colaboradores so outros problemas que recrudescem o resultado ruim dos projetos em tecnologia da informao. Renner (2008), citando Ricardo Viana Vargas do PMI board, diz que apesar do Brasil ter um nmero limitado de profissionais certificados em prticas de gerenciamento de projetos, cerca de cinco mil, e da Amrica Latina responder por apenas 4% do total mundial, a realidade muito diferente em outras partes do globo. Grande parte dos profissionais certificados no Brasil atua preponderantemente na rea de tecnologia da informao, setor que tem maior carncia e necessidade desse tipo de profissional devido complexidade dos projetos que so realizados e a criticidade empresarial que representam nos dias de hoje. As organizaes no mercado globalizado em que vivemos realizam seus objetivos estratgicos atravs de projetos. Neles esto contidas as doses de inovao investidas para produzir produtos e servios diferenciados que garantiro a sobrevivncia das empresas na economia moderna e hiper competitiva a qual vivemos. Vamos conhecer um pouco sobre as melhores prticas que tm transformado em sucesso os projetos das organizaes em todo o mundo.

Material Terico
Fundamentos de Gesto de Projetos
O conceito moderno sobre gerncia de projetos nasceu nos Estados Unidos, no final da dcada de 50 e incio da dcada de 60, motivado, entre outras coisas, pelo projeto Apollo que levaria o homem Lua. Todavia, as aplicaes iniciais das melhores prticas foram aplicadas para se realizar a anlise de sistemas computacionais e a implementao de empreendimentos fsicos, como construes complexas e bens de consumo. A gesto de projetos fornece conceitos e melhores prticas para que sejam enfrentadas as mudanas e riscos impostos pelo dia a dia da globalizao e a necessidade de lanar produtos e servios em tempos cada vez menores, com cada vez mais qualidade e valor agregado. Alm disso, a gesto de projetos oferece ferramentas e tcnicas para lidar com essas mudanas. O responsvel pela execuo e gerenciamento dessas mudanas se chama gerente de projetos. De acordo com o PMBOK (2008) um projeto um empreendimento nico que deve apresentar um comeo e um fim claramente definidos e que, conduzido por pessoas, possa atingir seus objetivos respeitando os parmetros de prazo, custo e qualidade. O que caracteriza de forma mais marcante um projeto so as categorias de entregas que ele pode proporcionar, como por exemplo:

Produtos: produto ou objeto produzido, quantificvel, podendo ser final ou intermedirio. Servios: so itens de capacidade, funes de negcio para produo, armazenagem ou logstica, desenhos ou melhorias em processos, inovao em uma abordagem de sistemas, entre outros. Resultados: relatrios, pareceres, documentos, resultados finais. Por exemplo, criao de algo inovador que gere uma documentao de patente, um projeto de pesquisa exploratria que desenvolve cincia.

Subprojetos: em vrios casos um projeto precisa ser dividido em partes devido a sua grande complexidade ou caracterstica de produo, isso auxilia em seu gerenciamento e controle. Essas partes, que foram divididas, chamamos de subprojetos. Elas so muito especficas e podem ser feitas por terceiros ou por equipes dedicadas. O mais importante que o subprojeto tratado isoladamente no faz sentido, ele precisa estar agregado ao projeto principal. Imagine que a arquitetura e modelagem do banco de dados para uma aplicao especfica em tempo real seja tratada como subprojeto, ela no tem sentido em ser desenvolvida se no houver o projeto de software que tratar estas informaes em tempo

real, ou seja, no h outra utilidade para essa modelagem que no seja servir esse software, ela no serve para outro software.

Programas: usamos esse termo para designar quando vrios projetos esto concentrados em um conjunto de melhoramentos e tticas comuns. O mais importante que eles podem ter vida prpria, alm do projeto principal. Por exemplo, vamos fazer um avio, uma das partes a turbina, ela faz parte do programa do avio, ou seja, a turbina pode ser desenvolvida para esse avio que ser construdo, mas pode ser usada por outros projetos de avies diferentes que possam utilizar o mesmo propulsor.

Gerenciamento de projetos: conforme definio do PMBOK (2008) a aplicao de conhecimentos, habilidades, ferramentas e tcnicas s atividades do projeto, cuja finalidade atender aos seus requisitos. Isso inclui, mas no se esgota em: Identificar as necessidades do projeto; Estabelecer objetivos claros, mensurveis e alcanveis; Balancear, distribuir e resolver demandas conflitantes que envolvam entre outras reas de conhecimento: riscos, qualidade, escopo, tempo, comunicao e custo; Adaptar as especificaes e abordagens, dos diferentes planos, preocupaes e expectativas dos stakeholders (partes interessadas) que na verso 5 do PMBOK uma rea de conhecimento nova.

Conforme Schmitz (2005, 16), as reas de conhecimento do PMBOK so 9 e possuem os seguintes propsitos:
Escopo: A Gerncia de Escopo assegura que o projeto inclua todo o trabalho necessrio, e to somente o necessrio, para complementar de forma bem sucedida o mesmo. Define e controla o que est e o que no est includo no projeto. A principal ferramenta a Estrutura Analtica do Projeto EAP (em ingls, WBS Work Breakdown Structure), que identifica e decompe os principais elementos do projeto. Tempo: Seus processos consideram a definio de atividades e seu sequenciamento (identificao de relacionamentos de dependncia entre elas), estimativas de recursos e durao, desenvolvimento do cronograma e seu controle. Os processos da gerncia de tempo so executados em paralelo com a gerncia de custos, uma vez que a durao de uma atividade depende diretamente da quantidade de recursos alocados para a mesma. Custo: Contempla os custos dos recursos necessrios a implantao das atividades. Ela inclui os processos necessrios para assegurar que o projeto ser concludo dentro do oramento aprovado. Seus processos so a estimativa e oramento dos custos e seu controle. As principais tcnicas e ferramentas utilizadas so: avaliao especializada de consultores, estimativas por analogia de outros projetos, estimativas por desagregao de custos (botton-up) ou modelos paramtricos.

Qualidade: Garantir que o projeto ir satisfazer as necessidades para as quais ele foi empreendido. A preocupao com qualidade deve ser estendida tambm para os fornecedores de insumos do projeto, devendo ficar claro que as referncias de qualidade da organizao devem ser seguidas nos projetos. Risco: prope a identificao, anlise e resposta aos riscos do projeto, considerando riscos internos e externos. Os processos contemplam a identificao, qualificao e quantificao dos riscos, desenvolvimento e controle de respostas, e monitoramento. A abordagem geralmente utilizada a anlise dos resultados que devem ser evitados e a monitorao de suas causas por meio do estabelecimento de gatilhos de aviso. Comunicao: Garantir a gerao, coleta, distribuio, armazenamento, recuperao e destinao final das informaes sobre o projeto de forma oportuna e adequada. Previne interpretaes errneas e garante que a informao correta esteja disponvel para quem dela necessite. RH: Contempla os processos requeridos para possibilitar o uso mais efetivo das pessoas envolvidas no projeto. Os principais tpicos a serem destacados so: liderana, negociao, comunicao, delegao, motivao, formao de equipes, gerncia de conflitos, treinamento, avaliao de desempenho, recrutamento e manuteno das relaes de trabalho. Aquisio: Inclui os processos necessrios para a obteno de bens e servios externos a organizao executora, para a realizao do trabalho. Possui as seguintes necessidades: preparao das aquisies e contrataes, obteno de propostas, seleo de fornecedores, administrao e encerramento dos contratos. Integrao: Compreende a coordenao entre os diversos elementos do projeto, atravs de processos, ferramentas e tcnicas. executada durante todo o projeto, paralelamente as demais gerncias, integrando seus resultados no Plano do Projeto.

Grupo de processos: trata-se dos macroprocessos existentes durante o ciclo de vida de um projeto e serve para demonstrar, determinar e atuar sobre documentos, relatrios, atuaes, papis e fases esperadas para saber como est situao do projeto e quais esforos esto consumindo os recursos. Essas fases so: Iniciao: Determina a existncia do projeto, so documentos e atividades de autorizao e incio. Por exemplo: contrato assinado, designao do gerente de projeto, termo de abertura do projeto. Planejamento: Cria e depura os objetivos do projeto, cria documentos estruturados de planejamento de ao necessrios para atingir as metas e o escopo do projeto. Execuo: trata da juno de recursos humanos e materiais para a execuo do projeto, o fazer, conforme estabelecido na fase de planejamento. Monitoramento e controle: estabelece medidas para controle de desempenho e previso identificando variaes contra o plano estabelecido para que possam ser tomadas medidas proativas e reativas sob as situaes encontradas. Encerramento: constitui os elementos de finalizao do projeto, entre outros a parte operacional, entregas, termos de aceite, termos de homologao e tambm a

parte administrativa, como por exemplo, ordem de emisso de nota fiscal final, encerramento de contrato, entre outros.

Figura 1: Grupo de Processos do PMBOK para Gesto de Processos. Fonte: http://professorprojeto.blogspot.com.br/2011/04/mapas-mentais-pmbok.html

Ento podemos perceber que cabe ao GP e a equipe determinar quais processos so os adequados e o grau de exigibilidade de cada processo para cada empresa e para cada projeto em especfico.

Escopo Conforme Ricardi (2005), Escopo possui os seguintes componentes: Do produto: aquilo que vai ser entregue como resultado do projeto, ou seja, um produto, servio ou qualquer outro resultado especfico. Do projeto: o conjunto das atividades que precisam ser realizadas para entregar o escopo do produto. Requisitos: representam as caractersticas de algo que ser entregue ou executado. Portanto podemos ter, em uma viso macro, requisitos de produto e requisitos de projeto. Uma das melhores formas de detalhar o escopo do projeto e

do produto atravs do detalhamento de requisitos associados. Atravs deles voc consegue aumentar a preciso em documentar as necessidades e desejos dos envolvidos (partes interessadas) no projeto. Devem atender as seguintes caractersticas: o Necessrio: ele essencial para o bom funcionamento da entrega ou do projeto. Se no estiver presente, caracteriza uma deficincia; o Completo: no exige complementos para ser atingido ou atendido, ou ento est relacionado a outros requisitos que o complementam e esta relao est explcita e de conhecimento e aprovada por todos quem interessa; o Consistente: no contradiz outros requisitos ou outros aspectos relacionados ao projeto; o No ambguo: evita interpretao ambgua; o Conciso: define uma nica coisa que deve ser feita e s a coisa que deve ser feita; o Isento de implementao: define o que deve ser feito ou atendido, e no como ocorrer; o Factvel: passvel de ser atingido durante a execuo do projeto, por um custo dentro dos limites orados, no prazo necessrio e com os recursos disponveis; o Verificvel: pode ser quantificado de forma a ter o seu atendimento verificado atravs de testes ou inspees. Componentes: um documento de escopo bem definido dever conter em sua composio pelo menos: o Critrios de aceitao o Objetivos o Premissas o Restries

Sua constituio feita dos seguintes processos e atividades: Entradas Termo de abertura do projeto Fornece a base para iniciar o detalhamento dos requisitos, pois contm a descrio do produto e alguns requisitos em alto nvel. Registro das partes interessadas Serve de referncia para identificar quais as partes interessadas que podero fornecer detalhes e definio a respeito dos requisitos necessrios.

Ferramentas e Tcnicas Entrevistas Utiliza conversas diretas com as partes interessadas, individualmente, no formato de perguntas e respostas, que devero ser registradas e aprovadas pelos entrevistados. Dinmicas de grupo Renem especialistas e partes interessadas pr-qualificadas, com o objetivo de levantar expectativas e atitudes relacionadas ao escopo do produto e/ou ao escopo do projeto. Oficinas Renem partes interessadas de diversas reas e/ou funes, com o objetivo de definir rapidamente requisitos que atendam a todos, reconciliando diferenas entre os diversos requisitos associados. Tcnica recomendada para levantamento de funcionalidades complexas e que envolvem muitos interessados. Exemplos: JAD (Joint Application Design) e QFD (Desdobramento da Funo de Qualidade). Tcnicas de criatividade em grupo Brainstorming A criatividade no repreendida, e todos podem sugerir e opinar a respeito. Tcnica de grupo nominal Amplia a tcnica de Brainstorming incluindo um processo de votao. A tcnica DELPHI So elaborados questionrios que so submetidos, de forma annima, a especialista no assunto. Estes devero responder a um facilitador que repetir o envio aos envolvidos, em ciclos de perguntas e respostas, at coletar todos os requisitos necessrios. Mapas mentais Diagramas com estrutura de itens e subitens, assuntos e descries, que denotam linha de raciocnio semelhante ao crebro humano. Diagrama de afinidade Organiza grande quantidade de ideias agrupando para reviso e anlise. Tcnicas de tomada de deciso em grupo Avalia mltiplas alternativas com o objetivo de resolver aes futuras. Gera, classifica e prioriza os requisitos do produto. Inclui os seguintes mtodos: Unanimidade Maioria

Pluralidade Ditatura

Questionrios e pesquisas Utilizados quando existe um universo muito grande de candidatos a entrevistas, e no h tempo hbil para conversas individuais. Observaes Acompanhamento e observao dos profissionais em seu ambiente de trabalho, onde a probabilidade de esquecimento de requisitos importantes minimizada, e o entendimento das necessidades fica facilitado. Prottipos Validao de modelo funcional do produto anterior sua construo. Permite ao cliente visualizar e em algumas situaes manipular o produto de forma simulada.

Sadas Documentao dos requisitos Algumas organizaes tm ferramentas especficas que permitem a documentao e o gerenciamento dos requisitos do projeto e do produto. Descreve como os requisitos individuais iro atender s necessidades de negcio do projeto, e pode ser apresentada em forma de listas categorizadas, priorizadas e associadas a outras informaes importantes e necessrias para o projeto. Plano de gerenciamento dos requisitos Define como os requisitos sero levantados, analisados, documentados e gerenciados durante todo o ciclo de vida do projeto. No menospreze a importncia deste plano, por ele ser um plano auxiliar. Sem uma definio consistente relacionada a este assunto, o projeto pode tomar um rumo de descontrole e falta de objetividade, e as consequncias sero imprevisveis. Matriz de rastreabilidade dos requisitos Associa os requisitos aos objetivos de negcio e aos objetivos do projeto. Ainda, consolida os requisitos criando referncia com outros requisitos e com as entregas do projeto.

EAP: trata-se de Estrutura hierrquica que decompe as entregas do projeto e os pacotes de trabalho associados. Ser utilizada como base para estimar e controlar escopo, custos e cronograma.

Dicionrio da EAP: Fornece o detalhamento dos componentes da EAP. Segundo o Guia PMBOK, poder conter as seguintes informaes (inclua ou retire aquelas que considerar necessrio): o o o o o o o o o Cdigo de identificador da conta Descrio do trabalho necessrio Organizao ou pessoa responsvel pela execuo Lista de marcos do cronograma Atividades do cronograma associadas Recursos necessrios Estimativa de custos Requisitos de qualidade Critrios de aceitao (da entrega, que pode conter os critrios dos requisitos associados, e mais algum que tenha a ver diretamente com a entrega. Exemplo: esta entrega dever ser validada pelo Diretor Fulano de Tal) Referncia tcnica Informaes do contrato

o o o

Linha de base do escopo: Componente do plano de gerenciamento do projeto composta pelos documentos: o Declarao de escopo do projeto o EAP o Dicionrio da EAP

Figura 2: exemplo EAP para um sistema de informao Fonte: http://www.gtics.com.br/wa_files/GRUPO-04_EAP_v1_3.png

Id.

Pacote de Trabalho Anlise da situao atual

Descrio Levantamentos dos pontos crticos e oportunidades de melhoria, suas causas e consequncias. Este pacote realizou o estudo necessrio para a definio da estratgia a ser seguida: terceirizar ou desenvolver soluo prpria Designao de funcionrios para o projeto. Definio da funo de cada membro e disponibilidade de tempo exigida.

1.1

Alocao da equipe 1.2

Definio de cada membro da equipe, por pacote de trabalho. Elaborao do Plano de Projeto Estudo e mapeamento do fluxo de trabalho para procedimento de leilo eletrnico Define como o projeto ser executado, quais so os recursos, financeiros e humanos alocados. Analisar e realizar um mapeamento de um fluxo de trabalho padro para leilo eletrnico a todos os cartrios.

1.3

2.1

Figura 3: exemplo de um dicionrio de EAP Fonte: http://desenv.tjms.jus.br/confluence/pages/viewpage.action?pageId=5505070

Tempo Para o PMBOK (2008:112), o Gerenciamento do Tempo do Projeto inclui os processos necessrios para gerenciar o trmino pontual do projeto. Marques et ali (2011) apontam e comentam os seguintes processo e atividades necessrios para a gesto do tempo no projeto, incluindo o diagrama de rede e o clculo DO CAMINHO Crtico envolvendo a tcnica CPM Critical Path Method a saber: Definir as atividades: Trata-se da identificao das aes que precisam ser feitas para produzir as entregas do projeto. Para tanto precisamos, aps identific-las, criar a EAP Estrutura Analtica do Projeto - que serve para identificar as entregas no nvel mais baixo da estrutura, a qual chamamos de pacote de trabalho. Uma vez levantada junto s reas uma lista de atividades que sero realizadas, passamos a criao da EAP e inserimos seus tempos. Porm, para iniciarmos, precisamos conhecer algumas tcnicas para definir essas atividades. Decomposio: trata-se de subdividirmos os pacotes de trabalho em atividades que, de acordo com o PMBOK, so mais gerenciveis, de forma que o trabalho e

as entregas estejam definidos at o nvel de pacote de trabalho. Este nvel o mais baixo na EAP antes do Deliverable e onde o custo e o cronograma podem ter uma estimativa mais confivel. Decompor envolve algumas atividades como: o Identificar as entregas relacionadas estruturao e organizao da EAP. o Quebrar os nveis mais elevados da EAP ampliando a granularidade, ou seja, detalhando para nveis mais baixos. o Atribuir os cdigos de identificao (taxonomia) aos itens da EAP. Lista das atividades: segundo as melhores prticas do PMBOK (2009:118), a lista das atividades uma lista abrangente que inclui todas as atividades necessrias no projeto. Inclui o identificador e uma descrio do escopo do trabalho de cada atividade em detalhe suficiente para assegurar que os membros da equipe entendam qual trabalho precisa ser executado. Lista dos marcos: o marcos datas chave no projeto e servem para designar ou identificar um evento significativo e importante no projeto. Podendo ser uma entrega, uma reunio ou uma homologao, incio ou encerramento. Sequenciar as atividades: Considera que as principais atividades de um projeto devem ser executadas levando-se em considerao a ordem e os desdobramentos das atividades que compem os pacotes de trabalho e as entregas da EAP. Para o PMBOK (2009:119), sequenciar as atividades processo de identificao e documentao dos relacionamentos entre as atividades do projeto. Essas so sequenciadas usando relaes lgicas (atividade predecessora e sucessora). Sequenciamento permite que todas as partes interessadas no projeto possam visualizar o trabalho a se realizar at a finalizao do projeto. O Gerente de Projetos dever possuir em suas mos como entradas para a execuo das atividades de sequenciamento: o Lista das atividades; o Atributos das atividades; o Lista dos marcos; o Declarao do escopo do projeto; o Ativos de processos organizacionais. Mtodo do diagrama de precedncia (MDP): constri o diagrama de rede do projeto atravs do uso de diversos ns que objetivam representar as atividades, e setas so utilizadas para que os ns fiquem ligados, mostrando suas dependncias. Esta tcnica chamada de Atividade nos Ns, a maioria dos sistemas que apoiam o gerenciamento de projetos baseada nela. O PMBOK (2009:120) determina quatro tipos de dependncias: o Trmino para Incio (TI) - o incio da atividade sucessora depende do trmino da atividade predecessora. o Trmino para Trmino (TT) - o trmino da atividade sucessora depende do trmino da atividade predecessora.

o Incio para Incio (II) - o incio da atividade sucessora depende do incio da atividade predecessora. o Incio para Trmino (IT) - o trmino da atividade sucessora depende do incio da atividade predecessora.

Figura 4: Exemplo de diagrama de precedncia MDP Fonte: http://arquivos.unama.br

Existem trs tipos de determinao que podemos utilizar: o Dependncias obrigatrias: conforme o PMBOK (2008:120), so aquelas exigidas contratualmente ou inerentes natureza do trabalho. A equipe do projeto define quais dependncias so obrigatrias durante o processo de sequenciamento das atividades. Geralmente envolvem limitaes fsicas, tais como num projeto de construo onde impossvel erguer a superestrutura antes que a fundao tenha sido concluda, ou num projeto de componentes eletrnicos, onde um prottipo tem que ser construdo antes de ser testado. o Dependncias arbitradas: normalmente so estabelecidas baseadas no conhecimento das melhores prticas numa rea de aplicao especfica ou em algum aspecto particular do projeto onde uma sequncia especfica desejada, mesmo que haja outras sequncias possveis ou aceitveis. Existe a necessidade de documentao dessa dependncia para evitar problemas de comunicao e para justificativa do caminho escolhido. o Dependncias externas: o gerente do projeto ou sua equipe definem quais dependncias so externas durante o processo de sequenciamento das atividades. Isso envolve uma relao entre as atividades do projeto e as no pertencentes ao mesmo. Aplicao de antecipaes e esperas: PMBOK (2009) determina que uma antecipao permita um aceleramento da atividade sucessora. Por exemplo, num projeto para construir um novo edifcio de escritrios, o paisagismo poderia ser agendado para comear duas semanas antes do trmino agendado dos itens da lista. Isso seria mostrado como um trmino para incio com uma antecipao de duas semanas. Uma espera direciona um retardo na atividade sucessora. Por exemplo, uma equipe de redao tcnica pode iniciar a edio do rascunho de um grande documento quinze dias aps ter comeado a escrev-lo. Isso poderia ser mostrado como um incio para incio com uma espera de quinze dias. O uso de antecipaes e esperas no deve substituir a lgica de desenvolvimento do cronograma. As atividades e suas premissas relacionadas devem ser documentadas. Uma antecipao permite um aceleramento da atividade sucessora.

Modelos de diagrama de rede de cronograma: so utilizados para agilizar a preparao da rede de atividades e normalmente esto em repositrios de conhecimento nas organizaes para esta finalidade. Podem conter todo projeto ou partes ou at mesmo fragmentos. Segundo o PMBOK (2009:121): (...) os modelos de sub-redes so especialmente teis quando um projeto inclui vrias entregas idnticas ou quase idnticas, tais como andares num alto prdio de escritrios, testes clnicos num projeto de pesquisa farmacutico, mdulos de programas de codificao num projeto de software, ou a fase inicial de um projeto de desenvolvimento. Estimar os Recursos da Atividade: As melhores prticas do PMBOK rezam que, para estimar os recursos de uma atividade envolvemos os tipos e quantidades de material, pessoas, equipamentos ou suprimentos que sero necessrios para realizar cada atividade da EAP. Estimar os recursos para uma atividade est intimamente ligado com o processo de estimativa de custos, sendo que podemos nos apropriar das mesmas tcnicas que utilizamos nessa rea da gesto de projetos. Dois exemplos prticos impostos pelo PMBOK (2009:122) demonstra o grande grau de sinergia entre esses processos: o Uma equipe de um projeto de construo precisar estar familiarizada com as legislaes de construo locais. Geralmente, tal conhecimento est facilmente disponvel em fornecedores locais. Contudo, se o servio de mo de obra local carece de experincia em tcnicas de construo incomuns ou especializadas, o custo adicional de um consultor pode ser a maneira mais efetiva de assegurar o conhecimento das legislaes de construo locais. o Uma equipe de planejamento automotivo precisar estar familiarizada com as mais recentes tcnicas de montagem automatizada. O conhecimento necessrio pode ser obtido atravs da contratao de um consultor, do envio de um projetista a um seminrio de robtica, ou da incluso de algum da produo como um membro da equipe do projeto. Estimar as Duraes da Atividade: segundo o PMBOK (2008), o processo de estimativa do nmero de perodos de trabalho que sero necessrios para terminar as atividades especficas com os recursos estimados. o A estimativa das duraes das atividades utiliza informaes sobre as atividades do escopo do projeto, tipos de recursos necessrios, quantidades estimadas de recursos e calendrios de recursos. As entradas para as estimativas de durao da atividade se originam da pessoa ou grupo na equipe do projeto que est mais familiarizado com a natureza do trabalho na atividade especfica. A estimativa da durao elaborada progressivamente e o processo considera a qualidade e a disponibilidade dos dados de entrada (PMBOK, 2009:125).

Estimar a durao de uma atividade requer que a quantidade do esforo e recursos necessrios sejam aplicados para finalizar a atividade. Dessa forma, estes elementos so utilizados para gerar o nmero de ms/dias/horas de trabalhos necessrios para a finalizao

da atividade. A durao decorre do esforo requerido para completar o trabalho relativo a uma atividade do projeto, e ajustar esse esforo levando em conta com os seguintes fatores: o o o o A quantidade de recursos que iro realizar o trabalho e o grau de eficincia desses recursos. O calendrio de disponibilidade dos recursos (isto se eles esto disponveis a 100% ou numa outra qualquer percentagem inferior de tempo). Os perodos especficos de inatividade (fins de semana, feriados e frias contratuais). Nmero normal de horas dirias de trabalho.

Para estimarmos a durao, podemos utilizar um mapeamento mediante o uso de um fluxo como nos exemplos abaixo:

Figura 5: Fluxo para concluirmos a atividade para estabelecer a durao das atividades no projeto. Fonte: http://ricardosatin.blogspot.com/2009/12/estimativa-de-duracao-de-atividades.html

Desenvolver o Cronograma: Conforme o PMBOK (2009:129), desenvolver o cronograma o

processo de anlise de sequncias das atividades, suas duraes, recursos necessrios e restries do cronograma visando criar o cronograma do projeto. A entrada das atividades, duraes e recursos na ferramenta de elaborao de cronograma gera um cronograma com datas planejadas para completar as atividades do projeto (PMBOK. 2009. P.129).

Importante citar no processo de construo do cronograma, tratar-se de um elemento dinmico e ativo de forma que a sua reviso e a manuteno so necessrias para mant-lo em concordncia realidade e deve ser executada durante todo o projeto medida que o trabalho avana, pois o plano de gerenciamento muda e a natureza dos eventos de riscos, custos e recursos humanos evolui. Para podermos desenvolver o cronograma, precisamos estar munidos dos seguintes documentos de projeto, que chamaremos aqui de entradas do processo Desenvolver o Cronograma: o o o o o o o o o Lista das atividades Atributos das atividades Diagramas de rede do cronograma do projeto Requisitos dos recursos da atividade Calendrios dos recursos Estimativas da durao da atividade Declarao do escopo do projeto Fatores ambientais da empresa Ativos de processos organizacionais. Anlise da rede do cronograma: os diagramas de rede so amostras esquemticas das atividades do cronograma do projeto e as suas relaes lgicas, tambm chamadas de dependncias. Mtodo do caminho crtico: calcula as datas hipotticas de incio e trmino mais cedo e incio e trmino mais tarde, em todas as atividades, sem considerar quaisquer limitaes de recursos, executando uma anlise dos caminhos de ida e de volta atravs da rede do cronograma. De acordo com o PMBOK (2009), as datas resultantes de incio e trmino mais cedo e incio e trmino mais tarde no so necessariamente o cronograma do projeto, mas sim uma indicao dos perodos de tempo dentro dos quais a atividade poderia ser agendada, dadas as duraes do projeto, relaes lgicas, antecipaes, esperas e outras restries conhecidas.

O PMBOK (2009:132) determina que os caminhos crticos tenham uma folga total igual zero ou negativa e as atividades do cronograma que esto no caminho crtico so chamadas atividades crticas. Um caminho crtico normalmente caracterizado por uma folga total igual zero no caminho crtico. Redes podem ter mltiplos caminhos quase crticos. Ajustes s duraes da atividade, relaes lgicas, antecipaes e esperas e outras restries do cronograma podem ser necessrios para produzir caminhos com folga total zero ou negativa. Uma vez que a folga total para um caminho da rede tenha sido calculada, a folga livre, isto , a quantidade de tempo que uma atividade pode ser atrasada sem atrasar a data de incio mais cedo de qualquer atividade imediatamente sucessora dentro do caminho crtico, pode tambm ser determinada.

Figura 06: Caminho crtico em um projeto (em vermelho) Fonte: http://teccrono.com.br/plan-desenvolvimento.html

Compresso do Cronograma: conforme PMBOK (2009), serve para encurtar o cronograma do projeto sem mudar o escopo do mesmo, para respeitar as restries do cronograma, datas impostas ou outros objetivos do cronograma, as tcnicas de compresso do cronograma incluem: o Compresso. Exemplos de compresso poderiam incluir a aprovao de horas extras, recursos adicionais ou o pagamento para a acelerao da entrega das atividades no caminho crtico. A compresso funciona somente para as atividades onde recursos adicionais encurtaro a sua durao. A compresso nem sempre produz uma alternativa vivel e pode resultar num maior risco e/ou custo. o Paralelismo. Uma tcnica de compresso do cronograma na qual fases ou atividades normalmente executadas em sequncia so executadas em paralelo. Um exemplo a construo da fundao de um prdio antes que todos os desenhos arquitetnicos tenham sido terminados. O paralelismo pode resultar na repetio de trabalho e aumento de risco. O paralelismo funciona somente se as atividades podem ser sobrepostas para encurtar a durao.

Figura 06: Compresso Fonte: http://teccrono.com.br/

Figura 07: Paralelismo Fonte: http://teccrono.com.br/

Sadas do processo para criar o cronograma: o Cronograma do projeto: o cronograma do projeto inclui pelo menos uma data de incio e de trmino planejadas para cada atividade. o Grficos de marcos: esses grficos assemelham-se aos grficos de barras, porm identificam somente o incio ou trmino agendado para as entregas mais importantes e interfaces externas chaves. o Grfico de barras: esses grficos, onde as barras representam as atividades, mostra as datas de incio e trmino da atividade, assim como as duraes esperadas. o Diagramas de rede do cronograma do projeto: esses diagramas, com informaes sobre as datas das atividades, normalmente mostra tanto a lgica da rede do projeto como suas atividades do seu caminho crtico. o Linha de base do cronograma: uma linha de base do cronograma uma verso especfica do cronograma do projeto desenvolvido a partir da anlise de rede do mesmo. o Dados do cronograma: os dados de apoio do cronograma para compor o cronograma do projeto incluem pelo menos os marcos, as atividades, os atributos das atividades e a documentao de todas as premissas e restries identificadas. o Por ltimo, o PMBOK (2009:139) depois consultar o especialista, reza que para manter os documentos em dia preciso. o Requisitos dos recursos das atividades. O nivelamento dos recursos pode ter um efeito significativo nas estimativas preliminares dos tipos e quantidades de recursos necessrios. Se a anlise do nivelamento de recursos muda os requisitos dos recursos do projeto, ento os mesmos so atualizados. o Atributos das atividades. Os atributos das atividades so atualizados para incluir quaisquer requisitos de recursos revisados ou quaisquer outras revises geradas pelo processo Desenvolver o Cronograma. o Calendrio. O calendrio para cada projeto pode usar diferentes unidades como base para Desenvolver o Cronograma do projeto.

o Registro dos riscos. O registro dos riscos pode precisar ser atualizado para refletir oportunidades ou ameaas percebidas atravs das premissas de agendamento. Controlar o Cronograma: E o processo de monitoramento do andamento do projeto para atualizao do seu progresso e gerenciamento das mudanas feitas na linha de base do cronograma. Conforme o PMBOK (2009: 136), o controle do cronograma est relacionado a: o Determinao da situao atual do cronograma do projeto; o Influncia nos fatores que criam mudanas no cronograma; o Determinao de que o cronograma do projeto mudou; o Gerenciamento das mudanas reais conforme ocorrem.

Fundamentos de Governana com ITIL

Como estamos constantemente frisando em nossos estudos, a TI tem ganhado peso e importncia nas organizaes, seus desafios tambm aumentaram em proporo semelhante; abaixo citamos alguns: Ajustar os servios de TI com as necessidades e metas atuais e futuras dos negcios da empresa. Aumento da complexidade no ambiente de TI. Os negcios esto cada vez mais dependentes de TI. Minimizao de riscos e custos. Melhores justificativas para o ROI - retorno sobre os investimentos em TI. Mais leis e regulamentos com exigncia de conformidade imediata. Zelo sobre a segurana das Informaes.

Os negcios empresariais, buscam melhorias e otimizaes com maior frequncia e possuem metas audaciosas para reduzir riscos e custos, por isso foram pensados diversos frameworks com a inteno de melhorar processos e prticas. Vamos falar especificamente de ITIL - IT Infrastructure Lybrary, composta pelas melhores prticas para Gerenciamento de Servios de TI. Foi introduzida pelo Governo Britnico em 1980 e se tornou padro no mercado em 1990. uma biblioteca composta de 5 livros. No uma metodologia, mas sim um conjunto de melhores prticas adotadas por diversas empresas em vrias partes do mundo. Estas melhores prticas pretendem: Inspirar a melhoria dos processos de TI;

Estabelecer metas e nortear o futuro mostrando que outras empresas j lograram xito; Orientar e sugerir para que servem os processos e prticas; Propor e motivas a adoo destes processos e prticas.

Conforme Pinheiro (2006,13), os livros que compem a biblioteca de melhores prticas ITIL so: Suporte a Servios: descreve os processos associados ao suporte do dia-a-dia e atividades de manuteno associadas com a proviso de Servios de TI. Entrega de Servios: cobre os processos necessrios para o planejamento e entrega de Servios de TI com qualidade e se preocupa ao longo do tempo com o aperfeioamento desta qualidade. ICT - Gerenciamento da Infraestrutura: cobre todos os aspectos do Gerenciamento da Infraestrutura como a identificao dos requisitos do negcio, testes, instalao, entrega, e otimizao das operaes normais dos componentes que fazem parte dos Servios de TI. Planejamento para Implementao do Gerenciamento de Servios: examina questes e tarefas envolvidas no planejamento, implementao e aperfeioamento dos processos do Gerenciamento de Servios dentro de uma organizao. Tambm foca em questes relacionadas Cultura e Mudana Organizacional. Gerenciamento de Aplicaes: descreve como gerenciar as aplicaes a partir das necessidades iniciais dos negcios, passando por todos os estgios do ciclo de vida de uma aplicao, incluindo at a sua sada do ambiente de produo (quando o sistema aposentado). Este processo d nfase em assegurar que os projetos de TI e as estratgias estejam corretamente alinhados com o ciclo de vida da aplicao, assegurando que o negcio consiga obter o retorno do valor investido. Perspectiva de Negcio: fornece um conselho e guia para ajudar o pessoal de TI a entender como eles podem contribuir para os objetivos do negcio e como suas funes e servios podem estar mais bem alinhados e aproveitados para maximizar sua contribuio para a organizao. Gerenciamento da Segurana: detalha o processo de planejamento e gerenciamento da segurana da informao e Servios de TI, incluindo todos os aspectos associados com a reao da segurana dos incidentes. Tambm inclui uma avaliao e gerenciamento dos riscos e vulnerabilidade, e implementao de custos justificveis para a implementao de contra-recursos (estratgia de segurana).

Figura 1: ITIL e seus livros Fonte:Service Suport OGC

Para esta nossa disciplina, vamos estudar apenas os dois primeiros. Conforme o livro de Services Suport do ITIL, o relacionamento entre os processos est descrito na imagem abaixo.

Figura 2: relacionamento entre processos do Service Suport ITIL Fonte: livro ITIL-SS

Figura 2: conforme figura do livro sobre Entrega de servios do Service Suport ITIL e seus relacionamentos Fonte: livro ITIL-ES

Possveis ganhos ou economias com ITIL: Reduo do custo total em at 48% - Gartner 6-8% de reduo de custos operacionais. $ 125 milhes de economia (10% do budget). Procter e Gamble Aumento da satisfao do cliente Aumento de resoluo de incidentes de 5% para 30% com o uso de uma base de conhecimento - IS Organizations Reduo de 50% no tempo mdio de resoluo. Reduo de 30% no tempo para realizar novas mudanas. Reduo de 50% dos recursos Utility Provider

Dentre os diversos motivos para de adotar uma estratgia de servios em ITIL, destaco: Incrementar a qualidade no servio, com um suporte mais confivel em T.I. Uma percepo e vivncia da segurana e confiana da continuidade nos servios de TI. Percepo da capacidade atual mais visvel e transparente a todos. Fornecimento de informaes gerenciais para acompanhamento de desempenho, possibilitando traar melhorias. Equipe de TI mais motivada: conhecendo a carga de trabalho possvel gerenciar melhor as expectativas.

Maior satisfao para os clientes e usurios, entregando o servio com mais qualidade e rapidez. (Em alguns casos) Reduo de custos: a partir do melhor planejamento e controle dos processos internos possvel otimizar os custos operacionais. Maior agilidade e segurana para realizar as mudanas propostas pelo negcio. Com processos definidos e controlados mais fcil implementar vrias mudanas simultaneamente.

O conceito de servio em T.I. deve ser entendido como sendo um conjunto de objetos relacionados, aprovisionados para suporte a um ou mais processo de negcios. Diferentemente de processo, em servios sempre o usurio que interage. A definio de processo em ITIL a reunio de atividades que so interdependentes e inter-relacionadas com uma meta especfica. Como componentes mais notveis pode-se citar: entradas de dados, informaes, produtos, que transformam os recursos necessrios nos objetivos previstos.

Figura: exemplo de processo Fonte: Pinheiro (2006, 18)

Visando a melhor prestao de servios em TI, ITIL separa em dois os atores da prestao de servios, a saber: Cliente: quem paga pelos servios. Caso TI seja uma rea interna, os clientes podem ser as unidades de negcios ou departamentos da empresa; caso TI seja um terceiro, prestador de servios, os clientes sero, ento, as prprias empresas que o terceiro atender. Usurio: quem utiliza os servios de TI quotidianamente. Segundo Pinheiro (2006,25), a implementao de uma central de servios ITIL tem por objetivos: Funcionar como o ponto central de contato (SPOC Single Point of Contact) entre os usurios e departamento de TI. A Central de servios funciona como o 1. Nvel de suporte aos usurios.

Restaurar os servios sempre que possvel. A equipe de suporte deve estar equipada com ferramentas e informaes, tais como Erros Conhecidos, Base de Conhecimento, para que possa oferecer solues o mais rpido possvel. Prover suporte com qualidade para atender os objetivos do negcio. necessrio que a equipe esteja bem treinada para ter conhecimento de todos os servios que sero fornecidos e entender o impacto que eles tm para o negcio. Gerenciar todos os incidentes at o seu encerramento. A central de servio ser responsvel pelo processo de Gerenciamento de Incidentes, e ser responsvel pelo tratamento de todos os incidentes. de responsabilidade tambm da Central de Servios monitorar o cumprimento dos acordos estabelecidos nas ANS (SLAAcordos de Nveis de Servios). Dar suporte a mudanas, fornecendo comunicao aos usurios sobre o agendamento de mudanas. Aumentar a satisfao do usurio, provendo suporte com maior qualidade, estando sempre de prontido para o atendimento, buscando solucionar os incidentes de forma mais rpida. Maximizar a disponibilidade do servio.

Suas atividades principais dizem respeito a: Receber e gravar TODAS as chamadas dos usurios. Gravar e acompanhar incidentes e reclamaes. Prover uma avaliao inicial dos incidentes. Monitorar / escalar incidentes por ANS - Acordo de Nvel de Servio (SLA em ingls). Comunicar mudanas planejadas nos nveis de servio. Encerrar os incidentes com confirmao. Manter os usurios informados sobre o progresso de suas requisies. Produzir relatrios de gerenciamento. Coordenar os grupos de suporte de 2 e 3 nvel. Prover informaes gerenciais. Identificar necessidades de treinamento dos usurios. Contribuir na identificao de problemas.

Para o ITIL, existem 3 tipos de central de servio, conforme Bom (2007, 38): Central de Atendimento (Call Center), atende grandes volumes, utiliza o telefone. Central de Suporte (Help Desk), o foco no perder nenhuma requisio seja abandonada ou no atendida, sua meta resolver e coordenar incidentes servindo como interface. Central de Servios (Service Desk), mais abrangente, inclui os processos de negcio de forma integrada no ficando apenas em incidentes, resolve problemas e dvidas.

Figura: Central de Servios Local esquema Fonte: Pinheiro (2006,24)

Como toda implementao, pode-se criar barreiras ao sucesso da implementao da central de servios, dentre elas o Service Delivery (2000, 48) expem: Usurios no ligarem para Central de Servios, mas tentarem buscar uma soluo diretamente com uma pessoa que conhece, ou que a ajudou da ltima vez. A equipe tcnica no estar preparada para atender as necessidades do negcio ou usurios. Nem todas as partes esto informadas sobre os servios fornecidos e os nveis de servios acordados, resultando em frustrao por parte dos usurios.

A central de servios atua sobre duas frentes, a primeira a gesto de incidentes, a segunda gesto de problemas. Entende-se que a gesto de incidentes tem como alvo restaurar os servios o mais rpido possvel com o mnimo de interrupo, minimizando os impactos negativos nas reas de negcio. Para Pinheiro (2006) e o livro ITIL intitulado Service Delivery (2000), o Processo de Gerenciamento de Incidentes tem como objetivos: Resolver os incidentes o mais rpido possvel, restabelecendo o servio normal dentro do prazo acordado. Manter a comunicao dos status dos incidentes aos usurios. Escalonar os incidentes para os grupos de atendimento para que seja cumprido o prazo de resoluo. Fazer avaliao dos incidentes e as possveis causas informando ao processo de Gerenciamento de Problemas.

Quanto ao gerenciamento de problemas, sua principal tarefa mitigar a interrupo nos servios de TI, organizando os recursos disponveis resolvendo o problema conforme as

necessidades do negcio, tentando evitar a recorrncia e agindo no sentido de documentar para promover a melhoria continua da disponibilidade e produtividade. De acordo com o Livro ITIL Service Delivery (2000), leva em conta os seguintes conceitos gerais:

Problema: a causa desconhecida de um ou mais incidentes Soluo de Contorno: soluo no definitiva (em ingls Workaround) Causa: um erro em um Item de configurao Erro Conhecido (Known Error): um problema cuja causa foi diagnosticada e para qual existe uma soluo Soluo: soluo definitiva Gesto de Incidentes X Problemas: foco na Soluo rpida x foco na introduo de melhorias confiveis e robustas na infraestrutura

Material Complementar

Caso voc queira se aprofundar em ITIL e entender mais detalhadamente as funes dos livros de servios e at poder implementar algumas prticas no lugar que voc trabalha, sugiro a leitura desta apostila de fundamentos em gerenciamento usando ITIL. Disponvel em: http://pt.scribd.com/doc/88136757/10/Fundamentos-em-Gerenciamento-deServicos-de-TI Outro material interessante j focado na verso 3 do ITIL este, disponvel em: http://www.slideshare.net/blogdufraga/apostila-itilv3conceitos Existe, disponvel nesse link um http://www.mp.go.gov.br/portalweb/hp/12/docs/apresentacao_gp.pdf, material muito bom sobre um resumo de gesto de projetos para que voc possa conhecer essa rea que cresce a cada dia em nosso pas e que tem falta crnica de mo de obra. Para uma leitura mais aprofundada na aplicao do gerenciamento de projetos em tecnologia da informao, eu recomendo a leitura do artigo intitulado Aplicabilidade dos Escritrios de Projetos de TI nas organizaes pblicas e privadas. Este fala um pouco das dificuldades em se implementar um escritrio de projetos voltado para TI. Disponvel em: http://www.upis.br/posgraduacao/revista_integracao/projetos_ti%20.pdf

Depois de ler o material e informar-se sobre o assunto, vamos pr em prtica esses conhecimentos nas atividades!

Bom trabalho!

Referncias
BON, Jan Von. Foundations of IT Service Management, based on ITIL. Lunteren Holanda: Van Haren Publishing. 2005. JUNIOR MARQUES, Artur Ubaldo; MARQUES, Daniela Gonalves de Moraes. Gerenciamento do Tempo em Projetos. EAD Universidade Cruzeiro do Sul, 2011. PINHEIRO, Flvio R. Fundamentos em gerenciamento de servios de TI baseados em ITIL. 2006. Disponvel em: http://pt.scribd.com/doc/32939973/ Apostila-ITIL. Acessado em: 22 jul. 2012. PMI Project Management Institute. Guia PMBOK. Um Guia do Conhecimento em Gerenciamento de Projetos. 4Ed.. PMI. 2008. RICARDI, Andr Luis Fonseca. Gerenciamento do Escopo do Projeto. Universidade Cruzeiro do Sul. 2011. EAD

SCHMITZ, Leandro Costa. Gerncia de Projetos: Histrico, Contextualizao, Principais Conceitos e Relaes. UDESC/ESAG. 2005. THE STATIONARY OFFICE. Service Delivery. Inglaterra: Londres. 2000

Anotaes
_________________________________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________