Gerência de Projetos Distribuídos

Apresentação em tema: "Gerência de Projetos Distribuídos"— Transcrição da apresentação:

1 Gerência de Projetos Distribuídos
Jean Reis - UFPA

2 Uma breve história… Em 1991, um estudante finlandês de Ciência da Computação enviou uma mensagem para uma lista de discussão na internet dizendo que estava desenvolvendo como passatempo um sistema operacional free para computadores 386, 486, AT …

3 Uma breve história…(2) Muitos acadêmicos conceituados ficaram interessados na idéia e, a partir daí, programadores de diversas partes do mundo passaram a trabalhar em prol desse projeto…

4 Uma breve história…(3) Cada melhoria desenvolvida por um programador era distribuída pela Internet e imediatamente integrada ao sistema operacional …

5 Uma breve história…(4) No decorrer dos anos este trabalho árduo e voluntário de centenas de pessoas distribuídas pelo mundo tornou-se um sistema operacional bem amadurecido. Atualmente esse sistema está presente em milhões de servidores, computadores pessoais e celulares pelo mundo.

6 Essa história é familiar pra vocês?

7 Muitas oportunidades foram criadas…
Falar das oportunidades criadas com o Linux , tanto para empresas como para pessoas.

8 Gerência de Projetos Distribuídos
Jean Reis - UFPA

9 O que é projeto? Definição 1:
É um empreendimento com características próprias, tendo princípio e fim, conduzido por pessoas, para atingir metas estabelecidas dentro de parâmetros de prazo, custo e qualidade. [PMBOK] Definição 2: “Um empreendimento realizado para criar um produto. O projeto se caracteriza por temporalidade e resultado, produto único e elaboração progressiva” [SOFTEX, 2009a].

10 Gerência de Projetos É a aplicação de conhecimentos, habilidades, ferramentas e técnicas em projetos com o objetivo de atingir ou até mesmo exceder às necessidades e expectativas dos clientes e demais partes interessadas do projeto. [PMBOK] Projetos envolvem decisões… Escopo, Tempo, Custo e Qualidade.

11 Introdução Os benefícios dos melhores métodos e ferramentas não podem ser alcançados em ambientes de projetos caóticos e indisciplinados. Entretanto, mesmo em organizações indisciplinadas, alguns projetos de software específicos produzem excelentes resultados, graças ao esforço heróico e da dedicação da equipe, ao contrário da repetição de métodos comprovados da organização. Quem trabalha em empresas de TI deve entender muito bem isso, sempre tem aqueles “Mestres JEDI”, as pessoas que no momento do aperto todos recorrem a elas para resolver os problemas e entregar tudo dentro do prazo. Na faculdade não é diferente, em todo grupo tem uma ou duas pessoas que fazem praticamente todo o trabalho, aí o resto fica lá tranquilo sabendo que a sua tarefa vai ser só passar os slides no dia apresentação. No meu ensino fundamental esses caras ficavam segurando a cartolina, enquanto os outros apresentavam. Aí esses caras evoluíram, ao invés de segurar a cartolina eles começaram a passar os slides.

12 O que acontece se esses heróis sairem do projeto?

13 Introdução(2) Torna-se necessário definir processos a serem seguidos para a organização. Nesse sentido, foram criados modelos de processo a serem seguidos pelas empresas: CMMI MPS.Br Esses processos tem ajudado as empresas a crescer, melhorar seus rendimentos e conseguir novos mercados… mas falando em crescer, existe um tipo de crescimento que tem acelerado muito atualmente… (projetos distribuídos)

14 Introdução(3) Mercados locais estão se tornando mercados globais
As empresas estão cada vez mais distribuindo seus processos de desenvolvimento de software.

15 Introdução(4) Diversos fatores têm contribuído para isto, entre eles:
As vantagens de estar perto do mercado local. A grande pressão para o desenvolvimento time-to-market. Demanda e Custos As vantagens de estar perto do mercado local -> incluindo o conhecimento dos clientes e as condições locais.

