:: LeoLuz ::

Tive um professor na época do cursinho que fazia uma brincadeira com a ingenuidade humana. Ele olhava para sua cara e questionava se você acreditava em Coelhinho da Pascoa, Alice no País das Maravilhas, Papai-Noel, etc.. No contexto da brincadeira ela se tornava sarcástica, inteligente e ao mesmo tempo engraçada. Porém nunca fui muito bom com piadas e esse nem é meu objetivo. O meu ponto é que doze anos se passaram e parece que ainda escuto alguns fantasmas do passado. Claro que não são ditas de maneira tão explicita, mas a moral da história é a mesma, e geralmente acontece mais ou menos assim:

1. Um solicitante pede uma estimativa para desenvolver um grande software.
2. O time quebra em pedaços de software menores e faz a estimativa de cada um.
3. O líder monta o cronograma do projeto com as informações estimadas pelo time.
4. O solicitante não aceita e fala que tudo tem que ser feito na metade do tempo.
5. O prazo das atividades é dividido ao meio e o cronograma é atualizado.
6. O time segue o novo cronograma.

Pode ser que você já tenha se deparado com alguma situação parecida com essa. Esse é o “famigerado” Prazo do Papai-Noel: Você ganha o presente, acreditando nele ou não. Na minha opinião, o maior perigo em um cenário desses é não perceber o quão prejudicial ele realmente é. Infelizmente, boa parte das pessoas são conformadas e aceitam a situação sem argumentar, negociar ou sequer refletir sobre o assunto.

Os Problemas

Motivação

O primeiro problema que aparece é a nítida decepção e falta de motivação do time em decorrência da falta de credibilidade depositada em seu trabalho. Por incrível que pareça, existem gestores que não estão nenhum pouco empenhados ou nem mesmo preocupados em fazer com que o time trabalhe motivado. Muitos destes tais gestores são os mesmos que adoram um belo comando-controle a la moda antiga e juram de pé junto que esse é o melhor tipo de gerenciamento.

Para ilustrar a questão da falta de motivação farei uma simples analogia:

Imagine que você é um artista-plástico que gosta de desenhar histórias em quadrinhos. Você acaba de ser contratado pela Marvel, está muito feliz e obviamente bastante motivado. No primeiro dia de trabalho seu novo chefe diz que no primeiro mês sua atividade seria avaliar o desenho de outros artistas e achar e apontar erros e imperfeições. Por mais que ache estranho e sem entender direito como realizar essa atividade, você aceita, afinal acaba de ser contratado pela empresa dos seus sonhos.
Pergunto:

• Como está a sua motivação no primeiro dia de trabalho?
• Como está a sua motivação no final do primeiro mês?
• Você foi informado que terá que ficar mais um ano nessa atividade. Como está sua motivação agora?
• Você vai realizar um bom trabalho? Qual será o seu rendimento no decorrer desse ano?

As respostas parecem meio obvias vistas por essa analogia extremamente simplista. Agora adicione vários fatores externos e traga para a sua realidade. Certamente as respostas não estarão tão evidentes mas provavelmente serão as mesmas. Última pergunta: Você como gestor.. Deveria se preocupar com o rendimento do seu time?

Mas não era estimativa?

Uma questão mais sutil, mas não menos importante, é o significado da palavra mágica citada no item 1: ESTIMATIVA. Acho incrível como uma estimativa vira um prazo concreto num piscar de olhos. Acredito que se alguém te pede para dar uma estimativa, está querendo na verdade ter uma noção do esforço de desenvolvimento para apoiar sua estratégia, entender se o custo é condizente com o budget, time-to-market, etc. Agora transformar uma estimativa em um prazo real não me parece muito coerente.. Basta acompanhar qualquer projeto nesse formato para perceber que a realidade é bem diferente do sonho. Tentar aproximar esses dois pontos, realidade e sonho, é um exercício que provavelmente trará alguns frutos positivos para seu projeto.

O Ciclo Vicioso

Não é difícil perceber que se iterarmos o cenário descrito nos itens 1 a 6 algumas vezes, ele tenderá a cair em um ciclo vicioso. Imagine que o time, após ter seu prazo cortado pela metade pela segunda ou terceira vez poderá sugerir um prazo maior. Por outro lado o solicitante também pode desconfiar da situação e diminuir o prazo cada vez mais. Isso criaria um ciclo vicioso de desconfianças. Não me parece algo saudável para se cultivar dentro da sua empresa, seja lá qual for o seu core-business.

Escalabilidade

Usando ainda a analogia do desenhista, imagine que você é o dono da editora e quer acelerar ao máximo sua produção de revistas e para isso a solução que te parece óbvia é contratar mais desenhistas e escalar sua linha de produção. Realmente pode ser que em duas pessoas seja possível dividir as atividades e ganhar mais agilidade. Talvez inserindo um terceiro elemento nesse grupo ainda traga algum ganho. Mas o que aconteceria se eu colocasse mais 10 pessoas para ajudar a desenhar uma única revista? A complexidade para fazer com que essas 10 pessoas se entendam e trabalhem em uma linha realmente mais produtiva será muito grande e provavelmente isso não ocorrerá.

Os Argumentos

Analogamente à ação de desenhar, do exemplo citado acima, a atividade de desenvolver software é empírica, ou seja, é um conhecimento adquirido apenas pela prática. Vamos supor que você já tenha 10 anos de experiencia como programador, desenvolveu uma funcionalidade para o software X e por algum motivo você perdeu os fontes. A próxima vez que você for desenvolver a mesma funcionalidade com certeza fará de maneira diferente e provavelmente melhor do que a primeira vez não é mesmo? Agora imagine um pedreiro com 10 anos de experiencia tem que subir duas paredes de tijolos. Ele vai demorar o mesmo tempo para subir cada parede e provavelmente elas terão o mesmo nível de qualidade. Percebe a diferença na realização de uma atividade que não é empírica? Então por que as pessoas constantemente comparam a engenharia civil com a engenharia de software sendo que são duas atividades totalmente diferentes? Já escutei de um PMP a seguinte frase: “Desenvolver software e construir um prédio é a mesma coisa!”

Dizem que existem 1000 técnicas para acertar prazos de projetos na mosca. Particularmente, sou meio céptico em relação a isso. Os motivos para a minha falta de crença já foram exaustivamente pontuados pela comunidade ágil, como no vídeo do Akita acima, e realmente fazem todo o sentido. Creio que esses acertos são na verdade prazos bem engordurados seguidos de uma bela síndrome do estudante. Assim fica fácil de acertar, se é que dá para considerar isso, algo certo e positivo para a sua empresa.

Realizar um projeto de software no menor tempo possível da melhor maneira possível de forma que o solicitante goste e que tenha um bom nível técnico é o grande desafio e não existem formulas mágicas para alcançar esse objetivo. Cada caso é único e a liderança estratégica tem obrigação de se preocupar com isso.

E você? Acredita em Papai-Noel?
Feliz Natal!