¿Son los parches una mala señal para el cliente? [cerrado]

En la oficina acabamos de salir de un largo período en el que lanzamos parches con demasiada frecuencia. Cerca del final de ese período, estábamos haciendo casi tres parches por semana en promedio.

Además de que esto fue muy desmotivador para los desarrolladores, me preguntaba qué pensaría el cliente sobre esto. Yo mismo hice la pregunta y concluí que nunca conocí el software que se actualizaba con tanta frecuencia. Sin embargo, para el caso que se acerca más, no me importa realmente, ya que los parches se aplican con bastante rapidez.

Los clientes que recibieron estos parches difieren mucho entre sí. Algunos realmente estaban esperando el parche donde a otros no les importaba, pero todos obtuvieron los mismos parches. El tiempo para actualizar el software del cliente es inferior a 30 segundos, por lo que no espero ningún problema relacionado con el tiempo. Sin embargo, deben cerrar sesión.

Entonces mi pregunta con más detalle: ¿Recibir actualizaciones con frecuencia da un mensaje 'negativo' al receptor?

Por supuesto, podría preguntar a los clientes, pero no estoy en esa posición ni quiero "despertar a los perros dormidos".

PD: Si hay algo que pueda hacer para mejorar mi pregunta, por favor deje un comentario.

Al igual que con muchas cosas en informática, depende. Si los parches son una respuesta a las solicitudes de los clientes de nuevas funciones o mejoras, su empresa será vista como receptiva. Si, por otro lado, sus parches son una respuesta a los informes de errores, entonces su empresa será vista como incompetente.

Probar el software en sus clientes es, con mucho, la forma más cara posible de detectar errores, sin importar lo que digan. Es una economía falsa; La mano de obra gratuita que cree que está obteniendo está más que compensada por el esfuerzo de servicio al cliente, rompiendo el ciclo de vida del desarrollo de software y perdiendo la confianza del cliente.

Siento que lanzar varios parches en estrecha proximidad se refleja mal en la empresa. Siempre me hace sentir que no probaron lo suficiente por adelantado, que los desarrolladores son incompetentes o que la gerencia no tiene idea de lo que están haciendo.

Dicho esto, el otro lado del token es que la liberación de varios parches cerca uno del otro muestra que la compañía está adoptando un enfoque proactivo para su producto y continúa mejorando su producto para el consumidor.

Estoy más inclinado a sentir que la primera es la forma en que la mayoría lo verá desde el punto de vista del consumidor, pero hablar directamente con ellos (obviamente) será la mejor opción, pero también planteará el problema dentro de la base de clientes para que puedan No haber sido consciente inicialmente.

Cada vez más empresas siguen los pasos de Chrome y tienen lanzamientos de clientes cada vez más frecuentes.

El requisito previo para implementar ciclos de lanzamiento cortos es una actualización sencilla: en Chrome, por ejemplo, la actualización se realiza sin intervención del usuario en el inicio de la aplicación, y si el usuario mantiene su aplicación siempre encendida, recibe una pequeña señal. aconsejándole que reinicie la aplicación en el momento conveniente, y la aplicación hace el esfuerzo de devolverlo a su estado anterior después del reinicio.

Este método deja al cliente contento, ya que no necesita estar al tanto de cada actualización, y dado que las versiones de funciones se presentan con frecuencia, las versiones de corrección de errores serán igualmente bienvenidas.

Si, por otro lado, los parches aparecen después de los errores evidentes de stop-showper, y vienen en grupos, ya que los anteriores no pudieron solucionar el error o crearon un error mayor, tenga la seguridad de que sus clientes lo olerán. Esto definitivamente se reflejará mal en la reputación profesional del proveedor y disminuirá los estándares de software percibidos por el proveedor. La entrega continua depende en gran medida de pruebas unitarias efectivas y pruebas de integración para garantizar su éxito.

Sobre el tema de no hablar con sus clientes para "dejar que los perros duerman", creo que esta es una estrategia incorrecta: los clientes no son ciegos y no son tontos. Creo que una buena comunicación con sus clientes solo puede asegurarles que son su prioridad y que usted es receptivo a sus críticas. Si ha entregado lanzamientos malos un par de veces, y no los escucha quejarse, definitivamente debe preocuparse, no es que no se hayan dado cuenta, lo más probable es que estén ocupados buscando un reemplazo para usted ...

Obviamente, los parches específicos para los clientes que han detectado un problema deberán salir lo antes posible.

He visto software en grandes empresas y luego adopto el enfoque de que otros clientes recibirán esos parches como un paquete de servicio a intervalos regulares programados. Normalmente, debido a que los parches requieren un esfuerzo para instalarse y probarse en el entorno del cliente, pero en su caso, podrían usarse para disminuir el posible impacto del efecto que le preocupa.

También he visto personas que abogan por poner parches en repositorios o en sitios web donde los clientes pueden descargar e instalar los que quieran. Esto puede crear problemas para saber qué parches tienen los clientes, por lo que cuando llaman con un problema, debe determinar exactamente qué código están ejecutando, pero con cuidado de que se pueda rastrear. Luego puede obligar a las personas a actualizar a uno de los 'paquetes' más grandes cuando se lanza uno que agrupa muchos parches.

La excepción son los parches de seguridad. Se sabe que una gran compañía de software con sede en Washington se metió en el agua caliente al esperar el tercer jueves del mes antes de lanzar parches de seguridad críticos e información sobre el hackeo se filtró y forzó su mano temprano a una vergüenza aún mayor.

Google Chrome soluciona el problema mediante la actualización automática con mucha frecuencia, también requieren que ciclo el programa (reinicie Chrome o, en su caso, cierre la sesión). Ahora han hecho esa práctica normal para los navegadores y las personas ya ni siquiera piensan en ello. Pero no todos pueden ser Google.

Las aplicaciones SaaS solucionan todo el problema haciendo las actualizaciones en segundo plano.

Sin embargo, sobre todo, a menos que esté haciendo una integración o actualización continua con las nuevas características solicitadas por el usuario con mucha frecuencia, creo que todavía estamos en un momento en que la gente espera que haya realizado una cantidad decente de pruebas antes del lanzamiento. Si le da vergüenza conocer a sus clientes y hablar sobre la frecuencia de las correcciones de errores, probablemente no esté haciendo suficientes pruebas. ¿Liberó la cantidad de riesgo que estaba tomando antes de lanzar el código? Existe un argumento para lanzar un código de error muy temprano siempre y cuando sepas que es lo que es, pero creo que necesitas tener una buena comprensión de tu calidad conocida, lo que significa comprender y mantener bajo control tu tiempo para conocer la calidad.