Tag: gerenciamento de projetos

Os 10 erros clássicos do desenvolvimento de software

16/10/2013 Processos Deixe um comentário

Com certeza você já se deparou com alguns erros clássicos do desenvolvimento de software. Infelizmente, por diversos motivos, as empresas e os engenheiros de software tem repetidamente falhado em seus projetos por não aprenderem com seus próprios erros. Que tal refletirmos sobre nossos maiores erros para, de alguma forma, evitar repeti-los?

Steve McConnell, um profissional experiente e autor de diversos livros e artigos sobre Engenharia Software, identifica em seu artigo Classic Mistakes os erros mais que ocorrem mais frequentemente. Abaixo, vamos analisar os 10 erros clássicos em projetos de software apontados pelo autor, acrescidos de alguns comentários:

10. Motivação

A motivação tem enorme impacto na produtividade e na qualidade, mas são poucos que adotam práticas efetivas para motivar as pessoas.

Salário não é o único nem o principal fator motivador, pois as pessoas tendem a se acostumar com o que ganham não importa o quanto seja. Programadores gostam de trabalhar com novidades tecnológicas, mas a excitação não dura tanto quanto gostaríamos, principalmente em projetos longos. Não existe uma fórmula mágica, o segredo é investir constantemente nas pessoas, financeiramente ou não.

Colegas mais experientes já me disseram que a motivação correta é um fator chave para o sucesso de um negócio.

9. Pessoas problemáticas

Não lidar com pessoas problemáticas, seja qual for o motivo, afeta a motivação de todos os envolvidos.

Soube de um gerente que teve problemas com o melhor desenvolvedor da equipe. Ninguém sabia se era inveja ou simplesmente o comportamento “normal” dele. Esse desenvolvedor constantemente gritava para toda a empresa ouvir a cada pequeno erro que seus colegas cometiam (como um erro de Português num e-mail), agredia verbalmente os outros desenvolvedores quando considerava suas dúvidas simples demais e interrompia deseducadamente seu gerente em reuniões com clientes e com a administração da empresa. O mal-estar foi generalizado e, embora ele fosse um desenvolvedor tecnicamente excelente, toda a equipe foi afetada negativamente.

8. Barulho

Lugares tumultuados e cheios de gente atrapalham muito a produtividade.

No livro Peopleware, o autor nos apresenta um exemplo de uma fábrica onde avisos eram feitos através de um sistema de auto-falantes, similar ao que ocorre em terminais, aeroportos e grandes lojas. Primeiro toca-se uma espécie de campainha e em seguida alguém fala. Todos os funcionários param o que estão fazendo para prestar atenção ao aviso, perdendo a concentração e levando algum tempo até retomar a produtividade anterior. Na maioria das vezes os avisos eram do tipo “fulano, favor comparecer ao…” e direcionados a apenas uma pessoa.

7. Abandonar o planejamento sob pressão

O cronograma ficou para trás e pressões surgem de todos os lados. A primeira reação é “sair correndo atrás do prejuízo”. Jogamos fora todo o planejamento (processo, testes, etc.) e tentamos entregar as funcionalidades como for possível, resultado num caos infinito de “codifica e arruma” (tentativa e erro).

6. Ignorar as atividades básicas de planejamento

“Pular” direto para a codificação aumenta de 10 a 100 vezes o custo de corrigir o código mal feito.

Não queira ser mais ágil que os métodos ágeis, pois até no agile em geral existe um plano detalhado da iteração (uma ou duas semanas, por exemplo) e um planejamento em alto nível até um certo horizonte do projeto.

Evite fazer em sua mente uma associação do ato de planejar com preencher documentos sem sentido. Planejar é pensar antecipadamente. Refletir sobre um problema antes de colocar a mão na massa irá evitar diversos tropeços.

5. Falta de controle de mudanças

Em média, os requisitos mudam 25% desde a fase de “requisitos definidos” até a primeira versão do sistema. Isso causa um aumento superior a 25% no cronograma. Portanto é necessário controlar as mudanças nos requisitos para limitar mudanças desnecessárias.

