Porque projetos atrasam?

Depois de "Qual o sentido da vida, do universo e tudo o mais?" a pergunta "Porque projetos atrasam?" deve ser a mais realizada de todas.

Existem diversas respostas que demonstram porque um projeto atrasa mas, raramente, quem faz a pergunta sequer aceita a resposta ou, ao menos, ponderar sobre o que foi respondido. Ninguém é no mundo uma autoridade em atrasos de projeto e eu duvido que exista qualquer projeto realizado ou em andamento onde NADA atrasou.

Um projeto que aconteceu sem qualquer atraso ou não existe, ou foi feito por um elfo, ou não foi bem definido e quem contratou não ficou satisfeito ou este projeto foi cancelado e não foi concluído.

Eu desafio ao leitor me demonstrar um projeto que não atrasou e que não entrou nas categorias acima.

(Se você encontrar um elfo que fez um projeto você é o cara!)

De quem é a culpa por um projeto atrasar? Essa deve ser a terceira pergunta mais feita no mundo. E ela não tem uma resposta correta. Isto é o mesmo que culpar o vento pela água ser molhada! Ou então, a culpa é de Deus?!

Antes de fazermos estas perguntas, seria melhor que nos perguntássemos: estamos completamente seguros de tudo o que queremos de um projeto? Estamos prontos para bancar os famigerados 30% de atraso previsto na definição de um projeto? Juramos por Deus que não vamos pedir nada diferente daquilo que definirmos ANTES do início do projeto!

Acho que agora cheguei no âmago do problema: mudanças.

As seguintes premissas garantem TOTALMENTE um projeto sem atrasos:

• O usuário sabe de cor e salteado todas as nuances e detalhes de sua atividade de negócio. Ele é tão expert no assunto que o Papa Francisco vem se consultar com ele. A Casa Branca usa esse cara para definir todas as estratégias de negócio do setor. Deste modo, todas as informações que a equipe do projeto precisar estarão determinadas, detalhadas, escritas e diagramadas corretamente não ficando espaço para dúvida.
• O usuário, esse super saiyan (do desenho Dragon Ball), estará 100% envolvido no projeto disponível o tempo todo para ser consultado e não arredará o pé nem fará qualquer outra atividade até a entrega do projeto. Não haverá uma "visita rapidinha a um cliente" ou uma "prioridade" em outra atividade.
• O gerente / coordenador do projeto terá autonomia para decidir o que for preciso, terá um budget (orçamento) à sua disposição para contratações de última hora, compra de alguma tecnologia necessária, sem que tenha que pedir a bênção do Chicão (Papa Francisco), de Deus, de um E.T. do Gandalf (Senhor dos Anéis), etc.
• A equipe do projeto será formada por pessoas capazes, determinadas e com conhecimento técnico específico para a tecnologia na qual será empregada no projeto e o RH da empresa (composto por Psicólogos de verdade) irá ajudar a compor uma equipe correta e completa e não pegar a rapa do tacho do que sobrou na empresa.
• A equipe do projeto vai ser madura para colocar de lado suas diferenças e trabalhar com vontade e determinação para o bom andamento e conclusão do projeto. 
• O gerente / coordenador não vai ter que ficar malhando o Judas nem rebanhando a equipe porque o Diretor acha que funcionário deve ser vigiado, tolhido, chegar às 8 em ponto e não ter horário para sair da empresa.
• As pessoas vão tomar mais de 500g de vitamina C todos os dias e diversas vacinas além de andarem com roupas anti-germes de forma a não contrair qualquer enfermidade.
• Todos os componentes do projeto vão morar a meros 10 metros da empresa de modo que os mesmos não se atrasem, não tenham problema com trânsito, não durmam além da conta e não tenham que sair correndo da empresa para voltar para casa.
• Todos os componentes do projeto serão andróginos sem sentimentos e não se relacionarão com ninguém fora da empresa de modo que não haja qualquer distúrbio pessoal em suas vidas e eles fiquem 100% focados no projeto.
• A sede da empresa será protegida por uma redoma de vidro indestrutível de modo que, se o mundo acabar em qualquer tipo de cataclismo a empresa sobreviverá flutuando no espaço tudo de modo que o projeto se complete.