16 Demanda X Profissionais disponíveis
Número de Computadores Profissionais Disponíveis(SW) Demanda por Serviços de SW Volume Ano 1970 1980 1990

17 Projetos Distribuídos
Projetos executados com equipes geograficamente distribuídas. 3 características básicas: Dispersão geográfica Dispersão temporal Diferenças culturais

18 Dispersão geográfica

19 Dispersão temporal

20 Diferenças culturais

21 Operacionalização dos projetos
O projeto pode:  Continuar sendo executado pela mesma empresa (Insourcing).  Ser executado por uma empresa terceirizada (Outsourcing). No Outsourcing uma empresa é terceirizada para a entrega de determinados serviços ou produtos.

22 Como o Brasil está sendo visto lá fora…
“Futebol, Samba e Outsourcing” (Wall Street Journal) “…estará no Top 3 dos melhores provedores de serviços do mundo, junto com a Índia e a China” (Analista do Gartner)

23 Com isso surgem…

24 Mas… nesse novo contexto de projetos distribuídos, outsourcing… os mesmos modelos (MPS.Br, CMMI) são aplicáveis?

25 Pergunta! Projeto: É um empreendimento com características próprias, tendo princípio e fim, conduzido por pessoas, para atingir metas estabelecidas dentro de parâmetros de prazo, custo e qualidade. [PMBOK] Serviço: É um produto que é intangível e não armazenável, planejado para satisfazer os requisitos do cliente. O serviço pode ser entregue em um momento definido ou entregue ao longo do tempo. [CMMI for Services]

26 Resposta! Enquanto os projetos tem um início e um fim definidos, o serviço pode ser entregue ao longo do tempo, sem existir um fim determinado.

27 As empresas que ofereciam “Outsourcing” tentavam usar o CMMI para seus serviços e viam que não se encaixava. Elas percebiam que alguma coisa estava faltando…

28 CMMI for Services O SEI (responsável pelo CMMI) resolveu criar uma versão do CMMI para serviços, chamada de CMMI for Services (CMMI-SVC), lançada em Fev/2009. O CMMI-SVC é aplicável para qualquer instituição que trabalhe com serviços, seja ela relacionada ou não à área de software. Além de algumas áreas do CMMI-DEV, foram criadas 7 novas Áreas de Processo.

29 CMMI for Services Áreas de Processo Criadas:
Desenvolvimento do Sistema de Serviço Transição do Sistema de Serviço Continuidade do Serviço Gerência Estratégica do Serviço Entrega do Serviço Prevenção e Resolução de Incidentes Gerência da Capacidade e Disponibilidade

30 Categoria - Gerência de Projetos
Gerência da Capacidade e Disponibilidade; Gerência Integrada do Projeto; Planejamento do Projeto; Gerência Quantitativa do Projeto; Gerência de Requisitos; Gerência de Riscos; Continuidade do Serviço; Monitoramento e Controle do Projeto; Gerência de Contrato com os Fornecedores;

31 Planejamento do Projeto
(Project Planning - PP) Estabelecer e manter planos que definem as atividades do projeto. OE1 – Estabelecer estimativas. OE2 – Desenvolver um plano de projeto. OE3 – Obter compromisso com o plano. SG 1 Establish Estimates -> Em projetos distribuídos o tempo de resolução das tarefas na maioria dos casos é maior…

32 Monitoramento e Controle do Projeto
(Project Monitoring and Control - PMC) A performance atual e o progresso do projeto são monitorados de acordo com o plano do projeto. OE1 – Monitorar o projeto de acordo com o plano. OE2 – Gerenciar ações corretivas. Bugzilla, JIRA…

33 OE1 - Monitorar o projeto
Durante o projeto é importante monitorar: Riscos Envolvimento dos membros do projeto Progresso das atividades Progresso das “milestones” …

34 Exemplo: Tesseract

35 OE2 – Gerenciar ações corretivas
Para gerenciar as ações corretivas é necessário: Analisar os problemas e definir as ações necessárias. Realizar a ação corretiva do problema. Gerenciar as ações corretivas.

