Tu proyecto lleva meses sin avanzar. Alguien tiene que entrar a mirar por qué.
Una migración encallada. Un desarrollo que se alarga. Un proveedor que ya no da respuestas claras. Entro, miro qué está pasando de verdad (el código, las personas y también el contrato) y te digo qué se puede hacer. Aunque la respuesta sea parar.
Primera conversación sin coste. Si el problema no es el que crees, prefiero decírtelo antes de facturarte nada.
Cómo se ve un proyecto bloqueado desde dentro
Casi nunca hay un día en que el proyecto se para. Se va parando. Estas son las señales que suelen estar sobre la mesa cuando alguien me llama.
- La fecha de entrega se ha movido más de dos veces, y la última vez ya nadie preguntó por qué.
- Las reuniones de seguimiento se han convertido en reuniones de justificación.
- El proveedor responde con lenguaje técnico cuando le preguntas por plazos, y con lenguaje comercial cuando le preguntas por problemas técnicos.
- Hay tickets abiertos de hace seis meses que nadie cierra y nadie borra, porque cerrarlos sería admitir que no se van a hacer.
- Cada nueva funcionalidad rompe otra cosa, y el tiempo de arreglar lo roto ya es mayor que el de construir lo nuevo.
- El presupuesto va por el 80 % y el proyecto, por sensación, va por la mitad.
- El equipo interno y el proveedor no se hablan más que por el gestor de proyecto, y cada uno tiene su versión de por qué esto va mal.
- Ya has pensado en cambiar de proveedor, pero te frena una duda razonable: y si el nuevo llega, mira esto y dice lo mismo.
Si has reconocido cuatro o más, no tienes un problema de ejecución. Tienes un problema de información: nadie de los que están dentro puede darte una versión neutral de lo que ocurre, porque cada uno es parte.
Y si el proyecto avanza pero lo que no controlas es a quien lo hace, antes de cambiar conviene saber qué se rompió: gestión técnica de proveedores.
El problema no siempre es técnico. Casi nunca lo es solo.
Cuando un proyecto se bloquea, lo primero que se busca es un culpable técnico: el código está mal, la plataforma no aguanta, el desarrollador no da el nivel. A veces es verdad. Pero en bastantes de los proyectos bloqueados en los que he entrado, la parte técnica era el síntoma. Una parte del problema suele estar en el código. Otra parte suele estar en cómo se decide, cómo se prioriza y cómo se pide el trabajo.
Bloqueo técnico
La plataforma tiene una limitación real, o una decisión de arquitectura de hace tres años hace que cada cambio cueste el triple. Es el único que se arregla programando. También es el que menos veces aparece solo.
Bloqueo operativo
El trabajo entra por cinco sitios y no hay nadie decidiendo qué va primero, así que el equipo prioriza por orden de llegada o por orden de insistencia. El código está bien. El proceso, no. Esto no se arregla contratando más desarrolladores.
Bloqueo de decisión
Hay una decisión pendiente que nadie quiere tomar, casi siempre porque es cara, incómoda o política. Mientras no se toma, el equipo trabaja en lo que no depende de ella y el proyecto parece avanzar. No avanza. Solo se está entreteniendo.
Desde fuera los tres se parecen mucho: un proyecto que no llega. Se tratan de forma distinta. Por eso el primer trabajo no es arreglar nada, sino averiguar cuál de los tres tienes.
Qué hago cuando entro
No hay una plantilla. Hay un orden, y empieza por escuchar a todo el mundo antes de tocar nada.
Escucho las tres versiones
Negocio, equipo técnico y proveedor. Por separado. Cada uno tiene una versión coherente de por qué el proyecto va mal, y ninguna de las tres es completa. La foto real está en las contradicciones entre ellas.
Miro el estado real, no el reportado
El repositorio, el histórico de commits, los tickets, los entornos, los despliegues, las integraciones. No para juzgar el código, sino para saber si lo que se dice en la reunión de seguimiento coincide con lo que ha pasado de verdad.
Leo el contrato y las estimaciones
Qué se comprometió, con qué alcance, y qué se ha ido añadiendo por el camino sin renegociar nada. Una parte enorme de los proyectos bloqueados están bloqueados aquí, y nadie lo ha mirado.
Separo los tres bloqueos
Qué es técnico, qué es operativo y qué es una decisión que lleva meses esperando. Con nombres y apellidos: qué decisión, quién la tiene que tomar, y qué se desbloquea cuando se tome.
Te digo qué haría yo
No una lista de opciones. Una recomendación, con lo que cuesta, lo que tarda y lo que se pierde si se hace. Y con lo que pasa si no se hace nada.
Me quedo hasta que se mueve
Si quieres. Puedo entregarte el análisis y salir, o quedarme a coordinar la ejecución con tu equipo y tus proveedores. Eso lo decidimos después del análisis, no antes.
Qué te llevas
Documentos cortos que puedas enseñar en un comité de dirección sin traducirlos.
- Un informe de situación
- Qué está pasando, en lenguaje de negocio, con las evidencias detrás. Incluye lo que no te va a gustar leer.
- La separación de los tres bloqueos
- Qué parte del atasco es técnica, qué parte es operativa y qué decisiones están pendientes de tomar. Con responsables.
- Un plan de actuación priorizado
- Qué se hace primero, qué se hace después y qué no se hace. Con el coste aproximado y el riesgo de cada línea.
- Una recomendación explícita
- Continuar, reordenar, reducir alcance, renegociar, cambiar de proveedor o parar. Una de las seis. Argumentada.
Y si me quedo: coordinación de la ejecución, interlocución técnica con los proveedores y un informe de avance periódico que puedas leer en cinco minutos.
Cuándo tiene sentido llamarme
- Cuando el proyecto lleva meses sin avanzar y las explicaciones ya no te convencen.
- Cuando sospechas del proveedor, pero no tienes cómo contrastar lo que te dice.
- Cuando vas a cambiar de agencia y quieres saber qué te llevas y qué dejas atrás antes de moverte.
- Cuando el presupuesto se está consumiendo y necesitas decidir si seguir invirtiendo o cortar.
- Cuando el equipo interno y el externo se culpan mutuamente y no hay nadie neutral en la sala.
- Cuando la migración está a medias y volver atrás ya no es gratis.
- Cuando tú mismo dudas de si el problema es tuyo: de cómo se pidió, de cómo se decidió, de cómo se gobernó.
Cuándo no soy la persona adecuada
- Si lo que necesitas son manos
- Si sabes exactamente qué hay que construir, quién lo va a hacer y en qué orden, y solo te falta capacidad de desarrollo, contrata desarrolladores o una agencia. Yo saldría caro para eso.
- Si ya has decidido y solo buscas quien lo firme
- Si la decisión está tomada y lo que hace falta es un informe externo que la respalde, no soy tu opción. Puede que mire lo mismo y llegue a otra conclusión.
- Si el problema es de producto o de mercado
- Si el proyecto no avanza porque nadie tiene claro para quién es o qué debe hacer, eso no es dirección técnica. Es una conversación distinta, y hay gente mejor que yo para tenerla.
- Si nadie dentro quiere que esto se mire
- Un rescate necesita acceso: al código, a la gente y a los contratos. Si esa puerta está cerrada por política interna, el trabajo no se puede hacer bien, y prefiero no empezarlo.
- Si la urgencia es de hoy para mañana
- Entender de verdad una situación lleva días, no horas. Si necesitas una respuesta esta tarde, la respuesta responsable es que no puedo dártela.
Un rescate no siempre termina en rescate
Nadie contrata esto para que le digan que pare. Pero a veces esa es la conclusión, y decirla es parte del trabajo. Estos son los seis finales posibles.
Desbloquear
Había un obstáculo concreto (una decisión, una dependencia, una persona) y se retira. El proyecto vuelve a moverse casi solo.
Reordenar
El trabajo estaba bien, el orden no. Se replanifica y lo que iba a tardar seis meses más se entrega en dos, con menos cosas.
Reducir alcance
El proyecto es viable, pero no el proyecto que se firmó. Se corta lo que no aporta y se entrega lo que sí.
Renegociar
El problema está en el contrato: alcance abierto, estimaciones que ya no valen, incentivos mal puestos. Se sienta uno con el proveedor y se rehace.
Cambiar de proveedor
A veces sí. Pero con un plan de traspaso, sabiendo qué se recupera y qué se pierde, y no en caliente después de una mala reunión.
Parar
El proyecto ya no tiene sentido, o costará más terminarlo que el valor que va a devolver. Parar a tiempo es la decisión que más dinero ahorra y la que menos se toma, porque nadie quiere ser quien la propone. Yo puedo ser quien la propone.
Lo que no va a pasar es que te diga que todo está bien para poder seguir facturando, ni que te diga que todo está mal para venderte una reconstrucción.
Cómo se define el alcance
En la primera llamada no cierro precio ni plazo. Todavía no he visto el proyecto. Lo que cuesta un rescate, una due diligence o una dirección técnica externa depende del estado real del sistema, de los accesos que haya, de cuántos proveedores estén implicados, de qué documentación exista y de la urgencia.
- 01
Primera llamada para entender la situación
Treinta minutos, sin coste. Me cuentas qué pasa, yo pregunto, y salgo sabiendo si puedo ayudarte y qué tipo de trabajo encaja.
- 02
Si encaja, revisión inicial del contexto
Miro por encima lo que exista: documentación, accesos, contratos, quién está implicado. Aquí es donde se ve el tamaño real del problema.
- 03
Definición del alcance
Qué entra, qué no entra, qué dependencias hay y qué se puede dejar fuera sin perder el sentido del trabajo.
- 04
Propuesta por escrito
Con alcance, precio, plazo y entregables. Nada de horquillas abiertas: una propuesta que puedas comparar y defender.
- 05
Empezamos solo si los dos lo aprobamos
Si la propuesta no te convence, no pasa nada y no has pagado nada. Si no me convence a mí, te lo digo antes.
Prefiero parecer prudente a parecer rápido. Un presupuesto dado en treinta minutos, sin haber mirado nada, se incumple en la semana tres.
Cuéntame qué lleva parado y desde cuándo.
Me explicas la situación, te digo qué veo desde fuera y qué haría yo si fuera mi proyecto. Si de esa conversación sale que no me necesitas, mejor saberlo el primer día que el tercer mes.
Me cuentas qué está pasando y desde cuándo.
Te digo si esto huele a bloqueo técnico, operativo o de decisión.
Si encaja, definimos un alcance inicial y te llega una propuesta cerrada antes de empezar.
Lo que me preguntan antes de empezar
¿En qué se diferencia esto de una auditoría técnica?
Una auditoría técnica mira el estado del sistema y te lo cuenta. Un rescate mira el estado del sistema, el de la organización y el del contrato, y además se queda a mover las cosas. La auditoría responde «cómo está esto». El rescate responde «qué hacemos ahora». Y si lo que vas a hacer es comprar o invertir, la pregunta es otra: la due diligence técnica.
¿Vas a decirle a mi proveedor que lo está haciendo mal?
No entro a repartir culpas, entro a averiguar qué pasa. En muchos casos el proveedor está haciendo exactamente lo que se le pidió, y el problema es lo que se le pidió. Cuando sí hay un problema de proveedor, lo digo con evidencias y en privado, primero a ti.
¿Necesito darte acceso al código?
Sí, al menos en lectura. También a los tickets y a las personas. Sin eso puedo darte una opinión, pero no un diagnóstico, y no quiero cobrarte por una opinión.
¿Cuánto tarda?
No lo sé antes de mirarlo, y desconfía de quien te lo diga en media hora. Depende del tamaño del proyecto, de cuánta gente haya que escuchar y de qué documentación exista. En la primera llamada entiendo la situación; si veo que puedo ayudarte, te digo qué información necesito para preparar una propuesta con alcance y plazo cerrados.
¿Y si me dices que hay que parar el proyecto?
Entonces habrás pagado un análisis para dejar de pagar un proyecto. Suele ser la mejor relación entre lo que cuesta y lo que ahorra de todo lo que hago.
¿Trabajas con mi equipo o lo sustituyes?
Trabajo con él. No vengo a ocupar el puesto de nadie, y si en el análisis sale que sobra o falta gente, eso es una recomendación para ti, no una oferta mía.
¿Puedes rescatar un proyecto de una plataforma que no conoces?
Los tres tipos de bloqueo son los mismos en cualquier stack, y dos de los tres no son técnicos. Si el bloqueo resulta ser puramente técnico y de una tecnología que no domino, te lo digo y busco a alguien que sí. Donde más terreno tengo pisado es en eCommerce: Magento, Shopify y BigCommerce.