Mi jefe decidió agregar un campo de "persona a quien culpar" en cada informe de error. ¿Cómo puedo convencerlo de que es una mala idea?

Dígales que este es solo un nombre de aficionado para el campo Root Cause utilizado por profesionales (cuando el rastreador de problemas no tiene campo dedicado, uno puede usar comentarios para eso).

Busque en la web algo como análisis de la causa del error del software , hay muchos recursos para justificar este razonamiento ^{1 , 2 , 3 , 4 , ...} .

  

... la causa raíz de un defecto no siempre es un solo desarrollador (que es el punto principal de este campo) ...

Es exactamente por eso que "causa raíz" es profesional, mientras que "la persona a quien culpar" es amateur. La responsabilidad personal es excelente, pero hay casos en los que simplemente queda "fuera" del equipo de desarrollo.

Dígale a su jefe que cuando hay un solo desarrollador a quien culpar, el campo de la causa raíz definitivamente cubrirá ese ( "error de codificación cometido por Bob en commit 1234, perdido por Jim en la revisión 567" ). El punto de usar el término causa raíz es cubrir casos como ese, junto con casos que quedan fuera del alcance del equipo de desarrollo.

^{Por ejemplo, si el error ha sido causado por un hardware defectuoso (con la persona responsable de ser alguien fuera del equipo que lo compró y probó), el campo de la causa raíz permite cubrir eso, mientras que el "desarrollador único" culpar "simplemente rompería el seguimiento del problema .}

^{Lo mismo se aplica a otros errores causados por alguien que no pertenece al equipo de desarrollo: errores del probador, cambio de requisitos y decisiones de gestión. Por ejemplo, si la administración decide no invertir en el hardware de recuperación de desastres, "culpar a un solo desarrollador" por un corte de electricidad en el centro de datos simplemente no tendría sentido.}

Otro resultado probable para una política de este tipo es que las personas no informarán errores si creen que pueden ser la "persona a quien culpar", por lo que realmente reducirá la cantidad de errores informados por el equipo.

El principal argumento que usaría contra él es preguntar qué problema está tratando de resolver. Es casi seguro que hay mejores formas de resolver el mismo problema.

Por un lado, ¿realmente solo hay una persona a quien culpar? Si la hay, estás haciendo otra cosa mal. Un buen proceso requiere un trabajo a través de un analista, un programador, un revisor y un probador antes de que llegue a la producción. Si no está haciendo todas estas etapas, tal vez esa sea la solución al problema que su jefe está tratando de resolver. Si usted es entonces cuál es el culpable? Puede que no sea ninguno de ellos, podría ser el código heredado el que tiene la culpa.

No es bueno tener gente que se muerda y apunte con los dedos, tratando de evitar una marca negra que no desaparezca una vez que esté lista. No resuelve nada. Muy pocas personas son maliciosamente negligentes. Debe hacer una retrospectiva adecuada , ver qué salió mal y qué puede hacer para asegurarse no vuelve a salir mal.

A partir de eso, verá claramente si una persona tiene la culpa regularmente y ese puede ser un problema diferente con el que lidiar.

El truco para detener a un administrador establecido para crear la responsabilidad es ofrecerlo libremente , pero de una manera que realmente tiene sentido para ti.

Hay al menos tres problemas con ese campo.

El primero es que culpar a la gente no es bueno para la moral. De acuerdo. Pero a lo mejor no le importa la moral y quiere despedir a los malos desarrolladores. Difícil de argumentar en contra.

El segundo es que hacer que el campo sea correcto será difícil y un tiempo bastante grande. Es más complejo que descubrir quién escribió el código incorrecto. Y cualquier información potencial que sea difícil de entender se puede usar como bolsa de arena / trampa. Pero quizás esté preparado para pagar ese costo y auditar la información. Bien.

El problema más fundamental es que este campo no será una buena métrica para tomar medidas. Claro, tendrá una buena clasificación de cuyo código causa la mayoría de los defectos. Pero adivina quién estará en la parte superior de esa lista? Probablemente el fundador de la empresa, o tal vez un desarrollador principal que tenga una tasa de defectos muy baja pero sea tan productivo que escriba una parte desproporcionada del código. Entonces, o bien terminará despidiendo a su mejor desarrollador, o hará que disminuya la velocidad tanto que ya no es su mejor desarrollador. Y el tipo que escribe una línea de código al mes, preferiblemente comentarios, probablemente será recompensado por sus bajos números de defectos.

Otra falla métrica del software.

La causa raíz de un defecto de campo nunca es una sola persona. La gente perfectamente consciente cometerá errores, y un proceso que espera que sean infalibles no es razonable. Si no está verificando los cambios en los sistemas de producción antes del despliegue, ya sea manualmente o mediante pruebas automatizadas, los errores son inevitables.

Incorrecto:

  

Bob se olvidó de verificar la entrada y el programa se estrelló dividiéndose por cero.

A la derecha:

  

El código vulnerable a un error de división por cero no se detectó antes del despliegue.       Se han agregado nuevos casos de prueba para verificar el manejo adecuado de la entrada no válida. El código se corrigió y todos los nuevos casos de prueba están pasando.

Cambie "Persona a quien culpar" por "Persona a quien alabar"

La persona principal para corregir los errores obtiene su nombre.

Respuesta simple.

El campo "Culpa" no se usará más que como chivo expiatorio y señalamiento, la moral se desplomará, la confianza del equipo se destruirá y todos intentarán encontrar formas de demostrar que algo no es culpa de ellos en lugar de arreglarlo. La gente también estará más inclinada a guardar silencio sobre los errores en lugar de informarlos, porque no quieren que un colega se meta en problemas. Es completamente contraproducente.

¿Qué es más importante, victimizar a alguien por cometer un error honesto o solucionar el problema lo más rápido posible?

Tu jefe parece pensar que los bichos son un signo de pereza o negligencia. Ellos no están. Son un hecho de la vida. ¿Cuántos parches expulsa Microsoft en un año?

Si estás preparado para una pequeña desobediencia civil, haz que el equipo acepte poner una lista de todos los desarrolladores en ese campo para cada error. Si eso no encaja, escribe "¡Soy Espartaco!" en lugar. El punto, por supuesto, es que todos ustedes son responsables de todos los errores, y no están contentos de tener que señalar a la persona que creó un error.

Otra opción: seguir el juego. No haga nada en particular; solo haga un buen trabajo y complete el campo con la mayor precisión posible durante unos meses. Luego, explíquele al jefe que asignar culpa a cada error hace que todos en el equipo sean infelices e incómodos. Dígale que todos sienten que hay poca correlación entre los errores creados y cualquier otra cosa (habilidad, esfuerzo, cordura). (Te ayudará si puedes ejecutar algunos números que muestren que realmente no hay una correlación).

Desobediencia civil de Gandhi: ponga su nombre en cada campo (a menos que otros desarrolladores se pongan en pie y pongan su nombre por sus errores), y acepte la culpa de cada error, ya sea suyo o no. Nada hará que ese campo o la idea de culpar a alguien sea más inútil que esto. Si su jefe pregunta por qué se llama su nombre en todos los campos, entonces puede explicar "porque no creo que el desarrollo sea un juego de culpa, si realmente necesita que la gente culpe y crucifique, crucifíqueme por todo y deje que mi equipo trabaje pacíficamente . "

Una vez hice que un jefe implementara un sistema muy similar a este, y aunque no estaba programando (era un diseño impreso para un diario), el concepto y la respuesta adecuada son los mismos.

Lo que ella hizo fue en lugar de agregar un campo de "persona a quien culpar" en nuestro papeleo, le dio a cada uno de los diseñadores un juego de pegatinas de colores. Cada diseñador recibió una pegatina de diferente color y se le indicó que para cualquier diseño trabajado o incluso tocado la pegatina debe agregarse a la documentación de ese diseño.

El objetivo declarado del jefe para "la iniciativa de calcomanías" era establecer el origen de todos los errores de nuestro departamento (errores en el papeleo, fallas, copias incorrectas, esencialmente el equivalente de impresión de errores)

Lo que hicimos fue darles a cada uno de los otros diseñadores un cuarto de nuestros adhesivos para que tuviéramos todos los colores, y en lugar de poner nuestro color en cada diseño, pusimos los cuatro colores de los diseñadores.

No solo escriba su nombre en el cuadro [Culpa], coloque el nombre de todos en el equipo / proyecto, y asegúrese de que todo el equipo haga lo mismo.

Trabajamos juntos contra su malicia orwelliana y, como resultado, terminamos atrapando los errores de los demás y hablamos el uno con el otro y finalmente tuvimos una reducción significativa de los errores. Sin embargo, ella era una gerente de sh * t, y en lugar de reconocer que su iniciativa terminó uniéndonos y aumentando la productividad, se recuperó del sistema de calcomanías, lo declaró un fracaso y nos reprendió formalmente a todos.

Terminará castigando a su programador más prolífico. Es probable que una o dos personas sean los mejores empleados que hayan trabajado en la mayoría de los proyectos. Si tiene, en un departamento de 10 personas, un codificador que es solo una fuente de producción y ha escrito el 60% del código de la interfaz, entonces el 60% de los errores estarán en su código.

Explique que este sistema hará que parezca que la persona que escribe la mayor parte del código es el peor programador, y la persona que escribe la menor cantidad de código es el mejor programador.

Esto suena muy parecido a cuando Scott Adams señaló la sabiduría fallida de un Bug Bounty cuando el jefe de pelo puntiagudo en Dilbert. Wally anunció que iba a ir y "escribirle un nuevo Mini Van".

Tira cómica de Dilbert para el 13/11/1995 del archivo oficial de tiras cómicas de Dilbert.

Una vez, cuando esquiaba en el esquí de nieve, alguien señaló que "no caerse" no era el signo de un buen esquiador, sino un signo de uno que no intenta nada (o que en realidad no esquía).

Los errores se pueden introducir en el código por una programación deficiente y un diseño deficiente; pero, también pueden venir como consecuencia de escribir muchos códigos difíciles. Dinging personas que producen la mayoría de los errores es tan probable para Ding los desarrolladores pobres como altamente productivos.

Parece que su jefe puede estar frustrado con la cantidad de defectos. ¿Las personas en su grupo son apasionadas por la calidad? Crear un campo 'qué' para la causa en lugar de un campo 'quién' podría ser más productivo. Ej .: Cambio de requisitos, Fallo de diseño, Fallo de implementación, etc. Incluso esto fallará a menos que exista un grupo para mejorar la calidad del producto.

Tal vez debería verlo como "¿Quién está en la mejor posición para corregir el error?" Una parte de mí también se siente, lo rompiste, lo arreglas. Debe haber alguna responsabilidad.

No estoy de acuerdo con mantener algún tipo de puntuación. Algunas personas crean más errores porque trabajan en partes más complejas del código. Si las líneas de código no son una métrica útil, dudo que los errores por cada línea de código sean mejores. El código nunca se registrará.

En algún momento, un gerente debe saber quién está haciendo su trabajo y quién no, y quién lo hace mejor porque el resto del equipo lo hace.

Es extraño que nadie haya mencionado esto antes: Agregar esa funcionalidad al rastreador de errores motivaría a los empleados a tratar de jugar con el sistema .

Este es un problema común para enfoques como lo que presentó la pregunta, entre otras ideas similares (pagar por número de líneas de código, pagar por número de errores). Esto animará a muchos a centrarse en obtener una buena puntuación, en lugar de resolver problemas relacionados con el software en el que están trabajando.

Por ejemplo, tratar de enviar un informe de error con una redacción para disminuir la culpa de uno mismo, y empujarlo a otra persona puede llevar a los desarrolladores a entender mal la causa del problema (o el trabajo que se le da a otro desarrollador que no sabe) esa sección de un código tan buena como la que más lo estaba trabajando y que fue la causa principal del error) lo que lleva a más tiempo y esfuerzo para solucionar el problema.

