Barrapunto

Cobra por horas (si, como meretriz). Pon que tienes que pagarte una nómina mensual y calcula cuanto te cuesta la hora.

Para gestión de empresas lo único que hay que hacer es buscar algún framework libre y retocar lo que haya que personalizar para la empresa (campos de bases de datos, consultas específicas, informes).

Lo más difícil ya lo has hecho, captar un cliente.

¿Cómo se factura? Por horas, naturalmente. Si no sabes estimar las horas que le vas a tener que echar (en órdenes de magnitud), quizás no deberías meterte todavía. Pero no me hagas caso, esa es la teoría. Hay megaconsultoras internacionales con jefes de proyecto que harían las mismas cuentas del gran capitán y si sale bien, bien, y si no, o bien se sangra al equipo de trabajo o se vacila con los plazos al cliente. (Lo normal es aplicar las dos opciones a la vez.)

Teniendo experiencia es de suponer que serás capaz de hacer un análisis antes de picar código, pon un precio a tu hora de trabajo, añades gastos varios que van a surgir y ya tienes por donde empezar. Siempre puedes dejar abierta la posibilidad de incrementar el precio si se añaden las típicas "pequeñas variaciones" que diga el cliente.

Si lo que quieres es cobrar por algo que ya tienes hecho... Pues ya va siendo hora que hagas el análisis, así te harás una idéa aproximada del precio.

La peor opción es la de venderlo al peso, 1 = tantas líneas de código.

Hola, yo trabajo como independiente en un emprendimiento con dos colegas haciendo mayormente software a medida.
Lo primero que te voy a decir es que no es fácil calcular el costo de un desarrollo. El método que utilizamos nosotros es, una vez que nos hemos reunido con la empresa en cuestión y ya tenemos bastante claro lo que el cliente necesita, dividimos el trabajo en tareas (no muy pequeñas). Luego calculamos el tiempo que creemos que le demandaría a una persona completar cada tarea (intentando de ser posible tomar en cuenta tareas similares realizadas con anterioridad).
Cuando ya tenemos un tiempo total aproximado lo multiplicamos por el precio que queremos cobrar la hora de trabajo (lo puedes calcular teniendo en cuenta cual el sueldo que te parecería justo cobrar si trabajaras como empleado ). Y de esa cuenta sale el presupuesto.
Una advertencia: Si estás empezando lo más probable es que calcules mucho menos tiempo que el real. Ten en cuenta que al tiempo de programación también debes sumarle el tiempo que perderás en reunirte con el cliente para mostrar el avance, el tiempo de instalación del sistema terminado, el tiempo que te tomará resolver problemas o errores que siempre aparecen, el tiempo que te llevará hacer las correcciones / cambios que te pida el cliente sobre el desarrollo a medida que avanzas, etc.
Una técnica que suelen recomendar es calcular el tiempo de programación y luego multiplicarlo por 2.
En fin espero que te sirva de algo y mucha suerte

Complicado.... El precio no se puede basar en el de alternativas existentes ya que estas han sido desarrolladas con la idea de vender muchas copias y por tanto el precio de cada copia no refleja el trabajo de desarrollo.

Por otra parte, el cobrar segun las horas que hayas invertido en escribir el software tampoco es lo mejor: tu programa puede puede ser relativamente sencillo y, sin embargo, para la empresa ser muy util (en este caso no deberias cobrarselo barato).

Yo creo que lo mejor es que intentes "indagar" (de manera mas o menos directa) cuanto estaria dispuesta la emrpesa a pagar por el software.

Hace un tiempo que me dedico a hacer aplicaciones web a medida. Te cuento algunas cosas que hago por si te pueden servir:

* Estimar es muy difícil y más a largo plazo. Si estás empezando, lo mejor es cobrar por horas al principio.

* A la hora de estimar por horas, tira por lo alto. El cliente te valorará más que si te considera barato, te dará menos el follón y confiará más en tus decisiones. Es triste, pero es así. Además piensa que con las horas que trabajes te tienes que pagar las horas de buscar otros clientes, cubrirte frente a un posible impago, que no tienes pagas extra, etc.

