Japegamx

A pesar de lo que muchos estuvieran pensando, no estamos hablando de política, sino de desarrollo de software y en éste caso quiero abordar un tema por demás extenso y que creo concierne a todo programador, consultor o cualquiera que se haya enfrascado en el desarrollo de sistemas y por su puesto en el coco de todos: Cotización del Desarrollo de un Proyecto de Software.

Como siempre, no pretendo exponer aquí el hilo negro de las cosas, sino simplemente emitir mi comentario basado en mi experiencia y por supuesto, fomentar la retroalimentación de externos con la finalidad de apoyar el tema y por su puesto, tratar de poner nuestro granito de arena en la ayuda que esto pueda proporcionar a los colegas programadores.

¿Cuántas veces no nos hemos encontrado con el cliente que nos pide la cotización de un proyecto basándonos sólo en una visión muy superficial del sistema? Cotización de tiempo, resultados y monto del producto de software. Determinar ésto en una etapa muy temprana del proyecto es demasiado riesgoso, es necesario e indispensable, realizar un estudio detallado de lo que se pretende elaborar y estas actividades pueden tardar tiempo, dinero y esfuerzo, que por lo general, no se obtiene lo segundo, ya que en la mayoría de los casos, el cliente está dispuesto a invertir el mínimo de tiempo en el estudio del proyecto y saber, cuanto antes, cuánto le va a costar y cuándo lo tendrá disponible.

La inversión de ese tiempo es conocida como Periodo de Análisis y Diseño y es muy recomendable realizarlo minuciosamente antes de llevar a cabo cualquier proyecto o cotización alguna. Es una actividad fundamental que, inclusive, los expertos en la materia, fomentan su uso y que puede llevar a conclusiones inesperadas como la de no realizar el producto de software por cuestiones de viabilidad, es decir, que se pueda realizar o, en su mayoría, el software requerido ya existe y se puede usar uno comercial o de ámbito libre. Pero en muchos de los casos, se le solicita al programador o líder de proyecto que al menos “aproxime” lo más que pueda el precio y los tiempos a la realidad. Esto crea mucha incertidumbre entre menos se conozca sobre el software a realizar.

Muchas veces clientes potenciales me han interrogado con algo como lo siguiente: “Oye, necesito un programa que me ayude a llevar el control de mis ventas, ¿Cuánto crees que costaría y como en cuánto tiempo podría estar?”. Es una pregunta muy ambigua, aunque parezca que no lo es, ya que eso me lleva a muchísimas preguntas, pero a simple vista, si nos centramos en sólo el control de las ventas, podrías aventurar un precio por sólo eso, pero siempre surgen las “adecuaciones” y cosas como “Pero también quiero que lleve mis gastos y compras de proveedores… Y que me muestre un reporte de las comisiones de mis vendedores”. Todo ésto agrega funcionalidades al sistema y por lo que casi siempre respondo con un “Necesitaría que nos sentáramos a platicar qué es exactamente todo lo que quieres o necesitas para poderte dar una cotización aproximada”, a lo que, casi siempre, accede el cliente, pero que por supuesto, es trabajo de Análisis que no es remunerado en la gran mayoría de los casos.

El trabajo de un Analista es estudiar todo lo que el cliente necesita para su producto de software, así como recabar requerimientos, información, detalle de reportes, reglas de negocio y documentar lo más posible los procesos que se llevan actualmente en la empresa del cliente para poder conocer y después, diseñar, como se puede dar solución a esas necesidades. Es un arduo trabajo que no siempre es bien realizado y que conlleva casi siempre a una mala interpretación de muchos módulos que terminan por tratar de corregirse sobre la marca o que terminan en un parche, si es que el sistema ya llegó a un punto demasiado avando, pero ¿Por qué si es tan importante la mayoría de los programadores, consultores o freelances no le prestan mucha atención? Pues porque no es remunerado.

En muchos casos (sino es que en la mayoría), si el cliente accede a invertir tiempo en el análisis como debe ser, se obtiene una amplia y detallada idea de lo que será el sistema y aunque no es una base perfectamente sólida para dar una cotización definitiva, ya es posible aventurar un estimado, pero al proporcionar esta cantidad al cliente, termina por negarse a realizarlo por el alto costo del mismo y es que en el análisis, el cliente, como no visualiza la relación costo de lo solicitado, termina por engancharse y hacer, lo que muchos llamamos en el medio “su cartita a Santa Claus” y no lo hacemos con el afán de burlarnos del cliente sino que en realidad, eso es en efecto. Muchos requerimientos y funcionalidades que se le fueron ocurriendo mediante el proceso de análisis y que extienden demasiado la idea inicial del proyecto.

Usualmente en estos casos, se procura tratar de aterrizar al cliente lo más apegado que se pueda a la idea original y dejar los “lujos” del sistema para desarrollos posteriores o para “una segunda o tercera etapa del programa” (que no siempre se llega a realizar). Lo más frustante es haber invertido una semana o dos de trabajo de análisis y que el cliente decida no llevar a cabo el proyecto, después de tanto trabajo, pero muchos clientes no lo ven así.

