gestão Ágil de projetos aplicada no desenvolvimento de ... · prof. dr. daniel c. amaral usp –...

Workshop Gestão de Projetos em Desenvolvimento de Produto31/03/08

Prof. Dr. Daniel C. AmaralUSP – São Carlos

UFRGS – PPGEP – LOPP – UFRGSwww.producao.ufrgs.br/gedepro 1

Gestão Ágil de Projetos Aplicada no Desenvolvimento

de Novos Produtos

Prof. Daniel Capaldo AmaralProf. Daniel Capaldo AmaralGrupo de Engenharia IntegradaGrupo de Engenharia Integrada

Escola de Engenharia de São Carlos Escola de Engenharia de São Carlos -- EESCEESCUniversidade de São Paulo Universidade de São Paulo -- USPUSP

Objetivos

• Apresentar o conceito de Gerenciamento Ágil de Projetos

aplicado no desenvolvimento de produtos inovadores

• Descrever pesquisas em andamento sobre o tema e

resultados parciais




Visão geral das abordagens de desenvolvimento de produtos

Desenvolvimento Seqüencial

Eng. Sim. ParalelismoEquipe Multidisciplinar

DFMA, QFDCliente-fornecedor

Gestão de projetosControle de recursos

Profissionais generalistasVisão ampla – processo

Revisão de fases Fases formais Revisão de fases

Estratégia de Produtos

P&D + PDP na estratégia Portfólio (funil de projetos)

Ágilidade ?

DP Lean

DFSS

Maturidade

Metodologias de projeto

Hoje

TempoDesenvolvimento Integrado de ProdutosDesenvolvimento

Sequencial

O que é Agilidade ?

• É a habilidade de criar e responder às mudanças de forma a responder às mudanças do ambiente

• É a habilidade de balancear flexibilidade e estabilidade

(Highsmit, 2004).




Gerenciamento Ágil de Projetos Agile Project Management - APM

• É a abordagem de gestão de projetos que busca a flexibilidade, simplicidade, iterações em períodos curtos de tempo e agregar valor ao produto de forma incremental (BECK, 1998; BOEHM, 2002; CHIN, 2004; COCKBURN, 2002; COHN; FORD, 2003; HIGHSMITH, 2004; SANJIV; WOODCOCK, 2003).

• As metodologias ágeis são orientadas para o resultado do projeto. Buscam adaptar o processo para absorver mudanças no escopo e funcionalidades do produto (ANGIONI, 2006).

Contexto

• Chin (2004), Fowler (2000) e Highsmith (2004) descrevem a gestão de projetos tradicional como sendo uma metodologia estruturada por processos, com ênfase no planejamento detalhado e, portanto, resistente às mudanças.

• Ao intensificar o tempo dedicado aos planos e controles, gera-se esforço em gestão desproporcional aos benefícios em desempenho do projeto.

• Segundo Chin (2004), há situações aonde isso é especialmente verdade:

� Quando o grau de inovação é elevado

� Quando as esquipes são pequenas

• Segundo os autores seria necessário novas técnicas para gerenciamento de projetos, mais simples e com foco no valor agregado.




Repensando a gestão de projetos

•Em 2003 foi publicado o resultado de uma pesquisa em rede, apoiada pelo pelo Engineering and Physical Sciences Research Council (EPSRC) do Reino Unido, chamada de “Rethinking Project Management” (2004-2006).

•O objetivo foi confrontar problemas e desafios encontrados pelas empresas, frente às idéias dominantes da literatura de gerenciamento de projetos. A meta era apresentar direções para futuras pesquisas sobre gerenciamento de projetos.

WINTER, M. et al. Directions for future research in project management: the main findings of a UK government-funded research network. International Journal of Project Management, v.

24, n. 8, p. 638-649, nov., 2006.

Engineering and Physical Sciences Research Council (EPSRC) X APM

VISÃO ÁGIL

Ambiente de Incerteza/Times adaptativos

Foco nas Pessoas

Criação de Valor para o Cliente

Encorajar exploração/Adaptabilidade doproduto

Capacidade de adaptação do processo edas pessoas

DIREÇÕES DO EPSRC

Direção 1 – Teoria de complexidade

Direção 2 – Projeto como Processo Social

Direção 3 – Foco na criação do Valor

Direção 4 – Conceituação ampla

Direção 5 – Praticantes Refletivos




Engineering and Physical Sciences Research Council

(EPSRC) X APM

VISÃO ÁGIL

Ambiente de Incerteza/Times adaptativos

Foco nas Pessoas

Criação de Valor para o Cliente

Encorajar exploração/Adaptabilidade doproduto

Capacidade de adaptação do processo edas pessoas

DIREÇÕES DO EPSRC

Direção 1 – Teoria de complexidade

Direção 2 – Projeto como Processo Social

Direção 3 – Foco na criação do Valor

Direção 4 – Conceituação ampla

Direção 5 – Praticantes Refletivos

Princípios da APM

• Foco no valor adicionado ao cliente� Foco no valor agregado� Utilizar o conceito de entregas e iterações baseadas em

especificações do produto� Excelência técnica (gerentes de projeto com domínio da

tecnologia)

• Estilo de gerenciamento baseado em liderança e colaboração� Os resultados finais (entregas) são reportados progressiva e