Su pregunta real fue sobre cómo cambiar la cultura antes de abandonar la empresa, al convencer a su jefe de que agregar a una persona responsable de los informes de errores es una mala idea. Pero, por supuesto, cambiar la cultura requiere que entienda realmente por qué esta es una mala idea.

Esto es una tarea difícil. Además del problema de salvar la cara después de cambiar de opinión, existe el problema básico de que las personas que piensan en soluciones principalmente en términos de culpa individual suelen estar bastante establecidas en esa mentalidad.

Pidiste escribir sobre este tema y Peopleware viene a la mente. Es muy respetado y habla en términos generales sobre cómo administrar a las personas que realizan trabajos creativos donde el resultado es difícil de medir. El problema es que leerlo no ayudará mucho, su jefe tendría que leerlo y creer al menos algo.

Curiosamente, dado que el problema aquí se trata más de personas que de informes de errores, es muy posible que pertenezca más a Workplace que a Programmers. Pero el éxito de los proyectos de software suele ser bastante rastreable a la interacción social humana, por lo que las respuestas reales a menudo son sobre todo cosas que trascienden el software.

Mi única otra sugerencia, mitad seria, es decir (o convencer a un compañero de trabajo para que diga, ya que planea irse) que usted está dispuesto a asumir toda la responsabilidad del éxito del proyecto. , y su nombre debería siempre ir al campo, ya que incluso si alguien más cometió el error directamente, usted asumió la responsabilidad de asegurarse de que todos en el equipo realicen un trabajo de calidad.