Controlar mudanças não consiste em limitar a adequação dos requisitos nem deixar de responder às mudanças em regras de negócio, como alguém pode pensar. O problema é que, se não houver controle, a tendência será um loop de alterações, muitas das quais serão feitas diversas vezes (por exemplo: aumenta fonte, diminui fonte, altera descrição, volta descrição anterior).

4. Síndrome da “bala de prata”

Quando as pessoas focam numa única ferramenta, tecnologia ou metodologia esperando que esta seja a solução para tudo, geralmente ocorre o contrário, a produtividade cai com o tempo.

Trabalhei na migração de um sistema feito na ferramenta chamada Genexus. É uma linguagem de quarta geração, tipo um Access um pouco mais evoluído, que se propõe a gerar telas e cadastros. Não vou entrar no mérito se é possível criar uma arquitetura adequada nessa ferramenta, mas no caso que conheço, apesar de ser muito mais fácil criar cadastros e telas do que em Java, com o tempo o código procedural do Genexus ficou tão complexo que alguns bugs simplesmente não podem ser corrigidos.

3. Informações insuficientes dos usuários

Uma pesquisa realizada em 1994 demonstrou que esta é a causa número um de fracassos em projetos de software.

Não adianta construir perfeitamente a coisa errada. Como engenheiros de software, e não como digitadores de código, nós temos a responsabilidade de compreender o suficiente sobre o domínio da aplicação para traduzir corretamente as necessidades de negócio em um sistema de software.

2. Cronogramas muito apertados

A mesma pesquisa também mostrou que a média de atraso dos projetos é de 220%, causados por cronogramas “agressivos”.

Ao permitirmos que a correria tome conta, as atividades que pensamos poder ignorar no princípio acabam sendo feitas com custo até 100 vezes maior em fases posteriores no projeto.

Além disso, a produtividade das pessoas cai devido à pressão. Alguns gerentes podem discordar, principalmente se estão acostumados a lidar com pessoas preguiçosas. Entretanto, os bons desenvolvedores não irão simplesmente produzir mais de uma hora para outra. Ao contrário, eles já dão o melhor e com a pressão passarão a cometer mais erros.

1. Adicionar mais desenvolvedores

Segundo o autor, este é o engano mais comum. A verdade é que, salvo raras exceções, adicionar pessoas à equipe vai gerar mais trabalho para as que já estavam no projeto, pois elas terão que parar a todo momento para explicar detalhes para os novos desenvolvedores. Dificilmente os novatos alcançarão um nível de produtividade recompensador no tempo esperado.

engenharia de software gerenciamento de projetos

Entendendo o Triângulo de Ferro, porque não podemos ter tudo

30/09/2013 Assuntos Randômicos 1 Comentário

A maioria dos projetos atrasa, estoura o orçamento e ainda fica aquém do esperado. Em geral damos um jeitinho de contornar essas situações, mas sempre há um preço a ser pago: trabalhar até mais tarde, diminuir a qualidade, perder a reputação e a confiança do cliente.

Existem diversas fontes de problemas que afetam um projeto de software, desde a negociação até a entrega. Porém, acredito que a maior contribuição para o constante fracasso do planejamento é oriunda de uma negação interior, lá no fundo, do fato de que…

Não podemos ter tudo

O grande desejo de todo administrador é produzir com o mínimo de recursos, no menor tempo possível, o produto com maior valor e qualidade do mercado. Mas não é assim que as coisas funcionam. Algo deve ser sacrificado.

Irei enfatizar essa verdade, de que não podemos ter tudo, com algumas analogias corriqueiras, pois é um paradigma para todas as esferas da vida. Quando usamos ingredientes baratos e de baixa qualidade em nossa alimentação, aliviamos o bolso mas a saúde vai de mal a pior. Se economizamos no material de construção, logo teremos goteiras e infiltrações. Se contratamos o buffet mais “econômico” para o casamento, os convidados irão, no mínimo, sair reclamando de fome e, no pior caso, acabar no hospital com intoxicação alimentar. Quando aplicarmos esse princípio conscientemente em nosso trabalho teremos menos dificuldades em entender nossos fracassos.

Se montarmos uma equipe somente com programadores juniors, podemos esperar qualidade? Se temos desenvolvedores experientes, mas o tempo é escasso, podemos esperar que todas as funcionalidades sejam entregues?

