Se tem algo muito importante que deve ser levado em consideração na hora de realizar a produção serviços e trabalhos é a organização. Para isso foram inventados os Gerenciadores de projetos, que têm a missão de ajudar na hora de analisar o tempo gasto em cada uma das tarefas, ter uma idéia de o que cada envolvido no projeto está fazendo e quais recursos o projeto precisa para continuar em pleno andamento.

Em minhas “andanças” pela web em busca de uma nova solução de gerenciamento aqui para a empresa, decidi testar o Microsoft Project 2007 e encontrei esse ótimo artigo, do antoniozigg, com uma descrição bem bacana do que é e quais os tipos de gerenciadores que podemos encontrar por ai. Segue o texto:

Recentemente fiz um estudo de vários gerenciadores de projetos para incorporar a nossa atividade diária, de modo que se possa ter um controle mais minucioso sobre os projetos nos quais está implicada nossa empresa.

Por causa disso, considerei como uma ótima idéia explicar um pouco o que é um gerenciador de projetos e dar várias possibilidades para o usuário interessado em administrar um sistema destes.

Um gerenciador de projetos é um ferramenta ou software que permite levar um controle minucioso de cada um dos projetos de uma empresa. O controle implica todas as partes do trabalho, como a planificação, desenvolvimento e produção, assim como o trato com o cliente.

Um gerenciador de projetos deve ser capaz de gerenciar vários trabalhos, já sejam internos da empresa ou contratados por clientes. Dentro de cada projeto ou trabalho, deve se poder administrar todo tipo de itens como:

• Projetos, com descrições, datas de entrega, tempos estimados, etc.
• Usuários, geralmente os trabalhadores que estão implicados nas tarefas dos projetos.
• Tarefas, manejando especificações, prazos, prioridade, planejamentos de tempo, etc. e ademais, deve poder atribuir recursos da empresa (geralmente empregados) a cada tarefa.

Este é um ponto inicial a partir do qual o gerenciador de projetos pode se complicar tanto como se desejar, agrupando mais ou menos possibilidades e opções para gerenciar cada um dos trabalhos da empresa e facilitando as tarefas de administração ao responsável dos grupos de desenvolvimento ou dos distintos projetos. Opções avançadas podem ser:

• Gerenciamento do tempo de cada usuário, com possibilidade de estabelecer horas e atribuí-las a cada uma das tarefas do projeto.
• Diagramas de Gantt das diferentes tarefas a realizar, com sua disposição em um calendário de dias.
• Gerar reportes de carga de trabalho dos trabalhadores e em que estão empregando o tempo.
• Gerenciar dependências em tarefas, que se tenham que fazer umas depois de outras.
• Ter um controle das comunicações entre usuários gerenciadores e o cliente, assim como ter um registro histórico dos materiais que tenham sido entregue ou utilizado para a especificação ou desenvolvimento do projeto.

A utilização do gerenciador de projetos pode ser algo específico da pessoa encarregada do gerenciamento do projeto (o administrador, gerenciador ou chefe do projeto). Então é um programa que o gerenciador utiliza e lhe serve internamente para saber sobre o andamento do projeto (em que ponto se encontra em cada momento e os tempos ou recursos que necessitará até a finalização). Porém, também pode ser uma ferramenta que utilize toda a equipe de desenvolvimento, e então trata-se de uma utilidade mais completa, porque não só serve ao gerenciador, como também a cada um dos integrantes da empresa, para saber as tarefas que têm pendentes e o andamento de cada uma delas.

Tipos de gerenciadores de projetos

Com certeza se podem fazer várias classificações de gerenciadores de projetos, porém vamos comentar uma em função da interface.

Aplicações de área de trabalho. São gerenciadores de projetos que funcionam como uma aplicação de área de trabalho, ou seja, um programa como qualquer outro que tenhamos em nosso sistema operacional. Por exemplo:

• Microsoft Project (da suite office)
• Team Manager
• Integrados em Outlook: Microsoft Outlook Project Management ou Outlook Project Management
• Task Juggler (um projeto de código livre para Windows)
• ToutDoux (outro software livre para sistemas Linux GNOME)
• KPlato (software livre para Linux com KDE)
• Open Workbench (Software livre para Windows)
• airTodo que é uma aplicação de código livre que se integra com Eclipse e com suporte para os sistemas operacionais mais habituais.