Por supuesto, es una tontería, ¿cómo podrías hacer una copia de seguridad de eso, pero algunas personas (especialmente las personas que son grandes culpables) realmente se comen esas cosas? Ronald Reagan solía aceptar públicamente la responsabilidad personal cada vez que un miembro de su gobierno se encontraba atrapado en un escándalo (y había bastantes) y en realidad funcionaba bastante bien políticamente cada vez. La mejor parte para usted es que la responsabilidad generalmente no tiene consecuencias reales, solo piensan que usted es un hombre de pie por asumir la responsabilidad.

O tal vez no es así como caerá. No tiene ningún sentido para mí, por lo que es difícil para mí predecir cuándo funcionará, pero he visto cómo funcionaba cuando parecía que no tenía nada que hacer (en el lugar de trabajo, no solo en el ejemplo de Reagan).

La gente no va al trabajo con la intención de cometer errores, y cualquier estrategia establecida para atribuir específicamente la culpa de lo que pudo o no haber sido un error humano es ridícula, por no mencionar que es extremadamente poco profesional.

Como mínimo, una "parte responsable" asignada para hacerse cargo y "arreglar" el problema, o crear un plan para rastrear y / o evitar que ocurran eventos similares, sería buena. A veces la solución no es más que entrenamiento adicional. He trabajado para varias empresas en las que formaba parte de la descripción de su trabajo, para obtener una educación de "empresa pagada / tiempo de empresa". Un lugar incluso construyó un "centro de capacitación" completo, que la universidad local "toma prestado" en ocasiones, para sus cursos de tecnologías industriales.

