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!
Nem acredito que finalmente o Globo Vídeos mudou para Flash! Desde às 05:53 da manhã de hoje toda a nova infraestrutura de Flash Vídeo da Globo.com está em produção e funcionando muito bem, obrigado. Com isso nós nos igualamos aos maiores players do mercado como YouTube, Yahoo! Video, Metacafe e blip.tv.
Na última semana tive a oportunidade de assistir ao treinamento de