36 Exemplo: Bugzilla

37 Gerência de Capacidade e Disponibilidade
(Capacity and Availability Management - CAM) Planejar e monitorar a provisão de recursos para suportar os requisitos do serviço. OE1 – Preparar para a Gerência de Capacidade e Disponibilidade. OE2 – Monitorar e Analisar a Capacidade e Disponibilidade. Capacity = Qual o máximo que eu posso oferecer ? Availability = Qual o grau de disponibilidade do que eu posso oferecer? - Recursos podem ser pessoas, servidores… Aqui na UFPA dois recursos que são muito importantes: servidor web e servidor de . Quando um desses dois cai as pessoas começam logo a ligar reclamando. É importante definir quais recursos são CRÍTICOS para que seja dada uma prioridade adequada.

38 Exemplo: Nagios Um exemplo de software muito útil pra quem gerencia Redes é o Nagios.

39 Agora sabe o que é bem mais complicado do que monitorar a disponibilidade de servidores? Monitorar a disponibilidade de pessoas… Qual o mês no Brasil que as pessoas menos trabalham ?(Dica: Carnaval). Uma empresa na Europa distribuída em 12 países verificou que em apenas 40 dias do ano todos os funcionários estavam disponíveis para ter conversas em tempo real (devido os feriados, etc.)

40 Exemplo: Rational Team Concert

41 Gerência Integrada do Projeto
(Integrated Project Management - IPM)  Gerenciar o projeto e as pessoas envolvidas de acordo com o processo definido e integrado, adaptado do conjunto de processos padrões da organização. OE1 – Usar o processo definido para o projeto. OE2 – Coordenar e colaborar com as pessoas relevantes do projeto É necessário garantir que todas as equipes de desenvolvimento utilizem o mesmo processo e ferramentas. SP 1.1 – Estabelecer o processo definido pro projeto. SP Estabelecer o ambiente de trabalho do projeto (ferramentas, etc.) SP 1.6 – Estabelecer times integrados SP 2.1 – Gerenciar envolvimento dos “stakeholders” SP 2.2 – Gerenciar dependências SP 2.3 – Resolver problemas de coordenação (ex: não disponibilidade de recursos (apis…) e pessoas)

42 Usar processo definido
Práticas importantes: Adotar um processo comum para todas as equipes distribuídas. Definir um conjunto de ferramentas a serem utilizadas por todos os membros do projeto. Estabelecer as integrações entre os times

43 Usar processo definido(2)
É importante definir pessoas para atuarem como intermediadores entre as equipes, fazendo um papel de ligação (“liaisons”).

44 Coordenar e colaborar com as pessoas relevantes
Práticas importantes: Gerenciar o envolvimento entre as pessoas do projeto. Gerenciar dependências. Uso de ferramentas de gerência de configuração. Arquitetura influencia diretamente nas dependências existentes. Resolver problemas de coordenação.

45 Gerência de Requisitos
(Requirements Management - REQM)  Gerenciar os requisitos dos produtos do projeto e dos componentes do produto, identificando também inconsistências entre os requisitos e os planos do projeto e produtos de trabalho. OE1 – Gerenciar os requisitos. A distribuição geográfica acaba dificultando ainda mais a clarificação dos requisitos durante a fase de desenvolvimento. Isso pode ser alcançando enviando um ou mais analistas da empresa contratada para participar da análise dos requisitos. Percepção da diversidade também é importante. Realização de treinamentos e workshops sobre as diferenças culturais, de contexto, de comunicação, etc, são importantes. É importante também definir responsabilidades e prioridades. Não deixar que todos se comuniquem com todos, porque senão requisitos com alta prioridade vem de todo lado e fica difícil de gerenciar. Assim, tem q definir antes os “liaisons” para essas tarefas. Manter comunicação frequentemente. “Experienced project managers advise to organize face to face meetings once in a month or two for planning and requirement ambiguity clarification.” Evitar o uso de mecanismos de comunicação assíncrona, que atrasam ainda mais o trabalho. Usar video-conferencia, telefone… SP 1.1 – Entender os requisitos SP 1.2 – Obter comprometimento em relação aos requisitos. SP 1.3 – Gerenciar as mudanças nos requisitos SP 1.4 – Manter rastreabilidade bi-direcional dos requisitos SP 1.5 – Identificar inconsistências entre o trabalho do projeto e os requisitos

