Freelance: Cómo definir y cobrar un proyecto

Este tema es de una gran importancia para todos quienes nos dedicamos a llevar proyectos de desarrollo en forma independiente, es decir, para todos quienes trabajamos como desarrolladores freelance. Es muy probable que a la hora de ponerle precio a un proyecto no sabes cuanto cobrar ni qué medidas de seguridad tomar para que el proyecto llegue a feliz término.

Esta no pretende ser la guía definitiva del tema, es simplemente un montón de experiencia personal volcada en estas líneas que te ayudarán a estar mejor preparado para definir, trabajar y cobrar tus proyectos.

Siempre debes analizar los requerimientos que te solicite un cliente

Este es uno de los momentos en que más precaución debes tener. Cuando un cliente (empresa o particular) te entrega lo que él pretende que desarrolles ten por seguro que creerá que la forma en la que ha definido su idea es perfecta y no deja lugar a ambigüedades, debes considerar que él tiene una idea, pero generalmente no es un experto (es lo mismo que te puede pasar a ti cuando llevas tu auto a un taller). Debes tener muy buen manejo para mostrarle a tu cliente cuan lejos puede estar de lo que es una definición correcta sin llegar a ofenderlo, muéstrale todas las cosas que hay que pensar y/o evaluar en cada uno de los puntos que menciona e indícile, si corresponde, todos los puntos que no está mencionando.

Alguna de las cosas a las que te tocará enfrentarte (o seguro ya te has enfrentado) son a declaraciones como:

Necesito que este sitio tenga un acceso con clave

Seguramente tu cliente debe pensar que eso corresponde a una completa referencia en relación a la funcionalidad que está pidiendo, incluso debe llegar a pensar que es un requerimiento muy fácil de hacer para ti. Es tu misión conseguir mostrar todo lo que puede implicar aquello que está solicitando, debes formular preguntas como:

• ¿Tendrá un usuario o será multiusuario?
• ¿Existirá distinto nivel de permisos dependiendo del usuario?
• ¿La clave se almacenará en la base de datos de forma explícita o encriptada?
• ¿Se podrá inhabilitar los usuarios activos? Si la repuesta es positiva ¿se eliminarán las cuentas, o se cambiará su estado?
• ¿Qué características de la cuenta pueden ser cambiadas por el propio usuario?
• ¿Existirá alguna validación de acceso adicional a la clave? (¿capcha?)
• ¿Existirá un número de intentos de acceso máximo? ¿qué pasará cuando este límite se alcance?
• ¿Existirá algún flujo para recuperar la contraseña? ¿cual?

Podría seguir toda el día preguntando los alcances de algo que para la mayoría del los clientes se define en una sóla linea. Es por esto que es tan importante analizar los requerimientos y, la mayoría de las veces que hagas este ejercicio de cuestionarte qué es lo que te están pidiendo hacer, te encontrarás con que no te aclaran absolutamente nada.

¿Cómo llevar el proyecto?

Dependiendo del tamaño del proyecto, y sobre todo dependiendo del tipo de cliente que tengas, puedes trabajar junto a él para llevarlo adelante utilizando metodologías ágiles o metodologías pesadas.

Si el cliente no va a aceptar comenzar a trabajar contigo a no ser que le entregues la duración del proyecto, los costos finales y toda la programación en una linda carta gantt, entonces estás en frente del caso más habitual de cliente y tendrás que llevar a cabo el desarrollo siguiendo metodologías pesadas.

Si, por el contrario encontraste al fantástico cliente que favorece los resultados, está dispuesto a arriesgarse a iniciar un proyecto sin un fecha de término y tiene la mente lo suficientemente abierta para trabajar junto a ti e involucrarse en todo el proyecto, entonces puedes iniciar con las metodologías ágiles que, curiosamente, son las que más favorecen a los clientes otorgándoles mejores desarrollos, en menores tiempos y con costos menores.

No es mi intención en este artículo darte una clase sobre qué se trata cada una de estas metodologías, pero si no las conoces acá puedes ver las diferencias en llevar el proyecto de una u otra manera.