He trabajado en un entorno de fabricación durante los últimos 20 años, donde los errores de programación no solo causan errores, destruyen físicamente las cosas o, lo que es peor, hacen daño a las personas. Sin embargo, una constante en cada campo de la fabricación que se mantiene fuerte es que nunca hay, bajo ninguna circunstancia, alguien a quien culpar. Debido a que es un defecto en el sistema, simple y simple, no es un defecto en las personas. Míralo de esta manera: el uso del corrector ortográfico es una herramienta altamente efectiva para aquellos menos afortunados en el área del virtuosismo textual, o quizás solo para aquellos que trabajaron un poco más ... pero de ninguna manera es un método de culpa o responsabilidad.

Un entorno de trabajo, no importa de qué tipo o para qué sirve, es un sistema. Un sistema compuesto de componentes individuales, que si se "sintoniza" correctamente, funciona en total armonía, o alguna apariencia de los mismos.

Lectura sugerida por parte de su jefe: Los 7 hábitos de las personas altamente efectivas

Parece que podría usar un poco de humildad, si no una comprobación de la realidad. Él es tan parte del equipo, como todos los demás, y necesita darse cuenta de eso, o simplemente no funcionará, y al final, llevará la bolsa a pesar de todo.

Lectura y / o investigación sugerida por su parte:

Busque en 5 por qué el análisis, el análisis de la causa raíz ... cualquier cosa que lo ponga en una mejor posición para ofrecer una solución, no un problema . Y su desacuerdo con su jefe es solo eso, un problema, no una solución. Ofrézcale algo mejor, algo que tenga sentido, e incluso prepárese para permitirle reconocer la idea.

En este momento, no parece que esté preparado para arreglar nada, porque no tiene una comprensión firme de lo que está roto, si hay algo roto, aparte de su mentalidad de "yo soy el jefe" .

¡Buena suerte! Espero que logren superar esto, de una manera que sea aceptable para todos, especialmente en estos tiempos.

EDITAR: Personalmente, desde mi propia experiencia ... "Adelante, culpe a mí. Porque, efectivamente, lo arreglaré, y luego, cuando vuelva a suceder, ¿quién estará allí para salvar el día? Sí, lo has adivinado ... yo, con una gran sonrisa. "

Para la responsabilidad, no querría un campo person to blame , quisiera un campo Person who knows the code o un campo person who can fix , para saber dónde enviar el ticket de soporte.