46 Gerência de Requisitos(2)
A distribuição geográfica acaba dificultando ainda mais a a gerência dos requisitos. Para contornar esse problema é recomendado enviar uma ou mais pessoas da empresa contratada para participar da elicitação e análise dos requisitos. É importante também definir responsabilidades e prioridades. Não deixar que todos comuniquem requisitos, porque senão fica difícil gerenciar. A distribuição geográfica acaba dificultando ainda mais a clarificação dos requisitos durante a fase de desenvolvimento. Isso pode ser alcançando enviando um ou mais analistas da empresa contratada para participar da análise dos requisitos. Percepção da diversidade também é importante. Realização de treinamentos e workshops sobre as diferenças culturais, de contexto, de comunicação, etc, são importantes. É importante também definir responsabilidades e prioridades. Não deixar que todos se comuniquem com todos, porque senão requisitos com alta prioridade vem de todo lado e fica difícil de gerenciar. Assim, tem q definir antes os “liaisons” para essas tarefas. Manter comunicação frequentemente. “Experienced project managers advise to organize face to face meetings once in a month or two for planning and requirement ambiguity clarification.” Evitar o uso de mecanismos de comunicação assíncrona, que atrasam ainda mais o trabalho. Usar video-conferencia, telefone… SP 1.1 – Entender os requisitos SP 1.2 – Obter comprometimento em relação aos requisitos. SP 1.3 – Gerenciar as mudanças nos requisitos SP 1.4 – Manter rastreabilidade bi-direcional dos requisitos SP 1.5 – Identificar inconsistências entre o trabalho do projeto e os requisitos

47 (Risk Management - RSKM)
Gerência de Riscos (Risk Management - RSKM) Identificar problemas potenciais antes deles ocorrerem, para que possam ser tomadas providências para evitar que esses problemas impactem nos objetivos do projeto. OE1 – Preparar para a Gerência de Riscos. OE2 – Identificar e analisar os riscos. OE3 – Mitigar os riscos. A gerência de riscos deve acontecer num nível estratégico e tático (antes do projeto começar) e num nível operacional (quando ele já começou). A idéia é que antes do projeto começar se verifiquem quais são os riscos envolvendo o projeto, para que tudo isso seja encaminhado para o gerente do projeto poder planejar medidas de resposta e monitorar esses riscos durante o projeto. Tem poucos trabalhos nessa linha e nos trabalhos sobre projetos distribuídos é um dos mais precisa crescer. Qualquer coisa cobrem o Adailton daqui a alguns anos porque ele tá fazendo pesquisa sobre gerência de riscos no doutorado dele. Aí quando vocês forem falar com ele não esqueçam de falar: “ah, o Jean falou de ti durante a Seminf” que aí eu aproveito pra cobrar 10% dele sobre o valor da consultoria.

48 Gerência de Riscos(2) Riscos para o projeto distribuído:
Comunicação ineficiente Diferenças culturais Perda do espírito de equipe

49 Comunicação Ineficiente
Dificuldade na comunicação devido a distância geográfica, diferença de fuso horário e diferenças de idioma. Perda da comunicação informal, que é essencial para a coordenação do projeto.

50 Como contornar o problema?
É importante estruturar as equipes evitando ao máximo a necessidade de comunicação entre pessoas distantes geograficamente. Projetar uma arquitetura o mais modular possível. Utilizar ferramentas para facilitar a comunicação. Estimular a documentação do projeto.

51 Diferenças culturais Pessoas de culturas diferentes podem se sentir incomodadas com as atitudes umas das outras, favorecendo situações de conflito. Ao abranger culturas diferentes, as dificuldades de entendimento tendem a crescer.

