NORMAS DA ABNT DEVEM SER PÚBLICAS PARA TODA A SOCIEDADE

A NBR 15575 – Edificações Habitacionais – Desempenho, publicada pela Associação Brasileira de Normas Técnicas – ABNT, estabelece parâmetros técnicos para vários requisitos importantes de uma edificação, como desempenho acústico, desempenho térmico, durabilidade, garantia e vida útil, e determina um nível mínimo obrigatório para cada um deles. O maior absurdo é que estas normas são comercializadas pela ABNT, ou seja a sociedade paga os impostos, taxas, sindicatos, federações e ainda para construir tem que pagar por uma norma que deveria estar publicada na internet para conhecimento de todos, assim como as leis, decretos, planos diretores, mapas e outros instrumentos de interesse público.

Arq. Manoel Marques

Norma de Desempenho ABNT 15575

Os desafios da Norma de Desempenho ABNT 15575



A Associação Brasileira de Normas Técnicas (ABNT) publicou, no final de fevereiro, a norma NBR 15.575 - Edificações Habitacionais - desempenho, com o objetivo de fornecer aos usuários garantia de qualidade das edificações residenciais a partir da definição de requisitos mínimos que devem ser atendidos pela unidade habitacional e suas áreas comuns.


Seu atendimento será obrigatório para edificações novas em 150 dias a partir da data de sua publicação .A norma é voltada a estipular parâmetros de desempenho que devem ser considerados em todo o processo da obra - seu atendimento deverá gerar alterações no modo de atuação de todo o segmento da construção civil.
A especificação de materiais e sistemas será baseada no desempenho requerido durante a vida útil da construção e visa a proteger o usuário final, dentro do tempo de utilização mínimo definido pelas normas vigentes, ou de maneira mais particular, pelo usuário ou projetista.
Os compradores dos imóveis deverão se certificar de que os produtos especificados nos memoriais descritivos de venda correspondem aos requisitos mínimos de desempenho, uma vez que estes manuais deverão trazer estes critérios. Os construtores, por sua vez, deverão fornecer o Manual de Uso e Manutenção correto das edificações.
O foco da norma está nas exigências dos usuários para seus sistemas, como seu comportamento em uso e não na prescrição de como ou quais sistemas ou materiais são utilizados. A forma de estabelecimento do desempenho é considerada por definição de requisitos qualitativos, critérios quantitativos ou premissas, e métodos de avaliação, os quais sempre permitem a mensuração clara do seu atendimento.
O desempenho do edifício pode ser classificado como: mínimo, intermediário e superior, e deve ser definido já na fase de projeto.
A abordagem explora conceitos que muitas vezes não são considerados em normas específicas definindo, por exemplo, durabilidade dos sistemas, capacidade de manutenção do edifício e conforto tátil e antropodinâmico de usuários.
A norma dividida em seis partes, que tratam respectivamente de requisitos gerais, estrutura, pisos, vedações verticais, cobertura e sistemas hidráulicos. Também permeiam a norma definições voltadas ao conforto térmico e acústico, proteção ao fogo, estanqueidade e ciclo
de vida da edificação.
Pela grande abrangência da 15.575, toda a cadeia construtiva terá de se adequar para atendê-la. Exigirá conhecimento maior dos arquitetos, engenheiros de cálculo, paisagistas, arquitetos de interiores, engenheiros de instalações das características requeridas durante o processo de especificação, que deve ser auxiliado pelas normas técnicas e pelas informações específicas passadas pelos fornecedores.
A Norma abrange todo o ciclo de vida da edificação - da concepção até o usuário final. Como exemplo, em obras públicas a norma permitirá a substituição do fornecedor do material por outro de acordo com o valor de venda pela construtora quando necessário, sem que se perca o desempenho inicial previsto pelo especificador, pois todas as características e as normas que devem ser atendidas estão claramente discriminadas no memorial descritivo do projeto.
Esta adequação pode ser explorada como um fator diferencial das empresas perante as concorrentes, sendo preferenciais em processo de seleção aquelas que comprovarem seu atendimento às normas.
A adoção da norma permitirá que todos os envolvidos na cadeia produtiva da construção civil trabalhem com a mesma base de informações, diminuindo significativamente erros e desvios ligados a falhas nas especificações dos materiais e sistemas.
Os arquitetos sabem o que devem coletar de informações, os fornecedores por sua vez sabem quais informações devem prover, e as construtoras já sabem quais informações terão disponíveis para trabalhar. E os usuários ganharão com a garantia de imóveis de maior qualidade e durabilidade.
As empresas do setor estão em processo de adaptação a esta nova legislação. Algumas em estágio mais avançado que outras, uma vez que esta adequação pode demandar custos de atualização e testes comprobatórios, de acordo com o produto fornecido.


Miriam Addor e Barbara Kelch, para o Estado de S. Paulo

Gerenciamento de Projetos

Os 7 passos do gerenciamento de projetos

Fernando C. Barbi

