T-Blog

Armadilhas para desenvolvedores

2012-01-10T17:51:00.001-02:00

Texto Extraído do Active Delphi... Veja só que interessante:

Com o passar do tempo, ficam nítidas para mim algumas situações nas quais desenvolvedores talentosos (ou não) entram e das quais saem completamente idiotas (raríssimas vezes com algum tipo de salvação). Chamo estas situações de “armadilhas para desenvolvedores” e, a partir deste post, pretendo expor algumas das que presenciei ou virei a me deparar a partir de então (sintam-se abertos a me contarem as suas).

A palavra “armadilha” foi selecionada a dedo. Isto porque todas as situações que irei mencionar aqui possuem uma característica em comum: apresentam um ambiente ou objeto aparentemente confortável e desejável que, uma vez penetrado ou obtido, mostra-se incrívelmente cruel.

Armadilha #1: Determinismo linguístico

É o meu pior pesadelo sem sombra de dúvidas. Para aqueles que não o conhecem, o determinismo linguistico consiste na hipótese segundo a qual a nossa percepção do mundo é definida por nossa linguagem. Exemplo clássico: os esquimós. Estes conseguem distinguir n tons diferentes de branco, cada um com seu próprio nome, ao passo que nós, brasileiros, basicamente conseguimos distinguir apenas o branco e o cinza. Em contra-partida, conhecemos n tipos diferentes de bananas (nanica, caturra, serra d’água…), ao passo que um esquimó só consegue distinguir de cara um tipo de banana.

Como isto se aplicaria a um desenvolvedor? Simples: aquele que só utiliza o mesmo ambiente de desenvolvimento/linguagem normalmente tem uma dificuldade monumental em aprender qualquer outro. Exemplo clássico: o pessoal que trabalha com ambientes RAD como Visual Basic ou Delphi (mais específicamente, os amontoadores de componentes (há pessoas absurdamente competentes trabalhando Delphi e VB)). Ao tentarem aprender outra linguagem como Java, por exemplo, a primeira coisa que tentam fazer consiste em aplicar exatamente as mesmas técnicas que utilizavam até então neste novo ambiente. Resultado: fracasso total. É possível diagnosticar alguém que tenha caido nesta armadilha ao ouvir alguma das frases abaixo:

“Linguagem/Ambiente X é um LIXO!”

O sujeito está tentando aplicar técnicas específicas de um ambiente/linguagem em outro. Como não irão funcionar, consequentemente, vê a culpa NO ambiente/linguagem, e não em si mesmo.

“Sou muito mais produtivo na linguagem/ambiente X. Se estivesse trabalhando nele, o trabalho já estaria pronto!”

O problema se torna nítido. O sujeito basicamente confirma que realmente só consegue trabalhar em um ambiente/linguagem.

“Linguagens de programação são todas iguais. Só varia a sintaxe…”

Aham… Se fosse verdade, só existiria UMA linguagem de programação (a que o sujeito conhece, provávelmente)

Um aspecto interessante de quem caiu nesta armadilha consiste em uma certa arrogância. Culpam a linguagem/ambiente por todos os problemas que estão enfrentando e se esquecem de que o mesmo ambiente/linguagem foi utilizado com sucesso incontáveis vezes em projetos do mesmo ou maior porte do que aquele no qual o indivíduo se encontra em dificuldades.

Na realidade, o determinismo linguístico fica exposto ao perceber o modo como o sujeito inicia sua produção no novo ambiente. Muitas vezes nem sequer chega a estudá-lo direito. Simplesmente cata a primeira IDE que encontra e começa a trabalhar exatamente como fazia no ambiente/linguagem com o qual estava habituado.

Armadilha #2: software = banco de dados relacional

O sujeito não acredita que exista desenvolvimento além do CRUD. Como detectar alguém que tenha caido nesta armadilha? Simples: mencione qualquer tipo de estrutura de dados diferente de tabela ou índice. Se disser que conhece, vá além: peça para que lhe descreva o funcionamento (alerta: criará inimigos com isto). Ou, pior ainda, pergunte ao indivíduo se ele consegue programar algo sem um banco de dados relacional por trás.

O que ocorre nesta situação: o sujeito trabalha em um ambiente no qual a esmagadora maioria das demandas consista apenas na criação de aplicações que armazenem e busquem informações presentes em bancos de dados (apenas CRUD). No máximo, um relatório ou outro mais complexo, envolvendo somatórios e agrupamentos. O que se percebe é a armadilha #1, ou seja, o determinismo linguístico. A diferença é que este é O caso mais comum da armadilha E o que também causa os maiores prejuízos.

Como o resultado de uma consulta SQL é imediato, o sujeito acredita que seu trabalho terminou na criação dos formulários de exposição e cadastro. No entanto, a partir do momento em que o problema se tornar mais complexo a coisa muda de figura.

O mais fascinante desta armadilha consiste no fato da vítima conseguir fazer coisas incríveis com SQL, porém falhar miserávelmente quando precisar de qualquer coisa que vá além desta.

Neste caso, no entanto, há uma bomba relógio ativada: está provado que os SGBDs relacionais não escalam bem em ambientes paralelizados (mais sobre isto aqui, aqui e aqui(terceiro link particularmente interessante, por apresentar o CouchDB)). Como o número de processadores por computdor está aumentando, e o clock de cada um destes tende a diminuir e cloud computing está crescendo MUITO, veremos problemas imensos de performance nos próximos anos cuja origem se encontra justamente neste tipo de profissional que acredita no mito de que uma aplicação é composta por um banco de dados relacional apenas.

Este tipo de indivíduo se esquece de algo básico: os dados são o resultado de um processamento, e não o contrário!

Armadilha #3: ambientes de desenvolvimento RAD

O sujeito aprende a programar em um ambiente RAD e se atém a este. O utiliza para criar um CRUD simples, sempre utilizando a mesma linguagem (99% das vezes VB, Delphi e Visual Studio). Resultado: armadilhas #1 e #2 engatilhadas com um agravante: a ilusão de que desenvolvimento de sistemas é uma tarefa simples.

