¿Cómo manejar a los colegas que no están dispuestos a escribir un informe de error?

Trabajo como desarrollador de software en una pequeña empresa (~50 empleados).

Mi proyecto principal es una aplicación móvil. Tengo a la mayoría de mis colegas en el canal de prueba alfa y los clientes no tienen acceso a este canal.

El problema es que algunos de mis colegas y mi jefe no están dispuestos a usar el sistema de tickets para informar sobre errores.

Apenas la semana pasada, mi colega pensó que había visto un error y me despotricó y deliró durante 5 minutos y le dije que anotara el error en el sistema de tickets. Ella no lo haría. Algunos de mis compañeros de trabajo se emocionan mucho cuando ven un error y prefieren despotricar sobre el error en lugar de informarlo.

Los errores deben informarse para que pueda poner el tiempo en mi hoja de tiempo.

La empresa tiene una persona de control de calidad que analiza la aplicación exclusivamente, pero también realiza otros trabajos.

Nota: la mujer que me despotricó usa el sistema de tickets todos los días.

my boss [is] unwilling to use the ticketing system to report any bugs&& Bugs need to be reported so I can put the time into my timesheet. ¿Su empresa requiere que llene su hoja de tiempo? Si es así, ¿su jefe no actúa según los estándares de su empresa?
Sí, hay momentos en los que incluso mi jefe directo no está dispuesto a escribir un informe de error a pesar de que usa el sistema de tickets a diario, al igual que algunos de mis compañeros de trabajo.
¿Tiene alguna idea de por qué no ingresan errores a través del sistema de tickets? Parece que están familiarizados con él, así que ese no es el problema. Si le preguntas a tu jefe por qué no ingresa errores, ¿qué responde?
No, no sé por qué. Dijo que si es algo pequeño, entonces no puedo hacerlo en ese momento, pero si no hay un ticket, entonces no puedo hacer mi hoja de horas ni rastrear el problema. Supongo que en lugar de registrar el problema, quiere una respuesta inmediata, incluso si no es una emergencia. Sin embargo, interrumpe mi flujo de trabajo. La otra mujer no pudo responderme por qué. Ella no tenía respuesta. Ambos usan el sistema de boletos todos los días.
@ user1261710 Tienes que hablar con tu jefe. El consejo a continuación es bueno, pero la respuesta más votada, por ejemplo, no se puede usar si su jefe no respalda su enfoque, y parece que ese no es el caso. ¿Ha hablado con él en detalle sobre cómo manejar el tiempo de notificación de problemas no informados? ¿O simplemente se lo quitó de encima?
¿Hay algo que le impida ingresar el informe de error en su nombre?
Algo no encaja aquí, si su colega usa el sistema de tickets a diario pero en lugar de usarlo para su proyecto se pone "emocional" y "despotrica". Necesitamos más de la historia.
@CarlKevinson Tal vez sea una buena sugerencia a primera vista, pero este tipo de "habilitación" solo te lleva a terminar haciendo el trabajo de todos por ellos y a que esto se considere normal. Sin embargo, también hay una consideración de "elige tus batallas" y esto puede, en general, ser la mejor opción viable para el OP. Lamentablemente, nuevamente, no tenemos suficiente información para juzgar adecuadamente.
¿Te pagan por hora? ¿Es esencial enviar una hoja de tiempo precisa para garantizar que le paguen?
¿Se niegan activamente o simplemente no se molestan en hacerlo?
¿Es necesario que estos usuarios estén en el canal alfa? ¿O simplemente los tiene allí para aumentar sus pruebas antes del lanzamiento?

Respuestas (21)

Dígaselo tal como es: ella no informó el error, por lo tanto, el error no existe. Ella solo desperdició diez minutos de su tiempo y el tuyo despotricando sobre el error. Y mañana, le envías un recordatorio por correo electrónico. Que cree que tuvo problemas, pero no hay un informe de errores en el sistema de emisión de boletos, por lo que necesita agregar esto. Envíele los recordatorios por correo electrónico durante al menos una semana.

Dígale también que despotricar sobre errores es totalmente inaceptable. Siempre habrá errores, ese es un hecho de la vida donde se desarrolla el software, y despotricar al respecto solo puede molestar a la gente (no me molestaría a mí, porque lo interpretaría como una estupidez, no como un error malo) sucediendo que no debería estar allí).

Y la próxima vez que comience a despotricar sobre el próximo problema, la interrumpes después de cinco segundos. Le dices que su trabajo es poner la descripción del error en el sistema de tickets, que no aceptarás ningún informe de error en la conversación y que definitivamente no aceptas sus despotricaciones. Luego te vas, o si es tu escritorio, le dices que se vaya.