* Si las especificaciones están claras y eres rápido programando, es mejor cobrar por hitos, porque puedes sacar más beneficio de tu rapidez. Si está mal especificado, por horas. El problema con los hitos es que el cliente tiende a meter más cosas en cada hito pagando lo mismo, o tiende a meter cosas menores "en las que no había caído", duda de si estás haciendo menos en el hito de lo acordado y en general hace falta más mano izquierda. Hitos es más riesgo, horas es más seguro.

* Si lo haces por hitos, fija muy bien qué entra en cada hito y deja claro que no va a entrar nada que no esté acordado en el hito. Siempre va a conseguir meter algo extra, así que tira un poco por lo alto para no perder.

* En el caso de conseguir una buena relación con el cliente, el estado ideal es que tú hagas un hito y luego le pases el precio de lo hecho, sin acordar de antemano cuánto va a costar. Es lo que mejor sale si hay confianza. No le estimas por lo alto, así que él gana, y tú no corres el riesgo de trabajar horas gratis. Si ves que algo le va a salir muy caro (el cliente no tiene por qué saber si algo es un cambio profundo o no), avisa y dale alternativas para que pueda decidir, o pierdes la buena relación.

* Para estimar las horas que le vas a echar, una medida (totalmente empírica, a ojo de buen cubero) es contar el número de tablas de base de datos y multiplicar por X horas. Cada tabla necesita una lógica, y esta medida más o menos funciona para hacerse una idea de la complejidad del proyecto. Parece una medida chapucera pero funciona.

* Otro sistema que funciona y se puede combinar con lo anterior es construir algo que el cliente puede ver funcionando lo antes posible y en cada iteración (1-2 semanas por ejemplo), el cliente dice qué añadir y lo añades a la aplicación y lo vuelve a ver en práctica. Esto funciona mejor que entregarlo todo de golpe al final porque el cliente suele darse cuenta de que necesita cosas a medida que pasa el tiempo y ve cómo su idea se materializa, y de esta forma te da feedback, puedes cambiar la aplicación según te va indicando y ve que la cosa avanza. Si sigues este sistema, una posibilidad de trato es que en cualquier iteración el cliente puede dejar de pagarte y quedarse con lo hecho hasta la fecha (o tú puedes abandonar el proyecto). El riesgo que corres es perder lo trabajado en la última iteración, pero es un riesgo que corres en cualquier caso, y ayuda a crear confianza y mantener una relación sana.

* Si un cliente te da mala espina, no lo cojas. Si ya trabajas con él, no sigas.

Puedes usar esto como orientacion:

http://es.wikipedia.org/wiki/COCOMO [wikipedia.org]

O puedes optar tambien por indagar cuanto se cobra por eso que vas a realizar en base a tiempo, trabajo y recursos que te haran falta.

En cualquier caso nunca metas menos del salario minimo en las horas que pienses echarle claro :P (salvo que lo hagas por hobby/aficion en vez de porque tengas como objetivo primario el ganarte la vida con ello).

Ademas le pongas el precio que le pongas, siempre procura venderlo como software libre para poder luego seguir usando sin problemas el codigo de lo que programaste y que te sea util de cara al futuro (tanto en aprender de lo que otros hagan sobre ello, como para facilitar que se difunda entre la gente quien eres, puedan probar lo que haces y sepan donde estas para hacerte otros encargos (o hacer cursos si es un software relativamente complejo) o comprarte originales tuyos (u otra mercancia asociada) en el caso de que ademas tuvieses una tienda/cadena de distribucion para venderlo en plan bonito/profesional con su caja manuales y demas, que siempre estan muy bien tambien).

Lo más lógico es cobrar por horas. Por experiencia a no ser que se trate de un desarrollo muy especifico y que el cliente tenga muy claro lo que quiera es mejor no dar un precio cerrado. Primero porque en esos casos las estimaciones de tiempo por muy bien que las hagas casi siempre se van a quedar cortas y si metes horas de más puedes dar un precio inflado que eche para atras al cliente.