Exageros à parte, somente se os quesitos acima foram contemplados não teremos qualquer atraso no projeto. Aliás, se lermos atentamente a lista acima, conseguiremos descrever ainda certos problemas que eu não parei para pensar e que podem levar um projeto a atrasar.

Com toda a certeza tenho leitores que estão se perguntando mas como você justifica que um projeto que tinha o prazo de um ano para acontecer, está há 3 e ainda não acabou? Justifico dizendo: quem foi que disse que o prazo inicial do projeto era de um ano? Quem disse que isto estava certo? Com base no que foi dito isto?

Tenho a experiência de estar passando por um projeto assim. Quem determinou tudo isto é uma pessoa extremamente experiente em desenvolver software sozinho, num determinado jeito, numa determinada qualidade. Um cavaleiro solitário. Software que só ele entende e que só ele consegue efetivamente dar manutenção em tempo hábil. Qualquer outra pessoa no mundo que pega o que ele fez se confunde, demora para entender, demora para tomar proficiência e faria diferente. Neste caso, o prazo dado foi feito com base no que ELE faria. Eu jamais daria um prazo sob pressão. 

Dar um prazo é se comprometer. 

Para dar prazo, existem técnicas consagradas, métricas a serem levadas em conta e ainda assim, com margens de erro tremendas. Dar prazo é uma arte. É uma maldição. Todo prazo dado, deve ser cumprido.

Nós humanos pedimos para sofrer.

Chego para minha equipe e peço um prazo. Quero que eles me digam um dia no máximo. No fundo no fundo já sei que o prazo que eu quero é impossível, mas quero saber da equipe. Todos se entreolham. Suam. Se remexem nas cadeiras. Pensam e por fim vem o prazo: um mês. Essa resposta entra em mim rasgando como se todos da equipe estivessem contra mim e querem o meu mal. Todos agora são meus inimigos. O clima se acende. A Pressão é perceptível. Mesmo que a equipe possa fazer em 5 dias, eles vão fazer em DOIS meses. Só por causa da maneira como pedi, da reação que tive quando me deram o prazo e pelo mal psicológico que eu causei às pessoas as interpelando dessa maneira.

Mas caramba! Sem prazo como vou saber custo, viabilidade, etc?

Calma pequeno gafanhoto! Tudo tem solução!

Tenho um carro. Não sei absolutamente NADA de mecânica de automóveis. Meu carro está fazendo pequenos ruídos em determinada situação. Não parou de andar nem nada mas eu estou achando estranho o ruído. Vou ao mecânico que meu pai costumava ir. Ele avalia o carro e chega numa conclusão: tem uma peça gasta. Não vai causar problema para andar mas vai continuar a fazer o ruído. A peça não é cara, mas a mão de obra para desmontar, trocar a peça e remontar vai ficar 10 vezes mais cara do que a peça em si e o serviço vai demorar cerca de 30 dias para ser realizado. Se eu ficar puto com o mecânico, o melhor que deveria acontecer comigo era ser espancado em praça pública e meus pelos púbicos deveria ser arrancados com uma pinça. Que culpa o mecânico tem? Porque quando eu fui comprar um carro eu não fui aprender mecânica básica e olhei embaixo do capô para me certificar de que a fábrica dava acesso fácil a determinadas peças? 

Poxa! Mas eu vou ter que fazer Engenharia Mecânica no ITA para comprar um carro? Não mas um mínimo você TEM que saber e deveria ser LEI antes de adquirir um carro como tudo o mais. Até mesmo para se ter um computador pessoal DEVERÍAMOS ter um conhecimento mínimo. Popularizar tudo é desastroso. 

Não dá para culpar os outros por esse tipo de coisa.

Para todo problema existem soluções. Algumas mais caras, outras nem tanto. Em projetos é o mesmo. Para se pedir um prazo, deve-se antes pensar no problema. Definir o que está em jogo. Apresentar a sua equipe tudo o que deve ser executado, todos os detalhes possíveis sobre o problema e como poderíamos solucionar. Quem está pedindo deve ter um conhecimento mínimo do que se vai pedir. Ou, pagar a pena de ter um prazo diferente de suas expectativas e não descontar esse desapontamento na equipe. Desconte em você mesmo por estar pedindo algo do qual você não faz ideia de como funciona. 

Um caso prático:

Certa feita quis dar um up no meu site. Sou desenvolvedor mas não tenho qualquer habilidade em web design. Para mim o mundo seria quadrado e em preto e branco. Mas sei como funciona código em Javascript, CSS, HTML a estrutura de uma página web, que para fazer um menu suspenso tenho que usar um script Javascript feito do zero ou usar uma biblioteca como o JQuery para ajudar, etc. Então, fiz num PowerPoint um rabisco, um rascunho dos elementos que eu queria ver no site. Disposição de determinadas coisas e FUNCIONALMENTE defini o que o site deveria fazer. 

Contatei um amigo que é desenvolvedor de frontend há muito tempo e dei a ele as premissas do projeto. Queria que ele fizesse o front esperando que houvessem funcionalidades de servidor que EU MESMO faria em JAVA EE e que deveriam devolver para as páginas parâmetros e informações de acordo com o rabisco em PPT que eu estava mostrando a ele.

Com base nisto, disse a ele: "Leve para casa, mastiga a idéia, critica, me diz o que estou pensando errado, rabisca do jeito que você faria e vamos voltar a conversar". Ele fez isso e ficou nisso por uns 5 dias. Quando voltamos a nos falar, ele me disse que alguns problemas aconteceriam e que se eu fizesse do jeito Y ao invés do jeito X daria certo. E me disse que se eu aceitasse o que ele tinha determinado, em 10 dias ele me devolveria o site pronto para que eu acoplasse com o lado servidor que eu iria começar a desenvolver. 

Vejam aí que eu já tinha uma ideia completamente definida, delineada, ajustada para passar a quem eu esperava um prazo. Dei liberdade à EUquipe de frontend para determinar problemas, sugerir, mudar coisas, afinal, se eu soubesse fazer frontend, não precisaria contratar alguém para isto. Nem questionei o valor que ele me passou. Ele sabe o quanto vale o trabalho dele. E ele sabe que eu sou exigente e cobro fortemente qualidade e comprometimento. 

Engraçado que ele me entregou a primeira versão em 8 dias, ao invés de 10, pedi uma mudança ou outra, pequei eu sei, e ele me entregou no dia seguinte, com um dia de crédito ainda.

Eu nem havia terminado o módulo servidor ainda quando ele me entregou. E a coisa se acoplou perfeitamente, sem problemas, sem atropelos, etc. Atrasou o projeto!!!! Por minha culpa. Eu quis coisas demais do lado servidor. Coisas que eu não sabia que iriam tomar tanto tempo. Não me frustrei porque era eu que estava exigindo e eu que estava fazendo. Será que seria assim se eu tivesse contratado o módulo servidor de outra pessoa e tivesse agido diferente do que eu fiz com o rapaz do frontend?

Pensem a respeito, Oh pessoas que pedem prazos!

O dia a dia nos consome!

De metodologias e conceitos acadêmicos de gestão de tempo e produtividade estamos lotados. Tem um sabor para cada tipo de pessoa no mundo. E nenhum deles parece funcionar em todos os lugares por onde eu passei.

Sim, sou azarado! Mas de azar em azar pude perceber um ponto em comum desses lugares onde estive e que o dia parece ter meros minutos ao invés das invejadas 8 horas de trabalho. Em muitos deles, mesmo ficando cerca de 16 horas na empresa, parece que nada rendia.

O grande vilão é o dia-a-dia.

O dia-a-dia é aquela economizada que seu diretor deu em determinado orçamento, aquele contrato com o fornecedor que cobrou mais barato mesmo não sendo a escolha de melhor qualidade, é aquela rotina que você poderia ter escrito melhor mas o seu chefe não permitiu para que não atrasasse a entrega do projeto, etc ...

Essa semente do mal cresce e nos engole. E eu dei o apelido carinhoso a ela de dia-a-dia.

Existem diversas maneiras de se evitar que um dia-a-dia apareça. Algumas eu descrevo abaixo:

Fazer antes de pensar: 

O trabalho do desenvolvedor de software é absolutamente parecido com o do arquiteto ou engenheiro na construção civil. É tão parecido que vários dos papas da tecnologia, escreveram padrões de projeto (design patterns) que surgiram justamente para ajudar a resolver problemas comuns aos construtores de edifícios e a aplicação do conceito é tão comum aos dois mundos que foi fácil "portar" os conceitos para o mundo da informática.