continuamente� Encorajar a exploração� Construir equipes auto-organizadas e auto-disciplinadas� Simplificar

mudança de foco: do planejamento e controle, para execução e adaptação, conforme descrito por Highsmith (2004) e Chin (2004)

Fonte: Highsmith (2004)




Fases da APM

• Visão - determinar a visão do produto, o escopo do projeto, a comunidade do projeto e a definição de como a equipe irá trabalhar

• Especulação - definir entregas, cronograma e o plano de iteração de acordo com a visão

• Exploração - entregar os componentes do produto (requisitos de projetos pré-definidos na fase da especulação) em ciclos de entregas reduzidos, minimizando riscos e incertezas

• Adaptação - rever os resultados entregues, analisar a situação atual e o desempenho do time. Adaptar esses resultados se necessário

• Encerramento - encerrar o projeto, finalizar tarefas pendentes e transferir as lições aprendidas mais importantes

Fonte: HIGHSMITH, 2004

Abordagem ágil de gestão de projetosAbordagem ágil de gestão de projetos

Especular Explorar

Adaptar

Plano deentregas

Funcionalidades completas

EncerramentoEncerramento

Produto final HIGHSMITH (2004)

Inovação contínua;Adaptabilidade do produto;Tempo das entregas reduzidos

Adaptabilidade do processo e das pessoas;Resultados confiáveis

Lista de Funcionalidades

VisãoArquiteturado produto

Framework





Especular Explorar

Adaptar

Plano deentregas







VisãoArquiteturado produto

Framework

Práticas da fase de visão

Categoria Prática Objetivo

Visãodo

produto

Visão do produto eDeclaração “de

elevador”[1]

Métodos para registrar diferentes visões dos membros do timeem forma textual curta, visual e concisa. O objetivo é forneceruma visão de alto nível do produto para os desenvolvedores,gerentes e pessoal de marketing.

Arquitetura do produtoDesenvolvimento da arquitetura técnica do produto, de forma afacilitar a exploração e assegure um direcionamento àcondução dos trabalhos e à organização da equipe do projeto.

Escopodo

projetoFolha de dados do projeto

Tem por objetivo “fazer saber a essência” em termos de escopo,cronograma, e recursos de como o projeto fará as entregas.

Comunidadedo

projeto

Escolha das pessoas certas

Montagem da equipe do projeto buscando sempre atrair eselecionar os melhores talentos.

Identificação dos participantes

Identificar todos os participantes do projeto, de forma que asexpectativas possam ser entendidas e gerenciadas.

Interface entre equipe do cliente e equipe de projeto

Definir a interface de colaboração entre a equipe do cliente e aequipe do projeto.

AbordagemAdaptação de processos

e práticas

Desenvolver o conceito de auto-organização. Conceito detrabalho em equipe aonde todos estão atentos às questõesrelacionadas com a gestão.





Especular Explorar

Adaptar

Plano deentregas







VisãoVisãoArquiteturado produto

Framework

Práticas da fase de especulação


Feature Breakdown Structure

Lista de Especificações (features) do

produto

Expandir a visão do produto por meio de um processo evolucionário de definição de requisitos e especificações do produto. Especificação (feature): “é uma característica ou funcionalidade que adiciona valor ao cliente ”

Cartões de especificações

A proposta dos cartões de especificação é proporcionar um meio simples para obter as informações sobre as especificações. Toda a equipe (não somente o gerente de projeto) é encorajada a criar cartões de especificações e utilizá-los (alterando-os) durante reuniões com os clientes.

Cartões de Requisitos de Desempenho

Documentar os requisitos de desempenho do produtoque será desenvolvido.

Plano de VersõesAbordagem

Versão, Marco e Plano de

Iteração

Ao invés de identificar atividades, a visão é alcançadapor meio do planejamento de marcos para diferentesiterações. Cada iteração é associada a um conjunto deespecificações (fetaures do produto).

Fonte: Adaptado de HIGHSMITH, 2004, p. 92.-125.




Práticas da fase de especulação

Lista de Especific

ações

Feature Breakdown Structure

Cartão de EspecificaçãoCartão de

EspecificaçãoCartão de EspecificaçãoCartão de

EspecificaçãoCartão de Especificação

Cartão de DesempenhoCartão de

DesempenhoCartão de Desempenho

Plano de Iterações

Plano de Iterações

Iteração 0 Iteração 1 Iteração 2 Iteração 3

Especificação 1

Especificação 2

Especificação 3

Especificação 4

Especificação 5

Especificação 6

Especificação 7

Arquitetura 1.1 Arquitetura 1.2 Arquitetura 2Arquitetura 0





Especular Explorar

Adaptar

Plano deentregas








Framework

Práticas da fase de exploração


Objetivos por meio de

Entregas

Gestão da carga de trabalho

A meta é fazer com que o próprio time gerencie a sua carga detrabalho diariamente identificando as atividades necessáriasconforme as necessidades de entrega de especificações(features).

Práticas Técnicas

Mudanças de baixo custo

O objetivo é manter mudanças constantes, porém pequenas,durante todo o desenvolvimento do produto. Garantindo umacompanhamento contínuo. Isso é feito por meio da busca desoluções simples, esforço concentrado nas etapas iniciais dodesenvolvimento e verificações de integração frequentes.