Si bien este es un buen consejo en general, desea establecer el tono sin que parezcan niños o tengan una mansión condescendiente. Quiere que trabajen con usted y jueguen su juego, así que actúe en consecuencia.
De acuerdo con lix. Estos son compañeros de trabajo, no subordinados. De hecho, una de las personas problemáticas es el jefe del OP. Tomar ese tono con tu jefe sería un GRAN no-no.
Me gustaría añadir una perspectiva diferente. En el hospital donde trabajo como médico, fuimos convocados para probar un nuevo sistema de archivo electrónico de pacientes. No funcionó muy bien. Los desarrolladores nos pidieron que nos adaptáramos a sus necesidades, y no al revés (sentimos que les estábamos haciendo un favor, mientras que ellos nos hicieron sentir que deberíamos estar felices de ayudarlos). Esto provocó resentimientos hacia los desarrolladores. Si realmente desea eliminar el error, póngalo fácil o hágalo usted mismo si eso le ahorra tiempo.
Esto me hizo no votar: "Envíale los recordatorios por correo electrónico durante al menos una semana". Sugiero "enviar un recordatorio después de unos días". No eres su manejador. Tienes pruebas de que lo intentaste. es su responsabilidad ahora. Esto está en línea con li x y David K.
Esto suena como una receta para establecer una mala relación laboral y una forma de garantizar que este usuario evite usar su aplicación siempre que sea posible.
Este es un consejo bastante desastroso. Generará resentimiento y los compañeros de trabajo usarán esa actitud como ejemplo de por qué es difícil trabajar con desarrolladores.
Tenga en cuenta con este consejo que OP indicó que su jefe era una de estas personas. Tratar al jefe de uno de esta manera es una gran manera de ser despedido.
Parte de esta respuesta se trata de capacitar a sus compañeros de trabajo para que utilicen los sistemas existentes específicamente para la tarea de gestión de errores. Si no lo usan, entonces es una pérdida de dinero de la empresa, además, es otra pérdida de dinero y tiempo tener que escuchar una diatriba de 10 minutos que podría ser una lectura de 3 minutos, y sin la política o el daño personal. sentimientos. Los errores son un hecho de la vida y, a menos que sean súper críticos, deben abordarse como un hecho más, para ser abordados en algún momento posterior cuando el tiempo y el presupuesto lo permitan.
Nadie debería gritarle a nadie más en una situación como esta. Despotricar hará perder el tiempo y causará muchos resentimientos. Cuando estaba abrumado con el trabajo y no me daban prioridades, las personas que eran amables conmigo tenían prioridad, y los problemas por los que me despotricaban se dejaban para más tarde.
"Tomar ese tono con tu jefe sería un GRAN NO-NO", bromeas. Me conocen por hacer eso y cosas peores. Busque a Dan Pena para una actitud más alfa / de alto rendimiento.
"Ella no informó el error, por lo tanto, el error no existe". El error existió. No permita que los procesos se interpongan en la mejora del software. “Entonces te vas, o si es tu escritorio, le dices que se vaya”. No ponga barreras en el camino de las personas que se comunican con usted. Existe un sistema de seguimiento de errores para ayudar al equipo a priorizar y realizar un seguimiento del trabajo. No es una herramienta de comunicación.
@Martijn "es su responsabilidad ahora" Aunque veo a lo que te refieres y estoy de acuerdo hasta cierto punto, el hecho es que este proyecto es responsabilidad del OP, por lo que no es realmente tan claro. El OP aún necesita solucionar el problema; no pueden simplemente fingir que no existe porque no se informó de manera deseable.
@BenMz Es difícil encontrar un equilibrio cuando las personas se comunican con usted no solo de manera inapropiada sino también ineficaz. No sé dónde está el término medio, pero seguramente hay uno, y encontrar alguna manera (descargo de responsabilidad: ¡no tengo idea de cuál sería eso en esta situación!) Para permitir que el colega se comunique sin complacer su aparente necesidad de hacerlo de la manera "incorrecta" sería apropiado En mi experiencia, este tipo de política e ingeniería social puede, lamentablemente, ser la mitad del trabajo de un desarrollador de software a veces :(
@JoeStrazzere, sí, la broma "... por lo tanto, no existe" es lo que hace que la gente se enoje al rojo vivo y se vuelva vengativa hacia los desarrolladores.
@BenMz: ""Ella no informó el error, por lo tanto, el error no existe". El error existió". - Estoy de acuerdo en que va un poco demasiado lejos. "Ella no informó el error, por lo tanto, el error nunca se ingresó en la cola de cosas para trabajar. En consecuencia, no se puede esperar que se solucione". es más preciso en mi humilde opinión. (Tenga en cuenta que esto no significa que el desarrollador no pueda simplemente presentar el informe de error en su nombre, según la diatriba). Sin embargo, no estoy de acuerdo con su afirmación de que "Un sistema de seguimiento de errores [es] no una herramienta de comunicación ." - Sí, eso es exactamente lo que es. ¿Qué más podría ser?
Los sistemas de seguimiento de errores de @ORMapper son herramientas para el seguimiento del trabajo. La mayoría de las características son para ese propósito. Puede usarlos para comunicarse, sin embargo, la relación señal / ruido es terrible.
@BenMz: "seguimiento del trabajo" es comunicación. Transmitir a (por ejemplo) los desarrolladores lo que se debe hacer. Transmitir a (por ejemplo) los gerentes de producto lo que ya se ha hecho. Indicar algún contexto de forma parcialmente estandarizada. Etcétera. Todo eso es parte del proceso de comunicación.

Además de "dígales que no puede corregir los errores que no se informan" (como se explica en las respuestas recientes), debe hacer que informar un error sea lo más fácil posible . La mayoría de las personas que no son de TI se sienten intimidadas por la perspectiva de tener que usar el sistema de tickets y piensan que es demasiado complicado para algo que simplemente pueden decirle a alguien .

Si un colega comienza a despotricar, muéstrele el sistema de tickets (dónde encontrarlo) y archive el error juntos para mostrarle cómo hacerlo. Si es posible, cree una plantilla con la información más importante que necesita:

  • Nombre de la aplicación (no creerás cuántas personas lo olvidan)
  • que querian hacer
  • ¿Qué/dónde hicieron clic?
  • Lo que sucedió en lugar del comportamiento deseado (el error real)
  • Agrega una captura de pantalla si es posible
  • Nombre del informador de errores para devolver la llamada

Además, anime a sus colegas a reportar errores . Déjales en claro que informar un error es bueno, útil y tiene un resultado positivo. Algunos pueden tener ganas de traicionarte al revelar los "errores" que cometiste.

La mujer que me despotricó usa el sistema de tickets todos los días.
@ user1261710 Entonces ella realmente no tiene motivos para quejarse... Todas las demás respuestas aún se aplican
@ user1261710 El hecho de que alguien use algo no significa que disfrute usándolo. Como desarrollador de más de 20 años, todavía odio registrar errores. La mayoría de los sistemas de emisión de boletos son difíciles de manejar, no establecen campos predeterminados que deberían tener valores predeterminados obvios, tienen demasiados campos obligatorios y terminan requiriendo 4 veces más tiempo para informar un error que hacerlo en persona. Todavía lo hago, porque entiendo la necesidad, pero también entiendo completamente por qué los que no son desarrolladores no querrían hacerlo. Así que concéntrese en las partes de esta respuesta que lo alientan a hacerlo más fácil y comunicar los beneficios.
Solía ​​trabajar en una empresa en la que nuestro sistema tenía errores frecuentes, de modo que encontraba errores nuevos varias veces a la semana, a veces varias veces al día. Entiendo la importancia de denunciarlos, así que lo haría. Sin embargo, el formato para reportarlos era tan largo que me tomó alrededor de 15 minutos completarlo. Perdería de 1 a 3 horas a la semana completando informes de errores. YElm tiene toda la razón en que informar el error debe ser lo más fácil posible, de lo contrario, es solo un dolor.
@user1261710 ¿Usan el sistema de tickets diariamente para procesar los tickets o archivarlos?
Nuestro sistema es bastante bueno. Sin errores Es estudio visual en línea. Hay algunos campos para completar, pero no toma 15 minutos. Tal vez 5 o menos.
@ user1261710 No necesita justificar su sistema de informe de errores. Es bueno escuchar que su sistema no es demasiado complicado y que sus colegas lo usan a diario, pero este puede no ser el caso para otras personas que se tropiezan con su pregunta y pueden encontrar información útil en esta respuesta.
@Nicholas: "El hecho de que alguien use algo no significa que disfrute usándolo". De todos modos, muestra que no solo es capaz de usarlo, sino que realmente lo usa , por lo que se deben hacer preguntas sobre por qué no lo usa para este proyecto en particular. Algo no está del todo bien aquí.
@LightnessRacesinOrbit Veo su punto, pero la razón por la que lo están usando para otras tareas podría ser porque no hay una solución más fácil (como lo que están haciendo en este caso), o que no usarlo para esas tareas causará demasiadas repercusiones negativas para ellos, o cualquier número de otras razones. No digo que sean razones válidas. Pero si la mayoría de los usuarios eluden este proceso, creo que la resolución se vuelve más importante que la culpa, incluso si estos usuarios realmente tienen la culpa.
@Nicholas: Exactamente, entonces, si el OP deja de ser el camino de menor resistencia, los resultados mejorarán;) Pero sí, resolver cualquier causa raíz subyacente sería una solución más amplia.
@user1261710 Diferentes roles usan sistemas de emisión de boletos para diferentes propósitos. Los analistas comerciales definen los requisitos, los gerentes de proyecto generan informes, los ingenieros de control de calidad se enfocan en los errores y casos de prueba, etc. El uso de un sistema no implica dominio o incluso comodidad con todos los aspectos del mismo.
Si las personas saben cómo usar un fb, también saben cómo archivar un error. Ser perezoso o pensar que tiene derecho a repasar los procedimientos es algo diferente.