52 Diferenças culturais “Não” “Não, mas ficaria feliz em aprender” “Sim!”
Considerando que a seguinte pergunta seja feita a 3 pessoas de nacionalidades diferentes, sendo que nenhuma delas conhece o ERP 4.5. Cliente: “Você conhece o ERP 4.5?” Holandês: Americano: Indiano: “Não” “Não, mas ficaria feliz em aprender” “Sim!”

53 Como contornar o problema?
Definir um glossário comum para todas as pessoas envolvidas; Procurar entender as diferenças culturais existentes; Realizar reuniões, treinamentos, workshops para informar sobre as diferenças culturais.

54 Perda do espírito de equipe
Como as pessoas ficam dispersas geograficamente elas podem acabar não se sentindo como se fossem parte de uma “equipe”. A perda do espírito de equipe prejudica questões relacionadas a confiança e comprometimento com as atividades.

55 Como contornar o problema?
Estimular a comunicação constante entre os membros do projeto. Estimular viagens para encontros entre os membros do projeto, especialmente no início.

56 Gerência de Contrato com os Fornecedores
(Supplier Agreement Management - SAM)  Gerenciar a aquisição de produtos e serviços dos fornecedores/clientes. OE 1 – Estabelecer contratos com os fornecedores/clientes. OE2 – Satisfazer contratos com os fornecedores/clientes SG 1 Establish Supplier Agreements SP 1.1 – Determine Acquisition Type – (Pág. 119 – Offshoring) SP 1.2 – Selecting Suppliers (Pág. 122 – Offshoring) SP 1.3 – Establish Supplier Agreements (Pág. 124 – Offshoring) SG 2 Satisfy Supplier Agreements

57 Continuidade do Serviço
(Service Continuity - SCON)  Estabelece e mantém planos de contingência para continuidade do serviço em caso de interrupções. Exemplo: desastres naturais ou eventos humanos (greve, por exemplo). OE1 – Identificar Recursos Essenciais para o Serviço OE2 – Preparar a continuidade do serviço OE3 – Verificar e validar o plano de continuidade do serviço Dar o exemplo do que aconteceu no Japão.

58 Falar de como muitos serviços foram interrompidos em decorrência do terremoto.
Muitas empresas como a Sony e a Mitsubishi foram afetadas pelo terremoto. Com isso, houve uma alta de preços em vários componentes eletrônicos, como os chips de memória usados em notebooks, celulares e tablets como o iPad. Detalhe: O Japão fornece 40% dos componentes eletrônicos usados no mundo.

59 - É preciso antecipar os riscos (Risk Management) e incluir no contrato (Supplier agreement management) as opções disponíveis em caso de descontinuidade do serviço. O cliente fica responsável por escolher qual a melhor opção. - É necessário ter contatos de outros fornecedores que poderiam realizar o serviço. Exemplo: Pittsburgh é a cidade que mais fornece componentes eletrônicos no mundo depois do Japão. O serviço poderia ser então terceirizado de forma que os componentes eletrônicos “faltosos” fossem comprados, deixando o “ônus” do valor para as empresas clientes (conforme especificado no contrato).

60 Gerência Quantitativa do Projeto
(Quantitative Project Management - QPM) Gerenciar o processo definido para o projeto visando alcançar a qualidade e os objetivos de performance definidos. OE 1 - Preparar para a gerência quantitativa. OE 2 – Gerenciar quantitativamente o projeto

61 Conclusão Atualmente, muitas organizações estão distribuindo seus projetos, migrando de mercados locais para mercados globais. Existem vários problemas associados aos projetos distribuídos, mas muitos esforços foram realizados para contornar esses problemas, como por exemplo a criação de ferramentas, técnicas e modelos de processo (como o CMMI for Services).

62 Conclusão Uma empresa que souber aproveitar as vantagens dos projetos distribuídos terá mais chances no novo mercado competitivo e global que está surgindo.

63 Perguntas?