Não tenho nada contra estes ambientes (sendo assim, por favor, não me ataquem), porém tenho contra o seu mal uso. O maior problema aqui ocorre quando se esquece que um ambiente como VB ou Delphi deve ser usado apenas para facilitar a execução de tarefas repetitivas e tediosas, como por exemplo a criação de um formulário, e que estas tarefas repetitivas e tediosas são apenas uma PEQUENA parte do processo de desenvolvimento, e não o seu todo.

O que se observa é basicamente o contrário: o indivíduo passa HORAS (ou DIAS) buscando componentes terceirizados para finalizar as tarefas que não envolvam CRUD, os incorporam em seus “sistemas” porcamente e se esquecem de outros elementos que também deveriam estar presentes no processo, como por exemplo segurança, escalabilidade, usabilidade e, mais importante ainda: código de qualidade, que seja fácil de ser mantido e compreendido.

Quer detectar alguém com este problema? Simples: remova deste indivíduo a sua IDE.

Armadilha #4: português é seu único idioma

Parece impensável, mas a quantidade de “programadores” que ignora completamente o inglês é alarmante. Como consequencia, tem de se virar apenas com o que existe publicado em português. Dado que a qualidade é muito inferior à que é produzida no exterior, o sujeito acaba se tornando limitado com o passar do tempo.

Claro, as coisas estão melhorando aqui no Brasil, porém, por mais que melhorem, difícilmente se igualarão à publicação atualmente produzida em inglês. Mesmo porque até os países no qual o inglês não é o idioma oficial costumam publicar conteúdo para nossa área em… inglês.

Armadilha #5: preguiça de ler

O sujeito acredita que não precisa ler para se tornar um bom profissional. Resultado? Programadores analfabetos. Já escrevi sobre isto aqui, sendo assim, não irei me alongar muito sobre o assunto.

Armadilha #6: medo da mudança

O indivíduo pira a cada mudança que ocorre em seu ambiente de trabalho. Mudou um pouco a especificação? Boom! Crise, o sujeito pensa em pular do último andar do prédio em que trabalha. Chamo este tipo de profissional de “desenvolvedor autista”.

O desenvolvedor autista não consegue ver que a mudança é a principal razão pela qual recebe seu dinheiro todo mês. Que se estas cessarem, seu trabalho automaticamente torna-se desnecessário e, pior ainda, nega o básico da realidade: tudo muda. No século V a.C Heráclito já dizia: panta rei (tudo muda). Se as coisas mudam na natureza, por que não muariam no seu trabalho? Será possível que 2500 anos depois, as pessoas ainda não conseguem aceitar este fato???

A origem do problema consiste na crença de que o desenvolvimento de sistemas é uma ciência exata. Noção esta completamente equivocada, se levarmos em consideração o fato de que nosso trabalho consiste em modelar no ambiente digital um problema que ocorre no mundo físico. Problema este que normalmente é criado por seres humanos que, como todos sabemos (com excessão do desenvolvedor altista), mudam de opinião o tempo inteiro!

Como identificar alguém com este problema? Varia do nível: nos casos extremos, basta mudar a posição do seu mouse.

Conclusão

Estas são as principais armadilhas que já presenciei. Após analisá-las, alguém poderia me fazer alguns questionamentos, como os a seguir:

Por que não foram mencionadas armadilhas de gerenciamento?

Simples: por que se alguém quer gerenciar uma equipe de desenvolvimento, você tem de saber o que está gerenciando, ou seja: tem de pelo menos uma vez na vida ter programado ou pelo menos tentado. Caso não tenha se mostrado um bom programador, ao menos deveria saber como reconhecer um.

Como eu evito estas armadilhas?

Basicamente evitando a primeira, ou seja, reconhecendo a diversidade e o fato de que desenvolvimento de sistemas é uma atividade complexa, que requer estudo constante e que poucos conseguem levá-la a cabo com sucesso, ou seja: diminuindo a arrogância.

O artigo original veio do site abaixo,

http://www.itexto.net/devkico/?p=292

Os 7 passos do gerenciamento de projetos

2012-01-10T17:48:00.000-02:00

O enxugamento dos quadros de pessoal e o aumento da necessidade de especialização técnica têm levado muitas empresas a recrutar no mercado profissionais por período determinado apenas para a execução de projetos específicos. Neste contexto, entender o processo de gerenciamento de projeto tem se tornado vital para organizações a medida em que mais e mais novos negócios vão se revestindo da aura de projeto e passam a exigir um cabedal de técnicas gerenciais que nem sempre estão disponíveis nas empresas.

Um projeto é um empreendimento temporário, com data de início e fim, cujo objetivo é criar ou aperfeiçoar um produto ou serviço. Gerenciar um projeto é atuar de forma a atingir os objetivos propostos dentro de parâmetros de qualidade determinados, obedecendo a um planejamento prévio de prazos (cronograma) e custos (orçamento). Ou seja, dadas as metas e as restrições de recursos e tempo, cabe ao gerente de projetos garantir que ele atinja os objetivos propostos.

Muitas empresas estão adotando a estrutura de projetos no seu dia-a-dia. Desde a concepção de um novo software até a implantação dos procedimentos de atendimento a clientes, desde a construção de uma ponte até a revisão dos processos de venda com vistas a aumentar a taxa de fechamento de negócios, muitos empreendimentos no seio das organizações se enquadram na classe de projetos. Nos mais diversos setores, a abordagem de gerenciamento de projetos está ganhando terreno por permitir um melhor uso dos recursos para se atingir objetivos bem definidos pela organização. Sabendo da importância de se gerenciar bem um projeto, vamos ver os passos que nos levam a melhorar nossas habilidades de gerenciamento de projeto.

Tudo começa com a contratação de uma empresa para tocar o projeto ou a definição dos colaboradores internos que integrarão a equipe de projeto. Num dia determinado, inicia-se o projeto. Este momento deve ser formalizado com um documento que se chama de “termo de início do projeto”. Em projetos maiores, deve ser um documento assinado pelos patrocinadores e pelo gerente do projeto. Para projetos menores, pode ser um e-mail que o gerente envia aos patrocinadores, copiando os demais envolvidos, para notificar que naquele momento se inicia o projeto e todos estão envolvidos com a sua execução.