Lo mejor en mi opinión es hacer uso de las metodologias agiles, entregando al principio una base con funcionalidad básica a un precio prefijado y luego ir añadiendo funcionalidades que vayais acordando. De este modo el cliente va viendo cosas funcionando y tu puedes hacer estimaciones mas fiables.

Esta forma de trabajo tambien es mejor a la hora de cobrar (ahora con la crisis es bastante importante) porque puedes ir asociando el pago a las distintas entregas de las versiones, tu te aseguras de tener liquidez y el cliente le resulta mas comodo pagar a plazos, viendo ademas que van asociados a nuevas funcionalidades.

Es triste pero asi es.

He tenido la suerte, o desgracia, de conocer gente que lleva ya tiempo en el sector y que ha gozado de una cierta prosperidad (sus empresas han llegado facilmente a 50 empleados o mas), y tienen su propia filosofia.

Para ellos el principio es facil: ¿cuanto esta dispuesto a pagar tu cliente? Si lo sabes ya sabes lo que le vas a cobrar. Evidentemente no confundas el coste o el valor con lo que le vas a cobrar. Si el coste es elevado relativo a lo que esta dispuesto a pagar, olvidate y a otra costa mariposa. Si el valor es mas elevado, mala suerte, quizas consigas un canal de distribución mejor que te ayude a sacar mejor rendimiento, pero seguramente le acabaras haciendo un favor enorme.

Lo ideal seria equiparar el valor al precio de cobro, pero ni siempre es facil, ni siempre el cliente sabe el valor de lo que recibe. Aqui se juega mucho en el factor comercial y la capacidad de hacer entender al otro lo que se le pone en sus manos. He visto clientes "tirar a la basura" productos, que si hubiesen comprendido lo que eran capaces de hacer, sus negocios se hubiesen beneficiado. Aqui lo mas curioso, es que contra mas caro cobres, mas valor se cree el cliente que tiene lo que le has dado. Asi que si te quieres sentir reconocido y apreciado, quizas es buena idea cobrar caro.

Sea como sea, hay un dicho de los "veteranos" que no olvidaré: "Si un cliente te comenta que el producto es barato, es que has hecho mal tu trabajo; le podrias haber cobrado mas".

Calcula cuanto quieres ganar. Por ejemplo pongamos 1500 al mes por jornadas de 40 horas a la semana.

Calculas cuanto vas a tardar en hacerlo ( ten en cuenta el tiempo de picar, el de recoger especificaciones, pruebas, revision de fallos post implementacion, imprevistos...) Por ejemplo has calculado que todo, todísimo te llevara 200 horas.
Calcula costes extra: gasolina, tarjetas, creación de manuales, energia gastada por tu ordenador...

200 horas es 1,5 meses.

Calcula lo que se te va a comer en impuestos hacienda, pago de autónomos, así como el beneficio empresarial....porque no lo olvides te van a pedir factura.

Así chupando y alzando el dedo, si el tiempo y el salario te cuadra... si pides menos de 2800 euros palmarás dinero. Seguramente con menos de 3500 también palmes... Un justiprecio me parece entre 4250-5000 euros.

Pero ahora la preguna es.... por ese dinero ¿que pueden conseguir en el mercado?

¿Sabes dónde te metes? es más ¿Sabe el cliente dónde se mete?

Un "programa de gestión para una empresa" es SAP, el contaplus, o una excel para hacer las facturas.

El programa completo (incluso un contaplus) te puede llevar meses de hacer, y luego otros tantos meses en depurar, perfilar y ajustar. Si no tienes experiencia de como funciona una empresa, el programa será flojito.

Si no has participado en proyecto de este tipo antes, te encontrarás rehaciendo cosas (y algunas cambios profundos). No te fíes de lo que te explique el cliente, una cosa es lo que tiene en la cabeza, otra es lo el sobre entiende, otra es lo que te sabe explicar (especialmente si no tiene una mente un poco "informática"), otra que tu entiendes. Te encontrarás discutiendo con el cliente "Esto no se me dijo lo cobro aparte!".

