Antes de iniciarmos, temos que ter em mente que as práticas genéricas são elementos mandatários do CMMI e seu objetivo central é a institucionalização, mas… o que é institucionalização?

O CMMI define como institucionalização: “A maneira de se fazer negócios que uma organização segue rotineiramente como parte de sua cultura corporativa”. Em outras palavras, o jeito que as coisas são feitas aqui.

Diversos elementos podem atrapalhar a implementação das práticas genéricas como menosprezar a importância da institucionalização, foco apenas nas práticas específicas ou até mesmo sub-estimar o tempo e esforço necessário para sua implementação.

Vamos falar da Generic Goal 2:

• GP 2.1 Estabelecer uma política organizacional
• GP 2.2 Planejar o processo
• GP 2.3 Prover recursos
• GP 2.4 Atribuir responsabilidades
• GP 2.5 Treinar as pessoas
• GP 2.6 Gerenciar configurações
• GP 2.7 Identificar e envolver stakeholders relevantes
• GP 2.8 Monitorar e controlar o processo
• GP 2.9 Analisar aderência objetivamente
• GP 2.10 Revisar o status com a alta direção

Mitos sobre práticas genéricas

GP 2.1 Mito 1: “Tudo que precisamos fazer é escrever algumas políticas e pedir para o CIO assina-las”

• As políticas podem virar um papel que nunca ninguém irá ler
• As políticas devem definir claramente o que deve ser feito
• Se as políticas documentarem o que a alta gerência realmente acredita ser importante, as chances delas serem seguidas aumentam considerávelmente.

GP 2.2 Mito 2 “Um plano para cada área de processo”

• O perigo dos infinitos planos “Aqui esta o plano para coletar as métricas de PPQA”
• O planejamento apropriado deve ser realizado para cada área de processo envolvido
• Garantir tempo, esforço e custo suficiente para executar as tarefas necessárias para realizar cada processo

GP 2.3 Mito 3: “Esta prática e apenas para garantir que teremos pessoas suficientes”

• O risco de focar apenas em pessoas: “Nunca teremos pessoas suficientes”
• Recursos INCLUEM custo, instalações, ferramentas e obviamente pessoas
• “Recursos adequados” quer dizer que o processo pode ser seguido naturalmente sem restrições de custo, prazo ou pessoas

GP 2.4 Mito 4: “As pessoas não precisam da descrição de seu serviço”

• Não assuma que as pessoas compreenderam suas responsabilidades e nível de autoridade
• Defina claramente papéis e responsabilidades que alinhem as pessoas ao serviço realizado
• Faça as pessoas compreenderem seus papel e defina a autoridade necessária para realizar seu trabalho

GP 2.5 Mito 5: “Todo mundo precisa ser treinado em todos os processos”

• Não desperdice esforço em treinamentos desnecessários
• Treine as pessoas … conforme a necessidade
• Estabeleça o entendimento comum sobre a área e necessidades de treinamento
• Define claramente as habilidades e conhecimento necessários para se realizar um trabalho

GP 2.6 Mito 6: “Não há necessidade de baseline de documentos”

• Pode ser vista como burocracia desnecessária: “Se nunca temos basenine de nada, não perdemos tempo com solicitações de mudanças”
• O tipo de controle deve ser apropriado ao tipo de produto
• A integridade dos produtos de trabalho é mantida, assim como a versão atual esta disponível para o público adequado

GP 2.7 Mito 7: “As pessoas que precisam estar envolvidas sabem quem são”

• Definir os stakeholders certos pode ser dificil: “O problema deste projeto é que a pessoa que conhece o negócio não esta disponível”
• Defina os Stakeholders RELEVANTES
• Garanta que as pessoas que precisam ser envolvidas estão engajadas no projeto a fim de previnir atividades paralelas que possam prejudicar o projeto

GP 2.8 Mito 8: “Precisamos coletar métricas para cada área de processo”

• Risco de definir métricas que passam uma falsa impressão do performance do projeto
• O desempenho de um processo deve ser acompanhado contra o planejado
• Os processos precisam ser acompanhados para garantir a entrega no tempo certo e garantir que potenciais desvios foram identificados e endereçados corretamente

GP 2.9 Mito 9: “O gerente garantiu que todo mundo segue o processo”