Perceba que, no contexto de um projeto de software, existem elementos que funcionam como variáveis de uma equação, gerando consequentes restrições. Se mexemos em uma delas, todas as demais são afetadas. Como abstraímos e representamos esse conceito?

O triângulo de ferro

O Triângulo de Ferro ¹

O “triângulo de ferro” (iron triangle), “triângulo do projeto”, “triângulo das compensações”, “triângulo das restrições” ou ainda “restrições triplas” é uma representação do relacionamento entre as principais variáveis de um projeto: recursos, tempo e escopo. Existe ainda um quarto elemento, ou quarta dimensão, que alguns autores acrescentam: a qualidade. Esta seria resultante das decisões tomadas em relação às demais variáveis.

Através do triângulo de ferro conseguimos visualizar certas consequências do *trade-off *das escolhas e restrições de um projeto. Em suma, o que a figura nos ensina é: todos os aspectos do projeto estão interligados. Não é possível alterar um deles sem afetar os demais. Recursos, tempo, escopo e qualidade possuem uma relação implícita.

Na prática: Quer mais qualidade? Aumente os recursos ou o tempo! Quer aumentar o escopo? Aumente o tempo ou os recursos! E assim vai…

Porque nós, desenvolvedores, deveríamos nos preocupar com isso?

Todo gerente de projetos deveria conhecer o triângulo de cor e salteado. Porém, o ideal é que todos os envolvidos em um projeto tenham um grau de consciência dessas restrições. Digo isso porque, falando especificamente da área de TI, a equipe de desenvolvimento sofre uma série de pressões do cliente e da gerência no decorrer do projeto e torna-se essencial equilibrar essas variáveis, reconhecendo aquilo que está dentro das possibilidades e tomando a decisão adequada. Os clientes sempre querem que entreguemos mais funcionalidades, com mais qualidade e mais rapidamente, mas com os mesmo ou até menos recursos. Quando a gerência não trata disso, a corrente arrebenta no elo mais fraco, isto é, os desenvolvedores “pagam” pelos diversos erros em todos os níveis do projeto tendo que fazer inúmeras horas extras.

Em minha experiência, o melhor remédio para o trabalho em excesso é a prevenção. Uma coisa é colaborar para o sucesso do seu empregador, outra é aceitar tudo o que lhe é imposto. Nós, desenvolvedores, devemos aprender a analisar a situação e, ao detectarmos problemas no projeto, negociarmos de antemão. Isso significa que, se sua empresa está prometendo o que você sabe que ela não pode cumprir, é melhor deixar isso claro desde o início para os responsáveis. Não estou dizendo para você desafiá-los ou confrontá-los rudemente, mas sim tentar expor de modo gentil e firme seu ponto de vista. Se eles derem ouvidos, ótimo, de outra forma, ao menos eles perceberão que você é um profissional sério e sabe o que está fazendo.

Entendendo as variáveis do projeto

Recursos

Embora o termo “recurso” seja ofensivo para alguns quando se trata de pessoas, ele é adequado quando falamos do investimento em um projeto. Esse investimento se traduz na contratação ou alocação da equipe, nos equipamentos necessários, espaço físico e outros itens. Embora, devido ao overhead, a quantidade de recursos não seja tão proporcional à produtividade, ainda assim podemos afirmar que, no geral, quanto mais recursos maior é a produtividade.

Tempo

Geralmente existe uma data limite definida pelo negócio, devido à uma janela de oportunidade, onde o software deve ser entregue.

Escopo

Quais funcionalidades serão entregues? Nem todos os requisitos e funcionalidades possuem a mesma prioridade. Num processo iterativo de desenvolvimento, deve-se definir junto ao pessoal de negócios quais funcionalidades trazem mais valor. Nem sempre é possível fazer tudo.

Qualidade

A qualidade é uma quarta dimensão entre as variáveis do projeto, a qual é influenciada pelas demais restrições. Como qualidade não é algo objetivamente mensurável, não há como fixar um valor para essa variável. Entretanto, se existe um padrão mínimo de qualidade para o projeto, devemos ajustar as demais variáveis de modo a atingir esse objetivo.

