#33 Normalmente en estos proyectos grandes, se crea un gráfico de barras con los bugs (tickets) en el tiempo.
Una la fase de diseño y desarrollo, donde se implementa todo lo que se quiere implementar se da por terminada, los testers empiezan a reportar bugs mediante tickets o el sistema que tenga la empresa.
Los tickets por resolver normalmente generan una forma de montaña en el eje temporal. Al principio hay pocos tickets por resolver, porque acaban de empezar el testeo, a medida que se testea van saliendo tickets y tickets y tickets y poco a poco el número de tickets pendientes crece porque el el equipo encargado de resolver estos tickets lo hace a un ritmo inferior al que salen los tickets.
Llega un punto que los tickets, porque el producto ya empieza a estar pulido, disminuyen, porque los que han de arreglar los problemas ya los arreglaron, y al no incorporar funcionalidades nuevas al proyecto es raro que se generen nuevos problemas.
El momento ideal de lanzamiento de cualquier producto es cuando esta curva está ya sobre 1/4 del final o después. Si lanzas el producto al principio porque piensas que tienes pocos ticktes es un error porque irremediablemente la montaña de errores llegará.
Por lo que han dicho, se sobreentiende, que el problema es que aún siguen saliendo tickets a un ritmo mayor del que son capaces de absorber, porque hay mucho aún por pulir.
Esto es extrapolable a cualquier producto complejo. Bien sea motos, tractores, aviones o software.