• A objectividade requer um certo grau de independência
• Garanta uma cobertura razoável da organização (uma amostra com representatividade): “Semana passada tivemos uma auditoria ISO neste projeto, nesta semana será uma auditoria CMMI e na próxima uma de PPQA”
• Isto não deve ser apenas um papel de policiamento do processo; deve fornecer insumos valiosos para a melhoria do processo e torna-lo mais fácil e efetivo

GP 2.10 Mito 10: “A alta administração não esta nem ai para o processo”

• Eles estão, pode ter certeza
• A alta administração deve fornecer uma linha direta para escalonamento de defeitos no processo
• A alta administração deve fornecer uma linha de contato direto
• A alta administração deve estar comprometida com o processo
• A alta administração deve garantir que as políticas estão sendo seguidas

E… porque as práticas genéricas são importantes?
Elas garantem a institucionalização através de elementos como:

• Políticas que devem ser respeitadas e seguidas por todos
• Todas as atividades do processo são planejadas e recursos são disponibilizados para sua execução
• As pessoas compreendem suas responsabilidades e seu nível de autoridade
• As saídas dos processos são controladas
• Os stakeholders são envoldidos
• O processo é monitorado dia-a-dia
• O processo é revisto de forma independente
• A alta direção tem visibilidade do processo

Veja também:

1. Cinco meios para incorporar CMMI em métodos ágeis Há um equívoco em achar que CMMI e métodos ágeis...
2. Dicas de institucionalização do CMMI Olá pessoal, hoje vamos falar de dicas para institucionalização, o...

Constantemente este tipo de discussão aparece quando converso com amigos das mais variadas empresas. Tanto empresas com CMMI e MPS.Br quanto empresas sem. O problema aparece porque RH e gerentes de projetos não entram em um consenso na definição do que é um profissional ruim, bom, e excepcional.

Será que o João, aquele excelente programador é mesmo excelente? E a Maria, dizem que ela é ruinzinha, será que é mesmo. Será que isso não é marketing?

Os questionamentos são variações de:

• “Como eu sei que um profissional é bom?”
• “Como eu avalio se o desempenho de um profissional é bom?”
• “Como eu quantifico a importância de um profissional para a empresa?”
• “Como identificar as falsas percepções?”
• “Como fazer isso, de verdade e atender OT?”

E… em sua grande maioria, as empresas não querem fazer isso apenas para constar em OT, querem ter o benefício real.

Em TI, muitas vezes avalia-se as pessoas puramente pela percepção, e não pelos resultados. Você provavelmente conhece que dizem que é bom, mas até hoje você procura saber no que. Um amigo comentou: “Tem um gerente de serviços lá na empresa que a gerência de departamento acha o cara o máximo, mas tudo serviço que ele entrega é atrasado, e alguns clientes nem podem ouvir o nome dele. Porque acham ele tão bom quando ele não é?”. Infelizmente eu não conheço o caso, apenas a versão do meu amigo, mas, muito provavelmente é “percepção” – há várias possibilidades que vão desde ele ter muita teoria e nenhuma prática até terem falado para o gerente do departamento que ele era bom.

O valor na percepção aumenta quando a empresa não mede os resultados ou não tem critérios para avaliar o desempenho. Contrata-se pelo Curriculum, mas depois de contratado, o que deve importar são os resultados e isso deve ser baseado em critérios.

Existem alguns sinais que alertam uma percepção equivocada como: “Todo mundo fala que o Pedro é um excelente gerente de projetos, mas os 3 últimos projetos dele fracassaram” ou “Todo mundo fala que a Kelly deixa a desejar como analista de sistemas, mas seus últimos projetos 3 projetos tiveram sucesso, e os clientes sempre pedem para ela atende-los”.

Vamos fazer uma análise: Como você define um analista como bom? E um programador .Net… o que é um programador .net bom?

Depois de ter feito isso, qual o desempenho esperado por esse analista? Esse resultado deve estar baseado em critérios, se puder ser quantificado, melhor ainda. E… depois deste trabalho pronto, vamos dizer que este analista bom é um analista Pleno – Qual a diferença esperada no desempenho e habilidades para um Junior e um Senior (ou quaisquer outras classificações).

Em um exemplo com gerentes de projetos podemos utilizar o que o mercado define como um bom gerente de projetos, ou seja, aquele que entrega o projeto no prazo, com qualidade, atendendo ao custo e com o cliente satisfeito. Simples não?

