Os prazos perdidos são comuns nos trabalhos de programação? [fechadas]

18

Era o meu trabalho freelancer na oDesk. Eu já fiz vários trabalhos mais cedo, mas foi a primeira vez que perdi o prazo. Foi um trabalho muito longo e eu tentei o meu melhor, mas ainda perdi o prazo. Agora estou com muito medo. Porque é minha culpa que eu perdi o prazo.

Minha pergunta é: essa é uma grande preocupação ou os prazos perdidos são comuns entre os trabalhos de programação, por isso não devo me preocupar muito com isso?

freelancing deadlines
fonte
1
Depende completamente do meio ambiente. Por exemplo, meu último trabalho foi em uma agência digital que cobrava dos clientes com base em estimativas. Se você perdeu o prazo, o negócio perdeu dinheiro. Meu trabalho atual é tão dinâmico que não há prazos reais. Se minha atenção for necessária em outro lugar, tenho tempo apropriado para me dedicar a ele. Talvez incluir isso em sua pergunta ajude com respostas.
22613 Simon Simonhead
possível duplicata de Qual é a maneira mais eficaz de comunicar possíveis atrasos no desenvolvimento de software?
Gnat
3
prazos não cumpridos são comuns em todos os postos de trabalho
Steven A. Lowe
2
Eu realmente espero que você esteja se comunicando com o cliente sobre o prazo não cumprido. A falta de prazos acontece, mas não deve ser inesperado quando ocorre - você deve poder vê-lo chegando e se comunicar sobre isso. Isso geralmente torna mais fácil do que apenas "Não, ainda não está pronto".
22413 Bobson
6
Faça rápido, faça barato, faça bem: escolha dois.
Reactgular

Respostas:

45

Sim. Prazos perdidos são comuns no desenvolvimento de software.

Muitos freelancers cumprem os prazos incorrendo em dívidas técnicas ou escondendo a sujeira debaixo do tapete.

Parafraseando o Mês do Homem Mítico de Frederick Brooks :

Frederick Brooks, autor de The Mythical Man Month

  • Muitas vezes, os prazos são perdidos porque os líderes de projeto continuam a estimar as tarefas de software da mesma forma que as tarefas de engenharia civil, o que é uma abordagem falha porque o software é uma indústria nova e artesanal, sem um corpo claro de normas. Isso é tão verdadeiro que você não pode revogar a "permissão" de um programador para codificar por negligência, nem processar alguém por programar sem título.

  • O desenvolvimento de software tem uma complexidade inerente que falta a outras disciplinas. Um grande programa pode ter mais componentes que um carro e esses componentes podem interagir de mais maneiras diferentes.

  • É difícil visualizar o software; portanto, diferentes tipos de diagramas são usados ​​para ver diferentes aspectos de um projeto, e esses aspectos podem não ser ortogonais. A engenharia civil, por outro lado, possui projetos que permitem ver encanamentos, fiação etc. tudo no mesmo gráfico (ou camadas) de forma ortogonal.

  • Não é comum, após a construção de uma ponte ou construção, o cliente alterar completamente o escopo do projeto. Esse é geralmente o caso em projetos de software.

  • O estado da arte no desenvolvimento de software não chegou ao ponto em que os projetos de software são repetíveis e quase sem risco. Até as maiores empresas de software como a Microsoft podem perder prazos em meses ou anos.

  • A maioria dos vaporware nada mais é do que projetos de software que foram cortados por causa desses tipos de problemas.

Em conclusão:

Estimativas ruins e subestimação da complexidade, devido à natureza artesanal do processo de desenvolvimento de software, significam que ele permanece uma disciplina imatura.

Tulains Córdova
fonte
11
+ Boa resposta, mas tendo tido alguma exposição à engenharia mecânica e civil, é divertido como os programadores fazem comparações fáceis com a construção de pontes e outras coisas, quando não têm a menor idéia de como elas são construídas.
Mike Dunlavey
3
Eu concordaria com a idéia de que o software é plano (em termos de plano de engenharia - descrevendo todos os detalhes do projeto). No caso da engenharia, o tempo de construção física domina uma variação tão grande no planejamento não desempenha um papel. No entanto, como o software consiste apenas em um plano ... "O estado da arte no desenvolvimento de software não chegou ao ponto em que os projetos de software são repetíveis e quase sem riscos" - nesses casos, por que o projeto é de todo? Se algo é repetitivo e pode ser automatizado, ele não precisa ser feito várias vezes, mas pode ser feito uma vez e copiado.
Maciej Piechotka
2
@ user61852: Você me entendeu mal. O 'plano' da engenharia é como 'fonte' da ciência da computação - ou seja, descrição detalhada de cada componente - mas, uma vez que o tenhamos, podemos construí-lo (entrar makeou o que for). O que é 'plano' na ciência da computação seria um 'plano' do plano 'na engenharia. A diferença é que, makena ciência da computação, leva no máximo algumas horas enquanto a escrita do código-fonte (incluindo testes e integração) leva meses, enquanto na engenharia o planejamento pode levar meses (incluindo o cálculo estrutural), enquanto a construção leva anos. por último.
Maciej Piechotka
1
@ user61852: Em relação à repetitividade - uma coisa que os computadores são ótimos é na automação. Digamos que você precise criar um blog simples - no momento em que você teria 'estimativas' precisas, você obterá um wordpress (ou qualquer outro sistema de blogs) para que você não precise fazer nada (em caso de ponte) você ainda tem um ambiente diferente, portanto, você precisa se adaptar com mais cuidado, pois a rocha pode ser diferente ou pode haver um habitat para pássaros ou destruir a vista) - os programadores podem ser mais responsáveis ​​por criar as ferramentas (o modelo de ponte padrão).
Maciej Piechotka
2
Bônus por citar o Mês do Homem Mítico; Frederick Brooks mantém-se depois de todos esses anos porque se concentra nas pessoas e não na tecnologia.
precisa
3