Esto aceleraría el proceso de solución del error y daría responsabilidad, como matar dos pájaros de un tiro. Yo, personalmente, se lo comentaría y le permitiría decidir si esto ayudaría a aumentar la moral y la responsabilidad sin hacer que nadie sienta que fracasó. Las pruebas extremas no detectan todos los errores, de lo contrario no habría informes de errores.

Dígale que "culpar" es negativo. Cámbielo a "persona para arreglarlo", al menos está enmarcado de una manera positiva, y el mismo trabajo aún se hace. ¿Cómo pueden las personas trabajar si se las "culpa"?

Si mi jefe hizo que sucediera lo siguiente, en este orden exacto:

1) Inmediatamente comenzaría a buscar un nuevo trabajo.

2) Cada vez que se informa de un error con la persona a quien culpar, aparece el nombre de mi jefe y un comentario sobre por qué un proceso malo en el equipo es responsable de ello. Y CC que a su jefe (preferiblemente en un lote). ¿Tienes pruebas unitarias? Si no, entonces significa que el proceso dev está roto, por lo tanto el error. ¿Tiene pruebas de integración automatizadas constantes con todos los sistemas externos? Entonces el proceso dev se rompe, por lo tanto el error. ¿Tiene la capacidad de hacer que cada entorno sea idéntico en producción a través de un script para no permitir errores humanos? Entonces el proceso dev se rompe, por lo tanto el error. ¿Es un desarrollador terrible? Entonces el criterio de contratación es el badm, por lo tanto es culpa del jefe. ¿Todos los desarrolladores cometen errores estúpidos debido a la falta de descanso porque trabajan 12 horas al día? Entonces el proceso de desarrollo se rompe. Como puede ver, el 100% de los errores son culpa del jefe.

Como nota al margen: todo buen gerente de desarrollo es consciente de lo que escribí anteriormente. Y las estrategias Agile están destinadas a señalar al jefe o sus superiores por qué el desarrollo se está ralentizando: mire, estamos gastando el 50% de nuestro tiempo corrigiendo errores. Veamos estrategias para reducirlos para que podamos dedicar el 40% del tiempo a corregir errores, y luego revisar este problema para llegar al 30%. etc.

Lamentablemente, parece que no tienes un buen administrador debido al campo. Así que sugiero hacer (1) y no llevarlo al gerente (excepto en su entrevista de salida)

Parece que su jefe no tiene un conocimiento profundo del software y quizás tampoco tenga la intención de hacerlo. Entonces él tiene un idioma diferente, una cultura diferente.

Abandonar un trabajo por un problema como este, incluso antes de intentar dar un paso adelante en busca de una solución es simplemente ser un quitter. Dejar de fumar es dejar de fumar. No renuncies hasta que él te asegure que nunca podrás entenderte. Para estar seguro de eso, primero debes intentarlo.

Como él no sabe nuestro idioma y él es el jefe, el primer paso aquí sería tratar de hablar con él en su idioma. ¿Qué quiero decir con lenguaje? Pensemos juntos:

La gente de software, la mayoría de nosotros amamos el trabajo que hacemos, tenemos una profunda conexión con lo que estamos haciendo. De lo contrario, no funciona y uno no puede continuar en este negocio por mucho tiempo sin amarlo o ser un completo ... usted llena los espacios en blanco ...

Él, sin embargo, ve las cosas de manera muy diferente. Con cada informe de errores, mientras la mayoría de nosotros nos entusiasma hacer que la cosa funcione mejor (no, aunque a veces es realmente muy estresante, nos encantan los problemas, ¡solo admitámoslo!), Lo ve como un fracaso, una medida de ser fracasado. Lo primero que debería querer entender es que los insectos son buenos. Bugs hace que los clientes amen a la compañía. (Ahora este es su lenguaje) Cuando un cliente informa un error, o cuando lo encontramos nosotros mismos, una vez resuelto, es mucho mejor que la situación en la que nunca ocurrió. Los errores crean la lealtad del cliente (¡lo digo en serio!), Los errores crean una gran excusa para la comunicación entre el consumidor y el productor del software.

Para "aumentar el beneficio de los errores", debería ofrecer que los informes de errores sean aún más abiertos. Con cada informe de errores y su solución rápida, limpia y buena, los clientes sienten y ven que "wow, estos tipos son increíbles. Trabajan muy duro. Miren estas cosas que están resolviendo. Ni siquiera sabíamos que el software era tan complejo ¡cosa!" bla bla y bla ...