O enxugamento dos quadros de pessoal e o aumento da necessidade de especialização técnica têm levado muitas empresas a recrutar no mercado profissionais por período determinado apenas para a execução de projetos específicos. Neste contexto, entender o processo de gerenciamento de projeto tem se tornado vital para organizações a medida em que mais e mais novos negócios vão se revestindo da aura de projeto e passam a exigir um cabedal de técnicas gerenciais que nem sempre estão disponíveis nas empresas.

Um projeto é um empreendimento temporário, com data de início e fim, cujo objetivo é criar ou aperfeiçoar um produto ou serviço. Gerenciar um projeto é atuar de forma a atingir os objetivos propostos dentro de parâmetros de qualidade determinados, obedecendo a um planejamento prévio de prazos (cronograma) e custos (orçamento). Ou seja, dadas as metas e as restrições de recursos e tempo, cabe ao gerente de projetos garantir que ele atinja os objetivos propostos.

Muitas empresas estão adotando a estrutura de projetos no seu dia-a-dia. Desde a concepção de um novo software até a implantação dos procedimentos de atendimento a clientes, desde a construção de uma ponte até a revisão dos processos de venda com vistas a aumentar a taxa de fechamento de negócios, muitos empreendimentos no seio das organizações se enquadram na classe de projetos. Nos mais diversos setores, a abordagem de gerenciamento de projetos está ganhando terreno por permitir um melhor uso dos recursos para se atingir objetivos bem definidos pela organização. Sabendo da importância de se gerenciar bem um projeto, vamos ver os passos que nos levam a melhorar nossas habilidades de gerenciamento de projeto.

Tudo começa com a contratação de uma empresa para tocar o projeto ou a definição dos colaboradores internos que integrarão a equipe de projeto. Num dia determinado, inicia-se o projeto. Este momento deve ser formalizado com um documento que se chama de “termo de início do projeto”. Em projetos maiores, deve ser um documento assinado pelos patrocinadores e pelo gerente do projeto. Para projetos menores, pode ser um e-mail que o gerente envia aos patrocinadores, copiando os demais envolvidos, para notificar que naquele momento se inicia o projeto e todos estão envolvidos com a sua execução.

1. Escolha e adote uma metodologia

Uma metodologia é um processo a seguir que dá maior controle sobre os recursos que serão utilizados no projeto. Controlando melhor o processo a equipe será mais eficiente pois entregará o projeto com maior grau de acerto em termos de prazos e custos. O bom uso de uma metodologia é importante porque permite evitar práticas que levam ao insucesso e com isso reproduzir o sucesso.

A Microsoft usa o MSF (Microsoft Solutions Framework) no desenvolvimento de seus produtos. Muitas empresas na área de software optam pelo CMM (Capability Maturity Model). A opção pela metodologia deve ser tomada a partir de alguns fatores: as exigências de cada mercado em que a empresa atua, a disponibilidade de mão-de-obra e a cultura organizacional necessária para adotá-la. Para exportar software, muitas empresas nacionais têm se alinhado com o padrão CMM para dar credibilidade a sua iniciativa em mercados dominados por indianos e chineses, que já possuem capacitação neste padrão.

Em última instância, uma metodologia é um conjunto de regras de como conduzir um projeto com sucesso. Pode até não ter siglas bonitas, mas é importante que já tenha se mostrado eficiente dentro da sua empresa, de preferência em situação similar à que você está vivendo no seu projeto atual. Para quem gosta de siglas, há uma que está bem na moda: a UML (Unified Modeling Language) que, como já diz o nome, não é uma metodologia mas uma linguagem, uma forma de se documentar um projeto. Uma linguagem de modelagem é uma notação, em geral feita com símbolos gráficos, que se usa para traduzir processos abstratos. A empresa que criou a UML desenvolveu uma metodologia conhecida como RUP, “Rational Unified Process”.

2. Comunique-se: não é só o peixe que morre pela boca!

Quando falta comunicação, os boatos e outras formas de ruídos tomam seu lugar. Na falta de versão oficial, ficam circulando informações que podem minar a moral da equipe e levantar suspeitas sem fundamento. O gerente de projeto deve evitar esse tipo de prática, conhecida por "rádio-peão", dando informações claras e confiáveis sobre o status do projeto. Certamente esta é uma área em que a diplomacia é essencial. Se há um problema, o gerente de projetos pode e deve não só falar sobre ele, mas também informar que está trabalhando na solução, e não apenas comunicar que o problema existe. Problemas sem uma perspectiva de solução são angustiantes e causam um desconforto na equipe que muitas vezes é desnecessário.

A criação de relatórios de progresso do projeto ajuda no processo de comunicação, sobretudo por que torna o processo impessoal e mais objetivo. Imagine o efeito de um email onde se critica um membro da equipe pelo atraso do projeto. Imagine a mesma informação vinda de um relatório em que a data de término real de uma tarefa está em branco: objetivamente a situação é a mesma, o indivíduo não fez a sua parte, mas no caso do email a pessoa envolvida pode se melindrar. No relatório, temos um dado objetivo, que salta aos olhos, mas que não gera ressentimentos.

3. Defina o escopo do projeto e detalhe as atividades