Após estes critérios criados, basta acompanhar periodicamente (documentar) o desempenho de todos e você reduzirá consideravelmente esta percepção. Mas… ainda tem um problema. Esta nova abordagem deve ser comprada pela alta direção e níveis superiores senão, todo trabalho vai por água abaixo e a empresa ainda ficará no mundo das percepções.

“Sucessos anteriores não garantem sucessos futuros, mas é mais fácil alguém que já fez algo bem feito fazer novamente do que alguém que nunca fez” – Francisco Silva

Em OT você deve acompanhar o desempenho das pessoas e o mesmo deve ser aprimorado através de treinamentos, coaching e outros. Se você não tiver o desempenho anterior, como poderá saber que o desempenho melhorou?

Nesta semana colocarei um método ou template (ainda não decidi o que…) que vai ajudar a classificar estes desempenhos e identificar pessoas importantes, estratégicas, attrition e outros.

Veja também:

1. Como melhorar (de verdade) a produtividade em protótipos e mockups? [Promoção] Em quase todo projeto de sistema, usa-se muito tempo em...
2. A importancia da definição de papéis e cargos Atendendo a nossa leitora Walkiria, estarei colocando alguns posts voltados...

Há um equívoco em achar que CMMI e métodos ágeis são opostos. Um depende mais de processos e institucionalização de um método padrão, o outro enfatiza a iteração entre os envolvidos no projeto e “Fazer software e não documentação” (Manifesto Agil). Um processo documentado e institucionalizado é o coração do CMMI e é frequentemente utilizado como modelo para definição de metodologias de desenvolvimento para projetos críticos. Por outro lado, a abordagem Agil é colocada em ação quando um projeto apresenta mudanças incrementais, em particular aquelas que não foram incluídas na definição de escopo inicial.

Há criticas a ambos, bem como: “CMMI é usado apenas em grandes projetos ou projetos de críticos que necessitam uma equipe muito grande e um ciclo de vida rígido”. Do outro lado: “Aqueles que implementam métodos Ágeis tem sido classificados como o indisciplinados ou “hackers” de projetos de software”.

O Software Engineering Institute (SEI) acredita que os críticos não estão exatamente certos. O sucesso ou fracasso da aplicação das metodologias Agile nada tem a ver com documentação, e segundo Margaret Kulpa e Johnson Kent: “Você poderia escrever uma tonelada de documentação sobre seus processos sem necessariamente praticar o que está no papel.

Então, onde é que os gerentes de projeto encontram “terreno comum”? Segundo os autores: “A institucionalização”, que o CMMI define como “A maneira de fazer negócios que uma organização segue rotineiramente como parte de sua cultura”. Simplificando, uma empresa de TI pode ter um alto grau de colaboração como parte de seu DNA , implementar a cultura Agile e estar aderente aos princípios definidos pelo CMMI ao mesmo tempo.

Há diversas formas de se institucionalizar métodos Agile com CMMI através da adoção de práticas genéricas associadas aos níveis de maturidade 2 e 3. Aqui estão algumas das mais importantes, senão as mais fáceis em um programa de implementação

1. Estabeleça uma política organizacional para planejar e executar Métodos Agile
   O primeiro passos é comunicar a todos o porque e como os métodos Agile serão utilizados na organização. É bom fazer a comunicação como é feita em projetos Agile. Por outro lado, os planos para a utilização de abordagens ágeis devem ser formalizados (documentados) para se certificar de que todos os processos são definidos e seguidos. Para ser eficaz, a política deve ter informações básicas que todos devam saber para se trabalhar em um projeto Agile.
2. Estabeleça responsabilidade e autoridade para executar métodos Agile
   A fim de se certificar de que o plano está sendo implementado e as políticas estão sendo seguidas, as pessoas deve ter autoridade e perfis correspondentes, como, por exemplo, o Product Owner ou o Scrum Master. Deve-se verificar a aplicação de métodos ágeis, enquanto, ao mesmo tempo, verificar se esta aderente ao CMMI. Isto quer dizer, monitorar se os processos estão sendo executados de acordo com o plano. Obviamente, qualquer desvio do plano deve ser corrigido.