Haz tu jugada, habla en su idioma. Los errores son excelentes para una empresa de software, no es un problema. Nos hacen la vida.

Para la ética del equipo, la eficiencia o cualquier tipo de conversación que hagas, podría funcionar de la manera opuesta a la que pretendías. Si quiere dejar de fumar, pensará "¡aha, mi solución comenzó a funcionar desde el primer día! ¡Los enlaces malos ya han comenzado a caer por sí mismos antes de que estén expuestos!" Él cree en su idea de encontrar a los chicos malos en la empresa y es muy difícil convencerlo de lo contrario. ¡Especialmente cuando puedes ser uno de esos chicos malos!

Entonces, enfócate en su problema real: Bugs. Demuéstrele que los insectos pueden ser muy útiles. Sin ningún problema, una relación es aburrida. Todo lo que no te mata te hace más fuerte. Cada error es una gran oportunidad que puede utilizar para aumentar la felicidad del cliente.

Esto es solo una cosa que puedes decir. Piense en sus preocupaciones y encontrará muchos otros elementos para agregar a su lista. ¡La CLAVE DE ORO es ofrecer una cosa alternativa en lugar de luchar con su idea!

Si estás haciendo Agile, y parece que eres del comentario features / stories . La persona a quien culpar sería la persona de control de calidad que dejó pasar el error, o el Propietario / Cliente del producto que aceptó la característica / historia como completa con el error en ella.

Hice la composición tipográfica en el día, aquí está mi opinión.

  

Esto es como culpar a un tipógrafo por faltas de ortografía y otras cosas   que un corrector de pruebas debería haber encontrado pero perdido. El tipógrafo hecho   el error de ortografía, pero el corrector de pruebas lo perdió, por lo que es el   el corrector de pruebas tiene la culpa del error cometido al imprimir, no el   Persona que cometió el error en primer lugar.

En un entorno Agile, es responsabilidad de las personas de control de calidad detectar errores (errores) y es responsabilidad del propietario del producto no aceptar las cosas que no son correctas. Estos son dos niveles de lectores de prueba que deberían aislar a los desarrolladores de las cosas que se lanzan, que es la única forma en que cualquier cosa debe clasificarse como un error en un entorno ágil.

Creo que su gerente está tratando de resolver un problema con la solución incorrecta. Creo que tal vez hay un problema de que se están publicando demasiados errores y su administrador quiere que los desarrolladores se responsabilicen más por el código que escriben.

El uso del desarrollo basado en pruebas y la configuración de un servidor de integración continua (como Jenkins ) ayudará a resolver este problema, sin introducir el " juego de la culpa". Un servidor de integración continua es importante para esto porque cuando alguien confirma un código que "rompe la construcción", se envía un correo electrónico al equipo que muestra a la persona a quien culpar. Dado que este código no se ha lanzado a un entorno de producción, este tipo de culpa es más proactiva y alentadora (¡y divertida!).

El resultado es que los desarrolladores tomarán más posesión, se sentirán más seguros y habrá menos errores en el código de producción.

Señale que si el error de una sola persona hace que un error termine en la producción, entonces hay algo que está mal con su metodología o su forma general de desarrollar software. Indique que evitar que los errores lleguen a la producción es responsabilidad de todo el equipo.

Usando cualquiera de estos dos argumentos, vea si puede persuadir a su jefe de que tener el campo "a quién culpar" como un campo de selección única sería engañoso; y por lo tanto, es necesario asegurarse de que el campo "a quién culpar" sea un campo de selección múltiple. Una vez que hayas logrado esto, asegúrate de que para cada error, el nombre de todos esté en el campo. Su jefe eventualmente verá que cualquier informe en el campo es inútil.

Para darle algo de crédito al jefe, el concepto de "asignación de culpa" ya está incorporado en herramientas como SVN , y el uso apropiado de los datos puede ser constructivo para los desarrolladores al "averiguar con quién hablar" mientras se realiza la depuración, por ejemplo: enlace