O “escopo do projeto” é o trabalho que deve ser realizado para se obter um produto ou serviço com determinadas características e recursos. Comece por definir o que deve ser feito e o que não deve. Esse processo nos permite entender os contornos do projeto e traçar uma linha divisória entre o que deve ser feito e o que não deve ser, pelo menos neste momento. Muitos novatos se perdem em discussões intermináveis sobre recursos do produto final que o tornariam “perfeito”. Sempre me lembro de um amigo muito experiente que, ante a minha ânsia em acertar todos os detalhes logo de cara, me dizia que “o ótimo é inimigo do bom”, ou seja: enquanto perseguimos o “ótimo” nos distanciamos de algo que está bem mais próximo, o “bom”, é que temos mais chance de conseguir atingir. Com o tempo achei uma forma elegante de contornar as exigências de projeto sem decepcionar os clientes: não é que não faremos o que está sendo pedido, mas devemos ver que este recurso cabe na versão 2, 3, etc... mas não cabe na versão 1, que é o que estamos tentando desenvolver neste momento ! Afaste o fantasma da perfeição.

Para você não se perder numa lista interminável de características da versão 1, uma boa idéia é pedir ao cliente que liste só que o que é “absolutamente essencial”. Claro que se você der a ele 30 minutos para responder, tudo será “absolutamente essencial”. Não adianta, temos de ser realistas, o tempo é curto é temos de escolher só o que realmente é importante. Se “escrever é cortar” como dizem os grandes escritores, a arte de se definir o escopo do projeto passa por saber o que abandonar e o que reter do universo de necessidades do cliente.

Bom, definido o escopo do projeto, podemos passar para a fase de detalhamento das tarefas. O objetivo é chegar ao WBS (Work Breakdown Structure), onde temos as “unidades de trabalho” com tempo medido em dias ou horas de trabalho. Como regra, uma atividade deve ocupar entre 4 e 80 horas, nem mais, nem menos.

Em paralelo, deve ser elaborado um orçamento levando em conta quantas horas de cada profissional serão necessárias. Veja um modelo simples:

Profissional	Tarefa 1	Tarefa 2	Tarefa 3	T.Total (h)	Custo/h	Custo
Gerente de projeto	20	0	3	23	150,00	3.450,00
Líder de projeto	10	3	2	15	80,00	1.200,00
Analista Sênior	20	0	0	20	50,00	1.000,00
Programador	0	40	20	60	30,00	1.800,00
Testador/Documentador	0	20	30	50	15,00	750,00
Total	-	-	-	168	-	8.200,00

Para montar este modelo, você precisa saber o custo-hora de cada profissional e estimar o tempo que cada um gastará no projeto. Os profissionais podem estar envolvidos em outros projetos e quando o programador está cuidando de uma fase do projeto A, o gerente de projeto já pode estar planejando o projeto B, só voltando ao projeto A quando for para entregar ao cliente e obter a sua aprovação, sobre o que falaremos mais adiante.

Estas estimativas são mais precisas à medida em que se avança no detalhamento do projeto. Para estimativas iniciais, admite-se uma variação de -25% a +75%. Na fase de planejamento, o orçamento deve ter uma variação de -10% a +25%. Lembre-se que nesta fase, o gerente de projeto já envolveu quem realizará a tarefa. Na estimativa final, a margem de erro é menor: de -5% a +10%. Aqui, o conhecimento do gerente de projeto de situações anteriores fará diferença. Eu, por exemplo, sei que quando lido com determinados clientes, haverá tanto “overhead” administrativo, como dezenas de reports para cima e para baixo antes que cada passo importante seja dado, que eu já estimo 50% a mais do tempo nas tarefas em que o cliente está diretamente envolvido. Vai da experiência do gerente, mas nessa hora, se a empresa têm um histórico de projetos semelhantes, vale a pena se basear neste background, mesmo que tenha sido com outras equipes e outros gerentes de projeto.

Um dos grandes segredos do gerenciamento de projetos é proteger o seu escopo. Projetos que ficam mudando o escopo durante sua execução têm sérias dificuldades em cumprir o cronograma e estouram o orçamento. O risco mais comum é o que se chama de “scope creep”, quando o escopo vai crescendo a medida que o cliente vai entendendo suas necessidades e reformulando seus objetivos. Há quem chame este problema de “Jacques”. Seria uma homenagem a um francês ilustre ? Não, trata-se apenas da forma como o cliente costuma abordar o assunto: “já que o sistema faz isso, ele pode então fazer aquilo. Agora eu quero aquilo também incorporado ao projeto.” O gerente do projeto deve ter calma e analisar com cuidado cada demanda: ao rejeitar um pedido, ele pode se indispor com o cliente, mas se aceitar ele pode estar dando um tiro no próprio pé, já que o prazo e orçamento não serão tão “elásticos” quanto as exigências. Devemos sempre contar com uma certa “margem de manobra”, mas nos tempos atuais, em que eficiência é a palavra que está na ordem do dia, não há muita “gordura para queimar” e os compromissos assumidos pelo gerente podem se transformar num sacrifício, muitas vezes desnecessário, para toda a equipe.