Metodologías pesadas

Esta es la forma más tradicional de llevar un proyecto. Algo importante es que antes de partir el cliente te pedirá el valor final del trabajo y la fecha de término o entrega, te pedirá también las fechas en las que podrá ir viendo “algo”. Aquí debes comprender que para poder aventurarte a seguir adelante adquiriendo todos estos compromisos debes tener perfectamente claro qué es lo que tendrás que hacer.

Para esto deberás preparar todo un documento que definirá el desarrollo en su totalidad. Todo TODO ¡Todo!. ¿lo notaste?, sí hacer este documento es, generalmente, un enorme trabajo. Mi consejo: no debe ser gratis. Muchos clientes no estarán dispuestos a pagar este concepto, es necesario que les hagas entender que lo que te están pidiendo no es el equivalente de un presupuesto, sino es el equivalente de un plano de un edificio. Pedir que no cobraras por esto sería como pedirle a un arquitecto que te entregara los planos de un edificio de forma gratuita. El desarrollo de este documento es un trabajo en sí mismo y como tal puedes cobrarlo.

Ahora, ¿qué gana el cliente con esto?. Con este documento completo y correctamente realizado el cliente será libre de realizar el desarrollo contigo o con cualquier otro desarrollador o empresa. Una vez que le has entregado este documento el cliente tendrá todas las herramientas para poder solicitar un valor a quien quiera, es importante que le menciones esta ventaja a la hora de que le expliques que existe un costo asociado a la producción de este documento.

Metodologías ágiles

Acá nos podemos poner a trabajar muy rápidamente, no será necesario un enorme esfuerzo definiendo el proyecto en su totalidad sino que nos bastará con una idea general de lo que pretende el cliente. A través de mucha intereacción con él nos enteraremos de qué es lo que pretende y le recomendaremos mejoras o cambios de acuerdo a nuestra experiencia.

Con este método podrás ir avanzando paso a paso definiendo algún tiempo de iteración, por ejemplo, comprometiéndote a entregar avances una vez por semana. Así el cliente y tú tendrán la oportunidad de dar por cerrada esa etapa, modificarla o corregirla. En mi experiencia esta metodología es la más conveniente para un cliente y para el desarrollador es la más satisfactoria, ya que al tener mucha comunicación con el cliente a lo largo de todo el desarrollo cuando se dé por finalizado el cliente se encontrará con un producto que satisface muy bien sus espectativas.

No existen las cosas obvias

No importa qué metodología escojas, siempre debes aclarar a tu cliente que no existe nada obvio y cuando se pongan a discutir sobre alguna funcionalidad toma un papel y anota una por una las dudas que puedas tener, luego explícaselas para que la aclaren en conjunto. No es bueno tener en mente cosas demasiado generales, es mejor detallar perfectamente qué es lo que se desea como resultado.

Muchas veces me ha pasado que los clientes consideran obvias muchas cosas y no es (necesariamente) que sea una mala persona, sino que él realmente cree que un concepto rodea un montón de funcionalidades y características que son tan obvias que no es necesario mencionar. Insiste en que esto no es así y aclárale que lo mejor que puede hacer es explicarte en detalle qué es lo que espera en todo aspecto del desarrollo.

En este sentido té eres el experto, no él. Es tu deber hacerle ver cuando existan mejores alternativas a algo que propone. Te sorprenderás de que muchas veces tu cliente estará dispuesto a sacrificar un pequeño porcentaje de sus funcionalidades a cambio de reutilizar código ya existente que mejore la oferta económica o el plazo de la solución. También a veces estará dispuesto a pagar más o esperar más tiempo si la mejora que le ofreces le resulta atractiva.

Tu mejor papel en este caso lo haces mostrándole a tu cliente todas las cartas con las que puede jugar, él lo agradecerá y terminarás mejorando tu relación comercial. ¡Crea buenos lazos!

No prometas cosas que no puedas cumplir

