abordarei a questão da perspectiva da engenharia de software, embora muitas das lições aprendidas também se apliquem a outros projetos. Produzir estimativas precisas de projetos é uma das tarefas mais difíceis de fazer em Engenharia de software e uma habilidade muitas vezes esquecida que a maioria dos engenheiros (inclusive eu) não sabe fazer bem. Também é o caso de pessoas que não precisaram estimar os tempos de conclusão dos projetos antes tenderem a subestimar a dificuldade e muitas vezes errarem suas estimativas em pelo menos um fator de dois. Como qualquer habilidade, só se melhora com a prática.
minha memória mais vívida das estimativas do projeto deu errado aconteceu alguns meses depois de ingressar como engenheiro na Ooyala, uma startup que forneceu uma plataforma de vídeo online de ponta a ponta. Em agosto de 2008, apenas pouco mais de um ano após a fundação da empresa, a equipe de engenharia começou a trabalhar em uma reescrita do player de vídeo baseado em Flash do produto. Nossos objetivos eram tornar o jogador mais modular e mais eficiente e também ter uma base de código mais limpa e melhor testada. Uma equipe inicial de 3 pessoas projetou e escreveu alguma infraestrutura central antes de puxar para mim e para o resto da equipe de engenharia de ~ 10 pessoas. Eles estimaram 4 meses para o projeto ser concluído, e o CTO e o gerente de produto produziram gráficos de Gantt resumindo o detalhamento e as dependências do trabalho. O novo jogador acabou sendo totalmente lançado 9 meses depois, em maio de 2009 .
perdemos o alvo não por falta de trabalho duro ou engenheiros talentosos; houve uma série de meses em que a maioria das pessoas na equipe puxou 70-80 horas por semana (não recomendado). No meio do projeto, até mesmo passamos meticulosamente por alguns dias de exercícios em que atribuímos estimativas horárias a tarefas bastante granulares. Os maiores atrasos quase sempre resultaram de fatores, muitos externos, que não consideramos nas estimativas iniciais:
- alta prioridade cliente lida sendo assinados, que exigia que os engenheiros de alternância de contexto para o trabalho personalizado,
- bugs no Adobe flash player código que tornava difícil determinar com precisão quando o vídeo era na verdade uma pausa, buffer, e jogando,
- difícil reproduzir vídeo bugs de corrupção que iria falhar, o jogador quando se busca a determinados quadros de vídeo no internet explorer,
- desenvolvimento de produtos de que necessitam para continuar a 4 meses de projeto, a fim de manter a base atual de clientes felizes
- problemas de escalabilidade que precisavam ser tratados como a quantidade de os dados analíticos cresceram,
- um engenheiro inicial deixando a equipe no meio do projeto, necessitando de uma grande quantidade de transferência de conhecimento das principais partes da base de código,
- etc.
enquanto a reescrita do jogador era definitivamente necessária para a empresa, a maneira imprevista em que se arrastou teve um grande impacto na inicialização inicial. Outros projetos em que trabalhei, vi em segunda mão ou conversei com outros engenheiros seguiram padrões semelhantes nos quais o tempo real de conclusão geralmente dobra as estimativas originais.
Aqui estão algumas das minhas lições takeaway tão longe dessas experiências:
tanto quanto possível, ter as pessoas produzindo as estimativas para uma tarefa ser as pessoas reais que vão trabalhar nele. Isso é semelhante ao ponto de Ian McAllister de usar a estimativa do Jogador B – já é incrivelmente difícil para uma pessoa prever com precisão quanto tempo uma lista de Tarefas levaria para fazer, mesmo que as tarefas sejam bastante granulares; é ainda mais difícil prever quanto tempo levaria outra pessoa com um grau diferente de familiaridade e um grau diferente de habilidade. Tornou-se evidente durante a reescrita do jogador de Ooyala que muitas das estimativas iniciais eram extremamente agressivas e ignoravam o tempo de aceleração de um engenheiro em partes da base de código com as quais ele estava menos familiarizado.
Cuidado com o efeito do segundo sistema. No mítico homem-mês, Frederick Brooks descreve a partir de suas experiências de projeto na IBM como uma tendência humana de projetar demais o segundo sistema leva a um aumento substancial da complexidade, fazendo com que os horários dos projetos de redesenho escorreguem :
o primeiro trabalho de um arquiteto é apto a ser sobressalente e limpo. Ele sabe que não sabe o que está fazendo, então ele faz isso com cuidado e com grande moderação.Como ele projeta o primeiro trabalho, folho após folho e embelezamento após embelezamento ocorrem a ele. Eles são armazenados para serem usados ” da próxima vez.”
mais cedo ou mais tarde, o primeiro sistema está concluído, e o arquiteto, com firme confiança e um domínio demonstrado dessa classe de Sistemas, está pronto para construir um segundo sistema.
este segundo é o sistema mais perigoso que um homem já projeta… A tendência geral é projetar demais o segundo sistema, usando todas as idéias e babados que foram cautelosamente desviados no primeiro.
especialmente para um projeto que envolve reescrever software existente, é tentador agrupar uma série de novos recursos no que de outra forma poderia ter sido uma porta simples, usando o argumento de que a equipe também poderia fazê-lo se eles vão reescrever a base de código de qualquer maneira. O aumento da complexidade não pode levar à reescrita nem aos novos recursos lançados até significativamente mais tarde.
tenha cuidado ao confundir quanto tempo as tarefas de um projeto levarão com o quão cedo antes de um projeto terminar. Quanto mais tempo um projeto leva, maior a probabilidade de que variáveis ambientais externas entrem em jogo e estendam o cronograma geral do projeto. O arrasto recorrente que Ian menciona contribui para a linha do tempo de um projeto, mas também eventos inesperados. Para projetos em que trabalhei no início deste ano no Quora, vários deles demoraram mais para serem lançados do que o esperado devido aos custos cumulativos de tempo de:
- responder e recuperar de uma forma inesperada, multi-dia da AWS interrupção,
- tratamento de perioidic pager dever alertas para manter o site no ar,
- agendados férias que parecia longe de um projeto, mas que acabou se sobrepondo com ele,
- preparar e participar de eventos de recrutamento,
- troca de contexto entre vários projetos que acabou por ser mais complicado do que inicialmente esperado.
para qualquer projeto, pode-se provavelmente listar qualquer número de eventos e distrações que individualmente podem ser improváveis ou não, mas que coletivamente estão fadados a acontecer e somar em um período de tempo suficientemente longo. Quanto mais tempo o projeto, mais distrações haverá, e é importante para o orçamento de tempo de buffer para fatores externos, desconhecidos.
Orçamento tempo suficiente para quaisquer tarefas relacionadas à integração. Especialmente para projetos com muitos componentes inter-relacionados, muitos engenheiros tendem a 1) adiar tarefas de integração de ponta a ponta até o fim e 2) subestimar significativamente a quantidade de tempo necessária para integrar todas as peças em um sistema de trabalho. Porque a integração tende a estar tão longe e porque os riscos são tipicamente desconhecidos-a suposição pelo tempo de integração é que todos os componentes funcionam com sucesso isoladamente-subestimar o tempo de integração tende a ser bastante comum. Os projetos geralmente recebem apenas uma fração minúscula do tempo total do projeto para testes de ponta a ponta, embora seja normalmente um dos aspectos mais arriscados de um projeto e, em comparação com Marcos anteriores, requer substancialmente mais sobrecarga de comunicação entre os membros da equipe.
o corolário para isso é iniciar o teste de ponta a ponta o mais cedo possível para identificar riscos e problemas de integração mais cedo, para que haja tempo suficiente para abordá-los.
estimativa com base em quanto tempo as tarefas realmente levarão, não com base em quanto tempo você ou outra pessoa deseja que elas demorem. Sempre haverá pressão para concluir projetos mais rapidamente, seja de você mesmo, dos membros da sua equipe, da administração ou dos clientes, e muitas vezes a resposta emocional a essa pressão nos ancora a cronogramas exigidos externamente e nos leva a subestimar sistematicamente as tarefas. Psicologicamente, ninguém quer decepcionar outras pessoas, e é fácil dizer a si mesmo que, se você trabalhar um pouco mais ou com mais eficiência, poderá cumprir um determinado prazo. Especialmente para projetos longos, no entanto, esse tipo de pensamento positivo é, em última análise, insustentável.
revisitar e revisar periodicamente as estimativas do projeto à medida que o projeto prossegue. Assim como a forma como a maioria dos bons softwares é construída e melhorada de forma incremental, também são estimativas de projetos. Revisitar as estimativas do projeto e comparar estimativas para tarefas na semana passada com o tempo real necessário ajuda a superar erros de estimativa e revisar cronogramas com base em riscos anteriormente imprevistos.
as estimativas do projeto quase sempre tendem a ser subestimadas em vez de superestimadas; raramente se ouve falar de projetos longos terminando antes do previsto. Estar ciente de que a estimativa do projeto é difícil e refletir sobre por que as estimativas deram errado em um projeto específico o guiará para erros de estimativa menores em projetos subsequentes.Há muito mais para executar em um projeto do que apenas produzir estimativas precisas. Se você é um engenheiro e deseja dominar as técnicas usadas pelos principais engenheiros de software para transformar seus projetos em sucessos, Baixe um capítulo de amostra grátis do meu livro, The Effective Engineer. Está repleto de centenas de histórias, insights e estratégias acionáveis de líderes em todo o Vale do Silício.
———-
http://en.wikipedia.org/wiki/Gantt_chart
http://go.ooyala.com/Swift.html
http://www.the-wabe.com/notebook/second-system.html