Gestão de projetos e suas metodologias

Sem dúvida é o calcanhar de Aquiles e que, infelizmente, manchou a reputação de excelentes profissionais de tecnologia por muitos anos.

Passamos por diversos momentos sempre buscando amenizar uma enorme fenda que existia entre área de negócios e área de TI. O grande problema era tentar sempre determinar uma data de entrega de um sistema de informação da mesma forma como se determina uma data para entregar doces para uma festa. Entender as complexas variáveis de um processo que inclui entender uma necessidade, traduzir esta necessidade em uma solução tecnológica, executar o projeto de tecnologia e, por fim, educar as pessoas em lidar com uma nova cultura.

Executar o projeto de tecnologia nunca foi o problema mas, ao meu ver, entender a necessidade (ou ser claro ao explicar a necessidade) sempre foi o grande problema. O pior é que esta falta de entendimento somente era detectado na validação final do projeto ou no treinamento.

Presenciei verdadeiros holocaustos quando cheguei em algumas empresas para dar uma solução viável após anos de projeto em andamento e centenas de milhares de reais gastos sem o resultado esperado. Situações realmente muito complicadas.

Existem diversas metodologias que acabei aprendendo durante cada fase da Gestão de Projetos nestes últimos 15 anos. Em cada uma delas existem pontos falhos e pontos relevantes, mas nenhuma delas conseguiu aplicar uma métrica eficaz para determinar o que as empresas sempre querem saber:

  1. Quando o sistema ficará pronto?
  2. Quanto o sistema vai custar?

Estas simples perguntas nunca foram respondidas com exatidão e esta falta de respostas fez com que a gestão de projetos fosse destacado para um cenário independente. Chegamos a tal ponto que foi necessário criar o PMO (Project Management Office), que acaba criando mais um nível de discussão onde os gerentes de projetos respondem ao PMO, mas não quero ter este assunto em foco agora. Como disse anteriormente, passei por cada uma destas fases e, em cada uma delas existiu a “metodologia salvadora” e que nos levou a uma nova metodologia e que, por sua vez, levou a uma outra nova metodologia. O mercado criava novas certificações e cada empresa acabou migrando para estas novas metodologias (ou não), criando um universo de letrinhas e templates a serem seguidos.

No final de tudo isso, as mesmas perguntas continuam a serem feitas e as respostas são variáveis. Na empresa “A” funcionou, mas na empresa “B” deu errado. Na empresa “A” o sistema ficou pronto dentro do prazo mas o custo foi muito superior ao orçado. Na empresa “B” o sistema nunca terminou e o custo continua subindo e ultrapassando o orçamento a cada mês.

Neste cenário caótico surgiram os “sistemas empacotados”. Sistemas prontos, funcionando e que atendiam áreas específicas. Conhecidos como sistemas de prateleira, não atendiam completamente as necessidades da empresa mas davam ao cliente uma perspectiva mais real de investimento e resultado.

Vieram, então, os ERP’s  (Enterprise Resource Planning) ou SIGE (Sistema Integrado de Gestão Empresarial) que nada mais são do que sistemas independentes que integram-se através do banco de dados. São vendidos por módulos e customizados de acordo com regras de negócios específicas de cada cliente. Será que foi a solução?

Definitivamente não foi a solução, pois as customizações são caras e infinitas. O ERP garante que algo será implantado e, se não houverem customizações, podem haver uma data de implantação e custo definidos. Caso contrário, como um consultor israelense me dizia, “o céu é o limite”.

Começamos então a adotar estratégias de adaptar a empresa ao sistema contratado ou preparar o CIO para por a mão no bolso.

Já participei de muitas implantações de ERP, assim como participei muito mais de projetos para retirar o ERP da empresa. O que faria uma empresa abrir mão de um investimento tão alto? Em um dos meus clientes esta decisão representou perder mais de 2 milhões de reais em uma implantação que custou 3 anos de migrações e informações importantes. Estas experiências permitiram enxergar que uma empresa que depende da tecnologia ou tem a tecnologia como elemento estratégico, necessita ter suas “próprias pernas” e moldar suas própria TI de acordo com suas pretensões no mercado.

Conclusões

Todas estas experiências permitem fazer um verdadeiro resumo do que é relevante. Implantar um projeto de TI requer muito mais do que dezenas de documentos, relatórios, métricas ou qualquer outra receita. Um projeto de sistema requer pessoas que conheçam muito bem cada área de negócios, assim como as necessidades da empresa. Estas pessoas são os Stakeholders e que são responsáveis por fornecer e aprovar as regras de negócios a serem implementadas no sistema a ser criado.

Conseguimos medir o andamento de um projeto acompanhando através de entregas pequenas, dentro de curtos espaços de tempo. Estes pacotes são criados por cada área de negócios envolvida. A área de TI, por sua vez, tem o papel de analisar, entender e propor um prazo de entrega deste pacote funcionando completamente. A equipe de desenvolvimento precisa estar focada apenas neste pacote e, para garantir isto, existe uma pessoa responsável por resolver os eventuais embaraços da equipe no dia-a-dia. Esta pessoa não é um gerente de projetos, pois ele está envolvido com diversas equipes e projetos diferentes. Não é responsável por determinar datas de entrega, mas é um facilitador para que as equipes não percam tempo com assuntos paralelos à tecnologia.

Quem fornece o prazo de entrega é a própria equipe de desenvolvimento, afinal, são eles que vão por a mão na massa e que são os especialistas.

Defendo a tese de manter uma equipe de testadores e que, baseado nas regras de negócios do pacote desenvolvido, os testadores farão as validações necessárias e apurações de eventuais erros lógicos e técnicos.

O pacote estando aprovado pelos testadores deve ser apresentado ao Stakeholder para homologar o pacote. Em seguida será marcado para publicação no ambiente de produção, conforme acordado entre área de negócios e TI.

Este modelo reúne documentação mínima que provém do levantamento de requisitos junto às áreas de negócios e, também, implementações necessárias durante o desenvolvimento do pacote, uma vez que a equipe de TI está sempre próxima do Stakeholder neste modelo. Além disso, este modelo privilegia a entrega de pacotes funcionais, diminuindo a expectativa e aumentando a credibilidade e segurança a cada entrega.

As técnicas de gestão do tempo são muito eficientes e, entre todos modelos que já pratiquei, este é, sem dúvida, o melhor modelo tanto para as áreas de negócios quanto para área de TI. Estou falando aqui sobre o Scrum.

Os especialistas em Scrum não gostam de classifica-lo como uma metodologia, mas sim um framework, um processo a ser respeitado. É quase uma filosofia de trabalho e, particularmente, o que eu mais aprecio neste trabalho é a possibilidade de modelar de acordo com as diferentes necessidades de cada empresa. Já trabalhei aplicando Scrum em 4 cenários completamente diferentes e os resultados sempre foram satisfatórios.

Se a empresa onde você trabalha ainda não conhece Scrum, vale a pena se informar e aplicar. Vou criar um artigo mais específico e explicando melhor como podem ocorrer estas adaptações. Certamente conseguirá estabelecer um processo que atenda sua empresa, independente do segmento que ela esteja atuando. Afinal, quando se trata de sucesso no desenvolvimento de sistemas, merece toda nossa atenção.

Anúncios

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s