Un proyecto de cuatro semanas que acaba tardando diez rara vez perdió seis semanas por mal código. Las perdió esperando — una decisión, una aprobación, a alguien con las credenciales correctas para enviarlas, una respuesta a una pregunta que llevaba cuatro días en una bandeja de entrada. El tiempo de desarrollo y el tiempo de calendario son dos relojes distintos, y en la mayoría de los proyectos retrasados, la diferencia entre ambos es casi por completo tiempo en que nadie estaba programando realmente.
Las decisiones son el cuello de botella más habitual
Un desarrollador que llega a una bifurcación —dos formas razonables de construir una función, cada una con implicaciones distintas— tiene que detenerse y preguntar, porque adivinar mal cuesta más tiempo que preguntar. Si esa pregunta queda sin responder una semana porque necesita el visto bueno de alguien que está de viaje, todo el proyecto se estanca detrás de ella, aunque el trabajo real pendiente no haya cambiado. Designar a una persona con autoridad para responder estas preguntas, con un tiempo de respuesta máximo acordado, elimina este cuello de botella antes de que aparezca.
Los retrasos de acceso cuestan más de lo que parece
Un proyecto que necesita credenciales de un procesador de pagos, un registrador de dominios o un sistema existente a menudo no puede avanzar más allá de cierto punto sin ellas — y esas credenciales suelen estar en manos de un tercero, un exempleado o alguien a quien hay que recordárselo dos veces. Una semana perdida esperando el restablecimiento de una contraseña es funcionalmente idéntica a una semana perdida por un problema de código, salvo que era totalmente evitable si los accesos se hubieran reunido antes de empezar el proyecto, en lugar de solicitarse a medida que surgía cada necesidad.
La latencia de la retroalimentación se acumula a lo largo del proyecto
Una ronda de retroalimentación que tarda tres días en llegar en vez de uno no cuesta dos días una sola vez — cuesta dos días en cada punto de revisión del proyecto, y la mayoría de los proyectos tienen varios. Un equipo que se compromete desde el principio a un plazo de retroalimentación concreto, y lo trata como trataría una fecha límite de pago, elimina una fuente de retraso que de otro modo reaparece en cada hito, no solo en el primero.
Lo que realmente es responsabilidad del desarrollador
Nada de esto excusa retrasos de desarrollo genuinos — complejidad subestimada, deuda técnica descubierta, o un desarrollador simplemente retrasado son reales y son responsabilidad del lado de la entrega gestionarlos y comunicarlos con honestidad. Pero confundir un retraso causado por una pregunta sin responder con uno causado por código difícil lleva a aplicar la solución equivocada — más horas de desarrollador no acelerarán un proyecto que en realidad está esperando una decisión del lado del cliente, por muchas que se añadan.
Distinguir entre ambos importa
Nombrar en qué categoría cae un retraso, en el momento en que ocurre y no en la autopsia final, es lo que permite que un proyecto vuelva realmente al calendario, en lugar de que todos acuerden tácitamente no estar de acuerdo sobre de quién fue la semana.
Esto forma parte de la misma conversación de comprar, construir o configurar — una construcción bien gestionada solo se mantiene en el calendario si ambas partes gestionan el reloj que realmente corre, no solo el que mide el código.
Nuestro equipo de software establece expectativas de tiempo de respuesta y requisitos de acceso antes de empezar un proyecto, para que las semanas que de otro modo se perderían esperando simplemente no ocurran.
