El riesgo de un proyecto a medida no es que el software salga mal. Es que salga tarde, cueste el doble y acabe usándolo nadie.
Estos son los cinco que se repiten y los mecanismos concretos con los que trabajamos. No son promesas: son cosas que pasan en fechas concretas del proyecto, y podéis exigirlas a cualquiera que os presupueste, no solo a nosotros.
Riesgo 1 — El alcance crece y el presupuesto no
Es el que se lleva la mayoría de los proyectos. No llega de golpe. Llega en forma de «ya que estamos, ponedle también…», dicho en una llamada de dos minutos, doce veces.
Cada una de esas peticiones parece pequeña. Sumadas son el margen del proyecto, y el momento en que el proveedor empieza a ir con prisa, a recortar por donde no se ve y a responder tarde.
Qué hacemos: todo lo que no esté en el brief inicial se cotiza antes de desarrollarlo, con una orden de cambio aprobada por escrito. Sin excepciones y sin cara larga: normalmente el cambio es buena idea y se aprueba. Lo que no hacemos es meterlo en silencio y pasar la factura después, ni construirlo gratis y ralentizar lo que sí estaba pactado.
Qué os toca a vosotros: decidir quién de vuestra casa puede pedir cambios. Si pueden pedirlos cinco personas, el proyecto tiene cinco alcances distintos.
Riesgo 2 — Descubrir al final que va tarde
Un proyecto no se retrasa tres meses de una vez. Se retrasa un día cada día, y eso solo se ve si alguien mira.
Qué hacemos: cuatro puntos de control con fecha. Antes de arrancar, se cierra el coste de infraestructura y licencias de terceros —no se aprovisiona nada sin saber lo que costará al mes—. Cada dos semanas, horas reales contra estimadas. A mitad de proyecto, desviación acumulada revisada con vosotros, antes de la fase de despliegue, que es donde el margen de maniobra desaparece. Y catorce días después de estar en producción, el coste definitivo contra el presupuestado.
La tolerancia es del 5 %. Por encima se para y se habla, no se sigue con la esperanza de recuperar. Y hay una regla que corta antes: si se ha consumido más del 80 % de las horas de una fase sin tener el 80 % de lo que había que entregar, se congela la entrada de tareas nuevas hasta entender qué está pasando.
Riesgo 3 — Ver el software cuando ya está hecho
La demo final es el peor momento posible para descubrir que os habíais entendido mal. A esas alturas, cambiar algo cuesta lo mismo que haberlo hecho bien y encima toca discutir quién lo paga.
Qué hacemos: demos cada dos semanas, con fecha fija cerrada el día del kickoff. Software funcionando, no capturas de pantalla ni informes de avance. Se ve, se toca y se dice lo que está mal cuando aún es barato arreglarlo.
Qué os toca a vosotros: que a esa demo venga quien va a usar la aplicación, no solo quien la ha pagado. Son opiniones distintas y las dos hacen falta.
Riesgo 4 — La entrega que nadie usa
Software correcto, entregado a tiempo, y a los seis meses el equipo ha vuelto al Excel.
Casi siempre es lo mismo: nadie de la casa era el dueño. Alguien pidió el proyecto, alguien lo firmó, pero no había una persona con nombre encargada de que se usara.
Qué hacemos: preguntarlo antes de cotizar. Si no hay un dueño interno identificable, lo decimos y a veces recomendamos no hacer el proyecto todavía. Perdemos la venta y nos ahorramos los dos un fracaso caro.
Qué os toca a vosotros: esa persona necesita tiempo asignado de verdad. Un dueño de proyecto que además tiene su trabajo completo no es un dueño, es un nombre en un acta.
Riesgo 5 — Quedaros atrapados con el proveedor
Es el miedo legítimo de cualquiera que ya se ha quemado una vez: que el día que queráis cambiar de proveedor, o simplemente contratar a alguien interno, nadie entienda lo que hay montado.
Qué hacemos: el contrato dice desde el primer día de quién es el código y qué pasa con él al terminar. Se firma antes de escribir una línea, no al final. Los accesos se piden con el mínimo privilegio necesario y por un canal seguro, nunca por email, y son vuestros: las cuentas de infraestructura y los repositorios están a vuestro nombre desde el principio.
Cuando hay migración de por medio, la ventana de corte y el plan de vuelta atrás se acuerdan en el kickoff. Antes, no durante. Un plan de rollback improvisado a las once de la noche de un sábado es como se pierden datos.
Lo que sí es un riesgo y no os vamos a cubrir
Por si lo estáis comparando con otra oferta que promete todo.
No damos guardia 24/7 ni acuerdos de nivel de servicio con penalizaciones. El horario de soporte es de lunes a viernes, de 9:00 a 19:00. Tampoco damos soporte a los usuarios finales de vuestros clientes ni alojamos vuestra infraestructura.
Si vuestra aplicación necesita que alguien responda a las tres de la madrugada de un domingo, necesitáis un equipo de guardia, y lo honesto es decirlo en la primera llamada en vez de firmarlo y fallar el primer fin de semana.
Cómo empieza esto
Rellenáis el brief en nordicbyte.co.uk/get-started. Respondemos en 24 horas laborables y en 48 tenéis una propuesta con alcance, supuestos y cifra. Ahí ya está escrito qué entra, qué no entra y qué pasa si algo cambia por el camino.
Si no os encaja, os habrá costado el rato de rellenar un formulario. Que es exactamente el riesgo que debería tener el primer paso.