¿Cuáles son las principales causas de retrasos en el producto (software)?

En mi experiencia, no validar su producto con frecuencia es una gran causa de demoras. Caes en la trampa de “¡Una característica más y es bueno!” En lugar de seguir con confianza en tu dirección. Las partes interesadas quieren contribuir más, los gerentes de producto quieren empujar más y nadie tiene idea de si lo que están construyendo es lo suficientemente bueno.

Estrechamente relacionado es esperar demasiado entre lanzamientos. Ponga en funcionamiento el software en funcionamiento rápidamente e impleméntelo con la frecuencia que tenga sentido. Cuanto más espere entre lanzamientos, mayor será el riesgo asociado.

La palabra “retraso” también tiene algunas suposiciones incorporadas. Es muy difícil (y no recomendado) para un equipo tener alcance, fecha límite y calidad como variables establecidas. Elige dos y haz que el tercero sea fluido. Esperemos que la calidad sea un valor no negociable en su organización, en cuyo caso solo el alcance o la línea de tiempo permanecen establecidos y definidos. Puede tener todo esto, o puede tener algo para una fecha establecida. Pedir todo esto en una fecha establecida es una receta para el fracaso.

En mi experiencia personal, hay dos cosas que tienen un alto impacto en el horario y una alta probabilidad de que ocurra:

• Alcance fluencia. Durante un proyecto de desarrollo, los clientes (y a veces incluso sus colegas) intentan incluir más y más funciones, ampliando el alcance de todo el esfuerzo. Esto causa dos problemas: 1) se necesita más tiempo para desarrollar funciones adicionales, 2) se necesita mucho más tiempo para garantizar la calidad general y la interoperabilidad, crear documentación, corregir errores, etc. – con cada nuevo componente, la complejidad del sistema aumenta exponencialmente.
  Naturalmente, eso arruina el plan original del proyecto y cualquier estimación de esfuerzo / tiempo. El desplazamiento del alcance es especialmente peligroso porque hay progreso todo el tiempo, por lo que todo se ve muy bien, pero sus objetivos originales no se están cumpliendo.
  Nota: esto no es lo mismo que Gold Plating, pero está relacionado en el sentido de que está haciendo un trabajo que tiene poco valor para el patrocinador de su proyecto.
• No o lentos comentarios de los clientes. Si no puede obtener comentarios tempranos y frecuentes de sus clientes, hay muchas posibilidades de que lo que está construyendo no sea lo que esperan, quieren y / o necesitan. Lo que significa que pasará más tiempo y esfuerzo cambiando las cosas cuando estaba a punto de terminar.
  Hay una regla simple que establece que cuanto antes reconozca un error, más fácil será corregirlo, por lo que si recibe comentarios en una etapa tardía, pasará mucho más tiempo reparándolo de lo necesario.

Esto depende de qué software se esté desarrollando. En mi experiencia (que no es más valiosa que la de cualquier otra persona), los retrasos fueron causados ​​con mayor frecuencia por el cambio de las especificaciones y la gestión del cliente, lo que les permitió hacerlo. Simplemente no había una especificación lo suficientemente rígida, probablemente causada por un meticuloso equipo de ventas que estaba preocupado de que el cliente acudiera a un competidor si no obteníamos el contrato rápidamente.

Cuando un programador está implementando una especificación que tiene el cambio de especificación continuamente, a menudo lo empuja a donde comenzó, porque estos cambios no se pueden planificar en la estructura original del programa.

Si está trabajando de la mano con el desarrollo de hardware, esto puede causar muchos retrasos imprevistos e inevitables. Recuerdo que una vez estaba desarrollando un controlador para un chip flash y encontré un problema que parecía estar en el software. Lo probé muchísimo (incluso hasta el punto de escribir un programa de prueba para demostrar que mi código original no tenía ningún error), solo para descubrir que no tenía nada de malo. Fui al hardware y les dije que su desarrollo debía tener una falla. Me miraron y se rieron (el diseñador jefe tenía más calificaciones que las que yo había cenado). Lo probé todo nuevamente y volví al hardware después de una semana más de tiempo perdido. Me habían dado un osciloscopio y tuve que demostrar que su hardware estaba defectuoso probando todos los tiempos de respuesta de componentes, voltajes y formas de onda de voltaje. No estaba entrenado para hacer esto, así que fue mi último intento. Encontré una falla con la CPU principal en dos de los pines de entrada. Devolvió los resultados al hardware. Ellos rastrearon la falla hasta un error en la documentación del chip que habían comprado.

