Hay una serie de factores que deben considerarse para llegar a un número.
- ¿De quién y cuánto capital ha sido / será gastado y puesto en riesgo?
- ¿De quién y cuánto tiempo ha pasado / pasará y estará en riesgo?
- ¿Es esta una negociación inicial o final? Es decir, los términos se establecen antes o después de que se haya creado un producto, o en algún punto intermedio.
- ¿De quién es la idea y cuál es el factor novedoso del concepto o cómo se implementó? Debe asignar un valor al concepto / idea, que generalmente es menor de lo que la gente piensa.
- ¿Qué tan crítico para el éxito es el desarrollador?
- ¿Cuáles son los márgenes de beneficio esperados? (es decir, ingresos recibidos versus costo de soporte, operación, comercialización, ventas, etc.)
Probablemente haya más dependiendo de la aplicación y las circunstancias específicas, pero estos son los tipos de cosas que debe observar para determinar qué debe obtener el desarrollador de software.
Veamos algunas respuestas diferentes a las preguntas anteriores y veamos cómo pueden impactar la respuesta.
¿De quién y cuánto capital ha sido / será gastado y puesto en riesgo?
Nos guste o no, la mercancía más crítica en la mayoría de las empresas es la capital. (Más o menos por qué se llama capital de riesgo …) La persona que pone dinero en riesgo generalmente obtiene la mayor parte de la equidad / recompensa, y con razón.
¿De quién y cuánto tiempo ha pasado / pasará y estará en riesgo?
La equidad de sudor es cuando usted contribuye con su tiempo sin compensación (o una compensación mínima en relación con el valor de mercado del esfuerzo). El valor de la equidad de sudor depende en gran medida de cuándo se contribuyó. Cuanto menos infusión de capital precede a la equidad de sudor, generalmente mayor es el valor de la equidad de sudor. La razón es que tener algo concreto reduce el riesgo del capital infundido. En general, cuanto mayor es el riesgo cuando se dona capital o tiempo, mayor es el valor de ese tiempo y dinero y mayor es la recompensa.
Por otro lado, si al desarrollador se le ha pagado / se le pagará un salario competitivo durante todo el desarrollo, entonces tienen (tenían) muy poco riesgo correspondiente y se les debe pagar mucho menos en el back-end.
¿Es esta una negociación inicial o final?
Esto nuevamente va al tema del riesgo. El momento óptimo para esta negociación desde la perspectiva del desarrollador de software es cuando su valor percibido para el proyecto es mayor. Esto generalmente es más temprano en el proyecto, pero después de que se establece el valor del desarrollador. Por lo tanto, un desarrollador que ingresa a un proyecto con un historial y reputación puede querer tener esta negociación antes de unirse al proyecto, mientras que alguien con un valor menos claro podría beneficiarse de esperar hasta que haya establecido su valor a través de los resultados.
Sin embargo, en todos los casos, esperar hasta que se complete un proyecto funciona en contra de los desarrolladores. Tienen poco poder de negociación y su valor para el proyecto es considerablemente menor una vez que se completa el trabajo.
¿De quién es la idea y cuál es el factor novedoso del concepto o cómo se implementó?
No es solo la idea de quién, sino quién lo hizo realidad: ¿quién creyó lo suficiente en la idea como para llevarla a buen término? ¿Qué tan diferente es la aplicación de lo que está disponible? ¿Cuánto aumenta la novedad o el concepto la barrera de entrada para los competidores? (Si la respuesta es “mucho”, considere si hay reclamos de patentes que deben presentarse para proteger la idea y evitar que otros vuelvan a implementar lo que hizo sin tener la inspiración de qué hacer y cómo hacerlo. Un reclamo de patente provisional proporciona hasta un año para presentar una solicitud de patente y se puede crear a un costo mucho menor que una solicitud de patente completa).
¿Qué tan crítico para el éxito es el desarrollador?
Si otro desarrollador puede intervenir para tomar su lugar, eso disminuye el valor del desarrollador. Otra forma de ver esta pregunta es: ¿qué aporta el desarrollador a la mesa? Cuanto más cerca de un producto se encuentre un desarrollador, menos valdrán.
¿Cuáles son los márgenes de beneficio esperados?
Un punto crítico que los desarrolladores / creadores de una aplicación a menudo no aprecian son las ventas y los costos operativos para generar ingresos. Una aplicación vendida a través de la tienda iTunes tiene muy pocos gastos generales, aparte del marketing y el costo de ventas que se paga a Apple cuando se registra una venta. Un sitio web orientado al consumidor tiene operación, mantenimiento, atención al cliente, marketing, posiblemente desarrollo de negocios, etc.
Estos costos deben apreciarse por adelantado, ya que desea que cualquier plan de reparto de ingresos se base en ventas netas o brutas, no en ganancias. (Es demasiado fácil manipular las ganancias).
–
Debe tener en cuenta todos estos factores. Un plan de reparto de ingresos razonable si se ha pagado a los desarrolladores durante todo el desarrollo podría ser un grupo total de 3% -10% de las ventas, dependiendo de los márgenes. Ese grupo se dividiría entre todos los que participan en el reparto de ingresos. Decidir cómo dividir el grupo se convierte en una segunda negociación. Creo que es mejor decidir cómo dividir un grupo al final del proyecto cuando se han establecido las contribuciones de todos.