Imagine que você quer comprar um apartamento. Você vai a um stand de venda e procura um corretor e ele lhe fala da obra magnífica que será edificada ali, que os quartos vão ser maravilhosamente dimensionados nos impressionantes 100m quadrados de área do apartamento, que a cozinha será funcional, etc. Bem, o prédio ainda não está pronto, logo, você não tem como saber como vai ficar. Para ajudar a demonstrar um pouco o arquiteto fez uma planta baixa (um desenho do andar em recorte demonstrando a disposição das paredes, portas, janelas, etc). Ele foi muito preciosista e construiu também uma maquete das fachadas do prédio. O resto fica por conta da sua imaginação. E você aceita. Acha bom, o preço e as condições de pagamento são legais, você fecha negócio e espera o prédio ficar pronto para se mudar com sua família.

Agora imagine que você é um usuário do sistema e a equipe de desenvolvimento de sistemas da sua empresa faz inúmeras reuniões com você para saber como é o seu dia-a-dia, quais são os problemas que você enfrenta para realizar o seu trabalho, etc. Deste modo, eles criam um protótipo de telas, clicável inclusive, diagramas demonstrando as regras de negócio que vão cumprir, criam cronogramas para que você acompanhe o andamento do projeto, o envolvem nos testes e tal. E VOCÊ USUÁRIO CARA DE PAU VEM FALAR QUE NÃO TEM COMO APROVAR O PROJETO PORQUE NÃO TEM O SOFTWARE PARA USAR. COMO VOU APROVAR UM PROJETO SE EU NÃO TENHO O PROGRAMA PARA USAR????

Porque o seu apartamento você compra sem o prédio existir e o software você precisa ter pronto???

É a mesma coisa!

Por causa de usuários assim, temos visto diretores e gerentes exigindo que funcionalidades complexas e regras de negócio beirando sistemas especialistas (com Inteligência Artificial) saiam do papel em questão de poucas horas. Como pode?

Alguém já parou para pensar que 9 mães grávidas juntas não fazem um filho em um mês? Do mesmo modo, tudo tem um tempo para surgir. Estamos fazendo as coisas sem pensar, sem planejar, porque alguém sem noção não está dando o devido tempo para as coisas surgirem.

Milhares de bons sistemas que ajudariam a humanidade a evoluir estão deixando de aparecer no mundo porque alguém inventou uma idiotice chamada TIME-TO-BUSINESS como se o tempo fosse fator limitante do que quer que seja! Algum publicitáriosinho metido a CEO acordou um dia com diarréia e pensou, nossa, quero que os sistemas da minha empresa sejam TODOS feitos em um dia ou dois. Para que perder meses num projeto para um software surgir? Não é só apertar uma série de botões?

A diferença nos casos que eu citei (da engenharia em relação a TI) é que um engenheiro tem um conselho regional que o apóia e o obriga a tomar certas precauções e a se responsabilizar civil e criminalmente pelo que ele está criando, ou seja, se o prédio desabar, ele está completamente ferrado. Se isto fosse imposto a um desenvolvedor, você iria se matar de fazer aquele sistema que na sua concepção levaria um mês para ficar devidamente pronto, em apenas dois dias porque o dono da empresa para a qual você trabalha quer? Por acaso o dono da sua empresa colocou o registro de Tecnologia dele em jogo? Ah, ele não tem porque não tem formação em Tecnologia? Ah, ele não tem formação em nada? Ah, o pai abriu a empresa para ele. Acho que estamos voltando a posts anteriores onde eu disse que alguém que abre uma empresa não necessariamente deveria participar do dia-a-dia dela. Mas contribui com esse monstro.

Pensou? Então pensa mais um pouco antes de sair fazendo:

Você recolheu os requisitos do usuário.
Você validou os requisitos e gerou as regras de negócio.
Você validou as regras de negócio, determinou fluxos para apoiar as premissas que você levantou.
Você gerou os casos de uso para determinar as fronteiras do que será construído.
Você realizou os casos de uso em diagramas de sequências.
Seus arquitetos de sistemas modelaram as classes de acordo com seus diagramas e regras.
Seus desenvolvedores foram envolvidos para validar o modelo.
Foram feitos protótipos.
Foram feitas apresentações dos protótipos aos usuários.
Os usuários aprovaram formalmente os protótipos.
Foram feitas seções de testes de mesa para apoiar as decisões que o projeto tem.
Todo mundo está satisfeito com os resultados.
Vamos começar a construir. Mesmo? Não falta nada?