Em projetos de software, o “scope creep” é uma situação tão comum que não dá para começá-los sem tomar algumas precauções. O primeiro cuidado é negociar a forma de remuneração: fixa ou variável. Se for fixa, o risco das mudanças está toda com o gerente do projeto, se for variável, o cliente assume os custos extras. Mesmo neste caso, o gerente do projeto deve cuidar para que o cliente seja informado a priori dos novos custos. Por precaução, eu sempre redijo um adendo ao escopo colocando o que será feito, em quanto tempo e a que custo. Colho a assinatura do cliente e só depois autorizo a execução da tarefa. Gerentes financeiros não participam destas reuniões e podem alegar que não há previsão de recursos para os extras, então mantenha-os informados das novas condições para evitar dissabores na hora do recebimento.

O segundo cuidado é documentar meticulosamente o escopo do projeto. Este documento resume o que será feito, com que características e com que recursos. Ele é um “quase-contrato” mas não traz as cláusulas de rescisão e as penalidades. Neste momento, tudo está bem e todos concordam. Só que, na cabeça de cada um, há uma imagem diferente do que será o produto final. Á medida que este produto vai tomando forma e sendo entregue, o cliente vai vendo que o que ele imaginou “não é bem aquilo” e podem começar as decepções.

A satisfação do cliente depende em muito do que será dito e prometido no que se chama de “pré-venda”. É neste momento que o gerente de projetos deve entrar em cena para meticulosa, cuidadosa e disciplinadamente escrever tudo o que o sistema deve ter e fazer. Este processo é o “planejamento de escopo” e num software dele abrange das telas até os relatórios. Esta tarefa pode ser delegada para um analista, mas a responsabilidade não sai nunca das mãos do gerente. Eu costumo especificar toda a interface dos usuários com o sistema: telas e relatórios. Depois de “colocar tudo no papel”, o gerente deve obter do cliente um “de acordo”, de preferência assinado no final do documento em que todas as páginas serão rubricadas com um “visto” para que ele tome ciência do que será feito. Não há palavras para expressar a importância deste planejamento em que as expectativas serão levantadas e moldadas, de forma que, diante do produto final, o cliente não possa se dizer decepcionado.

O terceiro cuidado é definir prioridades. O gerente deve ter a sensibilidade para identificar quais são os requisitos obrigatórios e quais os desejáveis, marcando cada um segundo com a sua prioridade. Isso evita que alguém arbitre o que é importante no lugar do cliente. Há gerentes de projeto que vão mais longe e pedem ao cliente para definir o que ele considera “sucesso” do projeto. Por exemplo, num sistema em que havia desperdício de 30% da matéria-prima, foi considerado sucesso reduzir esta taxa para 15%. Mas este número ainda é alto, diria você. Sim, mas o cliente considerou que uma redução de 50% dos desperdícios já representaria benefícios suficientes que compensariam os investimentos no projeto. Além do mais, lembre-se de que: “o ótimo é inimigo do bom”.

Em suma: definir o escopo, no fundo, é saber o que deve ser feito para atender a necessidade do cliente.

4. Conheça os envolvidos e monte seu time

Todos os envolvidos no projeto são os "stakeholders". Nesse grupo estão não apenas os membros da equipe, mas também os clientes e fornecedores envolvidos. Dentro da empresa do cliente, há uma pessoa que se destaca por ser a patrocinadora ("sponsor") do projeto. Ela é que cria as condições para a contratação do projeto, mesmo que não seja ela que vá usar o produto final.

É importante que o gerente do projeto conheça os interesses de todos os envolvidos. Imagine como é arriscado contar com um membro da equipe que não está disposto a colaborar. Ele pode ser um problema mais do que uma solução dentro do grupo: sabendo disso, melhor pensar em chamar outra pessoa. Eu passei por uma situação destas quando fui destacado para gerenciar um projeto onde havia um colaborador mais antigo e que entendia que ele é quem deveria estar gerenciando. Eu não percebi seu ressentimento a princípio e à medida que o projeto avançava esta pessoa se tornava um problema cada vez maior, na medida em que, não só ele não fazia a sua parte, como minava os demais membros da equipe contra minhas decisões. Um dia, eu o chamei e abri o jogo. Ele então me explicou o que estava sentindo e fizemos um acordo: ele se enquadraria para completar o projeto, que graças a ele já estava atrasado, e eu o apoiaria junto à direção para que recebesse seu próprio projeto para gerenciar. É claro que manter um “profissional” com este tipo de atitude não é bom negócio para a empresa no longo prazo, porque cedo ou tarde ele vai acabar atirando contra a própria equipe novamente, só para mostrar que as “coisas têm de ser feitas do jeito dele”.

No processo de definição do escopo, as habilidades necessárias vão ficando mais claras. Nesse momento, é importante formar uma equipe com competência diversificada e com experiência nas áreas de atuação do projeto. Em projetos em que há muito conhecimento técnico envolvido, surge a figura do "líder de projeto", um profissional com grande conhecimento técnico e com capacidade de liderança entre os técnicos. Em geral é um profissional sênior, com credibilidade junto aos demais técnicos e com muita bagagem. A experiência desse especialista pode economizar muito tempo e dinheiro no projeto. Dê-lhe voz ativa, cobre dele insights que você não tem e respeite a sua opinião. Só assim ele estará sempre do seu lado, mesmo quando você errar.