Comunidade de Projeto

Coaching e desenvolvimento

da equipe

Garantir que os membros da equipe aprimorem constantemente odomínio do conhecimento (técnio e de negócios) de forma a obtera auto-disciplina.

Reuniões diárias de integração

Coordenar as atividades da equipe de maneira diária.

Processo de decisão

participativo

Garantir que todos se envolvam nas decisões por meio depráticas frequentes de discussões focadas (aonde participemapenas os colaboradores envolvidos e capazes de constribuir)

Interação diária com clientes

Garantir o acompanhamento do atendimento das necessidadesdos clientes.

Fonte: Adaptado de HIGHSMITH, 2004, p. 92.-125.





Especular Explorar

Adaptar

Plano deentregas








Framework

Práticas de Adaptação e Controle)

• Customer Focus Groups. Realizar freqüentemente clínicas com clientes para avaliar o produto;

• Revisões Técnicas.• Avaliação de desempenho das pessoas da equipe. O

gerente avalia constantemente a equipe.• Relatórios de situação dos projetos.

� utilizar dois ou mais modelos de relatórios de acompanhamento, em geral, emitidos em ciclos de duas a quatro semanas

� Podem ser gráficos simples com determinados indicadores de desempenho do projeto (seguindo o princípio de controle visual).

� Podem possuir uma lista de datas importantes, comparação de resultados reais versus planejado, porcentagem de testes aceitos, e um texto simples (de 2 a 5 parágrafos) descrevendo a situação do projeto acompanhado de uma lista dos riscos mais relevantes (Fonte: COHN; FORD, 2003)




Aplicabilidade segundo Highsmith(2004)

Ágil Clássico

Ágil Clássico

Ágil Clássico

Ágil Clássico

Ágil Clássico

Projeto operacional

Projetos de novas tecnologias e plataforma

Projetos de desenvolvimento

de produto e processo

Uma única organização

envolvida no projeto

Várias organizações envolvidas

no mesmo projeto

Ágil Clássico

Uma única empresa, mas com

múltiplas organizações

envolvidas no projeto

Desafios

1.Novo discurso para as práticas tradicionais ?

2.Seria mais adequado para produtos do tipo software ?

... Na verdade, faltam estudos comprovando resultados

Nós iremos testar uma nova metodologia

chamada Programação Ágil

Significa nada de planejamento e nada de documentação. Apenas

escreva os códigos e verifique

Enfim ! Este é o nosso

treinamentoFiquei feliz em saber que há um nome para isso




Desafio 1 – Avaliar cientificamente - funciona? apenas para software ?

Ano Autor Título

1998 BECK, K.et al. Chrysler goes to “extremes”.

2000 FOWLER, M. The new methodology

2002 COCKBURN, A. Agile software development joins the “would-be” crowd.

2002 REIFER, J. et al. How good are agile methods?

2003 ABRAHAMSSON, P. et al. New directions on agile methods: a comparative analysis

2003 SANJIV, A. et al. Agile project management: emergent order through visionary leadership.

2003 UDO, N. et al. Will agile change the way we manage software projects? Agile from a PMBoK guide perspective.

2004 LINDSTRON, L. et al. Extreme programming and agile software development methodologies

2004 RAWSTHORNE, D. et al. Managing the work in an agile project

2005 DIAS, M. V. B. et al. Agile project manajement: um novo enfoque para o gerenciamento de projetos de desenvolvimentode sistemas de tecnologia de informação

2005 DIAS, M. V. B. et al Um novo enfoque para o gerenciamento de projetos de desenvolvimento de software

2005 MORIEN, R. Agile management and the Toyota way for software project management

2005 TORRES, J. A. P et al. Software development using agile methodologies: an airline case

2005 KARLSTRÖM, D. et al. Combining agile methods with gtage-gate project management

2005 AUGUSTINE, S. et al. Agile project management: steering from the edges

2006 MILLS, D. et al. Experiences using agile software development for a marketing simulation

2006 KANE, D. W. et al. Agile methods in biomedical software development: a multi-site experience report

2006 AMBLER, S. W. Initiating an agile project

2006 HANSSON, C. et al. How agile are industrial software development practices?

2006 OWEN, R et al. Is agile project management applicable to construction?

2007 BERTEIG, M. et al. Stories of agile work

2007 BARNETT, Liz. Why use agile processes outside of IT?

2007 POLLACK, J. The changing paradigms of project management

Fonte: Benassi & Amaral (2007)

Diferenças entre softwares e produtos físicos

Fonte: Adaptado de Pressman 1995, p. 13-16

Tipos de ProdutoObservações

Software Produto físico

Desenvolvido ou projetado por engenharia

Manufaturadono sentidoclássico

Os custos do software estão concentrados no trabalho deengenharia. Isso significa que os projetos de software nãopodem ser geridos como se fossem projetos de manufatura

Não sedesgasta

Há desgaste

Quando se desgasta um componente de hardware ésubstituído por uma “peça de reposição”. Não existem peçasde reposição para software. Toda falha de software indica umerro no projeto ou no processo por meio do qual o projeto foitraduzido em código executável por máquina. Portanto amanutenção de software envolve consideravelmente maiorcomplexidade do que a manutenção de hardware.