Tomado de Joel Spolsky , cofundador y director ejecutivo de Stack Overflow; quien escribió en su blog :

Por ejemplo, suponga que no se puede persuadir a nadie en su equipo para que use una base de datos de errores. No dejes que te moleste. Solo quédate con el tuyo. Introduzca los errores que encuentre en su propio código. Si encuentra un error que alguien más realmente debería corregir, asígnele el error utilizando la base de datos de errores. Si tiene un buen software de seguimiento de errores, esto les enviará un correo electrónico. Pero ahora, puede seguir enviándoles correos electrónicos si no solucionan el error. Eventualmente, verán el valor del seguimiento de errores y comenzarán a usar el sistema como se pretendía. Si el equipo de control de calidad se niega a ingresar errores en el sistema de seguimiento de errores, simplemente niéguese a escuchar los informes de errores a través de cualquier otro canal.. Sobre la tresmilésima vez que le dices a la gente, “escucha, me encantaría arreglar eso, pero lo voy a olvidar. ¿Puedes introducir un error en el sistema? comenzarán a usar la base de datos.

[Énfasis mío]

Tenga en cuenta que la listen, I’d love to fix that, but I’m going to forget. Can you enter a bug in the system?cortesía es la parte clave de esta respuesta.
Acordado. Como desarrollador, si no está en el sistema de seguimiento de errores, no lo sé. Por lo tanto, no ayudará a nadie si me gritan por algo que no sé. Responder de la misma manera a alguien que grita no suele tranquilizarlo, por lo que la cortesía suele ser el tratamiento adecuado. "Ok, veo que esto es un problema. ¿Por qué no me llevas a través de los pasos para reproducir el problema y comenzaremos un ticket..." Después de 1 o 2 veces de esto, espero que tengan la idea de simplemente inicie un ticket y evite sus 1000 preguntas "para obtener más información para incluir en el ticket". :->
La propia compañía de Spolsky reconoció que pedirle a la gente que ingrese errores en el software FogBUGZ que venden es tan oneroso que desarrolló un sistema que permite a las personas simplemente enviar un correo electrónico y se creará automáticamente un error.
Bueno, si mantener el tiempo al tener el error en el software adecuado es tan crucial, alguien tendrá que usar ese sistema oneroso. Si OP comienza a hacerlo por sí mismo, es probable que el problema no desaparezca. Es mejor no recompensar el comportamiento no deseado, como quejarse en voz alta en el escritorio de desarrollo.
La cuestión es que el OP no está hablando del "departamento de control de calidad". El OP está hablando de algo más parecido a, en la jerga del Sr. Spolsky, "pruebas de usabilidad de pasillo". ¿Es razonable esperar que personas que no son de control de calidad completen informes de errores pomposos? Probablemente no, a menos que sea específicamente parte de su trabajo.
Esto es lo que me quedé para hacer en mi último puesto permanente. Configuré Mantis en un servidor interno y lo iba a usar hasta que todos los demás lo hicieran. Pero terminé dejando la empresa primero.
@teego1967, para citar otro artículo de Joel Spolsky con mi negrita añadida: "Evite la tentación de agregar nuevos campos a la base de datos de errores... Es muy importante no ceder a estas ideas. Si lo hace, su nueva pantalla de entrada de errores terminará con miles de campos que debe proporcionar, y nadie querrá ingresar más informes de errores. Para que la base de datos de errores funcione, todos deben usarla, y si ingresar errores "formalmente" es demasiado trabajo, la gente recorrerá la base de datos de errores".
@Wildcard, sí, eso es exactamente lo que sucede en muchos lugares. Antes de que te des cuenta, el formulario se convierte en un desastre completamente inutilizable para todos, excepto para la persona que lo creó.
Joel puede dar este consejo porque él es el jefe. Un solo desarrollador militante que imponga su propio proceso preferido personal en la organización no va a terminar bien.
Aunque no es un "seguimiento de errores" per se, tenemos un sistema de emisión de tickets en ${EMPLOYER} en el que le digo a las personas que ingresen una solicitud para documentar esa solicitud antes de que pueda implementarla en cualquiera de las aplicaciones en las que soy administrador. . Esto es puramente para cubrir mi trasero para que nadie me acuse de ser el Llanero Solitario. Literalmente, alguien me preguntó "¿por qué hiciste eso?" solo que yo presente el número de ticket donde la misma persona solicitó el cambio. Imagínese ser arrojado debajo del autobús sin algo así para demostrar que fue culpa del acusador todo el tiempo.

Una cosa a la que muchos no desarrolladores tienen aversión son los sistemas de seguimiento de errores que están estrictamente interconectados para los propósitos de los desarrolladores . Estos rastreadores de errores suelen utilizar un formulario único masivo de "talla única" con demasiados menús desplegables/campos/botones de radio no aplicables o ininteligibles. Estas cosas son abrumadoras para completar y, además, con frecuencia quedan sin respuesta o simplemente se cierran de una manera que parece caprichosa.