5. Desenvolva o cronograma junto com quem põe a mão na massa

Uma vez que temos as tarefas definidas a partir do escopo, temos de estimar a duração de cada uma. Procure fazer esta estimativa de tempo de execução com a ajuda de quem está escalado para executar o trabalho. Ao mesmo tempo em que essa pessoa é quem melhor sabe quanto tempo precisará, ela estará se comprometendo com um prazo para a sua execução. Por outro lado, quando se trabalha com consultores externos, o custo será função direta do tempo estimado para a execução do projeto. Ao fixar o cronograma, o profissional está dando por tabela um orçamento da sua parte.

Veja estas atividades que representam as linhas gerais de um projeto de sistema:

Note que além de saber o que deve ser feito, as tarefas têm três propriedades importantes: duração, inter-dependência e responsável. A duração é importante mas se as tarefas podem ser realizadas em paralelo, como é ilustrado neste caso onde há duas figuras: o analista e o programador, a duração total do projeto encurta. Dessa possibilidade de trade-off entre tempo e recursos alocados, alguns gerentes acreditam que se o projeto está atrasado, então “basta colocar mais gente” que o problema se resolve. Isso raramente ajuda uma vez que com mais gente, os problemas de comunicação aumentam e o projeto que já está atrasado atrasa mais ainda. Trazer mais gente pode ser útil quando se precisa de especialistas em temas que os membros não dominem. A rigor, se o planejamento foi bem-feito, já se sabe que esta mão-de-obra será recrutada em algum momento do projeto. A atitude de simplesmente aumentar a equipe para acelerar a produção é que está errada e deve ser combatida. Só que alguns gerentes de projeto medem seu poder pelo tamanho da equipe que gerenciam. Você pode imaginar como isso acaba: contratamos mais pessoas, eu fico mais “poderoso” e temos todas as explicações para os atrasos, afinal o projeto era mesmo “muito grande”.

O gerente de projetos deve trazer sua experiência para corrigir as expectativas muito otimistas de algum colaborador mais afoito. Sim, há quem estime 50 horas e depois, com a maior tranqüilidade, cobre pelas 120 horas que foram necessárias para realizar a tarefa. Ele só errou em 140% ! Se o preço é fechado, o risco fica todo com o consultor, mas a sua boa-vontade e a qualidade do produto final podem sofrer em decorrência da pressa. Se a remuneração ficar vinculada ao tempo de prestação de serviço, o contratante precisa de um mecanismo de controle minimamente confiável. Eu não uso uma fórmula geral, prefiro trabalhar segundo as características do profissional mas de todos exijo um relatório de horas que contém o dia, data de hora e início, tempo de trabalho e a(s) tarefa(s) realizadas no dia.

Se no planejamento da semana há tarefas que não foram realizadas, na reunião de avaliação, eu pergunto porque a coisa não seguiu o ritmo programado e quanto isso impacta na data final de entrega. Procure estabelecer pontos de controle, "check-points", que são datas onde se medirá o andamento do projeto em face do cronograma que havia sido programado. Nestas datas, pode-se estar apenas executando-se uma verificação do progresso das atividades ("milestones") ou pode haver entrega de produtos ou sub-produtos (“deliverables”) tais como desenhos, especificações, protótipos, modelos, etc...

Quem já reformou ou construiu uma casa sabe que esta tão trivial experiência de gerenciamento de projeto pode acabar mal. Quantas histórias existem de gente que foi pagando o pedreiro sem atrelar os pagamentos a entregas de tarefas determinadas. Nestas histórias tristes, o dinheiro acaba antes da obra, e o pedreiro some, deixando o cliente sem dinheiro e sem a sua casa. Tudo porque ele não cuidou de atrelar entregas de tarefas a pagamentos, não criou pontos de controle que lhe dariam visibilidade do atraso. Sabendo antes que a “vaca está indo para o brejo” o cliente pode optar por “apertar” o pedreiro ou suspender os trabalhos enquanto ainda tem dinheiro, que poderá ser usado para pagar uma equipe mais eficiente.

É verdade que em projetos de TI nem sempre dá para “trocar o pedreiro” porque há muito conhecimento e estudo envolvidos. Mas por isso mesmo, temos de ser muito mais cuidadosos na monitoração para saber em que momento o projeto começa a atrasar e como fazer para recuperar o ritmo no futuro próximo.

6. Monitore os riscos e seja pró-ativo

Agora que todos sabem o que devem fazer, é importante mitigar os riscos que podem impedir o bom desenvolvimento do projeto. Desenvolva uma lista de fatores de risco e um plano para lidar com eles. Mas lembre-se de que são duas coisas diferentes: a monitoração do risco e controle do risco.

A monitoração dos riscos envolve acompanhar o status de cada risco e as opções de ações definidas para enfrentá-los, caso eles venham a se tornar problemas reais. A monitoração também se preocupa em avaliar a probabilidade de ocorrência de um risco, qual o seu impacto no andamento do projeto e como contorná-lo. Por exemplo, numa determinada tarefa crítica a contratação de dois profissionais pode parecer um exagero mas o gerente do projeto sabe que se algo acontecer nesta área do projeto o impacto será grande no restante. Os profissionais passam a ser um backup do outro dentro da linha de que “quem tem um, não tem nenhum”.