Aunque estoy de acuerdo con la respuesta de gnat sobre que un campo Raíz raíz es una buena cosa, no es la misma información, y "desnormalizar" el campo para asignar a veces el nombre del desarrollador anterior. ) para la fuente afectada, y algunas veces tener una descripción técnica (por ejemplo, "no escala a 10000 usuarios") solo enturbiará las aguas. Yo abogaría por mantener un campo Raíz raíz claramente una descripción técnica (por ejemplo, incluso cuando se trata de un error claro de programador, haga que capture detalles como "Excepción de IndexOutOfRange cuando fooData = 999") Esto puede potencialmente proporcionar algunos comentarios útiles cuando se revisan en masa, y permiten que se tomen algunas acciones correctivas para resolver clases enteras de problemas con cambios en la arquitectura o el marco (por ejemplo, mejorar las clases de contenedores personalizados, manejo de excepciones de nivel superior)

Dicho esto, agregar un campo Person To Blame claramente puede enviar un mensaje muy malo y un mensaje destructivo a un equipo de software que la administración desea destacar y castigar a los desarrolladores individuales que rompen el código con mayor frecuencia. Sospecho que el gerente cree que este escrutinio público hará que los desarrolladores sean más cuidadosos y autorregulados para evitar que aparezcan sus nombres en este "muro de la vergüenza", y no entiende por qué los desarrolladores se sentirían amenazados por esto, especialmente si se agrega. genéricamente a cada informe de error.

Los problemas para agregar esto como un campo de error / métrica potencial son fáciles de comenzar a enumerar:

1. Los errores son muy variables en la dificultad de resolver, y una estadística simple de conteo de errores / desarrollador no reflejará esto.
2. Los desarrolladores son altamente variables en capacidad "" "" "" "" ""
3. Muchos sistemas de software tienen componentes que necesitan refactorización, sin embargo, la refactorización de componentes heredados (particularmente si la base heredada no tiene instalaciones de pruebas unitarias limitadas) introducirá inicialmente errores. Es probable que los desarrolladores se desanimen de esta "buena" actividad, si hay un estigma / temor asociado con la generación de nuevos errores (incluso si son triviales de resolver y el resultado final es una mejora importante en el sistema).
4. Los evaluadores pueden presentar un número altamente variable de errores relacionados con el mismo problema, lo que resulta en un conteo / desarrollador de errores altamente sesgado, a menos que se realice un análisis más detallado.

Eso es solo la punta del iceberg. Combine esto con la indicación de quién esperaba qué comportamiento de API, los resultados esperados incorrectos en las pruebas y los problemas "anteriores en la cadena" con requisitos incorrectos / faltantes, y debería ser obvio que una métrica como esta está condenada como sin valor (a menos que el objetivo es dañar la moral y causar un éxodo masivo.)

Volviendo al punto de vista del jefe, está bien que él / ella quiera averiguar si hay desarrolladores que están rompiendo el código repetidamente, y tratar de hacer algo (con suerte constructivo) al respecto. Tratar de obtener esta información agregando un campo a los informes de errores no proporcionará información significativa por las razones enumeradas anteriormente. En mi experiencia, esta información puede aprenderse al estar conectada con el equipo, participar en la mayoría de las reuniones del equipo, integrar (cuidadosamente) la información aprendida en reuniones individuales ocasionales con los miembros del equipo y familiarizarse con los subsistemas en el código (incluso si no pueden leer el código).

Sólo déjalo ir. Su jefe descubrirá por sí mismo que causa un problema, si lo hace.

Seamos francos, tienes una opinión y él también. Él es tu manager y su opinión es la que gana.

Sí, puedes ir a la guerra por este problema, pero ¿realmente vale la pena? Dudo que dure más de 3 meses antes de que quede en desuso.

Pero sabotear esto activamente o gritarlo solo consume capital político que es mejor ahorrarlo por pedir ese tiempo extra, el próximo aumento, la promoción o cuando se va a tomar una decisión de diseño realmente importante.

En ese momento, cuando realmente cuenta, no quiere que el jefe recuerde que usted fue la persona que saboteó activamente su idea de "persona a quien culpar".

Respete la oficina aunque no respete la decisión.

Ahorre estrés y golpee la mesa para tomar decisiones que durarán mucho más.

Dígale a su jefe que desarrollar en un equipo necesita habilidades sociales. Incluso podría asentir.

Pero el problema es que esto es algo con lo que los desarrolladores son extremadamente malos. Agregar herramientas que sugieran que culpar es más importante que un análisis de problemas adecuado es contraproducente.

En cambio, necesita incentivos para mejorar las habilidades sociales, y la infraestructura de comunicación que tiene debe respaldar eso. Por ejemplo, acuéstelo positivamente: nombre una persona que es responsable de un boleto, que se encarga de ello.