Feitosob

medida

Feitoem

escala

Por exemplo, na construção do hardware cada circuitointegrado possui uma numeração de peça, uma funçãovalidada e definida, uma interface bem definida e umconjunto padrão de diretrizes de integração. Depois que cadacomponente é escolhido, o hardware pode ser montado. Nocaso de software isso não acontece, ou seja, não existemcatálogos ou “peças” pré-existentes que os projetistas podemconsultar ou utilizar para a construção do software.




Novo discurso para práticas tradicionais ?

CHIN, 2004 p. 166

Súmário

• Gestão de Projetos Clássica

• Gestão Ágil de Projetos

• Projetos de Desenvolvimento de Novos Produtos de Alta

Tecnologia

• Desafios para a aplicação da Gestão de Projetos Ágeis




Projetos de Desenvolvimento de Produtos de Alta

Tecnologia

ProjetoDetalhado

5

ProjetoConceitual

4

ProjetoInformacional

3

Lançamentodo Produto

7

PreparaçãoProdução

6

PlanejamentoProjeto

2

no

vid

ade

complexidade

Qual a diferença para projetos de alta tecnologia

Foco nas fases iniciais do PDP

• A fase de concepção merece maior atenção• As equipes precisam ser interdisciplinares• Maior interação nos ciclos de teste e interação




ProjetoDetalhado

5

ProjetoConceitual

4

ProjetoInformacional

3

Lançamentodo Produto

7

PreparaçãoProdução

6

PlanejamentoProjeto

2

Qual a diferença para projetos de alta tecnologia

Foco no valor adicionado ao

cliente

Estilo de gerenciamento baseado em liderança e colaboração

Foc

o no

va

lor

agre

gado

Ent

rega

s ba

sead

as e

m

espe

cific

açõe

s

Exc

elên

cia

Téc

nica

Res

ulta

dos

repo

rtad

os

prog

ress

iva

e co

ntin

uam

ente

Enc

oraj

ar a

ex

plor

ação

Equ

ipes

Aut

o-O

rgan

izad

as

Equ

ipes

Aut

o-D

isci

plin

adas

Sim

plifi

car

Princípios do APM

Gestão de Projetos em Empresas de Alta Tecnologia




Características das Empresas de Base Tecnológica

• Comercializa produtos de alta densidade tecnológica

• Possui proporção significativa de colaboradores altamente capacitados (graduados e pós-graduados)

• Possui proporção significativa dos investimentos em Pesquisa e Desenvolvimento

• Utiliza fontes externas como universidades e clientes; foco gerencial para a inovação

• Possui nível elevado de colaboração.

JONG, J.P.J.; MARSILI, O. The fruit flies of innovations: A taxonomy of innovative small firms. Research Policy, v.35, p. 213–229, 2006.

Avaliação da Literatura

• Há poucos estudos investigando as práticas e dificuldades na gestão de projetos específicas dessas empresas. � O empreendedor (proprietário) é geralmente o elemento

principal em termos de domínio do conhecimento e direcionamento da inovação. A sua atuação é fundamental para o resultado final do projeto de desenvolvimento da tecnologia ou produto

� O aumento da empresa pode significar diminuição do nível de inovação e uma das hipóteses pode ser o crescimento da complexidade dos projetos

� Há fortes evidências de que a melhoria da gestão pode trazer benefícios a estas empresas em termos de resultado da inovação




• Equipes auto-organizadas e disciplinadas são a solução mais adequada.

• O empreendedor (proprietário) é geralmente o elemento principal e gargalo nas equipes de desenvolvimento;

• A formalização pode trazer custos• Colaboradores capacitados


cliente


Foc

o no

va

lor

agre

gado

Ent

rega

s ba

sead

as

em

espe

cific

açõe

sE

xcel

ênci

a T

écni

ca

Res

ulta

dos

repo

rtad

os

prog

ress

iva

e co

ntin

uam

ente

Enc

oraj

ar a

ex

plor

ação

Equ

ipes

Aut

o-O

rgan

izad

as

Equ

ipes

Aut

o-D

isci

plin

adas

Sim

plifi

car

Literatura de EBT’s

Problemas em empresas da região de São Carlos

Antonio da Silva Jucá JuniorAntonio da Silva Jucá JuniorEdivandro Carlos ConfortoEdivandro Carlos Conforto

Daniel Capaldo AmaralDaniel Capaldo Amaral




Método

• Estudo de casos múltiplos• Modelo de Maturidade (OPM3 - Adaptado)• Instrumentos:

� Entrevista semi-estruturada norteada por pautas permitindo certa flexibilidade, mas garantindo profundidade na análise

� Observação direta do pesquisador durante o estudo de campo.

Empresas Estudadas• Empresa A -

� Empresa de software que desenvolve projetos e aplicações para WEB;� Estrutura projetizada;� Relacionamentos com a Universidade de São Paulo e Universidade Federal de São Carlos

• Empresa B� Empresa de tecnologia voltada para o ramo agroindustrial especializada em automação agrícola;� Possui estrutura organizacional do tipo matricial forte;� Forte vínculo com a Embrapa Instrumentação Agropecuária

• Empresa C� serviços de consultoria e desenvolve tecnologia na área de controle de acessos� produtos são baseados em tecnologia desenvolvida internamente - Possui uma estrutura organizacional