Aplicações web. São sistemas criados com interface web, que se acessam em um domínio de Internet ou uma intranet por meio de um navegador. Quando estão publicados em um domínio de Internet têm a vantagem de que se podem acessar desde qualquer outro computador em qualquer parte do mundo, sempre que tenhamos uma conexão à Internet.

• Código livre em PHP: Como dotProject, Open Project, Active Collab, Double Choco Latte, Tutos, PHProjekt, Project Pier
• Código libre para el framework Ruby on Rails
• Aplicaciones comerciales ASP: Ace Project (que tem uma versão online e uma básica que é gratuita)

Conclusão sobre o gerenciamento de projetos

Utilizar uma ferramenta de gerenciamento de projetos é imprescindível para se organizar, sobretudo em empresas de certo porte, que manejem vários projetos. Embora seja muito útil em geral para qualquer grupo de trabalho, seja do tamanho que for. Principalmente é muito interessante para modelos de empresa descentralizada, cada vez mais comum, onde cada pessoa trabalha de forma remota.

Fonte: Miguel Angel Alvarez

http://www.criarweb.com/artigos/que-sao-gerenciadores-de-projetos.html

E para quem se interessou pelo MsProject, segue o link de uma apostila que ensina a trabalhar com o programa:

Apostila MS PROJECT 2007 Pro

Bom, por hoje é isso. Até o próximo post.

Há tempos venho pensado (e passado por) – em situações em que nós, programadores somos cobrados no quesito prazo de entrega de projetos. Inclusive, dias atrás fiz, em minha cabeça, uma breve comparação em como cada uma das empresas que trabalhei e a que trabalho hoje, agem em relação à isto.

Hoje, meio que “sem querer, querendo”, encontrei um post que trouxe à tona exatamente a conclusão que cheguei na comparação que fiz anteriormente. Segue abaixo o post de Paulo Soares:

Eu sei o que é desenvolver?

Acredito que, muitos dos problemas que são enfrentados no dia-a-dia de um profissional de TI (Tecnologia da Informação), certamente, estão relacionados ao não entendimento dos conceitos que cercam a computação. Os gerentes de TI (entenda nossos chefes), talvez por pouca experiência, criam esperanças que as coisas poderiam ser melhores, que os prazos poderiam ser cumpridos, que os projetos poderiam ser entregues no primeiro prazo acordado etc.,  porém não analisam o contexto no qual submetem seus colaboradores.

Primeiro,  você sabe o conceito da palavra “desenvolver”? O melhor entendimento que extraí está no dicionário Michaelis:

de.sen.vol.ver: Adiantar, aumentar, melhorar, aperfeiçoar, fazer progredir

Pois bem, adiantar, aumentar, melhorar, aperfeiçoar, fazer progredir necessita que alguma coisa exista antes. E, geralmente, quando fazemos sistemas, a coisa nasce do zero. Tá bom, não é bem do zero, mas nada que se aproxime do que você realmente precisa existe. A menos que você esteja em uma manutenção evolutiva, as coisas nascem do zero, certo? Por que não usar a conotação bíblica? “No princípio, Deus CRIOU os céus e a terra”. Deixa eu repetir, CRIOU. Do zero… Então, se você parte do zero, você CRIA, e não DESENVOLVE.

Primeiro mito desvendado, você não desenvolve sistemas, você os cria. Eu criei isso.

Perceba que seu problema começou antes mesmo de você saber que estava em um problema. Quando você é nomeado/contratado para fazer parte de uma equipe de desenvolvimento de sistemas, você já está entrando em um barco furado e não tem noção disso. Mas, calma, como dizia Murphy: “Não há nada tão ruim que não possa piorar”.

No seu primeiro dia de trabalho, seu chefe lhe dará uma tarefa:

- Severino (esse é você), vamos iniciar o desenvolvimento do Sistema de Pagamento de Pessoal. A equipe é composta por todos os integrantes da Seção de Desenvolvimento de Sistemas, ou seja, somente você. Tudo bem?

É óóóóóóóbvio que você vai responder:

- Tudo bem, chefe. Estou aqui para desafios!

Detalhe, você nunca ouviu falar naquelas milhões de siglas que tangem a área de Pagamento de Pessoal, sem falar nos cálculos, consolidações, análises etc. Isso envolve pesquisa, seleção, construção, refinamento… Tranquilo, você sabe disso, mas seu chefe não. E não tarda para aparecer a pergunta matadora:

- Em quantos dias você me entrega isso?

Pode ter certeza, nessa hora dá vontade de “bater” num camarada desses. Pois bem, é melhor voltarmos à teoria.

