¿Son los "errores" por diseño una mala señal?

29

¿Es una mala señal si los usuarios envían informes de errores para cosas que son por diseño?

¿Significa generalmente que la aplicación es confusa o poco clara, o debería atribuirla a un error único del usuario a menos que se indique específicamente?

(En realidad no tengo ningún informe de este tipo. Esta es una pregunta puramente hipotética sobre si la existencia de "errores" de diseño es o no algo malo).

Maxpm
fuente
19
Quizás a algunos de los programadores de Lotus Notes les gustaría comentar, ya que la respuesta estándar es "no es un error, es una característica que no entiendes".
James Anderson el
55
Me sugiere que los requisitos del usuario que se dan a los desarrolladores no coinciden con lo que los usuarios creen que pidieron.
temptar
77
@temptar "Es lo que pedí, pero no es lo que quería".
StuperUser
55
Recientemente se me asignó un elemento de trabajo "error" por un comportamiento que era exactamente, específicamente, lo que se explicaba explícitamente en la especificación (y que se había discutido durante la fase de especificación). Si bien el comportamiento puede haber sido inesperado desde el punto de vista del usuario (se ignoraba una configuración particular, a la que se le prestó atención en otro lugar), si la especificación literalmente todo dice "ignoremos eso por ahora para ahorrar tiempo", entonces para mí no es un error, sino una solicitud de cambio. Ciertamente, podría hacerse un buen caso para querer que eso cambie, pero no lo llame un error .
un CVn
77
@Dunk: Implementé un sistema que asumía las 24 horas todos los días, porque no pudimos convencer al cliente de la existencia del horario de verano. Simplemente no creerían que hay días con 25 horas. ¿Es eso un error en el programa?
MSalters

Respuestas:

54

¿Es una mala señal? Creo que es una advertencia que vale la pena analizar, pero también creo que seguramente sucederá.

Cuando la gente me envía algún tipo de comentario, trato de filtrarlo en tres categorías:

  • Loco
  • Peticiones de características
  • Mala comunicación

Loco

Los errores son cuando algo obviamente no funciona de la manera que esperaría, ni de la manera que el usuario esperaría. Al igual que me pidió mi nombre, ingresé "Scott", presioné enter y dijo: "¡Hola Joe!"

Peticiones de características

Esto es como "Sé que nunca hablamos de esto, pero ¿puede el programa inferir de los gestos de mi mouse que soy zurdo y mover el botón Aceptar al lado izquierdo de la pantalla?" Esto es cuando el comportamiento actual coincide con sus expectativas y las del usuario , pero quieren cambiar las expectativas.

Mala comunicación

Esto es cuando se esperaría un resultado de un escenario, pero el usuario espera un resultado diferente. A veces esto se convierte en una solicitud de función, si simplemente no han comunicado sus expectativas, pero pensaron que lo hicieron. A veces esto se convierte en un error si se demuestra que su expectativa es incorrecta.

Sin embargo, muchas veces tienes conocimiento que el usuario no tiene. ¿Qué pasaría si dijeran: "En esta pantalla, puedo agregar un registro para mí dos veces con el mismo nombre y apellido! ¡Obviamente es un error!" Su respuesta podría ser: "Hay muchas personas en el mundo con el mismo nombre y apellido, por lo que no necesitamos que esa combinación sea única. Tenemos una tarea de limpieza que se ejecuta por la noche y envía por correo electrónico un posible informe de duplicados a servicio al cliente cuando cree que detecta un duplicado con un nombre y una dirección similares, y les pide que lo verifiquen manualmente ".

Por lo tanto, debe leer cada informe de error, pero la mayoría de los sistemas complejos tendrán informes de error que en realidad son solo solicitudes de características, o posiblemente una mala comunicación de los requisitos. No entender la complejidad subyacente del mundo real es probablemente la mayor fuente de estos problemas.

Scott Whitlock
fuente
3
La mala comunicación también incluye recordar mal (o olvidar) las expectativas que se comunicaron y acordaron.
Peter Taylor
1
Grandes distinciones, pero sigo pensando que la aplicación debería intentar explicar la falta de comunicación si es posible. Con sus múltiples personas con el mismo nombre, la aplicación podría decir: "Ya tenemos 3 John Smiths, ¿está seguro de que no es uno de estos?" Con un "No, estoy seguro de que esta es una nueva opción de John Smith".
Alex Andronov
@Alex Andronov: una falta de comunicación no significa que no haya que tomar ninguna medida: cambiar la documentación, la información sobre herramientas, etc., actualizar el material de capacitación o, posiblemente, solo una breve explicación y seguir adelante.
Scott Whitlock
7

