Buena parte de lo que nos piden no deberíamos construirlo. Lo decimos antes de cotizar, no después de cobrar.
Suena raro viniendo de quien vive de desarrollar software. Pero un proyecto a medida que nadie usa a los seis meses cuesta dos veces: el dinero que se fue y el problema que sigue ahí. En una empresa de 5 a 50 personas eso no es una línea del presupuesto anual. Es el presupuesto.
Así que antes de estimar nada, filtramos. Este es el filtro, entero, sin la parte comercial. Está escrito para quien firma, no para quien programa.
Antes de nada: qué es una aplicación crítica
No es la más cara ni la más moderna. Es la que, si se cae un martes a las diez, manda a la gente a casa.
Suele ser una de estas cuatro: el ERP donde se hacen los albaranes, la intranet donde está el único listado bueno de clientes, la aplicación con la que el comercial cierra en casa del cliente, o la web por la que entra el pedido. A veces es un Excel de doce pestañas en una carpeta compartida. Un Excel puede ser perfectamente una aplicación crítica: si se corrompe y para la facturación, lo es, aunque no lo llame así nadie.
La pregunta útil no es «¿qué software tenéis?». Es «¿qué pasa el día que esto no arranque?». Si la respuesta es «nada, seguimos», no hay proyecto crítico. Si la respuesta es una cifra de facturación parada o cuatro personas mirando la pantalla, entonces hablamos.
El filtro, pregunta por pregunta
1. ¿Qué se rompe hoy, y cuánto cuesta que siga roto?
Casi nadie llega con esto medido. Llega con una molestia: «vamos lentos», «esto es un lío», «el sistema es antiguo».
Lo convertimos en horas. Cuánta gente, cuánto rato, cuántas veces por semana. Alguien que recopia pedidos de un email a un ERP durante hora y media al día son unas 330 horas al año. Eso ya es una cifra, y contra una cifra se puede decidir. Contra «vamos lentos» no.
La conversión sirve en las dos direcciones. Muchas veces el número sale grande y el proyecto se justifica solo. Otras muchas sale que el lío cuesta veinte minutos a la semana a una persona, y entonces lo honesto es decir que no se toca. Un desarrollo que ahorra veinte minutos semanales no se amortiza nunca, por barato que sea.
2. ¿Ya existe comprado, y cuesta menos?
Somos los primeros interesados en construir. Aun así, esta pregunta se hace en serio.
Facturación, nóminas, firma electrónica, tickets de soporte, CRM de manual, tienda online estándar, gestión documental: hay producto hecho, probado por miles de empresas y mantenido por alguien que no somos nosotros. Un mes de desarrollo a medida cuesta más que varios años de una suscripción de 60 € al mes. Si el producto de catálogo cubre el 90 % y el 10 % que falta es una costumbre interna que se puede cambiar, se compra y se cambia la costumbre.
Construimos cuando pasa una de estas tres cosas, y solo entonces:
- El proceso es la ventaja competitiva. La forma de cotizar, de rutar, de valorar el stock es lo que os diferencia. Adaptarla a un producto genérico es tirar el motivo por el que os compran.
- El producto existe pero no habla con lo vuestro. Hay solución, pero el coste real está en pegarla a un ERP de 2011 con la base de datos cerrada. Ahí lo que se construye es la integración, no la aplicación.
- El número no sale. Cinco licencias son asumibles; cuarenta y cinco usuarios a 45 € al mes son 24.300 € al año, para siempre. A partir de cierto volumen, lo de catálogo deja de ser lo barato.
Si no se cumple ninguna, lo decimos: compradlo. Se pierde el proyecto y se gana algo que vale más, que es que la próxima vez nos llamen para lo que sí toca.
3. ¿Quién lo abre el martes a las nueve?
Pedimos un nombre. No un departamento, no «los de administración». Una persona.
El software interno que no tiene un dueño con nombre dentro de la empresa se muere. No se muere de golpe: se muere despacio, en forma de gente que sigue usando el Excel viejo «para lo suyo» porque nadie ha decidido que eso se acabó. A los ocho meses hay dos verdades, la de la aplicación y la del Excel, y ninguna de las dos es fiable.
Ese dueño interno no tiene que ser técnico. Tiene que ser alguien con autoridad para decir «a partir del lunes esto se hace aquí» y que le hagan caso. Si en la primera reunión nadie puede decir quién es, el proyecto no está maduro, y ninguna cantidad de código lo arregla.
4. ¿De dónde salen los datos, y quién nos deja tocarlos?
Aquí es donde se van los presupuestos.
La pantalla que se ve es lo barato. Lo caro es que el dato llegue: sacar precios del ERP, escribir de vuelta el albarán, cuadrar el maestro de clientes que en un sistema tiene el CIF con guion y en el otro sin él. Antes de estimar preguntamos qué hay debajo, y las respuestas cambian el precio en un orden de magnitud:
- Hay API documentada. Bien. Se integra y se sabe cuánto cuesta.
- No hay API, pero hay acceso a la base de datos. Se puede, con cuidado: se lee, no se escribe, y se pacta con quien mantiene el sistema.
- Ni una cosa ni la otra, pero exporta CSV cada noche. Se puede vivir con eso. El precio es que el dato tiene horas de retraso, y eso hay que decirlo antes, no cuando el cliente pregunte por qué el stock no cuadra.
- El fabricante del ERP no autoriza el acceso, o cobra por él. Esto no es un problema técnico, es un problema contractual, y se resuelve antes de firmar nada. Un desarrollo que depende de un permiso que no tenéis es un desarrollo que no empieza.
De las cuatro respuestas, la única que hace que digamos que no es la última sin salida. Las otras tres son precio, no obstáculo.
5. ¿Quién lo mantiene dentro de dos años?
Todo lo que se construye hay que sostenerlo. Se actualiza el sistema operativo, caduca un certificado, cambia el formato de la factura electrónica, se jubila una versión de PHP.
Por eso proponemos siempre lo más aburrido que resuelva el problema. Tecnologías con diez años de vida por delante y con gente que sepa usarlas, aunque no seamos nosotros. Un stack exótico puede ahorrar dos semanas al principio y dejaros atados a un único proveedor durante ocho años. Ese proveedor seríamos nosotros, y sigue sin ser buena idea: el código es vuestro, el repositorio es vuestro, y la documentación se escribe para que otro pueda continuarla.
Un proyecto que solo puede mantener quien lo hizo no está terminado.
Cuándo decimos que no
Con nombre y apellidos, para que se entienda que no es retórica:
Cuando el proyecto existe para justificar una decisión ya tomada. Alguien compró una herramienta, no funcionó, y ahora hace falta un desarrollo que salve la compra. Se nota enseguida: el alcance cambia según quién esté en la sala.
Cuando se pide la plataforma antes que el primer usuario. «Queremos un portal donde los clientes, los proveedores y los comerciales…». Nadie ha usado nunca nada de eso. Lo que proponemos es lo contrario: una cosa, para un grupo, en producción, y decidir con lo que pase. Si la respuesta es que hace falta todo desde el día uno, no es nuestro proyecto.
Cuando no hay dueño interno. La pregunta 3, sin respuesta.
Cuando la conversación es solo el precio. No competimos por precio y no lo escondemos. La tarifa está calculada sobre lo que cuesta hacerlo bien; bajarla recorta el tiempo que os dedicamos cuando algo falla, que es justo lo que se está comprando. Si la decisión se toma comparando dos números, la decisión es de otro proveedor y lo decimos en la primera llamada.
Cuando alguien pide que nos hagamos cargo del soporte a sus usuarios finales, de su infraestructura o de una guardia de 24/7. No lo hacemos. Preferimos decirlo en la primera llamada a incumplirlo el primer fin de semana.
Decir que no rápido es un servicio. Un «no» en la primera llamada os devuelve tres meses.
Las señales de que el desarrollo a medida sí compensa
Al revés también hay patrones. Cuando aparecen dos o más de estos, casi siempre sale a cuenta construir:
- Alguien copia datos de una pantalla a otra pantalla, todos los días.
- El Excel de verdad lo mantiene una sola persona, y cuando esa persona está de vacaciones se para algo.
- El proceso que os hace ganar dinero no está escrito en ningún sitio: vive en la cabeza de dos personas.
- Los datos existen, pero para saber cualquier cosa hay que pedirle un informe a alguien y esperar.
- Vuestro cliente os pide algo por email que podría hacer solo, y os lo pide cuarenta veces al mes.
- La herramienta actual funciona, pero cada cambio pequeño depende de un proveedor que tarda semanas.
Ninguna de estas es una emergencia. Por eso se arrastran años. Y por eso el momento de mirarlas es ahora, no cuando la aplicación crítica se caiga de verdad.
Cómo funciona esto en la práctica
Se rellena el brief. Contestamos en menos de 24 horas laborables y mandamos propuesta en menos de 48. La propuesta lleva alcance, precio y lo que no incluye, escrito con la misma letra que lo que sí.
A veces esa propuesta dice que no construyáis nada. Que compréis un producto de catálogo, que cambiéis una costumbre interna, o que el problema real es un permiso que os falta y no un software que os falte. Esa respuesta también sale en 48 horas y también es gratis.
Qué hacer con esto
Coged el proceso que más os molesta hoy y contestad a la primera pregunta: cuánta gente, cuánto rato, cuántas veces por semana. Multiplicad. Si el número no llega a un par de miles de euros al año, dejadlo estar y buscad otro proceso.
Si llega, contádnoslo en el brief. Con las cinco respuestas de arriba ya sabemos si hay proyecto. Y si no lo hay, es lo primero que os diremos.