Please enable JavaScript.
Coggle requires JavaScript to display documents.
Conceitos de Gerenciamento de Projeto, Capítulo 24 - Coggle Diagram
Conceitos de Gerenciamento de Projeto
Panorama
Por que é importante?
Projetos de software devem ser gerenciados pois o desenvolvimento de software é uma tarefa complexa, principalmente quando envolve muitas pessoas e um longo tempo
Quais são as etapas envolvidas?
Organização das pessoas para o trabalho de desenvolvimento de forma efetiva
Comunicação com o cliente e interessados para compreensão do escopo e os requisitos do produto
Seleção de um projeto adequado para as pessoas e para o produto.
Planejamento do projeto com base na estimativa do esforço e do prazo para realização das tarefas
definir artefatos
Estabelecer pontos de verificação (checagem) de qualidade.
Indentificar mecanismos para monitorar e controlar o trabalho no plano de projeto
Quem realiza?
Todas as pessoas gerenciam, mas o escopo das atividades de gerenciamento varia entre os envolvidos de um projeto para outro
Um engenheiro de software gerencia suas atividades diárias
Gerentes de projeto gerenciam uma equipe de engenheiros de software
Um gerente sênior coordena a interface entre o "lado comercial" e os lados profissionais de software
Qual é o artefato?
Assim as atividade de gerenciamento faz-se um plano de projeto
Define-se o processo e as tarefas a ser conduzidas
Define-se as pessoas que realizarão o trabalho
Define-se os mecanismos
De avaliação de riscos
Do controle das alterações
De avaliação de qualidade
O que é?
Envolve planejamento, monitoração e controle de pessoas, processos e eventos que ocorrem à mediada que o software evolui desde os conceitos preliminares até sua disponibilização, operacional e completa.
Como garantir que o trabalho foi realizado
corretamente?
O gerente de projeto deve encorajar o pessoal de desenvolvimento a trabalhar em conjunto como uma verdadeira equipe, concentrado-se nas necessidades do cliente e na qualidade do produto
Nunca se está completamente seguro de que o plano de projeto está correto até que se entregue um produto de alta qualidade, no prazo e dentro do orçamento
(1) O espectro de Gerenciamento
Gerenciamento efetivo tem um foco nos 4 Ps
Produto
Aquele que falha no encorajamento amplo para comunicação entre os envolvidos, bem cedo, no início da elaboração de um produto, corre o risco de desenvolver uma solução elegante para o problema errado
Antes de traçar um plano de projeto, deve-se:
1 - estabelecer os objetivos do produto e seu escopo
Reunião com os interessados no software (cliente) - Essa atividade se inicia como parte da Engenharia do Sistema ou de Engenharia do processo de negócio e continua como a 1ª etapa da Engenharia de Requisitos
Objetivos = metas gerais do produto
Escopo = principais dados, funções e comportamento que caracterizam o produto (também é necessário definir as fronteiras e limitações dessas características de maneira quantitativa)
2 - considerar as soluções alternativas
capacitam os gerentes e desenvolvedores a selecionar a melhor abordagem, dadas as restrições impostas pelos prazos de entrega, restrições orçamentárias, disponibilidade de pessoal, interfaces técnicas e outros.
3 - identificar as restrições técnicas e de gerenciamento
Processo
Um gerente que preste pouca atenção ao processo, arrisca-se a inserir métodos e ferramentas técnicas competentes em um vácuo
Fornece a metodologia por meio da qual um plano de projeto abrangente para o desenvolvimento pode ser estabelecido
Poucas atividades metodológicas são aplicáveis a todos os projetos de software
Uma quantidade de diferentes conjuntos de atividades-tarefas, pontos de controle, artefatos de software e pontos de garantia de qualidade possibilitam que as atividades metodológicas sejam adaptadas às características do projeto de software e aos requisitos de equipe
As atividades de apoio, como Garantia de Qualidade de SW, Gerenciamento de Configuração e de Medições, sobrepõem-se ao modelo do processo (são independentes de quaisquer das atividades metodológicas que ocorrem ao longo do processo).
Pessoas
O gerente que se esquecer de que o trabalho do eng. de soft. consiste em esforço humano nunca terá sucesso no gerenciamento de projeto
Modelo de maturidade e capacidade dos recursos humanos - People-CMM (desenvolvido pelo SEI)
Práticas-chave
treinamento
gerenciamento do desempenho
ambiente de trabalho
comunicação
formação de equipe
compensação
análise de compepetência e de desenvolvimento
desenvolvimento
do grupo de trabalho
da cultura de equipe, etc.
de carreira
O People-CMM tem maior probabilidade de implementar práticas de gerenciamento de software efeitvos em organizações que conseguem altos níveis de maturidade e capacidade
É um parceiro para o modelo SW-CMMi (conduz as organizações para ciração de um processo de SW mais maduro
Projeto
Aquele que embarcar sem um plano de projeto sólido compromete o sucesso do projeto
Projetos com planejamento, controle e monitoramento é única maneira de administrar a complexidade
Cumprir
Cronograma
Custos
Objetivos quanto à qualidade
(2) As pessoas
"Dos vice-presidentes de engenharia ao desenvolvedor mais simples, frequentemente consideram pessoal como um privilégio; os gerentes afirmam que o pessoal é prioritário, porém, suas opções rebaixam suas palavras"
Os interessados (comprometidos) no processo de software
Gerentes Seniores
Definem os itens de negócio e, com frequência, exercem influência significativa no projeto
Usuários finais
interagem com o software uma vez liberado para uso operacional, em ambiente de produção
Gerentes (técnicos) de projetos
Devem planejar, motivar, organizar e controlar os programadores que executam o trabalho de software
Clientes
Especificam os requisitos para o software a ser submetidos ao processo de engenharia e outros envolvidos que têm interesses periféricos no produto final
Programadores
Devem ter habilidades técnicas necessárias para desenvolver a engenharia de um produto ou aplicativo
Para ser efetiva, a equipe do projeto deve estar organizada para maximizar cada capacidade e habilidade dos profissionais.
Essa é a tarefa do líder da equipe
Líderes de equipe
Modelo MOI de liderança
Organização
A habilidade para moldar os processos já existentes (ou inventar novos) que irão capacitar o conceito inicial para ser traduzido num produto final
Ideias ou inovação
A habilidade de encorajar pessoas para criar e ser criativas mesmo quando estiverem trabalhando de acordo com os padrões estabelecidos para um produto ou aplicativo de SW específico
Motivação
A habilidade para encorajar o pessoal técnico a produzir com o melhor da sua habilidade
Aplicam um estilo de gerenciamento de solução de problemas
Entender o problema a ser resolvido (administrando o fluxo de ideias)
Deixar claro para os membros da equipe (por palavras e ações) que a qualidade conta muito e que não deve ser comprometida
Aspectos chave para efetivo gerenciamento de projeto
Identidade Gerencial
Um bom gerente
Deve ter confiança para assumir o controle quando necessário
Deve assegurar que permitirá ao pessoal técnico seguir os seus instintos
Deve assumir a responsabilidade do projeto
Realizações
Um gerente competente
Deve recompensar iniciativas e realizações para otimizar a produtividade de uma equipe
Deve demonstrar por meio de seus próprios atos que decisões por riscos controlados não serão punidas
Solução de problema
Um gerente eficaz
Diagnostica itens técnicos e organizacionais mais relevantes
Estrutura uma solução ou motiva outros desenvolvedores a buscar a solução
Põe em prática as lições aprendidas de projetos anteriores
Permanece flexível para mudar de direção caso a solução tenha sido ineficaz na solução do problema
Formação de equipe e de influência
Um gerente efetivo
Deve ser capaz de compreender sinais verbais e não verbais e reagir às necessidades das pessoas que enviaram esses sinais
Deve permanecer sob controle em situações de alto estresse
Deve ser capaz de "ler" pessoas
Equipe de software
Existem diversas estruturas organizacionais humanas para desenvolvimento de SW
O gerente do projeto é responsável pela organização do pessoal diretamente envolvido em um projeto
A estrutura de equipe depende
Quantidade de pessoas na equipe
Níveis de habilidade das pessoas
Estilo de gerenciamento das organizações
Grau de dificuldade geral do problema
Fatores que devem ser considerados no planejamento da estrutura da equipe de engenharia de software
Extensão do(s) programa(s) resultante(s) em linhas de códigos ou pontos de função
Tempo que uma equipe trabalhará em conjunto (tempo de vida da equipe)
Grau de dificuldade do problema a ser solucionado
Grau de modularização do problema
Qualidade e confiabilidade do sistema a ser construído
Rigidez das datas de entregas
Grau de sociabilidade (comunicação) requerido para o projeto
“Paradigmas organizacionais” para equipes de engenharia de software:
O paradigma randômico
Equipes que seguem esse paradigma se destacam quando avanço tecnológico e inovação são necessários
Mas, podem ter dificuldade quando é necessário "desempenho ordenado"
Estrutura a equipe de forma livre e depende da iniciativa individual de seus membros
O paradigma aberto
Estrutura a equipe de maneira que consiga alguns controles associados com o paradigma fechado, mas também muito da inovação que ocorre no paradigma randômico
As estruturas das equipes são bem adequadas para a solução de problemas complexos
O trabalho é feito de forma colaborativa, com forte comunicação
e tomada de decisão baseada no consenso
Mas não conseguem desempenhar tão bem quanto outras equipes
O paradigma fechado
Estrutura a equipe em uma hierarquia de autoridade tradicional
Equipes podem trabalhar bem em produção de software bastante similar a esforços de épocas passadas
Mas se mostrarão menos propícias a ser inovadoras trabalhando sob o paradigma fechado.
O paradigma sincronizado
baseia-se na compartimentalização natural de um problema
Organiza os membros da equipe a trabalhar nas partes do problema com pouca comunicação entre si
Para obter uma equipe de alta performance
A distribuição de habilidades deve ser adequada ao problema.
Estrelismos devem ser excluídos da equipe para manter a coesão do grupo.
Os membros da equipe devem confiar uns nos outros.
Seja qual for a organização da equipe, o objetivo em todo o gerenciamento do projeto consiste em ajudar a montar uma equipe que apresente coesão
Uma equipe deve ter consistência
Uma equipe deve ter uma definição de sucesso e um espírito de equipe identificável
Fortemente unida - o todo é maior que a soma das partes
A probabilidade de sucesso é crescente
Não e preciso gerenciá-la do modo tradicional, nem motivá-la
Os membros são mais produtivos e motivados que a média; compartilham de objetivo e cultura comuns
O reconhecimento das forças humanas é o primeiro passo em direção à criação de equipes consistentes
Fatores que fomentam um ambiente tóxico da equipe
um processo de software fragmentado ou pobremente coordenado (tarefas pesadas ou desnecessárias; artefatos mal selecionados)
Pode ser evitado
Pela permissão para que a equipe selecione o modelo do processo
Por meio da compreensão do produto a ser desenvolvido e das pessoas que realizam o trabalho
uma definição nebulosa dos papéis dentro da equipe de software
A própria equipe deve
Estabelecer seus próprios
mecanismos de responsabilidades
Definir uma série de abordagens para correções quando um membro falhar em suas atribuições
Alto grau de frustração que causa atrito entre os membros da equipe
Pode ser evitada oferecendo à equipe responsabilidade para tomada de decisão
contínua e repetida exposição a falhas
Estabelecer técnicas baseadas nas equipes voltadas para realimentação (feedback) e resolução de problemas
Uma atmosfera de trabalho frenética
O coordenador de projeto pode evitar garantindo
a disposição de todas as informações necessárias para realização do trabalho
Que as metas e objetivos prioritários (papéis), um vez estabelecidos, não devem ser alterados a menos que absolutamente necessário
Equipes ágeis
Desenvolvimento ágil tem sido um antídoto para muitos problemas nas atividades de projeto de SW
A filosofia ágil enfatiza
Métodos informais
Mínimos artefatos de engenharia de SW
Pequenas equipes de projetos altamente motivadas
Total simplicidade de desenvolvimento
Satisfação do cliente e a entrega prévia incremental de SW
Adota características das equipes de software bem-sucedidas, e evita muito das toxinas geradoras de problemas
Entretanto, a filosofia enfatiza competência individual casada com colaboração em grupo como fatores críticos de sucesso
Pessoas são o trunfo do processo
Pessoas não boas o suficiente - nenhum processo irá reparar a sua inadequação
Pessoas boas o suficiente - podem usar qualquer processo e realizar a missão
Política é o trunfo de pessoas
Falta de suporte ao desenvolvedor e ao usuário podem matar o projeto
Suporte inadequado pode fazer com que mesmo os bons fracassem na realização de seus trabalhos
Equipes ágeis se auto-organizam
Para uso das competências de cada membro da equipe
Para fomentar colaboração efetiva ao longo do projeto
Muitos modelos ágeis dão autonomia à equipe para fazer o gerenciamento do projeto e tomada de decisões técnicas
O planejamento é mantido em um nível mínimo
A equipe tem permissão para selecionar sua própria abordagem (processo, método, ferramentas), limitadas apenas pelos requisitos de negócio e padrões organizacionais
Reuniões são realizadas diariamente para coordenar e sincronizar as atividades que devem ser realizadas no dia
Com base nas reuniões a equipe adapta a abordagem para incrementar o trabalho
contínuas auto-organizações e colaboração conduzem
a equipe em direção a um incremento de software completo
Itens de comunicação e coordenação
Características do software moderno
Incerteza
Incertezas são comuns, resultando em contínua
cadeia de alterações que racham a equipe de projeto
Interoperabilidade
Novo software deve se comunicar com os softwares existentes e se ajustar a restrições predefinidas impostas pelo sistema ou pelo produto.
Escala
A escala de muitos esforços em desenvolvimento é ampla, conduzindo a complexidade, confusão e dificuldades significativas na coordenação dos membros da equipe
Para lidar com essas caracterísicas, deve-se estabelecer mecanismos para comunicação formal e informal entre os membros de equipes
Efetivos para coordenar pessoas que realizam o trabalho
Comunicação formal - escrita, reuniões estruturadas e outros canais de comunicação
Comunicação informal - é mais pessoal (membros de uma equipe de SW compartilham ideias numa base ad hoc e solicitam ajuda conforme surgem os problemas
(3) O Produto
Dilema que um gerente de projeto de SW se depara no início do projeto
Definir estimativas quantitativas e um plano organizado, sem informações sólidas disponíveis
As informações necessárias são obtidas por análise detalhada dos requisitos
As análises podem levar semanas ou meses
Os requisitos podem mudar regularmente conforme o projeto prossegue
Mesmo assim, o planejamento é necessário. Então deve-se analisar o produto e o problema no início do projeto
No mínimo, o escopo do produto deve ser estabelecido e delimitado
Escopo de software
Primeira atividade do gerenciamento do projeto
Obtido respondendo as seguintes questões
Objetivo da informação
Quais objetos de dados visíveis ao cliente são produzidos como saída de software? Quais objetos de dados são necessários como entrada?
Função e performance
Que função o software desempenha para transformar dados de entrada em saída? Há alguma característica especial de desempenho a ser abordada?
Contexto
Como o software a ser desenvolvido se ajusta a um sistema maior, a um produto ou contexto de negócio e quais são as restrições impostas resultantes do contexto?
O escopo do projeto não deve ter ambiguidades e deve ser compreensível tanto no nível gerencial quanto no nível técnico
Uma declaração do escopo do software deve ser limitada ()
restrições e/ou limitações são determinadas
Exemplos (custo do produto restringe tamanho de memória)
fatores mitigadores são descritos
algoritmos desejados são bem compreendidos e avaliados em Java
dados quantitativos são estabelecidos
Exemplos: número de usuários simultâneos, ambiente-alvo, tempo máximo de resposta
Decomposição do problema (elaboração do problema ou particionamento)
Atividade que ocupa o centro de análise de requisitos
Aplica-se em duas áreas vitais
(1) Na funcionalidade e no conteúdo (informação) que deve ser entregue
(2) No processo que será utilizado para entregar o software
Estratégia dividir para conquistar
Aplicada quando o problema é complexo
O problema é particionado em pequenas questões mais gerenciáveis
Estratégia a ser aplicada no início do planejamento do projeto
As funções de software, descritas na declaração de escopo, são avaliadas e refinadas para fornecer mais detalhes antes do início da estimativa
Uma vez que estimativas de custo e cronograma são orientadas pela funcionalidade, algum grau de decomposição é geralmente útil.
Conteúdo principal ou objetos de dados são decompostos em suas partes constituintes, fornecendo compreensão razoável da informação a ser gerada pelo software.
Nessa etapa, o gerente de projeto deve estabelecer uma declaração de escopo que limite os recursos que o produto deve ter.
À medida que a declaração do escopo evolui, um primeiro nível de particionamento ocorre naturalmente
Exemplo
Recurso do produto
Funções do recurso
(2) checagem de gramática
(3) checagem de referência para documentos externos
(1) Checagem separação silábica
(4) implementação de recursos de folhas de estilos que imponha consistência ao longo do documento
(5) validação da referência quanto à seção e capítulo para documentos externos.
Edição automática de cópia
(4) Processo
As atividades de modelagem que caracterizam o processo de SW são aplicáveis a todos os projetos de SW
Dificuldade: a equipe deve decidir qual o modelo de processo será mais apropriado
(1) aos clientes que solicitaram
o produto e aos profissionais que realizarão o trabalho;
(2) às próprias características de produto; e ao ambiente de projeto no qual a equipe trabalhará.
Após a seleção do modelo, a equipe define o planejamento preliminar com base no conjunto de atividades estabelecidas no modelo do processo
Em seguida, inicia-se o particionamento (decomposição) do projeto, seguido pela elaboração de um planejamento completo que reflita as tarefas de trabalho necessárias par apreencher as atividades de modelagem
Combinando o produto e o processo
Cada função a ser desenvolvida por engenharia deve passar pela estrutura de atividades definidas pela organização responsável pelo SW
Suponto a estrutura de atividade genéricas
Comunicação
Modelagem
Planejamento
Construção
Empacotamento dos programas executáveis
Atividades genéricas serão aplicadas pela equipe à funcionalidade que estão trabalhando
Pode-se construir uma matriz Funções x Processo
Para cada função são listadas as tarefas de trabalho de engenharia de software
O trabalho do gerente de projeto e outros membros da equipe é
estimar as necessidades de recursos para cada célula da matriz
Estimar datas de início e de fim para as tarefas
Estimar artefatos a ser produzidos como consequência de cada ação.
Decomposição do processo
A equipe de software deve ser flexível na escolha do modelo de processo mais adequado ao projeto e às tarefas do modelo
Abordagem sequencial linear - projeto relativamente pequeno
Abordagem incremental - projeto maior no qual o prazo final é bem apertado a ponto de a funcionalidade completa não poder ser razoavelmente entregue
Características de projetos conduzem para seleção de outros modelos de processo
Por exemplo, requisitos indefinidos, tecnologias avançadas recentes, clientes difíceis, potencial de reúso significante
Após a escolha, as atividades estruturadas (estrutura do processo) são adaptadas ao processo (aplicam-se a qualquer modelo: linear, interativo, incrementais, entre outros)
Apesar da estrutura do processo ser invariável para todo trabalho realizado, as tarefas de trabalho variam.
O processo de decomposição começa quando o gerente de processo pergunta: Como realizar a atividade estruturada?
Para um projeto pequeno e relativamente simples, a lista de tarefas para as atividades de comunicação podem ser requeridas
3 - Desenvolver conjuntamente uma base documentada do escopo
4 - Revisar a base considerando todos os envolvidos
2 - Reunir-se com interessados para esclarecer os itens pendentes
5 - Alterar a base conforme necessário
1 - Desenvolver uma lista de itens para esclarecimentos
Para um projeto mais complexo, com escopo mais amplo e um impacto comercial mais significativo, o projeto pode requerer as seguintes tarefas para comunicação
3 - Realização de uma pesquisa para especificar a solução proposta e as abordagens existentes
4 - Preparação de um documento de trabalho e de uma agenda para a reunião formal
2 - Planejamento e agendamento de reuniões viabilizadas e formais com todos os envolvidos
5 - Realização de reunião
1- Revisão da solicitação do cliente
6 - Desenvolvimento conjuntamente de miniespecificações que reflitam os dados, a funcionalidade e os fatores comportamentais do software. De forma alternativa, desenvolvimento de casos de uso que descrevam o software sob o ponto de vista do usuário
7 - Revisão de cada miniespecificações ou caso de uso para realizar correções, consistências e eliminação de ambiguidades
8 - Reunião de miniespecificações em um documento de escopo (bases)
9 - Revisão do documento de escopo (bases) ou da coletânea de casos de uso com todos os envolvidos.
10 - Alteração do documento de escopo ou de casos de uso conforme o necessário
(5) O Projeto
Para gerenciar um projeto com sucesso, deve-se compreender o que pode sair errado, para que ações planejadas evitem-os
10 sinais de que um projeto de Sistema de Informação está em perigo
As necessidades de negócio mudam (ou são mal definidas).
Os prazos estão fora da realidade.
A tecnologia escolhida muda.
Os usuários mostram-se resistentes.
As alterações são mal gerenciadas/administradas.
O patrocínio é perdido (ou nunca foi propriamente obtido).
O escopo do produto está parcialmente definido.
Faltam profissionais à equipe ou esta não possui pessoal com habilidades adequadas.
O pessoal de software não compreende as necessidades de seus clientes.
Gerentes e desenvolvedores evitam práticas e lições aprimoradas e aprendidas.
Como um gerente deve agir para evitar os problemas mencionados
Rastreie o andamento
O andamento é rastreado quando produtos de trabalho (modelos, código fonte, conjunto de casos de teste) são produzidos e aprovados (usando revisões técnicas) como parte de uma atividade de garantia qualidade
Medições do processo e projeto de SW podem ser coletados e usados para avaliar o progresso contra as médias desenvolvidas para a organização de desenvolvimento de SW.
Tome decisões com astúcia (rapidez).
Em essência a decisão do gerente e da equipe deve ser a de manter a simplicidade
Evitar interfaces customizadas quando houver disponibilidade de abordagens padrão
Ficar atento aos riscos óbvios para evitá-los e decidir por alocar maior prazo do que o necessário para tarefas arriscadas ou complexas
Decidir por utilizar software comercial ou componentes e modelos de software existentes
Mantenha a velocidade (ímpeto).
O coordenador deve fornecer incentivos para que a rotatividade de pessoal seja mínima
A equipe deve dar ênfase à qualidade em todas as tarefas que realiza
O coordenador sênior deve fazer o possível para posicionar-se fora do caminho da equipe
Faça uma análise post-mortem
Definir mecanismos consistentes para extrair lições aprendidas para cada projeto
Avaliar os cronogramas planejados e os realizados, as métricas de projetos coletadas e analisadas
Obter feedback dos membros da equipe e dos clientes e registrar por escrito
Comece com o pé-direito
Trabalhar arduamente possibilita:
Compreender o problema a ser solucionado
E, então, estabelecer expectativas e objetivos realísticos para todos os envolvidos no projeto
Formação da equipe correta, concedendo-lhe autonomia, autoridade e tecnologia necessárias para realizar o trabalho
(6) O Princípio W5HH
Princípio organizacional que facilita a obtenção de planejamentos simples para projetos simples
Abordagem voltada para
Responsabilidades
Gereneciamento
marcos e cronogramas
Abordagens técnicas
Objetivos do projeto
Recursos necessários
Consiste em uma série de perguntas que conduzem a uma definição das características-chave do projeto e do planejamento resultante
Quem será o responsável por uma função?
Os papéis e responsabilidades de cada membro
serão definidos.
Onde se posicionam organizacionalmente?
Nem todas as situações e responsabilidades estão
a cargo dos desenvolvedores de software.
O cliente, os usuários e outros envolvidos também
têm as suas responsabilidades.
Quando será feito?
A equipe definirá o cronograma de projeto, identificando quando serão realizadas as tarefas e quando os pontos de referências (marcos) serão atingidos.
Como será realizado o trabalho tecnicamente e gerencialmente?
Uma vez estabelecido o escopo, deve-se definir uma estratégia técnica e gerencial.
O que será feito?
Define-se o conjunto de tarefas necessárias para o projeto.
Quanto de cada recurso será necessário?
A resposta a essa pergunta irá derivar-se de estimativas
desenvolvidas, baseando-se nas respostas a questões anteriores.
Por que o sistema está sendo desenvolvido?
Todos os interessados devem avaliar a validade
das razões comerciais para o trabalho de software
O propósito justifica os gastos referentes
a pessoal, tempo e dinheiro?
(7) Práticas Vitais
As práticas críticas incluem
Rastreamento de valor agregado
Estimativas empíricas de custo e cronograma
Gerenciamento de projeto baseado em métricas
Rastreamento de defeitos em contrapartida com os objetivos de qualidade
Gerenciamento consciente de pessoal
Práticas vitais para gerenciamento baseado no desempenho
São usadas por projetos de software bem sucedidos e organizações cuja linha de performance inferior é muito melhor do que a média das indústrias
Capítulo 24