Cómo presupuestar un proyecto de precio fijo para desarrollo: Mi método paso a paso

En este artículo te voy a explicar paso a paso mi método para presupuestar un proyecto de precio fijo o fixed price, para desarrollo web. Si te dedicás al diseño o programás para otras plataformas, igualmente este método te puede ayudar.

Quiero aclarar que mi método quizás no sea perfecto pero es el que suelo usar y a mí me da resultado. Al menos, me quita la incertidumbre de saber si estoy presupuestando bien o no.

Mi idea con este artículo no es que copies todo, sino que compares con lo que vos hacés y tomes lo que te sirve.

Será un artículo largo así que vamos de a poco. Comencemos definiendo qué es un proyecto fixed price.

Proyecto de precio fijo o fixed price

Un proyecto fixed price es aquél que se presupuesta, se le pone un precio, una fecha de entrega, se hace y se entrega.

Se diferencian de los proyectos ongoing que son los que nunca terminan y para los que se va cobrando por hora o por trabajo realizado.

La ventaja de los proyectos de precio fijo es que, en general, se desarrollan y se entregan. Se cobra el dinero y ya después uno puede seguir su camino. En algunos casos estos proyectos devienen en proyectos ongoing de mantenimiento, pero eso depende del proyecto.

La desventaja de los proyectos de precio fijo es que suelen llevar bastante tiempo de análisis, presupuesto y negociación con el cliente, hasta que finalmente este acepta la propuesta de desarrollo.

Por otro lado, cuando se terminan, hay que salir a buscar otro cliente. En realidad, esto hay que hacerlo con anticipación. En cambio, los proyectos ongoing te aseguran estabilidad. Sabés que hay cierta cantidad de trabajo fijo que vas a tener por mes.

Cómo presupuestar un proyecto de precio fijo

Presupuestar parece un arte y a algunos programadores y freelancers que recién empiezan esto les intimida. Me ha pasado. Uno no sabe qué referencia tomar y nunca termina sabiendo si pasó un presupuesto demasiado bajo o si se pasó.

Con el tiempo y la experiencia, se obtiene suficiente capacidad para superar este problema. Aquí he reunido una serie de pasos que hago a la hora de presupuestar.

Tras el primer contacto con el cliente, comienza la etapa de relevamiento donde se recopilan las necesidades que el sistema a desarrollar tiene que satisfacer. Pero para ser sincero, antes de esa etapa, siempre se parte de un pedido informal de presupuesto.

La estimación previa

En general, el cliente pregunta «en cuánto anda tal cosa». En otras palabras, cuál es el precio de una página web institucional, un sistema e-commerce o cuál es el de una intranet.

Como sabemos, es imposible determinar un precio en base a una pregunta tan amplia. Sin embargo, sí podemos saber en qué número estimado se arranca.

Yo suelo analizar esto en base a la frase «a partir de qué cifra empiezo a mover un dedo para un proyecto de esas características». Si es una página web estándar, no lo hago por menos de cierta cantidad de dinero. Si es una intranet, tengo otro valor, y así con cada tipo de sistema.

Es muy importante tener en la mente, o mejor, anotado en algún lado cuál es el precio base de estos sistemas típicos. Ayudan mucho a disuadir a personas que quieren trabajos pero no tienen dinero para pagarlos.

Lo que recomiendo siempre es aclarar que el número que se le facilita al potencial cliente no es el precio final, sino el precio base. Hay que recalcarlo bien para que luego no haya malos entendidos.

Relevamiento minucioso

Si pasado el número base inicial el cliente está de acuerdo con este número estimado, entonces es hora de hacer un relevamiento profundo para determinar todo lo que se necesita.

En esta etapa es necesario tener entrevistas con el cliente y preguntarle todas las dudas respecto a las necesidades a satisfacer con el sistema a desarrollar.

Conviene tener plantillas con preguntas típicas según el tipo de proyecto. Esto hace que no te puedas olvidar de ningún aspecto importante a relevar.

Toda la información recabada durante el relevamiento se utilizará en la etapa de presupuesto propiamente.

Paso previo al proceso de presupuesto

A continuación viene la parte del presupuesto propiamente. Hay muchos aspectos a tener en cuenta, pero antes de entrar de lleno en el proceso, hay dos que me gustaría resaltar.