Voltando ao nosso projeto de exemplo, chamo a atenção para um recurso que o MS Project tem e que deve ser usado para se identificar riscos. Veja a tela do diagrama de Gantt que obtivemos a partir da lista de tarefas que elaboramos acima:

Note que há uma seqüência de tarefas que quando alinhadas compõem o prazo de duração do projeto todo. Destaquei o início e o final só para que você perceba que se trata de uma série de processos que devem ser gerenciados mais de perto uma vez que o atraso em algum deles acarretará o atraso do projeto todo. Por isso é que se chama este de “caminho crítico”. Os riscos que estão embutidos nestas tarefas são os que se deve gerenciar mais de perto, de forma mais pró-ativa.

O controle dos riscos é o processo de executar o plano de ações e divulgar seus relatórios de status. Inclui também possíveis mudanças no plano de riscos, e eventualmente até nos planos do projeto. Essas mudanças são referentes a recursos, funcionalidades ou cronograma.

7. Formalize o início e o encerramento do projeto

O início do projeto é um momento solene. O patrocinador deve formalizar a todos os envolvidos que o projeto está iniciado e o cronômetro está correndo. Muita gente não gosta de se preocupar com isso, mas imagine que haja resistência de setores da empresa que se opõem ao projeto. Sem um documento que atesta que o projeto começou, o gerente pode não conseguir apoio algum. Além disso, este documento funciona como um “cumpra-se” de uma autoridade da empresa: não cabe discutir a ordem, o projeto começou e todos os “arrolados” devem participar.

Outro momento importante é o do encerramento do projeto. É preciso formalizar o final para que fique claro para todos os envolvidos, especialmente para o cliente, que o projeto está concluído e que novas necessidades serão atendidas em um novo projeto. Qualquer extensão ou alteração deverá ser orçada e todo o ciclo se inicia novamente. Com relação à manutenção do sistema entregue, não se pode considerá-lo um projeto na medida em que, a princípio, trata-se de um processo contínuo. O que pode ocorrer é definir-se projetos ao longo da vida útil do sistema com o objetivo de melhorá-lo. Por exemplo, a atualização dos equipamentos eletrônicos (“aviônicos”) de um avião para auxílio ao vôo é um projeto que se distingue da sua manutenção rotineira.

Ao final faz-se também uma reunião de avaliação dos erros e acertos da equipe. Chamadas de reuniões "post-mortem", elas servem para se gerar uma lista de "melhores práticas" contribuindo para a formação de uma base de conhecimento que poderá ser muito útil em projetos futuros. Da minha experiência pessoal, posso dizer que tirei grandes lições quanto às "piores práticas", atitudes e decisões que se mostraram ruins e que devem ser evitadas em projetos futuros.

Conclusão

Acima de tudo, gerenciar projetos é planejar e acompanhar a execução com "um olho no peixe e outro gato". O gerente do projeto deve se manter alerta e flexível com os acontecimentos do dia-a-dia mas deve estar sempre se reportando ao plano inicial para não perder o controle. A principal qualidade do gerente de projeto é saber se comunicar bem com todos. Ele é o ponto focal das informações, nele convergem as informações que ele depois deverá processar e divulgar para todo o restante da equipe.

O segredo é envolver a equipe, cliente e fornecedores de tal forma que todos se sintam diretamente responsáveis pelo sucesso do projeto. Como diz aquele velho ditado caipira, "quando todos empurram na mesma direção, ná há carroça que não saia do atoleiro".

(*) Fernando C. Barbi (fernando@hexxa.com.br)

Taxa interna de retorno modificada (MTIR)

O que é?

A TIR modificada (ou MTIR) é uma forma alterada da taxa interna de retorno e procura corrigir problemas relacionados à diferença de taxas reais de financiamento dos investimentos (despesas com valores negativos) e de aplicação de caixa excedente (receitas com valores positivos) existente no cálculo da TIR.

A principal finalidade da MTIR é estabelecer o retorno de um investimento que contemple a aplicação dos fluxos excedentes por uma taxa de aplicação e os déficits de fluxos por uma taxa de captação.

Sintaxe da função MTIR

=MTIR(valores; taxa_financiamento; taxa_reinvestimento)

• Valores é um intervalo que contenha os fluxos de caixa do investimento. Estes números representam uma série de pagamentos (valores negativos) e recebimentos (valores positivos) que ocorrem em períodos regulares. Os valores devem conter pelo menos um valor positivo e um negativo para calcular a taxa interna de retorno modificada.
  Observação: Se não houver ao menos um valor negativo neste intervalo, MTIR devolverá o valor de erro#DIV/0!; este erro ocorre porque a fórmula da MTIR envolve um quociente cujo denominador está relacionado aos pagamentos;