Esto no se mencionó en las respuestas anteriores hasta ahora, por lo que agregaré que también podría ser un signo de una base de usuarios ignorantes. No uso la palabra "ignorante" de una manera despectiva o condescendiente, simplemente como una forma de expresar que no tienen el conocimiento adecuado o la educación en su dominio o de las complejidades del software en sí.

La mayoría de los usuarios no son conscientes de cuán complicado debe ser el software para cumplir con ciertos requisitos. Algo en el sentido del 80% del esfuerzo se destina solo al 20% de la funcionalidad (casos marginales y excepcionales).

A veces no entienden por qué el software tiene que comportarse inherentemente de una manera determinada, muchas veces para evitar una multitud de defectos o corrupción de datos, etc.

Esto no es preocupante ya que esto mejora con una documentación y comunicación clara y concisa.

árbol de arce
fuente
2
+1, pero busque la diferencia entre complejo y complicado ... El software no necesita ser complicado en absoluto, pero a menudo es muy complejo.
Marjan Venema
Esto es muy cierto. El caso más común con el que me encuentro es que los usuarios no se dan cuenta de la diferencia entre las relaciones de muchos a uno y de muchos a muchos. Una solicitud común que recibo es: "¿puede hacer que el informe muestre el número de pedido en el encabezado?" y tengo que explicar que, si bien en aproximadamente el 95% de los casos solo hay un número de pedido en las cosas en las que trabajan, hay muchos casos en los que la consulta puede incluir datos en varios pedidos. Luego tengo que preguntar, ¿desea que enumere todos los números de pedido en el encabezado separados por comas o desea el número de pedido en cada línea de detalle en el informe?
Scott Whitlock
@ScottWhitlock Sí, es lo mismo. Un buen desarrollador o analista de negocios no solo debe hacer lo que el cliente le pide, sino tratar de descubrir el problema central que está experimentando por qué hizo tal solicitud en primer lugar. Una vez que identifique su problema, puede identificar una solución adecuada y escribir los requisitos apropiados o las historias de los usuarios.
maple_shaft
5

Si tiene un usuario experto en su campo, podría tener un problema importante. Imagine que un contador que encuentra que su software, por diseño, no sigue los procedimientos generales de contabilidad o un ingeniero que descubre que tiene una fórmula incorrecta. Esto no debería ser demasiado difícil de investigar para ver si son correctos. Rediseñe y corríjalo si es necesario, rápido.

Se debe considerar una opinión sobre una característica de IU particular o un campo que creen que debería tener un símbolo de moneda o algún otro formato, al menos hasta que obtenga más comentarios. Investigar esto podría ser un poco más difícil.

JeffO
fuente
1
No hay una respuesta única, entonces, supongo. Debe evaluarse caso por caso. Me imaginé tanto.
Maxpm
5

Los errores de diseño en mi experiencia significan que sus casos de uso no se ajustan a sus usuarios reales. Intente leer sobre el uso de usuarios reales para sus casos de uso (solo darles nombres y una descripción en miniatura hace maravillas para la calidad de los casos de uso).

Cuando los proveedores prominentes de sistemas operativos dicen "este comportamiento es por diseño", generalmente tenían en mente la facilidad de implementación o la ventaja comercial. Si no es usted, intente descubrir el conjunto de habilidades y la relación real de sus usuarios con su software. ¿Lo usan todo el día? Por diversión ? ¿Una vez a la semana porque reemplazó los formularios TPS?

Tim Williscroft
fuente
5

La interfaz de usuario debe seguir el Principio de Menos Asombro : los informes repetidos de errores en una característica que funciona según lo diseñado son una indicación de que este principio no se ha cumplido correctamente.