matricial forte, onde as equipes de projeto possuem um líder de projeto que direciona a equipe e gerencia as diferentes etapas do projeto;

� Relacionamentos com a Universidade de São Paulo e Universidade Federal de São Carlos• Empresa D

� Serviços de consultoria e desenvolver sistemas de automação � Possui uma estrutura organizacional matricial balanceada.� Pós-graduandos da Universidade de São Paulo (EESC)

• Empresa E� Produtos de software para diversas finalidades. Utilizando e desenvolvendo software livre dentro de seus

projetos, ela emprega o compartilhamento (interno e externo) de informações como forma de acelerar o desenvolvimento e aumentar a qualidade dos novos softwares produzidos;

� Possui estrutura organizacional matricial forte. A empresa E participa de projetos internacionais com equipes remotas de trabalho.

� Ex-alunos e relacionamento com a Universidade Federal de São Carlos e Universidade de São Paulo (EESC)




Incidência das melhores práticas conforme as empresas analisadas (Gráfico Radar)

Resultados por área

As atividades que envolvem o

gerenciamento de pessoas, atividades e

custos são as mais presentes no dia a dia

dos envolvidos em projetos destas

empresas.





As atividades de comunicação e qualidadeapresentaram uma baixa pontuação em relação às demais, apesar disso não

significar, segundo as observações no campo,

problemas ou dificuldades de comunicação do

projeto.


O questionário perguntava também quais os maiores problemas enfrentados pelas empresas em GP:

• Nenhum entrevistado apontou problemas de qualidade na entrega;

• Houve unanimidade de que o maior problema das empresas era gerenciar prazos e planejar a capacidade




Conclusões Principais

1. Há a necessidade de aprimorar o nível de gestão de projetos destas empresas

2. Revisão das Teorias de Gestão de Projetos � pode haver incompatibilidades entre as necessidades e características

específicas dessas empresas e a teoria de gerenciamento de projetos, especificamente os modelos de maturidade.

� Exemplo: � práticas relacionadas às categorias gestão da qualidade e comunicações � Segundo os critérios do OPM3 obtém-se níveis baixos de pontuação. Isso deveria significar deficiências. Dados da observação no campo, entretanto, demonstram o contrário. � As maiores dificuldades citadas pelos gerentes foram itens como controle de prazos, sinalizadas como as de melhor prática segundo o modelo de maturidade.

� Portanto. Seria necessário repensar as teorias de GP, tanto os modelos de maturidade como as práticas.

� Pesquisas que revejam os métodos e os adaptem a esta realidade aonde o papel do gerente de projetos, o empreendedor-desenvolvedor, é diferenciado.

Pesquisas futuras indicadas no estudo

• Há um campo de pesquisa importante em métodos e técnicas que possam trazer níveis mais avançados de padronização e melhoria no gerenciamento de projetos em pequenas EBT’s.

• O efeito identificado por Tsai & Wang (2005) de diminuição da produtividade em inovação com o crescimento das pequenas empresas pode estar intimamente relacionado a este fato.

• Os instrumentos de gestão utilizados nessas empresas, baseados nas relações pessoais, informais, que o empreendedor mantém com equipe e cliente, tornam-se ineficazes com o crescimento.

• Estudo do papel dos agentes de governança no apóio à gestão de projetos: � Estruturas de escritório de projetos voltados para arranjos produtivos

ou conjuntos de empresas.� Indicadores de desempenho




• Como empreendedor (proprietário) é geralmente o elemento principal e a formalização pode trazer custos, o conceito de equipes auto-organizadas e auto-disciplinadas seriam soluções adequadas.

• Colaboradores capacitados ajudam.

• Permitiria o crescimento sustentável mantendo a exploração a colaboração.


cliente


Foc

o no

va

lor

agre

gado

Ent

rega

s ba

sead

as

em

espe

cific

açõe

sE

xcel

ênci

a T

écni

ca

Res

ulta

dos

repo

rtad

os

prog

ress

iva

e co

ntin

uam

ente

Enc

oraj

ar a

ex

plor

ação

Equ

ipes

Aut

o-O

rgan

izad

as

Equ

ipes

Aut

o-D

isci

plin

adas

Sim

plifi

car

Estudo de Caso 1

Estudo de Caso - Aplicaçãode Escritório de Projetos

Sanderson Barbalho (EESC/USP) Sanderson Barbalho (EESC/USP) Daniel Capaldo Amaral (EESC/USP) Daniel Capaldo Amaral (EESC/USP)

João H. Roziz (EESC/USP)João H. Roziz (EESC/USP)Tiago Sanches Kernbinchler (UFSCAR)Tiago Sanches Kernbinchler (UFSCAR)




Tecnologias Básicas

Linha Oftalmológica (ap. 28 produtos) Linha Odontológica (2 linhas)

Tratamentos de Lentes (Antireflexo)

Componentes ÓpticosLaser Industial

Microscópios

Refletores

Aplicações

Percepção dos envolvidos em projetos sobre a eficácia do trabalho do escritório de projetos

• Foram ouvidas 9 pessoas da população de 21 profissionaisque atuam diretamente no desenvolvimento dos projetos (43%)