Piénsalo, si vas ha estar 6 meses trabajando, eso deberían ser 12.000 euros mínimo (muy mínimo). ¿Está el cliente dispuesto a pagar eso? Si has calculado un par de meses, luego tendrás problemas con el cliente al subir y subir el presupuesto a medida que avanza el proyecto. O por el contrario la frustración de haber cobrado (o fijado el precio) y le sensación de estar trabajando gratis. Mucho trabajo, muchos "marrones", muchos problemas, mucho estrés, muchas horas y sin dinero. Cuando a la gente le falla el programa del día a día, descuelga el teléfono cabreado y quiere una solución en cinco minutos.

Otra cosa es si quieres invertir en hacer un programa completo para luego venderlo a otros clientes con cambios menores. En cualquier caso, siendo un programados solo, no inspirarás mucha confianza para venderlo, salvo familiares y conocidos que se quieren jugar, como supongo es ese cliente. Como te digo, si no has participado en proyectos parecidos te saldrá una aplicación flojita, difícil de vender.

Sobre la forma de calcular el tiempo ya se ha escrito bastante. Un aspecto muy a tener en cuenta, sobre todo ahora, es la forma en que se va a cobrar ese dinero. Muchas veces se peca de pardillo y se realiza un enorme trabajo que se espera cobrar al final. Y tras meses de trabajo se encuentra uno con que el cliente ya no quiere el proyecto, o no tiene dinero para pagarlo. O incluso es una empresa que desapareció.

Por eso creo que es importante establecer pagos parciales por tareas entregadas. En consultoría, es muy normal cobrar una cantidad del 25% antes incluso de empezar, luego un 50% a la entrega del principal del proyecto y finalmente un 25% tras corregir errores y realizar la integración final.

Para un proyecto pequeño quizás sea muy difícil conseguir cobrar antes de empezar, pero nunca cobraría menos del 25% por el 25% del trabajo realizado. Nunca olvidéis que es muy común que no se cobre un proyecto terminado o casi terminado. En la tarifa no sólo debe ir el precio por hora de asalariado, sino también un porcentaje que cubra los impagados, tal y como hacen los seguros y los bancos.

"programa para gestionar empresa", inventiva nuevamente, esos programas hace decadas que estan terminados y cualquiera lo consigue gratis

Para un empresario el problema de los "programas para gestionar empresas" es que incluyen un 20% de funcionalidades que le interesan, un 80% de funcionalidades que no interesan (y estorban), y les falta un 1% de funcionalidades que son cruciales para su modo de gestionar la empresa.

Yo en su día estuve probando software para montar un negocio relacionado con el mundo comercial, y probé uno que tenía buena pinta, pero lo descarté porque incluía un montón de opciones que yo no necesitaba, como por ejemplo la gestión de comisiones para los distintos comerciales (yo sería el único comercial), que suponían un auténtico engorro porque no te permitían avanzar sin rellenar el campo.

Al final terminé montándome una mierda de base de datos en Access, que era de todo menos profesional, pero servía exactamente para lo que yo lo necesitaba, y no me pedía datos de más ni de menos. De haber necesitado algo más complejo, seguramente la única solución realista habría sido el desarrollo a medida.

no has leído la continuación de la entrada, verdad? ;)

ciao!

Los "programas para gestionar empresas" (gestión/contabilidad/erps/etc...) no están ni mucho menos "terminados" y es difícil acertar con uno que se adapte a tus necesidades. La mayor parte de las empresas requieren un nivel elevado de personalización de estos programas, pero no gastas una burrada en mantenimiento, por lo que ven con buenos ojos otras alternativas.

El desarrollo a medida aún no ha desaparecido.
- Es una oportunidad para desarrollar algo a alguien que lo necesita (ya que no hay siempre un software genérico que se adapte a lo que necesitas).
- Una vez creado, si te sale bien, es posible que pienses "haciéndolo poco más genérico, hay gente a la que le interesaría". Así es como a veces nace un negocio.
- En todo caso, si hay una alternativa buena (que muchas veces no hay o no se adapta a lo que necesitas), lo mejor es no reinventar la rueda.

Lo siento, pero eso no implica la necesidad de comprar una vivienda. En casi toda Europa lo normal es vivir de alquiler y comprarse una casita cuando los hijos se han independizado ya.