1. Escolha e adote uma metodologia

Uma metodologia é um processo a seguir que dá maior controle sobre os recursos que serão utilizados no projeto. Controlando melhor o processo a equipe será mais eficiente pois entregará o projeto com maior grau de acerto em termos de prazos e custos. O bom uso de uma metodologia é importante porque permite evitar práticas que levam ao insucesso e com isso reproduzir o sucesso.

A Microsoft usa o MSF (Microsoft Solutions Framework) no desenvolvimento de seus produtos. Muitas empresas na área de software optam pelo CMM (Capability Maturity Model). A opção pela metodologia deve ser tomada a partir de alguns fatores: as exigências de cada mercado em que a empresa atua, a disponibilidade de mão-de-obra e a cultura organizacional necessária para adotá-la. Para exportar software, muitas empresas nacionais têm se alinhado com o padrão CMM para dar credibilidade a sua iniciativa em mercados dominados por indianos e chineses, que já possuem capacitação neste padrão.

Em última instância, uma metodologia é um conjunto de regras de como conduzir um projeto com sucesso. Pode até não ter siglas bonitas, mas é importante que já tenha se mostrado eficiente dentro da sua empresa, de preferência em situação similar à que você está vivendo no seu projeto atual. Para quem gosta de siglas, há uma que está bem na moda: a UML (Unified Modeling Language) que, como já diz o nome, não é uma metodologia mas uma linguagem, uma forma de se documentar um projeto. Uma linguagem de modelagem é uma notação, em geral feita com símbolos gráficos, que se usa para traduzir processos abstratos. A empresa que criou a UML desenvolveu uma metodologia conhecida como RUP, “Rational Unified Process”.

2. Comunique-se: não é só o peixe que morre pela boca!

Quando falta comunicação, os boatos e outras formas de ruídos tomam seu lugar. Na falta de versão oficial, ficam circulando informações que podem minar a moral da equipe e levantar suspeitas sem fundamento. O gerente de projeto deve evitar esse tipo de prática, conhecida por "rádio-peão", dando informações claras e confiáveis sobre o status do projeto. Certamente esta é uma área em que a diplomacia é essencial. Se há um problema, o gerente de projetos pode e deve não só falar sobre ele, mas também informar que está trabalhando na solução, e não apenas comunicar que o problema existe. Problemas sem uma perspectiva de solução são angustiantes e causam um desconforto na equipe que muitas vezes é desnecessário.

A criação de relatórios de progresso do projeto ajuda no processo de comunicação, sobretudo por que torna o processo impessoal e mais objetivo. Imagine o efeito de um email onde se critica um membro da equipe pelo atraso do projeto. Imagine a mesma informação vinda de um relatório em que a data de término real de uma tarefa está em branco: objetivamente a situação é a mesma, o indivíduo não fez a sua parte, mas no caso do email a pessoa envolvida pode se melindrar. No relatório, temos um dado objetivo, que salta aos olhos, mas que não gera ressentimentos.

3. Defina o escopo do projeto e detalhe as atividades

O “escopo do projeto” é o trabalho que deve ser realizado para se obter um produto ou serviço com determinadas características e recursos. Comece por definir o que deve ser feito e o que não deve. Esse processo nos permite entender os contornos do projeto e traçar uma linha divisória entre o que deve ser feito e o que não deve ser, pelo menos neste momento. Muitos novatos se perdem em discussões intermináveis sobre recursos do produto final que o tornariam “perfeito”. Sempre me lembro de um amigo muito experiente que, ante a minha ânsia em acertar todos os detalhes logo de cara, me dizia que “o ótimo é inimigo do bom”, ou seja: enquanto perseguimos o “ótimo” nos distanciamos de algo que está bem mais próximo, o “bom”, é que temos mais chance de conseguir atingir. Com o tempo achei uma forma elegante de contornar as exigências de projeto sem decepcionar os clientes: não é que não faremos o que está sendo pedido, mas devemos ver que este recurso cabe na versão 2, 3, etc... mas não cabe na versão 1, que é o que estamos tentando desenvolver neste momento ! Afaste o fantasma da perfeição.

Para você não se perder numa lista interminável de características da versão 1, uma boa idéia é pedir ao cliente que liste só que o que é “absolutamente essencial”. Claro que se você der a ele 30 minutos para responder, tudo será “absolutamente essencial”. Não adianta, temos de ser realistas, o tempo é curto é temos de escolher só o que realmente é importante. Se “escrever é cortar” como dizem os grandes escritores, a arte de se definir o escopo do projeto passa por saber o que abandonar e o que reter do universo de necessidades do cliente.

Bom, definido o escopo do projeto, podemos passar para a fase de detalhamento das tarefas. O objetivo é chegar ao WBS (Work Breakdown Structure), onde temos as “unidades de trabalho” com tempo medido em dias ou horas de trabalho. Como regra, uma atividade deve ocupar entre 4 e 80 horas, nem mais, nem menos.

Em paralelo, deve ser elaborado um orçamento levando em conta quantas horas de cada profissional serão necessárias. Veja um modelo simples:

Profissional	Tarefa 1	Tarefa 2	Tarefa 3	T.Total (h)	Custo/h	Custo
Gerente de projeto	20	0	3	23	150,00	3.450,00
Líder de projeto	10	3	2	15	80,00	1.200,00
Analista Sênior	20	0	0	20	50,00	1.000,00
Programador	0	40	20	60	30,00	1.800,00
Testador/Documentador	0	20	30	50	15,00	750,00
Total	-	-	-	168	-	8.200,00

Para montar este modelo, você precisa saber o custo-hora de cada profissional e estimar o tempo que cada um gastará no projeto. Os profissionais podem estar envolvidos em outros projetos e quando o programador está cuidando de uma fase do projeto A, o gerente de projeto já pode estar planejando o projeto B, só voltando ao projeto A quando for para entregar ao cliente e obter a sua aprovação, sobre o que falaremos mais adiante.

