|
Os Sete Pecados... Se a frase "parabéns! O projeto de Tecnologia da Informação foi realizado dentro do prazo e orçamento previstos e atende às expectativas dos clientes e usuários!" foi dita alguma vez sobre um projeto de informática, certamente constituiu uma ocasião rara na história da TI.
Se a frase "parabéns! O projeto de Tecnologia da Informação foi realizado dentro do prazo e orçamento previstos e atende às expectativas dos clientes e usuários!" foi dita alguma vez sobre um projeto de informática, certamente constituiu uma ocasião rara na história da TI. Projetos de TI historicamente são caracterizados por atrasos horripilantes, aparente descaso para com o orçamento, e resultados aquém das expectativas dos clientes e usuários finais. O acúmulo destas falhas acaba provocando por sua vez, retrabalho, soluções quebra-galho e consertos, denominados no ramo de "bacalhau". Por que então tantos projetos de informática fracassam? Será que a área de TI é tão peculiar que é impossível realizar seus projetos dentro dos parâmetros clássicos de custo, prazo e qualidade? Ou será que os profissionais da área carecem de capacitação nos conceitos básicos de project management? Ou ainda, a causa dos fracassos será a falta de infra-estrutura e "cultura de projetos" nas empresas? Vamos examinar. TI é diferente? De fato, projetos de informática são diferentes. É inegável, no entanto, que tanto os projetos de desenvolvimento de software puro, quanto os de adaptação de pacotes de software adquirido comercialmente, representam desafios peculiares. Eis algumas das características inerentes a projetos de informática: o estado final dos projetos não é claramente definida; as fases dos projetos se sobrepõem e também são espiraladas; há pouca informação histórica para auxiliar nas estimativas; a mesma pessoa comumente executa papéis distintos: analisa, realiza o projeto, programa e faz os testes; os pontos de não retorno (cancelamento) não são claros; e há tendência do profissional de TI querer "engordar" o projeto. Por outro lado, há grandes similaridades entre projetos de TI e os de outras naturezas. Por exemplo, a maioria dos projetos tem esses aspectos em comum: necessidade de satisfazer cliente/usuário; exigência quanto à qualidade; necessidade de comprometimento dos stakeholders; pressão temporal; limitações orçamentárias; desafios de comunicação; e desafio de trabalho em equipe. Portanto, a maior parte dos desafios de gerenciamento é igual aos outros projetos, no entanto, as peculiaridades inerentes à TI merecem um tratamento especial. A lista de "pecados clássicos" a seguir espelha o tipo de desafios enfrentados na TI em função da somatória das dificuldades clássicas com as peculiaridades à área. Há falhas no gerenciamento de projetos de TI. Algumas tem impacto forte e merecem o rótulo pecado. Estes pecados variam em natureza, mas em boa parte, tem sua origem no início dos projetos. Pecado 1: Não começar o projeto pelo início - Iniciar bem um projeto de TI significa definir com clareza os requerimentos do negócio, entender o cenário em torno do projeto e verificar o alinhamento do projeto com as estratégias da empresa. Parte destas ações extrapola a responsabilidade da área de TI, no entanto, em função do forte impacto destes itens no projeto em si, merecem ser monitorados e alinhados através de interface com as outras áreas envolvidas. O bom início também exige a existência de metodologia ou processo para bem gerenciar as etapas do projeto, particularmente no que diz respeito aos requisitos do sistema a ser desenvolvido e o escopo do trabalho a ser realizado para construir o sistema aplicativo. Pecado 2: Definição ambígua dos requisitos do sistema e do escopo do trabalho (EAP) - Os requisitos do sistema são as características e funções a serem incluídas no sistema. Estes por sua vez partem dos "requerimentos do negócio". A clara definição dos requisitos do sistema aumenta substancialmente as chances para se obter êxito no projeto. O escopo do trabalho, por outro lado, engloba todas as atividades de trabalho (planejamento, elaboração de código, etc.) necessárias para atender os requisitos fixados. Isto se desenvolve através da estrutura analítica do projeto (EAP), também chamada de WBS - Work Breakdown Structure. A clara fixação do escopo do trabalho garante que todo o trabalho necessário será realizado e elimina a realização de trabalho desnecessário. Pecado 3: Não gerenciar mudanças nos requisitos do sistema e no escopo do trabalho (EAP) - Mudanças nos requisitos (funções ou características do sistema) são frutos de avanços tecnológicos, novos cenários de mercado e decisões políticas internas. Tais mudanças requerem controles e acompanhamento, pois as mesmas provocaram repercussões no trabalho necessário para completar o projeto a contento. As mudanças no escopo do trabalho também precisam ser monitoradas, pois novas atividades ou flutuações no volume das atividades existentes, certamente provocaram impacto no cronograma e orçamento do projeto. Pecado 4: Utilizar profissionais de TI com pouca experiência e treinamento em gerenciamento de projetos - A área de TI era notória pela falta de estruturação na condução de seus projetos e pelo pouco preparo dos profissionais dentro de sua especialidade, as habilidades administrativas e gerenciais associadas à gerência de projetos não eram valorizados. Nos EUA, esta postura mudou substancialmente a partir da década de 90. Em função do número alarmante de fracassos nos projetos de TI, houve grande conscientização na comunidade profissional e nas empresas quanto à necessidade de gerenciar projetos de TI e quanto a necessidade de melhorar o desempenho profissional. Isto comprova-se pela grande procura de aperfeiçoamento profissional junto ao PMI, Project Management Institute, o instituto internacional que agrega profissionais de todos os tipos de projetos, onde atualmente 40% dos seus 70.000 membros pertence a área de TI. No Brasil, a situação não é diferente, tanto quanto aos fracassos freqüentes, quanto a conscientização sobre a necessidade de gerenciar mais profissionalmente os projetos de TI. Pecado 5: Fornecer pouco apoio e infra-estrutura - Para se gerenciar múltiplos projetos de TI, alguns elementos básicos precisam existir, tais como: metodologia (ou processo) de gerenciar projetos corretamente com outros procedimentos da empresa; sistemas de informação adequados para controlar projetos e interagir com outros sistemas da organização; e um ponto de apoio (project office ou escritório de projetos) que fornece consultoria interna e apoio a projetos quando necessário no que diz respeito a metodologias e ferramentas. Quando faltam estes elementos, os projetos de TI sofrem as conseqüências. Pecado 6: Dar poucas ênfase a questões comportamentais e de gerência de stakeholders - Quando a área de TI é solicitada a desenvolver um projeto, parte-se da premissa que a solução será fundamentalmente técnica em natureza. Logicamente, as soluções desenvolvidas pelos profissionais de TI espelharão aquela necessidade. Este contexto tecnológico induz os responsáveis pelo projeto a dar pouca ênfase ao lado humano. Mesmo reconhecendo que a solução final será de essência técnica, o trabalho é realizado por pessoas que enfrentam desafios semelhantes aos de profissionais de outras áreas. Isto é, existem desafios de comunicação, conflitos de personalidades, necessidade de criar espírito de equipe, e questões políticas, entre outros. Os stakeholders portanto (todos que tem a ganhar ou perder com o sucesso ou não do projeto) precisam ser proativamente gerenciados para evitar um fracasso na condução do trabalho. Pecado 7: Dar pouca atenção ao controle dos projetos - Um cenário não raros em projeto de TI é descobrir, no quinto mês de um projeto programado para seis meses, que é preciso prorrogar o prazo por um período de seis meses adicionais, conseqüentemente dobrando o prazo inicial. Tal "descoberta" é feita apenas no penúltimo mês por falta de controle. Um sistema de controle que acompanha as datas chaves e marcos principais, identificaria esta tendência cedo no projeto, em tempo hábil para se tomar medidas corretivas e reduzir o risco de ocorrer atrasos. Quem peca mais: o profissional ou a organização? Já que gerentes de projetos excelentes são por natureza raros, é de esperar que a organização colabore para que gerentes bons e razoáveis também possam fazer um trabalho eficaz. Parte da eliminação destes pecados depende da organização, que tem responsabilidade para criar uma "cultura de projetos" e implanta os apoios necessários através de metodologias, normas, procedimentos, project office, etc. Mesmo reconhecendo a responsabilidade substancial da organização, nesta época de empregabilidade, não é razoável imputar toda a responsabilidade da capacitação do profissional à empresa. Cada indivíduo tem o dever de se preparar para desempenhar sua função em termos de conhecimento, treinamento e certificação profissional, independentemente do apoio eventual da empresa. Cabe portanto a ambas as partes cumprir suas respectivas responsabilidades para que os projetos de TI possam ser motivo de celebração e alegria, e não de crítica e lamentação. O gerenciamento de todos os projetos de TI em perfeito atendimento aos parâmetros de custo, prazo e qualidade pode ser um sonho inatingível, no entanto o número excessivo de fracassos pode ser reduzido substancialmente. O passado de atrasos horripilantes, pouca atenção aos orçamentos e resultados abaixo das expectativas dos clientes e usuários finais aos poucos poderá ceder caminho a projetos mais estruturados que desviam menos dos caminhos traçados. Com isto reduz-se o retrabalho, as soluções "quebra galho" e os consertos "bacalhau". Projetos de informática são diferentes e merecem tratamento diferenciado. Mas, estes projetos possuem os mesmos desafios que todos os outros projetos tem. A solução para os responsáveis nas organizações bem como os profissionais da área é de ficar atento aos pecados clássicos historicamente cometidos e passar a praticar a boa gerência de projetos. Assim reduzir-se-à o número de fracassos e aumentar-se-à a probabilidade de realizar o sonho de se ter projetos de TI que atendam aos parâmetros de custo, prazo e qualidade e atendendo plenamente aos clientes e usuários. Paul Campbell Dinsmore é Project Management Professional (PMP) e Fellow do instituto internacional PMI Project Management Institute. É autor de oito livros e diretor presidente da DA Consultores (www.dinsmore.com.br) Fonte: Developers CioMagazine, nº 55 - Março/2001 |