Costos a tener en cuenta

Probablemente el proyecto a realizar requiere realizar algún gasto que en última instancia se le traslada al cliente y que por eso hay que considerarlos en el presupuesto.

Estos costos pueden ser los siguientes:

• Trabajo tercerizado: si sos programador, quizás trabajes con otros programadores o con diseñadores. Si sos diseñador, te puede pasar algo similar pero al revés. Si pasás alguna parte del proyecto a un tercero, entonces es necesario considerar el costo.
• Licencias de software: si se utiliza algún tipo de software que se deba pagar, entonces hay que tener esto en cuenta. Las licencias pueden ser de plugins, temas o cualquier otra pieza de software.
• Suscripciones a servicios: el más común en estos casos es el hosting. Puede o no estar incluido en el presupuesto. A veces, algunos clientes ya cuentan con su hosting.

Cotas superiores e inferiores

Durante el proceso de relevamiento es difícil no ir armando un presupuesto mental. En algún punto te vas dando cuenta de cuánto puede costar lo que el cliente está necesitando.

En este paso suelo utilizar un concepto simple pero efectivo que me sirve de brújula para el proceso que viene a continuación. Me refiero a las cotas.

Una cota es simplemente un número. Hay cotas inferiores y cotas superiores.

Una cota inferior es un número que se ubica por debajo del valor de lo que estamos considerando. En este caso, un presupuesto. Como habíamos dicho, si partimos de un presupuesto mínimo de la estimación inicial entonces ahí ya tenemos una cota inferior. Pero con lo aprendido en el relevamiento minucioso, podemos llevarla hacia arriba.

La cota superior es justamente lo contrario. Un número que se ubica por encima del valor que estamos considerando.

¿Cómo lo aplico? Hago un ejercicio mental exagerado. Me pregunto: «¿Vale un millón de dólares este proyecto?». Hasta el momento esa respuesta no ha sido afirmativa nunca. Luego me pregunto si vale 100.000 dólares. Luego, si vale 50.000, 10.000 y a partir de allí, el ejercicio que parecía fácil empieza a volverse más complicado.

En algún punto encuentro una cota superior de la que estoy seguro y hago lo mismo con la cota inferior. Entre esos dos valores, se supone, deberá estar el precio final.

El proceso de presupuestar

Ahora, sí, me voy a meter con el proceso de presupuesto paso a paso.

1. Análisis minucioso con estimación del tiempo necesario

El presupuesto se arma con un análisis profundo de cada una de las tareas que hay que llevar a cabo para poder realizarlo por completo. Para ello es necesario descomponer todo lo que hay que hacer en las unidades más básicas posibles.

A continuación, por cada una de estas tareas hay que estimar cuánto tiempo lleva. A mí me gusta medir el tiempo neto de trabajo. Te recomiendo que hagas lo mismo. Si te interesa saber cómo hacerlo, podés leer el artículo sobre 10 motivos para medir el tiempo de trabajo.

Está más que claro que la precisión en la estimación estará dada por la experiencia que vayas acumulando.

Es importante considerar todos los aspectos del proyecto: gestión administrativa, análisis y diseño de la aplicación, desarrollo, testing, implementación, documentación y mantenimiento.

Aquí te recomiendo usar una planilla de cálculo. Lo que ves en la siguiente imagen es sólo un ejemplo, pero la estructura es de este tipo:

Yo suelo volcar todas estas tareas en Google Spreadsheets donde anoto una descripción de la tarea, el tiempo que calculo me va a llevar completarla y… el tipo de tarea. Porque no todas las tareas son iguales. Esto nos lleva al siguiente punto.

2. Clasificar las tareas por tipo

Este paso es optativo, porque yo considero que cada tipo de hora tiene un peso distinto. Si no considerás lo mismo, entonces calculá un precio de hora promedio y salteá este paso. Pero me gustaría explicarte por qué lo considero así.

Para mí no es lo mismo una hora de desarrollo que una hora de análisis. No es lo mismo una hora de testing que una hora en la que hay que escribir documentación.

Una hora de análisis es una hora en la que tengo que concentrarme al 100% y no puedo tener ningún tipo de distracción. En cambio una hora de testing, por ejemplo, es una hora que puedo tercerizar y encomendar a otra persona. Las horas de desarrollo las puedo llevar adelante de forma más relajada. Las horas dedicadas al despliegue son para mí las de máxima concentración.

