82. Presupuesto cerrado VS presupuesto por horas

Transcripción

A la hora de empezar un proyecto de programación como freelance, podemos encararlo de dos formas principalmente. La primera, es presupuestar todo y establecer un precio cerrado; la segunda, es acordar un precio por hora e ir desarrollando sobre la marcha y facturar sobre las horas trabajadas.

Hay que aclarar una cosa y es que quizás el nombre no sea del todo acertado ya que el presupuesto cerrado también se basa en las horas de trabajo. El freelance, al fin y al cabo, tiene un precio-hora, sean 20, 30 euros la hora, lo que sea.

Se presupuesta el proyecto, se hace un plan y se establecen unas horas, de ahí sale un precio fijo y cerrado. Mientras que el otro va sobre la marcha. En otras palabras, no se sabe cuánto tiempo se va a dedicar, con lo cual se factura simplemente por las horas que se vayan a trabajar.

Cuestiones con el precio-hora

Me gustaría remarcar el tema del precio por hora porque este no indica, o no tiene por qué indicar el precio final de un proyecto, puede ser más barato o más caro.

Me explico: normalmente, alguien que tiene un precio/hora más bajo significa que, entre otras cosas, tiene menos experiencia por normal general, mientras que el que tiene un precio más elevado tiene más experiencia.

Esto quiere decir que el que tiene más experiencia, va a tardar menos (repito, por normal general) en desarrollar ciertas características de un proyecto, las mismas funcionalidades que desarrollaría otro programador.

A la hora de buscar un programador, no podemos fijarnos solamente en el precio, sino en el global del proyecto. Quizás, alguien que cobra 40 euros la hora, hace el trabajo por un precio menor que otro que cobra 20 euros la hora, porque aquel tarda menos.

Sin embargo, esto no es normalmente así ya que un precio/hora alto significa otras cosas: experiencia, calidad, saber hacer, lo cual tiene su coste como es evidente. Pero hay que tenerlo en cuenta.

Si vas a buscar un programador en una web de freelance donde se listan todas las personas capaces de hacer ese trabajo, verás que generalmente sale el precio/hora.

Si únicamente te fijas en ese precio porque estás buscando un precio económico, si ese es tu baremo, puedes estar equivocado porque lo importante es cuantas horas va a dedicar a ese proyecto.

Si alguien tiene un precio/hora de 15 euros la hora y para hacer ese proyecto dice que tardará 100 horas; y por otro lado, tenemos que alguien que cobra 40 euros por hora y va a tardar la mitad de horas, quizás el precio no sea tan distinto. Es algo a tener muy en cuenta.

Ventajas y desventajas de presupuestos cerrados o abiertos

Volvamos a los tipos de presupuesto. El presupuesto cerrado se basa en analizar todo y establecer un precio. Es decir, el cliente que contrata al programador, le dice exactamente todo lo que quiere.

Por ejemplo, le pide una aplicación que tenga un login, registro de usuarios, que se puedan loguear con Facebook, otras redes sociales y con el email. Además, le pide que muestre una lista de productos y que se muestren sobre un mapa, etc.

A partir de ahí, lo que hace el programador es ver cuánto tiempo estima que le va a llevar hacer eso y decirle al cliente: “Me va a llevar 100 horas, tres meses o dos meses”. Con esto y considerando el precio/hora establece un precio cerrado; de ahí no se sale.

Por otro lado, el presupuesto por hora, es simplemente acordar un precio por hora y empezar a desarrollar sobre la marcha, quizás con un límite de horas semanales, mensuales, etc. Cada uno puede elegir la forma que mejor le funcione.

Personalmente, prefiero un presupuesto cerrado, aunque también trabajo con presupuesto por horas; depende del proyecto.

Me vuelvo a explicar. Si un proyecto está claramente cerrado y se sabe lo que se quiere hacer, es viable un presupuesto cerrado porque sabes exactamente todo lo que vas a tener que programar y podrás saber más o menos, el número de horas que te va a llevar. Se especifican unas características y eso es lo que se presupuesta, ni más ni menos.

Por otro lado, si un proyecto va variando, no está claramente definido o se van a ir haciendo cambios sobre la marcha, simplemente es imposible hacer un presupuesto cerrado ya que este va a ir cambiando con el tiempo; no sabes exactamente lo que vas a tener que hacer y qué trabajo vas a desarrollar. Con lo cual, el presupuesto por horas, no es que sea lo más indicado, sino que es lo más viable en esa situación.

La gran ventaja del presupuesto cerrado es que ambas partes saben el precio final; hay un planning claramente definido y es más previsible saber qué pasará en cuanto a fechas y costes.

Asimismo, el cliente sabrá cuándo estará listo ese proyecto y de cara al desarrollador, le permite algo muy importante que es planificarse, porque como freelance, es muy importante saber organizarte con otros proyectos a la vez, o saber cuando vas acabar uno, para empezar otro. De ahí que yo prefiera un presupuesto cerrado donde está todo establecido y es más previsible.

Otra gran ventaja del presupuesto cerrado es que permite más flexibilidad sobre todo de cara al cliente quien puede ir cambiando el proyecto tanto como quiera. Aunque claro, del lado del desarrollador también es bueno establecer un límite en el tiempo ya que, si no, se vuelve imposible gestionar varios proyectos.

Imaginemos que empiezas en un proyecto y no te dicen nada sobre la cantidad de horas que vas a trabajar o cuando va a estar listo el proyecto. Si te dicen esto, y tienes que ofrecer disponibilidad ilimitada a lo largo del tiempo, es muy difícil planificarte con otros proyectos.

No esperes que acabes ese proyecto y ya tengas planificado otro porque básicamente no lo podrás planificar. No sabes si al mes siguiente vas a seguir con ese proyecto y te va a ocupar gran parte de tu día de trabajo.

Al fin y al cabo, ambas formas de encarar un proyecto dependen de las dos partes, tanto del cliente como del programador. Aunque, también depende del tipo de proyecto.

Si tú como freelance, únicamente quieres trabajar con proyectos fijos, especificados con presupuestos cerrados, lo único que te queda hacer es rechazar aquellos proyectos que no estén claramente especificados, con características fijas y delimitados en el tiempo.

Si te ha resultado útil este artículo puedes hacer que también lo sea para otras personas compartiéndolo en , LinkedIn o .

Como siempre para cualquier duda o sugerencia puedes contactar conmigo y estaré encantado de poder ayudarte.

¡Suscríbete

a la newsletter!

Simple y llanamente te mantendré al día una vez al mes a través de un email con artículos o noticias de interés relacionadas con el mundo de las aplicaciones móviles. ¡Nada de spam!