Si desea abordar el problema sin simplemente obligar a sus colegas a cumplir, considere formas de optimizar el sistema de informe de errores y hacerlo más receptivo. Esto podría ser tan simple como escribir una oración corta a la persona que informó el error (en lugar de simplemente seleccionar un estado en un menú desplegable). ¿Está recopilando cosas como el número de compilación automáticamente o está haciendo que los usuarios lo encuentren? ¿Los usuarios saben cómo tomar una captura de pantalla en su teléfono (y llevarla al rastreador)? Te sorprendería cuántas personas no pueden. Estos parecen obstáculos triviales, pero si se necesita investigación para "descubrir" cómo completar el informe de error, MUCHAS personas simplemente no lo harán.

Alternativamente, puede intentar trabajar con un usuario "alfa" que esté dispuesto a ser un intermediario para el resto de los usuarios. Haga que esta persona complete los informes de errores reales en nombre de otros. De esta manera, obtiene sus boletos y los usuarios pueden hablar con un humano y los problemas se notan y resuelven.

¿Qué pasa si no te importa obligar a tus colegas a cumplir? :PAG
@PoloHoleSet, mucha gente está de acuerdo con eso. Sin embargo, se consume buena voluntad para obligar a la gente a hacer cosas. No esperes favores o consideración a cambio si obligas demasiado a la gente. Será mejor encontrar la causa raíz y solucionarlo en lugar de fingir que todo es problema suyo y descartar los informes de errores que no están en el rastreador.
Totalmente en broma, de la persona hastiada que tiene que dar soporte y arreglar los errores del lado de las cosas.
Upvoted para el tercer párrafo. Tenemos un usuario tan "alfa", y es maravilloso.

Introduzca el informe de error usted mismo. Si puede extraer suficiente información de la conversación o el correo electrónico para que el error sea reproducible, genial. De lo contrario, al menos tendrá el error mal definido registrado para vincularlo con otras ocurrencias en el futuro.

¿Por qué digo esto? Su trabajo es producir una pieza de software con la menor cantidad de errores posible. Eso significa que los informes de errores son algo que deberías desear mucho. Si hace que el proceso sea demasiado engorroso, las únicas personas que reportarán errores serán aquellas cuyo trabajo principal sea hacerlo, y su producto se verá afectado.

Tu opinión sobre la dificultad de usar el rastreador de errores es irrelevante: aparentemente tienes más de un usuario al que no le gusta usarlo. Por lo tanto, acepte gentilmente sus aportes, cree un error en el rastreador y conviértalos en los creadores si es posible. Si no puede, tenga en cuenta que fue informado por fulano de tal y continúe con su trabajo. O pídale a su persona de control de calidad que llame al reportero e ingrese un error si es real.

El problema de que su colega no siga el proceso no es su problema. Es el problema del gerente de tu colega. Y dado que ha dicho que incluso su gerente no siempre sigue este proceso, concéntrese en las formas en que puede hacer su trabajo.

Y si las personas tienen un problema sobre los errores ingresados ​​por ellos mismos, puede completar un formulario en papel mientras despotrican y pedirles que lo firmen una vez que terminen de despotricar y usarlo como prueba del informe. Si se niegan a firmar, dígales que no puede corregir el error de otra manera.
Si OP ingresa el error para este colega, eso solo la alentará a ella y a todos los colegas a venir y despotricar siempre en lugar de ingresar el error ellos mismos (que es la forma oficial en que se deben hacer las cosas).
Asi no es como funciona esto. Producir software con pocos errores es solo UNA parte del trabajo de un desarrollador. Con su razonamiento, "No debería molestarme en comentar el código o ingresar buenos comentarios de compromiso. Mientras mi código no tenga errores, todo es juego limpio". Todos tienen un rol diferente, y hay procedimientos. Hacer el trabajo de otras personas solo porque se niegan a seguir los procedimientos es una forma segura de enredarse en otro lío más adelante. Especialmente cuando no entendiste el error correctamente y mañana la misma persona volverá a despotricar aún más fuerte.
No dije que no deberías hacer tu trabajo. Dije que no deberías preocuparte por si la otra persona está haciendo su trabajo. Lo que no es su trabajo es administrar a su colega o hacer cumplir los procedimientos de la empresa a sus compañeros.
@Dragonel: No necesariamente. Un resultado muy posible es que, por un lado, el desarrollador termine trabajando de manera más eficiente, porque los informes de error escritos por el desarrollador dicen "después de hacer clic en X en el módulo Y, aparece el mensaje de error Z", mientras que el error informa sobre el mismo problema. por colegas reacios a leer "la función X falla". Y, por otro lado, los colegas que sienten que los informes de errores que el desarrollador escribe ellos mismos carecen de precisión (por ejemplo, porque el desarrollador carece de algún conocimiento del dominio sobre casos de uso representativos) de repente tienen un incentivo real para escribir los informes ellos mismos.
@ORMapper: estoy de acuerdo en que si el desarrollador y el colega hablan de manera racional y se combinan para ingresar el error, puede ser mucho más fácil de solucionar, pero alentarlos a venir y despotricar cada vez que encuentren un error puede afectar gravemente la productividad de los OP y puede no ser útil. información si están "despotricando" en lugar de "discutiéndola". Hacer que ingresen un error, luego OP va a discutir cualquier cosa que no esté clara es una práctica más estándar porque ahorra tiempo de discusión sobre errores que OP ya conoce o puede entender instantáneamente.
Sí, y marque al informador/archivador de errores como ellos.

Simplemente envíeles un correo electrónico con una solicitud cortés para informar el error en el sistema de emisión de boletos y envíe una copia a su gerente. Si no aparece, haga un seguimiento con su gerente copiado.

Es el rol de los gerentes asegurarse de que el personal esté usando las herramientas correctamente, también es su rol asegurarse de que nadie fuera de su equipo lo confronte personalmente ni lo insulte. No tienes la autoridad para hacerlo cumplir, y no es tu trabajo intentarlo.

Básicamente estoy de acuerdo con usted, pero OP dijo que incluso el gerente a veces no está dispuesto a escribir un informe de error, por lo que probablemente esto no ayude a largo plazo:/
Cuando la gerencia misma no sigue las reglas y encona el ambiente tóxico, es hora de escalar o pulir el CV. Probablemente ambos. @dontbyteme
@dontbyteme: "el gerente a veces no está dispuesto a escribir un informe de error": por extraño que parezca, una completa falta de voluntad para presentar informes de error y un compromiso total para hacer cumplir un "no realice ningún cambio en el código a menos que tenga un elemento de seguimiento de problemas para "eso" puede muy bien coexistir en la vida real.

