Hay una conversación que se repite en casi todos los proyectos que llegan a nuestra mesa con problemas, y siempre suena parecida: el informe dice «vamos por el ochenta por ciento» desde hace tres meses, las facturas siguen llegando puntuales y el dueño del negocio no tiene forma de comprobar si algo de eso es cierto. No suele ser un problema de confianza, sino de idioma, porque nadie le ha dado nunca una manera de medir el avance sin entender de programación.
Por qué nadie le da una respuesta clara sobre el avance
La razón de fondo es que dos cosas muy distintas se parecen mucho vistas desde fuera. Una es la actividad: reuniones, diseños que se aprueban, pantallas en las que alguien está trabajando, mensajes que confirman que el equipo está ocupado. La otra es el avance: algo que un cliente real podría usar hoy, tal cual, sin ayuda ni explicaciones. La actividad se ve todos los días y tranquiliza, mientras que el avance se ve pocas veces y es lo único que vale dinero, así que cuando un proyecto se tuerce casi siempre es porque durante meses se pagó la primera creyendo que era la segunda.
Conviene decir también algo que rara vez se dice en voz alta: casi todos los proyectos se desvían en algún momento, y esa desviación se sobrevive sin drama. Un retraso de tres semanas detectado en el mes dos se corrige recortando alcance o moviendo una fecha, mientras que el mismo retraso descubierto en el mes cinco ya se ha multiplicado, porque encima de él se han construido decisiones, contratos y promesas hechas a clientes. Lo caro nunca es la desviación en sí, sino enterarse tarde.
Todo lo que sigue está escrito para que usted pueda juzgar su propio proyecto sin saber qué es una base de datos ni cómo funciona un servidor. Son preguntas sencillas, y todas ellas de las que un equipo honesto agradece, porque le obligan a poner por escrito lo que ya sabe y le quitan de encima la incomodidad de dar buenas noticias imprecisas.
La única prueba que cuenta es un software que usted pueda tocar
Antes de nada hace falta una palabra. El entorno de pruebas, que muchos equipos llaman «staging», no es más que una copia privada del sistema, con su propia dirección web, donde el trabajo se puede revisar antes de que ningún cliente lo vea. Si su proyecto no tiene esa copia, ya tiene usted el primer hallazgo, porque significa que nadie ajeno al equipo ha podido comprobar nada todavía.
Con eso claro, aquí va la regla que sustituye a todos los porcentajes: si usted no puede abrirlo en su propio teléfono y usarlo, no está hecho, diga lo que diga el informe. Es una regla dura, pero es la única que no admite interpretaciones, y en cuanto se adopta las conversaciones cambian de tono en una sola semana.
En los desarrollos a medida que hacemos en Linkysoft el ritmo es siempre el mismo: una demostración semanal de treinta a cuarenta y cinco minutos en la que el cliente maneja el ratón. No una presentación narrada, ni un vídeo grabado, ni tres capturas de pantalla en un correo, sino el propio dueño del negocio entrando en el entorno de pruebas e intentando hacer algo real mientras el equipo mira en silencio. Resulta incómodo las dos primeras veces y después se convierte en la media hora más rentable de la semana.
Falta acordar el significado de una palabra que cada uno entiende a su manera. «Terminado» debería querer decir cuatro cosas a la vez: construido, probado, revisado por usted y funcionando en el entorno de pruebas. Cuatro casillas, no una opinión. Un desarrollo de aplicación web a medida contiene mucho más que pantallas, y precisamente por eso conviene fijar esa definición por escrito durante el primer mes, cuando todavía no duele.
Qué contiene un informe de estado útil y qué esconde uno vago
Un informe que sirve tiene tres partes y cabe en media página. La primera es qué se ha terminado desde la última vez y se puede pinchar ahora mismo, con el enlace incluido. La segunda es en qué se está trabajando esta semana y con qué fecha prevista. La tercera es qué está bloqueado y el nombre de quien lo tiene en su tejado, sea alguien del equipo, sea usted, sea un tercero. Si un informe no trae esas tres partes, no es un informe, es una nota tranquilizadora.
Existe también un pequeño vocabulario de palabras blandas que debería llevarle a preguntar una vez más: «casi», «prácticamente listo», «solo falta pulirlo», «pendientes de un par de cosas», «problemas de integración» y, sobre todo, cualquier frase que no lleve un sustantivo concreto dentro. Rara vez son mentiras, porque casi siempre son incomodidad, y la pregunta que las deshace es la misma en todos los casos: ¿qué puedo abrir hoy y qué falta exactamente para que eso ocurra?
Merece la pena darle la vuelta al asunto de los bloqueos, porque el instinto de muchos dueños es alarmarse cuando aparecen. Un equipo que nombra sus bloqueos es un equipo que sabe dónde está, mientras que un equipo que nunca tiene ninguno normalmente los está guardando para el final. Los bloqueos declarados se resuelven en días, y los escondidos reaparecen en el mes seis convertidos en semanas.
Para que no tenga que inventarse las palabras, copie estas tres preguntas en un correo y envíelas tal cual: ¿qué puedo abrir y usar hoy en el entorno de pruebas?, ¿qué está bloqueado ahora mismo y quién tiene que desbloquearlo?, ¿qué fecha tiene lo siguiente que voy a poder probar? Un equipo sano contesta en menos de un día, y contesta con enlaces.
Cinco comprobaciones que puede hacer esta semana, sin saber nada técnico
Ninguna de las cinco necesita conocimientos de programación y las cinco juntas caben en una tarde. Apunte las respuestas en un papel, porque el valor de verdad aparece cuando repita el ejercicio dentro de un mes y compare los dos papeles.
- La prueba del clic, diez minutos. Abra el entorno de pruebas en su propio teléfono, sin que nadie le guíe, y complete una tarea entera de principio a fin igual que la haría un cliente: entrar, buscar algo, pedirlo y llegar hasta la confirmación. Si se atasca a mitad de camino, ya sabe más sobre el estado real del proyecto que después de leer los tres últimos informes.
- La prueba del registro de cambios, quince minutos. Pida la lista escrita de todos los cambios solicitados desde el principio, con los días que costó cada uno y la fecha a la que movió la entrega. Que el alcance crezca entre un 15 y un 30 por ciento a lo largo de un proyecto de cuatro meses es normal y a menudo hasta sano, porque el negocio aprende mientras mira. Lo que no es sano es aceptar cambios sin anotar lo que cuestan, de modo que si esa lista no existe, el calendario que le enseñan no puede ser real.
- La prueba del registro de incidencias, diez minutos. Pregunte cuántos problemas hay abiertos hoy y cuántos había abiertos hace un mes, y compare las dos cifras sin más análisis. La dirección de ese número dice bastante más que cualquier porcentaje de avance.
- La prueba del alcance contra la factura, veinte minutos. Ponga la lista original de funcionalidades al lado del dinero gastado hasta hoy y cuente solo las que puede pinchar, nunca las que están «en curso». Es la comprobación que más incomoda a todo el mundo y también la que antes detecta un problema.
- La prueba de las dos personas, cinco minutos. Pregunte por separado a dos miembros del equipo qué va a pasar la semana que viene. Dos respuestas distintas significan que el plan vive en la cabeza de una sola persona, y eso es un riesgo bastante mayor que cualquier retraso puntual.
Si alguna de las respuestas le deja intranquilo, la reacción útil no es exigir más velocidad, sino pedir que le expliquen cómo se organizan las pruebas antes de cada demostración, porque casi todos los sustos que llegan al final nacen justo ahí.
La aritmética del calendario que cualquiera puede hacer
Deje de contar porcentajes y empiece a contar cosas. La pregunta es sencilla: en las últimas cuatro semanas, ¿cuántos elementos se terminaron de verdad y se pueden usar hoy? Ese número dividido entre cuatro es el ritmo real del equipo, y manda por encima de cualquier plan, porque el plan es una intención mientras que el ritmo es un hecho ya medido.
Veámoslo despacio con un caso corriente. Su proyecto tiene sesenta elementos en total, entendiendo por elemento cada pantalla o función que alguien puede abrir y usar. Hoy hay veinticinco terminados y comprobados. Durante el último mes se han cerrado tres por semana, ni uno más. Quedan por tanto treinta y cinco, y a tres por semana eso son unas doce semanas de trabajo, no las seis que dice el calendario colgado en la pared. Nadie ha mentido en ningún momento, simplemente nadie había hecho la división.
A esa cuenta hay que aplicarle una corrección que casi nunca se le explica al cliente. Una persona descrita como «a tiempo completo» entrega en la práctica entre 25 y 30 horas útiles de las 40 que tiene la semana, porque el resto se lo llevan las reuniones, la revisión del trabajo de otros, el soporte de lo ya entregado y el coste de saltar de una tarea a otra. Un plan construido sobre semanas de 40 horas nace un 25 por ciento optimista en el mejor de los casos y cerca de un 40 por ciento en el otro extremo de esa horquilla, antes incluso de que ocurra nada malo.
Queda la trampa del noventa por ciento, que se entiende mejor con números delante. Una funcionalidad declarada al 90 por ciento suele necesitar entre un 20 y un 40 por ciento adicional de su estimación original para cerrarse del todo, porque lo que queda no es la parte vistosa sino unirla con todo lo demás y probarla en serio. En una funcionalidad estimada en diez días, ese 90 por ciento significa entre dos y cuatro días por delante, no medio día. Cuando cinco funcionalidades están «al noventa» a la vez, el proyecto lleva escondidos entre diez y veinte días laborables, es decir, entre dos y cuatro semanas.
El trabajo que no se ve, y por qué las pantallas son solo un tercio
Ese trabajo invisible tiene nombres concretos y vale la pena decirlos en castellano llano: quién puede ver y hacer cada cosa dentro del sistema, las conexiones con los servicios de pago, de mensajería o de contabilidad, el traslado de los registros antiguos al sistema nuevo, las pruebas y las correcciones que salen de ellas, el trabajo de seguridad, las copias de respaldo y el propio día del lanzamiento. Nada de eso aparece en una pantalla bonita, y sin embargo todo eso decide si el sistema aguanta el primer lunes con clientes reales dentro.
De ahí sale la conclusión que a usted le interesa. Cuando los diseños están aprobados y las pantallas empiezan a existir, aproximadamente un tercio del trabajo está hecho, así que un proyecto que ha gastado la mitad del presupuesto en ese momento va razonablemente bien, mientras que uno que ha gastado el ochenta por ciento en el mismo punto tiene un problema serio que todavía nadie ha puesto por escrito.
La parte de seguridad y protección del sistema merece un párrafo aparte porque es la que nunca se ve en una demostración. Cerrar accesos, cifrar lo que debe ir cifrado, dejar registrado quién hizo qué y probar las copias de respaldo restaurándolas de verdad no cambia una sola pantalla, y aun así es lo que separa un sistema que se puede publicar de otro que no. Cuando alguien recorta plazo, esta suele ser la primera partida que desaparece, y también la única cuya ausencia no se nota hasta el día malo.
Dónde se pierden de verdad las semanas, y casi nunca es el código
Ordenadas de mayor a menor, las causas son casi siempre estas cinco:
- Las decisiones que esperan al comprador, que son con diferencia la porción más grande.
- El alcance que entra a mitad de obra sin volver a planificar.
- Los servicios de terceros, sea una pasarela de pago, un banco o un portal de la administración, donde los certificados, los entornos de prueba y las aprobaciones llegan cuando llegan y ninguna prisa suya los acelera.
- Las pruebas, siempre estimadas por debajo.
- La ausencia de una persona clave en el peor momento.
A la primera conviene ponerle cifras, porque sorprende. Un proyecto normal necesita entre 12 y 20 decisiones suyas, y la mayoría de esas esperas no cuestan nada, ya que el equipo se pone mientras tanto con otra cosa. Las caras son las pocas que dejan parado lo siguiente, y bastan dos o tres de ellas, cada una esperando una semana laborable, para producir las dos semanas y media del gráfico anterior sin que el equipo de desarrollo haya hecho nada mal.
Toca decir la parte incómoda con claridad: buena parte del retraso suele estar sobre la mesa del comprador, no sobre la del equipo. Es una buena noticia aunque no lo parezca, porque es justo la porción que usted controla del todo y la que puede empezar a arreglar esta misma semana sin gastar un céntimo.
El arreglo, de hecho, cuesta cero: una lista escrita de decisiones pendientes, con un nombre y una fecha al lado de cada una, revisada en la misma reunión semanal en la que se hace la demostración. Los desarrollos de seis meses que funcionan sin demostración semanal se desvían típicamente entre un 25 y un 40 por ciento, es decir que acaban durando de siete meses y medio a ocho y medio, y con esa lista y esa media hora semanal solemos verlos quedarse por debajo del 10 o el 15 por ciento.
Señales que significan algo y ruido que no
Hay cosas que asustan a los dueños y no deberían. Una fecha incumplida en una funcionalidad concreta es ruido, igual que lo es una pantalla intermedia con aspecto provisional, un programador que se toma una semana de vacaciones o una pantalla de administración fea que ningún cliente verá jamás. Todo eso forma parte del proceso normal de construir, y perseguirlo solo consigue que el equipo empiece a maquillar el trabajo en lugar de avanzar.
Y luego hay cinco señales que sí importan de verdad: dos demostraciones seguidas sin nada nuevo que pinchar, la lista de incidencias abiertas subiendo tres semanas seguidas, una propuesta repentina de reescribir el sistema desde cero, la definición de «terminado» moviéndose sin que nadie lo anuncie, y el silencio, que es la más grave de todas, porque los equipos a los que les va bien tienen ganas de enseñar lo que han hecho.
La aritmética de las incidencias es fácil de aplicar y no requiere ninguna herramienta. En las seis semanas anteriores al lanzamiento, un proyecto sano cierra más problemas de los que abre, y lo hace tres semanas seguidas. Si la lista de abiertos sube tres semanas seguidas, la fecha de lanzamiento ya se ha movido, lo haya dicho alguien en voz alta o no. Ante esa señal, la conversación correcta no es pedir más esfuerzo, sino preguntar cómo va la seguridad y las pruebas finales, que es donde se acumula todo lo que nadie quiere mirar de frente.
Leer el dinero contra el trabajo entregado
La comprobación de presupuesto cabe en una sola línea: compare el porcentaje de dinero gastado con el porcentaje de funcionalidades que usted puede pinchar. Si va por el 70 por ciento del dinero y el 40 por ciento de lo utilizable, el 30 por ciento de presupuesto que queda tendría que pagar el 60 por ciento del trabajo, y eso no ocurre nunca, así que a partir de ese punto solo hay tres salidas posibles: más dinero, menos alcance o una fecha distinta.
La forma de evitar llegar ahí es cambiar la manera de pactar los pagos. Un hito de calendario paga tiempo, mientras que un hito ligado a algo que usted puede abrir y usar paga avance, y aunque la diferencia parezca de matiz, cambia por completo lo que el equipo optimiza cada semana. En nuestros casos de éxito puede ver cómo se trocean proyectos reales en entregas pagadas y funcionando, en lugar de en meses facturados.
Queda una expectativa que conviene fijar desde el principio, porque casi nadie la incluye en su presupuesto inicial: el proyecto no termina el día del lanzamiento. Reserve entre el 15 y el 20 por ciento del coste de construcción cada año para alojamiento, actualizaciones, parches de seguridad y cambios pequeños. Un sistema de 15.000 lleva por tanto entre 2.250 y 3.000 al año de sostenimiento, y quien no lo presupuesta acaba con un sistema que se degrada solo hasta volverse un problema.
Ya sabe que va con retraso. ¿Y ahora qué?
La buena noticia es que solo existen cuatro palancas, así que la conversación es más corta de lo que teme: recortar alcance, mover la fecha, poner más dinero o parar. Cualquier otra propuesta que le hagan es una combinación de esas cuatro con otro nombre, y decirlo así de claro suele desbloquear reuniones que llevaban semanas dando vueltas.
La palanca del dinero conviene entenderla bien, porque añadir personas a un proyecto que ya va tarde lo hace más lento durante las primeras dos a cuatro semanas. Quien estaba construyendo pasa a explicar, y hasta que la persona nueva entiende el sistema no devuelve nada, de modo que sumar gente sirve cuando quedan meses por delante y no cuando quedan semanas.
La mejor respuesta suele ser otra: lanzar una primera versión más pequeña. El sesenta por ciento del alcance funcionando tres meses antes empieza a facturar, recoge opiniones de clientes de verdad en vez de suposiciones y muy a menudo paga el resto del desarrollo, aparte de que buena parte de lo que quedaba fuera deja de parecer necesaria cuando se mira con usuarios reales delante.
Sea cual sea la palanca elegida, el acuerdo hay que rehacerlo por escrito en una página: fecha nueva, alcance nuevo, qué ha cambiado y por qué, firmado por las dos partes. Un reinicio que no se escribe no es un reinicio, es simplemente el siguiente retraso silencioso esperando su turno.
Y si la respuesta honesta es parar, conviene saber lo que cuesta lo contrario. Hacerse cargo de un desarrollo abandonado o parado sale, según lo que nos encontramos en Linkysoft cuando nos llaman para rescatar uno, entre el 40 y el 70 por ciento de lo que costaría hacerlo de nuevo, y hacen falta de tres a seis semanas solo para entender qué hay construido antes de tocar una línea. Por eso detener a tiempo un proyecto equivocado casi siempre es más barato que empujarlo hasta el lanzamiento, y por eso no es un fracaso, sino una decisión de negocio como cualquier otra.
Cuando la opción pequeña y barata es la respuesta honesta
Hagamos la comparación en voz alta, con las cifras en la moneda que usted maneje, porque la proporción es la misma en todas. Una herramienta ya hecha, de las que se pagan por suscripción, ronda entre 30 y 80 al mes, o sea de 360 a 960 al año. Un desarrollo a medida suele arrancar entre 8.000 y 25.000, más ese 15 a 20 por ciento anual de mantenimiento del que hablábamos. La distancia es tan grande que el camino a medida necesita un motivo de verdad, no una preferencia.
Motivos válidos hay tres, y son fáciles de reconocer. El primero es tener una forma de trabajar que ningún producto del mercado soporta, no porque sea rara, sino porque es la que le hace ganar dinero. El segundo es estar obligado a custodiar usted mismo los datos, por normativa o por contrato con sus propios clientes. El tercero es una cuota por usuario que crece hasta superar el coste de construir, cosa que pasa antes de lo que parece cuando un equipo se duplica. Si no reconoce ninguno de los tres en su caso, lo más rentable es una herramienta ya hecha.
Lo decimos con todas las letras porque nos ha ahorrado disgustos: en Linkysoft rechazamos proyectos cuando una herramienta del mercado resuelve el problema, ya que un sistema que no debería haberse construido nunca va según lo previsto, por bien gestionado que esté.
Si decide seguir adelante, empiece el lunes con un ritmo muy simple y sosténgalo: una demostración semanal que usted maneja, un recuento mensual de los elementos que quedan, y una revisión cada tres meses para comprobar que el sistema sigue costando menos de lo que aporta. Con eso, sin ninguna herramienta de gestión ni ningún conocimiento técnico, verá venir cualquier desvío con meses de margen.
Si prefiere que alguien de fuera mire sus números con usted, puede escribirnos y pedir una segunda opinión, le salga seguir, recortar o parar. Y si lo que necesita resulta ser algo bastante más pequeño que una aplicación completa, empiece por el diseño y desarrollo de una web, que resuelve muchísimos casos por una fracción del coste y con la mitad de riesgo, sobre todo cuando el presupuesto disponible es ajustado.
