Dicas para reduzir o estresse em Projetos de TI

AGRADEÇA AO AUTOR COMPARTILHE!

“Existem questões que podem ser verificadas durante todo o ciclo de vida de um projeto como forma antecipada de minimizar a quantidade de estresse e problemas”

O ambiente de TI está acostumado com projetos de implementações de sistemas cada vez mais agressivos em termos de prazos e custos. Tais projetos acabam por requerer grande esforço adicional de toda a equipe (cliente e fornecedores), gerando horas extras, descontentamentos e, em grande parte deles , atrasos, alterações de escopo e custos adicionais. estresse-projetos-ti-tecnologia-informacao-equipe Muitos projetos já iniciam com incertezas em relação ao cumprimento das metas propostas. Mas será que todo projeto exige todo esse nível de estresse? Não há outro caminho? Temos visto uma gama enorme de projetos, todos eles com metodologias aplicadas, gestão integrada, PMO, ferramentas de controle e acompanhamento semanal e até diário, mas que com o avanço das fases iniciais geram grandes dificuldades de implementação. Não é necessário repetir aqui que a base para o sucesso de um projeto é a comunicação em todas as suas camadas. Sem ela não há projeto bem sucedido.

Mas, além da comunicação, uma série de outras questões necessitam ser verificadas para que tenhamos sucesso em cada vez mais projetos. E quando dizemos sucesso, nos referimos não só a escopo, custo e prazo, mas também outro a fator de suma importância: a satisfação das equipes envolvidas (cliente e fornecedores).

Observe estes pontos:

Os requisitos foram bem detalhados e a área usuária final está ciente do futuro funcionamento do sistema? Em alguns casos os requisitos são detalhados pela equipe de TI sem a participação da área de negócios, o que aumenta a chance de alterações de escopo ao contato com o futuro sistema – o que ocorre geralmente em fases avançadas do projeto.

O esforço foi realmente bem dimensionado? Cliente e implementador estão cientes das atividades previstas para cada um e dos esforços necessários? Ocorre muitas vezes que atividades são subestimadas e previstas para ocorrerem em paralelo com outras, como, por exemplo, atividades de treinamento e de testes de sistema planejados para ocorrerem em paralelo e pela mesma equipe.

A participação dos times, principalmente da área usuária, foi definida previamente de comum acordo? É muito comum atribuir responsabilidades à áreas que não estão preparadas para executá-las. É necessário o envolvimento cada vez mais cedo das equipes, de forma a adquirir o comprometimento de tais áreas e garantir o cumprimento das metas propostas.

Todas as fases do projeto foram detalhadas? Muito se tem visto de atividades e responsabilidades que surgem de um dia para o outro sob a alegação de que são atividades comuns a todos os projetos e desta forma implicitamente inseridas a estes, sem planejamento adequado.

Respostas positivas para as questões acima diminuem o surgimento de atividades não previstas, falta de comprometimento, atrasos, e, alterações de escopo.

Falando sobre alterações de escopo, os famosos “change requests”, é lógico e racional que surjam em alguns dos projetos, principalmente os de maior escala, mas, estes não devem ser utilizados para acomodar atividades não detalhadas ou justificar atrasos decorrentes de outras situações, como as apontadas acima. Regras de jogo definidas a priori, com a participação de todos os envolvidos, como TI, área usuária e fornecedores, bem como uma gestão efetiva, onde os pontos acima são verificados recorrentemente durante TODO o projeto, são o caminho para aumentar o compromisso e satisfação das equipes e desta forma diminuir o nível de estresse na implementação de projetos.

Obs.: O artigo possui maior foco em desenvolvimento/implantação de software, no entanto, os mesmos questionamentos podem ser aplicados em projetos de TI variados.

AGRADEÇA AO AUTOR COMPARTILHE!

Felicio de Riggi Jr

Mais artigos deste autor »

Gerente de Projetos da Oracle, com ampla experiência profissional em TI. Gestão de Projetos de CRM e ERP. Possui certificação PMP e é mestre pela Universidade Federal de São Carlos.


2 Comentários

Nelson
1

Não sei se concordo com a abordagem que você passou e os pontos destacados.

O esforço foi realmente bem dimensionado? Cliente e implementador estão cientes das atividades previstas para cada um e dos esforços necessários?

Todas as fases do projeto foram detalhadas?

Pensando em um projeto de 1000 horas, você considera realmente viável que todo o planejamento seja feito antes? Tudo mto bem dimensionado?

Pq não, dividir esse projeto em pequenos entregáveis, verificando o que é de uso imediato pelo usuário.

Note que adotando essa abordagem que falo, o usuário tem apenas uma previsão de quando o projeto será entregue, mas essa previsão pode ir se modificando ao longo do projeto pelas MUDANÇAS.

Acredito que o maior problema é entender que as coisas são dinâmicas, os requisitos de negócio mudam constantemente e simplesmente não temos como prever quanto tempo o desejo inicial do usuário precisa para ser produzido e entregue.

Não sou defensor do “ágil” mas vejo que o pensamento “Precisamos de todo o escopo” tende a morrer logo….

Felicio
2

Olá Nelson, boa tarde.

Obrigado pelos comentários !

O principal recado de minha colocação é a necessidade de transparência na execução dos projetos.

Concordo com você que grandes projetos devem ser divididos em entregas menores, observando as necessidades do usuário. Não há dúvida disso !

Considerando seu exemplo, precisa estar muito claro para todos os envolvidos que as “1000 horas” são somente uma ESTIMATIVA INICIAL.
Na grande maioria das vezes o cliente compra um projeto de 1000 horas esperando que ele seja entregue em exatas 1000 horas.
Se você não conhece o escopo total, não há garantia alguma que as 1000 horas são reais. O que gera grande desconforto e estresse durante a aprovação das MUDANÇAS.

Abraços,

Felicio

Deixe seu comentário

Seu endereço de e-mail não será publicado. Campos com * são obrigatórios!

Você pode usar estas tags e atributos de HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">