Estas estimativas são mais precisas à medida em que se avança no detalhamento do projeto. Para estimativas iniciais, admite-se uma variação de -25% a +75%. Na fase de planejamento, o orçamento deve ter uma variação de -10% a +25%. Lembre-se que nesta fase, o gerente de projeto já envolveu quem realizará a tarefa. Na estimativa final, a margem de erro é menor: de -5% a +10%. Aqui, o conhecimento do gerente de projeto de situações anteriores fará diferença. Eu, por exemplo, sei que quando lido com determinados clientes, haverá tanto “overhead” administrativo, como dezenas de reports para cima e para baixo antes que cada passo importante seja dado, que eu já estimo 50% a mais do tempo nas tarefas em que o cliente está diretamente envolvido. Vai da experiência do gerente, mas nessa hora, se a empresa têm um histórico de projetos semelhantes, vale a pena se basear neste background, mesmo que tenha sido com outras equipes e outros gerentes de projeto.

Um dos grandes segredos do gerenciamento de projetos é proteger o seu escopo. Projetos que ficam mudando o escopo durante sua execução têm sérias dificuldades em cumprir o cronograma e estouram o orçamento. O risco mais comum é o que se chama de “scope creep”, quando o escopo vai crescendo a medida que o cliente vai entendendo suas necessidades e reformulando seus objetivos. Há quem chame este problema de “Jacques”. Seria uma homenagem a um francês ilustre ? Não, trata-se apenas da forma como o cliente costuma abordar o assunto: “já que o sistema faz isso, ele pode então fazer aquilo. Agora eu quero aquilo também incorporado ao projeto.” O gerente do projeto deve ter calma e analisar com cuidado cada demanda: ao rejeitar um pedido, ele pode se indispor com o cliente, mas se aceitar ele pode estar dando um tiro no próprio pé, já que o prazo e orçamento não serão tão “elásticos” quanto as exigências. Devemos sempre contar com uma certa “margem de manobra”, mas nos tempos atuais, em que eficiência é a palavra que está na ordem do dia, não há muita “gordura para queimar” e os compromissos assumidos pelo gerente podem se transformar num sacrifício, muitas vezes desnecessário, para toda a equipe.

Em projetos de software, o “scope creep” é uma situação tão comum que não dá para começá-los sem tomar algumas precauções. O primeiro cuidado é negociar a forma de remuneração: fixa ou variável. Se for fixa, o risco das mudanças está toda com o gerente do projeto, se for variável, o cliente assume os custos extras. Mesmo neste caso, o gerente do projeto deve cuidar para que o cliente seja informado a priori dos novos custos. Por precaução, eu sempre redijo um adendo ao escopo colocando o que será feito, em quanto tempo e a que custo. Colho a assinatura do cliente e só depois autorizo a execução da tarefa. Gerentes financeiros não participam destas reuniões e podem alegar que não há previsão de recursos para os extras, então mantenha-os informados das novas condições para evitar dissabores na hora do recebimento.

O segundo cuidado é documentar meticulosamente o escopo do projeto. Este documento resume o que será feito, com que características e com que recursos. Ele é um “quase-contrato” mas não traz as cláusulas de rescisão e as penalidades. Neste momento, tudo está bem e todos concordam. Só que, na cabeça de cada um, há uma imagem diferente do que será o produto final. Á medida que este produto vai tomando forma e sendo entregue, o cliente vai vendo que o que ele imaginou “não é bem aquilo” e podem começar as decepções.

A satisfação do cliente depende em muito do que será dito e prometido no que se chama de “pré-venda”. É neste momento que o gerente de projetos deve entrar em cena para meticulosa, cuidadosa e disciplinadamente escrever tudo o que o sistema deve ter e fazer. Este processo é o “planejamento de escopo” e num software dele abrange das telas até os relatórios. Esta tarefa pode ser delegada para um analista, mas a responsabilidade não sai nunca das mãos do gerente. Eu costumo especificar toda a interface dos usuários com o sistema: telas e relatórios. Depois de “colocar tudo no papel”, o gerente deve obter do cliente um “de acordo”, de preferência assinado no final do documento em que todas as páginas serão rubricadas com um “visto” para que ele tome ciência do que será feito. Não há palavras para expressar a importância deste planejamento em que as expectativas serão levantadas e moldadas, de forma que, diante do produto final, o cliente não possa se dizer decepcionado.

O terceiro cuidado é definir prioridades. O gerente deve ter a sensibilidade para identificar quais são os requisitos obrigatórios e quais os desejáveis, marcando cada um segundo com a sua prioridade. Isso evita que alguém arbitre o que é importante no lugar do cliente. Há gerentes de projeto que vão mais longe e pedem ao cliente para definir o que ele considera “sucesso” do projeto. Por exemplo, num sistema em que havia desperdício de 30% da matéria-prima, foi considerado sucesso reduzir esta taxa para 15%. Mas este número ainda é alto, diria você. Sim, mas o cliente considerou que uma redução de 50% dos desperdícios já representaria benefícios suficientes que compensariam os investimentos no projeto. Além do mais, lembre-se de que: “o ótimo é inimigo do bom”.

Em suma: definir o escopo, no fundo, é saber o que deve ser feito para atender a necessidade do cliente.

4. Conheça os envolvidos e monte seu time

Todos os envolvidos no projeto são os "stakeholders". Nesse grupo estão não apenas os membros da equipe, mas também os clientes e fornecedores envolvidos. Dentro da empresa do cliente, há uma pessoa que se destaca por ser a patrocinadora ("sponsor") do projeto. Ela é que cria as condições para a contratação do projeto, mesmo que não seja ela que vá usar o produto final.