• A amostra foi estratificada segundo as diferentes competências técnicas (mecânica, eletrônica, térmica, ótica e filmes finos) e fases do projeto (projeto, protótipo e manufatura)

• O questionário solicitava que os respondentes analisassem cada uma das novas práticas quanto à eficácia no apoio ao trabalho de desenvolvimento realizado. Eles escolhiam segundo uma escala Likert: Discordo Totalmente, Discordo, Indiferente, Concordo e Concordo Totalmente.




Grau de Satisfação Geral do Pessoal Envolvido

17%

10%

20%

36%

17%

0%

5%

10%

15%

20%

25%

30%

35%

40%

1

Disc.TotalmenteDiscordoIndiferenteConcordoConc.Totalmente

Grau de Satisfação por Tipo de Atividade

27%

11%

13%

22%

5%

0%

24%

16%

20%

24%

41% 40%

4%

27% 27%

0%

5%

10%

15%

20%

25%

30%

35%

40%

45%

1 2 3

DT

D

I

C

CT

Tipo A Tipo B Tipo C

A – Atividades de planejamento e controleB – Redução do lead time de protótiposC – Organização e controle de documentos

DT – Discordo totalmente / D –Discordo /I – Indiferente / C –

Concordo / CT – Concordo Totalmente




Resultados da Avaliação de Percepção

• O impacto do trabalho do PMO não era perceptivo para todos os envolvidos em projetos

• As atividade do tipo planejamento e controle foram consideradas as menos efetivas. Hipóteses:

�sensação de vigilância

�crença existente na organização de que tais atividades podem diminuir a “criatividade” e, portanto, a inovação

�nível elevado de detalhe frente às necessidades da organização

• As atividades consideradas mais eficazes eram aquelas que tiveram efeitos imediatos no dia-a-dia dos profissionais

Escritório de Projetos

Tipo de ProdutoNível de Maturidade

em GPEstrutura

OrganizacionalAspectos Culturais

Existe uma infra-estrutura que maximiza o uso do escritório de projetos

Sobrecarga do Escritório de

Projetos (Perda de eficiência)

Sub-utilização do Escritório de Projetos (Aumento do custo)




Resultados do caso 2 x APM


cliente


Foc

o no

va

lor

agre

gado

Ent

rega

s ba

sead

as

em

espe

cific

açõe

sE

xcel

ênci

a T

écni

ca

Res

ulta

dos

repo

rtad

os

prog

ress

iva

e co

ntin

uam

ente

Enc

oraj

ar a

ex

plor

ação

Equ

ipes

Aut

o-O

rgan

izad

as

Equ

ipes

Aut

o-D

isci

plin

adas

Sim

plifi

car

Caso 2

Estudar a aplicação de PMO’s que

apóiem práticas de

APM

Motivações para o estudo da APM no desenvolvimento de produtos inovadores


cliente


Foc

o no

va

lor

agre

gado

Ent

rega

s ba

sead

as

em

espe

cific

açõe

sE

xcel

ênci

a T

écni

ca

Res

ulta

dos

repo

rtad

os

prog

ress

iva

e co

ntin

uam

ente

Enc

oraj

ar a

ex

plor

ação

Equ

ipes

Aut

o-O

rgan

izad

as

Equ

ipes

Aut

o-D

isci

plin

adas

Sim

plifi

car

Caso 1 Caso 2Revisões da Literatura de

EBT’s

Revisões da Literatura de

GDP




Súmário

• Gestão de Projetos Clássica

• Gestão Ágil de Projetos

• Projetos de Desenvolvimento de Novos Produtos de Alta

Tecnologia

• Desafios para a aplicação da Gestão de Projetos Ágeis

Temas de Pesquisa em Andamento




Linhas de Pesquisa em Andamento

1. Métodos e técnicas para definição da visão do produto

2. Ferramenta computacional para o gerenciamento ágil de projetos de novos produtos

3. Escritório de Projetos para APM

4. Indicadores de desempenho para a gestão ágil de projetos

Tema 1 - Métodos e técnicas para definição da visão do produto

Categoria Prática Questões relevantes

Visão

do

produto

Visão do

produto

Qual o nível de detalhamento necessário?

Como compartilhar informações?

Como utilizar modelos computacionais 3D para estabelecimento da visão

do produto ?

“Declaração

de elevador”

Como trabalhar com equipes compostas por especialidades distintas

como hidráulica, elétrica, eletrônica e mecânica, que utilizam diagramas

e formas de especificação dos produtos distintos ?

Arquitetura

do produto

Até que ponto do projeto deve haver a definição da arquitetura?

Como criar metodologias para descrever a arquitetura e relacionar com

as interfaces entre equipes de projeto?

Fonte: Benassi & Amaral (2007)




Tema 2 - Ferramenta computacional para o gerenciamento ágil de projetos de novos produtos

Tema 3 - Escritório de Projetos para APM

• O escritório de gerenciamento de projetos (PMO - Project

Management Office) é uma unidade organizacional que centraliza e coordena o gerenciamento de projetos sob seu domínio, operando continuamente e promovendo suporte às funções de GP na forma de treinamentos, software, políticas padronizadas, e procedimentos (PMBok, 2004).

• O objetivo da linha de pesquisa é propor um modelo de PMO com base na abordagem ágil da gestão de projetos.

