¿Cuándo está bien enviar un producto con un error conocido?

¿Cuándo está bien enviar un producto con un error conocido?

Supongo que está hablando de un error "conocido" (de lo contrario, la pregunta no tiene sentido). Bueno, la respuesta depende de estos factores:

1) ¿Quién es el usuario y cómo aceptará el error en caso de que se encuentre?

2) ¿Cuál es el posible impacto (daño) del error?

3) ¿Es factible retrasar el envío del software para corregir el error?

4) Lo más importante: ¿qué esperas de tu software? ¿Hora de comprar? ¿Calidad? ¿Desea ver si sus clientes usan el software el tiempo suficiente para encontrar el error?

Tiene que estar siempre bien, porque no existe un software sin errores.

Es una decisión judicial. Recuerde, un error puede ser muchas cosas. Si es una pieza importante de funcionalidad que no funciona, entonces lo arreglas primero. Si es algo menor que tiene un impacto mínimo o nulo en la utilidad del programa, puede dejarlo pasar.

Míralo desde un punto de vista costo / beneficio.

Usted envía productos con errores conocidos cuando el costo total y el riesgo de corregir el error supera cualquier problema o impacto negativo que pueda surgir si el error se presenta.

Entonces, si tiene un período de prueba de 2 semanas antes del lanzamiento, y se encuentra un pequeño error, la pregunta es ... ¿está solucionando ese error por las 2 semanas adicionales que un equipo ahora podría tener que pasar para volver a probar la aplicación y la instalación? (un paso a menudo olvidado en la creación de software)? ¿Cuáles son los costos para la reputación o las ventas si el software llega tarde? ¿La gente se va a enojar? Puede que estén muy contentos de vivir con un error menor si la funcionalidad principal se puede entregar a tiempo.

Los riesgos incluyen el riesgo de presentar un nuevo problema, no solo para solucionar el error, sino también las cosas que pueden surgir al crear una nueva instalación.

El impacto negativo es tanto el tiempo como el esfuerzo para tratar con los clientes que informan el error, y cosas como el daño a la reputación.

Los errores vienen en diferentes severidades. En cualquier compañía de software en la que he trabajado, hemos clasificado los errores en orden de prioridad de P0 a P4.

P0 Es que el software no funciona / falla y puede causar daños a los negocios del cliente. P1 No funciona como se diseñó y se bloquea constantemente en la funcionalidad principal. P2 Se bloquea ocasionalmente y / o una funcionalidad lateral puede no funcionar. P3 Algún elemento del software no funciona como se diseñó / esperaba. P4 Problema cosmético.

He trabajado en lugares donde los P4 simplemente no se arreglan porque tienen un efecto tan pequeño en el software.

Yo diría que está bien enviarlo si su software ha conocido problemas P3 / P4, lo pondré en las notas de la versión y notaré que se están trabajando.

Nunca lanzaría software con un problema P0, P1 o P2 que yo conociera.

Se llama un " problema conocido ". Google, Microsoft, Apple, etc., todos envían productos con errores, tanto conocidos como desconocidos. Intenta minimizarlos, pero no esperes a la perfección. Envíe rápido, envíe a menudo.

No puede enviar software sin errores. El consejo que puedo dar es que siempre es mejor decirle a su cliente: "Esta versión no puede hacer eso y eso, pero vamos a solucionarlo" que la situación en la que el cliente le dice a USTED que tiene un error.

cuando es una "característica"! ;)

En una nota seria, a menos que sea un programador perfecto con una configuración de prueba perfecta, para probar perfectamente cada ruta de código y eventualmente podría existir, es improbable que envíe un producto sin errores.

Por lo tanto, sea pragmático, si todo lo que ha encontrado en sus pruebas se ha solucionado, cualquier cosa adicional debe repararse según sea necesario.

Siempre y cuando sea honesto con sus clientes, puede enviar errores. Informarles acerca de todos los errores existentes les muestra que usted tiene un buen conocimiento de su software, y que de hecho está bien probado (si lo es ...). :)

Obviamente lo mejor es evitar el envío con errores.

Con frecuencia es mejor enviar un producto a tiempo, con una lista de problemas conocidos, que no enviarlo en absoluto.

Una de las cosas en el mundo de la programación que da confianza a las personas en un proyecto es si tienen un lanzamiento programado y si el horario se mantiene .

Es por eso que Ubuntu envía lanzamientos cada medio año, incluso si todavía hay problemas abiertos.

Yo diría que una buena regla general es: "¿Es este error un obstáculo?"

Si el error provoca un "escenario feliz-path" a fallar, a continuación, absolutamente no se entregue con ese error.

Si el error hace que falle un "escenario de tangente a la ruta feliz" y no hay solución, entonces no envíe con ese error.

Si se documenta un error y hay una solución conocida, entonces probablemente esté bien enviarlo con ese error.

Desde el punto de vista del consumidor ... Nunca. Mi punto es que siempre que sepa que hay un error importante en el software, nunca debe enviarlo. Sin embargo, las fuerzas de la naturaleza (negocios) anulan esto si el ciclo de producción del software está ahora en la etapa en la que puede dañar el modelo comercial y son errores menores que no: (i) comprometerán la seguridad del software (ii) afectarán la usabilidad

Como la gente ha dicho, es una pregunta muy amplia. Realmente me lleva a una perspectiva interesante: los llamados "errores" que usted reclama son solo las fallas que fueron descubiertas por sus evaluadores. Podría haber infinitas más lagunas. Recién recordé una historia interesante que escuché de un respetado profesor en un seminario de posgrado: cuando las personas en uno de los países escandinavos usaban una máquina de votación de tipo "escritura a mano reconocible", ciertas personas hackearon todo el sistema escribiendo código SQL malicioso (que el el sistema tomó como entrada normal).

Hay algo llamado FMEA (modo de falla y análisis de efectos) que es muy útil para decidir cuándo un error conocido es importante o no según:

1. Ocurrencia
2. Gravedad
3. Detección

Otro factor decisivo puede ser cómo se relaciona el defecto con su última versión. Si el error es parte de una característica nueva pero rota, entonces la falta de funcionalidad no representa una regresión de la funcionalidad. Sigue adelante y envía.

Por otro lado, si el defecto causa una pérdida de funcionalidad existente que se sabe que es útil para los clientes existentes, entonces debe bloquear el lanzamiento. Tal lanzamiento sería una rebaja para sus clientes y no serviría ni a sus intereses ni a los de ellos.

Puede haber tonos de gris en esto. Una regresión en la funcionalidad central nunca debería salir por la puerta. Alguna regresión en las características periféricas podría llegar a los usuarios principales si la versión también contiene una nueva funcionalidad en la que han expresado interés. Un defecto oscuro que probablemente no afecte a muchos clientes puede entrar en una versión, siempre que se proporcione una solución temporal cuando sí afecta a esos clientes. Los defectos en las funciones altamente experimentales que están desactivadas por defecto de todos modos nunca deberían retrasar el lanzamiento.