|
|
||
        |
 |
Conheça o Plugfeed | » Início » Desenvolvimento » Gerência e Mercado » EXPECTATIVA: o segredo do sucesso em projetos, Parte 1
Conheça o Plugfeed | » Início » Desenvolvimento » Gerência e Mercado » EXPECTATIVA: o segredo do sucesso em projetos, Parte 1
--> |
|
Avaliação: Não avaliado | Publicado em: 05/06/2008
EXPECTATIVA: o segredo do sucesso em projetos, Parte 1
Alercio Bressano é Gerente de Projetos e Professor Universitário. Possui 8 anos de experiência na área de desenvolvimento de projetos de software, atuando como desenvolvedor, analista e líder de equipe. Atualmente, é líder do PMO (Escritório de Gerenciamento de Projetos) da área de TI de um grupo empresarial, gerenciando o portfólio de projetos dessa companhia. Leciona disciplinas relacionadas à área de Engenharia de Software em curso de Graduação e de Gerência de Projetos em curso de Pós-Graduação. Sobre a sua formação acadêmica, é especialista em Melhoria de Processo de Software pela Universidade Federal de Lavras (UFLA-MG), especialista (MBA Executivo) em Gestão Empresarial pela Fundação Getúlio Vargas (FGV-RJ), graduado em Processamento de Dados pela Universidade Tiradentes (UNIT-SE) e técnico em informática pela CEFET (SE). Tem interesse nas áreas de Qualidade de Software (Modelos e Processos), Gestão de Projetos, Empreendedorismo e Administração.
EXPECTATIVA: o segredo do sucesso em projetos, Parte 1
Vou iniciar essa série de artigos com a seguinte questão para você, profissional de informática: por que os projetos fracassam? Por que não atendo o que o meu cliente deseja? Falando especificamente dos projetos de software, vocês podem responder: "os projetos fracassam porque os prazos estouram, ou seja, o projeto é entregue dias ou meses depois do previsto"; ou ainda "porque foi prometido que ia ser entregue um sistema com diversas funcionalidades e no final foi entregue um produto sem ter o que o usuário necessitava ou algumas não funcionavam adequadamente"; ou até mesmo "eu havia previsto gastar Y e gastei Y x 4". Nesses 5 anos de estudos e vivência nessa ciência inexata (gerenciar projetos e conduzir pessoas) e diante dos diversos motivos que poderíamos elencar que fazem com que os projetos fracassem, aponto que, na minha leitura, a fronteira entre o sucesso e o fracasso de um projeto pode ser resumido em uma única palavra: EXPECTATIVA. Você deve estar pensando: “esse cara está maluco! Eu aqui estudando como fazer um bom cronograma, como definir estimativas de tempo adequadas, como estimar o custo correto do produto, a qualidade, os recursos humanos envolvidos, entre outras áreas, e você vem me dizer que um projeto que satisfaz o cliente é aquele que eu administro bem as expectativas?! Está de brincadeira...”. Pois é! Vejamos: se pararmos para analisar as causas dos insucessos relatados em projetos e outras que existirem, todas elas convergem para a seguinte afirmação: os projetos fracassam quando alguma expectativa do cliente foi frustrada! Concorda? Se ainda não concordou, não se preocupe. Ainda temos um longo caminho pela frente e espero conseguir fazer você pensar melhor nisso. J Daí vem uma outra questão: mas como atender as expectativas dos clientes, considerando que existem diversas variáveis envolvidas (tempo, custo, pessoas, qualidade, escopo, etc.)? Se observarmos, o que todo cliente deseja é um sistema com todas as funcionalidades que ele necessita (escopo), que seja feito e entregue o mais rápido possível (tempo) e no preço mais baixo (custo). Isso é impossível, não acha? Isso mesmo. Isso não é possível! Como tudo em informática, se eu quiser ter esse benefício de um lado, vou perder de outro. Por exemplo, se eu quiser ter mais desempenho nessa aplicação, vou perder em segurança e vou ter um custo maior. Se eu quiser ter mais segurança, vou perder em desempenho. Assim como na informática, as variaveis TEMPO, CUSTO e ESCOPO no gerenciamento de projetos sao conflitantes! O que isso quer dizer? Isso significa que, se optarmos por uma, teremos que abrir mão de outra. Isso é chamado de trade-off. Daí, somos apresentados ao conceito denominado "restrição tripla"*. * Gostaria de deixar claro que, alguns autores citam cinco restrições, ao invés de três: escopo, tempo, custo, qualidade e satisfação do cliente.
Quando iniciamos o planejamento de um projeto de software, a partir de um entendimento do problema com o cliente, definimos a solução informatizada que irá atender as necessidades dele. Ao ter essa visão macro das funcionalidades que o produto final deverá conter (nesse caso, o sistema de informação), temos o escopo desse projeto. Após essa fase, partimos para a definição dos recursos humanos (e materiais) necessários para o desenvolvimento desse produto definido. Após conhecer o número de pessoas que serão alocadas, estruturamos o escopo numa sequência de atividades e, para cada uma delas, definimos os responsáveis e a estimativa de tempo necessária para execução. Depois de ter definido isso para todas as atividades do projeto, teremos a nossa primeira versão do cronograma do projeto. Nesse cronograma, visualizamos as atividades que serão necessárias para construir o produto, os recursos que serão responsáveis pela execução de cada uma delas e o tempo que foi estimado para essa execução. Portanto, nesse ponto temos o ESCOPO (atividades), o CUSTO (valor dos recursos humanos e materiais a ser utilizado no período do projeto) e o TEMPO (a data inicial e final do projeto). Vamos a um exemplo prático: Um cliente necessita administrar melhor seus projetos e contrata uma empresa de software para desenvolver uma ferramenta para automatizar o controle dos projetos. Após a reunião de definição de escopo e a elaboração do cronograma, temos o seguinte cenário:
- Módulo de Cadastramento de Projetos - Módulo de Alocação de Recursos e Estimativas - Relatório de Controle de Atividades Semanais - Relatório de Avaliação Mensal dos Projetos
Recursos a serem alocados nesse projeto (stakeholders principais): VT – Cliente/Sponsor AB – Gerente de Projeto / Analista TA – Arquiteto / Desenvolvedor
Custo Inicial do Projeto: R$ 43.680,00
Cronograma do projeto
* esse gráfico é gerado com o número de atividades a serem concluídas em cada período de tempo do projeto (nesse exemplo, período mensal.
Continuem plugados...
Alércio Bressano, MBA Professor Universitário  |
   |
 |
 |
|
|