Joris Timmermans
fuente
3
O que hay un grupo de usuarios dividido. Por ejemplo, supongamos que su aplicación web imita un escritorio. ¿Espera que al cerrar una ventana se cierre el programa? Sí para usuarios de Windows, No para usuarios de Mac.
keppla
1
@Keppla: haces un buen punto. No puede complacer a todos, por lo que en el caso de "errores" como los mencionados aquí, se necesita una investigación para asegurarse de que no recibirá más informes de errores después de la "corrección" que antes.
Joris Timmermans
1
tal vez, pero es mucho más poderoso citar los datos de "¡cientos de personas han presentado errores en esto!" que algunos usuarios rabiosos te dicen que has violado su interpretación personal del Principio Mágico de Menos Asombro y que están asombrados. Estoy un poco cansado de esto último, ya que el "asombro" de un hombre es "directo" de otro.
Jeff Atwood
@Jeff Atwood: como dice el refrán "una golondrina no hace verano", "un informe de error no implica un error de diseño". Un solo informe de error sobre algo que es una característica no es motivo para un rediseño, e incluso varios informes sobre una característica común no necesariamente significan que la mayoría de sus usuarios no estarían más felices sin una "solución". Especialmente si su lanzamiento original ya es popular y la gente está acostumbrada a usarlo "de esa manera".
Joris Timmermans
2

Hay dos tipos de errores: la funcionalidad no coincide con las intenciones del programador, o la funcionalidad no coincide con los requisitos. Los programadores tienden a centrarse en lo primero en detrimento de lo segundo. En pocas palabras, si sus usuarios informan una gran cantidad de "errores de diseño", sus requisitos no son lo que usted cree que son.

Karl Bielefeldt
fuente
2

No necesariamente. Podría ser que el error reportado está en un uso del software que está fuera de su alcance originalmente definido. Considere el software que fue diseñado para hacer A, B y C (para un ejemplo trivial, dibuje líneas, triángulos y rectángulos). Si D es un próximo paso lógico (por ejemplo, pentágonos), el usuario puede asumir que también debería hacerlo, y que no hacerlo es un error. Pero si esto está fuera del alcance original, no es un error. En cambio, podría ser un descuido (error) en el diseño, o un área gris en las especificaciones, o un conjunto diferente de suposiciones hechas por el desarrollador y el usuario.

(Editar: agregué mi comentario a la respuesta según la sugerencia de @Marjan Venema.

James McLeod
fuente
Realmente no veo que se marque como un informe de error. Más como una sugerencia o solicitud de función. (Aunque, con algunos sistemas de seguimiento de errores, podría contar como uno de todos modos.)
Maxpm
1
Estoy de acuerdo, la mayoría de las veces, pero puede significar un descuido (error) en el diseño, o un área gris en las especificaciones, o un conjunto diferente de suposiciones hechas por el desarrollador y el usuario.
James McLeod
1
James, si agregas ese comentario a tu respuesta, la respuesta completa se vuelve mejor.
Marjan Venema
1

Creo que es una mala señal principalmente debido al hecho de que el diseño no es genérico y los requisitos de los usuarios no se entienden / analizan completamente.

Veo dos categorías de diseño: Diseño por accidente. - Diseño por intención.

El diseño por accidente conduce a tales problemas con frecuencia y no puede sostenerse.

18bytes
fuente
1

Me gustaría agregar a la respuesta de maple_shaft sobre la "ignorancia" de los usuarios. También debe tener en cuenta que el 90% de los usuarios solo se preocuparán por su propia experiencia y forma de usar el sistema. No les importan otros usuarios, ¿por qué deberían hacerlo? Nuestro trabajo como diseñadores / desarrolladores es recibir los aportes de todos los diferentes tipos de usuarios y hacer algo que se adapte a todos lo mejor posible. La mayoría de las veces no se puede hacer una solución óptima para todos.

¡Pero, por supuesto, necesita leer y evaluar los comentarios de sus usuarios! ¡Son, después de todo, los que usan tu creación!

AndSoYouCode
fuente
0

Los usuarios que enviaron las solicitudes de error generalmente no fueron consultados sobre el diseño, por lo que no es sorprendente que vean las cosas como errores que fueron decisiones de diseño deliberadas. Para un usuario, cualquier cosa que no funcione como se espera es un error.

He descubierto que el problema es a menudo una señal de que BA o PM solo recibió requisitos de gerentes, no de usuarios reales. Lo que los gerentes esperan del sistema a menudo es muy diferente de lo que realmente necesitan las personas que ingresan los datos. Me enseñaron a recopilar datos directamente de los usuarios reales, pero la mayoría de los BA con los que me he encontrado últimamente solo hablan con los gerentes (y, en general, con los gerentes relativamente mayores).

HLGEM
fuente