Actualmente clasifico las horas de la siguiente manera.

• Análisis: horas dedicadas a analizar la aplicación y diseñar la solución. Aquí entra la arquitectura de la aplicación, diagramas de clases y de bases de datos. No incluyo el análisis puntual de cada tarea, que lo considero hora de desarrollo.
• Desarrollo: son las horas de programación propiamente. De las que más insumen los proyectos.
• Reuniones: horas que se van en reuniones, sean virtuales o presenciales. Es posible hacer también esa distinción de ser necesario. Obviamente las horas de reunión presenciales deberían ser más caras que las virtuales.
• Administrativo / comercial: horas dedicadas a la confección del presupuesto, gestión comercial y al manejo de los sprints.
• Infraestructura / Despliegue: son las horas en las que tengo que realizar un despliegue o poner a punto un servidor.
• Testing: horas dedicadas a probar la aplicación que estoy desarrollando. No es un testing informal, sino preparado a través de una serie de casos de prueba.
• Investigación: son las horas en las que se investiga alguna tecnología nueva, una API o un sistema puntual que debe utilizarse en el proyecto. En algunos casos, estas horas las descuento del presupuesto ya que capitalizo conocimiento y experiencia.
• Documentación: horas dedicadas a escribir y generar documentación del sistema. Se incluye también capacitación del cliente para su uso.
• Mantenimiento: suelen ser horas de desarrollo pero que se dejan para luego de instalada la aplicación. Me gusta diferenciarlas de las de desarrollo durante el proyecto.

¿Qué hora vale más? En mi caso, el orden es: reunión; análisis; infraestructura / despliegue, desarrollo, investigación y mantenimiento; administrativo / comercial, documentación y testing.

Si vas a aplicar este paso, te recomiendo que te crees tu propia estructura de horas. No hace falta que sean tantas. Yo al principio tenía dos o tres y luego fui creando nuevas por necesidad. En la mayoría de los proyectos no uso más de 6 de estas.

3. Horas de gestión y de testing

A continuación uso una regla un poco arbitraria, pero que se hace necesaria. Cada determinada cantidad de horas de desarrollo, incluyo una hora de testing y una hora de gestión.

La hora de gestión es para manejar las tareas y los sprints. Generalmente es una hora por semana, manejando entre unas 5 y 6 horas netas de desarrollo por día. Desde el punto de vista práctico en mi caso esto es crear los sprints e ir actualizando el progreso en Taiga. Si no conocés esta herramienta para gestionar proyectos ágiles, te recomiendo el artículo completo sobre Taiga.

Respecto al testing estas son horas que me parece conveniente agregar porque me solía ocurrir que luego de programar durante muchos días seguidos, si bien agregaba funcionalidad, también rompía partes ya construidas. La solución que encontré es poner etapas intermedias de testing, aproximadamente 1 ó 2 horas por semana.

Si seguís la metodología Scrum, esto es algo natural que debería hacerse al concluir el sprint. Mis sprints suelen ser justamente de una semana para intentar llegar al final de ellos con alguna funcionalidad completa.

Aclaro que estas horas de testing se agregan a las que calculé en el paso 1. Esas en realidad se asocian con un testing más exhaustivo al finalizar todo el proyecto. Las que agrego aquí se tratan de un testing preventivo.

4. Calcular el precio final

Con la estimación del tiempo de cada tarea y el precio de la hora tipificado o no, ya es posible calcular el valor final del presupuesto. Basta con multiplicar y sumar. No hay que olvidar agregar los costos mencionados anteriormente.

Con eso obtendremos un precio final que en realidad no es tan final, puesto que todavía hay algunos ajustes que hacer.

5. Ajustes del precio final

Una vez obtenido el precio de las horas de todas la tareas que hay que realizar, es el momento de tener en cuenta algunos aspectos que pueden llevar ese precio hacia arriba o hacia abajo. Veamos cuáles son.

Desvíos

El desvío ocurre cuando el cliente incluye nuevos requerimientos en el medio del desarrollo y es necesario incluirlos, sin alterar el presupuesto. ¿Es posible esto? Bueno, sí, con la regla del desvío.