Mi proyecto principal es una aplicación móvil. Tengo a la mayoría de mis colegas en el canal de prueba alfa y los clientes no tienen acceso a este canal.

Hasta ahora tan bueno.

El problema es que algunos de mis colegas y mi jefe no están dispuestos a usar el sistema de tickets para informar sobre errores.

Tal vez no tan bueno como parecía.

Apenas la semana pasada, mi colega pensó que había visto un error y me despotricó y deliró durante 5 minutos y le dije que anotara el error en el sistema de tickets. Ella no lo haría. Algunos de mis compañeros de trabajo se emocionan mucho cuando ven un error y prefieren despotricar sobre el error en lugar de informarlo.

Ahora, mirando hacia atrás en la primera cita, una pregunta que me viene a la cabeza es quién puso a sus colegas en el canal de prueba alfa. El propósito de sus pruebas es generar los informes de errores. Ahora habrá algunas personas que no pueden dedicar tanto tiempo como pensaban a las pruebas, o usar tan pocas funciones del producto que apenas prueban el programa, pero es necesario que las personas que completen el ciclo realicen las pruebas. .

Los errores deben informarse para que pueda poner el tiempo en mi hoja de tiempo.

No, no lo hacen. Los errores deben informarse para que la calidad del producto mejore. La hoja de tiempo es la forma en que registra sus horas. El sistema de informe de errores es la forma en que los desarrolladores saben qué se debe corregir. El objetivo de las pruebas alfa es garantizar que la mayor parte de los errores no lleguen a los clientes.

La empresa debe asegurarse de que las personas asignadas a las pruebas alfa o las voluntarias sepan lo que se espera de ellas. Necesitan saber los plazos, los procesos, cuánto tiempo implica y qué tipos de informes necesitan producir. Necesitan saber si se espera que prueben toda o solo una parte de la aplicación, necesitan saber qué hacer si prueban la parte x y no tienen ningún error que informar.

¿Qué sucede si los procedimientos de registro de horas de la empresa exigen que se incluyan los identificadores de error? "Pasé 15 minutos arreglando el error 641. Pasé 30 minutos arreglando el error 832" y así sucesivamente. Similar a cómo la mayoría de las hojas de horas (programadores) requieren que el nombre del proyecto o el código se incluyan cuando están realizando un trabajo de desarrollo regular.
Si bien recibir un pago es importante, si las pruebas alfa no producen informes, ¿cómo mejorará el producto? es por eso que los participantes necesitan entender las expectativas.
@mhoram_psprep: Cobrar es importante. Para la empresa, hacer las pruebas es más importante, pero para el individuo que le paguen es más importante. Los participantes no solo necesitan entender el proceso, necesitan alguna razón para seguirlo.
Por eso incluí el último párrafo. El objetivo de la prueba Alfa es mejorar el producto. Si no entienden que no deben participar o necesitan capacitación.
@alroc Si ​​la hoja de tiempo espera ID de errores, entonces no hay nada que impida que uno cree una ID de ticket según sea necesario para el informe, incluso si no hay discusión en el ticket.
Aunque no se indica, las confirmaciones de código fuente también pueden requerir un número de error. El último lugar en el que trabajé fue así, cada compromiso tenía que incluir el número del proyecto o el error contra el que se comprometió. Al principio parecía un poco draconiano, pero ayudó a mantener un registro de las cosas. Por lo tanto, es posible que, literalmente, no pueda corregir un error sin un informe de error.
"Los errores deben informarse para que pueda poner el tiempo en mi hoja de tiempo". "No, no lo hacen". OP dice que es obligatorio, por lo tanto, es obligatorio.
@ Industry7, creo que te perdiste el punto. Las hojas de tiempo no son la razón por la que se deben informar los errores.
@Wildcard "Se deben informar los errores para que mejore la calidad del producto". Para mejorar el producto, el qa puede simplemente acercarse al escritorio del desarrollador y explicarle el problema en persona. Absolutamente NO tiene que ingresar errores en un sistema de seguimiento para solucionarlos. Básicamente, le está diciendo a OP que le diga al jefe de OP: "Corregir errores no mejora nuestro producto. Informar errores en el sistema de seguimiento mejora nuestro producto".
@ Industry7: No entiendo de dónde sacas la suposición de que los errores no escritos se corregirán en lugar de olvidarse.
@or-mapper: no estoy seguro de dónde proviene su confusión. Para ser claros, todos los trabajos tienen responsabilidades, y si no puede recordar cuáles son las responsabilidades de su trabajo, probablemente lo despidan.

El problema es que algunos de mis colegas y mi jefe no están dispuestos a usar el sistema de tickets para informar sobre errores.

Ninguno de estos se refiere a que su jefe tampoco quiere hacer esto.

Recomendaría tres cosas.

Primero, hable con su jefe y comprenda por qué su jefe no está dispuesto a usar el sistema de tickets. Al final del día algo está mal aquí. Debe completar una tarjeta de tiempo con precisión, pero su jefe está trabajando activamente en contra de su capacidad para hacerlo. ¿Su jefe siquiera sabe esto?

Si tus colegas están literalmente, como dices, "despotricando" contigo durante cinco minutos y a tu jefe no le importa, tu jefe apesta. Personalmente, sospecho que hay mucho más en esta historia de lo que ha presentado aquí, pero independientemente de lo que necesite hablar con su jefe.

Incluso preguntas como "Bob no quiere enviar informes de errores, ¿cómo quieres que haga un seguimiento de ese trabajo?" es significativo

En segundo lugar, reflexione seriamente sobre el proceso por el que deben pasar sus colegas al informar un error. Hay equipos con los que trabajo para los que he dejado de escribir informes de errores debido a lo frustrante que es ese proceso.

Más o menos he delegado el "¿es esto un error?" les pregunto ya que he tenido demasiadas experiencias negativas trabajando con ellos, ya sea cerrando el ticket como "no servirá" o cambiando un informe de error a una solicitud de función o discutiendo conmigo sobre si es un error, solo tengo paciencia por mucho de eso antes de que deje de importarme. Les informo la funcionalidad a través del chat y les dejo decidir si es un error. He perdido demasiado tiempo tratando de "probarles" las cosas y, en última instancia, no es mi responsabilidad mejorar su producto.

Por último, si la situación es realmente lo que estás describiendo aquí, tu lugar de trabajo suena realmente horrible. Pero, es probable que haya dos lados de la historia y lo que todos nos estamos perdiendo (incluyéndote a ti, parece) es la otra historia.

