¿Cuál es la mejor manera de introducir contratos de servicio en nuestro desarrollo de software independiente para cubrir el mantenimiento a largo plazo y ejecutar la aplicación en ‘modo SaaS’ tanto para nuestros clientes existentes como para los nuevos? ¿Qué deben cubrir dichos contratos?

Gracias por el A2A.

Esto toca lo más difícil de hacer en consultoría: la renegociación del contrato posterior al cierre.

A veces es bastante fácil. El documento de alcance original dice “esto es todo”, entregas, te pagan. Más tarde, el cliente regresa, dice “pero qué pasa con X”, donde X no estaba en la especificación original, y puedes extender tu mano y decir “claro, pero eso es extra”.

A veces, apesta. Como escribir en “soporte gratuito de por vida” y no entender realmente lo que eso significa (ese casi se vino abajo en mi primer negocio de consultoría de software, ¡afortunadamente, el cliente cerró antes que nosotros!). Espero que ese no sea el caso.

O peor, el cliente que venía con X, y X no estaba específicamente en el contrato original, pero se puede argumentar que está implícito en Y, que estaba en el contrato, y que simplemente te lo perdiste …

Eso no es bueno. Eso significa que, potencialmente, deberías haberlo hecho y no lo hiciste, lo que abre la puerta para que el cliente cuestione todo tipo de otras cosas …

Voy a tomar la posición de que lo correcto es ir al cliente con un nuevo Acuerdo de Soporte, que dice de una manera mucho más sólida desde el punto de vista contractual “en consideración al hecho de que le entregamos un código de trabajo por Contrato X , y debido a que desea que este código se admita y modifique con el tiempo, aceptamos que estaremos disponibles para hacerlo en una base de tiempo y materiales, a veces mutuamente convenientes para nosotros por una tarifa de $ X / h, y de manera expedita base a $ 2X / h “.

Probablemente también les ofrecería el derecho de comprar alguna “preferencia” pagando un anticipo mensual que precompraría un pequeño número de horas en forma prepaga, pero las horas son para usarlas o perderlas. sobre una base mensual.

¿Y en cuanto al aspecto “crítico para la vida”? No es tu proyecto. No es tu problema. Si nunca te vuelven a llamar y la gente muere, ESO ERA ELLOS, NO TÚ.

Vital para la vida?

No puedes tener tiempo de inactividad. Tendrá que aprender a combinar HA con el mantenimiento programado y las actualizaciones. Esperar que los clientes de sistemas “críticos para la vida” estén de acuerdo en que puede fallar, ya sea en un horario publicado o sin advertencia, está fuera de discusión.

Además, como este tipo de cosas me asusta, dime qué es lo que produces para que al menos pueda tratar de evitarlo …