En el desarrollo de software independiente, ¿qué tipo de sanciones deberían tener las empresas cuando no cumplen con los plazos? [cerrado]

Estaba hablando con un co-desarrollador.

Él tiene un cliente que quería asegurarse de entregar a tiempo. El cliente quiere repercusiones por plazos vencidos.

Si bien no hago trabajo independiente, no pude dar una respuesta.

Entonces, mi pregunta es:

¿Qué repercusiones acuerdan ustedes (freelancers) con su cliente si no cumplen con los plazos de entregables (aparte de ser despedidos)?

Uno de los más efectivos: penalización por día de retraso. Esto también es lo que se hace para grandes proyectos, la multa es a veces miles de dólares por día.

Si una fecha límite precisa es importante (por ejemplo, si se desarrolla para los Juegos Olímpicos una aplicación web que se encargará de la transmisión del evento en 2014, la fecha límite sería el comienzo de los Juegos Olímpicos en 2014), entonces la medida efectiva podría ser que en En el caso de que el proyecto llegue tarde, la empresa no recibe ningún pago y también debe pagar una multa.

Si tales medidas drásticas no son apropiadas, entonces el solo hecho de que un cliente bien pagado se irá si el proyecto llega tarde puede ser el truco.

Nota para el cliente:

1. Muchos retrasos son culpa de los propios clientes. Las causas pueden ser múltiples:

   • No SRS, pero en su lugar dos párrafos que describen de manera poco precisa lo que el cliente imagina que son sus necesidades (y, por supuesto, el cliente no quiere pagar por la recolección de requisitos, considerando este paso como una pérdida de tiempo).

   • Llegando dos semanas antes de la fecha límite final y diciendo que no importa que el proyecto se haya realizado en Java hasta ahora y haya usado Oracle: es imprescindible que se reescriba en Python y use MySQL, porque el cliente ha leído una revista ayer. diciendo que esas tecnologías son el futuro.

   • Con un nuevo conjunto de requisitos en cada reunión. Puntos de bonificación cuando esos requisitos contradicen casi todos los requisitos dados hasta ahora.

2. La buena comunicación es esencial para un buen proyecto.

   Muchos otros retrasos se deben a la falta de comunicación. Las prácticas en las que el cliente no tiene comunicación alguna durante meses con la compañía y espera ser contactado solo una vez que el producto está terminado y pulido, invita a un desastre.

3. Tienes lo que pagas.

   Existen procedimientos específicos que ayudan a mantener el proyecto organizado, y en realidad, la programación debería tomar solo del 10 al 15% de tiempo para proyectos grandes y del 15% al ​​20% de tiempo para proyectos medianos. Esos proyectos también deben ser realizados por personas que saben lo que están haciendo.

   En la práctica, los clientes no están dispuestos a pagar $ 800 / día a un analista que creará arquitectura y diseño de software, y tampoco quieren pagar por otros pasos. Un programador albanés novato que está feliz de trabajar por $ 50 por día parece mucho más ventajoso.

   No se queje de que el proyecto es un desastre cuando solo está listo para pagar proyectos desastrosos.

4. No negocies el tiempo requerido para hacer el trabajo.

   A menudo encuentro las discusiones así:

   Desarrollador: dados los requisitos, puedo entregarlo en cuatro meses.
   Cliente: es imposible. El proyecto debe hacerse en dos meses.
   Desarrollador: bueno, a menos que elimine algunas características ...
   Cliente: ¡ No puedo! Todas las características son necesarias. ¿Por qué no puedes hacer el trabajo en dos meses? Me puse en contacto con un programador indio, un amigo mío, puede entregarlo en un mes y medio, ¡y solo pide la mitad del precio!

   El tiempo de negociación es una receta para el desastre.

5. Conoce tus prioridades.

   Tenga en cuenta la regla del 90%. Cuando el proyecto se gestiona incorrectamente, no es inusual ver a los desarrolladores decir que han realizado el 90% del proyecto un mes después de comenzar el proyecto. Luego, un mes después, sigue siendo del 90%. Y un mes despues.

   Esto puede tener dos causas:

   • Cuando el proyecto no se realiza correctamente, es decir, el 100% del tiempo se dedica a la programación, lo que deja un 0% para la recopilación de requisitos, la arquitectura, el diseño y las pruebas, lo que sucede es que los programadores no tienen idea del trabajo que deben hacer, y descubren nuevas tareas durante toda la vida del proyecto. Preparar el proyecto ayudaría a tener una mayor comprensión de todas las tareas que deben llevarse a cabo.

   • Cuando el cliente tiene prisa, no es inusual que algunas empresas entreguen basura rápidamente y luego pasen una enorme cantidad de tiempo resolviendo errores. Algunas empresas trabajan solo así, lo que les ayuda a mantenerse competitivas y dicen que lograron un proyecto determinado en tres semanas, incluso si más tarde, pasaron tres años resolviendo el problema.

   Poner las prioridades en orden y exigir que el proyecto se realice correctamente ayuda a eliminar esas compañías de la lista de candidatos.