La empatía es importante. Múltiples compañeros de trabajo, incluido su jefe, "despotricando y delirando" en lugar de informar un error correctamente sugiere que hay una gran falta de empatía en alguna parte de las interacciones.

El OP podría insistir en que todos los demás usen el sistema de emisión de boletos e ingrese errores solo para su jefe.
El jefe es el corazón del problema. Nadie más lo hará si ven que el jefe del OP no se molesta. Este es un jefe que socava su propio problema de personal.

Menciónalo, dile a tus compañeros que

Si no usa el sistema de emisión de boletos, no puedo arreglarlo porque no se incluye en mis hojas de tiempo.

De esta manera, van a multar a los errores; de lo contrario, parecerá que los errores no se "Encuentran" y son ellos los que tienen la culpa, no usted. Por lo tanto, multan a los errores o dejan que los errores entren en una aplicación en vivo. Esto pone la pelota en tu cancha.

Luego, pueden acudir a su gerente y decirle que no está solucionando los errores, pero luego puede razonar con ellos allí y es probable que su gerente se ponga de su lado y les pida que usen el sistema de emisión de boletos.

Sin embargo, para evitar la conmoción, simplemente dígaselo a su gerente.

Las personas están encontrando errores y los estoy arreglando, pero se niegan a registrarlos en el sistema de emisión de boletos para que pueda marcarlos en mi hoja de tiempo, por lo tanto, mis hojas de tiempo no son precisas.

Como desarrollador desde hace mucho tiempo, odio informar errores en un sistema de informes de errores. Todos requieren la entrada de múltiples campos, casi todos de los cuales no sé la respuesta o no me importan. Y también son lentos. Además, cuando termino, el desarrollador siempre lo cierra "no se puede reproducir" de todos modos.

Yo, al usar su aplicación, agradecería mucho un botón allí mismo en la aplicación que informaría el error en su aplicación. Tomaría una captura de pantalla, conocería su propio maldito número de compilación, serializaría el registro de las últimas 100 interacciones de UI o cualquier otra cosa que lo ayudaría a reproducir el problema, y ​​también agregaría otras cosas de interés para usted, el desarrollador, que tiene allí mismo en RAM. en este momento y, tal vez, permitirme opcionalmente ingresar un comentario.

Entonces todos seríamos felices.

Usamos JIRA. Todo lo que tiene que hacer es ingresar los pasos para reproducir el error y quizás adjuntar una captura de pantalla. Pero la gente todavía no. Pegan una captura de pantalla en un correo electrónico y dicen "Encontré este problema". Si tienen incluso el "título" más pequeño como "líder" (un líder ni siquiera es un gerente), también agregarán comentarios de opinión sobre el sistema. Debido a estas personas, la empresa contrató a una persona cuyo trabajo consistía en tomar esos correos electrónicos e ingresarlos en JIRA.
Como desarrollador desde hace mucho tiempo, me encanta informar errores en un sistema de informes de errores. :D
@hjf y eso es probablemente lo correcto: ahorra tiempo a los usuarios y, por lo tanto, les ahorra dinero y, por lo tanto, proporciona suficiente dinero para la nueva contratación.
@Mark, la persona fue despedida, pagó una compensación completa y fue contratada nuevamente 3 meses después. Los clientes (nuestros clientes son empresas de telecomunicaciones multimillonarias) amenazaron con rescindir nuestro contrato si no se restablecía dicha posición.
@hjf parece que su empresa aprendió la importante lección de que ningún sistema puede reemplazar a un buen administrador humano :-)

Trabajé para una gran empresa de TI en el pasado y muchos de los empleados de un equipo en particular se negaron a usar el sistema de tickets. Perdieron sus trabajos eventualmente debido a la redundancia.

No hay registro del trabajo que debe realizarse en el sistema, por lo que la planificación de la fuerza laboral no tiene ningún registro en el que basar sus estimaciones futuras.

Los sistemas están ahí por una razón que no es para divertirse y las personas no siempre piensan en el panorama general y ven esto como otro obstáculo que tienen que cruzar para hacer su trabajo. Enfatice la importancia de registrar el trabajo para que puedan contabilizar su tiempo.

Esto es cierto. Todo el proceso de usar Rally o JIRA o lo que sea para rastrear el trabajo es un PITA, y esos están entre los mejores. (No me haga comenzar con ServiceNow). Parece un trabajo pesado y molesto... hasta el día en que el vicepresidente de su departamento le dice todo, lo sigue de cerca y usa todos los números de resumen allí para ir a la junta y obtener su presupuesto para el próximo año ...

Si bien estoy de acuerdo en general con las otras respuestas, además quiero agregar otro punto de vista.

Por supuesto, usted y su gerente pueden obligar a sus colegas a escribir informes de errores, pero si estos colegas no son desarrolladores o no están familiarizados con los sistemas de tickets, podría terminar con muchos tickets inútiles como "la característica estúpida X no funciona". Luego, podría devolverles el boleto con "no claro", pero esto conduce fácilmente a un ciclo infinito e inútil, que no le ayuda en nada.

Otro enfoque sería sentarse con ellos para reproducir el error y luego crear un informe de error significativo. Esto puede parecer más lento, pero tiene varias ventajas:

  • sus colegas sienten que se abordan sus problemas
  • sus colegas se informan sobre la información que necesita para corregir errores
  • obtienes un informe de error significativo con toda la información necesaria
  • pasa menos tiempo clasificando tickets incompletos

Al final, este podría ser un enfoque más rápido y satisfactorio.

El hecho de que el desarrollador se siente con el usuario para ver el error demostrado no está relacionado con si hay un sistema de tickets o no. Nunca resolvería un caso porque no estaba claro. Hago preguntas más específicas y tal vez hago una visita al usuario, y esto es con un buen sistema de informes de errores. No creo que esto responda la pregunta.

Punto de vista alternativo: agradezca tener colegas que estén lo suficientemente comprometidos como para brindarle información directa sobre el producto.

Sí, deberían escribir buenos informes de errores, pero no todos lo hacen. Y lo más probable es que, como desarrollador, usted mismo escriba un mejor informe de errores.

