Uma vez participei de um projeto que tinha um cronograma gigantesco tentando prever alguns meses de trabalho. Como de costume esses mega-projetos estão descritos em um também gigantesco Gantt Chart (se você não sabe do que eu estou falando veja a imagem ao lado).
O software que estávamos desenvolvendo era super específico e estavamos lidando com uma série de variáveis desconhecidas. Por exemplo, uma das partes do projeto era fazer integração com um sistema em C utilizando um protocolo não muito bem documentado baseado em HTTP. Para esta tarefa o gerente de projeto estimou “5 dias”. Quando eu perguntei como ele fez para estimar 5 dias sem nem mesmo saber exatamente como funciona o protocolo HTTP, a resposta foi a tradicional: “ah, eu chutei o valor pra cima porque não tinha muita certeza”. Como assim chutou pra cima? De onde ele tirou que isso é “para cima”? (só de curiosidade, no fim das contas a integração levou 3 semanas…)
Assumir que coisas deste tipo levarão tempos pré-determinados não funciona. O que esse gerente fez é tão tosco quanto um exemplo que tem no livro do Ken Schwaber: “para cada 4 classes, 3.5 designers completarão uma tarefa em 16 horas”. Acredite, esse é o tipo de “técnica” que os gerentes de projeto CMM Level 5 Certified utilizam para definir esses cronogramas malucos.
Além disso para poder fazer esse tipo de cálculo considera-se que as pessoas conseguem fazer uma determinada quantidade de trabalho por dia. Aí eu pergunto: isso leva em conta um dia de trabalho de um profissional bem treinado, bem qualificado, bem supervisionado, totalmente consciente, sem problemas pessoais, começando de manhã após um copo de café expresso? Ou seria um dia de trabalho de uma pessoa qualquer?
É por isso tudo que esses projetos sempre atrasam!
O que é preciso enxergar é que o processo de desenvolvimento de software não é uma linha de produção, não é executado por robôs e por isso não se pode determinar exatamente o que acontecerá durante um longo período de tempo. Além disso o processo envolve muita criação e não se pode garantir que os produtos finais sempre serão os mesmos ainda que aplicado o mesmo método de trabalho. Veja, produzir um carro, por exemplo, envolve uma série de atividades encadeadas e repetidas. Se você produzir 8.000 carros todos passarão pelo mesmo processo de fabricação e no fim do processo você terá 8.000 carros idênticos fabricados na mesma quantidade de tempo. Mas se você entregar o mesmo projeto de software para 8.000 programadores diferentes é totalmente possível que no final você tenha o mesmo problema resolvido de 8.000 formas diferentes e em prazos totalmente diferentes dependendo do nível de conhecimento, linguagem/tecnologias adotadas e etc.
No projeto que estou trabalhando atualmente fazemos diferente. Não definimos um prazo de entrega para o projeto inteiro mas sim a data de entrega dos Sprints (as iterações do Scrum). Fazendo análise e desenvolvimento de forma incremental os riscos são bem menores e é muito difícil alguém não levantar uma bandeira amarela antecipadamente caso uma estimativa esteja totalmente fora da realidade como a que eu citei. Mesmo não tendo muita flexibilidade nas datas de entrega acho que as pessoas se sentem mais confortáveis assim porque sempre estamos entregando alguma coisa e não atrasamos. O máximo que já aconteceu foi cortar a última história do Sprint (que voltou para o backlog e acabou nem entrando no Sprint seguinte), mas mesmo assim eu sinto que as pessoas ficam mais satisfeitas.
Sempre que esse papo vem á tona alguém pergunta: e como eu controlo o projeto? Quer ver um exemplo: sabendo que a nossa equipe faz Sprints de 15 dias nossos clientes decidiram que nós deviamos desenvolver determinadas funcionalidades chave para que agora no fim do segundo Sprint possamos fazer um release em produção de um software novo. Além disso eles participam ativamente das reuniões de planejamento dos Sprints e decidem quais tarefas serão feitas por nós. Quer mais controle que isso?!?
Por isso tudo que eu acredito que os cronogramas não são eficientes. Em alguns casos já é difícil planejar um Sprint de 15 dias, imagina projetos de meses ou anos? Fico me perguntando se esse projeto desse Gantt Chart (aquela imagem do início – achei no Google Images) foi entregue na data certinha que está especificada alí… Eu duvido!
26 replies on “Cronogramas não funcionam”
E aqueles calculos de ponto de caso de uso então… fui estimar um projeto pessoal e ele resultou em surpreendente 1.754,475 horas de trabalho 😛 precisão absoluta heim hahahaha
Pior que cronogramas funcionam. Mas depende da sua organização e se o gerente de projeto exerce realmente a profissão.
Uma vez ouvi num podcast (Não lembro se foi do Vinicius Teles) algo do tipo “Ja que não tenho a oportunidade de trabalhar com a Mãe Dinah do meu lado vou continuar fazendo minhas iterações curtas”.
Na dúvida, não tente adivinhar o futuro. Alem disso, esteja preparado para as mudanças, visto que elas são bastante comuns do universo do desenvolvimento.
Belo post Guilherme!
Esse projeto não, posso me atrever de lhe perguntar:
Algum projeto já foi entregue na data do planejado no inicio de seu cronograma?
O que acho é o seguinte, as empresas que trabalham dessa forma estabelecem um cronograma inicial, mas sabem que será inevitável Alterações de Escopo ocorrerem durante o projeto, logo, alteração do cronograma.
Te pergunto, será que todo projeto seria aceito pelos clientes utilizando SCRUM?
Acredito que funcionam na maioria com projetos internos, mas e externos?
[]’s
Guilherme,
O problema é o não entendimento de muitos gerentes sobre o que é uma estimativa. Uma estimativa é exatamente… bem, uma estimativa. Não é um fato. Não é uma verdade. É engraçado quando gerentes “chutam para cima” e depois cobram resultados dentro da estimativa. Muito criterioso.
valeuz…
E o Gantt Chart começa bem: Netwroking?
Vou dar mais um motivo para projetos atrasarem: questionar o modelo Entidade-Relacionamento (ou “quem precisa normalizar?”). O_O
Acho que não existe formula mágica e nem metodo 100% eficaz. Por isso dizer que cronograma não funciona não é de todo verdade, pois se bem usado funciona extremamente bem. Creio que devemos tomar cuidado com modimos, pois hoje se fala no SCRUM como solução mas amanhão ele pode ser o grande vilão.
Creio que o essencial a um bom gestor de projeto é bom senso e organização seja ela da forma que for.
Será que ainda existem empresas que utilizam pontos de função para conhecer o tamanho do sistema, qnt tempo levará e o custo para então montar o “MS Project” ?! o_O
Abraços
Cronogramas… Um professor meu lá no início da graduação chamava os mesmos de “pornograma” pois os prazos e as estimativas dos mesmos eram sempre tão indecentes e chutados de tal forma que não poderia haver nome melhor.
Sempre lidei com cronogramas com medo… Quantas gargalhadas já dei na frente deles… A pergunta que sempre fazia: de onde veio esse prazo mirabolante de 4 dias e meio para a tarefa X? A resposta que eu recebia do ger. de projetos era a mesma, “eu acho que”…
Putz, vou te falar uma coisa, eu detesto gerentes de projeto nesse estilo aí… Na verdade não são gerentes, que tal darmos a eles o cargo de Mãe Dinah? Talvez seja mais aceitável.
Para completar, o que mais me assustava era ver a felicidade dos clientes vendo um cronograma “completo” com data de início e fim planejadas… Clientes, por favor, quantas vezes um projeto baseado nesse tipo de cronograma deu certo? Não sejam cegos! Eu nunca vi um…
Acho também, Guilherme, que os clientes devem mudar de pensamento, pois no final de contas, são eles que dão as ordens.
Já levantaram e reitero: cronograma é baseado em estimativa, não é fato. Acontece que com o acúmulo das experiências, cada vez a estimativa é feita melhor. Além disso, se há profissionais que fazem estimativa no chute, há profissionais que a fazem com técnica, por exemplo, de Análise de Pontos de Função ou de Pontos de Caso de Uso. De qualquer maneira, é de se esperar que as primeiras estimativas sejam piores e só com o tempo é que se tenha melhor qualidade. Outra questão é que os clientes querem um comprometimento de prazo. Você pode imaginar um cliente solicitando um sistema e vc respondendo: não sei quanto tempo vai levar, pode ser um mês ou seis meses! Me desculpa, mas se o cliente fosse eu, com certeza não compraria de você!
Andre (não o André Pinto),
Em momento algum disse que Scrum é a solução para todos os problemas. No nosso aqui na Globo por acaso usamos Scrum, mas poderia ser XP, ou “papel de pão” ou qualquer outra coisa. Não usamos nenhuma “fórmula mágica”, apenas usamos ferramentas que funcionam.
O ponto aqui é que _não é possível_ prever uma cadeia de acontecimentos em um projeto de software e acertar na mosca. É _impossível_, simples assim. Na minha opinião só se faz isso para ter uma falsa impressão de controle. O cara quer chegar numa determinada data e olhar para o cronograma para saber se está bem ou não. Mas quem disse que o cronograma vai estar certo? Nada impede de na última semana você descobrir um mega problema e atrasar a entrega em um mês, por exemplo, _mesmo que todo os 6 meses anteriores do projeto tenham sido feitos no tempo_. Eu já ví isso acontecer muitas vezes. Para ser mais exato, só nesse ano aconteceu em aproximadamente 50% dos projetos que participei. E em quase 10 anos de profissão o que eu sempre ví foram cronogramas que não funcionam.
Portanto insisto que não acredito em cronogramas, mas isto é minha observação pessoal baseada na minha experiências ao longo da vida. Ninguém é obrigado a concordar 🙂
[ ]s, Guilherme
João,
Isso serve se você trabalhar sempre em projetos iguais, caso contrário suas experiências de projetos anteriores não valem totalmente para o próximo.
Vamos fazer uma brincadeira. Sou seu cliente e quero que você encha para mim 200 balões. Quero eles todos cheios e amarrados na minha frente. Nas primeiras vezes você não vai conseguir estimar corretamente mas com o tempo você saberá exatamente e velocidade que você leva e poderá fazer cálculos simples para ter estimativas bem precisas independente da quantidade de balões que eu pedir. Ok.
Agora vamos falar de _desenvolvimento de software_:
– De projeto para projeto as pessoas mudam, portanto a velocidade de excução do trabalho muda;
– A quantidade de pessoas muda, o que torna o cúlculo ainda mais difícil (as pessoas nunca produzem igual);
– Pessoas ficam doentes (mês passado fiquei 5 dias fora porque operei o rim, por exemplo);
– Pessoas pedem demissão e você precisa subistituí-las no meio do projeto. As vezes você está perdendo um analista sênior com vastos 5 anos de experiência no negócio e está substituindo por uma pessoa super competente mas que não tem a menor idéia do projeto. Ou seja, a velocidade _vai_ mudar;
– As tecnologias mudam. Hoje você pode ter que desenvolver um site em PHP mas amanhã pode ser em Java e depois Ruby. E a velocidade denovo muda…
Enfim, eu poderia passar duas horas aqui te dando vários motivos para você não conseguir acertar.
Concordo com a seguinte frase que você escreveu: “com o acúmulo das experiências, cada vez a estimativa é feita melhor”.
Se você encher balões para o resto da vida isso será verdade. Para projetos de software que mudam a cada dia isso não funciona!
E pra finalizar, se algum dia você fosse meu cliente e tivesse a oportunidade de participar de um projeto de verdade e entendese isso tudo, certamente você não ia querer ser cliente de mais nenhum outro 😀
[ ]s, gc
Esta é uma discussão muito interessante. Parabéns, Guilherme, ao levantá-la!
FATO 1: Atuo há 12 anos na área de desenvolvimento de software e NUNCA ví um cronograma acertar em 100% DA MANEIRA INICIAL COMO FOI CONCEBIDO, seja esta maneira uma técnica empregada ou “achismos” dos profissionais envolvidos na elaboração do cronograma. Os casos de sucesso que ví foram estimativas “astronomicamente-bicadas-para-cima-e-entubadas-pelo-cliente”, sendo que alguma delas, ainda assim, andaram por muitas rodadas finais na zona de rebaixamento. 🙂
FATO 2: Clientes ficam extremamente mais felizes com pequenas entregas modularizadas, afinal, eles acompanham e participam ativamente da evolução do software – como bem empregou o Guilherme em seu texto -, mesmo que a data final estimada para a entrega do software atrase um pouco.
Infelizmente, o cronograma é um mal necessário. Culturalmente, está enraizado como uma forma de garantir ao cliente a data de entrega do serviço completo. Também acredito que não exista uma fórmula mágica para elaborá-lo e que, por desenvolvimento de software lidar diretamente com o fator humano, é preciso estar atento para os problemas mundanos. Acredito que a melhor prática para a entrega de software ainda é ser bastante transparente com seus clientes com relação ao andamento do desenvolvimento do seu software.
Levantar a bandeira amarela é sempre bem-vindo!
Grande abraço a todos!
Na maioria dos comentários, percebo que as pessoas têm uma idéia de cronograma engessada. Se na execução do seu projeto acontecer tudo como foi planejado, ótimo e improvável. Mas caso algo aconteça diferente, não precisa jogar fora seu cronograma, pelo contrário, nessa hora ele vai ser extremamente útil. Alguma pessoa que executava a tarefa X ficou doente, meu cronograma furou por causa disso?
Em qual área do mundo quando se perde um profissional de vasta experiência a velocidade de execução não é alterada? E só no desenvolvimneto de software eu não consigo resolver?
Existem N maneiras de se manter no rumo caso algum imprevisto aconteça. Existem N maneiras de se chegar em uma estimativa realista, como também existem mais N formas de se tentar corrigi-la.
Outra coisa que achei estranha, o uso de cronogramas é inversamente proporcial a pequenas entregas?!
Guilherme, parabéns pelo texto.
[]s
Oi Marcio,
“Mas caso algo aconteça diferente, não precisa jogar fora seu cronograma, pelo contrário, nessa hora ele vai ser extremamente útil.”
Curiosidade: para que exatamente?
Concordo com tudo que foi colocado em ralação aos prazos nunca serem acertados. O problema é que, geralmente, quem vende software não desenvolve software e ao ser pressionado pelos clientes estabelece prazos que só Deus sabe de onde vieram e acontece um reação em cadeia, onde todo mundo começa a tentar estimar prazos para as “partes” do projeto para que se consiga entregar no prazo. Na minha opinião é necessário que, não só quem faz, mas também quem vende devem tentar convercer o cliente que pra ele é melhor participar efetivamente do desenvolvimento de um produto de qualidade e que atenda satisfatóriamente as suas necessidades do que receber alguma coisa em determinado prazo cheia de problemas….
ISSO Thiago! Esse é o caminho 🙂
Marcio Says:
“Outra coisa que achei estranha, o uso de cronogramas é inversamente proporcial a pequenas entregas?!”
Oi, Márcio!
Tudo beleza?
Este seu questionamento me fez refletir sobre o que havia escrito acima (“é fato que clientes ficam extremamente felizes com pequenas entregas modularizadas”).
Você tem razão, o uso de cronogramas NÃO É inversamente proporcional às pequenas entregas.
Fui pontual e acabei usando um exemplo que acontece MUITO dentro de algumas áreas da nossa fábrica de software: o coordenador do projeto é o ÚNICO a receber/cobrar as pequenas entregas definidas no cronograma.
O cliente só vê/cobra o produto na data final do cronograma e, quando o projeto como um todo atrasa, e quase sempre atrasa, temos problemas …
Não é dos melhores modelos de coordenação/gestão de desenvolvimento de software, de fato, e acabei generalizando e me expressando mal.
No mais, o Thiago foi brilhante!
Grande abraço!
Excelente post Chapiewski!
Ótimo post ! Um dia desses conversando com os estagiários de onde trabalho, fiquei assustado, pois todos saem “inocentes” pensando que este tipo de abordagem (cronogramas gigantes e chutados) funciona. Acho que esta questão, leva a outro tópico interessante, o quanto um professor desatualizado sem experiência na área mais “estraga” os alunos do que os ajudam.
sucesso!
Olá pessoal,
Bom Guilherme, “caso algo aconteça diferente” o seu cronograma vai te dar subsídio para suas ações. Se na tarefa de “integração com um sistema em C utilizando um protocolo não muito bem documentado baseado em HTTP” o gerente de projetos, que juntamente com sua equipe ou colhendo opiniões especializadas, estimou 10 dias e colocou junto dessa tarefa, visto o risco percebido no planejamento, uma folga de mais 5 dias, todas essas informações irão estar no cronograma. Ou melhor, porque não prever no cronograma um tempo para planejamento do que ainda estar por vim no projeto, e aí sim, após esse planejamento, que já esta r previsto, definir componentes mais específicos, já que se trata de algo muito específico.
Concordo em parte com as suas colocações, apenas reintero o que falei anteriomente, se é pra generalizar, eu não diria que cronogramas não funcionam, eu diria que existem muitos cronogramas que não funcionam, mas é como falo no posto anterior, depende de muitos fatores.
Fabiano, entendi tua colocação!
[]s
Caramba … tudo bom Guilherme! .. ótimo post!
Eu li sobre isso na revista MundoJava n26 – “Entregue Software Funcionando – Gerenciamento de Projetos Ágil” e fiquei muito surpreso pois na faculdade passei todo o tempo desenvolvendo projetos com Gantt Charts .. e realmente o que o Roger Leite disse:
“Um dia desses conversando com os estagiários de onde trabalho, fiquei assustado, pois todos saem “inocentes” pensando que este tipo de abordagem (cronogramas gigantes e chutados) funciona.”
é verdade! e agora fiquei super decepcionado com o professor, por nos ter ensinado algo inútil e não eficaz para o desenvolvimento de software…
e ele ainda dizia – “coloquem em seus currículos que agora vcs sabem usar MSProject / Gantt Charts” .. meu deus, tirei o mais rápido que pude!!! =))
abraços !
Guilherme,
Claro que sou suspeito para falar deste assunto, já gerenciei muitos e muitos projetos usando cronogramas, estimativas de esforço com uso pontos de função, casos de uso de dezenas de páginas, levantamentos de requisitos de meses, milhoes de reais investidos e no final, NINGUEM satisfeito milhões de reais perdidos e projeto atrasado em meses pra não dizer anos.
Vários aqui já disseram e eu concordo, é IMPOSSIVEL mapear tudo o que vai acontecer em um projeto com meses de antecedencia, com ou sem margem de segurança, requisitos mudam, pessoas mudam, empresas mudam e o mercado muda. Projetos precisam se adaptar rapidamente pois os clientes na maioria das vezes não sabem o que querem, e vão descobrindo isso com o andamento do projeto. Não dá pra trabalhar escrevendo _Change Requests_ toda vez que um cliente muda de idéia, isso vira um inferno de aprovação de documentos, trava o andamento e atrasa de vida de todo mundo.
Depois de passarmos a usar SCRUM, conseguimos adicionar compromisso e comprometimento as pessoas da equipe, demos poder a elas para decidir o que é melhor ser feito para atingir ao Goal do Sprint/Release, e quando vc dá empowerment ao time as coisas decolam sozinhas, as estimativas ficam mais precisas, as entregas são feitas com qualidade e o time melhora sozinho. Estou realmente impressionado com o que conseguimos fazer e no tempo que conseguimos fazer usando SCRUM e o melhor é que nunca tive clientes tão satisfeitos, e não precisamos perder tempo e dinheiro com MS Project.
[…] de garantia de que o Time vai entregar alguma coisa em alguma data. Eu cada vez mais acredito que cronogramas não funcionam e não tem como garantir […]
[…] Sei que isso pode parecer irreal para você que está num waterfall enraízado, porém, tente pelo menos. Tenha um ambiente mock para desenvolvimento, isso pode te salvar ao manter sua tarefa “verdinha” no Gantt Chart. Sim, todos nos sabemos que o Gantt Chart não funciona, porém eu e você que estamos no waterfall temos que usar e até fingir que funciona. […]
A grande sacada dos cronogramas está justamente na estimativa de software e isso depende de muito fatores que infelizmente são dificílimos de controlar. Uma equipe de software que esteja desenvolvendo um sistema em um domínio totalmente novo, não terá dados históricos suficientes para estimar corretamente.
Estudei um pouco sobre as técnicas COCOMO II, e pelo que pude ver, parece bem coerente, pois esta técnica se subdivide em várias atividades de estimativas que acontecem antes, durante e depois do projeto. Há um refinamento completo.
Certamente o desenvolvimento incremental e interativo sempre funcionaram muito bem, pois o cliente passa a ser parte da equipe e não um carrasco cobrando o trabalho pronto em prazos absurdos!
Desenvolvimento ágil realmente funciona!