Os prazos perdidos não devem se tornar uma prática comum se você quiser continuar a conseguir empregos.

Com isso dito, você normalmente deseja deixar um espaço extra de "mexer" em suas estimativas, caso as coisas aconteçam (e sempre acontece). Você não precisa divulgar que adicionou em tempo extra, apenas não o torne irracional. Talvez entre 5 - 10% do tempo total? A única maneira de descobrir é fazê-lo algumas vezes.

Para se tornar realmente bom em estimativas, você precisa saber quanto tempo leva para codificar um certo tipo de widget ... por exemplo, digamos que você precise criar um widget de rolagem infinito para o cliente X. Se demorar uma semana Para implantá-lo na produção sem erros, você pode usá-lo como linha de base para suas infinitas estimativas de rolagem.

TJ Trapp
fonte
2
Eu sempre dou 20% de espaço ao fazer estimativas. 5-10% é muito pouco. Eu acho que depende de quanto você está distraído. Desenvolvedor solo pode não se distrair em nada #
30/07/2013
Eu sou um desenvolvedor solo e costumo ter uma margem de 10% para meus projetos.
Konsole
Hmmm ... veja Hofstadter's_law
Philip
1
Comparado com 5-20%, acho que uma margem de 100% é melhor. Seriamente. Ele permite que você explore suas opções muito melhor. E responda a mais perguntas no Stack Exchange.
Acumenus
Ah, sim, a culpa é do desenvolvedor quando um gerente de projeto veterano de 15 anos pressiona um engenheiro de software novato de 1,5 anos para lhe dar uma estimativa e depois ajusta para que seja ainda mais agressivo e age como se o desenvolvedor estivesse frouxo quando o projeto fosse desossado . Eu nunca trabalhei para um gerente ou gerente de contas que pudesse escrever software, e você está me dizendo que os prazos perdidos não devem se tornar uma prática comum se você quiser continuar recebendo empregos? Os prazos perdidos são endêmicos porque a maioria dos PMs é literalmente incompetente em seus empregos. Meu melhor gerente ainda não era engenheiro de software, apenas conhecia seus limites.
dez
3

A falta de prazos não é incomum no desenvolvimento de software. É quase impossível estimar com precisão quanto tempo levará um projeto de software.

O profissionalismo é mostrado em como você lida com isso. Quando souber que perderá um prazo, informe o seu cliente o mais cedo possível para que ele possa planejar adequadamente.

Philipp
fonte
2

É bastante comum, mas você pode melhorar. Você pode querer avaliar usando algo abstrato, como pontos da história , e acompanhar sua velocidade para calcular suas estimativas reais. Esses conceitos são mais comumente associados ao scrum, mas podem ser usados ​​mesmo que você não faça o scrum.

O incrível da velocidade é que ela abrange todas as coisas intangíveis, como interrupções e complexidade inesperada, pelas quais os desenvolvedores têm dificuldade em contabilizar suas estimativas. Todas as probabilidades atingem a média ao longo do tempo. Média em 10 semanas, nossas estimativas de velocidade foram precisas em cerca de 5%. No entanto, quando estimamos as mesmas tarefas em horas, a mesma equipe exata subestima de 30 a 50%.

Karl Bielefeldt
fonte
1

Minha teoria (não comprovada) é que os humanos evoluíram para subestimar trabalhos complicados em dois ou três a um. Sempre que o Congresso pergunta à NASA algo como: quanto custará construir um ônibus espacial ou viajar para a lua, eles voltam dentro de uma semana com um número. Depois de esgotar todos os custos esperados, descobrem que custará três vezes mais.

Tivemos uma piada na década de 1970: pegue qualquer estimativa de programador, duplique o número e depois mova-o para a próxima unidade de tempo. Portanto, se um programador disser que isso pode ser feito em duas semanas, ele terminará em quatro meses.

Se alguém remodelou uma cozinha, geralmente pensa: 'Bem, eu vou fazer isso em duas semanas'. Eles terminam cerca de seis semanas depois.

Meredith Poor
fonte
1
O que a NASA tem a ver com a minha pergunta?
1
Mais precisamente, o que a evolução humana tem a ver com sua pergunta? A NASA é um exemplo claramente documentado no registro público de pessoas treinadas e experientes que subestimam grandes projetos. Em suma, sua experiência é "natural".
Meredith Poor
Embora eu concorde que as estimativas da maioria das pessoas sejam pelo menos duplas, mas a próxima unidade de tempo ... hmmmm. De qualquer forma, a NASA é muito boa em estimar tarefas que eles já sabem fazer. O problema é que as pessoas não são muito boas em estimar tarefas quando não sabem o que não sabem. Como a NASA faz um trabalho verdadeiramente pioneiro, não é de admirar que eles não saibam muito sobre o que estão fazendo até começar a fazê-lo. Assim, o motivo da subestimação inicial. Além disso, algumas pessoas estão predispostas a serem otimistas e outras pessimistas. Não tenho certeza se a evolução está envolvida.
Dunk