Por lo tanto, recomendaría el siguiente enfoque en el futuro:

  • Deje en claro que está agradecido por el aporte de sus colegas. O para decirlo de otra manera, deja muy claro que no los consideras un problema que deba desaparecer. Esta podría ser la reacción percibida si dice "archivar un error".
  • Explique que será el mejor uso del tiempo de todos si se sientan y escriben juntos el informe de error , allí mismo.
  • Trabaje con su propia plantilla/lista de verificación de informes de errores.
  • Capture absolutamente todo lo que pueda sobre el error, mientras tiene la atención de la persona y la capacidad de reproducirlo frente a usted, mientras el problema está fresco en la mente del reportero. Esto es particularmente importante para las aplicaciones móviles, donde es posible que no tenga acceso a un dispositivo de prueba que reproduzca el problema, o puede ser un problema que solo se puede reproducir en una instancia de instalación específica de la aplicación.
  • Asegúrese de que el reportero esté suscrito a las actualizaciones sobre el error por correo electrónico, para que pueda verlo progresar a través del sistema.
  • Agradezca a su colega por su aporte y dígale cuánto valora las "pruebas de usabilidad de pasillo" (como dice Joel) y que se preocupan lo suficiente como para informar errores. Diga que desearía que más personas en la empresa hicieran esto.

Al adoptar este enfoque, se le percibirá como abierto y receptivo a los informes, educará al reportero sobre cómo es un buen informe de errores y ambos sentirán que han logrado algo como equipo.

Tanto el producto como las relaciones en el lugar de trabajo se beneficiarán de la adopción de este enfoque.

¿Debería estar agradecido de que la gente se acerque a él (cualquier desarrollador al azar) y RANT sobre un error? Lo siento, ¿aún trabajas para una empresa? Parece que no eres consciente de lo tóxicas que son algunas personas, especialmente las que tienen "títulos de trabajo" más altos que los tuyos.
Como desarrollador, obtener una breve descripción de un error, con una demostración , a veces es mucho mejor que tratar de interpretar la descripción típica de un no desarrollador en un informe de error "formal", especialmente si incluyen una "captura de pantalla" que no realmente mostrar el error. Pedirle al usuario que intente grabar su pantalla probablemente también consumirá mucho más de su tiempo. En una organización , usar tiempo extra del "presupuesto" de otras personas es en realidad menos eficiente en general.

Mi primer trabajo tenía un problema similar. Mi grupo creó un software que usaron algunos de nuestros ingenieros y se sentaron justo afuera de nuestra habitación. Todos estaban acostumbrados a volver y decirnos cuando teníamos un problema que hacía que se olvidaran algunas cosas.

Iniciamos un sistema de tickets para combatir esto, ayudar a realizar un seguimiento de las cosas y eliminar las interrupciones. Tomó un tiempo, pero eventualmente conseguimos que la gente usara el sistema siempre diciendo "¿Puso un ticket en el sistema?" y no trabajar en ningún problema hasta que esté listo. También les recordamos que esto no es solo para nuestro beneficio, sino también para que sus problemas no se olviden. Si se grabó, eventualmente se haría.

¿Los colegas involucrados son desarrolladores? En caso afirmativo, debería ser fácil explicarles cuál es el proceso y por qué ayuda tener todo organizado. De lo contrario, es posible que no estén familiarizados con los sistemas de seguimiento de errores y no entiendan por qué son útiles.

Se les ha pedido que ayuden a probar la aplicación, lo que significa que lo ven muy diferente a un probador, por ejemplo. Un probador sabe cuál es el proceso y sigue los pasos. Un colega al que se le pide que pruebe la aplicación asumirá que cada error es un gran problema y asumirá que puede decírselo y explicarle personalmente por qué es un gran problema, en lugar de agregarlo a una herramienta de seguimiento.

Encuentra con qué se sienten cómodos

Si se sienten mejor al agregar la descripción a un documento, bríndeles acceso a un nuevo documento de Google para eso. Luego revise los problemas y agréguelos usted mismo al sistema de seguimiento de errores, si realmente son errores. Eso no debería llevar demasiado tiempo. Podría ser mejor que hacer que completen detalles insuficientes en una herramienta de seguimiento de errores.

El objetivo es lograr que las personas envíen comentarios valiosos, no que usen las herramientas a las que está acostumbrado.

Si las respuestas principales aún no logran que sus compañeros de trabajo escriban sus errores y se los envíen en el sistema de tickets, esta es una forma segura de asegurarse de que su tiempo de trabajo se asigne al sistema de tickets.

Primero, anota todo lo que tu compañero de trabajo te dice sobre el error. Si es posible, pídales que le envíen un correo electrónico al respecto para que tenga algo que leer.

A continuación, escriba el error usted mismo.

Finalmente, solucione el error: si lo sabe y se espera que lo solucione, arréglelo.

Esto hace un par de cosas por usted: coloca el error en el sistema de tickets para mostrar que le ha asignado tiempo de codificación, y también pone el tiempo que pasó escribiendo el error en el sistema, esencialmente, el tiempo que el 'desperdicio' de su compañero de trabajo al contárselo en persona se convierte en tiempo facturable para usted .

Debe continuar alentando a sus compañeros de trabajo a que escriban sus propios informes de errores, ya que eso es lo que deberían estar haciendo, y no debe desalentarlos. Pero en lugar de eso, si su objetivo real aquí es tenerlo en el sistema para que pueda registrar el tiempo dedicado a trabajar en él, simplemente escríbalo usted mismo y obtenga el crédito por escribir y solucionar el error.

Incluir el hecho de que el compañero de trabajo se niega a escribir errores es una forma de poner a esa persona en su contra. Es más probable que la gerencia se ponga de su lado si NO soluciona un error no informado, que si "delata" a un compañero de trabajo. Les preocupa más que la gente "no pelee" que conseguir un producto de calidad.
@hjf Eso suena como una gestión horrible... pero también creo que podrías tener razón. Editaré mi respuesta. Todavía estoy convencido de que deberían escribir el error ellos mismos, pero eliminar la parte en la que delatan debería ayudar.
@hjf No pensaría en ello como "soplar". Simplemente puede ingresar el error como "Joe Smith informó que hacer clic dos veces provoca un bloqueo del sistema". Solo los hechos. Es importante saber quién encontró originalmente el error en caso de que necesite más detalles. No creo que nadie pueda reprocharle a la persona que ingresa el informe que incluyeron el nombre de la persona que realmente encontró el error.

Es posible que sus colegas simplemente prefieran la interacción humana en lugar de ingresar datos en una herramienta.

Así que arrástrelos a una reunión periódica . Si su empresa no es apta para reuniones (¿quizás no tiene buenas salas de conferencias con monitores grandes?), camine hasta el escritorio de cada persona y hágalo 1:1:

Durante esta reunión, abre la herramienta de seguimiento de errores en su propia computadora portátil y pide que le dicten la descripción del error para que pueda ingresarla en la herramienta. Aproveche esta oportunidad para que le muestren el error o le aclaren los pasos necesarios para reproducirlo.