• Até o momento desenvolveu-se um estudo teórico com o intuito de identificar quais “serviços” de um escritório de projetos precisam ser desenvolvidos ou repensados para apoiar a APM.




Tema 4 Tema 4 –– Indicadores de Desempenho para APMIndicadores de Desempenho para APM

GP Clássica Abordagem Ágil

Prin

cipa

is d

ifere

nças

3

Muitos indicadores com elevado nível de detalhe

Baseados em medidas financeiras

Relatórios complexos

Maior % de indicadores quantitativos

Poucos indicadores, simples e objetivos

Baseados em medidas financeiras e não financeiras

% equilibrada de indicadores quantitativos e qualitativos

Relatórios simplificados, objetivos e visuais

A flexibilidade é premissa

Indicadores inflexíveis, não ajustáveis

Resultados Parciais




Estudo de Caso - Instituto ParqTec de Design

Edivandro Carlos Conforto (EESC/USP)Edivandro Carlos Conforto (EESC/USP)Marcos Brefe (IPD)Marcos Brefe (IPD)

Daniel Capaldo Amaral (EESC/USP)Daniel Capaldo Amaral (EESC/USP)

Descrição da Empresa

• Instituto sem fins lucrativos que presta serviços na área de design industrial para pequenas empresas;

• Cerca de 20 projetos concorrentes com desenvolvimento colaborativo, envolvendo empresas incubadas no ParqTec, com duração aproximada de 3 meses aproximadamente;

• Busca integração Design & Engenharia no desenvolvimento de produtos;




Painel Visual de Planejamento e Controle dos Projetos

Meses

Fev.2008

Mar.2008

Abr.2008

Abr.2008

Mar.2008

Fev.2008

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

Fases do Projeto

Grupo de entregas de um projeto

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

Prioridade de execução dos projetos

Cada conjunto de post-its da mesma cor representam as entregas de um projeto. Esse conjunto pode ser alinhado em baixo de outro conjunto de entregas de outro projeto. Isso indica a prioridade de execução do projeto. De cima para baixo, e da esquerda para direita representa prioridade máxima. Ex.:

(1) Apelido do Projeto

(2) Entrega

(4) Responsável

(5) Data Prevista/Realizada

(3) Cód. Entrega

Dados inseridos no post-it

Indica Entrega com data à vencer

Indica Entrega com data vencida (Atrasada)

Quadro de Instruções para utilização do Painel Visual de Planejamento e Controle de Projetos

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

Entrega com prioridade de execução

Indicação de atraso

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

............

Meses




Planejamento dos pacotes de serviços

Quadro de planejamento fino. Pacotes de serviços (Semanal)

S T Q SQ

Cada post-it irá conter uma atividade a ser desenvolvida, necessária para realizar a entrega (Painel Visual) ex.: pesquisar similares.

No painel visual, cada cor de post-it representa um projeto

diferente

No quadro de planejamento fino, cada cor de post-it representa um membro da equipe de projeto. Por exemplo: se tiver 3 post-its na cor azul, significa que um membro da equipe tem 3 atividades para executar nessa semana.

Dia da Semana

Manhã

Tarde




Quadro de planejamento fino (Work Packages)

Componentes do Modelo de Referência para Gestão Ágil de Projetos IPD

Modelo de Fases e Entregas

Painel Visual para Planejamento e Controle das entregas do projeto

S T Q SQ


Indicadores de Desempenho

Software DotProject

Templates

1. Plano de Projeto

2. Product Design Specification

3. Documento para realização de “Gates”; Sistemática de Gates

Sistemática para armazenamento dos documentos do projeto na

rede IPD

Repositório deConhecimentos(windows)




Modelo de Referência para Gestão Ágil de Projetos IPD

Modelo de Fases e Entregas

S T Q SQ


Pacotes de serviços

3

Head do Projeto

Legenda:EtapasFluxo de

informações

Coordenador IPD

Entregas do projeto

Novoprojeto

Cada pacote de serviço <> LOG.no DotProject

4

Membro da equipe de projeto

Indicadores de Desempenho

5Relatórios de status

dos projetos

6

Equipe de projeto

Painel Visual para Planejamento e Controle das entregas do projeto

Cada post it <> entrega no DotProject

1

2

Software DotProject

Este procedimento não demanda muito tempo (simplicidade)

5%

42%

21%

11%

21%

1

2

3

4

5

Discordo Plenamente

Concordo Plenamente

O procedimento exigirá auto-gestão e auto-disciplina da equipe de projetos

95%

5%1

2

3

4

5

Discordo Plenamente

Concordo Plenamente




Estudo de Caso - O Programa Instituto Fábrica do

Milênio

Daniel Capaldo Amaral (EESC/USP) Daniel Capaldo Amaral (EESC/USP) Cristiano Garcia (IFM)Cristiano Garcia (IFM)

Francis R. Da Silva (IFM)Francis R. Da Silva (IFM)Ricardo Marcacini (IFM)Ricardo Marcacini (IFM)

Solange Rezende (ICMC/USP)Solange Rezende (ICMC/USP)

Grupos de Pesquisa

MCTCNPq

Casos

Cenários

Livros

Divulgação

Institucional

$

Resultados do projeto