• Taxa_financiamento é a taxa de juros paga sobre o dinheiro usado nos fluxos de caixa;
• Taxa_reinvestimento é a taxa de juros recebida nos fluxos de caixa ao reinvesti-los. Geralmente, esta taxa representa o custo de capital do projeto.

Observação: Se você tentar utilizar a função MTIR e ela não for encontrada, será necessário ativar o suplemento de ferramentas de análise, através do item suplementos do menu ferramentas. Para instalar este recurso, o CD do Microsoft Office pode ser necessário.

Exemplo

No exemplo a seguir, calcularemos a MTIR de um projeto onde, além do investimento inicial, há um gasto complementar ao final do primeiro período. Observe a planilha:

Neste exemplo, a taxa de captação (financiamento) é de 15% ao período, e a de aplicação (reinvestimento), 10% ao período. Não podemos utilizar a TIR neste caso porque a taxa de reinvestimento ao longo do ciclo de vida do projeto não é a mesma da taxa de financiamento. Siga os passos abaixo para calcular a MTIR:

• Abra o assistente de função;
• Selecione a categoria financeira;
• Selecione a função MTIR;
• Aplique os argumentos da função e dê OK quando terminar. Observe a janela do assistente com os dados preenchidos:

Veja a fórmula da MTIR na célula G16:

Observe o resultado da função:

Cavalcante Consultores 

Análise financeira de Empreendimentos

Embora os métodos para a análise de investimentos sejam realmente válidos, eles são deixados de lado por grande parte da comunidade dos negócios, principalmente nas pequenas e médias empresas.

Há muitas razões para esse lamentável fato. Em primeiro lugar, a introdução desses métodos nos currículos das faculdades é um desenvolvimento relativamente recente. Segundo, em muitos casos, os empresários usam, e às vezes, abusam da intuição e da experiência na tomada de decisões sobre a aplicação do capital. Finalmente, o método da taxa de retorno, que é o mais popular, muitas vezes é utilizado de maneira inadequada, gerando uma expectativa errada a respeito do projeto em questão. Infelizmente, essas maneiras inadequadas de aplicação do método da taxa de retorno foram consagradas pela prática devido a suas aparentes simplicidades.

Os objetivos deste artigo são:
- Apresentar, discutir e comparar os dois principais métodos para a análise de investimentos: Método do Valor Presente líquido e o Método da Taxa de Retorno.

- Mostrar que, quando aplicados adequadamente, as decisões são as mesmas, independente do método utilizado.

1) Método do Valor Presente Líquido - VPL

Seja uma empresa que tem uma proposta para aplicar R$ 500.000,00 em um novo projeto. Qual decisão a ser tomada?

O método do VPL consiste no seguinte roteiro para a tomada de decisão:

1) Projete o fluxo de caixa durante toda a vida econômica do projeto.
2) Determine a taxa de desconto, que deve refletir o valor do dinheiro no tempo, o custo de capital e o risco do projeto.
3) Usando a taxa de desconto calcule o valor presente do fluxo de caixa projetado.
4) Calcule o VPL subtraindo o valor presente do fluxo de caixa projetado (VP) do investimento inicial: VPL = VP – Investimento inicial.
5) Se VPL > 0, invista no projeto.

Por que o VPL é um método consistente?

Analisando sob o ponto de vista dos acionistas da empresa, o interesse deles é que a empresa aumente o seu valor. Se a empresa tem hoje um ativo total de R$ 10 milhões e sendo VP o valor presente do fluxo de caixa do novo projeto, o valor da empresa, caso aceite o projeto, passa a R$ 9,5 milhões + VP, caso rejeite o projeto, continua em R$ 10 milhões. Assim, se VP > R$ 500 mil, o projeto deve ser aceito, porque aumenta o valor da empresa.

O que significa a taxa de desconto?

A taxa de desconto é difícil de mensurar com precisão, mas pode-se afirmar que ela é o custo de oportunidade da empresa investir no projeto, ao invés de aplicar o dinheiro no mercado financeiro. Pois se o projeto render menos que o mercado financeiro, a empresa poderia devolver o dinheiro para os seus acionistas para eles mesmos aplicarem no mercado, e não haveria necessidade alguma da empresa existir. Portanto, a empresa só tem sentido se ela consegue criar oportunidades de projetos com retorno maior que o mercado financeiro. Por outro lado, uma aplicação razoavelmente segura, como a caderneta de poupança, rende 6% reais ao ano. Isso não significa que a empresa deve aceitar todos os projetos que rendem 7% a/a, pois essa equivalência de taxas só é válida se os riscos dos dois investimentos são semelhantes. Se o projeto em análise for mais arriscado, deve-se adotar como taxa de desconto o retorno de um ativo financeiro com risco semelhante.

Por que o VPL é método mais indicado?

O VPL é mais indicado porque tem as seguintes características:

1) Reconhece o valor do dinheiro no tempo.
2) Não é afetado por técnicas contábeis.
3) Reflete o aumento de riqueza para o acionista.
4) VPL’s podem ser somados.
5) Depende somente dos fluxos de caixa e do custo de oportunidade.

2) Método da Taxa Interna de Retorno – TIR