La regla del desvío la aprendí trabajando en mi último empleo y dice que todo proyecto tiene tendencia a desviarse en un 25%. Por lo tanto, hay que incrementar el precio final en un 25% para cubrir esta posibilidad.

Hablar de elevar un 25% un precio puede parecer exagerado, pero lo cierto es que en la práctica el desvío suele ocurrir mucho. En mi caso, utilizo la regla pero con un 15% y debo decir que últimamente me estoy quedando corto. Por algo será que se usa el 25%.

Riesgo

El riesgo implica evaluar las posibles consecuencias de la implementación del proyecto o la exigencia de un plazo difícil de conseguir.

Con un ejemplo se va a entender mejor. Supongamos que nos piden que realicemos un nuevo sistema y que debemos migrar a todos los usuarios del sistema anterior. Nos aclaran que en el traspaso, ningún usuario tiene que perder acceso al sistema. Entonces, ¿qué pasaría si, por algún motivo, tras la implementación, la mitad de los usuarios se quedan sin acceso al sistema? Evaluar esta posibilidad y qué habría que hacer al respecto es un análisis de riesgos.

Si hay riesgos, hay que tomar recaudos y en caso de hacerlo esto puede ser incluir un plan B, o dedicar muchas más horas para contrarrestrar algún imprevisto. Sea lo que sea, eso tiene un precio adicional.

El riesgo se puede traducir al presupuesto como un valor fijo o como un porcentaje.

Pensá que cuanto más riesgo haya, más estrés vas a padecer con el proyecto. Por lo tanto, no tengas miedo en subir tu precio en estos casos.

Inflación

Si vivís en un país como Argentina, con más de 50% de inflación anual, entonces hay dos posibilidades: fijar el precio en dólares o incrementar el precio en el porcentaje estimado de inflación durante el tiempo que dure el proyecto.

Por experiencia, si fijás el precio en dólares, muchos clientes van a considerar que cobrás caro y a huir. Así que no queda otra que calcular un estimado de inflación e incrementar el precio final.

En síntesis, mi consejo es que si sos argentino, evites el mercado local. Hay muchas posibilidades de trabajar para el exterior.

Si vivís en otro país y la inflación es menor al 10%, podés incluso obviar este punto.

Descuento o bonificación

No todo lleva el precio final para arriba. También puede haber descuentos para los clientes.

Si se trata de un amigo, o de alguien recomendado entonces se le puede hacer un descuento. También se puede considerar un descuento para empresas pequeñas que están creciendo, empresas familiares, startups, asociaciones sin fines de lucro y fundaciones.

Por supuesto que esto depende de cada uno. Tener un precio diferenciado en estos casos es parte de la función social que podemos optar cumplir los freelancers.

6. Analizar el precio final

Ahora sí se tiene un número final y es aquí donde viene la gran pregunta: ¿Está bien cobrar esto? Aparecen las dudas, el nerviosismo y se llega al pensamiento «¿Me rechazarán el presupuesto?» Y acto seguido aparece la idea de bajar el precio para que no sea rechazado.

Pero antes de hacer nada, hay que analizar el valor obtenido. Para ello, vamos a tener en cuenta diferentes aspectos.

Compararlo con las cotas

Como comenté antes, hay que tener algunas cotas de referencia. Justamente lo primero que haremos al tener el valor final es compararlo con las cotas. ¿Está este valor entre las cotas? ¿Se fue muy arriba? ¿Quedó muy debajo?

Si quedó entre las cotas es un buen síntoma. Sin embargo, hay que comparar con otros aspectos.

Compararlo con proyectos desarrollados previamente

Este punto solo lo podés implementar si ya tenés algo de experiencia y desarrollaste algún proyecto similar. En realidad ni siquiera es necesario que sea similar. Simplemente que se puedan comparar.

Hacerse preguntas como las siguientes ayudan mucho: ¿Este proyecto es más grande que este otro que ya hice? ¿O es más chico? ¿Cobré lo mismo por aquel proyecto similar a este nuevo? Si no, ¿tengo que cobrar más ahora?

Consultar con colegas

Este es un punto que la verdad no quería incluir porque los precios son tan heterogéneos en el mundo de los freelancers que me parece en vano considerarlo. Sin embargo, debo admitir que es una posibilidad.