Claro, no estoy diciendo que todos los clientes sean de ésta manera, pero por lo general nos encontramos en estas situaciones, mucho se debe al fomento que hemos generado la comunidad en estos rubros y parte, el desconocimiento, por parte del cliente, que el trabajo de análisis también debería remunerarse. Incluso, he llegado a escuchar el término o puesto de Arquitecto de Software y que es un trabajo de ingresos muy altos, pero claro, es una persona especializada sólo en Análisis y Diseño, es como un arquitecto de construcción, quien estudia y decide cómo se van a hacer las cosas, da “los planos” del proyecto a los líderes de proyecto y este a su vez  a los programadores para desarrollo y por su puesto, dirige la construcción del mismo. En lo personal, no conozco a ninguno hasta el momento, pero sí me gustaría llegar a ser uno, desde luego.

Simplemente hagamos unas sencillas preguntas ¿Acaso un ingeniero o arquitecto podría darnos un presupuesto exacto y tiempo de una construcción basándose sólo en un croquis? O ¿Podría un doctor determinar el tratamiento o si debe operar a un paciente con sólo verlo? Por supuesto que no, debe haber una curva de aprendizaje, estudio, análisis de la situación, en algunos casos más detallados que en otros, para poder saber cómo, cuánto, dónde, por qué y cuando.

En el caso del arquitecto necesita saber dimensiones, necesidades, dónde se pretende construir, qué se pretende construir y más detalle para poder dar incluso un presupuesto, considerar eventualidades, etcétera. El caso de los doctores, pues consulta con el paciente, estudio de historial médico (si cuanta con él) y por supuesto: Toda consulta genera honorarios. Al menos en el ámbito médico así es, ¿Por qué no en nuestro caso? ¿Por qué no tenemos el grado de doctor? ¿Y si lo fuéramos, nos lo pagarían? ¿Cuánto se cobra?

Hemos escrito mucho y sin llegar a una solución concreta al respecto. Existen varias recomendaciones de los expertos en cuanto a cómo realizar una cotización muy aproximada del desarrollo de software, sin llegar a ser una regla o estándar dentro del medio. Y menciono algunas a continuación:

• Costo por Hora de Programación: Después del análisis, tratar de determinar el tiempo de elaboración del producto en base en la experiencia del programador o en base a sus recursos (por ejemplo, número de programadores, tiempo en que pueden realizar tareas, etcétera) y multiplicarlos por un valor-hora que puede ir en función de los gastos generados en el tiempo determinado, más los recursos invertidos (costos de tiempo de desarrollo como luz, teléfono, internet, etcétera). Es importante que el tiempo determinado tenga un estimado de holgura considerable, también basado en la experiencia, para posible eventualidades que puedan surgir en el trayecto.
• Costo por Tabla: Después del análisis, realizar un estimado de cuántas tablas de base de datos usará el sistema, en base a la experiencia del programador, podrá determinar cuánto trabajo y tiempo puede llevar en realizar un sistema de la magnitud establecida, en base a eso, podría agregarse un 20% por posibles tablas que puedan generarse en el trayecto de desarrollo y contemplar un 6% por cualquier posible eventualidad. Ese número de tablas, podrían dar un estimado de la complejidad del sistema para poder otorgar una cotización aproximada.

Existen algunas más empleadas pero creo que más ambiguas, poco por ejemplo, he llegado a escuchar la estimación en número de líneas de código, pero si de por sí es bastante complejo determinar un presupuesto decente en las actividades mencionadas, cuanto más en la determinación de cuánto código puede llegarte a generar un sistema.

Aún con las recomendaciones antes expuestas, siguen quedando en el aire incógnitas que son dignas de temas completos como por ejemplo: ¿Cuánto cobrar en base a la experiencia del programador? ¿Cuánto es el valor-hora de un programador promedio o master? E incluso, hay quien asegura que influye hasta el lugar en donde estés haciendo el presupuesto, es decir, país en donde vivas y no lo dudo, habrá países en donde la demanda de programadores o incluso su calidad, sea mayor o menor que en otros.

Este es un tema bastante extenso que ha abarcado muchos libros, debates, conferencias, opiniones y diversos estudios. He tratado de exponer aquí en base a mi experiencia y lo que he leído pero sin embargo, no podría abarcar todos los aspectos del tema.

Enlaces adicionales

http://www.latiumsoftware.com/es/articles/00018.php
http://www.forosdelweb.com/f50/cotizacion-software-404816/
http://www.clubdelphi.com/foros/showthread.php?t=56003
http://www.slideshare.net/ernestoq1973/como-cotizar-servicios-de-desarrollo-de-software

Hace un par de días estuve en el estire y afloje para realizar un proyecto en Flash con un cliente argentino. Lo contacté mediante una de tantos sitios web en donde se postulan proyectos y los programadores freelancers hacen propuestas y se ponen en contacto con los interesados para realizarlos.

