Gestão de Projetos Além do Óbvio apresenta casos reais de projetos de software para ilustrar os desafios da gestão. Os casos demonstram como fatores como escopo, comunicação, tamanho da equipe e metodologia impactam o sucesso dos projetos. A apresentação também discute a diferença entre indústrias de replicação versus criação e introduz o Framework Cynefin para auxiliar na escolha da abordagem correta de acordo com o tipo de problema.

1. Gestão de Projetos
Além do Óbvio
Débora Modesto & Douglas Siviotti
Outubro de 2019

2. Sobre esta Apresentação
2/62
1. Caso Emblemático
2. Apresentação dos Palestrantes
3. Teoria sobre projetos e processos
4. Diferenças entre as indústrias (Modelo de criação vs. Modelo de replicação)
5. Cases reais
6. Gestão com eficácia
7. Framework de caracterização de problemas

3. Vamos começar...
3/62
...assistindo um case emblemático

4. O CASO CHALLENGER

7. 73 segundos após a decolagem
A Challeger Explodiu

9. O que isso tem a ver com
Gerenciamento de Projetos
Gestão vai além dos gerentes.
O planejamento é importante, mas ele não garante o sucesso do
projeto isoladamente.
Gerenciar riscos é diferente de gerenciar crises - não adianta saber
dos riscos se tratá-los apenas quando se materializam.

10. Quem é Débora Modesto
10/62
●
Gerente de Projetos na área de TI, trabalha no SERPRO
(Serviço Federal de Processamento de Dados) há 10 anos
●
Trabalhou no mercado privado em empresas de consultoria
como EDS e Accenture
●
Graduada e Mestre pela Universidade Federal do Estado do
Rio de Janeiro (UNIRIO)
●
Experiência: gestão de pessoas e projetos na área do
CNPJ, Dívida Ativa da União e Comércio Exterior
●
Autora do blog ArteSoftware
●
Paixão: transformar ideias em produtos reais, resolver
problemas e usar a gestão para ajudar e guiar pessoas.

11. Quem é Douglas Siviotti
11/62
●
Arquiteto de Software no SERPRO
●
Atua há mais de 20 anos como desenvolvedor e consultor.
●
Analista de sistemas, pós graduado em engenharia de
software pela Universidade Federal do Rio Grande do Sul.
●
Entusiasta da qualidade e da excelência no
desenvolvimento de software
●
Autor do blog ArteSoftware

12. 12/62
Um projeto é um empreendimento
para gerar um resultado e,
por natureza, é
temporário e
exclusivo.
Relembrando o que é um projeto
Ele precisa ser tangível
e viável, mas conta
com restrições de
recursos.

13. 13/62
Organizar uma viagem para a Europa Lançar um foguete tripulado até a lua
Desenvolver um novo celular Construir um prédio

14. O Gerenciamento de Projetos
14/62
As áreas de conhecimento do gerenciamento de projetos são:
●
Escopo
●
Integração
●
Custos
●
Qualidade
●
Aquisições
●
Recursos (Materiais, Equipamentos, Pessoas)
●
Comunicações
●
Riscos
●
Cronograma
●
Partes Interessadas

15. O Gerenciamento de Projetos
15/62
As áreas de conhecimento do gerenciamento de projetos são:
●
Escopo
●
Integração
●
Custos *
●
Qualidade
●
Aquisições *
●
Recursos (Materiais, Equipamentos*, Pessoas)
●
Comunicações
●
Riscos
●
Cronograma
●
Partes Interessadas
* particularidades da nossa
empresa

16. 16/62
Projetos precisam ser guiados por Processos de Trabalho.
Processo = conjunto de atividades que transformam entradas em saídas
Gera resultados padronizados
Os Processos

17. Os Processos
17/62
Os processos do gerenciamento de projetos são basicamente:
●
Início
●
Planejamento
●
Execução
●
Monitoramento e Controle
●
Encerramento
Se aplicam a qualquer indústria

18. 18/62
A diferença entre as indústrias e os sistemas produtivos
Modelo de Replicação
vs.
Modelo de Criação

19. 19/62

20. 20/62
Modelo de Replicação
Gera itens físicos
Prevê redução de variabilidade (tender a zero)
Precisa processos prescritivos

21. 21/62

22. 22/62
Modelo de Criação
Gera informação (que gera receita)
A variabilidade é inerente ao processo, sendo
natural e necessária
A gestão precisa comportar a variabilidade através
de um modelo que suporta a experimentação
Fazer uma coisa exatamente igual a outra acaba
gerando desperdício

23. 23/62

24. 24/62
Chef
vs.
Cozinheiro

25. 25/62
Naturezas distintas
Soluções distintas

26. 26/62
Origem do problema de gestão de software:
O único modelo conhecido era o industrial
Foco em: CONFORMIDADE
Produzir mais com menos, com menor variabilidade possível