Consultar un precio con un colega puede ser una buena idea, pero yo sólo consideraría esto con colegas que están en tus exactas mismas condiciones. Esto quiere decir que tengan tu mismo nivel, que se especialicen en las mismas tecnologías y que vivan en tu mismo país.

Comparar precio con servicios automatizados

Hoy en día hay muchos servicios online que resuelven una gran cantidad de problemas. Una buena idea es considerarlos como punto de comparación. Se supone que si estás construyendo un sitio fixed price, estás desarrollando a medida, por lo tanto tu proyecto debería valer más que un servicio automatizado.

Aunque esto puede no ser así. Lo explico con dos ejemplos claros.

El caso en que tu proyecto puede ser más caro es si te piden desarrollar un sistema e-commerce. Si programás en PHP seguramente implementes WooCommerce, OpenCart, Magento, PrestaShop, o alguno similar. Al mismo tiempo, existen plataformas como TiendaNube, que crean un sitio web e-commerce con un par de clicks.

Por lo tanto, tu proyecto de desarrollo tiene que se más caro que al menos un año de suscripción a este servicio. Si no, estás regalando tu trabajo.

El caso en que tu proyecto no puede ser más caro es cuando ya existe un servicio online mejor de lo que puedas desarrollar. El caso obvio es el de Google y sus herramientas de Google Drive. En realidad, tu aplicación no puede ser más cara simplemente porque no podés competir con Google. En ese caso, el proyecto se descarta.

Compararlo con el salario de un trabajo en relación de dependencia

Si bien no es fácil hacer un cálculo de comparación con un sueldo, en algún punto es necesario que lo hagas. Hay que considerar demasiados aspectos: con qué tipo de trabajo compararlo, y luego tener en cuenta descuentos, obra social, gastos de luz, agua, internet y muchos otros.

Después hay que calcular el precio la hora trabajando en relación de dependencia y compararlo con el precio la hora promedio del proyecto.

Son demasiados cálculos pero lo bueno de realizar esta estimación es que es el resultado es bastante contundente: deberías ganar más como freelancer. Si te da que no es así, entonces deberías revisar el presupuesto o replantearte lo que cobrás.

Sentido común

Lo más importante de todo es tener sentido común. Analizar el contexto e intentar entender si el número final tiene una razón de ser o si es completamente descabellado.

Si el precio final es demasiado bajo

Una de las posibilidades es que el precio final del presupuesto sea inferior a lo que te parece que tendría que haber dado. Es el caso en el que quedó por debajo de la cota inferior, o por encima pero muy cerca.

Hay dos opciones en este caso:

• Subir el precio de las horas. Hasta que consideres que el número final es conveniente y que justifica realizar el proyecto.
• Descartar el proyecto. No hay que perder tiempo en proyectos que no dan ganancias.

Si el precio final es demasiado caro

Puede ocurrir que uno mismo se dé cuenta que el precio final es demasiado alto y que el cliente no podrá de ninguna manera llegar a pagarlo. Al mismo tiempo, quizás estés necesitando trabajo porque no tenés otros proyectos o simplemente puede ocurrir que este proyecto en particular te guste mucho y lo consideres un lindo desafío.

En ese caso, podés bajar el precio de la hora para ajustarlo un poco a las capacidades de pago del cliente o directamente incluir un descuento.

Esta flexibilidad también te recomiendo que la apliques en caso de que el proyecto sea prestigioso, o que el cliente no sea conflictivo.

Cronograma

No me quiero meter demasiado en la planificación del desarrollo en sí mismo para no extenderme demasiado. Sin embargo, me gustaría recalcar que puede que el cliente pretenda ver un cronograma de entregas. En este caso, hay que tener en cuenta dos aspectos a la hora de armar un cronograma tentativo:

• El tiempo disponible para trabajar, considerando otros proyectos.
• En qué fechas te gustaría que te entren los pagos.

Creación del documento de presupuesto

Lo siguiente es armar una propuesta comercial de desarrollo (o de diseño, o de lo que sea a lo que te dedicás). Esto no es más que un documento en PDF donde te presentás, explicás de qué forma trabajás, describís lo que vas a hacer para este proyecto puntual y al final, clavás el numerito con el precio final del presupuesto y un cronograma tentativo.