Conjugando as restrições

A fim de planejar, o gerente do projeto deve considerar as restrições, fixar as variáveis críticas e então estimar as demais. De forma incoerente, alguns tentam fixar todas elas, o que sempre resultará nas falhas descritas no início deste artigo. Quantas e quais variáveis são fixas, depende do projeto e do modelo de desenvolvimento adotado.

Variando o escopo e fixando os recursos e o tempo

Se temos uma equipe e um prazo fixos, então devemos estimar quais funcionalidades poderemos entregar de acordo com a produtividade da equipe dentro do tempo disponível.

Variando os recursos e fixando o tempo e o escopo

Temos um conjunto de funcionalidades a serem implementadas até uma data limite. Podemos então estimar o esforço necessário para completar a tarefa dentro do esperado. Quantas horas e quantos desenvolvedores serão necessários para completar as tarefas?

Variando o tempo e fixando o escopo e os recursos

Contamos com N desenvolvedores para entregar X funcionalidades. Com isso, estimamos em quanto tempo concluiremos o projeto.

Variando a qualidade

O projeto está atrasado. Não há tempo, nem como obter ajuda porque não há mais pessoas com conhecimento do projeto e ninguém quer negociar com o cliente uma entrega parcial, já que o relacionamento com ele está desgastado há meses. Então todos aceleram o passo. Testes? Para quê? As horas extras vão ajudar a pagar aquela fatura do cartão, não é? Será possível fixar tempo, escopo e recursos?

Então, na noite de sexta-feira, todos limpam o suor do rosto e suspiram de aliviados. A release já está no cliente. De alma lavada vão para o seu merecido descanso, pensando em como ultrapassaram as expectativas. Até a segunda de manhã, quando o cliente liga muito bravo devido à quantidade absurda de erros. Parabéns, foi entregue um produto no prazo, no orçamento e completo, mas que não funciona. Um software de péssima qualidade que demandará mais tempo de manutenção que desenvolvimento!

Você conhece algum caso onde o sistema foi enviado ao cliente sem passar por testes porque os desenvolvedores só concluíram o que foi prometido em cima da hora?

A qualidade é influenciada de diversas formas, sendo os principais fatores relacionados às pessoas envolvidas, tais como: equipe inexperiente ou desmotivada, pressão para concluir o projeto, dificuldades de comunicação.

O que vale mais para você?

Variáveis fixas e estimadas conforme o tipo de plano²

A gestão “tradicional” de TI geralmente foca no plano. Por “tradicional”, entenda aquilo que temos feito vez após vez nos últimos anos de forma irrefletida. Planeja-se a implementação sequencial das funcionalidades de acordo com a quantidade de recursos e o tempo disponíveis. “Vamos começar pelos cadastros mais simples, para ir pegando o jeito, depois avançamos para as regras de negócio mais complexas”, é algo comum de ouvir, uma tendência natural que se percebe.

Em contrapartida, processos modernos, principalmente os ágeis, procuram focar em trazer valor ao cliente. Com uma equipe e iterações fixas, priorizam-se as funcionalidades que mais beneficiarão o cliente e, a cada iteração, uma nova versão funcional do sistema é entregue. Ao aplicarmos o Princípio de Pareto (regra do 80-20), em tese, pode-se entregar 80% do valor do sistema nos primeiros 20% do projeto.

Lições e Conclusões

O triângulo de ferro é apenas uma representação, mas nos dá um referencial para entendermos as consequências das escolhas que fazemos. Não podemos ter tudo. Mesmo quando alguém acha que pode, na verdade estará sacrificando algo. No que se refere ao desenvolvimento de software, geralmente é a qualidade.

Um projeto é mais que cronograma, um gráfico ou qualquer documento, não podemos manipular a nosso bel-prazer. Se tentarmos forçar as variáveis do projetos certamente afetaremos algo. Justamente por isso o nome “triângulo de ferro”.

Além da adoção de um processo adequado, de ações preventivas e de boas práticas em todas as fases e áreas do desenvolvimento de software, as melhores formas de lidar com as inevitáveis restrições e dificuldades dos projetos são: aprender a negociar as restrições junto ao cliente e à gerência e priorizar devidamente as funcionalidades de modo a entregar algo de valor ao cliente.