Obviamente y de ésto nadie se salva a la hora de querer hacer proyectos o sistemas informáticos; existe un proceso de negociación entre el programador y el cliente, ya sea que sena varios programadores o una empresa en sí. La victoria se determina entre quienes aporten mejores presupuestos, pero he aquí lo malo del asunto. Muchas veces los clientes se inclinan por el candidato que de más barato y que se apegue a sus necesidades lo más que se pueda. Si existe un candidato que compite con el precio cerca de otro, entonces se procura elegir al mejor, pero no siempre es así, y, por otro lado, muchas empresas y programadores terminan malbaratando su trabajo por obtener los proyectos. Mal, muy mal.

Existe un problema enorme al malbaratar tu trabajo y más si eres programador freelance (también se aplica a empresas), que todo el tiempo que estés desarrollando lo harán de muy mala gana ya que la paga no será ni siquiera cercano a bueno o decente. Los clientes siempre quieren lo mejor por menos dinero y eso tampoco es posible, lamentablemente, nosotros mismo empeoramos el mercado por querer ganar los proyectos y se termina trabajando demasiado por menos dinero. No se llega a un equilibrio justo para ambos, puesto que el programador o la empresa en cuestión, al querer deshacerse del cliente “que da demasiada lata como si pagara bien por el servicio”, terminan por hacer los sistemas al aventón y disfrazarlos de buenos, cuando se sabe que es un producto que no cumple al 100% con las necesidades del cliente.

Otro problema es cuando se llegan a supuestos “arreglos” o “negociaciones” entre el cliente y el programador o la empresa de desarrollo. La clásica promesa de que se sabe que el precio es muy bajo, pero que terminando el corriente se destinarán más proyectos y “garantizar” así, más trabajo, lo que debería conllevar a más dinero o al menos, dinero seguro. Lo peor viene después. Cuando en un considerable tiempo de uso del sistema, ya en producción o liberado, el cliente comienza a percatarse de que el sistema no cumple con los requerimientos al 100% de lo que se había acordado o, en el peor de los caso, que aún cuenta con bugs u otras inconsistencias. Muchos clientes terminan optando por la alternativa de otro proveedor, tal vez de los presupuestos que fueron descartados en un principio o por comprar el producto comercial que no resuelve enteramente sus necesidades y problemas, pero que fue una de las causas que originaron la iniciativa de crear o construir un software especializado, gastando así, más dinero y recursos, además del tiempo perdido.

De ahí se deriva el título de éste post. El proceso del desarrollo de sistemas invariablemente se rige por esa regla. Si quieres que sea rápido y barato (la elección preferida de los clientes), no será bueno. Si quieres que sea barato y bueno, no será rápido. Si quieres que sea rápido y bueno, seguramente, no será barato. Y en varios estudios y libros que hablan del Análisis y Desarrollo de sistemas se encontrarán con ésta premisa, sin duda. De hecho, la frase exacta la leí en el libro Applying UML And Patterns An Introduction to Object-Oriented Analisis and Design and the Unified Process (Second Edition) por Craig Larman, hace ya algún tiempo.

Pero me desvié bastante del tema. Regresando a mi caso, tuve una negociación bastante rápida con el cliente. En cuanto le hice llegar mi propuesta, no tardó en contestarme que el precio que sugería era demasiado alto a otros que le habían propuesto y que no estaba interesado. El motivo de éste post no es exponer a nadie, por lo que me reservo más detalles del cliente, e incluso, del detalle del proyecto en cuestión. Lo cierto es y créanme que no soy de esos que pretenden hacerse millonarios con un sólo proyecto, por lo que le ofrecí un precio que se acercó a lo más justo que pude calcular, sacando el tiempo estimado en el que me tardaría en hacerlo multiplicado por un precio por hora, basándome en una jornada laboral de 8 horas y que estoy seguro que terminaría trabajando más horas (es bastante usual cuando se trabaja de freelance), y el cálculo resultante fue el que le envié al cliente. No me pareció descabellado de ninguna manera. Se perfectamente que incluso, cualquier empresa especializada cobraría muchísimo más, pero tampoco dudo ni por un segundo, que se varios freelancers de los miles o millones que hay en Internet, le haya hecho una oferta por debajo de la mitad del mío.

Soy de los que nos gusta el trabajo que hacemos, pero también nos gusta ganar, al menos, lo justo por lo que hacemos. No malbaratemos nuestro trabajo, simplemente da lo justo y si no obtienes el proyecto, ya habrá quien sí esté dispuesto a pagar su justo valor o ¿Acaso estamos obligados a dar precios ínfimos por el simple hecho de ser freelance? Yo creo que no, puede haber muy buena calidad en un trabajo de freelance, pero el mercado y la mentalidad debe cambiar y creo que es por nosotros mismos (los desarrolladores), por donde debe empezar la actitud.

¿Ustedes qué opinan?