Estas son mis recomendaciones para armar este presupuesto:

Usar una herramienta profesional

No te recomiendo Google Docs para este tipo de documentos. Para vos, esta es una carta de presentación y lo mejor que podés hacer es distinguirte e imponer todo tu profesionalismo. Así que tenés que usar una herramienta profesional.

Buscando webs que sirvan para generar PDFs de calidad encontré Visme y me encantó. Desde entonces, utilizo esta plataforma para crear mis propuestas comerciales y presupuestos. Trae muchas plantillas ya diseñadas con calidad profesional.

Describir lo que se hará en el proyecto

El presupuesto tiene que describir a cada una de las funcionalidades que se realizarán en el proyecto, o aquellos elementos que tendrás que diseñar o entregar.

Hay que recordar que este documento lo leerá alguien que no tiene conocimientos técnicos de tu disciplina, así que tiene que ser claro para todo el mundo.

Es buena idea armar una lista con todos las funcionalidades o elementos a entregar. Si es necesario, describir de qué se trata cada una de estas para que no quede ningún tipo de dudas acerca de cómo se tiene que ver o cómo tiene que funcionar.

Poner lo que NO se incluye

Así, con un NO en mayúsculas. Puede resultar chocante pero es super necesario incluir una sección donde se aclara explícitamente aquellas funcionalidades que no se incluyen en el proyecto.

Migraciones, carga de datos, backups y horas de mantenimiento extras suelen ser los más comunes. Aquí es importante que desarrolles tu creatividad y pienses en todos aquellos aspectos en los que el cliente podría exigirte algo adicional porque no quedó claro en el presupuesto.

En otras palabras, tenés que pensar en cubrirte por cada uno de los posibles grises que hay en el presupuesto.

Incluir el cronograma tentativo o la duración del proyecto

Es buena idea incluir el cronograma tentativo o al menos la duración aproximada del proyecto. Esto no quiere decir que tenga que cumplirse tal cual está en este primer presupuesto. La planificación puede venir después negociando tiempos con el cliente.

Esto quiere decir que no hace falta definir fechas puntuales sino que es mejor referirse a periodos de tiempo relativos, como por ejemplo: «La primera entrega será tres semanas después de comenzado el proyecto».

Caducidad del presupuesto

Los presupuestos no son eternos. Tienen una fecha de caducidad que tiene que definirse en el documento. Este puede ser de uno a tres meses, pero depende del contexto comercial y del país.

En todo caso, si transcurrió mucho tiempo desde la entrega del presupuesto y se pasó la fecha de caducidad, será necesario revisarlo para actualizarlo.

Si trabajás en Argentina, este punto es muy importante producto de la inflación y otros cambios repentinos que suelen ocurrir de un día para el otro.

De quién y para quién

Una buena costumbre es aclarar quién escribió el presupuesto y para quién es. Porque un presupuesto no es general para todo el mundo. Es algo hecho a medida. No puede aparecer otra persona a la que le llegó tu presupuesto a reclamarte nada.

Planificación de los pagos

En el documento de presupuesto también hay que incluir las formas de pago y la planificación de los distintos pagos.

En desarrollo, hay una regla que dice que hay que cobrar un tercio antes de comenzar el proyecto, otro tercio a mitad de proyecto y el último tercio luego de instalada la aplicación. Sin embargo, esto en la práctica no es tan fácil de cumplir.

Lo cierto es que los clientes suelen postergar los pagos. En mi experiencia, comienzan a desembolsar a medida que ven resultados y se pueden beneficiar de ellos.

Lo más importante de todo, por supuesto, es no entregar un proyecto sin haber cobrado algo antes. Salvo que tengas mucha confianza con tu cliente.

Para cerrar

Esto ha sido todo por este artículo. Espero que lo que he volcado aquí te sea de utilidad y que puedas incorporar algo a tu proceso de presupuesto.

Es muy probable que me haya olvidado de algunos aspectos a tener en cuenta. Así que dejo abierta la posibilidad de ir actualizando este artículo si se me ocurre algo que omití.

Si tenés alguna duda, sugerencia o aporte, dejame un comentario al final del artículo.

Gracias por tomarte tanto tiempo para leerme.

¡Hasta la próxima!