É importante que o gerente do projeto conheça os interesses de todos os envolvidos. Imagine como é arriscado contar com um membro da equipe que não está disposto a colaborar. Ele pode ser um problema mais do que uma solução dentro do grupo: sabendo disso, melhor pensar em chamar outra pessoa. Eu passei por uma situação destas quando fui destacado para gerenciar um projeto onde havia um colaborador mais antigo e que entendia que ele é quem deveria estar gerenciando. Eu não percebi seu ressentimento a princípio e à medida que o projeto avançava esta pessoa se tornava um problema cada vez maior, na medida em que, não só ele não fazia a sua parte, como minava os demais membros da equipe contra minhas decisões. Um dia, eu o chamei e abri o jogo. Ele então me explicou o que estava sentindo e fizemos um acordo: ele se enquadraria para completar o projeto, que graças a ele já estava atrasado, e eu o apoiaria junto à direção para que recebesse seu próprio projeto para gerenciar. É claro que manter um “profissional” com este tipo de atitude não é bom negócio para a empresa no longo prazo, porque cedo ou tarde ele vai acabar atirando contra a própria equipe novamente, só para mostrar que as “coisas têm de ser feitas do jeito dele”.

No processo de definição do escopo, as habilidades necessárias vão ficando mais claras. Nesse momento, é importante formar uma equipe com competência diversificada e com experiência nas áreas de atuação do projeto. Em projetos em que há muito conhecimento técnico envolvido, surge a figura do "líder de projeto", um profissional com grande conhecimento técnico e com capacidade de liderança entre os técnicos. Em geral é um profissional sênior, com credibilidade junto aos demais técnicos e com muita bagagem. A experiência desse especialista pode economizar muito tempo e dinheiro no projeto. Dê-lhe voz ativa, cobre dele insights que você não tem e respeite a sua opinião. Só assim ele estará sempre do seu lado, mesmo quando você errar.

5. Desenvolva o cronograma junto com quem põe a mão na massa

Uma vez que temos as tarefas definidas a partir do escopo, temos de estimar a duração de cada uma. Procure fazer esta estimativa de tempo de execução com a ajuda de quem está escalado para executar o trabalho. Ao mesmo tempo em que essa pessoa é quem melhor sabe quanto tempo precisará, ela estará se comprometendo com um prazo para a sua execução. Por outro lado, quando se trabalha com consultores externos, o custo será função direta do tempo estimado para a execução do projeto. Ao fixar o cronograma, o profissional está dando por tabela um orçamento da sua parte.

Veja estas atividades que representam as linhas gerais de um projeto de sistema:

Note que além de saber o que deve ser feito, as tarefas têm três propriedades importantes: duração, inter-dependência e responsável. A duração é importante mas se as tarefas podem ser realizadas em paralelo, como é ilustrado neste caso onde há duas figuras: o analista e o programador, a duração total do projeto encurta. Dessa possibilidade de trade-off entre tempo e recursos alocados, alguns gerentes acreditam que se o projeto está atrasado, então “basta colocar mais gente” que o problema se resolve. Isso raramente ajuda uma vez que com mais gente, os problemas de comunicação aumentam e o projeto que já está atrasado atrasa mais ainda. Trazer mais gente pode ser útil quando se precisa de especialistas em temas que os membros não dominem. A rigor, se o planejamento foi bem-feito, já se sabe que esta mão-de-obra será recrutada em algum momento do projeto. A atitude de simplesmente aumentar a equipe para acelerar a produção é que está errada e deve ser combatida. Só que alguns gerentes de projeto medem seu poder pelo tamanho da equipe que gerenciam. Você pode imaginar como isso acaba: contratamos mais pessoas, eu fico mais “poderoso” e temos todas as explicações para os atrasos, afinal o projeto era mesmo “muito grande”.

O gerente de projetos deve trazer sua experiência para corrigir as expectativas muito otimistas de algum colaborador mais afoito. Sim, há quem estime 50 horas e depois, com a maior tranqüilidade, cobre pelas 120 horas que foram necessárias para realizar a tarefa. Ele só errou em 140% ! Se o preço é fechado, o risco fica todo com o consultor, mas a sua boa-vontade e a qualidade do produto final podem sofrer em decorrência da pressa. Se a remuneração ficar vinculada ao tempo de prestação de serviço, o contratante precisa de um mecanismo de controle minimamente confiável. Eu não uso uma fórmula geral, prefiro trabalhar segundo as características do profissional mas de todos exijo um relatório de horas que contém o dia, data de hora e início, tempo de trabalho e a(s) tarefa(s) realizadas no dia.

Se no planejamento da semana há tarefas que não foram realizadas, na reunião de avaliação, eu pergunto porque a coisa não seguiu o ritmo programado e quanto isso impacta na data final de entrega. Procure estabelecer pontos de controle, "check-points", que são datas onde se medirá o andamento do projeto em face do cronograma que havia sido programado. Nestas datas, pode-se estar apenas executando-se uma verificação do progresso das atividades ("milestones") ou pode haver entrega de produtos ou sub-produtos (“deliverables”) tais como desenhos, especificações, protótipos, modelos, etc...

Quem já reformou ou construiu uma casa sabe que esta tão trivial experiência de gerenciamento de projeto pode acabar mal. Quantas histórias existem de gente que foi pagando o pedreiro sem atrelar os pagamentos a entregas de tarefas determinadas. Nestas histórias tristes, o dinheiro acaba antes da obra, e o pedreiro some, deixando o cliente sem dinheiro e sem a sua casa. Tudo porque ele não cuidou de atrelar entregas de tarefas a pagamentos, não criou pontos de controle que lhe dariam visibilidade do atraso. Sabendo antes que a “vaca está indo para o brejo” o cliente pode optar por “apertar” o pedreiro ou suspender os trabalhos enquanto ainda tem dinheiro, que poderá ser usado para pagar uma equipe mais eficiente.

É verdade que em projetos de TI nem sempre dá para “trocar o pedreiro” porque há muito conhecimento e estudo envolvidos. Mas por isso mesmo, temos de ser muito mais cuidadosos na monitoração para saber em que momento o projeto começa a atrasar e como fazer para recuperar o ritmo no futuro próximo.

6. Monitore os riscos e seja pró-ativo

Agora que todos sabem o que devem fazer, é importante mitigar os riscos que podem impedir o bom desenvolvimento do projeto. Desenvolva uma lista de fatores de risco e um plano para lidar com eles. Mas lembre-se de que são duas coisas diferentes: a monitoração do risco e controle do risco.