También comience con las revisiones de código para que puedan aprender unos de otros. Eso ahorra las culpas más adelante.

Envíele por correo electrónico esta pregunta SO. Si está abierto a la razón, los comentarios aquí proporcionarán controles de cordura para su razonamiento. Si no es razonable, es poco probable que lo convenza con razones que tengan sentido. Además, podrá leer los motivos fuera de una conversación (lo que a veces puede ser más convincente debido a la motivación eliminada de "tener razón" en el momento de una conversación).

También puedes intentar darle la vuelta. El campo podría ser "pasos posibles para evitar que ocurra un error similar", o algo más corto para ese efecto. Luego, puede agrupar soluciones y votar sobre cuáles implementar para mejorar su lugar de trabajo. Tal vez un enfoque orientado a la solución sea más productivo y probablemente se reciba mejor (siempre que haya un seguimiento real de la revisión de sugerencias).

Veo dos posibilidades aquí: Él quiere poder castigar a las personas que cometen errores, o simplemente no lo ha pensado. Hágale saber que la percepción de todos será que pretende castigar a quienes cometen errores. Pregúntale si esa es la cultura que él quiere fomentar.

mi jefe decidió que agregar un campo "Person To Blame" a nuestra plantilla de seguimiento de errores aumentará la responsabilidad

En mi experiencia, cuando la gerencia quiere "hacer que las personas sean más responsables", lo que quieren decir es que quieren ser capaces de imponer un castigo por el fracaso. Ya sea para despedir a los de bajo rendimiento, o simplemente dejar que se pierdan en la revisión salarial anual ("Lo siento, Bob, tienes 17 errores marcados como tu culpa, y eso supera el límite de 15"), es un castigo.

Probablemente dirá "Oh, no, no queremos eso", entonces pregúntale cómo se utilizarán esos datos. Recuérdele que no agrega puntos de datos a una base de datos a menos que vaya a usarla. ¿Desea o bien seleccionar un criterio dado ("Mostrar todos los errores abiertos en el subsistema creador de informes"), para que pueda trabajar en cosas, o para poder obtener datos agregados ("¿Qué subsistema ha tenido más bugs "), para que puedas hacer análisis post-mortem. ¿Visualiza algún tipo de plan de fracaso donde las personas puedan humillarse públicamente?

Entonces, ¿cuál es su intención? ¿Quiere poder decir "Mostrarme todos los errores que son culpa de Bob?" ¿Por qué? ¿O quiere poder decir "Muéstrame quién tiene la culpa la mayor parte del tiempo?" ¿Por qué? El primero no es significativo, y el segundo es solo punitivo. O la tercera opción es que no tiene ninguna razón real.

Admito que existe la posibilidad de que él esté buscando a aquellos programadores del equipo que necesitan ayuda para mejorar sus habilidades. Si es así, hay mejores formas de capturar esta información que no crean una cultura de señalar con los dedos.

Creo que el aspecto clave que se debe observar aquí es cuán abierta está la comunicación en el equipo hacia el "jefe" y al revés. Señalar con el dedo nunca es bueno, sin embargo, desde la perspectiva de la administración, si uno de sus desarrolladores cae en el mismo problema varias veces, podría ser el momento de intervenir y tratar de ayudarlo a superar este problema repetitivo (por ejemplo, John no está realizando las pruebas correctamente. el código: 3 errores de producción en los últimos 3 meses, vamos a darle una lista de verificación para que recuerde cómo se supone que es su código y cómo debería probarlo).

Desde el punto de vista del desarrollo, "culpar" ya está incorporado en una herramienta común como SVN, por lo tanto, realmente no veo ningún daño en ir "John, por favor, arregla ese pedazo de basura que escribiste" y ponle un nombre al lado de él. JIRA también incorpora el nombre de una persona cuando se presenta un error (sin embargo, el campo no está realmente destinado a la persona responsable de esto, sino que alguien lo arregla).

Una vez más, creo que todo se trata de la comunicación. Quizás lo único que su jefe quiere hacer es ver quién tiene problemas en el equipo de desarrollo o qué tipo de problemas tiene el equipo (¿quizás para las sesiones de entrenamiento?), Pero no creo que descubra exactamente qué hay detrás de él. decisión (o mejor dicho, nosotros, carteles / lectores) a menos que hable con su jefe y con todo su equipo.