3. Identifique e envolva os stakeholders relevantes
   Uma boa coisa nos métodos Agile, é que o cliente é envolvido no projeto constantemente e o mesmo fornece feedback de cada incremento ou entrega. No entanto, o feedback dos clientes não é a única opinião que deve ser considerada; O feedback de outras partes interessadas, tais como a alta direção, membros da equipe, ou outros envolvidos no projeto.
4. Revise o status do programa de implementação com a alta direção
   A implementação de um programa Agile em uma organização ou projeto requer apoio e suporte da gestão em geral, e isto é possível se eles souberem como funciona ou terem uma idéia clara das questões envolvidas nos métodos Agile.
   Os autores recomendam fornecer dados relacionados ao status com os “Scrum Burndown Charts” que ajudarão fornecer estratégias de gestão e recursos, e resolver quaisquer questões ou impedimentos relatados por equipes Scrum.
5. Treine as pessoas na execução de métodos Ágeis
   A aceitação de uma implementação Ágil em uma organização é mais fácil se:
   - For definida pela alta administração
   - Ter comunicação clara e objetiva
   - Se conhecida e apoiada por todos envolvidos
   Há uma série de Métodos Ágeis por ai, e na adoção de qualquer um dos métodos deve-se considerar auto-estuto, workshops, treinamentos por especialistas ou até mesmo treinamentos externos.

Enfim, CMMI (ou MPS.Br) e Agile convivem muito bem juntos e ajudam bem até o CMMI nível 3.

Veja também:

1. PMBOK X Agile Software Development Já ouvi muita gente colocar o Agile Software Development como...
2. Aderência do CMMI com métodos ágeis (SCRUM, XP e FDD) O Scrum é compatível com o CMMI? Sim e não....

O que é mais importante para um gerente de projetos? Certificação, Pós Graduação ou formação?

Constantemente tenho me deparado com esse questionamento, e por isso resolvi escrever este post para dar uma resposta definitiva, direta e que não deixe dúvidas, enfim, sem enrrolação.

E a resposta é: Depende.

Existem no mercado muitos cursos (e isso não é prerrogativa do Gerenciamento de Projetos) “baratinhos”, que prometem o impossível e que tentam forçar o “candidato a  aluno”  a uma decisão tendenciosa que resulte na compra do curso oferecido. A maioria deles vem com um carimbo como “alguma coisa PMI” ou “alguma coisa PMP”.

Não gosto dessa posição por achar que ela caminha pelo limite da ética, um argumento mais forte e ela cai para o lado errado…

Por isso eu respondo Depende, e procuro ajudar quem faz a pergunta a encontrar sua própria resposta, porque o que serve para um, pode não servir para outro e assim por diante, então, vamos analisar esses três caminho:

Certificação

As certificações, e a Certificação PMP oferecida pelo  PMI não é exceção, não tem por objetivo ensinar algo, mas avaliar se o candidato já tem conhecimento suficiente para assumir a função de gerente de projetos, é um “carimbo de atestado de competência”, ou… vamos falar diferente, atesta que o canditato se deu bem na prova.

Estes certificados são reconhecidos pelo mercado, e apesar de não concordar com essa fábrica de certificados isso, é uma realidade de mercado e faz diferença na carreira profissional, porém, os cursos de certificação PMI ou qualquer outra, não tem por objetivo ensinar nada ao candidato. O Objetivo é preparar o candidato (que já CONHECE o assunto) a passar na prova e tirar sua certificação.

Portanto não é indicado para quem quer iniciar a carreira. O Público alvo é quem tem MUITO conhecimento e quer apenas comprovar isso, com um certificado reconhecido internacionalmente.  Mesmo porque, pelas regras do PMI (que muitos tentam burlar com informações falsas) é preciso ter 4.500 horas de experiência para se candidatar a prova.

Pós Graduação ou MBA em gestão de projetos

Embora muitos cursos “vendam diplomas”, os cursos de Pós Graduação sérios (em todas as áreas)  se preocupam com a transmissão de conhecimento, todavia a estrutura ideal de um curso de pós exige um bom conhecimento prévio e se possível alguma experiência, pois é dessa troca de experiência que nasce o conhecimento – e sinceramente é o que diferencia um curso bom de um ruim.

Portanto, estes cursos não são (também) os mais indicados para iniciantes. Apesar de muitos procurarem o curso pelo certificado, o conhecimento, que deveria ser o principal motivador de um curso desse, só é realmente aproveitado por quem tem alguma experiência na área de abrangência.