Recuerde incluir en sus hojas de tiempo el tiempo que dedicó a documentar cada error, eso es solo una parte integral de la corrección del error.

Practica el arte de mantener la cara seria mientras escuchas sus diatribas (siempre que no sean abusivas). Esta es una habilidad importante y la interacción adicional con estas personas puede parecerle una pérdida de tiempo ahora, pero lo ayudará más adelante en su carrera cuando finalmente decida que quiere un mejor trabajo.

Cuando solucione un error que se informó con mucha emoción, acérquese a esa persona y hágale saber que se ha solucionado, y si tiene la amabilidad de verificar y confirmar que funciona a su satisfacción para que pueda cerrar el ticket.

¡Arrástrelos a una reunión de clasificación de errores y oblíguelos a ver cómo se priorizan los informes de errores de los demás sobre los suyos porque el suyo no está en la herramienta!
Esto supone que la persona puede decidir qué hacer con su tiempo. Que tengan tiempo para reuniones, que las otras personas acepten ser arrastradas a una reunión. Teniendo en cuenta que la publicación original decía que BOSS se niega a ingresar boletos, sabemos cómo funcionan las cosas en esta empresa: Boss da órdenes verbales y luego, cuando las cosas salen mal, lo arrojan debajo del autobús. Y siempre están sumergidos en el agua hasta el cuello. Sí, esto no va a suceder en el tipo de lugar de trabajo que OP describió.
Todo esto apesta a agresividad pasiva. Permitir que cada persona haga lo que se le sugiere, cuando acude a usted para informarle el error , es hacer un mejor uso general de su tiempo y el de ellos :o)

Una solución ortogonal:

Agregue un botón de "informe de error" a la versión de prueba alfa del software que recopila automáticamente datos importantes y archiva el informe de error.

Agrega algunos campos de texto simples: "¿Qué estabas tratando de hacer?" "¿Qué esperabas que sucediera?" "¿Qué salió mal?"

(Esto no ayudará, por supuesto, si el problema es que la aplicación se bloquea o falla).

Deje que los usuarios avanzados refinen el informe y dejen que los ranters simplemente presionen "enviar".

He lidiado con esto durante 20 años y básicamente la misma respuesta los últimos 19.

Usted les dice: "Miren, si ese error es importante para ustedes, lo incluiría en el sistema de emisión de boletos lo más rápido posible. Mi equipo y mi gerencia asignan prioridad y tiempo mientras revisan el sistema en busca de errores. Si su error no está en en el mejor de los casos, es de alta prioridad en el próximo ciclo. Realmente no puedo trabajar para arreglar las cosas sin una autorización adecuada. Además, todo el equipo necesita comprender el impacto total, ya que podría afectar otras cosas, es decir, lo que sea que me acaba de decir a todos. necesita ser capaz de ver cuál puede hacer que la resolución del problema sea más rápida".

Los sistemas de ticketing y los usuarios finales son incompatibles. La gente los odia (por muchas buenas y no tan buenas razones). Si tienes un problema, quieres que te escuchen activamente.

Tal vez debas enfatizar de alguna manera que tus colegas son parte activa del desarrollo, y no meros usuarios. Envíe estadísticas de errores y desarrollo todos los viernes, mencione a las personas por su nombre que han ayudado a encontrar errores críticos, tal vez incluso haga una pequeña clasificación (sin embargo, no permita que se vuelva demasiado competitivo).

Además, ¿tal vez pueda mejorar la interfaz de usuario del sistema de emisión de boletos? Cortar todos los detalles técnicos, un cuadro de texto y (muy) pocas categorías para elegir son suficientes. Haga que sea lo más fácil posible informar un error de la manera correcta.

"Si tienes un problema, quieres que te escuchen activamente". - irónicamente, la diatriba de la persona en el escritorio se olvidará cuando se vaya, mientras que un boleto almacenado permanentemente en el rastreador de errores recibirá atención individual y activa en algún momento.

¡JUEGALO!

¡A todo el mundo le encantan los puntos, porque los puntos significan premios**!

Simplemente tenga un marcador de 'La mayoría de los errores encontrados (válidos) esta semana*' junto con menciones especiales para errores particularmente extraños/interesantes para desafiar a todos.

* ¡Solo se pueden contar los errores informados correctamente!

**Los premios solo pueden ser cumplidos

A la gente a la que le gusta despotricar sobre los errores no le gustará ver que "el desarrollador 'incompetente' está tratando de convertir su trabajo en un juego en lugar de arreglar su software". Trabajé en una oficina donde intentaron algo similar, la situación solo empeoró.
Si las personas que encuentran los errores no entienden el papel de un desarrollador, es probable que tampoco deberían ocupar un puesto en el equipo de prueba. Lo ideal sería tener un equipo de prueba dedicado que sepa exactamente lo que está haciendo y por qué. . No se pueden arreglar los lugares de trabajo rotos...
Asi no es como funciona esto. ¿También esperas que OP proporcione sus propios premios? Recuerda que él no es el gerente.
Ok, ok, los premios pueden ser teóricos y simplemente cumplidos.
@djsmiley2k la empresa tiene 50 empleados. Bien podría ser que los probadores sean solo consultores que explican el funcionamiento de la aplicación a los clientes, o tal vez incluso a un vendedor. (¡Sí, esto sucede!) No siempre es posible contar con un equipo de pruebas dedicado, incluso si su producto principal es el software, en una empresa pequeña.
Cuando juegas un sistema como este, las personas encontrarán formas de explotarlo para su beneficio. ¿Quién decide qué es un error "válido"? ¿Cómo maneja a una persona que informa 4 "errores" que son el mismo problema?
Terrible idea. Si las personas obtienen algo adicional, encontrarán errores (que tal vez ni siquiera existan) para 'jugar' con el sistema.
Dilbert relevante: dilbert.com/strip/1995-11-13 .
Trabajé en un lugar que, durante un tiempo, literalmente le dio £ 5 a cualquiera en la empresa que encontrara un error en el software insignia, siempre que no fuera del equipo de desarrollo (NB, no teníamos control de calidad dedicado; imagínense por qué necesitábamos sobornar a la gente para que nos probara!). En última instancia, todavía no obtuvimos muchos interesados ​​y los desarrolladores se sintieron bastante molestos. Porque, ¿por qué otros deberían obtener una bonificación por esto? Encontré errores todos los días, pero no obtuve ningún dinero extra por eso. Eso sí, supongo que yo también los había creado, así que...
¿Cómo manejar a los colegas que no están dispuestos a escribir un informe de error?
RespuestasAquíPolítica de privacidad1y, 1v