Dijeron que tendrás que reescribir tu software. Dije que el software no puede solucionar un problema de direccionamiento de memoria de bajo nivel. Ese era el problema, los pines afectados eran pines de direccionamiento de memoria. Tuve que ser entrenado por el programador senior sobre cómo volver a direccionar todo el acceso a la memoria en C, sobre la marcha, para cada línea de código. Eso nos retrasó 4 semanas (incluida la búsqueda de la falla), pero la gerencia aún esperaba que entregara una solución de trabajo a tiempo (aunque la falla no había sido de software). Esa compañía me causó muchos fines de semana perdidos y vacaciones canceladas.

Entonces, para mí fue 1) Cambios del cliente a la especificación, y 2) Fallos en el hardware.

Otro problema común fue una solución de software que nos llevó a un callejón sin salida. Recuerdo una vez que nos pidieron que escribiéramos un controlador de computadora remoto múltiple en Java.

Escribí el código pero encontré un problema. La memoria se perdería hasta que la aplicación fallara. Lo rastreó hasta una limitación en la clase de recolector de basura. Ejecuté el programa a través de algún otro software para mostrar lo que estaba sucediendo en el funcionamiento interno del motor Java mientras se ejecutaba. Investigué las soluciones al problema y descubrí que no había otras cuentas enumeradas de este problema específico en Internet. Entonces, tuve que aprender a reescribir los recolectores de basura y anular el valor predeterminado incorporado. Eso demostró más de lo que tenía la experiencia. El problema es que podríamos haber resuelto fácilmente la pérdida de memoria en casi cualquier otro idioma, pero estábamos limitados a usar Java. Al final tuvimos que volar en un contratista para completar el proyecto.

Entonces, no 3), limitaciones fundamentales de software imprevistas o imprevisibles que están más allá de la capacidad del programador para resolver. Si otras personas se han enfrentado al mismo problema y lo han resuelto, eso ayuda, pero si no puede encontrar ningún indicio de una solución en línea y no hay tiempo para la investigación académica, realmente puede arrojar una llave en el trabajo.

Otra causa es la política de la oficina. Conocía a alguien que trabajaba como programador para una empresa de telefonía móvil. En la primera semana hubo una disputa interna que resultó en la renuncia de todos los programadores y el personal superior en desarrollo de software. Por lo tanto, se quedó como el ÚNICO programador en su primera semana, sin que quedara nadie para entrenarlo y ponerlo al día. Llamó a una reunión con la gerencia y exigió un aumento salarial de £ 35k. Se negaron, pero le dieron £ 4k en efectivo y un aumento salarial de £ 20k, por lo que se quedó. Logró hacer en 1 semana lo que me llevó 3 años lograr, bastardo con suerte. Sin embargo, tenía su trabajo hecho por él, así que no fue un viaje fácil.

Entonces, no 4) Política de la oficina. Cosas que un programador no puede controlar. Cosas dentro del negocio (no en la tecnología) que afectan negativamente el desarrollo del producto.

Para colmo:

1. Cambios tardíos en la especificación del software,
2. Hardware u otras fallas externas del sistema,
3. Limitaciones de software fundamentales imprevisibles,
4. Politicas de oficina.

Hay más, pero esos son los que inmediatamente vienen a la mente.

En mi propia experiencia, la falta de una hoja de ruta o estrategia de producto a largo plazo creará cambios y retrasos en los requisitos de manera constante.

Subestimar los desafíos tecnológicos y el esfuerzo de integración (si corresponde) también contribuyen de manera importante al retraso del producto.