Formação

Os cursos de formação, sejam eles de graduação ou cursos livres, são os cursos apropriados para quem deseja iniciar em uma nova área, pois normalmente partem de um ponto mais básico e são modulares, permitindo que o conhecimento seja absorvido de forma gradual, no ritmo adequado para cada aluno. Infelizmente no caso de Gerenciamento de projetos, curso de formação são raros (alguém conhece algum?), principalmente na área de TI. (veja mais em Gerente de Projetos de TI – Uma carreira acidental?)

Esse é o caminho recomendado para iniciantes e que, ainda por cima, é o de custo mais baixo.

Por esses motivos a reposta de qual o Melhor curso é DEPENDE:

1. Se você já é um Gerente de Projetos experiente (experiente = mais de 5 anos como GP), busque a certificação
2. Se você tem uma boa base, e alguma experiência, busque uma Pós Graduação
3. Se você quer INICIAR na carreira, procure um curso de formação

Em tempo: Não conheço nenhuma universidade com um curso de graduação em gerenciamento de projetos, mas… quem sabe não seria uma boa idéia para as universidades. O mesmo vale para cursos voltados a MPS.Br e CMMI.

Adaptado de Projetizando.com.br

Veja também:

1. 49 provérbios do gerenciamento de projetos Você não consegue fazer um bebê em um mês usando...

Prólogo

O objetivo deste mini-tutorial é mostrar como se inicia um projeto.
Para facilitar o entendimento (e disseminar conhecimento) ele é focado na simplicidade, facilitando assim o entendimento.

A estimativa de tamanho em APF toma por base que todos os elementos são de complexidade média, todavia é importante vocês terem em mente que isto é apenas o início. Em se interessando procurem ler mais sobre estimativa, planejamento, desenvolvimento de requisitos e controle de mudanças – aos que estão iniciando com MPS.BR ou CMMI, este tutorial vai ajudar bastante nos primeiros níveis.

Tutorial Mini Projeto – O nascimento da idéia

Um amigo te liga e pede para você fazer uma visita pois ele precisa de um projeto, ele te fala que é bem simples e precisa apenas de um aplicativo para gerenciar seus contatos.

Chegando em seu escritório, a conversa começa e ele fala que tem mais de 1.000 contatos em uma agenda (papel mesmo) e que quer (e precisa) automatizar isso. Na sua cabeça você já percebe que terá uma tela (até agora).

Conversa vai, conversa vem, ele comenta que um grande problema que ele tem é que ele não consegue dizer de onde são os contatos. Ele comenta que se ele pudesse agrupar-los, isso o ajudaria muito.

Ele também comenta que gostaria que tudo ficasse em uma única tela, ele não gosta de ficar passeando de uma tela pra outra.

Neste ponto você já esta pensando “é fácil”, mas… como estimar isso?
Então você vai e joga a famosa pergunta: “Em que linguagem você quer?”
Seu amigo responde: Linguagem? Tanto faz (isso será muito importante na sequência).
Você então senta com ele e monta o seguinte esboço de como será a tela (imagem 2)

Ele comenta que é isso mesmo, e vocês começam a detalhar o que terá na tela como campos, funcionalidades, etc. Seu amigo comenta que quer que tenha foto, que o nome apareça grande, que possa digitar email, telefone enfim… ele te passa tudo que ele gostaria.

Você anota tudo e começa a pensar em como seria a tela. Este projeto é bem simples, mas em projetos grandes é primordial que você anote tudo, gere uma ata e busque uma aprovação formal de seu o cliente. Você novamente faz um esboço (no papél mesmo) e apresenta para ele como seria o sistema conforme a imagem 3).

Repare que o que fizemos aqui não é nada demais e qualquer um pode fazer. É uma coisa simples, mas ajuda muito pois “tela” é uma coisa que todo mundo entende. Fazendo estes “drafts” você exercita junto ao seu cliente a idéia e ele já vai validando a linha de raciocínio e entendimento do negócio.

Se amigo analisa e te fala: “Perfeito! É isso mesmo que eu quero. Quanto fica?”
Vejamos… você já sabe o que o sistema deve fazer, já tem o escopo definido, então, vamos à estimativa.
Apenas para efeito de curiosidade, depois do protótipo, o sistema ficará como esta imagem.