Al comienzo de mi trabajo como desarrollador freelance me daba mucho miedo perder un cliente por no ser capaz de ofrecerle una solución que el necesitaba. Créeme, es muy mala idea. Lo mejor es ser claro y transparente con tu cliente, si hay algo que no puedes hacer dícelo, no le molestará tanto como que no le entregues lo que digiste que le podrías entregar. Tampoco digas cosas tan amplias como “su sitio se verá bien en todos los browsers”, esta declaración es una de las que más dolores de cabeza traen a los desarrolladores, quizás tu cliente justo revise lo que hiciste en un antiguo PC con Internet Explorer 5.5 (o incluso más antiguo), quizás no soporte los elegantes estilos que desarrollaste con CSS3, quizás tengas que enfrentar un cliente al que le encanta trabajar con versiones betas y va siempre muy adelantado en los browsers que utiliza, quizás incluso le gusta usar browser que ni siquiera son muy conocidos ¿da miedo no?.

Bien, la forma en la que te evitas esto es aclarando tu compromiso, haciéndolo transparente con tu cliente, algo como: “su sitio se verá bien en Internet Explorer 7 y 8, también se verá bien en Firefox 2.5 a 3.6, Opera 7, 8, 9 y 10 y también será desarrollado para verse bien en Safari 3 y 4,”, a esto debes agregar algún dato como “entre estos browsers cubrimos el 95% de la demanda de usuarios de Internet” (el número lo acabo de inventar, pero tú averígualo en serio).

De este modo le entregarás a tu cliente la tranquilidad de saber que la gran mayoría de las personas podrán utilizar sin problemas tu desarrollo y, por otro lado, te quita la problemática de tener que considerar los casos límite para browsers que, quizás, ni siquiera conozcas.

Arriésgate

¿Tienes un buen cliente? ¿Sientes que conoces su modelo de negocio?. Aventúrate y toma riesgos. Si por ejemplo tu cliente está orientado a un mercado de usuarios adultos-jóvenes podrías animarte a realizar una versión minimalista de un versión mobile de la aplicacioón que desarrollaste para él. No te pongas ambicioso, no trates de replicar todas las funcionalidades, simplemente prepara una demo que sea muy vistoza y que incorpore las funcionalidades más básicas. Tu cliente no pensará en encargarte un desarrollo mobile hasta que lo vea y cuando lo haga, créeme, tendrá ganas de tenerlo y además querrá más funciones.

¿No te resultó? No importa, es parte del riesgo, tampoco debes ir por la vida preparando demos para todo el mundo, debes conocer bien a tu cliente para asumir este riesgo.

Desarrolla para sentirte orgulloso

Siempre se habla de la calidad del código, de lo meticuloso que somos y de lo maravillos que trabajamos. Todos decimos lo mismo. Ahora, cuando te pongas a escribir el código de verdad recuerda que habrá personas que verán tu trabajo, que lo usarán y lo comentarán.

Una de las mejores formas de inspiración a la hora de escribir código es recordar que te puedes llenar de gloria con tus desarrollos, puedes colocarlos en tu portafolio, podrás contarle a la gente que tú lo hiciste y cada uno de los proyectos que termines harán que nuevos y mejores proyectos vengan por delante.

¿Cuanto cobrar por un desarrollo?

Este es un tema muy delicado, no tengo una fórmula que me permita calcularlo ni tengo darte la forma precisa de hacerlo. Sólo te puedo dar algunos consejos:

Algo que debes tener en cuenta es que cuando trabajas con un sueldo fijo para una empresa tienes algunos beneficios, derecho a salud, si te enfermas y tienes que quedarte en casa de todas formas recibirás tu salario, si te despiden tendrás indemnización, etc. Cuando trabajas como freelance el riesgo que estás corriendo es mucho mayor, por lo tanto mi recomendación es que nunca cobres menos de lo que ganarías trabajando a sueldo, de hecho creo que deberías cobrar al menos un 50% más.

En el fondo esta práctica funciona de forma similar al mercado, una empresa que te contrata a sueldo es como si estuviera comprando tu trabajo “al por mayor”, por lo que debes darle un mejor precio que a la empresa que te contrata para un trabajo en particular, por que estaría comprando tu trabajo “al detalle”.