Blog do Alex Pimenta

Típico Cronograma

Toda regra tem uma exceção. O que vemos na maioria das vezes são atrasos nos projetos de TI. Quantas vezes você já ouviu algo parecido com isso: “Era para entregar no dia primeiro, mas hoje é dia 10.”; Faremos em dois meses, mas levou 3. Por quê?

Inicialmente vamos entender o que é projeto. Projeto é um conjunto de etapas, que permitem que evolua do conceito até o produto ou serviço final. Pra se concluir um projeto nós partimos de processos.

O que é processo? Um processo é uma série de ações que geram um resultado.

Processos se enquadram em duas categorias:

1. Processos da gerência de projetos : se relacionam com a descrição, a organização e a conclusão do trabalho do projeto. São universais a todos os projetos, pois controlam o ciclo de vida do gerenciamento de projetos.
2. Processos orientados ao produto : se relacionam com a especificação e a criação do produto do projeto, sendo exclusivos a cada produto. São definidos pelo ciclo de vida do projeto, e variam de acordo com a área de aplicação.

Agora vamos pensar nos programas para o controle dos processos (detesto cronogramas, mas é um mal necessário): Microsoft Project e OpenProj (mais sobre o OpenProj aqui).

O que costumamos definir e quem define na criação desses cronogramas?

Descrevemos cada etapa dos processos. Detalhamos o máximo possível descriminando os processos, as etapas para concluí-las, atribuimos à membros da equipe e definimos o tempo para que cada etapa seja concluída. Devemos considerar algumas varíaveis como: feriados, rotinas que devem ser cumpridas pelos membros e que impactam na evolução do projeto, demandas excepcionais e urgentes (out of scope – daí que entra a mãe diná); entre outras variáveis que não podem ser previstas. Então supomos que uma etapa chamada cadastro de produtos, por exemplo, pode ser concluída em 8 horas mas também poderá levar 16 horas (dobramos em muitos casos). Normalmente desconsideramos ausência dos membros por motivos diversos (dor de barriga, enxaqueca, etc), falha nas comunicações internas e no briefing (acontece muito e é onde o escopo normalmente é aumentado por conta do desenvolvedor ou é insuficiente). Então as 16 horas podem virar 32 horas.

O grande problema é que na maioria das vezes, quem define o cronograma é uma pessoa que não entende de desenvolvimento. É um gerente que não sabe se comunicar com os membros de desenvolvimento. Isso não é regra mas, acontece muito. O resultado é que este gestor costuma tratar o processo de desenvolvimento como uma linha de produção onde um cadastro leva 8 horas, um relatório 16 horas, etc. Porém a principal diferença ao meu ver é que Projetos de software são normalmente mais complexos do que projetos de outras áreas da indústria.

Tomamos como exemplo o processo de montagem de um veículo. Ao se produzir um automóvel sabemos que ele levará 6 horas para ser concluído então podemos com segurança prever que 20 (vinte) deste mesmo automóvel levará 20 x 6, e saberemos o tempo exato para entregar esses 20 automóveis. Por outro lado se dermos a tarefa para 20 programadores desenvolverem um mesmo cadastro teremos 20 formas diferentes de codificação do mesmo cadastro, apesar do resultado ser o mesmo pois, cada um terá um modo de pensar, um método de desenvolvimento diferente, dependerá da lógica e da criatividade de cada um, diferenças de experiência em resolver dificuldades, etc, serão inevitavelmente o ponto determinante para o tempo de desenvolvimento. Assim funciona a engenharia também, cada um vai entregar um projeto totalmente diferente para construir um mesmo hall de entrada.

Leiam também :

• “Por que projetos falham“;
• “As Cinco Doenças do Gerenciamento de Projetos“;
• “Especificação de Requisitos (Por que os projetos atrasam?)”
  “Processos da gerência de projetos“

Não poderia finalizar este post, sem falar um pouco sobre o que podemos fazer para minimizar ou evitar os atrasos. Poucas empresas possuem, mas é importante uma documentação de padrões para desenvolvimento. Esses documentos devem possuir desde descrição de ambiente de desenvolvimento, homologação e produção como servidores de banco de dados, nomenclaturas para banco de dados, tabelas, stored procedures, colunas de tabelas, functions, etc. Padrões para nomenclaturas de projetos de software, classes, páginas web, regras de codificação utilizadas pela equipe, comentários, nomenclaturas para variáveis, constantes, etc. Ou seja, tudo que facilite o desenvolvedor e minimize a exigência de criatividade para esses detalhes. O tempo será minimizado, pois o mesmo só deverá se preocupar em aplicar técnicas e métodos ultizando lógica de programação. Esta padronização também minimiza o tempo de compreensão por parte dos programadores, que deverão conhecer todos os métodos assim que entram para a equipe. Abaixo alguns exemplos que podem ser seguidos:

• “Padrão de Desenvolvimento C#“
• “MSDN – Boas práticas em C#“
• “Convenção de nomes para projetos .net / C#“

Ultilização de padrão de processos de desenvolvimento. Acho que neste aspecto não temos muito o que dizer, a microsoft já criou um bem adequado o SDL, que tem como fator principal a procupação na segurança evitando ataques maliciosos :

• “O processo SDL – Trustworthy Computing Security Development Lifecycle“

Alta produtividade usando Visual Studio. Abaixo artigos sobre atalhos, e outras ferramentas que ajudam na produtividade no desenvolvimento através do Microsoft Visual Studio:

• “Dicas para alta produtividade no Visual Studio“
• “Aumente sua produtividade com o Visual Studio 2008“
• “A busca da qualidade no desenvolvimento de software“

Espero que tenham gostado e seja proveitoso.

Até a próxima…