27. 27/62
Características:
Ambiente estático de planejamento e controle
Otimizar as técnicas é a excelência
Robotização elimina desperdício
Objetivo: tornar o processo estável e controlado

28. 28/62
EFICIÊNCIA
Fazer as coisas do jeito certo

29. 29/62
Na indústria da criação
fazer gestão é a constante
tomada de decisão e adaptação

30. 30/62
Crise do Software (década de 70): Engenharia de software
praticamente inexistente.
Cenário:
Projetos com orçamento e prazo estourado
Produtos de baixa qualidade que não satisfazia os requisitos
Clientes insatisfeitos

31. 31/62
Crise do Software (década de 70): Engenharia de software
praticamente inexistente.
Cenário:
Projetos com orçamento e prazo estourado
Produtos de baixa qualidade que não satisfazia os requisitos
Clientes insatisfeitos
Anos 90: Saímos do cenário de zero controle para total controle.
Cenário:
Requisitos estáveis
Muitos artefatos
Mais planejamento
Foco em satisfazer os processos
Clientes insatisfeitos

32. 32/62
Crise do Software (década de 70): Engenharia de software
praticamente inexistente.
Cenário:
Projetos com orçamento e prazo estourado
Produtos de baixa qualidade que não satisfazia os requisitos
Clientes insatisfeitos
Anos 90: Saímos do cenário de zero controle para total controle.
Cenário:
Requisitos estáveis
Muitos artefatos
Mais planejamento
Foco em satisfazer os processos
Clientes insatisfeitos

33. 33/62
Case 1: Projeto Catástrofe

34. 34/62
Case 1: Projeto Catástrofe
Prazo político e escopo inviável
●
Processo baseado em RUP
●
Equipe: Experiente, com requisito à parte do desenvolvedor
●
Tecnologia nova - unidade não sabia a linguagem
●
Desenvolvedores alertaram o gerente de que não estava pronto
●
Produto de alto impacto! Ninguém abriu empresa em MG por uma semana e comércio
exterior parou
●
Sistema de uso público sem teste de desempenho (funciona na minha máquina)

35. 35/62
Case 2: Projeto já-nasceu-morto

36. 36/62
Case 2: Projeto já-nasceu-morto
Comunicação e antecipação de todos os requisitos
●
Sistema megalomaníaco
●
Cliente queria definir todo o produto antes de implantar
●
Demorava tanto para definir o requisito e desenvolver, que quando o
um módulo ficava pronto, já não servia mais (8 anos desenvolvendo)
●
UML como projeto e não como rascunho (muito esforço e pouca
reflexão sobre o que era útil)
●
Requisitos e desenvolvedores separados
●
Muitas integrações e comunicação complexa

37. 37/62
Case 3: Projeto nem-nasceu

38. 38/62
Case 3: Projeto nem-nasceu
Patrocínio acabou
●
Reconstrução do case 1 – gerou tanta dívida técnica que o cliente
desejava refazer o produto.
●
Era exatamente o que o cliente precisava e queria para sustentação do
seu negócio.
●
Muito tempo fazendo requisitos e o patrocínio acabou.
●
Produto preso a um stakeholder, como demorou a ser lançado, quem
ficou após a saída dele não sustentou o projeto.

39. 39/62
Case 4: Projeto feijão com arroz – tradicional que funciona

40. 40/62
Case 4: Projeto feijão com arroz – tradicional que funciona
Escopo definido
●
Sistema interno – escopo era evoluir um sistema já existente
●
Clientes presentes e profundamente conhecedores do negócio (da
própria empresa)
Demandas “quebradas” em pequenas entregas
●
Equipe pequena e experiente, em busca da recuperação de confiança
do cliente sobre prazos
●
Acordo sobre entregas sequenciais em menor tempo

41. 41/62

42. 42/62
O mundo mudou….
Exige mais velocidade e menos desperdício para viabilizar
negócios.
Surgiram então os métodos ágeis, focados em:
Minimizar o desperdício
Entregar valor mais rapidamente
Aumentar a colaboração
Maior aceitação da mudança
Melhoria contínua

43. 43/62
Case 5: Agilidade mamão com açúcar - Pequena Escala

44. 44/62
Case 5: Agilidade mamão com açúcar - Pequena Escala
Negócio novo e totalmente diferente da expertise da empresa
●
Previsto para 6 meses, mas entregue em 8 por conta de aumento de
escopo que agregou mais valor que o previsto para o produto
●
Equipe experiente, coesa e pequena
●
Desenvolvedores participavam da definição do produto e, por ser um
produto diferente do que estavam acostumados, precisaram entender o
negócio
●
Cliente in loco
●
Alto diferencial para o cliente: software barateou operações

