La pregunta es probablemente demasiado amplia. Las razones por las cuales son infinitas.
jmq
77
La pregunta es: nave con errores o no enviar a todos :)
Vitor Py
41
Todos los productos se envían con errores.
Joel Etherton
44
Definir ERROR. Recientemente enviamos un producto que no se instalaría. Gran error: D
Barfieldmv
2
¿Te refieres a 'errores conocidos'?
Nadie
Respuestas:
12
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?
pero parece que él está al tanto del error ... así que en ese momento parecería que un programador está siendo flojo para no arreglarlo al estar al tanto ...
Kenneth
77
@Kenneth: Podrías verlo así, pero los productos tienen que enviarse y siempre tendrán errores. Dependerá de la gravedad del error en cuanto a si retrasas tu fecha límite.
Matt Ellen
1
@ Matt, esto es cierto. Sin embargo, me parece que en la mayoría de los casos no querría enviar a sabiendas un producto con errores importantes. Eso significaría que los errores restantes que conoces serán menores, lo que en la mayoría de los casos se solucionará fácilmente o al menos se solucionará. No puede manejar los errores que no conoce, pero si el proceso de prueba se realiza correctamente, la mayoría de los errores deberían detectarse ...
Kenneth
1
Tal vez mi sarcasmo no fue claro ... pero decir que "siempre está bien" enviar software con errores es algo irresponsable. Es como decir "siempre habrá asesinos en el mundo, así que no importa si voy y mato a algunas personas".
DisgruntledGoat
77
@DisgruntledGoat No todos los errores son iguales: algunos son soluciones fáciles, otros son desastres que destruyen proyectos. Obviamente esos deberían ser reparados. Algunos son errores muy raros, difíciles de encontrar, basados en circunstancias inusuales, y generalmente difíciles de solucionar sin una gran reescritura. A veces, esos solo tienen que quedarse porque arreglarlos ofrece muy poco valor y el software debe enviarse ayer. Se trata de análisis de costo / riesgo / beneficio.
CodexArcanum
33
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.
Un error tipográfico en el cuadro 'acerca de' es algo que realmente debería solucionar. Tomará aproximadamente 0.7 segundos (suponiendo que ambos escribamos a la misma velocidad). Sin embargo, si dejas ese error tipográfico, la gente puede verlo . Es la muerte instantánea para la confianza de sus usuarios en su software si hay errores visibles en la interfaz de usuario.
Esto me parece correcto. La mayoría de las veces hay algunos errores menores conocidos en un producto, incluso cuando se va a lanzar. Tienden a ser cosas que son muy inusuales y tienen un efecto insignificante en la operación y el uso real del software o cosas que la mayoría de los usuarios nunca ven.
glenatron
3
De hecho, los errores tipográficos en su interfaz de usuario rompen la fe en la calidad de un producto (erróneamente, ya que muchos programadores excelentes simplemente no hablan bien inglés), sin embargo, entiendo su punto: errores triviales que no causan ningún daño real y probablemente nunca llegarán arriba no valen la molestia de retrasar un lanzamiento. Déjalo como una viñeta en 1.01.
Phoshi
No permita que haya errores ortográficos en su aplicación. Francamente, estoy más avergonzado por ellos que un error real.
ChaosPandion
1
No tengo idea de lo que estás hablando sobre ...;)
Andreas Johansson
6
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.
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.
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).
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.
Respuestas:
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?
fuente
Tiene que estar siempre bien, porque no existe un software sin errores.
fuente
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.
fuente
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.
fuente
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.
fuente
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.
fuente
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.
fuente
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.
fuente
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.
fuente
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.
fuente
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
fuente
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).
fuente
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:
fuente
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.
fuente