A taxa interna de retorno é a taxa de desconto que faz o VPL ser zero. Se ela é maior que o custo de oportunidade considerado, o projeto tem VPL positivo, caso contrário, o VPL será negativo. Aceita-se um projeto se a sua TIR for maior que o custo de oportunidade.

A maior vantagem da TIR é que ela gera as mesmas decisões que o método do VPL na maioria das vezes, mas conflita em alguns casos. O método é amplamente utilizado na prática, mas são necessários alguns cuidados para a sua correta utilização, principalmente nos seguintes casos:

1) Entre um conjunto de projetos, aquele que tem a mais alta TIR não necessariamente tem o maior VPL. Por isso deve-se ter cuidado com o uso indiscriminado da TIR na escolha entre projetos mutuamente exclusivos.

2) Em projetos em que o fluxo de caixa muda de sinal mais de uma vez, pode haver múltiplas TIR’s.

3) Em projetos longos, pode haver diversos custos de oportunidade. Como a TIR é única para todo o projeto, não fica claro contra qual custo de oportunidade deve-se compara-la.


Comparação entre os métodos VPL e TIR

Uma diferença básica entre os métodos do VPL e TIR, que às vezes resulta em decisões conflitantes, é que o método do VPL supõe que as entradas de caixa ao longo do projeto, sejam reinvestidas ao custo de capital da empresa, ao passo que o método da TIR supõe o reinvestimento à própria TIR. Se a empresa acreditar que suas entradas de caixa possam ser investidas realmente à própria TIR, então o método da TIR será o mais indicado. Geralmente esta suposição é difícil de verificar na prática.

Qual método é melhor: VPL ou TIR?

Com base puramente teórica, o uso do VPL é melhor. Sua superioridade teórica é atribuída aos vários fatores já discutidos aqui. O mais importante é a suposição implícita no uso do VPL de que todas as entradas de caixa geradas ao longo do projeto são reinvestidas ao custo de capital da empresa, enquanto que no uso da TIR supõe-se que todas as entradas de caixa são reinvestidas à taxa interna de retorno do projeto. Essa premissa é válida desde que não haja uma grande discrepância entre a taxa interna de retorno e a taxa de desconto utilizada para o projeto. Quando há discrepância entre as taxas mencionadas, os resultados tendem a ser menos confiáveis e podem induzir a erros de avaliação. Além disso, o método da TIR pode levar as múltiplas taxas internas de retorno para um mesmo projeto, caso haja mais de uma inversão de sinal no fluxo de caixa do projeto. Essas taxas múltiplas, embora matematicamente corretas, não têm significado financeiro relevante para o processo de decisão de investimento. Mas as evidências sugerem que os administradores das grandes empresas preferem usar o método da TIR. Essa preferência pela TIR é atribuível à disposição geral dos administradores por taxas de retorno ao invés de dinheiro puro de retorno. Em vista de se citar freqüentemente as taxas de juros, as medidas de lucratividade e assim por diante, como taxas anuais de retorno, o uso da TIR faz sentido para os responsáveis pelas decisões nas empresas. Eles tendem a achar o VPL mais difícil de usar, porque o VPL não mede, na realidade, os benefícios relativos ao montante investido. Ao contrário, a TIR dá àquele que toma as decisões muito mais informações para tomar uma decisão de investimento ao lhe prover dados sobre os benefícios relativos ao investimento inicial. Embora o VPL seja teoricamente preferível, a TIR é mais popular devido ao fato de os responsáveis pelas decisões financeiras poderem relacioná-la diretamente aos dados disponíveis de decisão. Ao responder à questão, qual técnica é melhor, somente se pode dizer teoricamente, o VPL, mas em base prática, a TIR.

Uma alternativa ao método da TIR: O Método da Taxa Interna de Retorno Modificada - MTIR

Como vimos, o método da TIR, embora amplamente utilizado, apresenta algumas restrições que o colocam em desvantagem quando comparado com o método do VPL. As duas principais restrições são:

1) O método da TIR supõe que todas as entradas de caixa devem ser reinvestidas à taxa de retorno do projeto.

2) Um projeto pode apresentar múltiplas TIR’s.

O método da Taxa Interna de retorno modificada – MTIR evita essas duas restrições. Os fluxos negativos são trazidos a valor presente, enquanto que os fluxos positivos são levados a valor futuro no último período do fluxo. Com os valores concentrados no instante zero e no período final, o cálculo da taxa interna de retorno fica fácil e direto.



Bibliografia


FLEISCHER, Gerald A. Teoria da Aplicação do Capital, São Paulo: Editora Edgard Blucher, 1973.


GITMAN, Lawrence J. Princípios de Administração Financeira, Terceira Edição, São Paulo: Editora Harbra, 1984.


BREALEY, Richard A.; MYRES, Stewart C. Princípios de Finanças Empresariais, Terceira Edição, Portugal: Editora McGraw Hill, 1992.


COSTA, Paulo Henrique S.; ATTIE, Eduardo V. Análise de Projetos, Rio de Janeiro: Editora da Fundação Getúlio Vargas, 1987.


HIRSCHFELD, Henrique. Engenharia Econômica, Quarta Edição, São Paulo: Editora Atlas, 1989