Cuantificar el precio del código fuente y el producto de software

Estoy a punto de emprender un proyecto. Esto requiere que escriba código, y toneladas de él. El requisito del cliente es entregar todo el código fuente al final del proyecto.

Mi pregunta es: ¿Cómo cuantifico el precio del código fuente y el producto de software? ¿Hay alguna métrica que se siga para determinar el precio? ¿Cómo cuantificaría el producto de software?

Información adicional: la aplicación debe ejecutarse en cualquier lugar, en cualquier sistema operativo, incluidas tabletas (iPad, pestañas Galaxy, etc.), teléfonos inteligentes (iPhone, teléfonos Android, etc.) y también en la web. (Ahora, imagina cuánto código será este) .

Nunca se puede saber un precio exacto o casi exacto, ya que depende de muchos factores. Ejemplo:

Caso de estudio

Recibió una solicitud de un sitio web pequeño basado en WordPress. Lo único que tiene que hacer: trabajar con su diseñador para crear gráficos atractivos, luego crear el sitio web en sí (nada muy técnico, solo un conjunto de complementos para agregar a WordPress) y luego implementarlo. El trabajo es realmente fácil, lo cotizaste en $ 600.

Su diseñador creó el primer borrador. El cliente explicó que no lo encuentra atractivo en absoluto. Lo mismo ocurrió con el segundo, tercer y cuarto borrador. Finalmente, después de dos semanas de arduo trabajo, el diseñador finalmente obtuvo el borrador que fue aceptado por el cliente.

Pero, lamentablemente, el diseñador fue atropellado por un autobús y lo único que obtuvo fueron los archivos JPEG que le envió, pero no los PSD originales, por lo que tuvo que comenzar de nuevo con un nuevo diseñador. Finalmente, obtuviste los gráficos y comenzaste tu trabajo.

Sorpresa: descubrió que el complemento A es incompatible con el complemento B, que el complemento C no funciona como se esperaba y que el complemento D no se puede instalar en la versión más reciente de WordPress, mientras que el complemento A solo se puede instalar en esta nueva versión. Ahora tiene que hacer una gran cantidad de codificación PHP a mano, y dado que es un desarrollador de Python y nunca escribió una sola línea de código en PHP, no es la tarea más fácil.

Mientras tanto, el cliente comienza a enviarle correos electrónicos aterradores, preguntándole por qué el trabajo aún no se realizó, mientras que la fecha límite era hace una semana. Finalmente termina la codificación PHP, y todo funciona perfectamente en su máquina. El cliente esta contento.

Luego, comienza a implementar el sitio web en el servidor de alojamiento para descubrir que no solo el sitio web falla con algún error críptico, sino que también la empresa de alojamiento no admite una función de PHP que ha utilizado mucho en su código.

Finalmente, después de gastar más de $ 3,000 en este proyecto, tiene el sitio web en funcionamiento. El cliente está enojado por los plazos y porque "nada funciona como se esperaba". ¿Pedirías $ 600? $ 3,000?

¿Por que sucede?

Lo que ilustré en este ejemplo ocurre mucho más a menudo de lo que crees. ¿Por qué? Porque hay demasiadas variables que no puedes predecir y que aumentan el riesgo. Aquí, el riesgo aumentó por:

• Las especificaciones poco claras relacionadas con el diseño visual,
• La muerte del diseñador.
• La incompatibilidad de los complementos que ha seleccionado,
• El mal soporte de los complementos que has seleccionado,
• El hecho de que no hayas usado PHP antes,
• La diferencia entre el entorno de desarrollo y el entorno de producción y la ausencia de puesta en escena.

Uno podría resolver esos problemas con enfoques específicos:

• Requisitos funcionales y no funcionales claros y precisos,
• Gestión de escenarios Hit-by-a-bus (es decir, el diseñador tuvo que compartir todos los documentos con usted para que pudiera estar muerto en cualquier momento sin comprometer el proyecto),
• Conocimiento previo de herramientas e idiomas que debe usar (lo que requiere mucho trabajo),
• Estadificación, pruebas intensivas, etc.