45. 45/62
Case 6: Agilidade Insana – ágil em larga escala

46. 46/62
Case 6: Agilidade Insana – ágil em larga escala
Alta complexidade de gestão
●
Mais de 10 módulos - integração era ponto de atenção
●
Sistema distribuído (complexidade técnica alta)
●
Segurança baseada nos testes
●
Scrum – analogia do trem para publicações
●
Diferencial: cliente entendia a necessidade
●
Cliente presente
●
Prazo político na Release 1 do produto – horas extras, geração de
dívida técnica e entrega do produto no prazo

47. 47/62
Depois dos exemplos, então, por que fazer gestão?
A gestão é necessária por causa das interações em um sistema:
Equipe, Comunicação, Integração, Produtos, Demandas, Clientes,
Gerentes, Investidores etc.
O que aumenta a complexidade da gestão ao longo do tempo é o
aumento das interações

48. 48/62
Modus Operandi da Indústria da Criação
Se a variabilidade é inerente ao processo (natural e necessária) qual é o
fator mais importante para a gestão?

49. 49/62
Modus Operandi da Indústria da Criação
Se a variabilidade é inerente ao processo (natural e necessária) qual é o
fator mais importante para a gestão?
FEEDBACK
O output do processo serve como insumo para rever o processo.
Processo ideal: empírico

50. 50/62
Adianta ser eficiente na indústria da criação?
Eficiência é uma premissa. É fazer algo do jeito certo, por exemplo,
programar, testar, etc. Isso significa quão bem os recursos são usados
para atingir um determinado fim.
Ela pode ajudar a reduzir custos ou aumentar a capacidade de
produção, mas não vai afetar o produto final.
Ela lida com a ideia de produzir mais (maior volume)
com menos (menor custo).

51. 51/62
Adianta ser eficiente na indústria da criação?
A indústria da criação demanda EFICÁCIA.
Fazer a coisa certa.
Já pensou que
quanto mais corretamente
você faz a coisa errada,
mais errado você fica?

52. 52/62
Como ser EFICAZ?
Todas as opções envolvidas em uma decisão são hipóteses, suposições,
e que só saberemos se tomamos a decisão certa quando pudermos
avaliar a eficácia dessa decisão → a posteriori.
Fórmula do sucesso: ser capaz de validar rapidamente
se a opção escolhida foi acertada ou não,
e ajustar o curso antes que mudar se torne custoso demais.
Ser EFICAZ é minimizar o tempo para validação de uma hipótese.

53. 53/62
Como ser EFICAZ?
Exemplos:
Nos testes de um sistema
Teste das pequenas partes vs. Teste do todo ao final
No desenvolvimento de uma solução para um cliente
Ciclo de entrega rápido vs. Ciclo de entrega longo
Na coordenação tática da equipe
Validar o andamento esporadicamente vs. Validar diariamente

54. 54/62
Framework Cynefin
SIMPLES / ÓBVIO
Previsível
Causa-efeito repetível
Mundo das melhores práticas

55. 55/62
Framework Cynefin
SIMPLES / ÓBVIO
Previsível
Causa-efeito repetível
Mundo das melhores práticas
COMPLICADO
Alguma previsibilidade
Causa-efeito analisável e até repetível
Mundo das boas práticas

56. 56/62
Framework Cynefin
COMPLEXO
Imprevisível
Causa-efeito analisável em retrospecto
Práticas emergentes
SIMPLES / ÓBVIO
Previsível
Causa-efeito repetível
Mundo das melhores práticas
COMPLICADO
Alguma previsibilidade
Causa-efeito analisável e até repetível
Mundo das boas práticas

57. 57/62
Framework Cynefin
COMPLEXO
Imprevisível
Causa-efeito analisável em retrospecto
Práticas emergentes
CAÓTICO
Crise
Nenhuma causa-efeito perceptível
Intervenção para estabilização
SIMPLES / ÓBVIO
Previsível
Causa-efeito repetível
Mundo das melhores práticas
COMPLICADO
Alguma previsibilidade
Causa-efeito analisável e até repetível
Mundo das boas práticas

58. CONCLUSÃO
58/62

59. 59/62
Para cada tipo de problema, há um tipo de solução.
CONCLUSÃO

60. 60/62
Para cada tipo de problema, há um tipo de solução.
O bom gerente busca um
repertório de práticas.
CONCLUSÃO

61. 61/62
Todas as pessoas exercem a gestão em
algum nível, não só o gerente.
Para cada tipo de problema, há um tipo de solução.
O bom gerente busca um
repertório de práticas.
CONCLUSÃO

62. Muito Obrigado!
Perguntas?
Douglas Siviotti de Alcantara
douglas.siviotti@gmail.com
github.com/siviotti
Débora Maurmo Modesto
deb.modesto@gmail.com
www.artesoftware.com.br