¿Son comunes los plazos incumplidos en los trabajos de programación? [cerrado]

18

Era mi trabajo de freelance en oDesk. He realizado varios trabajos antes en un tiempo determinado, pero esta fue la primera vez que no cumplí el plazo. Fue un trabajo muy largo y lo intenté lo mejor que pude, pero aún no cumplí el plazo. Ahora tengo mucho miedo. Porque es mi culpa que no haya cumplido el plazo.

Mi pregunta es: ¿Es esto una gran preocupación o se pierden los plazos comunes entre los trabajos de programación, por lo que no debería preocuparme demasiado por esto?

freelancing deadlines

1

Depende completamente del medio ambiente. Por ejemplo, mi último trabajo fue en una agencia digital que cobraba a los clientes según las estimaciones. Si no cumplió con la fecha límite, el negocio perdió dinero. Mi trabajo actual es tan dinámico que no hay plazos reales en absoluto ... si se requiere mi atención en otro lugar, me dan el tiempo apropiado para dedicarlo. Quizás incluir esto en su pregunta le ayudará con las respuestas.

— Simon Whitehead

posible duplicado de ¿Cuál es la forma más efectiva de comunicar posibles retrasos en el desarrollo de software?

— mosquito

3

los plazos vencidos son comunes en todos los trabajos

— Steven A. Lowe

2

Realmente espero que te hayas comunicado con el cliente sobre la fecha límite perdida. Los plazos que faltan suceden, pero no debe ser inesperado cuando lo hace, debe poder verlo venir y comunicarse al respecto. Por lo general, es más fácil que simplemente decir "No, aún no está listo".

— Bobson

66

Hazlo rápido, hazlo barato, hazlo bien: elige dos.

— Reactgular

45

Si. Los plazos vencidos son comunes en el desarrollo de software.

Muchos freelancers cumplen con los plazos incurriendo en deudas técnicas u ocultando la suciedad debajo de la alfombra.

Parafraseando el mes del hombre mítico de Frederick Brooks :

Frederick Brooks, autor del Mes del hombre mítico

A menudo se pierden los plazos porque los líderes del proyecto continúan estimando las tareas de software de la misma manera que las tareas de ingeniería civil, lo cual es un enfoque defectuoso porque el software es una industria artesanal novedosa sin un cuerpo claro de normas. Esto es tan cierto que no puede revocar el "permiso" de un programador para codificar por negligencia, ni puede demandar a alguien por programar sin un título.
El desarrollo de software tiene una complejidad inherente que otras disciplinas carecen. Un gran programa puede tener más componentes que un automóvil, y estos componentes pueden interactuar de más formas diferentes.
El software es difícil de visualizar, por lo que se utilizan diferentes tipos de diagramas para ver diferentes aspectos de un proyecto, y estos aspectos pueden no ser ortogonales. La ingeniería civil, por otro lado, tiene planos que le permiten ver plomería, cableado, etc., todo en la misma tabla (o capas) de forma ortogonal.
No es común, después de que un puente o edificio esté medio construido, que el cliente cambie completamente el alcance del proyecto. Este suele ser el caso en proyectos de software.
El estado del arte en el desarrollo de software no ha llegado al punto en que los proyectos de software sean repetibles y casi libres de riesgos. Incluso las compañías de software más grandes como Microsoft pueden perder los plazos por meses o años.
La mayoría de los programas de vapor no son más que proyectos de software que se cortaron debido a este tipo de problemas.

En conclusión:

Las malas estimaciones y la subestimación de la complejidad, debido a la naturaleza artesanal del proceso de desarrollo de software, significa que sigue siendo una disciplina inmadura.

— Tulains Córdova
fuente

11

+ Buena respuesta, pero habiendo tenido cierta exposición a la ingeniería mecánica y civil, es divertido cómo los programadores hacen comparaciones fáciles para construir puentes y otras cosas, cuando no tienen la menor idea de cómo se construyen.

— Mike Dunlavey

3

Me suscribiría a la idea de que el software es plan (en términos de plan en ingeniería, describiendo cada detalle del proyecto). En el caso de la ingeniería, el tiempo de la construcción física domina, por lo que una gran variación en la planificación no juega un papel. Sin embargo, como el software consiste en un solo plan ... "El estado del arte en el desarrollo de software no ha llegado al punto en que los proyectos de software son repetibles y casi libres de riesgos", en esos casos, ¿por qué el proyecto? Si algo es repetitivo y se puede automatizar, entonces no es necesario hacerlo en varias ocasiones, sino que se puede hacer una vez y copiar.

— Maciej Piechotka

2

@ user61852: Me entendiste mal. El 'plan' para la ingeniería es como 'fuente' para la informática, es decir, una descripción detallada de cada componente, pero una vez que lo tengamos podemos construirlo (ingresar makeo lo que sea). Lo que es 'plan' en informática sería un 'plan de plan 'en ingeniería. La diferencia es que makeen ciencias de la computación lleva pocas horas, mientras que escribir el código fuente (incluidas las pruebas y la integración) lleva meses, mientras que en ingeniería la planificación puede llevar meses (incluido el cálculo estructural) mientras que la construcción lleva años. Por lo tanto, la variación de la planificación tiene un impacto menor en este último.

— Maciej Piechotka

1

@ user61852: En cuanto a la repetitividad, una cosa en la que las computadoras son excelentes es la automatización. Digamos que necesita crear un blog simple: en el momento en que tenga 'estimaciones' precisas, obtendrá un wordpress (o cualquier otro sistema de blog) en su lugar, por lo que no necesita hacer nada de eso (en caso de puente todavía tiene un entorno diferente, por lo que debe adaptarse con más cuidado, ya que la roca puede ser diferente o puede haber un hábitat para pájaros o puede destruir la vista): los programadores pueden ser más responsables de crear las herramientas (el modelo de puente estándar).

