“Necesitamos esta función para finales de trimestre; la competencia acaba de lanzar la suya.”
Ya lo has oído. Quizá incluso lo hayas dicho. La presión por entregar más rápido no es nueva, pero algo ha cambiado. Ahora tenemos backlogs ágiles, OKR, compromisos de sprint y gráficos de velocidad: herramientas que prometen previsibilidad. Sin embargo, las conversaciones sobre plazos imposibles no han desaparecido. Simplemente han adquirido un nuevo vocabulario.
La competencia lanza una función que no estaba en tu hoja de ruta. Marketing se compromete con una fecha de lanzamiento en una presentación de ventas. La junta directiva pregunta por qué la velocidad es de “solo 32 puntos” en este sprint. Y el equipo de ingeniería se encuentra en medio, obligado a negociar la realidad con quienes creen que el software se desarrolla simplemente trabajando más.
Ahora añadamos otro factor: proveedores que prometen que la IA resolverá sus problemas de productividad. ¿Para qué invertir meses en la mejora de procesos —enseñando a estimar, creando disciplina de planificación, ganándose la confianza mediante la constancia— cuando una herramienta afirma que puede multiplicar por diez su producción mañana mismo?
Porque los problemas fundamentales no se solucionan con mejores herramientas. Simplemente se automatizan.
¿Quién paga cuando la realidad no coopera?
Trabajé en el departamento de TI de una aseguradora: 15 personas que atendían a partes interesadas internas que los trataban como un simple departamento de pedidos. Las prioridades cambiaban constantemente. Las interrupciones a mitad de sprint eran habituales. El sprint de dos semanas se había convertido en una broma amarga.
Cuando llegué, la confianza se había esfumado. En el ámbito empresarial, la pregunta “¿cuándo estará listo?” se hacía con una sospecha apenas disimulada. Los retrasos en el desarrollo de productos se trataban como contratos vinculantes en lugar de como el inicio de conversaciones. Todos trabajaban a destajo. Nada funcionaba bien.
El problema no era la metodología. No eran las herramientas. Era la rendición de cuentas.
Convocamos una reunión conjunta —técnicos y responsables de negocio reunidos en una misma sala—. Hice una pregunta sencilla: «Cuando interrumpimos un sprint, ¿de quién es la culpa?».
La habitación quedó en silencio.
Elaboramos reglas que se ajustaban a su contexto. Si surgía un requisito crítico a mitad del sprint que debería haber estado en el backlog, es un error del Product Owner. El negocio asume el coste de la replanificación. Si ingeniería descubre que una historia se estimó muy mal y tiene que descartarla a la mitad, es responsabilidad de ingeniería. El departamento de TI asume la responsabilidad de ese fallo.
La filosofía era sencilla: visibilizar el coste de la disrupción y asignarlo de forma justa. No para castigar, sino para generar conversaciones honestas sobre las ventajas e inconvenientes.
En tres meses —de cuatro a seis sprints— el equipo empezó a cumplir sistemáticamente con lo prometido en la planificación de cada sprint. No porque trabajaran más, ni porque adoptaran una herramienta nueva, sino porque ya nadie interrumpía el sprint. Cuando sabes quién paga las consecuencias del caos, el caos resulta caro.
Ningún asistente de IA redactó esas reglas. Ninguna herramienta de optimización de velocidad creó esa responsabilidad. Requirió conversaciones difíciles, acuerdos específicos para cada contexto y la disciplina para cumplirlos.
La era de las herramientas no ha resuelto esto.
La era de las herramientas ha aportado herramientas de asistente de IA queSon realmente útiles. Pueden acelerar la codificación, detectar errores y sugerir mejoras. Pero no solucionan los incentivos mal alineados. No generan responsabilidad por las interrupciones. No enseñan a tu equipo a realizar buenas estimaciones ni a tus interesados a respetar los límites de planificación.
En todo caso, las nuevas herramientas han dificultado la negociación de fechas. Los gráficos de velocidad implican una predictibilidad inexistente. Los OKR crean una urgencia artificial. El “compromiso de sprint” suena a promesa cuando en realidad es una previsión. Y ahora la IA promete multiplicar por diez la productividad de los desarrolladores, lo que los responsables interpretan como “podemos exigir diez veces más trabajo”.
Watts Humphrey escribió sobre elMercado en llamas comoUn factor motivador: la presión competitiva que impulsa a las organizaciones a avanzar más rápido o arriesgarse a quedar obsoletas. Esa presión es real. La solución no es ignorarla ni esperar que la próxima herramienta la resuelva. Se trata de construir sistemas donde se puedan tener conversaciones honestas sobre capacidad y recursos sin temor.
Cuando tus competidores parecen moverse rápido (y más rápido que tú), no intentes alcanzarlos tratando instantáneamente de moverte más rápido.Desde mis inicios jugando al tenis, cuando la pelota del oponente es más rápida que la tuya, no intentas golpearla más fuerte, ¡intentas prepararte un poco antes!Para el desarrollo de software, la lección es¡Avanzar de forma sostenible y construir cosas que funcionen es la clave del éxito a largo plazo!
Empieza por el proceso, no por las promesas.
El trabajo de ingeniería bien planificado rara vez se retrasa. Lo contrario también es cierto: el trabajo mal planificado siempre se retrasa, por muy buenas que sean las herramientas. Si tu equipo incumple constantemente los plazos de entrega, la solución no es adoptar asistentes de programación con IA ni la última plataforma de gestión de proyectos. La solución es mejorar la planificación.
Enseñe a estimar. Cree espacios para el seguimiento y el ajuste. Acuerde las reglas para las interrupciones. Haga visible el costo del caos. Genere confianza mediante la entrega constante, no con esfuerzos heroicos ni soluciones tecnológicas milagrosas.
La negociación de fechas no desaparece. La promesa de herramientas más rápidas no la hará erradicar. Pero cuando se cuenta con evidencia, un proceso y un historial comprobado, se negocia desde una posición de fortaleza, no de desesperación. Y cuando se adoptan nuevas herramientas —ya sean de IA o de otro tipo— se utilizan para potenciar los fundamentos sólidos, no para disimular los problemas.
Si bien los principios que aquí se presentan son sencillos, su implementación efectiva suele requerir una comprensión profunda del contexto particular de su equipo. Ahí es donde el coaching basado en evidencia marca la diferencia, acelerando su camino hacia una productividad sostenible. Exploremos cómo el coaching personalizado puede ayudarle a generar confianza mediante la entrega constante de resultados y a afrontar con seguridad la presión de plazos imposibles. Contáctenos hoy mismo y transformemos sus negociaciones de fechas límite, pasando de conflictos a conversaciones colaborativas de consenso.
Discover more from The Software Coach
Subscribe to get the latest posts sent to your email.