Para concluir, uma citação que usei na minha monografia sobre estimação de software:

Frequentemente falta aos gerentes de software firmeza de fazer o pessoal esperar por um bom produto ³

Referências

1) O Triângulo das Restrições de Gerenciamento de Projetos (acessado em 30/09/2013)

2) Scope, Time & Cost Triangle Balancing To Motivate Team and Satisfy Client (acessado em 30/09/2013)

3) BROOKS, F., The Mythical Man-Month, Addison-Wesley, 1975

gerenciamento de projetos

9 pecados capitais do planejamento de projetos

09/08/2013 Carreira Deixe um comentário

Em seu artigo Nine Deadly Sins of Project Planning, Steve McConnell nos apresenta uma forma bem interessante de reconhecermos um projeto mal planejado. O autor baseou-se em sua experiência para identificar os “pecados capitais” que frequentemente levam os projetos ao fracasso. Francamente, suspeito que ele andou visitando algumas empresas que eu conheço!

O que se segue abaixo é uma tradução um tanto informal do artigo, isto é, não muito ao pé da letra. Eis os nove pecados capitais do planejamento de projetos:

#1 → Não planejar nada

Um dos erros mais comuns. Não é necessário ser um especialista para planejar. Pessoas pouco experientes já o fizeram com sucesso simplesmente porque tiveram o cuidado de atentar para os requisitos do projeto.

Se tiver de escolher entre um especialista em planejamento que não pensa cuidadosamente sobre o plano e um iniciante na carreira, mas que analisa criteriosamente as necessidades do projeto, é melhor ficar com o último.

#2 → Não planejar todas as atividades necessárias

O pecado número 1 é não planejar, o número 2 é não planejar o suficiente.

Alguns planos de projeto simplesmente assumem que ninguém ficará doente, participará de treinamentos, sairá de férias ou deixará a empresa. Tais planos preparam o projeto para um desastre. Há inúmeras variações neste linha. Por exemplo, não incluir atividades auxiliares tais como criar instalação do software, conversão de dados de versões anteriores e outros tipos de tarefas por vezes irritantes que levam mais tempo do que gostamos de admitir.

Em alguns projetos que estão com o cronograma atrasado, tenta-se recuperar o prazo diminuindo o tempo que foi originalmente planejado para os testes. A justificativa é que provavelmente não haverá tantos erros como a princípio se pensava. Fica como exercício para o leitor imaginar por que então o tempo de testes já não foi menor desde o início. 😉

#3 → Não planejar considerando os riscos

Henry Petroski argumenta que os maiores desastres na construção de pontes ocorrem após períodos de sucesso que dão margem à autoconfiança. Os projetistas tornam-se complacentes e simplesmente copiam os atributos de uma ponte para outra sem atentar-se para os riscos em potencial da nova construção.

Em muitos projetos, a palavra “risco” não é mencionada a menos que estejamos com sérios problemas. Em projetos de software, se não estamos usando essa palavra cotidianamente e incorporando-a em nossos planos, não estamos fazendo bem nosso trabalho. Como disse Tom Gilb: “se você não atacar ativamente os riscos, eles irão atacar ativamente você”.

#4 → Usar o mesmo planejamento em todos os projetos

Algumas organizações familiarizam-se com uma abordagem para executar projetos. Ela é mais conhecida como “o jeito que nós fazemos as coisas por aqui”. As coisas costumam ir bem quando os novos projetos são bem parecidos com os anteriores. Mas, se aparecer algo diferente, essa abordagem vai causar mais problemas do que ajudar.

Um bom planejamento visa necessidades específicas do projeto para o qual ele foi criado. Muitos elementos podem ser reusados, mas deve-se considerar cuidadosamente se os elementos antigos se aplicam ao novo contexto.

#5 → Aplicar modelos de planejamento indiscriminadamente

Um planejamento que alguém realizou chega na forma de um livro ou metodologia e parece funcionar muito bem do jeito que está. Então usa-se este plano genérico indiscriminadamente sem pensamento crítico ou consideração pelas particularidades do projeto.