Usuário mudam de idéia como eu mudo a roupa de baixo. Se você conversar com um usuário, principalmente aquele mais mimado, genioso, em dias diferentes da semana, antes do pagamento do mês, na época que a esposa dele está menstruada, sei lá, pode ter certeza de que ele vai contradizer tudo aquilo que ele havia aprovado. Gestão de mudanças em desenvolvimento de software é a disciplina mais importante em qualquer modelo de gestão de projetos que você venha a adotar. Não importa qual. Alguns te ajudam mais a medir o impacto das coisas, outros menos.

Mas não há milagre feito neste universo, nem na Bahia, que te impeça de frustrar o chefe mimado. Aquele mesmo! Ele ACHA e vai continuar assim eternamente, porque está pagando, que o sistema que ele imaginou ficar pronto em três meses, tem que ficar e pronto. Se não ficar é porque a cadeia de desenvolvimento, do gerente ao faxineiro, não prestam. São incompetentes. Imagina se ele vai achar que por algum momento ele subdimensionou o prazo.

Amigo, as coisas são caras. Você quer algo exclusivo por 10 reais? Aqui não é a China e lá, com toda a certeza, não há itens exclusivos.

Tá bom! Todo mundo entendeu e o projeto vai começar!

Gostaria que alguém me dissesse se existe um sistema que gera sistemas!

Adoro a série Star Trek. Todas as versões.

Havia um instrumento na nave em que você (usuário) pedia algo (sistema) e esse algo era materializado e você poderia interagir com as ilusões, etc. Era chamado na série de Holodeck. Um super simulador, criador de realidades, transformava energia em matéria temporária onde você poderia confundir o seu cérebro e interagir com entidades irreais num mundo de realidade virtual. Conseguiu entender?

Talvez, no século XXIV (24) tenhamos um instrumento capaz de construir um sistema sem a intervenção de pessoas. Mas até lá, talvez você não precise mais de software como o conhecemos. De qualquer modo, para fazer uma casa você precisa de arquiteto, engenheiro, mestre-de-obras, pedreiro, material e TEMPO (além de aprovações de prefeitura e outras burocracias). Ah, esquecemos do bom e velho DINHEIRO!!!!

Para fazer software, também. Você precisa do gerente de projetos, do arquiteto, do desenvolvedor, do usuário (burocracia) e do bom e velho TEMPO também. Preciso falar que tudo isso se resume a dinheiro?

Sacaram o lance das pessoas no meio de tudo isto?

Somos imperfeitos. Seres em constante mudança. Duais em tudo. Temos sempre uma vida dupla. Somos o profissional e o pessoal ao mesmo tempo, entre outras dualidades que não vem ao caso neste blog. Porque diabos o velho idiota dono da empresa acha que ninguém vai se desmotivar, cansar, adoecer, errar, complicar o que poderia ser simplificado, se enganar, enganar, ter medo, ter coragem de assumir o erro, se acovardar porque precisa do emprego, se encher do emprego e mandar o chefe a merda e ir procurar outro emprego, etc, etc, etc?

Projetos ATRASAM!
Projetos DÃO ERRADO!
Projetos SE COMPLICAM!
Projetos DÃO PREJUÍZO!

Mas com a devida paciência, com o devido tempo, com a devida autonomia dada ao Gerente / Coordenador / Desenvolvedor, o projeto ANDA, ACONTECE, FUNCIONA, TERMINA, DÁ LUCRO, DEMONSTRA QUE FOI UM SACRIFÍCIO QUE VALEU A PENA, etc ...

O dia a dia é a briga diária contra todos os obstáculos que eu apontei aqui. Tem horas em que parece que não estamos gastando nosso tempo e conhecimento para resolver um problema e criar um sistema. Tem hora que estamos combatendo valentemente os problemas do dia a dia. Ao invés das pessoas se unirem para uma causa maior e resolver logo o que deve ser resolvido, tendemos a olhar para nossos umbigos, salvarmos nossos empregos e os outros que se danem. Até quando seremos egoístas a este ponto?