Procedimento para controle de projetos do IFM – em funcionamento

Coordenação

AIFMEscritório de Projetos

~800 pesquisadores




Projeto Específico (SP)

Conselho (“Anciões”)

Coordenador Geral

Pacote de Trabalho (WP)

WP6 – Coordenação do Projeto (Escritório de Projetos)

Estrutura Organizacional (Projetizada)

WP6 – Coordenação do Projeto

Apoio

(Informal)

Coordenador Geral

Coordenador do WP6 (Henrique Rozenfeld)

Prof. Alexandra Klen

Prof. Daniel C. Amaral

Coord. Admin.Financeira (Francis)

Coord. Técnica (Cristiano)

Suporte Técnico

Ricardo Marcacini

(Portal IFM)

Lauriberto(Dot Project)

SimoneAdministrativo




Coordenadora

Administrativa

Base de Dados sobre Projetos

(dotproject)Solicitar

Recursos

Base de Dados Financeira

(Gastos por SP)

Planejar (recurso/ atividades

Relatórios de Prestação de ContasRelatório Técnico

Detalhamento dos SP’s

e WP’s

Relatório de Acompanha-

mento

Equipe de Projeto (SP)

Coordenador

Técnico

Coordenador

WP

Visão Geral da Proposta

Visão Geral da Proposta

Coordenadora

Administrativa

Base de Dados sobre Projetos (dotproject)

Base de Dados Financeira (Gastos

por SP)

Relatórios de Prestação de ContasRelatório Técnico

Relatório de Acompanha-

mento

Coordenador

Técnico

(SP)

Pacote de Trabalho (WP)

Coordenador Geral

MCTCNPq

WP6 – Esta estrutura do WP6 foi inspirada em um escritório de projetos, isto é, uma estrutura, composta de

pessoas e recursos, para apoiar a gestão

dos projetos (SP’s)




Coordenador e equipe devem identificar as atividades necessárias (trabalho)

• Portanto:

� O coordenador de SP tem bastante liberdade para definir a melhor EDT/WBS, conforme as necessidades do seu projeto

� Poucos padrões, porém rígidos.

� A única exigência é preecher os requisitos: � Possuir ao menos uma entrega a cada 3 meses.� A entrega precisa ser algo preciso, com metas que possam ser avaliadas e comprovada por meio de documento.

� Ele pode pedir auxílio para a equipe do escritório de projetos

Tipos de planejamento - Somente entregaPlanejando somente as entregas




Indicadores por projeto - Módulo Baseline

Indicadores da Entrega




Considerações Finais



Considerações Finais

• Em projetos complexos de novos produtos (inovadores) precisamos aprimorar as técnicas de GP

• Os resultados parciais mostram que as diretrizes propostas pelos teóricos do APM têm potencial para serem aplicados em projetos de novos produtos

• É preciso desenvolver novas soluções

• Este programa de pesquisa que vem sendo realizado dentro do grupo EI espera auxiliar a desenvolver e sistematizar métodos que possam auxiliar neste desafio.




FIM

Dúvidas ?

Prof. Daniel Capaldo Amaral ([email protected])

Escola de Engenharia de São Carlos (USP)Depto de Engenharia de Produção Instituto Fábrica do Milênio (http://www.ifm.org.br)Núcleo de Manufatura Avançada Grupo de Engenharia Integrada (EI2)http://www.numa.org.br/ei_pt

Grupo de Engenharia Integrada




Estudo de Caso - Cenário utilizando uma ferramenta de

PDM (Smarteam)



Objetivo

Investigar estratégias de integração entre sistemas de controle de documentos e sistemas de gestão de projetos Descrição detalhada do modelo proposto




• Pesquisa-ação • Utilização de sistemas PDM e PM de fácil acesso às

pequenas e médias empresas.• Registro dos dados• Estrutura do trabalho:

� Análise de possíveis integrações� Implantação da mais promissora

Metodologia

• Instalação e parametrização dos sistemas

• Configuração dos dados básicos

• Configuração do Workflow� Encaminhar Problema� ECR� ECO� ECO Relâmpago

• Análise das estratégias de integração e desenvolvimento da mais promissora

Cenário

Conjunto de artefatos que permitem simular ou representar uma empresa real.




Painel de Controle (Módulo

desenvolvido em JSP)

(6) Projeto, Produto, Status, Data limite,

Data de Criação, Data de Término, Tempo

Dispendido e Atraso

Relatório em MS Excel

(5)

Consulta

(7) Projeto, Produto,

Status,Data limite,

Data de Criação eData de Término

MS Project

Gerente de Projeto

RELATÓRIO DE STATUSProjeto, Produto, ID, Status,

Data de Criação, Data limite, Tempo Dispendido e

Atraso

(8)

Sistema

Dados

LegendaDocumento

(1)

Projeto, Produto, Status e

Data limite

SQL Server armazena os

dados

(2)

Armazena

(3)

Tarefa

Prazo

(4)

Horas

Equipe de Projeto

Smarteam (PDM)

Regras do Workflow

Ações

Estratégia Escolhida

Exemplo de Fluxo




http://www.ifm.org.br/controledeprojetos/intro.html

gestão Ágil de projetos aplicada no desenvolvimento de ... · prof. dr. daniel c. amaral usp –...

Documents