A monitoração dos riscos envolve acompanhar o status de cada risco e as opções de ações definidas para enfrentá-los, caso eles venham a se tornar problemas reais. A monitoração também se preocupa em avaliar a probabilidade de ocorrência de um risco, qual o seu impacto no andamento do projeto e como contorná-lo. Por exemplo, numa determinada tarefa crítica a contratação de dois profissionais pode parecer um exagero mas o gerente do projeto sabe que se algo acontecer nesta área do projeto o impacto será grande no restante. Os profissionais passam a ser um backup do outro dentro da linha de que “quem tem um, não tem nenhum”.

Voltando ao nosso projeto de exemplo, chamo a atenção para um recurso que o MS Project tem e que deve ser usado para se identificar riscos. Veja a tela do diagrama de Gantt que obtivemos a partir da lista de tarefas que elaboramos acima:

Note que há uma seqüência de tarefas que quando alinhadas compõem o prazo de duração do projeto todo. Destaquei o início e o final só para que você perceba que se trata de uma série de processos que devem ser gerenciados mais de perto uma vez que o atraso em algum deles acarretará o atraso do projeto todo. Por isso é que se chama este de “caminho crítico”. Os riscos que estão embutidos nestas tarefas são os que se deve gerenciar mais de perto, de forma mais pró-ativa.

O controle dos riscos é o processo de executar o plano de ações e divulgar seus relatórios de status. Inclui também possíveis mudanças no plano de riscos, e eventualmente até nos planos do projeto. Essas mudanças são referentes a recursos, funcionalidades ou cronograma.

7. Formalize o início e o encerramento do projeto

O início do projeto é um momento solene. O patrocinador deve formalizar a todos os envolvidos que o projeto está iniciado e o cronômetro está correndo. Muita gente não gosta de se preocupar com isso, mas imagine que haja resistência de setores da empresa que se opõem ao projeto. Sem um documento que atesta que o projeto começou, o gerente pode não conseguir apoio algum. Além disso, este documento funciona como um “cumpra-se” de uma autoridade da empresa: não cabe discutir a ordem, o projeto começou e todos os “arrolados” devem participar.

Outro momento importante é o do encerramento do projeto. É preciso formalizar o final para que fique claro para todos os envolvidos, especialmente para o cliente, que o projeto está concluído e que novas necessidades serão atendidas em um novo projeto. Qualquer extensão ou alteração deverá ser orçada e todo o ciclo se inicia novamente. Com relação à manutenção do sistema entregue, não se pode considerá-lo um projeto na medida em que, a princípio, trata-se de um processo contínuo. O que pode ocorrer é definir-se projetos ao longo da vida útil do sistema com o objetivo de melhorá-lo. Por exemplo, a atualização dos equipamentos eletrônicos (“aviônicos”) de um avião para auxílio ao vôo é um projeto que se distingue da sua manutenção rotineira.

Ao final faz-se também uma reunião de avaliação dos erros e acertos da equipe. Chamadas de reuniões "post-mortem", elas servem para se gerar uma lista de "melhores práticas" contribuindo para a formação de uma base de conhecimento que poderá ser muito útil em projetos futuros. Da minha experiência pessoal, posso dizer que tirei grandes lições quanto às "piores práticas", atitudes e decisões que se mostraram ruins e que devem ser evitadas em projetos futuros.

Conclusão

Acima de tudo, gerenciar projetos é planejar e acompanhar a execução com "um olho no peixe e outro gato". O gerente do projeto deve se manter alerta e flexível com os acontecimentos do dia-a-dia mas deve estar sempre se reportando ao plano inicial para não perder o controle. A principal qualidade do gerente de projeto é saber se comunicar bem com todos. Ele é o ponto focal das informações, nele convergem as informações que ele depois deverá processar e divulgar para todo o restante da equipe.

O segredo é envolver a equipe, cliente e fornecedores de tal forma que todos se sintam diretamente responsáveis pelo sucesso do projeto. Como diz aquele velho ditado caipira, "quando todos empurram na mesma direção, ná há carroça que não saia do atoleiro".

(*) Fernando C. Barbi (fernando@hexxa.com.br)

Fernando é Gerente de Projetos especializado em TI com 18 anos de experiência na área e colaborador da ADVANCE Marketing – empresa de treinamento consultoria em gestão, marketing e vendas (www.advancemarketing.com.br)

Acelere o Chrome com sua placa de vídeo - Navegador pode usar poder extra de processamento

2011-03-20T14:07:00.001-03:00

Com o lançamento do Internet Explorer 9, muito se fala de novos recursos e principalmente do aceleramento de render de páginas da web, mas poucos sabem, que outros navegadores ja tem este recurso bastando para isto, ativa-lo. Vejam o video como fazer a ativação no Google Chrome.

2011-03-18T21:31:00.000-03:00

Esta é uma forma de fixarmos sempre as páginas que mais utilizamos no Google Chrome. Acredito que a maioria das pessoas, assim como eu, abrem o Chrome pelo menos umas 20 vezes por dia, e sempre visualizam os mesmos sites. Então, acabei encontrando este vídeo explicativo no site do Baboo, e resolvi por no Blog para que todos tenham a mesma facilidade, assim como eu tive.

1º Curso Pré Matrimonial

2011-03-18T21:16:00.000-03:00

No Dia 27 de Março (Domingo) das 7:30hs às 12:00hs e das 13:00hs às 17:00hs, estará sendo realizado o 1º Curso Pré Matrimonial da nossa Paróquia de São Joaquim e Sant´Anna. As inscrições deverão ser feitas na Secretária da Igreja com a Alessandra até o dia 21/03/2011.

Tragédia no Japão

2011-03-15T12:39:00.001-03:00

Assim como eu, muitas pessoas devem ter ficado chocado com a tragédia que o Japão passou recentemente, primeiro com o Terremoto, depois com o Tsunami que acabou com a costa japonesa e agora, mais recentemente com os problemas energéticos, mais precisamente com as usinas nucleares.
Por uma curiosidade minha, fiz uma pesquisa no google e para minha surpresa, muitas empresas estão ajudando e de graça o Japão a se recuperar, das mais variadas formas... veja a matéria no Gizmodo Brasil.

Delphi Meeting 2011 - Evento será realizado em diversas cidades