El único problema es que con este enfoque, debe decirle a su cliente que pagará al menos $ 5,000 en primer lugar, ya que en realidad es el precio de los requisitos, las especificaciones, el diseño, las pruebas, etc. Su presupuesto es extremadamente bajo.

¿Entonces no hay nada que hacer?

Si no puede dar un precio muy preciso, aún puede dar una aproximación, que tenga en cuenta cada parte del trabajo para hacer por separado, con un índice de riesgo afectado en cada parte. Mayor es el riesgo predecible, mayor es el precio.

Tienes dos formas de hacer eso:

1. Watefally way

Si trabaja en proyectos que se ajustan a Waterfall / V-Model, esto puede funcionar:

1. Enumere los requisitos funcionales y no funcionales de un proyecto. Obtenga el documento firmado por el cliente, de la misma manera que firma el contrato.

2. Una vez que recibió este documento, ya tiene:

   • El precio que ya gastó reuniendo los requisitos y creando este documento. Esto puede representar una cantidad importante de dinero, ya que esos documentos pueden variar de veinte a cien páginas para un proyecto ordinario, y pueden ser cientos o miles de páginas para proyectos grandes.

   • La comprensión clara, precisa y completa del producto que debe hacer.

3. Vaya con su equipo paso a paso, analizando cada requisito y evaluando:

   • Un precio promedio de esta parte del proyecto,

   • Un precio máximo sin tener en cuenta el riesgo,

   • Un índice de riesgo.

   Los tres se tendrán en cuenta para determinar el precio que le dará al cliente.

4. Asigne el riesgo que no depende de un requisito específico, sino más bien de la compatibilidad entre los requisitos o el sistema en general.

Ventajas del enfoque de waterfally: el cliente obtiene un precio que es bastante preciso, teniendo en cuenta que tiene una visión muy clara del trabajo a realizar y los riesgos que pueden surgir.

Contras del enfoque de waterfally: debe escribir un documento de 200 páginas antes de dar el precio. ¿Qué pasa si el cliente cancela el proyecto mientras tanto, o va a su concurrente? Todo el proceso también es extremadamente pesado y los requisitos no pueden cambiar más adelante.

2. Manera ágil

Si trabaja en proyectos que se ajustan a Scrum u otros modelos ágiles:

• o no dan el precio general del proyecto, sino los precios de cada componente,
• o puede indicar un precio general muy aproximado al principio, y luego dar el más preciso.

En ambos casos, debe tener una fuerte confianza entre usted y el cliente, o tener excelentes personas en el departamento de ventas. De otra manera,

• en el primer caso, la persona creería que solo le estás robando su dinero pidiendo pequeñas cantidades una y otra vez, y esto nunca terminará,

• en el segundo caso, la persona no entendería por qué está cambiando su precio todo el tiempo, especialmente si el precio aumenta la mayor parte del tiempo.

Ventajas del enfoque ágil: el cliente puede cancelar en cualquier momento. Además, si cancela en las primeras etapas, todavía tiene un código fuente que funciona.

Contras del enfoque ágil: el precio es demasiado impreciso o ni siquiera se da. La mayoría de los clientes no estarían dispuestos a hacer negocios con usted si no les dice cuánto tendrán que pagar.

No acepte un proyecto cuando no está claro tanto el resultado como el dinero que el cliente debe pagar. Solo hago lo siguiente:

• Proponga los pasos y pagos que el cliente debe hacer.
• Cuando el paso anterior esté hecho y totalmente pagado y el cliente esté contento, pase al siguiente.

Para el método de pago, elija el pago según las características. Entonces, si el cliente tiene la oportunidad de abandonar las funciones si no puede pagar todo el proyecto.

Recibir un pago basado en líneas de código (LOC) es una estupidez. ¡Porque LOC no significa nada! ¡Sé inteligente, escribe un buen código y carga según la función !.

Buena suerte,

No acepte un precio fijo por un compromiso abierto. Serás jodido cada vez que lo hagas.