Por que é tão difícil estimar?

O trabalho de criação de sistemas é tão complexo quanto o trabalho de criação de qualquer coisa inédita. Alguém, em sua sã consciência, teria a ousadia de perguntar ao Thomas Edison:

- Ei, Edison, em quantos dias você inventa a lâmpada?

Não há como medir a velocidade de criação de uma pessoa. Esse é um evento espontâneo que varia de pessoa para pessoa. Não existe regra, é o acaso que determina isso.

Por isso é tão difícil para qualquer técnica precisar, com eficiência, o prazo de criação de um sistema. Por mais que você envolva as melhores práticas de gerência de projetos, que você reduza os impactos dos riscos, que você derrube barreiras que geram atrasos, você vai acabar caindo na técnica do CHUTE, para emitir qualquer estimativa.

Segundo mito desvendado, a única técnica para mensurar o tempo de desenvolvimento de um sistema é o chute. Eu acho.

Bem, agora você deve estar achando que fiquei louco e estou falando abobrinha. Vamos ver se isso confere.

Se você é do tipo “Gerente de Projetos”, você deve estar falando: “Eu uso PERT (Análise de três pontos) e, geralmente, acerto meu cronograma”. Primeiro, acerta o cronograma um @#$%*… Você mexe no cronograma todo dia e a data de término é sempre mais longa. Segundo, o PERT usa a análise de três chutes: o prazo quando tudo dá errado, o mais provável e quando tudo dá certo. Daí se aplica um cálculo, alguma medida de dispersão, como: média ponderada, aritimética, desvio-padrão etc., e se chega a um valor que será usado para todas as atividades do projeto. Certo, é um chute calculado, mas não deixa de ser um chute.

O pessoal do XP (Extreme Programming) nem tem o que reclamar, é o chute da equipe. Então, quanto menor a equipe, maior a chance de erro. Esse é um chute bem às escuras mesmo. Mas quanto mais se treina, mais próximo do acerto estamos.

A galera da APF (Análise de Ponto de Função) se baseia numa tabela para analisar a complexidade de uma funcionalidade e daí aplica um percentual para saber quanto tempo o pessoal do desenvolvimento irá precisar. Olha só o absurdo, se você usa uma entidade com 51 atributos a complexidade é a mesma que se você usasse uma entidade com 151 atributos. Detalhe, a medida é usada para qualquer tipo de projeto. É claro que pode-se usar os Pontos de Função Ajustados, mas, isso ainda não deixa de ser um chute.

Bem, chute por chute, quanto mais simples melhor. XP, estou com vocês, viu?

Enfim, vamos aos finalmentes. E eu já inicio com o terceiro e último mito.

Terceiro mito desvendado, hoje é o seu último prazo, amanhã reavaliaremos a situação.

Já me aconteceu, salvo engano, em 100% dos casos, o último prazo não era o último. Sempre há espaço para mais uns dias de trabalho.

Não adianta você passar madrugadas em claro, sair correndo de casa, acelerar tudo que seu carro pode oferecer de potência para chegar mais cedo ao trabalho e adiantar aquele trabalho hiper-atrasado. Não precisa disso. Os prazos não são compromissos escritos em pedra. Eles mudam.

Geralmente, prazos para desenvolvimento de sistemas são negociados. Você é cobrado por prazos incumpríveis simplesmente para satisfazer o ego de alguém (chefes?). Neste caso, é a confiança que está em jogo.

Seu chefe prometeu algo para alguém e você é quem deve cumprir. Mas você não foi consultado disso. Normal, chefes adoram fazer isso. Seu chefe cobra que você entregue no prazo estipulado por ele, simplesmente, para que a confiança nele seja mantida perante os clientes. Mal sabe ele que, se entregar algo no prazo, isso, apesar de soar bem, é ruim para a equipe. Pois vão acreditar que, se você se esforçar um pouco mais, poderá entregar antes. E aí, meu querido, ninguém lembra que você dormiu 4 horas e levou duas multas de pardal para chegar ao trabalho. Você não está no seu limite, você está além.

Eu considero que há duas situações onde o rigor do prazo correto deva ser aplicado:

1. Quando tem gente morrendo;
2. Quando tem gente perdendo dinheiro.

Se esse não for o seu caso, dê um sorriso bem grande e relaxe! Sempre há uma luz no fim do túnel.

Bom. Nem preciso dizer que concordo com o que o Paulo disse em seu post, né? E você, o que pensa a respeito? Deixe seu comentário.