2011-02-04T18:52:00.001-02:00

Delphi Meeting - Evento será realizado em diversas cidades, vejam a matéria abaixo:

http://www.baboo.com.br/conteudo/modelos/Delphi-Meeting-2011_a40948_z345.aspx

Novas lentes de contato "inteligentes" - Lentes monitoram a saúde de diabéticos

2011-02-04T18:48:00.001-02:00

Novas lentes de contato "inteligentes" - Lentes monitoram a saúde de diabéticos

Novos HDs podem ter até 24TB

2010-12-01T00:00:00.002-02:00

Vejam só que matéria Interessante que saiu no site do Babbo...

"A Hitachi, em parceria com a New Energy and Industrial Technology Development Organization (NEDO), Tokyo Institute of Technology e com a Universidade de Kyoto, desenvolveu no Japão uma nova tecnologia para criação de discos rígidos com pratos que possuem até 3.9 Tb por polegada quadrada.

A mídia de alta densidade foi desenvolvida usando uma nova tecnologia que permitirá a criação de HDs de 3.5” com até 24 TB e HDs de 2.5” com até 8 TB de capacidade.

A nova tecnologia será apresentada na próxima semana durante o evento ‘Materials Research Society (MRS) 2010 Fall Meeting and Exhibition’, que será realizado em Boston, nos EUA."

Fonte: Baboo.com.br

Segurança na Internet

2009-11-09T07:24:00.008-02:00

Muitos clientes me perguntam sobre segurança na internet. Visando tentar ajudar não só a mim, mas como a todos que precisam de informações, o CERT lançou uma apostila contendo varias especificações para prevenção, navegação segura, etc. Veja abaixo na integra o que fala o site do CERT e como proceder o Download.

"A partir da versão 3.1 a Cartilha de Segurança para Internet passou a ser editada também como livro. Nesta página você encontra o prefácio do Livro e o arquivo para download.

Prefácio

A Cartilha de Segurança para Internet é um documento com recomendações e dicas sobre como o usuário de Internet deve se comportar para aumentar a sua segurança e se proteger de possíveis ameaças.
Produzido pelo Centro de Estudos, Resposta e Tratamento de Incidentes de Segurança no Brasil -- CERT.br, com o apoio do Comitê Gestor da Internet no Brasil -- CGI.br, o documento apresenta o significado de diversos termos e conceitos utilizados na Internet e fornece uma série de procedimentos que visam melhorar a segurança de um computador.
Nós esperamos que esta Cartilha possa auxiliá-lo não só a compreender as ameaças do ambiente Internet, mas também a manter seu sistema mais seguro. Gostaríamos ainda de lembrar que é muito importante ficar sempre atento ao usar a Internet, pois somente aliando medidas técnicas a boas práticas é possível atingir um nível de segurança que permita o pleno uso da Internet.
Caso você tenha alguma sugestão para este documento ou encontre algum erro, por favor, entre em contato através do endereço .

Equipe do CERT.br
Outubro de 2006"

Vejam abaixo como proceder para baixa-la e também maiores informações.

Estrutura da Cartilha

Este documento conta com oito partes, que dividem o conteúdo em diferentes áreas relacionadas com a segurança da Internet, além de um glossário, um checklist e uma compilação de dicas rápidas.

Parte I: Conceitos de Segurança Apresenta conceitos gerais de segurança de computadores, importantes para o entendimento das partes subseqüentes.
Parte II: Riscos Envolvidos no Uso da Internet e Métodos de Prevenção Aborda diversos riscos envolvidos no uso da Internet e métodos de prevenção, como programas que possibilitam aumentar a segurança de um computador e medidas preventivas no dia-a-dia do uso da Internet.
Parte III: Privacidade Discute questões relacionadas à privacidade do usuário ao utilizar a Internet e aos cuidados que ele deve ter com seus dados pessoais.
Parte IV: Fraudes na Internet São abordadas questões relacionadas a fraudes na Internet e medidas preventivas que devem ser adotadas no acesso a sites de comércio eletrônico ou Internet Banking.
Parte V: Redes de Banda Larga e Redes Sem Fio (Wireless) É dedicada aos usuários de conexões banda larga e de redes sem fio, sendo discutidas as implicações de segurança e métodos de prevenção peculiares a estes ambientes.
Parte VI: Spam São discutidos os problemas acarretados pelo spam, principalmente aqueles que possam ter implicações de segurança, e métodos de prevenção.
Parte VII: Incidentes de Segurança e Uso Abusivo da Rede Trata dos conceitos relacionados a incidentes de segurança, técnicas de detecção e recomendações sobre como proceder para notificar ataques recebidos via Internet.
Parte VIII: Códigos Maliciosos (Malware) Agrupa informações detalhadas sobre os tipos mais comuns de códigos maliciosos que podem infectar os computadores dos usuários, dando ênfase no tipo de ameaça que cada código oferece e quais são as medidas de prevenção específicas para cada caso.
Glossário: Apresenta definições de diversos termos usados na Cartilha.
Checklist: Consiste em um resumo das boas práticas discutidas ao longo da Cartilha e que devem ser adotadas pelos usuários para se previnirem das ameaças discutidas. Pode ser usado como um guia rápido para conferir se as boas práticas estão sendo seguidas.
Dicas: Compilação de dicas básicas de segurança, que reúnem formas de prevenção contra os problemas mais freqüentes enfrentados pelos usuários de Internet.

Outros Formatos

A Cartilha de Segurança para Internet é um documento público e gratuito, disponível no site http://cartilha.cert.br/, em diversos formatos:

arquivo PDF deste livro;
arquivos PDF de cada uma das partes, do glossário e do checklist;
dois folders de dicas:
em frente e verso (dobrável);
em tamanho A4;
versão em HTML de todo o conteúdo.

Licença de Uso da Cartilha

