Hola de nuevo,
Como he dicho... quería participar pero no disponía de tiempo. Bueno, dejé esto para los últimos minutos antes de acostarme.
A mi se me conoce por no tener demasiado poder de síntesis así que no te asustes si me extiendo. De todas formas trataré de ser breve.
La respuesta sencilla, fácil y rápida sería DEPENDE, DEPENDE, DEPENDE como había dicho antes de irme. Y si quisiera completarse con algo más quizá se resuma a que NO existe un único criterio, forma o método para dar valor al software, mientras encuentres (o mejor dicho, desarrolles) alguno con el que te sientas cómodo... lo demás es secundario.
Ahora si... ¡a gastar teclas!
Primeramente debemos distinguir lo que es COSTO de PRECIO. No son lo mismo, aunque lo utilicemos como si fueran sinónimos. El primero apunta a un valor interno, de lo que nos cuesta o necesitamos invertir para llegar a producir nuestros productos; mientras que el segundo es en realidad el valor real que le atribuímos y ponemos al producto para el mercado, es decir algo externo.
Si tenemos en esto presente, ahora la pregunta es ¿Cuál o de que manera ponerle precio?
La respuesta mágica, y para ser breve, es APRENDER A VALORAR NUESTRO TRABAJO. Si logramos definir un valor a nuestro trabajo podemos, en cierto modo, entonces recién podemos estar en condiciones de estimar y darle un valor a nuestra creación.
Si no tienes desarrolladas las herramientas con las que estimar tu VALOR PROFESIONAL muy difícil que logres darle un PRECIO JUSTO.
Además hay que considerar los factores externos que nos limitan o condicionan, como ser la competencia.
¿sabes algo de las
4/5 fuerzas de Porter? Te recomiendo un poco alguna lectura sobre ello. Algunos libros sobre Organización de Proyectos y/o de Empresas traban de ello. En forma simple,
se trata de conseguir un equilibrio y poner en análisis 4 puntos claves: Oportunidades vs Amenazas, Fortalezas vs Debilidades para saber cómo, en donde estamos parados, y en qué debemos empezar a mejorar.
Esto acompañado del concepto de
cadena de valor te ayudará a poder contar con una visión estratégica, o al menos te aportará nuevos elementos a tomar en cuenta.
Dejando de lado lo "gerencial" por el momento, y tratando de encontrarle un giro más práctico y menos aburrido, hay al menos dos métodos básicos de como "estimar" un valor:
1) Asignar un valor a nuestra hora de trabajo
2) Calcular nuestros costos internos y de éste aplicarle un porcentaje de recuperación
Como puede verse, no hay demasiada ciencia. Nada raro ni estrambólico... o el super método chingón que aplica en la NASA; simple juegos "caseros" que utiliza cualquier negociante y trabajador común de barrio.
Si nos quedamos en el punto 1, ahora si nos toca volver a lo que había comentado antes ¿Y cuanto vale mi hora de trabajo? Y... ¿Cuánto te gustaría ganar?
Este mismo principio incluso se puede expandir, mejorar o variar un poco.
A veces no es del todo preciso, ni justo, quedarnos solamente en una valoración basada en horas. Por darte un ejemplo ¿Vale lo mismo un proyecto que te ha tomado 5 meses de trabajo y que cuenta con 10 módulos de otro que te demandó 10 meses y solamente eran 5 módulos? Muy seguramente no valgan lo mismo; mejor dicho: muy seguramente tu sientas que no valen lo mismo. !El 2do quizá sea en realidad 2 veces más complejo que el 1ro!
¿Entonces como decidir? Ponderando nuestro trabajo y poniendo tantos factores como quisiéramos en la balanza.
En muchos libros de Ingeniería de Software se dedican muchas líneas a expresar el concepto de tamaño o complejidad. No existe una única, ni real, manera de obtener tanto cuantitativa como cualitativa del tamaño o complejidad del software... A pesar de que hay varios intentos y hay varias propuestas ya aceptadas y estudiadas; como COCOMO, Puntos Función, uno es libre de utilizar sus propios patrones y unidades de medición.
Los más habituales son: (K)LDC O (Kilos) Líneas De Código que simplemente se trata de contar la totalidad de líneas de código, Cantidad de Clases y/o Módulos.
Entonces si uno mide el "tamaño" o "complejidad" como función de la cantidad Cx de x cosa y asigna un precio Px unitario la ecuación es simple:
Precio_x = Cx * Px
Ahora supongamos que uno siguiendo este planteo llega a N Precios_x. ¿Cuál es el JUSTO? Nuevamente cada uno es libre... Lo directo, fácil, y tentador nos llevaría a calcular un promedio:
Precio = (Precio1 + ... + PrecioN) / N. Pero en ocasiones el promedio no es lo más adecuado... y además se ve muy afectado por los valores extremos por lo que puede ser más bajo de lo que realmente nos resultaría viable o demasiado alto.
Yo he propuesto, como ejemplo en algunas ocasiones como para orientar y tengan algunas ideas en YR algo como esto:
Sunpongamos que cada factor evaluado y con el que hemos llevados los cálculos tiene su propio peso o ponderación. Entonces ahora en vez de promedio se aplica una media ponderada:
Precio = ((Precio1 * Peso1) + ... (PrecioN * PesoN)) / (Peso1 + ... + PesoN)
Este valor quizá si sea más justo.
El principio del tamaño no sólo puede llevarse a lo que hace al software en si, puede ser llevado para estimar en bases de datos (y que también, si es lo consideramos, suma al valor real). Un modelo que suelo exponer a modo de ejemplo es:
PrecioDB = (Ct * Pt) + (Cp * Pp) + (Ctr * Ptr)
Siendo Ct la cantidad de tablas, Cp de procedimientos almacenados, Ctr el de triggers.
Aunque también he llegado a proponer algo como:
PrecioDB = (Pt + Pp + Ptr) * Ct * 2
La explicación es simple: estadísticamente la cantidad de procedimientos almacenados y de triggers es del 50% de cantidad de tablas. Por ejemplo, si nuestra DB tiene 50 tablas, es posible que tengamos 25 SP y 25 triggers. Entonces si sumamos éstos a la cantidad Ct nos damos que sería equivalente a hacer Ct * 2.
Y ahora el precio final de todo el sistema sería algo como:
Precio = PrecioSoft + PrecioDB
Siendo PrecioSoft el precio estimado para el software.
Ahora bien, volvamos a lo que dije antes... Precio y Costo no son lo mismo. ¿Verdad? Cierto... y también he dicho que juega mucho el factor externo.
Si seguimos añadiendo más y más cosas de valor nos sentiremos muy chochos... ¡quien no!
Ahora bien ¿Y en realidad cuántas licencias esperas vender? ¿Qué te diferencia de la competencia? ¿A cuánto lo vende tu competencia?
Si haciendo un estudio de mercado calculas que podrías vender M licencias ¿Porqué no bajar un poco el precio? Después de todo... ¿Es justo que todos paguen el mismo valor del software como si se tratase de un proyecto nuevo? Digo... Si fuera a medida, o el primero que compra ¡se morfa el pago por todo tu esfuerzo! Pero los siguientes ¿Porqué han de seguir pagando ese esfuerzo ya hecho y que justamente se te ha retribuído? Después de todo... es copiar en un nuevo CD ¿o no?
Entonces si se espera ganar unos buenos clientes, y quizá más, ¿Porqué no venderlas a algo aproximado a Precio/M? Si resulta que en realidad vendes 3M... ¡Que alegría!
Que no te sorprenda si la competencia hace algo como eso para conseguir más clientes
Hasta ahora hablé de puras formulas bonitas... Pero sabes que No todo se puede resumir en fríos números. Y además, por más exacta que sea la matemática simplemente estamos en pura ESTIMACION... Por tanto aquí va la 1ra lección: Recuerda que no necesariamente los cálculos son exactos y representativos de la realidad... ¡Estás ESTIMANDO!
Si quieres estimar con toda precisión ¡Estima al final del proyecto! Asi tendrás las cifras reales y exactas... pero claro... eso ya no es estimación
Y algo muy importante ¿Donde está tu valor de emprendedor? ¿Sólo en el desarrollo del SW? Si volvemos a las lecciones de la cadena de valor deberíamos aprender una lección valiosa: el valor está en todas las etapas ¡aún cuando el producto sale a la calle! ¡Debemos seguir aportando valor cuando el producto ya esté hecho! El cliente en realidad no se limitará a quedarse contento con tu sistema. Espera que le de valor a su emprendimiento... Y una de las lecciones más aprendidas, a fuerzas, con la crisis del software es que el Software quizá no se daña pero se estropea. Tiene sus ciclos de vida.
Aquí la 2da lección: Cuando desarrollas un software, TE ESTAS CASANDO con él. Y como en todo matrimonio debes cultivarlo, mantenerlo. Y esto lleva a nuevos modelos de negocio y hacer software.
Atrás quedaron los días en las exclusivas fábricas de software. El software es un elemento más dentro de la cadena; hoy lo que vale es EL SERVICIO y EL VALOR AGREGADO que tu más puedas agregar al desarrollo de SW.
Te pregunto a ti ¿Haces solo software o brindas servicios?
Te recomiendo más que una leída a libros de Ingeniería de Software. De ellos se puede sacar mucho material de donde hilar.
Saludos,
con uds, desde ya muchas gracias.
