¿Cómo debo informar a mi cliente que los cambios en el backend después del lanzamiento de un producto no son solo una corrección de errores o una mejora?

Solo cuéntales los hechos.

Hola.

Desafortunadamente, usar Firebase no es un simple cambio en el proyecto e implicaría una cantidad significativa de reelaboración de la arquitectura. Como estimación muy aproximada, creo que tomaría alrededor de <algún número> de semanas de esfuerzo. ¿Hacemos una llamada para discutir más?

Sospecho que la respuesta aquí sería "OK, entonces no te preocupes por eso", pero nunca se sabe.

Por su naturaleza, los elementos de back-end de los sistemas son esencialmente invisibles para los clientes/usuarios finales y, como tales, a menudo tienen dificultades para comprender la cantidad de complejidad y trabajo que implican. No es su culpa, y depende de los desarrolladores como tú y yo ayudarlos a cerrar esa brecha y ponerlo en términos con los que puedan identificarse. Las metáforas son buenas para esto, especialmente si puede usarlas para mostrar las diferencias entre un cambio de tipo "corrección de errores" y un cambio más significativo como el que están hablando. El uso exacto depende de la persona con la que esté hablando, pero comparándolo con cosas como cambiar un neumático (corrección de errores) versus un cambio completo del motor (cambiar a base de fuego) en un automóvil, o reemplazar una ventana (corrección de errores) versus estructural trabajar en los cimientos de un edificio (firebase) es el tipo de cosas de las que estoy hablando.

Como una pequeña nota al margen, parece que no está convencido de que el cambio ofrezca algún valor real (o al menos no lo suficiente como para justificar el trabajo involucrado), si es así, diría que vale la pena explicar los pros y los contras del cambio, diga que está feliz de hacer el trabajo si ellos quieren, pero que no está seguro de que les dará valor por dinero.

Diría que, en última instancia, ayudar a su cliente a comprender el alcance técnico completo del cambio deseado no es su problema. En realidad, esto suena más como si no hubiera instituido un muy buen proceso de control de cambios en sus interacciones pasadas con el cliente, es decir:

• Tienes un contrato de precio fijo
• Ha permitido que el alcance del proyecto se deslice repetidamente en el pasado
• Es poco probable que le hayan pagado en "hitos", prefiriendo tal vez un depósito al principio y una gran cantidad de dinero al final.

Si ha "entrenado" a su cliente para que crea que el aumento del alcance es un regalo de promoción, no debería sorprenderse ni un poco en esta etapa. He visto muchas situaciones en las que el cliente retiene el pago final como rehén de grandes cambios de última hora, y no es justo para el desarrollador, pero muchos desarrolladores toleran ese comportamiento por ignorancia (inocente).

No se preocupe por el proyecto n.º 2, porque, sinceramente, puede ir a la sección 'Conciertos informáticos' en Craigslist en cualquier ciudad importante y ver cuántas partes intentan, a diario, realizar el trabajo de forma gratuita con promesas de más trabajar más tarde. Es un ajetreo muy común.

Preocúpate más de que este cliente no intente superarte para el proyecto n.º 1. Establece tu precio y apégate a él. Le recomiendo que cobre por hora, porque además de los cambios en su código, el cliente también esperará que migre los datos existentes a Firebase. Desarrolle un documento escrito del alcance del trabajo y pídale a su cliente que lo firme antes de comenzar cualquier trabajo. Este paso reduce los malentendidos posteriores.

Supongo que tienes un contrato con el cliente.

Para que este cambio se produzca, necesita un nuevo contrato porque es un trabajo que no está cubierto por el acuerdo inicial.

Entonces, para comunicarle que esto no es algo baladí, hágale una oferta donde especifique las horas que necesita y un precio por su trabajo.

Esa es la mejor manera de comunicar esto.

Prepararía una estimación detallada que incluyera todas las tareas que se necesitarían hacer y las horas para hacerlas y el costo total. No olvide el costo de mover los datos existentes a la nueva fuente de datos. Como suposición, estimaría que esto son varios miles de horas de trabajo, pero debe ser mucho más específico que eso, mostrarles lo que se debe hacer y lo que requeriría cada tarea importante.

También incluiría un análisis de riesgos que describa el riesgo de introducir nuevos errores, la falta de integridad de los datos, la posibilidad de que se pierdan algunos datos al transferirlos a la nueva base de datos, etc.

Una vez que lo presentes, o te pagarán una gran cantidad de dinero por hacer el cambio o no volverás a saber de él.

Hay una regla muy simple: el cliente siempre tiene la razón. Siempre y cuando el cliente pague.

El costo es: Migrar todos tus datos de MySQL a Firebase (sin perder nada). Actualización del software del cliente. Convence a todos los usuarios finales para que actualicen sus aplicaciones; eso es complicado, porque los usuarios finales odian ese tipo de cosas y tendrás pérdidas.

La actualización del software del cliente no es trivial. Pasará de una aplicación bien probada a algo que está nuevamente en un estado alfa. Pasará de un entorno estándar y probado a una solución propietaria. Hay un costo involucrado, Firebase no es gratis y, dependiendo de lo que estés haciendo, puede que no sea barato. Y de las cosas que leo aquí y allá en Internet, Firebase es fácil para cosas simples, pero puede convertirse en una pesadilla cuando te pasas de los límites. MySQL estará aquí dentro de cinco, diez o 20 años. No hay garantía con Firebase. Firebase cambiará cada vez que Google tenga ganas de cambiarlo.

Finalmente, ¿cuál es su fuente de información? ¿Habló con alguien de Google? Firebase es un producto de Google. Por supuesto, alguien de Google lo alabará hasta el cielo.

Entonces harás una estimación para este cambio "simple". El presupuesto se basará en sus estimaciones, no en la opinión de los clientes. Si cree que su estimación es demasiado alta, puede ofrecerle como alternativa para hacer este trabajo, pagado por cada día de trabajo real. Seguramente no vas a hacerlo en base a su baja estimación. Dígale que usted es un desarrollador de software profesional y que sabe más que un vendedor de Google.