Este documento é Copyright ©2000--2006 CERT.br. Ele pode ser livremente distribuído desde que sejam respeitadas as seguintes condições:
É permitido fazer e distribuir gratuitamente cópias impressas inalteradas deste documento, acompanhado desta Licença de Uso e de instruções de como obtê-lo através da Internet.
É permitido fazer links para a página http://cartilha.cert.br/, ou para páginas dentro deste site que contenham partes específicas da Cartilha.
Para reprodução do documento, completo ou em partes, como parte de site ou de outro tipo de material, deve ser assinado um Termo de Licença de Uso, e a autoria deve ser citada da seguinte forma: "Texto extraído da Cartilha de Segurança para Internet, desenvolvida pelo CERT.br, mantido pelo NIC.br, com inteiro teor em http://cartilha.cert.br/."
É vedada a exibição ou a distribuição total ou parcial de versões modificadas deste documento, a produção de material derivado sem expressa autorização do CERT.br, bem como a comercialização no todo ou em parte de cópias do referido documento.
Informações sobre o Termo de Licença de Uso podem ser solicitadas para . Embora todos os cuidados tenham sido tomados na preparação deste documento, o CERT.br não garante a correção absoluta das informações nele contidas, nem se responsabiliza por eventuais conseqüências que possam advir do seu uso.

Histórico da Cartilha

No início de 2000, um grupo de estudos que, entre outros, envolveu a Abranet e o CERT.br (que à época chamava-se NBSO -- NIC BR Security Office), identificou a necessidade de um guia com informações sobre segurança que pudesse ser usado como referência pelos diversos setores usuários de Internet. Como conseqüência, a pedido do Comitê Gestor da Internet no Brasil e sob supervisão do CERT.br, em julho do mesmo ano foi lançada a Cartilha de Segurança para Internet Versão 1.0.
Em 2003 foi verificada a necessidade de uma revisão geral do documento, que não só incluísse novos tópicos, mas que também facilitasse sua leitura e a localização de assuntos específicos. Neste processo de revisão a Cartilha foi completamente reescrita, dando origem à versão 2.0. Esta versão, a primeira totalmente sob responsabilidade do CERT.br, consolidou o formato e a base de conteúdo que até hoje compõem o documento, trazendo a divisão em partes, o checklist e o glossário. Também nesta versão foram introduzidas as seções relativas a fraudes na Internet, banda larga, redes sem fio, spam e incidentes de segurança.
Na versão 3.0, de 2005, a Cartilha continuou com sua estrutura, mas, devido à evolução da tecnologia, novos assuntos foram incluídos. Foi criada uma parte específica sobre códigos maliciosos, expandida a parte sobre segurança de redes sem fio e incluídos tópicos específicos sobre segurança em dispositivos móveis, como telefones celulares e computadores de mão. Esta versão também foi a primeira a disponibilizar um folheto com as dicas básicas para proteção contra as ameaças mais comuns.
A versão 3.1 não introduziu partes novas, mas incorporou diversas sugestões de melhoria recebidas, corrigiu alguns erros de digitação e atendeu a um pedido de muitos leitores: lançá-la em formato de livro, para facilitar a leitura e a impressão do conteúdo completo.

Inicio do Horário de Verão como proceder

2009-10-14T17:00:00.005-03:00

Os softwares Tagra Sound e Tagra Image são bem simples em seu manuzeio quanto ao Horário de Verão. Basta você realizar a programação normal do dia 18 e nada mais é necessário. O próprio software se encarrega de fazer as modificações necessárias e carregar as programações corretas.

Rádio Cidade AM 890Mhz de Matão

2009-10-10T09:10:00.003-03:00

É com grande satisfação que a Rádio Cidade AM de Matão, agora também é um cliente da Tagra Software, ficamos 2 semanas implantando e convertendo os arquivos necessários para a sua devida implantação e treinamento.

Gostaria de salientar o grande apoio do Sr. Max, pelo apoio e indicação da Tagra Software como automação de emissoras de rádio.

Em breve, teremos fotos da emissora. Aguardem !

Horário de Verão

2009-10-06T10:42:00.001-03:00

No ano passado o governo fez algo muito benéfico para todos nós: definiu uma data de início e término do tão "estimado" horário de verão. Segundo o Decreto nº 6.558/08, fica estipulado que o horário de verão se inicia a zero hora do terceiro domingo do mês de outubro, e se encerra a zero hora do terceiro domingo de fevereiro do ano seguinte. Em 2009, o horário de verão então, irá começar no dia 18 de Outubro e se encerrará no dia 21 de fevereiro de 2010.

Para certificar-se de que seu Windows fará a mudança numa boa, a Microsoft Brasil publicou uma página de ajuda relacionada ao tema. Basicamente, instale a atualização referenciada no artigo do KB970653, disponível para os Windows XP, Vista, Server 2003 e Server 2008. Ele afeta não apenas o horário de verão brasileiro, mas também o de diversos países, e pode já estar instalado em seu PC, já que a Microsoft liberou esse hotfix nas atualizações do Windows Update de agosto - em dezembro sai o que voltará o horário ao "normal", em fevereiro de 2010.

Para ajudar na mudança, principalmente em ambiente corporativo, a Microsoft Brasil conta com webcasts dedicadas ao tema, com um bloco de 15 minutos mostrando como realizar as alterações necessárias, e outro de 45 minutos para perguntas e respostas. A primeira já aconteceu, no dia 2 de outubro; a segunda está agendada para 16 de outubro. Maiores informações podem ser obtidas através do suporte, inclusive via telefone: (11) 4706-0900 para São Paulo capital e região metropolitana, e 0800 761 7454 para as demais regiões do Brasil.

Maiores informações sobre como proceder com a programação das emissoras, será feito em uma publicação mais para a frente.

Fonte: http://blogs.msdn.com/winbr/archive/2009/10/06/hor-rio-de-ver-o-do-brasil-2009-2010.aspx.

Teclas Virtuais no Delphi

2008-06-15T10:50:00.007-03:00

Bom, sei que isto não é novidade para ninguem e que existem varias ferramentas no mercado que fornecem esta informação, mas você assim como eu, já deve ter perdido horas para conseguir achar a famosa tecla virtual no Delphi, aquelas VK_(alguma coisa), bom achei esta dica no site about.com e estou postando.

UPDATE: Também achei este Blog do Alexandre José na qual ele também traduziu, fica aqui registrado.