Não perca a próxima parte – Tutorial Mini Projeto – Estimativa.

Veja também:

1. Analisando o custo x benefício em um projeto Uma das principais responsabilidades de um gerente de projetos é...

A descrição de papéis e responsabilidades (também conhecida como descrição de cargos e responsabilidades) é uma coisa básica na industria, porém em TI ela ainda esta engatinhando.

Vamos fazer um teste, procure em sua empresa se há uma documentação definindo claramente o que você (ou alguém com o mesmo cargo) deve fazer. Bom… provavelmente em mais de 90% dos casos não haverá nada ou uma definição informal do que é.

O mesmo vale para os níveis de senioridade.

Mas, porque é tão importante ter essa descrição? Simples: organização, produtividade e escala.

Tendo os crítérios, você reduz riscos de:
Contratar um junior achando que é senior
Enviar demanda a um profissional que não esta apto a executa-la
Ter diferentes faixas salariais para o mesmo perfil
Não cumprimento de prazos
E outras

Vale lembrar que esta definição deve ser apoiada pela política organizacional e deve ter a aprovação e comprometimento da alta direção.

Agora, vamos a um exemplo simples de como deve ser uma “descrição de cargos e responsabilidades”:

Cargo: Programador Junior Java
Formação: Técnica, superior ou curso que ateste os conhecimentos

Conhecimentos:
1. UML
2. Java
3. …

Habilidades:
1. Conversação em inglês
2. Digitação rápida
3. …

Responsabilidades:
1. Entregar os produtos com a qualidade definida
2. Apontar diáriamente as horas trabalhadas nas tarefas específicas
3. …

A quem se reporta: Gerente de desenvolvimento

É muito importante você definir critérios para os elementos evitando que alguém que saiba apenas a frase “the book is on the table” seja classificado com “Conversação em Inglês – OK”

Lembrando, este é um exemplo básico, da pra evoluir bem com elementos como: “Elementos Obrigatórios e Opcionais”, “Faixa Salarial”, “Atuação secundária”,”autoridade”, etc, etc, etc

Os que estão envolvidos com OT ou GRH devem montar esta definição para cada cargo (papel ou função) de sua organização e segui-la.

Abraço a todos.

Veja também:

1. A importancia da definição de papéis e cargos Atendendo a nossa leitora Walkiria, estarei colocando alguns posts voltados...
2. Descrição rápida das PA’s do CMMI nível 3 PI – Integração de produto Tem como objetivo integrar os...

Atendendo a nossa leitora Walkiria, estarei colocando alguns posts voltados a OT (e GRH – mais pra frente explico).

Hoje vamos falar da importância de ter papéis e funções definidas.
Primeiramente, isto é pré requisito tanto para o CMMI quanto para o MPS.BR, mas você deve estar se perguntando “o que minha empresa ganha com isso?”. Bom, ganha produtividade e agilidade.

Muitas empresas (normalmente as pequenas) não tem isso muito bem definido, então é como se todo mundo pudesse fazer tudo (e fazem). Nestes casos ninguém acaba se especializando em nada e com isso perde-se a oportunidade de aumentar a produtividade e ganhar agilidade. Um analista que passa 70% do tempo programando, com certeza não se especializará em levantamento de requisitos, relacionamento, desenvolvimento de requisitos e outras disciplinas voltadas a análise, pelo contrário ele se poderá ser excelente em “java” ou “.net”, então você pergunta “mas… ele não é um analista???”
Ele até pode programar, mas se ele é analista, seu principal foco é análise e é ai que ele deve se especializar.
O mesmo vale para as vagas (muito comum) de Gerente de Projetos onde na descrição consta até J2EE. Bom… se a vaga é pra gerente as habilidades que ele deve ter são várias mas J2EE com certeza não é uma delas, e é comum encontrar J2EE e não encontrar “Gerência de Riscos”

Uma dica que dou é:

• Mapear os cargos (ou papéis);
• Definir as responsabilidades de cada um;
• Definir as habilidades necessárias;
• Definir critérios para classificar alguém como A ou B
• E o mais importante… manter tudo isso funcionando

Especialização gera agilidade, que gera aumento da produtividade e que acaba reduzindo os custos.

No related posts.