— Maciej Piechotka

2

Bonificación por citar el Mes del Hombre Mítico; Frederick Brooks aguanta después de todos estos años porque se enfoca en las personas, no en la tecnología.

— Michael Shopsin

3

Los plazos vencidos no deberían convertirse en una práctica común si desea continuar obteniendo empleos.

Dicho esto, por lo general, desea dejar un margen adicional de "meneo" en sus estimaciones en caso de que suceda algo (y siempre sucede). No necesita revelar que ha agregado tiempo adicional, simplemente no lo haga irrazonable. ¿Quizás entre 5 y 10% del tiempo total? La única forma de averiguarlo es hacerlo varias veces.

Para ser realmente bueno en las estimaciones, debe saber cuánto tiempo lleva codificar un cierto tipo de widget ... por ejemplo, supongamos que debe crear un widget de desplazamiento infinito para el cliente X. Si le toma una semana para implementarlo en producción sin errores, puede usarlo como base para sus estimaciones de desplazamiento infinito.

— TJ Trapp
fuente

2

Siempre doy un 20% de espacio cuando hago una estimación. 5-10% es muy poco. Supongo que depende de lo distraído que estés. El desarrollador en solitario puede no estar distraído en absoluto

— B --овић

Soy un desarrollador en solitario y generalmente tomo un 10% de margen para mis proyectos.

— Konsole

Hmmm ... ver Hofstadter's_law

— Philip

1

En comparación con el 5-20%, creo que un margen del 100% es mejor. Seriamente. Le permite explorar sus opciones mucho mejor. Y responda más preguntas sobre Stack Exchange.

— Acumenus

Ah, sí, es culpa del desarrollador cuando un gerente de proyecto veterano de 15 años presiona a un ingeniero de software novato de 1.5 años para que le dé un estimado, luego ajusta que sea aún más agresivo y actúa como si el desarrollador se aflojara cuando el proyecto está deshuesado . Nunca he trabajado para un gerente o PM que podría escribir software, y ¿me estás diciendo que los plazos vencidos no deberían convertirse en una práctica común si quieres seguir buscando trabajo? Los plazos vencidos son endémicos porque la mayoría de los PM son literalmente incompetentes en sus trabajos. Mi mejor gerente todavía no era ingeniero de software, solo conocía sus límites.

— Bajista

3

La falta de plazos no es infrecuente en el desarrollo de software. Es casi imposible estimar con precisión cuánto tiempo llevará un proyecto de software.

La profesionalidad se muestra en la forma en que lo manejas. Cuando sepa que perderá una fecha límite, informe a su cliente lo antes posible para que pueda planificar en consecuencia.

— Philipp
fuente

2

Es bastante común, pero puedes mejorar en eso. Es posible que desee considerar la estimación utilizando algo abstracto como los puntos de la historia , y realizar un seguimiento de su velocidad para calcular sus estimaciones reales. Esos conceptos se asocian más comúnmente con scrum, pero se pueden usar incluso si no lo haces.

Lo sorprendente de la velocidad es que abarca todas las cosas intangibles como interrupciones y complejidad inesperada que los desarrolladores tienen dificultades para explicar en sus estimaciones. Todas las probabilidades promedian con el tiempo. Con un promedio de más de 10 semanas, nuestras estimaciones de velocidad han sido precisas en aproximadamente un 5%. Sin embargo, cuando estimamos las mismas tareas en horas, el mismo equipo exacto subestima constantemente en un 30-50%.

— Karl Bielefeldt
fuente

1

Mi teoría (no comprobada) es que los humanos han evolucionado para subestimar los trabajos complicados en dos o tres a uno. Cada vez que el Congreso le pregunta a la NASA algo como: ¿cuánto costará construir un transbordador o viajar a la luna? Regresan dentro de una semana con un número. Después de que se agoten todos los costos esperados, descubren que costará tres veces más.

Tuvimos una broma en la década de 1970: tome cualquier estimación del programador, duplique el número y luego muévalo a la siguiente unidad de tiempo. Por lo tanto, si un programador dice que se puede hacer en dos semanas, lo terminará en cuatro meses.

Si alguien ha remodelado una cocina, generalmente piensan 'Bueno, lo haré en dos semanas'. Lo terminan unas seis semanas después.

— Meredith Pobre
fuente

1

¿Qué tiene que ver la NASA con mi pregunta?

1

Más concretamente, ¿qué tiene que ver la evolución humana con su pregunta? La NASA es un ejemplo claramente documentado en el registro público de personas capacitadas y con experiencia que subestiman los grandes proyectos. En resumen, su experiencia es 'natural'.

— Meredith Poor

Si bien estoy de acuerdo en que las estimaciones de la mayoría de las personas se reducen al menos el doble, pero la siguiente unidad de tiempo ... hmmmm. De todos modos, la NASA es muy buena para estimar tareas que ya saben hacer. El problema es que las personas no son muy buenas para estimar tareas cuando no saben lo que no saben. Siendo que la NASA hace un trabajo realmente pionero, no es de extrañar que no sepan mucho sobre lo que están haciendo hasta que comienzan a hacerlo. Por lo tanto, la razón de la subestimación inicial. Además, algunas personas están predispuestas a ser optimistas y otras pesimistas. No estoy seguro de que la evolución esté involucrada.

— Dunk