Exemplos conhecidos são o RUP (Rational Unified Process), o XP (Extreme Programming) e, até certo ponto, meu próprio “Guia de Sobrevivência a Projetos de Software” (Software Project Survival Guide). Esses planos “pré-fabricados” podem ajudar a evitar os pecados #1 e #2, mas não substituem nossa análise das demandas únicas do projeto.

Nenhum especialista externo pode entender as necessidades específicos de um projeto como as pessoas envolvidas diretamente nele. O plano de um especialista deve ser adaptado para as circunstâncias específicas. Felizmente, existem gerentes que estão atentos para esses problemas e usam o senso comum para selecionar as partes dos livros de Engenharia de Software que atendem suas demandas.

#6 → Permitir que o planejamento esteja divergente da realidade

Uma abordagem comum ao planejamento é criar o plano no início do projeto e depois abandoná-lo numa gaveta, juntando poeira até o fim projeto. Quando as condições mudam, o planejamento torna-se irrelevante e, no meio do caminho, o projeto anda sem rumo. Não há mais relação do planejamento com a realidade do projeto.

Isso pode estar relacionado ao pecado #5, pois quando alguém abraça uma metodologia pré-fabricadas algumas vezes torna-se relutante em mudar quando ela não funciona. Eles pensam que o problema está na aplicação, quando, na verdade, está no planejamento.

Um bom planejamento deve ocorrer e ser revisado incrementalmente em todo o projeto.

#7 → Planejar muito detalhadamente logo de início

Alguns gerentes bem intencionados tentam mapear todas as atividades do projeto logo no início. Mas um software consiste num constante desdobramento de decisões, cada fase gera novas pendências para decisões futuras. Como não temos uma bola de cristal, tentar planejar atividades distantes em detalhes é um exercício burocrático tão ruim quanto não planejar nada.

Quanto mais trabalho é despendido em criar planos prematuros, maiores são as chances do plano ser engavetado (pecado número #6). Mas ninguém gosta de jogar seu precioso trabalho fora, então o gerente algumas vezes tentará forçar a realidade do projeto para se encaixar em seus detalhados planos, ao invés de revisar o plano prematuramente detalhado.

Eu penso num bom planejamento de projeto como dirigir a noite com os faróis do carro ligados. Eu posso ter um mapa que me diga como ir da cidade A para a cidade B, mas a distância que posso ver com os faróis é limitada. Em um projeto médio ou grande, um macro planejamento pode mapear todo o projeto. Então micro planejamentos detalhados conduzem o projeto apenas algumas semanas por vez.

#8 → Planejar para correr atrás do tempo perdido

Em projetos que começam a atrasar, um erro comum é planejar para se recuperar depois, correndo para “alcançar” o cronograma. A racionalização típica é: “a equipe passou pela curva de aprendizado no início do projeto, nós aprendemos várias lições duras, mas agora que entendemos o que estamos fazendo devemos conseguir concluir o projeto rapidamente”. Resposta errada!

Uma pesquisa de 1991 em mais de 300 projetos descobriu que dificilmente projetos recuperam-se, pelo contrário, a tendências é atrasar ainda mais. O erro desse raciocínio é que a equipe de desenvolvimento toma decisões importantes no início do projeto, enquanto ainda está aprendendo sobre as aspectos tecnológicos, de negócio, e sobre as metodologias. Nas fases posteriores do projeto, o passo não irá acelerar, mas diminuir na medida em que são colhidas consequências de decisões iniciais erradas e então é necessário investir tempo corrigindo esses erros.

#9 → Não aprender com os “pecados” cometidos anteriormente

O pecado mais mortal de todos é não aprender com os pecados já cometidos. Projetos de software podem levar muito tempo e a memória das pessoas pode ficar enevoada pelo ego e pelo tempo. No fim de um projeto longo, pode ser difícil lembrar todas as decisões iniciais que afetaram sua conclusão.

Uma forma fácil de contornar essa tendência e prevenir-se de pecados futuros é conduzir uma autópsia estruturada do projeto. Uma revisão não vai apagar os pecados passados, mas pode certamente evitar mais erros futuros.