Presupuestar una web: por qué el primer número casi nunca es el bueno
Hace un par de años cerré un presupuesto con un cliente del sector inmobiliario en cuarenta horas de desarrollo. Al final del proyecto habíamos facturado setenta y dos. No fue porque pidieran cosas nuevas cada semana, que también, sino porque el presupuesto original no tenía ni una hora reservada para lo que yo llamo “cosas que no sabemos que no sabemos”: en este caso, que su CRM tenía una API sin documentar y que integrar el formulario de contacto con eso nos costó casi tres semanas de ida y vuelta con su proveedor.
Desde entonces presupuesto distinto. No mejor en el sentido de “más barato” ni “más rápido”: distinto en la estructura. Antes ponía un número por funcionalidad y sumaba. Ahora separo tres bloques: lo que sé hacer porque lo he hecho quince veces (login, blog, formularios, un carrito simple), lo que depende de un tercero que no controlo (pasarelas de pago, CRMs ajenos, APIs de proveedores del cliente) y lo que es directamente incertidumbre de diseño, o sea, decisiones que el cliente todavía no ha tomado aunque crea que sí.
El segundo bloque es el que me ha reventado presupuestos más veces que ningún otro. Cuando alguien dice “solo hay que conectarlo con nuestro ERP” yo ya sé, por experiencia, que esa frase esconde entre cero y cuarenta horas de trabajo y que no lo voy a saber hasta que vea la documentación, si es que existe. Ahora cotizo esa parte aparte, con un rango, y dejo claro por escrito que el número final depende de lo que encontremos. Algunos clientes se incomodan con esa ambigüedad. Prefiero que se incomoden en la propuesta a que se incomoden en la factura final.
Hay otra cosa que cambié: dejé de presupuestar en horas sueltas por tarea y empecé a presupuestar por semanas de dedicación real. Da igual que una tarea “debería” tardar seis horas si en la práctica un desarrollador tiene reuniones, otros proyectos y el cliente tarda cuatro días en responder un email con una duda de una línea. Un proyecto de “seis semanas de trabajo” en la práctica dura diez o doce en calendario, y si el presupuesto no lo refleja, el cliente se lleva la sorpresa a mitad de camino, que es el peor momento posible para dársela.
Lo que no he conseguido resolver, ni creo que se resuelva del todo, es el presupuesto cerrado con alcance abierto. Un cliente quiere saber el número final antes de firmar, y a la vez no sabe todavía qué quiere exactamente. Yo puedo ajustar el proceso, meter fases, cobrar un descubrimiento previo de una semana antes de dar cifra en firme, pero al final alguien tiene que decidir con información incompleta, y ese alguien casi siempre soy yo. La última vez que lo intenté sin fase de descubrimiento previa, en un proyecto de un comercio online mediano, terminé comiéndome ocho horas de mi margen solo para no tener la conversación incómoda de subir el precio a mitad de proyecto. No sé si hice bien. Sé que la próxima vez la fase de descubrimiento va a estar en el contrato, se use o no se use.