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

14

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.

Mixxifoides
fuente
@downvoter, ¿quieres explicarlo?
Mixxifoides
66
Si le preocupa la percepción del cliente, ¿puede describirlos como "actualizaciones" en lugar de "parches"? :)
Chris Taylor
Si bien esta no es una respuesta directa, si puede mantener la implementación de parches lo más intrusiva y automática posible (por ejemplo, descargar actualizaciones en segundo plano, tener un servicio de actualización en ejecución para aplicar mientras está inactivo), puede mitigar la ansiedad del usuario final al no haciendo obvias las actualizaciones. Por ejemplo: ¿Cuántas actualizaciones de Google Chrome ha recibido en el último mes? (Respuesta: lotes ) Podrían lanzar 5 parches para Chrome por día, y nadie levantaría una ceja. Las actualizaciones automáticas de Windows (cuando están habilitadas) son otro ejemplo.
Jason C
"El tiempo para actualizar el software de los clientes es inferior a 30 segundos, por lo que no espero ningún problema relacionado con el tiempo. Sin embargo, es necesario cerrar sesión". ¿Qué pasa con el cliente probando el parche ellos mismos? No sé con qué tipo de software está trabajando, pero si está cerca de ser de misión crítica para alguien, querrán probar una actualización antes de lanzarla en un entorno de producción. Si bien la instalación del parche puede ser rápida y fácil, las pruebas requerirán mucho tiempo y esfuerzo por parte del cliente.
un CVn
@ MichaelKjörling El problema es que, en ese período, las funciones críticas de la misión fallaron, por lo que realmente no importaba si el entorno de producción o el entorno de prueba se actualizaron primero. Solo necesitaba trabajar lo antes posible.
Mixxifoides

Respuestas:

24

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.

ingrese la descripción de la imagen aquí

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.

Robert Harvey
fuente
3
Tal vez esta debería ser una pregunta diferente, pero de todos modos: sabíamos que estábamos probando a través de nuestros clientes, pero no pudimos detener eso en ese momento, estábamos atrapados en un ciclo. ¿Qué podríamos hacer para salir?
Mixxifoides
3
Robert, he visto este diagrama muchas veces antes. Probablemente fue correcto cuando el desarrollo de software siguió un modelo puro en cascada, pero dado que el software se puede desarrollar e implementar en pequeños ciclos, se equivoca cada vez más. Para ser precisos: para una pequeña cantidad de errores y software, la tendencia sigue siendo cierta, para muchos errores es definitivamente errónea.
Doc Brown
2
@DocBrown: el gráfico sigue siendo correcto. Ciclos de desarrollo más cortos significan menos costo por ciclo, lo cual es consistente con el gráfico. Pero eso aún no significa que deba probar alfa su software con sus clientes, a menos que haya un claro entendimiento y acuerdo de que esto es parte del proceso.
Robert Harvey
Bueno, el costo de los defectos disminuye cuanto antes se encuentre y solucione el error . Y la posibilidad de que se encuentre un error aumenta dramáticamente cuanto antes saque su software de la puerta. Eso no significa que uno deba impulsar el software no probado a producción, por supuesto. Recomiendo, por ejemplo, este artículo agileelements.wordpress.com/2008/04/22/cost-of-software-defects
Doc Brown
1
Todo lo que se necesita es un poco de autorreflexión para ver que el principio en sí mismo es sólido, incluso si los números o la forma de la curva son solo suposiciones. Incluso tenemos un nombre para ello en lenguaje de programación: Fail Fast.
Robert Harvey
10

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.

Jack
fuente
Entonces, ¿deberíamos tratar de parchear solo a aquellos clientes que realmente lo necesitan, y a los demás en un momento posterior en forma masiva para mejorar nuestra imagen?
Mixxifoides
55
Parchear para clientes individuales parece que podría ser un dolor de cabeza, especialmente si hay una gran base de clientes. La implementación de parches en un horario regular (mensual, bimensual, etc.) y la promoción de los parches a los clientes podría ser una buena manera de aumentar el interés en "lo que viene después" de su producto, así como abordar los problemas. que se están resolviendo Por supuesto, la documentación y notificación adecuadas son cruciales para comunicar al usuario final con notas de parche.
Jack
Eso realmente me aclara mucho. Parece que deberíamos poner algo de esfuerzo en usar nuestros parches para mejorar nuestra imagen. Hasta ahora estaba convencido de que eso no era posible. Siempre vi los parches como un mal necesario.
Mixxifoides
depende de cuándo en el ciclo de lanzamiento también. Si los parches están juntos en los primeros días después del lanzamiento, eso da una impresión diferente de cuando están (todavía) juntos varios meses después.
Jwent
7

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 ...

Uri Agassi
fuente
2
+1, como cliente frecuente de software, quiero que los chicos tengan actualizaciones frecuentes y buenas formas de implementarlos. Los productos que se estancan son la verdadera señal de alerta aquí, al menos significa que el vendedor no está invirtiendo en el producto. O invirtiendo en vNEXT que quieren que pague nuevamente.
Wyatt Barnett
Lo que entiendo de su último párrafo es que siempre debemos ser honestos y transparentes en nuestra comunicación con el cliente. ¿Hay situaciones que no deberíamos (todavía) informar al cliente sobre ciertas cosas?
Mixxifoides
1
Por supuesto, ser honesto con el cliente no significa dejar la línea abierta mientras convoca una reunión de pánico para mitigar un desastre recién descubierto. Debe comunicar la información después de haber evaluado la situación, tener una estrategia para solucionarla y, sinceramente, decir que todo está bajo control. Puede que te encuentres embelleciendo la verdad, pero las mentiras francas tienen una forma de atormentarte más tarde ...
Uri Agassi
2

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.

Encaitar
fuente
+1, ese es el punto clave: cuanto más rápido pueda corregir un error (e implementar), mejor, siempre y cuando el usuario / cliente no tenga ningún esfuerzo adicional con la implementación. Cuando el cliente tiene que implementar manualmente, o las actualizaciones simplemente interrumpen su flujo de trabajo, es importante encontrar la frecuencia correcta para las implementaciones. Sitios como Facebook implementarán varios parches al día y la mayoría de las personas ni siquiera lo notarán.
Doc Brown
así que supongo que tenemos suerte en esa parte. Nuestras actualizaciones nos cuestan (además del estrés y la codificación y todo) solo 1 o 2 horas. Al cliente le cuesta 1 minuto volver a trabajar. Analizaré el enfoque de 'paquete de servicio', esto puede ser útil para aquellos que no necesitan el parche directamente.
Mixxifoides
Encontré esta referencia para Facebook: blogs.wsj.com/cio/2013/04/17/… , por lo que parece que hay dos lanzamientos, no varios, por día. Todavía impresionante, supongo.
Doc Brown
'Escuché' ese código push de Amazon cada 17 segundos. Pero lo pongo en un comentario porque no recuerdo quién me lo dijo y un google no lo muestra. :-)
Encaitar
@Encaitar: Correcto, la arquitectura de Amazon tiene cientos de servicios interactivos. Así que no me sorprende si empujan algo con mucha frecuencia, pero dudo mucho que cada empuje afecte directamente a más de un componente. Lo que ves como un solo sitio web no necesariamente tiene una versión general. Es más como decir que la red de carreteras de la ciudad se actualiza cada 17 segundos porque sus equipos pintan en total 5 mil líneas nuevas al día :-)
Steve Jessop